从 MCP 到 Skills：AI Agent 的能力栈正在被重新划分

从 MCP 到 Skills：AI Agent 的能力栈正在被重新划分

【摘要】Agentic AI Foundation 现在手上有三张牌：MCP 管连外部工具和数据，AGENTS.md 管项目级指令，Agent Skills 管可复用的专业流程。三者不重叠，但很多人正在把它们混着用——最典型的症状是 AGENTS.md 里塞满了操作步骤。这篇讲清三者各自的定位，以及怎么判断一段内容该放哪儿。

目录

一、三张牌，三种生命周期
二、最常见的错误：把步骤塞进 AGENTS.md
三、判断标准：三个问题
四、渐进式披露：为什么"少写一点"比"写清楚"更重要
五、Skills 和 MCP 到底怎么配合
六、实战：一个内容该放哪儿的例子
七、还没定下来的部分

一、三张牌，三种生命周期

10 月 22 日，Anthropic 把 Agent Skills 捐给 Linux 基金会旗下的 Agentic AI Foundation（AAIF）。加上此前已经托管的 MCP 和 AGENTS.md，AAIF 手里现在有三张牌。

很多人知道这三个名字，但没分清它们管什么。分清了，配置才不乱。

一句话区分：

• MCP 是"连接" —— 打通能力边界
• AGENTS.md 是"上下文" —— 让 Agent 知道自己在哪
• Skills 是"程序" —— 让 Agent 知道怎么做

三者的关系不是替代，是分层。MCP 提供原子能力，AGENTS.md 提供项目约束，Skills 把多个原子能力编排成一件具体的事。

二、最常见的错误：把步骤塞进 AGENTS.md

有篇讲 Agent Skills 捐给基金会的文章里，有句话说得特别准：

很多人的 AGENTS.md 里塞满了操作步骤——那些内容应该搬进 skill，靠渐进式披露按需加载。

这个错误很常见，因为它看起来很合理：AGENTS.md 是给 Agent 看的说明文件，把"怎么部署"写进去，Agent 不是随时都能查到吗？

问题在于加载时机。

AGENTS.md 是无条件加载的——每个会话开始，Agent 都会读它。所以它的每一行都在为每一次对话付费，无论这次任务跟部署有没有关系。

而 Skills 是三层渐进披露：

第 1 层  启动时加载所有 skill 的 name + description      每个约 100 token
第 2 层  任务匹配上，才读入 SKILL.md 全文                 建议 < 5000 token
第 3 层  正文指到了，才读 scripts / references / assets    按需

同一个知识，放在 AGENTS.md 里是常驻成本，放在 skill 里是按需成本。

这在 skill 少的时候看不出来。等你有了 30 多个 skill，AGENTS.md 里那 200 行操作步骤，就会变成每次对话都要付的固定开销——哪怕你这次只是问了个语法问题。

三、判断标准：三个问题

我给自己的判断流程，三问：

第一问：这段内容的生命周期跟项目绑定吗？

跟项目绑定 → AGENTS.md。比如"这个仓库用 pnpm"、“测试命令是 pnpm test”、“src/lib 是公共库”。

不绑定 → Skills。比如"怎么排查 DNS 解析异常"、“怎么发一个规范的 GitHub Release”——这些在任何项目里都用得上。

第二问：这段内容需要 Agent 主动去读吗？

需要 → AGENTS.md。比如项目结构、命名约定。

不需要，只要"用到的时候能查到" → Skills。

第三问：这段内容是"知识"还是"连接"？

知识（怎么做、判断标准、清单）→ Skills。

连接（怎么访问某个外部系统）→ MCP。

三问下来，位置基本就定了。

四、渐进式披露：为什么"少写一点"比"写清楚"更重要

Skills 的设计里有个反直觉的点：它的价值不在于让你写更多，而在于让你少写、常驻。

因为 description 是唯一一段对所有 skill 常驻上下文的文字。

Agent 判断"这个任务要不要激活你"，只能靠它。你写得太短，它匹配不到；写得太长，每个 skill 都得多摊一份 token。

规范给的正面例子是这样的：

Extracts text and tables from PDF files, fills PDF forms, and merges multiple PDFs. Use when working with PDF documents or when the user mentions PDFs, forms, or document extraction.

反面例子是：

Helps with PDFs.

差别不在长度，在有没有触发词。“Use when…” 后面那些词——PDF、forms、document extraction——是 Agent 拿去和用户说的话做字面匹配的依据。

用户说"把这几个 PDF 的表格填了"，能匹配上。

这引出一个很实际的判断：description 是写给机器读的，不是写给人读的。

人看 description 会觉得"写得挺全"，但真正决定效果的是它有没有覆盖用户可能的说法。把用户会说的词都列进去，比把功能列全更有用。

我自己有个 skill 的 description 是 445 字符，是整个库里最长的。回头看，它把"这个 skill 干什么"和"什么条件下用"混着写了——这两件事，前者可以进正文，后者才该进 description。

