Agent Skill：大家开始把经验打包给 Agent

Agent Skill 解决的核心问题很直接：把重复任务里的经验、流程、规则和脚本打包起来，让 Agent 在需要时按这套方法做事。

如果说 MCP 更像工具连接层，Skill 更像任务执行手册。MCP 让 Agent 接上外部工具，Skill 让 Agent 知道某类任务应该怎么做。

先给结论：

问题	Skill 的作用
每次都要重复写长 Prompt	把固定任务流程沉淀成可复用说明
团队规范容易散在文档里	把规范放进 Agent 可加载的工作手册
Tool 只能提供单个动作	Skill 可以组织多步骤流程
项目经验难复用	把检查清单、脚本、模板一起打包
上下文需要控制	通过描述触发，再按需加载细节

一句话概括：Skill 解决的是“经验复用”和“流程稳定”。它适合高频、边界清楚、有固定标准的任务。

Skill 解决的核心摩擦

很多人一开始会把 Skill 当成高级 Prompt。这个理解有一部分对，但还不够。

Prompt 更像一次会话里的指令。你可以告诉模型：

请按照我们的代码审查规范检查这段 Java 代码：
1. 看事务边界
2. 看空指针
3. 看日志
4. 看异常处理
5. 看测试覆盖

这次模型会照做。换一个会话、换一个同事、换一个项目，又要重新贴一遍。

如果规范很长，还会出现几个问题：

• Prompt 变得很臃肿。
• 模型容易忽略中间规则。
• 团队成员复制的版本可能不一致。
• 规则更新后，很难保证所有人同步。
• 一些动作需要脚本辅助，单纯文本指令承载不了。

Skill 想解决的就是这类摩擦。它把一类任务需要的说明、流程、脚本、模板、检查清单放到一个独立包里。Agent 看到任务匹配时，再加载对应 Skill。

Skill 通常长什么样

一个 Skill 通常以小目录的形式存在。

java-service-review/
├─ SKILL.md
├─ scripts/
│  └─ run-checks.sh
├─ references/
│  └─ review-rules.md
└─ assets/
   └─ report-template.md

最核心的是 SKILL.md。它通常包含两类内容：

1. 元数据。

元数据告诉 Agent 这个 Skill 叫什么、适合什么场景。

---
name: java-service-review
description: Review Java service-layer changes for transaction boundaries, null handling, logging, exceptions, and regression tests.
---

2. 执行说明。

执行说明告诉 Agent 触发后要怎么做。

# Java Service Review

Use this skill when reviewing Java service-layer changes.

Steps:
1. Inspect changed service methods.
2. Check transaction boundaries.
3. Check null handling and validation.
4. Check logging and exception handling.
5. Run related tests if available.
6. Produce a review report with risks and suggested fixes.

真正成熟的 Skill 往往还会配脚本和规则文档。

部分	作用	适合放什么
SKILL.md	入口、触发描述、主流程	使用场景、步骤、边界
scripts/	可执行动作	检查脚本、转换脚本、生成脚本
references/	详细规则	团队规范、平台规则、领域知识
assets/	稳定模板	报告模板、输出格式、示例文件

这样设计的好处是，Agent 不需要一开始读完所有细节。它可以先通过 description 判断是否需要这个 Skill，再按任务需要读取 references/ 或调用 scripts/。

Skill 的关键机制：按需加载

Skill 的价值不只是“把说明文档放到一个目录”。真正关键的是按需加载。

如果把所有规则都塞进全局上下文，模型每次任务都要背着一堆无关信息。写前端页面时看到 Java 审查规则，写博客时看到数据库迁移规范，都会浪费上下文。

Skill 的思路是：

用户提出任务
-> Agent 根据任务和 Skill description 判断是否匹配
-> 匹配后读取 SKILL.md
-> 根据流程再读取 references 或运行 scripts
-> 完成任务并输出结果

这有点像渐进式加载：

阶段	加载内容	目的
发现阶段	Skill 名称和描述	判断是否相关
执行阶段	SKILL.md 主流程	知道怎么做
深入阶段	参考文档和脚本	处理具体细节

这个机制能缓解上下文膨胀。Agent 平时只需要知道有哪些 Skill，以及它们大概适合什么任务。真正用到时，再加载细节。

所以 Skill 的 description 很重要。它写得太宽，容易误触发；写得太窄，Agent 可能想不到要用它。

Skill 和 Prompt、Tool、MCP 的区别

这几个概念经常混在一起。可以从“解决的问题”来拆。

机制	解决的问题	更适合放什么
Prompt	当前会话怎么做	一次性要求、临时背景
Tool	执行一个具体动作	查询、计算、写文件、调用 API
MCP	外部工具怎么接入	GitHub、数据库、浏览器、文件系统
Skill	一类任务怎么稳定完成	工作流、检查清单、团队规范、模板

举个例子：让 Agent 做一次代码审查。

Prompt 可以写：

帮我 review 这个 PR，重点看事务、空指针和测试。

Tool 可以提供：

读取 diff
运行测试
查询静态扫描结果

MCP 可以把 GitHub、CI、代码仓库接进来。

Skill 可以组织整个流程：

1. 读取 PR diff
2. 按团队规范检查风险
3. 调用测试工具
4. 汇总问题
5. 按固定模板输出 review

所以 Skill 更适合把 Prompt、Tool、MCP 串成一个可复用任务流程。

一个最小 Skill 可以怎么写

最小 Skill 不需要一开始就做得很复杂。可以先围绕一个高频任务写清楚三件事：

1. 什么场景触发。
2. 按什么步骤做。
3. 输出什么结果。

比如一个技术文章检查 Skill：

article-review/
└─ SKILL.md

SKILL.md 可以先写到这个粒度：

