大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



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

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

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

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

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

没有人不想定义标准，比如谷歌也折腾了 A2A （Agent2Agent，跨智能体通信协议）、AP2 （Agent Payments Protocol，智能体支付协议），UCP （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