一个可以传播的观点句：description 不是简介，是触发条件。它唯一的作用是让 Agent 知道"该不该叫你"，不是让人看懂你有多厉害。

五、Skills 和 MCP 到底怎么配合

举一个我实际在用的例子。

我有一个做网络审计的 skill，它要连到软路由上执行只读命令、读配置、查 DHCP 租约。这里面有两类东西：

MCP 部分（连接）：SSH 到设备的通道、执行命令的工具、读文件的能力。这些是"怎么访问"，写在 MCP server 里。

Skills 部分（程序）：先跑哪条命令、输出怎么解析、什么算异常、哪些操作绝对不能做、租约条目按什么字段去重。

同样的 MCP 工具，套不同的 skill，能干完全不同的事。

这就是分层的价值：MCP 是可复用的基础设施，Skills 是可复用的流程。一个新的 skill 建立在已有的 MCP 工具之上，不需要重新实现连接。

Google 的 Data Agent Kit 是这个模式的完整版：MCP 工具连数据服务，37 个开源 skills 教 Agent 怎么写 BigQuery SQL、怎么设计 Bigtable 行键。

其中有一个 skill 专门做"防误删"：描述开头就是 “STOP AND VERIFY”，列了一串不可逆操作——DROP TABLE、TRUNCATE、缺 WHERE 的 DELETE、gcloud projects delete、KMS 密钥销毁——要求先停下、解释影响、等明确同意。

这是流程知识，不是连接能力——所以它属于 skill。

国内平台是怎么分的

这套分层在国内的智能体平台上同样成立，而且因为要管理大量企业资产，边界划得更清楚。

以华为云智果（AgentArts）为例，它的资产广场把可复用资产分成了五类：应用模板、模型、MCP、插件、Skill。

对照上面的三层看，映射很清楚：

一个比较典型的组合是：知识库让 Agent 读懂企业的私有资料，MCP 让它调得动外部工具与业务系统，Skill 让它把重复任务按标准流程做完做对。

这三样加在一起才是"一个能上生产的智能体交付"。缺任何一样，落地的形态都不一样：只有 MCP，Agent 会调工具但不知道贵公司的规矩；只有 Skill，流程再规范也读不到它需要的数据。

托管侧还有一层关键设计：Agent 和 MCP Server 都能统一托管，支持自研和第三方。网关（Gateway）负责 API 转 MCP，能把存量 REST/OpenAPI 服务快速转换接入，减少改造成本。

也就是说，"MCP 怎么接"这件事，国内平台基本替你做完了——从 HTTP 转 MCP、鉴权配置、公私网管控，到工具的按需启停，都是平台能力而不是用户要自己拼的活。

一个可以传播的观点句：MCP 解决"能不能接上"，Skill 解决"接上之后按什么规矩做"。少任何一半，Agent 都停在半路。

六、实战：一个内容该放哪儿的例子

拿个具体的。我平时写这类文章，会有一份"公众号排版规范"。

错误的放法：全写进 AGENTS.md。结果是，我每次跟它讨论正则表达式、讨论服务器配置，这些跟排版毫无关系的对话，也都在为这几十行规范付费。

正确的放法：

注意 AGENTS.md 里只留了"一行指向"——不是把规范复制一份过去。

这就是渐进式披露在实战里的样子：AGENTS.md 负责"告诉 Agent 去哪儿找"，skill 负责"真的在那儿"。

七、还没定下来的部分

有几件事现在还不能确定，得说清楚：

第一，跨平台复用不等于跨平台对齐。 70 多个平台都"支持" Agent Skills，但三层渐进披露未必每家都做全了。格式统一了，能力没对齐。跨工具复用之前，还是得在目标平台上跑一遍。

第二，治理迁移还在进行中。 规范仓库的 README 目前仍写着"最初由 Anthropic 开发"，没提 AAIF。捐的是资产，实际治理要慢慢搬。

第三，路线图还是"提议"状态。 版本化发布、正式的提案流程、以及给写 skill 和装 skill 的人的安全指南——都还没落地。

第四，安全指南没出来之前，装第三方 skill 仍然等于把一堆脚本放进你的环境执行。 规范不提供沙箱。标准统一了格式，但没统一信任。

第五，AGENTS.md 和 Skills 的边界目前没有官方规范。 我上面给的三问是我自己总结的，不是规范里的。这块大概率会随着 AAIF 的提案流程慢慢明确。

最后回到那个最初的判断：很多人在 AGENTS.md 里写步骤，不是因为不懂 Skills，而是因为 Skills 刚出现不久，还没成为默认选项。 现在它成了中立基金会维护的标准，写步骤这个习惯可以开始改了。

你现在的项目指令是放在 AGENTS.md 里，还是已经拆成 Skills 了？ 评论区聊聊，我挺想知道大家实际是怎么分的。