---
name: article-review
description: Review a Chinese technical article for structure, factual clarity, AI-like phrasing, and reader flow.
---

# Article Review

Use this skill when reviewing a Chinese technical blog draft.

Steps:
1. Check whether the article has a clear main question.
2. Check whether each section supports that question.
3. Mark vague claims that need examples or evidence.
4. Find AI-like phrasing and suggest more natural wording.
5. Check whether the ending gives a clear judgment.

Output:
- Main issue
- Structural suggestions
- Sentence-level suggestions
- Final revision priority

这个 Skill 没有脚本，也能工作。它先解决流程复用。

如果后面发现某些动作可以自动化，再加脚本：

article-review/
├─ SKILL.md
└─ scripts/
   └─ check-ai-phrasing.js

这就是 Skill 的一个常见演进方式：先沉淀流程，再把确定性动作脚本化。

什么任务适合做成 Skill

适合做成 Skill 的任务通常有几个特征：

特征	说明
高频重复	经常做，重复讲规则很浪费
标准明确	有稳定流程、检查清单或输出格式
多步骤	需要先做 A，再做 B，再汇总 C
有团队规范	希望多人按同一套方式执行
可配脚本	部分步骤能用脚本提高确定性

典型场景包括：

• 代码审查。
• TDD 开发流程。
• 技术文章检查。
• 前端页面实现规范。
• PR 总结。
• 测试用例生成。
• 数据报表生成。
• 发布前检查。

这类任务靠临时 Prompt 能做，但效果不稳定。做成 Skill 后，流程、标准和输出格式会更统一。

什么任务不适合一上来做成 Skill

有些任务写成 Skill 的收益不高。

场景	原因
一次性探索任务	流程还没稳定，提前封装会限制思路
强创意任务	固定步骤可能压缩发挥空间
输入差异极大	Skill 很难写出清楚触发边界
高风险自动动作	需要权限、确认和审计先到位
规则频繁变化	维护成本可能超过收益

Skill 的前提是“可复用”。当一个任务还处在探索阶段，先用普通 Prompt 或手动流程更合适。等流程反复出现，再沉淀成 Skill。

写 Skill 最容易踩的坑

Skill 看起来只是写个 SKILL.md，实际用起来有几个常见坑。

1. description 写得太泛

比如：

description: Help with programming tasks.

这个描述几乎什么都能匹配，Agent 很容易误触发。

更好的写法是写清场景：

description: Review Java service-layer code changes for transaction, null handling, logging, exception, and regression-test risks.

Skill 的触发很依赖描述。描述越具体，路由越稳定。

2. 把知识库塞进 SKILL.md

SKILL.md 适合放入口和主流程。详细规则适合放到 references/。

如果把几十页规范全塞进 SKILL.md，Agent 每次加载都会吃掉大量上下文，也更容易抓不住重点。

更合理的结构是：

SKILL.md      -> 主流程
references/  -> 详细规范
scripts/     -> 确定性动作
assets/      -> 输出模板

3. 只写建议，不写输出格式

很多 Skill 会写“请认真检查”“请给出建议”。这类描述太松。

更好的方式是明确输出结构：

Output:
- Summary
- Blocking issues
- Non-blocking suggestions
- Missing tests
- Suggested next action

Agent 最后输出什么，应该在 Skill 里给出稳定格式。

4. 把危险动作自动化

Skill 可以调用脚本，但脚本不代表什么都能自动执行。

删除文件、发布内容、修改数据库、调用付费接口这类动作，需要确认点。Skill 里应该写清楚哪些动作可以直接做，哪些动作需要停下来让人确认。

5. 缺少测试样例

Skill 也需要测试。

至少要准备几类样例：

• 正常输入。
• 缺字段输入。
• 边界输入。
• 不适合触发的输入。
• 触发后应该停止确认的输入。

没有样例，Skill 容易变成一份“看起来很完整”的说明文档，用起来才发现触发不稳。

Skill 的价值不在“更聪明”

Skill 不会让模型本身突然变强。它的价值在于把任务环境变得更稳定。

对 Agent 来说，Skill 提供了几样东西：

• 任务边界。
• 执行顺序。
• 领域规则。
• 输出格式。
• 可调用脚本。
• 人工确认点。

这些东西能减少随机性。尤其在团队协作场景里，Skill 可以把“某个熟手脑子里的流程”变成可复用资产。

所以 Skill 更像工作手册和工具包的结合。它通过流程、规则和脚本，让模型在某类任务里少走弯路。

我的判断

Agent Skill 最适合沉淀高频、标准明确、流程稳定的任务。

它的优势很明显：

• 降低重复 Prompt 成本。
• 统一团队执行标准。
• 让复杂任务有固定步骤。
• 把脚本和模板纳入同一个能力包。
• 通过按需加载减少上下文浪费。

它的代价也很明确：

• description 写不好会误触发。
• 流程写太死会降低灵活性。
• 规则维护需要版本意识。
• 脚本动作需要权限和确认。
• Skill 数量多了以后需要治理。

我会把 Skill 看成 Agent 工程里的“流程复用层”。Prompt 解决当前怎么说，Tool 解决单个动作怎么执行，MCP 解决外部工具怎么接入，Skill 解决一类任务怎么稳定完成。

真正好用的 Skill，通常是从重复工作里长出来的：先靠 Prompt 跑几次，发现流程稳定，再写成 SKILL.md；发现某些步骤每次都一样，再抽成脚本；发现输出总要统一，再加模板。

Skill 的成熟度，取决于它能否把经验、边界和确定性动作放在合适的位置。写得好，它会让 Agent 像一个按流程办事的熟手；写得太泛，它只会变成另一份没人维护的长 Prompt。