Agent Skill 从使用到原理：大模型时代的「说明书系统」

2025 年末，Anthropic 在自家产品里低调上线了一套叫 Agent Skill 的机制。刚开始官方定位很克制，只是说「用于提升特定任务表现」。但很快，大家发现这套东西太顺手了：Cloud Code、VS Code 插件、各类智能体框架都开始跟进。到了 12 月，这套机制被正式发布为开放标准，可以跨平台、跨产品复用。

很多人一看到「Agent」「Skill」这两个词，就本能紧张：

这是不是又一个新名词？和 MCP 有什么区别？是不是要重学一套东西？

这篇文章不搞玄学，只从一个问题出发：

Agent Skill 解决了什么真实痛点，它到底是怎么工作的？

一、Agent Skill 到底是什么？

先抛开所有文档、协议，用一句话解释：

Agent Skill 本质上是「大模型随时可以翻阅的一份说明书」。

你可以把它理解成「给大模型写的 SOP（标准操作流程）」：

• 做客服时，说明书里写清楚：
• 遇到投诉先安抚情绪
• 不允许随意承诺赔偿
• 做会议总结时，说明书里写清楚：
• 必须输出参会人员、议题、结论
• 最好给出一个标准示例输入输出

以前你每次对话都要贴一大段要求。

现在只要把这些要求写进一个 Skill 里，大模型在需要的时候自己会去翻这份说明书。

当然，「说明书」只是最直观的比喻。真正的 Agent Skill 能做的远不止固定格式输出：它还能按需读额外文件（reference），还能跑脚本（script），把一整套小工作流封装进去。

从实现上看，一个最小可用的 Agent Skill，大致长这样：

meeting-summarizer/

└── skill.md

其中：

• meeting-summarizer 是 Skill 的名字（对应文件夹名）
• skill.md 里写明：
• 这是谁（name）
• 能干什么（description）
• 应该按什么规则干（instructions）

就这么简单。

二、用一个会议总结例子，走一遍完整流程

我们还是用官方常见的例子：会议总结助手。

1. 创建一个 Skill

在 Cloud Code（或类似支持 Agent Skill 的开发工具）里，默认会约定 Skill 所在的目录，比如：

~/.config/cloud/skills/

你只需要：

1. 在这个目录下新建一个文件夹，比如 meeting-summarizer
2. 在文件夹里创建 skill.md
3. 写上类似下面的内容（伪代码示意）：

---

name: meeting-summarizer

description: "用于对会议录音文本进行结构化总结"

---



你是一个会议总结助手，需要完成以下工作：



1. 输出参会人员列表

2. 输出本次会议的核心议题

3. 输出每个议题对应的决定和后续动作



【示例】



输入：

<这里是一段会议记录示例>



输出：

参会人员：

- A（职位）

- B（职位）



议题：

1. ……

上面这段有两部分：

• 顶部 --- 包起来的是 元数据（metadata）
• name：Skill 名称，必须和文件夹名一致
• description：一句话说明这个 Skill 用来干什么
• 下面全部是 指令（instructions）
• 写给大模型看的具体规则
• 可以包含列表、示例、注意事项等

2. 在编辑器里使用

写好 Skill 后，打开 Cloud Code，随便找一个目录，问一句：

你有哪些 Agent Skill？

工具会把本地扫描到的 Skill 列出来，比如：

• meeting-summarizer：用于对会议录音进行结构化总结

接着你输入一个真实任务：

总结以下会议内容：

……（粘贴会议记录文本）

Cloud Code 并不会直接让模型瞎编，而是先问你一句：

检测到有一个名为「meeting-summarizer」的 Agent Skill，可以用于当前请求，是否使用？

你点「是」，工具才会把 meeting-summarizer/skill.md 的全文交给大模型。

几秒之后，你就会看到一份结构清晰的会议纪要：参会人员、议题、决定都在。

表面上看，这只是一个「模板化任务」。

