作者：段小草

年底这段时间确实太忙了，而且我承认自己严重低估了 Agent Skill 的重要性，其实这几个月零零散散看到了很多关于 Skill 的内容，却一直没有系统地形成自己的思考，这篇就当作我自己整理的学习资料和笔记吧，持续更新（可能有点混乱），也欢迎大家评论区批评指正。

写在前面：关于定义「行业标准」

眼下的 AI 领域，先发优势其实是个矛盾的概念，看上去，谁来得早就能定义规范，并在推广演进后成为事实意义上的行业标准，比如 OpenAI 就曾经定义了大模型 API 的格式，几乎所有的模型接口都是 OpenAI Compatible；但 AI 领域（特别是 Agent 领域）可供探索的空白也还有很多，只要有新的足够好用的规范出现，就会被社区认可。

回头想想，OpenAI 折腾了这么久，明明先做出了 Tool Use（Function call）[1] / Code Interpreter[2] / Data Analyst，早早喊出了 Agent 的口号，却连续在 Coding Agent、MCP、Skill 上落后于 Anthropic。OpenAI 虽然牵头搞了个 Agents.md[3]，也像是对 Claude.md[4] 的规范和泛化，谈不上多么原创。

三流企业做产品，二流企业做品牌，一流企业做标准。

没有人不想定义标准，比如谷歌也折腾了 A2A[5]（Agent2Agent，跨智能体通信协议）、AP2[6]（Agent Payments Protocol，智能体支付协议），UCP[7]（Universal Commerce Protocol，通用商业协议），但目前来看，也许是太过超前（Agent 还没发展到相互通信、打通交易支付流程那一步），所以影响力暂时还比不上简洁有效的 MCP 和 Skill（如果你把 Skill 看做是一种标准的话，在我来看，这当然是一种标准）。

所以现在很奇怪的是，Agent 领域目前的行业通行标准，几乎全部出自 Anthropic。

所以我一直觉得，Anthropic 这家公司有点邪性的，很难想象他们是怎么连续踩对好几个 Agent 的风口，持续领跑 Agent 的方向。

硬要分析原因的话，我觉得有两点：

一是 Claude 的编程能力一直都很强，也是 Anthropic 压箱底的看家本领，在出现通用 Agent 之前，Anthropic 押中了可以通过强化学习提升能力的模型 + 可验证、可落地（同时能让程序员真金白银付费）的编程场景。

二是 Anthropic 这帮人，确实在思考并推动 Agent 的落地，他们的解法也确实简洁有效，比如 Claude Code 充分利用了 bash 命令（相比之下 Codex 倾向于写 Python 脚本），比如从文件系统（环境）和文本文件（指令）出发去思考工具调用。（参见：Bash Is All Agent Need：Anthropic 重新定义智能体开发）

而且这两点是有机统一的。正是 Anthropic 足够相信 Claude 模型的编程能力，他们才敢相信给模型一个 bash 环境，让模型能读/写文件，就能几乎解决所有的问题。

Agent内部构成（远端 MCP Server）+Agent 运行的虚拟机环境

从这个信念出发，就有了方向，剩下的就是做两件事：训练更强的模型，同时思考如何构建有效的上下文工程，让模型自己通过 bash 和文件系统，完成各种任务。

Claude Code、MCP、Claude.md、Skill，都是在朝着这个方向走，而且目前来看，效果很好。其他家的 Agent，都只能模仿，MCP 和 Skill 俨然已经形成了事实上的行业标准。

现在介绍 Skill 的文章非常多，已经可用并分享出来的 Skill 也非常多。

不过我还是回归起点，尽可能从官方博客、文档、示例出发吧。

Anthropic 官方 Blog：Equipping agents for the real world with Agent Skills \ Anthropic（极其重要，每个字都要读，多读几遍，后面的笔记就不用看了）

Anthropic 官方 Skill 库：anthropics/skills: Public repository for Agent Skills

Anthropic Skill Cookbook：Introduction to Claude Skills

Anthropic Agent Skill 文档：Agent Skills - Claude Docs

Agent Skill（Specification）：Agent Skills

