Agent Skills：让 Agent 从“会调用工具”走向“会按方法做事”

Tool Calling 解决了一个很直接的问题：模型可以决定“我要调用哪个工具”。

MCP 又把这个能力向前推了一步，它解决的是“Agent 怎么用统一方式连接外部工具和上下文”。

但当 Agent 真正进入复杂工作流之后，还会遇到另一个问题：

即使工具都接好了，Agent 也不一定知道“这件事应该怎么做”。

比如让一个 Agent 处理 PDF，不只是“会调用 PDF 工具”就够了。它还要知道什么时候应该提取文本，什么时候应该检查表格，什么时候应该保留版式，什么时候应该输出新的文件，以及完成之后要检查哪些内容。

这些“怎么做”的知识，就是 Skills 想解决的问题。

Skill 到底是什么

可以把 Skill 理解成一份给 Agent 使用的可复用工作说明书。

它不是模型本身的能力，也不是一个新的 API。Skill 更像是把一个任务的操作流程、规则、示例、脚本和参考资料打包起来，在 Agent 真正遇到对应任务时再加载。

OpenAI 目前把 Skill 定义为一种可重复使用、可共享的工作流，它可以包含指令、示例和代码；Agent Skills 开放规范则规定，一个 Skill 至少包含一个 SKILL.md 文件，也可以继续携带 scripts、references、assets 等资源。([OpenAI][1])

一个 Skill 的目录可能长这样：

pdf-processing/
├── SKILL.md
├── scripts/
│   └── extract.py
├── references/
│   └── formatting-guide.md
└── assets/
    └── template.docx

其中最核心的是 SKILL.md。

它负责告诉 Agent：

这个 Skill 是干什么的，什么时候应该使用，具体应该按照什么步骤执行，输出应该长什么样，以及完成之后应该检查哪些问题。

SKILL.md 做了什么

一个最简单的 SKILL.md 可以写成：

---
name: pdf-processing
description: 处理 PDF 文件，包括文本提取、表格检查和格式转换。用户要求处理 PDF 时使用。
---

处理 PDF 时：

1. 先检查文件结构。
2. 如果存在可读取文本，优先直接解析。
3. 如果文本缺失，再考虑图像或 OCR。
4. 修改完成后检查页数、字体和布局。
5. 输出最终文件前验证文件能正常打开。

前面的 YAML 部分是 Skill 的元数据。

Agent Skills 规范目前要求至少提供 name 和 description。其中 description 很重要，因为 Agent 会用它判断：当前用户的问题到底需不需要加载这个 Skill。 ([Agent Skills][2])

后面的 Markdown 则是真正的操作说明。

所以 Skill 并不是把一大段 Prompt 永久塞进 System Prompt，而是把任务知识独立保存，需要的时候再加载。

这一点非常关键。

Skills 的信息是怎么进入 Agent 的

Skills 真正有意思的地方，是它采用了一种类似“渐进式加载”的机制。

Agent 启动时，并不会把所有 Skill 的完整内容全部塞进 Context。

它通常先只知道：

Skill A：名字 + Description
Skill B：名字 + Description
Skill C：名字 + Description

当用户提出：

帮我处理一下这个 PDF

Agent 根据 description 判断 pdf-processing 可能有用。

然后才进一步读取：

pdf-processing/SKILL.md

如果 SKILL.md 又写着：

详细格式要求见 references/formatting-guide.md

Agent 在真正需要这些规则的时候，再继续读取对应文件。

这就是 Agent Skills 所强调的 Progressive Disclosure。官方规范把它大致分成三个阶段：首先只加载 Skill 的名称和描述；Skill 被激活后再读取完整 SKILL.md；脚本、参考资料和素材则继续按需加载。这样 Agent 可以拥有很多 Skill，而不需要一次性把所有内容塞进 Context。([Agent Skills][3])

从 Agent 信息流的角度看，大概是：

User Request
     ↓
Agent Runtime
     ↓
已知的 Skills Catalog
(name + description)
     ↓
判断是否匹配
     ↓
加载 SKILL.md
     ↓
Context Builder
     ↓
LLM
     ↓
按照 Skill 执行任务

如果任务需要脚本：

SKILL.md
   ↓
读取 scripts/
   ↓
Tool / Shell
   ↓
执行结果
   ↓
重新进入 Agent Loop

