为真实世界装备智能体：Agent Skills

Equipping agents for the real world with agent skills

https://github.com/anthropiddcs/skills

Agentic 软件工程工作流（Agent-driven SE）

梳理重点（Agent Skills）：

1. 问题背景：模型很强，但真实工作需要流程知识 + 组织上下文
2. 核心思想：用文件夹 + SKILL.md，把人的“操作流程”交给 Agent
3. Skill 本质：不是 prompt，而是可复用的“工作说明书”
4. 触发机制：先加载 name / description，再按需读取完整内容
5. 关键原则：渐进式披露（只在需要时加载更多上下文）
6. 工程取向：能用代码做的事，不让模型用 token 硬算
7. 迭代方式：从 Agent 的失败中反推并完善 Skill

重点对照表

Agent 能力构建：问题 → Skill 解法

关注点	传统方式	Agent Skills 做法
流程知识	写在 prompt 里	写成 SKILL.md
上下文规模	一次性全塞	分层、按需加载
复杂操作	语言模拟	脚本直接执行
可复用性	几乎没有	Skill 可移植
稳定性	易跑偏	流程被固化
长期演进	不可积累	失败沉淀为 Skill

Agent Skills = 把人的工作流程，变成 Agent 能反复执行的能力包

详细论述：用 Skill 驱动 Agent

一、核心认知转变（最重要的一条）

从「写 prompt」→「构建会工作的 Agent」

传统用 AI 编程的方式是：

写 prompt → AI 回答 → 复制粘贴 → 改

Agent Skills 代表的是范式升级：

把流程、经验、规范写成结构化资源 → AI 在真实环境中按流程执行

也就是说：

• Prompt 是临时指令
• Agent Skills 是工程资产
• AI 不再是“问一次答一次的助手”，而是长期协作的工程角色

👉 这是一种工程化用 AI，而不是“对话式用 AI”。

---

二、AI 编程的标准工程步骤（Agent-first 流程）

结合文章，总结出一个稳定可复用的 6 步开发流程：

---

Step 0：准备真实执行环境（不是聊天）

前提条件：

• AI 能访问：
  • 文件系统
  • 代码仓库
  • 命令行 / 脚本执行
• 示例：
  • Claude Code
  • Codex CLI
  • 带工具调用的 Agent

📌 结论：

没有“代码执行 + 文件系统”的 AI，不适合做工程级开发。

---

Step 1：先做评估（Evaluation-first）

不要一上来就“让 AI 写功能”

正确做法：

• 给 Agent 一些代表性任务
• 观察它：
  • 哪些地方反复出错？
  • 哪些步骤需要你反复解释？
  • 哪些流程每次都要你手动纠正？

📌 工程结论：

Agent 的失败点 = Skill 的设计起点

---

Step 2：把“人脑里的流程”固化成 Skill（而不是 prompt）

文章里的关键思想是：

Skill ≈ 新员工入职手册

要做的是：

• 把“每次都会提醒 AI 的东西”写下来
• 包括：
  • 开发顺序
  • 约束规则
  • 常见错误
  • 推荐做法

形式不是一大段 prompt，而是：

skill/
 ├ SKILL.md        ← 什么时候用、怎么用
 ├ plan.md         ← 规划模板
 ├ checklist.md    ← 校验清单
 ├ scripts/        ← 可执行脚本（可选）

📌 工程结论：

重复说三次的 prompt，必须变成 Skill

---

Step 3：使用“渐进式披露”控制复杂度（Progressive Disclosure）

文章里最重要的工程思想之一。

不要一次性塞给 AI 所有规则

而是分层：

1. 元信息（name + description）
   • 只告诉 AI：这个 Skill 是干嘛的
2. 核心流程（SKILL.md 正文）
   • AI 判断“需要用”时才加载
3. 细节文件（额外 md / 脚本）
   • 只在特定场景下读取

📌 工程结论：

上下文不是越多越好，而是“按需加载”最好

这解决了：

• 上下文爆炸
• 模型注意力分散
• 长任务失控

---

Step 4：让 AI 用“代码”而不是“生成 token”解决问题

文章非常明确地强调了一点：

能用代码解决的，就不要让模型用自然语言去“算”

典型做法：

• 排序、解析、提取、转换 → 用脚本
• 模型负责：
  • 判断何时执行
  • 如何组合结果