Simon Willison：Claude Skills are awesome, maybe a bigger deal than MCP

笔记：Skill 的渐进式披露上下文

MCP 的劣势：还没获取到有效的结果，工具描述先把 Context 占满了。

Skill 最大的改变就在于「渐进式披露」，通过控制本地文件的读取，只在需要时加载内容。

什么叫「渐进式披露」？

简单来说就是，一个刚入职的实习生，是不会一次性把公司所有的操作手册背到脑子里的。也许有很多个文件柜，每个文件也有自己的目录，目录指引到某篇具体的手册，手册里写明了最终的 SOP 和工具。遇到具体问题，实习生会一级一级地逐步展开必要的内容。

具体来说，Agent 最初只加载多个 Skills 的元数据（每个 Skill 占用几百 token）。

当 Agent 认为需要使用某个具体的 Skill，就会读取这个 Skill.md 说明（几千 token）：

Skill 里还可以无限嵌套下去，告诉 Agent，想要深入了解某个具体问题，还可以继续读取哪份文件：

如果 Agent 有必要操作某个工具的话，就会运行相应的预置代码脚本，这个脚本运行在本地电脑的环境里，运行过程不占用模型上下文，最终把运行结果返回给 Agent 即可。

笔记：Skill 的成功在于比 MCP 更简洁，更纯文本（Skill vs MCP）

Skill 可以很简单，简单到就是几句 Prompt；但 Skill 也可以很复杂，可以装下完整的代码工具库。但 Skill 从形式上看，始终很简洁，就是放在文件夹下的文本文件。

这也是 Skill 优于 MCP 的地方，MCP 虽好，还是复杂了一些，需要服务端、客户端，需要 bun、npx、unx，对于非程序员来说还是有门槛。

但 Skill 并不会替代 MCP，二者应该是共存的，甚至再想想， Skill 应该是可以调用 MCP 的？那反过来 MCP 可以调用 Skill 吗？理论上可以，但实际没有必要。

当然，如果单纯地理解为「工具调用」，肯定有很多种情况，Skill 和 MCP 都可以做，但从设计哲学上，应该可以进行区分并选择最佳实践。

Skill 是一个可复用的 Prompt + 能力、资源包，是尽可能本地的（当然也可以通过运行脚本执行一些远程请求）、模块化的（文件夹组织）、可发现的（list dir 即可）、可渐进加载（运行到哪一步就读取哪些文件）的指令、脚本和资源。

MCP 则始终是 C/S 架构，是为了让 Agent 有能力和外部数据、应用、服务进行通信，并把获取的结果添加到上下文中。MCP 可以是远程的，可以抽象掉更多下层的技术细节。

MCP 更像是 API，Agent 只关心提交什么「参数」、得到什么「结果」。

Skill 则是个代码/文件库，Agent 需要知道自己应该「如何」运行（读取）「哪个」文件。

纯文本，意味着「分享更简便」，也就更容易传播和使用，因为「安装」Skill，就是把一个文件夹+几个文件保存到指定的路径下而已。

（当然，也要注意 Skill 的安全问题，不要轻易信任未知来源的 Skill）

（也许，应该做一个代码审查的 Skill 来审查第三方 Skill 安全性？套娃了）

笔记：Skill 的核心理念，就是 Skill（Skill vs Workflow / MCP）

这句话像是废话，我自己写出来都觉得是废话，但没想出更好的表述方式。

Skill 和 Workflow、MCP 也许有重合，但并不一样，甚至很难说谁包含谁，谁的层级更高，取决于你自己的理解。

Skill 就是通过渐进式地添加上下文，教会 AI 掌握一项「技能」，理论上讲，Skill 的最小单位或者说原子化能力，就是「技能」，比如处理 PPT、Excel、PDF 的技能。

Workflow 是做一件事的流程，比如先怎么样后怎么样。举个例子，比如要把一篇博客转化为一份 PPT，那也许需要读取网页内容、提取信息、确定大纲、生成图片、制作 PPT；要把一个播客转化为一篇博客，需要下载音频、转录文本、生成内容。

MCP 则更像是工具，是把传统的一组 API 转化为 Agent 能调用的工具，让 Agent 通过提交参数、获取结果，来填充自己的 Context。