但真正有价值的，是背后那一套 按需加载 + 渐进式披露 机制。

三、Agent Skill 的内部机制：三层渐进式披露

从「模型能看到什么」的角度，Agent Skill 大致分成三层：

1. 元数据层：Skill 目录
2. 指令层：Skill 说明书
3. 资源层：Reference 文件和脚本

1. 第一层：元数据层（Skill 目录）

在每次对话开始时，编辑器会把所有本地 Skill 的「目录信息」发给模型：

• Skill 名称（name）
• 简要描述（description）

哪怕你本地有十几个 Skill，这一层的文本也很短。

模型就像在翻一个「功能清单」，知道有哪些可用能力，但暂时看不到具体细则。

这层信息是常驻的，不会被上下文裁剪掉，也是模型判断「该不该用某个 Skill」的关键依据。

2. 第二层：指令层（skill.md 正文）

当模型拿到用户请求 + 所有 Skill 的元数据后，会做一件事情：

判断当前任务是否适合用某个 Skill 来解决。

如果判定「会议总结」可以用 meeting-summarizer 这个 Skill，它就会让编辑器加载该 Skill 的 skill.md 正文。

这时，skill.md 的指令内容才第一次进入模型上下文。

其它 Skill 依然只有「目录信息」，正文不会被加载。

这一层就是典型的 按需加载：

• 节省 Token
• 避免无关 Skill 的规则干扰当前任务
• 让 Skill 可以写得比较详细，而不必担心每次都全量注入上下文

3. 第三层：资源层（Reference 和 Script）

只靠一份 skill.md，有时候还不够。

比如你希望会议总结助手：

• 一旦涉及费用，就自动判断是否符合公司财务制度
• 一旦提到合同条款，就提示可能涉及的法律风险

显然，这些规则要依赖另外的文档（比如《财务报销手册》《合同审查指引》），不可能全塞进 skill.md 里。

Agent Skill 的做法是引入第三层资源：

• Reference：可读资源文件（如 财务手册.md）
• Script：可执行脚本（如 uploader.py）

两者的处理逻辑不一样：

• Reference：
• 被「读」进上下文
• 内容会占用 Token
• 通常是按条件触发，比如：
• 只有当会议内容出现「预算」「报销」「合同」等关键词时才读取
• Script：
• 被「执行」，而不是被读
• 脚本内容本身不会进入模型上下文
• 模型只看到「执行结果」

举个组合例子：

• 用户说：「总结会议，并帮我检查费用是否超标。」
• 模型根据 skill.md 发现：
• 需要用会议总结 Skill
• 且涉及「钱」，需要加载《财务手册》这个 Reference
• 编辑器按模型请求：
• 把 财务手册.md 注入上下文
• 再让模型生成总结和合规提示

如果用户只是在做一次纯技术复盘会，不提钱，也不提合同，那这一整套 Reference 都不会被加载，完全不占用 Token。

这就是 Agent Skill 真正有意思的地方：在按需加载的基础上，再做一层更细粒度的按需加载。

四、Script：让 Skill 不止能「看书」，还能「动手」

光读文件并不够自动化，很多时候我们希望 Skill 能直接动手做事。

例如：

会议总结完之后，你希望它自动上传到某个内部系统。

这时可以给 Skill 加一个脚本：

meeting-summarizer/

├── skill.md

└── uploader.py

脚本内容可能是：

• 把总结内容写入一个本地文件
• 通过 HTTP 请求发到某个 API
• 或者上传到一个云盘目录

在 skill.md 里只要写清楚一条规则，大致像这样：

如果用户提到「上传」「同步到服务器」等词语，请执行 uploader.py，把本次生成的总结发送到服务器。

当用户发出请求「总结会议，并上传到服务器」，流程就会变成：