所以 Skill 本质上也是 Agent Context 的一个动态来源。

Skill 和 Prompt 有什么区别

最容易把 Skill 理解成“大号 Prompt”，但两者还是有明显差别。

普通 Prompt 往往属于一次性的上下文：

User
↓
Prompt
↓
LLM

而 Skill 是一个可以长期保存、按任务触发、带有资源结构的能力包。

可以理解成：

Prompt
= 这一次我要你怎么做

Skill
= 遇到这一类问题，你应该一直按照什么方法做

Skill 还可以附带代码、模板和参考文档，所以它承载的不只是自然语言指令。

这也是为什么它很适合团队使用。

比如公司可以做一个：

company-report/
├── SKILL.md
├── references/
│   └── brand-guide.md
└── assets/
    └── report-template.pptx

以后不同 Agent 做公司报告时，都按照同一套规范执行，而不需要每个人每次重新写 Prompt。

OpenAI 也把这种一致性和团队知识复用列为 Skills 的主要用途之一。([OpenAI][1])

Skill 和 Tool 有什么区别

这个区别更重要。

Tool 解决的是：

Agent 能做什么。

例如：

search_web()
send_email()
query_database()
create_pdf()

Skill 解决的是：

Agent 应该怎么利用这些能力完成一件完整的事情。

比如 Agent 有：

read_file
edit_file
run_python
create_pdf

这些都是 Tool。

而一个“制作财务报告”的 Skill 可能告诉 Agent：

先读取数据
→ 检查缺失值
→ 计算指标
→ 生成图表
→ 写分析
→ 制作 PDF
→ 检查最终文件

所以可以非常简单地记：

Tool 是动作能力，Skill 是做事方法。

两者通常一起使用。

Skill
↓
规定 Workflow
↓
Agent 决策
↓
Tool Calling
↓
执行具体动作

Skill 和 MCP 又是什么关系

MCP 解决的是连接问题。

比如一个 Agent 要访问 GitHub：

Agent
↓
MCP Client
↓
GitHub MCP Server
↓
Tools / Resources

MCP 告诉 Agent：

这里有哪些能力可以连接。

Skill 则可能告诉 Agent：

当你进行 Code Review 时，应该先读哪些文件、检查哪些问题、什么时候运行测试、最后以什么格式给出结论。

所以：

MCP
= 能力怎么接进来

Tool Calling
= 模型怎么提出调用

Skill
= 面对一类任务应该怎么组织这些能力

三者不是竞争关系。

一个完整 Agent 完全可能是：

用户：
检查这个 PR

        ↓

Code Review Skill
告诉 Agent 应该怎么检查

        ↓

Agent Runner

        ↓

MCP
连接 GitHub

        ↓

Tool Calling
读取 PR / Diff / Tests

        ↓

Observation

        ↓

继续按照 Skill 完成 Review

这时 Skill 描述方法，MCP 提供连接，Tool 真正执行。

Skill 和 Workflow 有什么区别

这两个概念看起来更接近。

Workflow 通常强调的是运行时控制流。

比如：

Node A
↓
Node B
├→ Node C
└→ Node D

系统明确知道当前 State、下一步 Transition、失败后去哪里。

Skill 更接近程序性知识。

它告诉 Agent：

处理这类任务时，通常应该按照这些规则和步骤做。

但这些步骤未必被写成一个严格状态机。

例如：

如果文档包含表格，优先检查表格。
如果只有扫描图片，再使用 OCR。
如果用户要求保持格式，不要重新排版。

这些更像操作规范，而不是固定 DAG。

因此可以这样理解：

Workflow 是运行时的控制结构，Skill 是 Agent 的方法知识。

当然，Skill 完全可以要求 Agent 去执行一个 Workflow。

为什么 Skills 对 Coding Agent 很重要

Coding Agent 是 Skills 最容易体现价值的地方之一。

代码工具其实已经很丰富了：

Read
Write
Edit
Bash
Git
Browser
Test Runner

但“有这些 Tool”不代表 Agent 就知道团队怎么开发。

比如一个团队可能规定：

修改 API 前必须先读 schema
数据库迁移必须同时写 rollback
提交前必须跑 lint + unit test
前端组件必须复用 design system
PR 描述必须包含测试结果

如果每次都在 Prompt 里重新告诉 Codex，非常麻烦。