当然，你硬要过度设计的话，Skill 也可以是一个完整的 Workflow，取决于你定义的抽象。

比如，你可以把「下载音频」定义成一个 Skill，可以把「播客转博客」定义成一个 Skill。

也许很多人忽略了两点：

Skill 和 MCP 是共存的，不是非此即彼的，有时相互替代（二者选其一实现即可），有时互为补充（各有各的场景）。

Skill 和 Skill，MCP 和 MCP，Skill 和 MCP，都是可以组合使用的。

所以理论上，可以写出一些最小化的 Skill / MCP，再把它们组合成 Workflow 使用，或者写一个更高维的 Skill，让这个 Skill 去发现/调用低维的 Skill。

Skill 的理念就是「可复用」。但可复用有两种理解：

这件事（流程）会重复做，所以包装成一个 Skill。

这个技能可以在很多个场景下调用，所以包装成一个 Skill。

这两种理解应该说都没错，还是那句话，没有标准答案，取决于把业务抽象到哪一个层次。

目前我有个模糊的感觉，最佳实践也许是 Workflow -> Skill -> MCP，这样更清楚。

只不过 Claude Code 里现在没有什么 Workflow，所以层次也许是「教智能体端到端产出的工作流 Skill」->「教智能体干一件具体事情的技能 Skill」->「调用外部工具/数据的 MCP」。

当然这并不绝对，就像软件工程一样，抽象的过程，就是组合和隐藏的过程，就是要合理规划层级、设计接口，没有标准答案。

好像有点绕，不用纠结，用着用着就会有感觉。

哦对了，这里还漏了 Sub-Agent，概念/场景上似乎也有重合的部分，所以说，没什么绝对的最佳实践，能用起来就行。

笔记：Skill 的组合使用

所谓 Skill 的组合，也许只是抽象的层级问题，导致技能更偏向于原子化，还是更偏向于工作流。

不过，想象力也许在于，让模型自由地发现、组合 Skill，创造出预期设计之外的用途？

（待补充）

笔记：Skill 的稳定调用/触发问题

Skill 和 MCP 一样，依赖于模型通过上下文中的「技能描述」「工具描述」来自行选择是否调用、调用哪个。

所以 Skill 并没有解决 Agent 有时会忽略工具（不调用）或者选错工具的现象。

核心就在这个「decide」，模型根据理解，自己决定读取哪个文件、调用什么工具。

（待补充，初步查询到的解决方案：hook）

总之，回归基础认知：

模型就像是个刚毕业的本科大学生，来公司做实习生，它有一定的认知和理解能力，也已经掌握了一些内化的基础技能（bash 命令）。

Skill 就像是一沓技能手册（和工具），它会先读标题，根据需求选择某一本展开阅读，再根据了解到的详细说明，在自己电脑上亲自动手去完成某个工作。

MCP 就像是一个外部的服务窗口（比如信息查询窗口、采购审批窗口、食堂打饭窗口），实习生发出一个指定格式的请求，然后得到自己想要的结果，它不用关心窗口背后发生了什么。

Sub-Agent 则像是更下一层的外包工具人，可以交付某一类具体的任务。（前提是这个外包自己已经具备了相对完善的能力、Skill 和 MCP）

先写这么多，待续：

skill的这种做法，可以看做某种 Memory 的管理方式（类似的实现：NevaMind-AI/memU: Memory infrastructure for LLMs and AI agents）

一个 skill 不如 MCP 好用的例子：Notes on SKILL.md vs MCP - Tao of Mac

skill 虽然形式上很简单，就是一些文件。但关键在于「如何根据需要动态加载上下文」，什么时候、加载哪些内容，这些看似简单、实则精巧的工程化设计是点睛之笔。

Skill 为什么重要：Why OpenAI’s Move to Skills Matters If You’re Shipping AI Agents

Skills Are All You Need

斜杠命令、subagent、Skill 之间的区别、演化，界限正在模糊，Skill 有可能成为上下文管理的「超集」：Subagents, Commands and Skills Are Converging

参考（略）

·················END·················

分享

收藏

点赞

在看