AI Agent 的基本模型：
Agentic Coding
↓
Context Engineering
↓
MCP
↓
Tool Design
↓
Agent Loop
但还有一个问题没有解决：
Agent 知道有哪些工具，也知道怎么调用工具，为什么它还是经常“不知道应该怎么做”？
例如让 Agent 完成一次代码 Review。
它可能拥有：
git_diff
read_file
search_code
run_test
这些 Tool 已经足够让它操作代码库。
但它仍然需要知道：
先看什么？
重点检查什么？
什么问题值得报告？
如何判断问题严重程度？
什么时候应该运行测试？
最终应该如何输出？
这些内容既不是 Tool，也不是 MCP。
它更接近一种：
任务级的知识、流程和操作规范。
这就是 Agent Skill。
今天的 Agent Skills 已经不只是某个产品里的一个概念，而是正在形成一个开放的文件格式和生态。官方规范将 Skill 定义为一个包含 SKILL.md 的目录，可以进一步携带脚本、参考资料和其他资源，并通过 Progressive Disclosure 按需加载。
1. Skill 到底是什么？
先给出一个比较工程化的定义：
Skill 是围绕某一类任务封装的可复用知识、操作流程、规则、示例和辅助资源，让 Agent 能够以更加稳定和一致的方式完成这类任务。
例如：
code-review
不是一个具体的 Tool。
它可能包含：
代码 Review 原则
↓
Review 流程
↓
问题分类
↓
严重程度判断
↓
测试策略
↓
输出格式
Agent 可以进一步调用：
git_diff
read_file
search_code
run_test
这些 Tool。
所以可以把两者简单理解成：
Tool
=
“我能做什么？”
Skill
=
“面对这类任务，我应该怎么做？”
例如：
Tool：
search_code()
Skill：
发现 Bug
→ 定位相关代码
→ 阅读上下文
→ 判断影响范围
→ 搜索调用方
→ 验证假设
→ 给出修改建议
Tool 提供能力。
Skill 提供方法。
2. Skill、Prompt、Tool、MCP 和 Workflow 有什么区别？
这是最容易混淆的地方。
可以把几个概念放在同一个任务里理解。
假设用户说：
「帮我检查这个 Pull Request。」
Agent 可能拥有：
Prompt
↓
当前用户提出的任务
Skill
↓
告诉 Agent 如何进行 Code Review
Tool
↓
git_diff
read_file
search_code
run_test
MCP
↓
负责把 GitHub 等外部系统的能力标准化提供给 Agent
Workflow
↓
如果某些步骤是固定的，可以按照固定流程执行
因此：
| 概念 | 主要解决什么问题 |
|---|---|
| Prompt | 当前这次要做什么 |
| Tool | Agent 能执行什么动作 |
| MCP | Agent 如何标准化连接外部能力 |
| Skill | 某一类任务应该怎么做 |
| Workflow | 一组确定步骤应该怎么执行 |
| Agent | 根据目标、Context 和环境决定下一步 |
可以进一步画成：
User Task
│
↓
Agent
│
┌──────────┼──────────┐
↓ ↓ ↓
Context Skill Memory
│
↓
Task Methodology
│
┌──────────┼──────────┐
↓ ↓ ↓
Tool Workflow Rules
│
↓
MCP
│
↓
External Systems
因此，Skill 并不是「另一个 Prompt」。
也不是「Tool 的别名」。
它实际上位于 Agent 的任务知识层。
3. 为什么 Agent 需要 Skill？
因为 Tool 越多，Agent 不一定越强。
假设一个 Coding Agent 有：
git_status
git_diff
git_log
read_file
write_file
search_code
run_test
create_branch
commit
push
create_pr
从能力上看，它已经非常强。
但如果用户说：
「这个登录接口偶尔返回 500，帮我排查。」
Agent 还是需要决定：
先看日志？
还是先看代码？
先复现？
还是先搜索异常？
修改之前需要不需要测试？
测试失败以后应该怎么继续？
如果没有明确的任务方法，模型只能依靠训练数据和当前 Context 临时推断。
于是同一个任务可能出现：
第一次：
搜索代码 → 修改 → 测试
第二次：
直接修改 → 测试 → 再搜索
第三次：
分析半天 → 没有执行测试
这就是 Agent 工程中一个非常现实的问题：
模型具有通用能力，但企业级任务通常需要稳定的方法。
Skill 的作用，就是把这些方法沉淀下来。
人的经验
↓
Skill
↓
Agent
↓
重复执行
因此 Skill 的价值并不是让模型「知道更多知识」，而是让模型在某一类任务上按照更稳定的方法工作。
04. 一个 Skill 到底长什么样？
目前已经出现了一个开放的 Agent Skills 格式。
按照官方规范，一个 Skill 最基本的结构是：
my-skill/
└── SKILL.md
更完整的 Skill 可以是：
my-skill/
├── SKILL.md
├── scripts/
│ └── validate.py
├── references/
│ ├── api.md
│ └── guidelines.md
└── assets/
└── template.md
其中：
SKILL.md
是核心。
它包含 YAML Front Matter 和 Markdown 指令。
最简单的例子：
---
name: code-review
description: Review code changes for correctness, security, performance, and maintainability. Use when reviewing pull requests, diffs, or requested code changes.
---
# Code Review
Review the change systematically.
## Process
1. Understand the purpose of the change.
2. Inspect the diff.
3. Check business logic.
4. Check error handling.
5. Check security.
6. Check performance.
7. Check tests.
## Output
For every issue, provide:
- file
- line
- severity
- problem
- impact
- recommendation
这里最值得注意的是：
Skill 本身不需要复杂的 SDK。
它可以只是一个目录和一份 Markdown。
这也是 Agent Skills 非常有意思的地方：
传统扩展：
代码
+
SDK
+
Plugin API
+
配置
Agent Skill：
文件
+
指令
+
可选资源
官方规范要求 name 和 description，其中 description 不只是介绍 Skill 做什么，还应该说明什么时候使用，因为它参与 Agent 对 Skill 的发现和选择。
5. 最关键的设计：Progressive Disclosure
Skill 最值得理解的一个设计，是：
不要一开始把所有内容全部塞进 Context。
假设有：
100 个 Skill
每个 Skill：
5000 Token
如果启动时全部加载：
100 × 5000 = 500,000 Token
显然不可行。
因此 Agent Skills 采用 Progressive Disclosure：
第一层：Discovery
↓
name + description
第二层：Activation
↓
SKILL.md
第三层：Execution
↓
scripts / references / assets
也就是：
启动时：
code-review
debugging
testing
mysql-optimization
pdf-analysis
...
只知道“有哪些 Skill”。
用户：
“帮我 Review 这个 PR。”
↓
匹配：
code-review
↓
加载：
code-review/SKILL.md
↓
发现需要数据库检查：
读取：
references/database.md
↓
必要时执行：
scripts/check.sh
官方规范明确将 Skill 的加载设计为三个阶段：
启动时加载
name和description；Skill 被激活后加载完整
SKILL.md；执行过程中再按需加载
scripts/、references/、assets/等资源。
这实际上和上一篇讲的 Context Engineering 是直接对应的：
Skill
↓
减少一次性 Context
↓
按任务加载
↓
降低上下文成本
↓
提高相关信息密度
所以 Progressive Disclosure 并不是一个目录结构技巧。
它本质上是：
Context Engineering 在 Skill 层面的具体实现。
6. 一个高 Star 的经典案例：mattpocock/skills
如果想真正理解 Skill，而不是停留在概念层面，非常推荐直接研究 GitHub 上的：
这个项目的定位很直接：
Skills for Real Engineers.
它不是为了展示几个简单 Prompt，而是把 Skill 真正用于软件工程工作。
当前仓库已经拥有约 19.6 万 Star 和 2.2 万 Fork，并且持续维护。仓库中包含工程开发、代码 Review、Debug、TDD、Issue 管理、需求规格等多个 Skill。
它的一个重要特点是：
Skill 被当成真正的软件工程资产，而不是一次性 Prompt。
例如仓库中的工程 Skill 包括：
ask-matt
triage
code-review
debugging
to-spec
to-tickets
testing
writing-great-skills
这些 Skill 并不是简单地告诉模型：
“请认真写代码。”
而是把工程经验拆成可以复用、组合和维护的能力。
例如 to-spec 的职责就是把当前对话中的需求整理成项目规格，并发布到项目 Issue Tracker。
这就很接近真正的 Agent Engineering：
User Request
↓
Skill
↓
工程方法
↓
Tool
↓
项目实际状态
↓
产出
7. 重点看一个 Skill：writing-great-skills
这个项目中有一个值得研究的 Skill：
writing-great-skills
它甚至是一个：
用来帮助 Agent 编写 Skill 的 Skill。
这非常有代表性。
它的目标不是简单告诉 Agent：
“写一个 SKILL.md。”
而是围绕：
Skill 是否稳定？
Skill 是否容易误触发？
Skill 是否应该拆分？
哪些内容应该放在 SKILL.md？
哪些内容应该放到 references？
如何降低 Context Load？
进行约束。
项目作者将 Skill 的核心目标概括为：
从随机性的模型系统中尽可能获得确定性。
也就是说：
不是要求：
每次输出完全一样
而是要求：
每次都遵循可靠的过程
这实际上是非常重要的思想。
因为 Agent 本身是概率系统。
我们很难保证：
同一个任务
→
100% 产生完全一样的结果
但可以通过 Skill 约束：
触发条件
↓
执行步骤
↓
判断规则
↓
输出格式
让：
任务输入
→
执行过程
更加稳定。
writing-great-skills 还专门强调 Cognitive Load 和 Context Load，说明 Skill 的设计目标并不是「写得越详细越好」，而是让 Agent 在真正执行任务时获得足够而且相关的指导。
这与 Agent Skills 官方规范建议将较大的参考资料拆到 references/，并保持核心 SKILL.md 精简，是完全一致的。
8. 从这个项目可以学到什么？
研究 mattpocock/skills，最值得学习的不是某一个 Skill 的具体 Prompt，而是它的工程化思路。
第一，Skill 应该足够小
不要设计：
software-engineering
然后把：
开发
测试
Review
部署
数据库
Git
架构
全部塞进去。
更合理的是：
code-review
debugging
testing
to-spec
to-tickets
一个 Skill 负责一个相对完整、可识别的任务。
第二，Skill 应该可以组合
例如：
用户需求
↓
to-spec
↓
to-tickets
↓
implementation
↓
testing
↓
code-review
每个 Skill 负责自己的职责。
而不是：
super-engineering-skill
把所有事情都做掉。
第三，Skill 不应该把所有知识塞进一个文件
例如：
mysql-optimization/
├── SKILL.md
└── references/
├── mysql-8.md
├── indexes.md
├── transactions.md
└── performance.md
SKILL.md 负责：
任务流程
选择逻辑
核心原则
具体知识放：
references/
这样 Agent 只有在真正需要时才读取。
第四，Skill 需要明确“什么时候使用”
例如：
description: >
Review pull requests for correctness, security, performance,
and maintainability. Use when reviewing PRs, diffs, or requested
code changes.
而不是：
description: >
A useful code review skill.
因为 Agent 首先需要解决的是：
“这个 Skill 与当前任务有没有关系？”
官方规范也明确要求 description 同时描述 Skill 的用途和适用场景。
9. 如何设计一个生产级 Skill？
如果自己开始编写 Skill，可以使用下面这套结构：
skill-name/
├── SKILL.md
├── scripts/
├── references/
└── assets/
然后按照：
第一步：定义任务
↓
第二步：定义触发条件
↓
第三步：定义核心流程
↓
第四步：定义判断规则
↓
第五步：定义输出标准
↓
第六步：拆分参考资料
↓
第七步：加入必要脚本
↓
第八步：真实任务测试
例如设计一个：
mysql-optimization
可以是：
mysql-optimization/
├── SKILL.md
├── references/
│ ├── explain.md
│ ├── index.md
│ ├── lock.md
│ └── transaction.md
└── scripts/
└── explain-analyzer.php
SKILL.md 不应该成为一本《高性能 MySQL》。
它只需要告诉 Agent：
什么时候使用
↓
如何判断问题
↓
应该检查什么
↓
什么时候读取哪份参考资料
↓
应该如何验证
↓
最终如何输出
这才是一个好的 Skill。
10. Skill 的未来：从“Prompt 文件”走向 Agent 能力生态
现在回头看整个 Agent 技术栈：
AI Agent
│
┌─────────┼─────────┐
↓ ↓ ↓
Context Skill Memory
│
↓
Task Knowledge
│
┌─────────┼─────────┐
↓ ↓ ↓
Tool Workflow Rules
│
↓
MCP
│
↓
External Systems
可以发现：
MCP
解决：
“Agent 如何连接外部能力？”
Tool
解决：
“Agent 可以执行什么？”
Skill
解决：
“Agent 应该如何完成某类任务？”
而 Skill 的开放格式正在进一步解决：
Skill 如何打包？
Skill 如何发现？
Skill 如何加载？
Skill 如何跨 Agent 复用？
目前 Agent Skills 已经有公开规范，核心格式保持非常简单：
SKILL.md
+
scripts/
+
references/
+
assets/
这种设计的一个重要价值，就是把 Skill 变成普通的、可版本控制的文件，而不是绑定某一个厂商的内部数据库或专有 API。官方文档也明确将其定位为一种开放、可移植的 Agent 扩展格式。
这意味着未来我们可能会看到：
GitHub
↓
Skill Repository
↓
Agent Skill Registry
↓
Agent
就像今天：
GitHub
↓
npm / Composer / PyPI
↓
Application
一样。
但 Skill 和传统软件包又有一个根本区别：
Library：
提供代码
Skill：
提供“完成任务的方法”
因此，Skill 很可能成为 Agent 生态中的一种新型软件资产。
总结
Skill 不是给 Agent 增加一个按钮，而是把人的经验、流程和专业方法，封装成 Agent 可以发现、加载和复用的任务能力。
一个成熟的 Agent 系统最终不会只有：
Model
+
Tools
而更可能是：
Model
+
Context
+
Memory
+
Skills
+
Tools
+
MCP
+
Workflow
+
Runtime
+
Evaluation
其中：
Tool 决定 Agent 能做什么，Skill 决定 Agent 应该怎么做。
而真正优秀的 Skill，也不是越长越好、规则越多越好，而是能够在正确的任务中被正确触发，以尽可能少的 Context 提供足够明确的方法，并通过真实任务持续验证和迭代。
这也是 mattpocock/skills 这类项目值得研究的原因：它已经不再把 Skill 当成一段 Prompt，而是在尝试把 Skill 当成可组合、可维护、可版本化的工程资产。