把它写成 Skill：

backend-change/
├── SKILL.md
├── references/
│   └── architecture.md
└── scripts/
    └── validate.sh

之后 Agent 遇到对应任务，就可以自动加载这些工程规则。

OpenAI 目前也明确把 Skills 用在 Codex 中，用于把指令、资源和脚本打包成可复用工作流，并让 Codex 根据任务自动选择相关 Skill。([OpenAI][4])

这意味着 Coding Agent 的能力开始从：

“模型会不会写代码”

逐渐变成：

“Agent 是否掌握这个项目正确的开发方式”。

这两者差别非常大。

Skills 为什么不应该无限变大

既然 Skill 能放各种资料，一个很自然的想法就是：

那我直接把所有公司规范都写进一个 SKILL.md 不就行了？

实际并不合适。

因为 Skill 一旦被激活，它的内容还是要进入模型 Context。

Skill 太大会带来两个问题。

一个是 Token 成本。

另一个是无关信息会干扰当前任务。

Agent Skills 规范因此建议把核心 SKILL.md 保持相对精简，把详细资料拆到 references、scripts 和 assets 里，再根据需要继续加载。([Agent Skills][2])

这和 RAG、Memory 的设计思想其实很像：

不是把所有知识都给模型，而是在正确的时间提供当前需要的信息。

Skills 其实也是 Context Engineering

从更底层来看，Skills 并没有改变 LLM 的基本工作方式。

模型还是：

Context
↓
LLM
↓
Output

Skills 做的事情，是改变 Context 的构造方式。

没有 Skills 时：

System Prompt
+ User Message
+ Tool Schema
+ History

有 Skills 后：

System Prompt
+ User Message
+ Relevant Skill
+ Tool Schema
+ State
+ History
+ Relevant Resources

因此 Skills 可以被放进更大的 Agent Context Engineering 体系中理解。

它和 RAG、Memory 的区别主要在于来源。

RAG
→ 找“和问题相关的知识”

Memory
→ 找“过去需要重新记起的信息”

Skill
→ 找“完成这类任务的方法”

Tool
→ 提供“可以执行的动作”

Agent Runtime 最终负责把这些内容组合成这一轮模型真正需要看到的 Context。

一个完整的 Agent 信息流

把这些概念放到一起，一个更加完整的 Agent Runtime 可能是：

User Request
      ↓
Runner
      ↓
识别相关 Skill
      ↓
加载 SKILL.md
      ↓
读取 State
      ↓
检索 Memory / RAG
      ↓
Context Builder
      ↓
组装 Messages + Tools
      ↓
LLM
      ↓
Tool Call
      ↓
Tool / MCP
      ↓
Observation
      ↓
更新 State
      ↓
重新构造 Context
      ↓
LLM
      ↓
Final Answer

这时候就能看出来：

Skill 并不是一个孤立的新概念。

它实际上处在 Agent 的信息流转层。

模型负责推理和选择动作，Tool 提供行动能力，MCP 提供连接协议，State 保存事实，RAG 和 Memory 提供动态知识，而 Skill 提供的是程序性知识——告诉 Agent 一件事应该按照什么方式完成。

最后

Tool Calling 让 Agent 从“只会说”变成“能够做”。

MCP 让这些能力更容易被标准化连接。

Skills 又解决了下一层问题：

当 Agent 已经有很多工具之后，怎么让它稳定地知道这些工具应该怎么用。

所以我更愿意把 Skill 理解成 Agent 的“操作经验”。

它没有给模型增加新的参数，也没有真正训练模型，但通过一套可以按需加载、版本管理、共享和复用的工作说明，让同一个模型在具体任务上表现得更像一个真正熟悉流程的人。

从这个角度看，未来 Agent 系统里最重要的资产，可能不只有模型、Prompt 和 Tool。

还有大量真正沉淀业务经验的 SKILL.md。

[1]: https://openai.com/academy/skills/?utmsource=chatgpt.com "Using skills | OpenAI" [2]: https://agentskills.io/specification?utmsource=chatgpt.com "Specification - Agent Skills" [3]: https://agentskills.io/home?utmsource=chatgpt.com "Agent Skills Overview - Agent Skills" [4]: https://openai.com/index/introducing-the-codex-app/?utmsource=chatgpt.com "Introducing the Codex app | OpenAI"