• 代码负责：
  • 确定性
  • 可复现
  • 高效率

📌 工程结论：

AI 是调度者，代码是执行者

这会极大提升：

• 稳定性
• 可调试性
• 成本效率

---

Step 5：以 Claude / AI 的“视角”来设计工程结构

这是一个反直觉但非常关键的原则。

要问的问题不是：

我觉得这样好不好？

而是：

• AI 会不会误用这个 Skill？
• 名字是否清晰到足以触发？
• description 是否能准确区分相似 Skill？
• 是否存在 AI 误加载、过度加载？

📌 工程结论：

工程结构要为“机器理解”优化，而不是只为人

---

Step 6：与 AI 一起迭代工程资产（Meta-development）

这是 AI 工程和传统工程最大的不同：

AI 既是使用者，也是改进者

正确做法：

• 当 AI 成功完成一个复杂任务：
  • 让它总结“成功路径”
  • 写回 Skill
• 当 AI 失败：
  • 让它反思失败原因
  • 修正 Skill，而不是骂模型

📌 工程结论：

Skill 是活文档，不是一次性配置

---

三、整体方法论总结（浓缩版）

可以把这套方法论总结为一句话：

用 AI 写代码 ≠ 用 prompt 驱动模型用 AI 做工程 = 用 Skill 驱动 Agent

---

方法论关键词总结

关键词	含义
Agent-first	以可执行 Agent 为核心
Evaluation-driven	从失败中设计能力
Skillization	把经验变成结构化能力
Progressive Disclosure	分层加载上下文
Code over Tokens	用代码替代语言推理
Machine-centric Design	为 AI 设计工程结构
Continuous Skill Evolution	持续进化能力库

---

四、这套方法适合什么样的项目？

非常适合：

• 中大型项目
• 长期维护项目
• 有明确流程/规范的系统
• 你想反复用 AI 做同类事情（CRUD、API、前端、迁移、测试）

不太适合：

• 一次性脚本
• 超短实验
• 完全无结构的探索

---

五、一句话总结

不要让 AI 每次“重新理解你的世界”，而是把你的世界写成它能反复使用的能力模块。

Agentic软件工程方法论和项目管理思考：

AI 编程真正的瓶颈已经不在“写不写得出代码”，而在“如何把知识、流程和上下文长期、稳定地交给 AI 使用”。

Agent Skills 本质上并不是一个新工具，而是一种把人的经验工程化、文件化、可复用化的思路。

在现阶段，想要更好地利用 AI 进行系统性开发，关键不再是不断给模型下更复杂的 Prompt，而是把“怎么做事”从对话里迁移到结构化的资产中。Skills、spec、plan、脚本、本地文件夹，其实都是在做同一件事：把隐性的工作经验显性化，并且让 AI 能按需加载，而不是一次性塞进上下文。

从软件工程的角度看，AI 编程正在推动一种新的开发范式：

人不再直接“写所有代码”，而是设计约束、定义流程、搭建样板和护栏；AI 则在这些约束之内进行高强度实现。这意味着工程质量越来越依赖于前期的结构设计——比如不变式、目录结构、技能拆分、上下文加载边界——而不是某一次生成是否“灵光一现”。

这也改变了项目管理的重心。传统项目管理关注的是“任务拆分给人”，而在 AI 编程下，更重要的是管理 AI 的工作方式：

如何防止它过早宣布完成、如何避免上下文漂移、如何让它在多次会话中保持一致理解。像 Agent Skills、spec-kit、AGENTS.md 这类机制，本质上都是在为 AI 建立一种“可持续工作的认知环境”。

另外一个很重要的转变是：代码不再只是产出物，也是训练和约束 AI 的媒介。

脚本既是工具也是文档，文件夹结构既是组织方式也是认知地图。好的工程结构，本身就在“教 AI 怎么工作”。

从更长远来看，这种方式也解释了为什么“长期运行的 agent”“skills 可移植”“跨平台共享经验”会变得重要——当 AI 能够不断把成功的工作模式沉淀为技能文件时，开发效率的提升将不再是线性的，而是经验复利式的。

可以确认的一点：

未来的高效开发者，更像是 AI 的系统架构师和流程设计师，而不是单纯的代码生产者。