1. 模型选择 meeting-summarizer Skill
2. 编辑器加载 skill.md，模型根据说明先生成总结文本
3. 模型请求执行 uploader.py
4. 编辑器在本地或指定环境中运行脚本
5. 把脚本的执行结果（成功/失败、返回信息）再发回模型
6. 模型整理最终回应给用户：

• 一方面是总结内容
• 另一方面是上传状态说明

这里有一个关键细节：

默认情况下，Agent Skill 不会把 uploader.py 的源码读进上下文，只执行它。

这意味着：

• 脚本再复杂，也不会额外占用模型 Token
• Skill 可以承载比较重的业务逻辑，而不拖慢对话

只有一种情况会例外：

你在 skill.md 里没有把脚本的用法说清楚，模型搞不明白如何调用时，工具可能会把脚本内容给模型看，让它「反向理解」调用方法。

因此写 Skill 的时候，越明确越好。

五、Agent Skill 和 MCP：谁干什么，什么时候用哪个？

看完上面这套设计，很多人会有一种既视感：

这不就是「另一种连接外部世界的方法」吗？那和 MCP 到底什么关系？

先用一句官方给过的观点做个总结：

MCP 更侧重「给模型提供外部数据和能力」，

Agent Skill 更侧重「教模型如何处理任务和这些数据」。

稍微展开一点：

1. MCP 的角色

• MCP 是一个独立运行的服务程序
• 定义了完整的协议，让 Agent 可以通过统一方式调用各种外部资源：
• 数据库
• 内网系统
• 搜索引擎
• 第三方 API

它更像是「给 AI 接 USB 扩展坞」：

• 谁实现了 MCP Server，谁就能把自己的能力挂到这套扩展坞上
• 各种 Agent 和编辑器复用这一套协议，互通性很强
• 支持较严肃的权限、审计、安全控制

2. Agent Skill 的角色

Agent Skill 本质上是一份「说明书 + 工作流」，它更偏向：

• 把高频任务流程提取出来
• 用自然语言 + 少量代码，封装成一个可复用的技能包
• 依托编辑器 / Host 已有的代码执行和文件访问能力来完成工作

它适合的场景通常是：

• 单机或本地环境
• 轻量自动化流程
• 对外部系统要求不复杂
• 更关注「如何做」和「做成什么样」

3. 能不能只用 Agent Skill，不要 MCP？

从纯功能上讲：可以。

你完全可以在一个 Skill 的脚本里：

• 直连数据库
• 调用 REST API
• 操作本地文件系统

但从工程角度看，这是典型的「能这么干，但不建议」：

• MCP 更适合做「跨系统、跨团队复用的底层能力」
• Agent Skill 更适合作为「贴近业务的流程、模版、策略层」

在很多实际项目里，更合理的做法是：

用 MCP 暴露核心业务能力，再用 Agent Skill 封装具体任务流程，两者配合使用。

使用算力可以在 晨涧云AI算力平台 直接租用云端 GPU 服务器。

六、写在最后：什么时候你真的需要 Agent Skill？

如果你只是在和模型聊天，偶尔让它写写小脚本、改改文案，其实没必要一上来就研究 Agent Skill。

但一旦你遇到这些情况，就可以考虑：

• 你发现自己在不同项目里，反复对 AI 说同一套规则
• 你已经有一整套固定的「工作流」，但每次都要手动 copy 要求
• 你希望某些任务有长期、一致的风格和结构（例如代码 Review 模板、会议纪要格式、日报规范）
• 你希望大模型能「自动记得」某些规范，而不是每次你来提醒

这个时候，把它们抽出来写成 Agent Skill，通常是有效且划算的。

从产品形态上看，Agent Skill 并不是多一个「炫酷功能」，而是给大模型补上一个很朴素的能力：

不再把所有规则夹在一次次对话里，

而是给它一份可以随时翻阅、分层加载的说明书系统。

在大模型逐渐从「聊天玩具」走向「长期合作伙伴」的过程中，这一步并不耀眼，却非常关键。