前言 #
最近在用 Claude Code 的时候，我发现一个功能越用越顺手，就是 Agent Skill。一开始我只把它当成一个「提示词存档」，后来才发现它的设计比我想象的要精巧得多。这篇文章聊聊 Agent Skill 到底是什么、怎么用，以及底层的设计思路，顺便和 MCP 做个对比，帮你在实际场景中选对工具。
Agent Skill 是什么 #
最简单的理解：Agent Skill 就是一份大模型可以随时翻阅的说明文档。
举个例子，你想做一个智能客服，可以在 Skill 里面写清楚「遇到投诉先安抚情绪，不得随意承诺」；想做会议总结，可以规定「必须按参会人员、议题、决定这个格式输出」。这样一来不用每次对话都重复粘贴一长串要求，模型自己翻翻这份文档就知道该怎么干活了1。
当然，「说明文档」只是一个方便入门的理解。Skill 能做的事情远不止于此，后面会慢慢展开。
基础用法：创建一个会议总结助手 #
以 Claude Code 为例，使用 Skill 的第一步是创建它。
Claude Code 要求把 Skill 放在用户目录下的 .claude/skills/ 文件夹中。我们创建一个文件夹叫「会议总结助手」，文件夹名称就是 Skill 的名称。然后在里面新建一个 skill.md 文件。
这个文件分两部分：
头部是元数据（metadata），用三条横线包裹，包含 name 和 description 两个字段。name 必须和文件夹名字一致，description 则是向模型说明这个 Skill 是干什么的。
剩余部分是指令（instruction），用来详细描述模型需要遵循的规则。比如我规定了必须总结参会人员、议题和决定这三个方面，并且给了一个输入输出的示例，确保模型真的理解了要求。
创建完成之后，打开 Claude Code，问它「你有哪些 Skill」，它就会列出刚才创建的那个。然后输入一段会议录音文本，让它总结。Claude Code 会先识别到这个请求跟「会议总结助手」相关，请求使用这个 Skill，得到你的同意后读取 skill.md 的内容，最后按照规定格式输出总结。
整个过程非常直观。
流程拆解：Skill 的运行机制 #
基础用法看完了，不妨想想刚才到底发生了什么。
整个流程中有三个角色：用户、Claude Code（宿主程序）、以及背后的大模型。流程是这样的：
- 用户输入请求
- Claude Code 把用户请求连同所有 Skill 的名称和描述一起发给大模型
- 大模型发现用户请求跟「会议总结助手」匹配，把这个信息返回给 Claude Code
- Claude Code 去读取匹配到的 Skill 的
skill.md全文 - Claude Code 把用户请求和完整的
skill.md内容发给大模型 - 大模型按照 Skill 要求生成响应
这里有一个关键细节：第 2 步只发了名称和描述，第 4 步才读取全文。也就是说，哪怕你装了十几个 Skill，模型一开始看的也只是一份轻量级的目录。这引出了 Skill 的第一个核心机制：按需加载。
高级用法一：Reference（条件加载文件） #
按需加载已经挺省 Token 了，但还不够极致。
假设你的会议总结助手越来越高级：当会议涉及花钱时，能在总结里标注是否符合财务合规；涉及合同时，能提示法务风险。要实现这些，Skill 就需要知道相关的财务规定和法律条文。如果把所有这些内容都写进 skill.md，文件会变得非常臃肿，哪怕只是开个简单的技术复盘会，也要被迫加载一堆用不上的财务条款。
能不能做到更细粒度的按需加载？比如只有当会议内容真的聊到了钱，才把财务规定加载进来？
这就是 Reference 解决的问题。
我们创建一个 集团财务手册.md 文件，写明各种费用的报销标准，然后在 skill.md 里加一条规则：仅在提到钱、预算、采购、费用的时候触发，触发时读取这个文件并根据内容判断金额是否超标。
实际测试一下：如果会议内容涉及了预算，Claude Code 会先读取 skill.md，发现跟钱相关，再去加载财务手册，最终在总结中给出财务提醒。如果是个跟钱无关的技术复盘会，那个财务文件就只会安静地躺在硬盘上，不会占用哪怕一个 Token。
Reference 的核心特性：条件触发，只在需要的时候才加载，不需要就完全不碰。
高级用法二：Script（执行代码） #
查资料只是第一步，能直接跑代码把活干了，才是真正的自动化。这就用到了 Skill 的另一大能力：Script。
我们在文件夹里创建一个 upload.py 脚本用于上传文件，然后在 skill.md 里加一条规则：如果用户提到了「上传」「同步」「发送到服务器」，就必须运行这个脚本。
实际测试时，Claude Code 会正常生成会议总结，然后直接执行 upload.py 完成上传。这里有个值得注意的细节：Claude Code 申请执行脚本时，并没有去读取脚本内容。它只关心怎么跑和跑出来的结果，至于代码写了什么，它毫不在意。
这意味着哪怕你的脚本写了 1 万行复杂的业务逻辑，它消耗的模型上下文也几乎是零。
所以 Reference 和 Script 虽然都属于高级功能，但对模型上下文的影响截然不同：
- Reference 是读：把文件内容加载到上下文中，会消耗 Token
- Script 是跑：只执行不读取，几乎不占用上下文
渐进式披露：Skill 的三层架构 #
把上面的内容串起来，Skill 的设计其实是一个精密的渐进式披露结构，一共三层：
第一层：元数据层。 所有 Skill 的名称和描述，始终加载，相当于目录。模型每次回答前都会扫一遍，判断用户的问题是否跟某个 Skill 匹配。
第二层：指令层。 对应 skill.md 中除了元数据以外的部分。只有当模型发现用户问题跟某个 Skill 匹配时才加载，所以叫按需加载。
第三层：资源层。 包含 Reference 和 Script（官方规范中还有 Assets，但与 Reference 有重叠，暂不展开）。这一层只在模型根据指令层判断出需要具体资源时才会触发，是在按需加载的基础上又做了一次按需加载，可以叫「按需中的按需」。
三层之间层层递进，每一层的加载都建立在上层的判断之上，把 Token 消耗压到了最低。
Skill 和 Prompt Engineering 是什么关系 #
聊到这里，另一个经常被问到的问题自然就浮现出来了：Skill 和 Prompt Engineering 到底什么关系？感觉都在「教模型做事」，有啥区别？
我的理解是，它们解决的是不同层级的问题。
Prompt Engineering 解决的是「如何思考」。 它的核心工作是引导模型进行正确的理解和推理：明确角色、提供上下文、规范输出格式、减少幻觉。本质上它属于认知层，决定模型「要做什么」「怎么拆解问题」「是否需要外部能力」。但 Prompt 本身不负责执行任何实际操作。
Skill 解决的是「如何行动」。 它把模型的决策转化为可执行的行为：调用函数、跑脚本、读写文件。Skill 不参与思考，只负责拿到指令后干活并返回结果2。
打个不太严谨但好记的比方：Prompt Engineering 像是给新人写了一份入职手册，告诉他遇到什么情况该怎么判断；Skill 则是给他配了一套工具箱，判断完了直接上手操作。一个是脑，一个是手。
理解了这层关系，再看前面的三层架构就很清晰了：Skill 的指令层承载的是 Prompt Engineering 的成果，资源层承载的才是真正的执行能力。
Agent Skill 和 MCP 怎么选 #
聊完用法，很多人会有个感觉：Skill 和 MCP 是不是有点像？本质上都是让模型连接和操作外部世界。
Anthropic 官方有一句话把两者的关系说得很到位：
MCP connects Claude to data. Skills teach Claude what to do with that data.
MCP 给大模型供给数据，比如查询销售记录、读取物流状态；Skill 教会大模型如何处理数据，比如会议总结必须包含议题、汇报文档必须附上具体数据。
有人可能会问：Skill 里面也能写代码连接数据，干嘛不直接用 Skill 把两件事都干了？
确实能干，但不代表适合干。就像瑞士军刀也能切菜，但没人真拿它做饭。MCP 本质上是一个独立运行的服务程序，Skill 本质上是一段说明文档，两者在安全性、稳定性和适用场景上差别很大。Skill 更适合跑轻量脚本和处理简单逻辑，在复杂的数据连接方面不如 MCP 可靠3。
实际场景中，很多时候需要把两者结合起来用：MCP 负责连接数据源，Skill 负责定义处理规则，各司其职。