MCP 负责“能做什么”，Agent Skills 负责“应该怎么做”：2026 年 Agent 架构的分层革命

同一份操作手册，两个 Agent 给出了两种人生

上周我把同一份技能说明书分别喂给了两个不同的 Agent 客户端，一个按步骤把任务跑得干干净净，另一个把关键步骤跳过去直接开始瞎编。两个客户端用的是同一个模型，连温度参数都一样，唯一的区别就是其中一份说明书被写成了标准格式，另一份只是塞在对话里的普通文本。这个对比让我第一次真切感受到，Agent 时代的竞争已经从模型本身转移到了怎么给模型写操作手册。

过去一年我写过不少 prompt，也搭过一整套 MCP 服务，一直觉得让 AI 干活无非就是这两件事。但今年下半年圈子里突然流行起一个叫 Agent Skills 的概念，Anthropic 在 2025 年 10 月 16 日发布了 Claude Skills 功能，两个月后的 12 月 18 日又把它升级成了开放标准，随后 48 小时内微软和 OpenAI 就宣布跟进。一个标准能被两个竞争对手同时接纳，这在 AI 行业里并不多见，我意识到自己可能低估了这件事的分量。

很多人听到 Skills 的第一反应是，这不就是把 prompt 打包一下吗。我刚接触时也是这个想法，直到我认真读完规范才明白，它跟 prompt 根本是两个物种。prompt 是一次性的指令，写完就扔，换一个模型可能就失效。Skill 是可复用的能力资产，它有自己的文件结构、元数据、版本号，可以被 Agent 自主发现、按需加载、反复使用，甚至可以像 npm 包一样被分发和共享。

这篇文章我会从零拆解 Agent Skills 到底是什么，它和 MCP 的分工边界在哪里，2026 年 7 月 28 日那轮 MCP 协议大更新为什么让两者的关系彻底清晰，以及我踩过的坑和梳理出的实践建议。全程不写虚的，每个结论都有可验证的来源和可运行的示例。

先搞清楚一件事：MCP 和 Skills 到底谁替代谁

网上最流行的说法是 Skills 要取代 MCP，这个说法错得离谱。Anthropic 在 Skills 发布公告里说得非常直白，他们计划探索的是 Skills 如何补充 MCP Server，而不是取代它。要理解这句话，得先回到问题的起点：Agent 干活到底缺什么。

一个 Agent 要完成真实任务，需要两样东西。第一样是能力，也就是它能调用哪些工具、连接哪些系统，这解决的是能做什么的问题。第二样是方法，也就是面对一个具体任务时应该按什么步骤、什么标准、什么顺序去执行，这解决的是应该怎么做的问题。

MCP 解决的是第一样。它把数据库、文件系统、API、浏览器这些外部资源统一成标准接口，Agent 通过工具调用就能连上任何支持 MCP 的服务。我之前的文章里反复强调过，MCP 是 Agent 时代的 USB 接口，一根线通吃所有外设，这个比喻到今天依然成立。

Skills 解决的是第二样。它把某个领域的专业知识、操作流程和判断标准封装成结构化的能力包，让 Agent 在遇到这类任务时知道该按什么套路走。如果说 MCP 决定了一个 Agent 能摸到多大的世界，Skills 决定了它在那个世界里干得专不专业。

打个比方，MCP 相当于给员工开通了公司所有系统的账号权限，Skills 相当于员工桌上那本写满流程细节的操作手册。有权限没手册，员工只能乱试；有手册没权限，员工什么都干不了。两者是互补关系，缺了任何一个，Agent 都算不上一个合格的数字员工。

两者目前的发展阶段也不同。MCP 已经进入大规模生产落地期，从云厂商到开源社区都在围绕它建基础设施，而 Skills 还在从爆发式增长走向工程化成熟，大多数团队连技能库都还没建起来。我见过不少团队把 MCP Server 部署得井井有条，却对技能零管理，这恰恰说明知识层的标准化才刚刚开始，先动手的人能吃到第一波红利。

解剖一个真实的 SKILL.md，它比你想的简单

Agent Skills 规范的核心是一个叫 SKILL.md 的 Markdown 文件，它由两部分组成：开头的 YAML 元数据区，和正文的 Markdown 说明区。YAML 区告诉 Agent 这个技能叫什么、什么时候该用、被哪些平台支持，正文区才是真正的操作手册，里面写清楚任务目标、执行步骤、输入输出格式、质量标准和常见陷阱。

我自己写的一个文件检索技能，去掉注释后不到 60 行，结构大概是这样的，这是规范定义的完整格式，可以直接复制改写成你自己的技能：

--- name: repo-file-finder description: 在大型代码仓库里按语义定位文件。 当用户需要找某个功能、某个报错、某个配置对应的源码文件时使用。 不适用于已经明确给出文件路径的提问。 --- # 任务目标 根据用户描述的功能或报错，定位仓库中对应的源码文件，给出相对路径和一句话说明。 # 执行步骤 1. 先用 grep 搜索关键词，找到候选文件列表。 2. 对候选文件逐个读取开头 50 行，判断职责是否匹配。 3. 匹配结果按相关度排序，输出相对路径和职责说明。 4. 找不到匹配时，明确回答未找到，不编造路径。 # 输出格式 每行一个文件：相对路径 | 职责一句话 | 匹配关键词 # 质量标准 - 路径必须是仓库内真实存在的相对路径 - 未找到时必须如实说明，禁止猜测 - 每次最多输出 5 个候选，避免信息过载

注意 description 这一行的写法，它决定了 Agent 在什么情况下会主动加载这个技能，是全套规范里最讲究的字段。描述要写清楚触发条件和排除条件，前半句说什么时候该用，后半句说什么时候不该用，这样 Agent 才能准确判断。

模型消费这个文件的方式也很有意思，它不是一次性把整个 SKILL.md 塞进上下文，而是先读 description 决定要不要用，确认需要之后才完整加载正文。这个渐进式发现机制让技能库可以做得很大，Agent 却不会因为技能太多而拖慢响应，这一点跟 MCP 的 progressive discovery 思路完全同构。

你可能会问，这不就是系统提示词加上 Markdown 格式吗。区别在于 Skill 是独立于对话的资产，它有自己的目录结构，可以放辅助文件，比如模板、脚本、参考文档，正文里可以用相对路径引用它们。我把一份 3000 行的项目规范拆成了一个 40 行的 SKILL.md 加三个参考文档，模型表现反而比塞全文更好，因为它先掌握了执行框架，需要细节时再去翻参考。

为什么必须分层：200 行 prompt 的教训

我之前在一篇文章里讲过一件事，我给一个复杂任务写了将近 200 行的 system prompt，包含完整工作流、输出格式模板、边界条件处理，结果换了个模型版本直接崩了，输出格式错乱、中间步骤被跳过、在同一个循环里反复打转。那次翻车让我意识到，把方法论和模型绑在一起是最脆弱的设计。

Skills 的分层解决了这个问题的根源。模型只负责思考和推理，运行时提供文件系统和代码执行能力，MCP Server 负责连接外部世界，Skill 提供专业判断与执行方式。每一层都可以独立升级，模型换版本了，Skill 文件不用动；Skill 改进了，模型也不用动。

分层带来的第一个好处是可组合。一个技能可以引用另一个技能，复杂任务可以拆成多个简单技能的编排，而不是写一个无所不能的巨型文档。Anthropic 的规范里已经把依赖声明列进了未来方向，届时技能之间可以像软件包一样声明依赖关系。

分层带来的第二个好处是可测试。以前调 prompt 靠肉眼观察输出，现在 Skill 是可以被评估的单元，你可以对同一个技能跑一组固定用例，用评分规则衡量它的表现，改一行说明就能对比前后差异，这相当于给 Agent 的行为上了自动化测试。

分层带来的第三个好处是可治理。团队里几十个技能谁在用、哪个版本、质量如何，都可以集中管理。Uber 内部管着 500 多个 Skill，Anthropic 自己内部也有几百个在活跃运行，没有分层结构和统一格式，这种规模的管理根本不可能实现。

我用一个真实的对比来说明分层前后的差异。以前我让 Agent 做代码审查，得在每次对话里重复粘贴审查规则，一次粘贴遗漏一条，审查标准就悄悄漂移。现在我把审查规则写成一个 SKILL.md，Agent 每次接到审查任务都会加载同一份标准，审查风格稳定得像同一个人写的，这是 prompt 方案永远给不了的确定性。

还有一点经常被忽略，Skill 的加载是条件触发的，不用的时候完全不占上下文。我本地挂了二十多个技能，日常对话的 token 消耗跟没挂技能时基本一样，只有任务匹配到某个技能时，它才临时加载进来，干完活就退场。这种按需加载的机制，让技能库的规模不再是性能负担。

生态爆发得比 MCP 还快：数字不会说谎

Skills 生态的成长速度超出了几乎所有观察者的预期。到 2026 年年中，GitHub 上的 Skills 仓库已经超过8 万个，四大开源框架 agent-skills、superpowers、gstack、compound-engineering 加起来拿了30 万颗星，而 skills.sh 这个分发平台已经兼容 Claude Code、Cursor、GitHub Copilot、ChatGPT、Gemini CLI 等十几个主流 Agent 平台。

作为参照，MCP 到 2026 年年中做到了月 SDK 下载量9700 万次、官方 Registry 注册服务器接近一万个、GitHub 相关仓库超过1.5 万个。React 月下载量达到一亿花了三年，MCP 只花了 16 个月就到了 9700 万，而 Skills 的仓库数量用了更短的时间就追平了这个量级。

客户端支持的速度也快得反常。OpenAI 在标准发布两个月后就悄悄给 ChatGPT 和 Codex CLI 加了 Skill 支持，Cursor、GitHub Copilot、Goose、Windsurf 全部跟进，Spring AI 在 2026 年 1 月发布了集成模式。一个技能写一次，到处都能用，这种跨平台互操作性正是开放标准最核心的价值。

企业侧的采用同样在加速。2026 年的行业调研显示，41%的软件组织已经在生产环境使用 MCP，财富 500 强里28%部署了 MCP 服务器，78%的企业 AI 团队已有 MCP 项目上线，Gartner 预测 2026 年底75%的 API 网关厂商会原生支持 MCP。基础设施层被协议统一之后，知识层跟着爆发是顺理成章的事。

这里有一个值得注意的细节，Skills 的增长不是从零开始的。Anthropic 发布开放标准之前，Claude 生态里已经积累了大量的内部技能实践，开放标准等于把存量实践格式化了，所以标准一落地，仓库数量就出现了陡峭的增长曲线。先有实践后有标准，标准反过来放大实践，这是 MCP 和 Skills 共同的成长路径。

2026-07-28 MCP 大更新，把两者的关系彻底焊死了

今年 7 月 28 日，MCP 协议发布了史上最大的一次更新，我在之前的文章里拆解过无状态化和握手切断的部分，但那次更新里还有一个细节对 Skills 意义重大，就是协议正式引入了渐进式发现的机制。MCP Server 不再需要一次性把全部工具定义塞给客户端，而是支持客户端先搜到工具再按需加载详细定义。

这个机制跟 Skills 的加载方式是完全同构的，都是先看简介、再按需加载全文。Anthropic 已经把它作为一等公民模式放进了 Claude Code 和 API 的 Tool Search 工具里，MCP 网关如果采用同样的搜索优先思路，Agent 面对几百个工具时也不会被上下文撑爆。

更关键的是，这次更新明确回答了一个悬而未决的问题：工具服务器能不能自带操作手册。以前一个 MCP Server 只提供工具定义，使用方法要靠客户端自己维护文档，现在规范鼓励设计良好的 MCP Server 在工具定义旁边带上自己的 Skill 文档，让使用指南跟着服务器走，而不是散落在每个连接它的客户端里。

已经有网关实现验证了这条路径。MCP360 这类实现把一百多个工具暴露在 search_tools 和 execute_tool 两个接口后面，Agent 通过搜索发现工具、通过技能文档学习用法，工具层和知识层的边界在实践中变得清晰可辨。

所以现在可以把完整的架构图画出来了：模型在最底层负责思考和推理，MCP 在中间层负责连接外部世界，Skills 在最上层负责提供专业判断与执行方式，Agent 本身只是一个薄薄的执行载体。Anthropic 内部管这个叫薄 Agent 加可组合 Skills 加标准化工具连接的分层结构，跟软件工程从单体到微服务的演进路径如出一辙。

这套分层还解释了为什么 Skills 和 MCP 的争论会消失。争论的前提是两者在同一层竞争，一旦看清它们一个在工具层一个在知识层，替代关系就不成立了。MCP 负责能做什么，Skills 负责应该怎么做，Agent 负责把两者编排起来，各司其职。

这次更新里另外两个新能力对 Skills 同样重要，一个是原生流式支持，工具结果可以边生成边返回，一个是 Triggers 机制，服务器可以主动通知客户端新数据。对技能执行来说，这意味着进度反馈和事件驱动场景有了协议级的支撑，知识层和工具层的配合可以从简单的调用返回，深化到长任务中的实时协作，这个方向再过半年回头看会非常明显。

我踩过的坑：description 的 57 个字符陷阱

第一个坑是 description 写得太长。平台索引技能时只显示简介的开头部分，大概 57 个字符的窗口，我一开始把触发条件写在描述末尾，结果 Agent 从来没触发过那个技能，排查了半天才发现是索引截断导致它根本看不到触发条件。正确写法是把触发场景压进开头一句话，窗口之外的字符留给补充说明。

第二个坑是技能膨胀。我最早写的一个技能把六种相似任务塞进一个 SKILL.md，结果模型每次加载它都要读完所有分支，判断成本直线上升，偶尔还会用错分支。拆成六个独立技能之后，每个技能短小精悍，触发准确率反而更高了，这跟代码里单一职责原则是同一个道理。

第三个坑是版本管理缺失。技能改了几轮之后，我根本说不清当前行为对应哪个版本，直到有一次改动引入了回归，我才被迫给技能目录接上 git。现在每次改动都提交，技能文件跟代码一样有完整的变更历史，出问题可以直接回滚到上一版。

第四个坑是过度抽象。规范里鼓励技能可组合，我一度把通用步骤拆得过于细碎，结果一个简单任务要串联四五个技能，上下文往返开销反而更大。后来我遵循一个朴素原则，先写能完整跑通一个任务的单体技能，等出现第二个类似需求时再考虑抽取公共部分。

什么时候该写 Skill，什么时候不该写

我现在的判断标准是看任务的重复频率和稳定性。一个任务每周出现超过一次、执行步骤相对固定、结果可以验收，就值得写成 Skill。反过来说，一次性任务、步骤高度依赖临时上下文的任务、或者你自己都说不清楚好坏的模糊任务，写 Skill 只会增加维护负担。

还有一个反向场景值得警惕，就是什么都想写成 Skill 的冲动。写 Skill 本质上是把隐性知识显性化，这个过程需要投入时间，而且显性化之后还要持续维护。我见过有人把一句两句就能说清的小事也封装成技能，结果是技能库越来越臃肿，检索成本越来越高，收益却趋近于零。

判断一个 Skill 写得好不好，最有效的办法是给它跑固定用例。我每个技能都配了一组典型的输入输出对，改完技能先跑一遍用例，再放回真实任务里观察。这个习惯帮我挡住了至少三次回归，尤其是那些改动后表现看起来正常、实际上边界行为已经悄悄改变的情况。

给团队的建议：先管好入口，再谈规模

如果你在团队里推广 Skills，我的建议是先从入口治理开始。规定技能必须包含 name、description、清晰的步骤和验收标准，description 必须写明触发条件和排除条件，这个入口规范能挡住大部分质量低下的技能，比事后审查高效得多。

其次是建立共享仓库和审查流程。技能是团队资产，不是个人文件，放在共享仓库里，改动走评审，重要技能配负责人。Uber 管理五百多个技能靠的就是这套治理结构，规模上去了，没有治理的技能库会迅速退化成垃圾场。

安全上也要提前想清楚。Skill 的内容会被模型当作指令执行，一个被投毒的技能文件可能引导 Agent 执行危险操作，这跟 MCP Server 的供应链风险是同构的。从可信来源获取技能，安装前审查内容，运行时对敏感操作保持确认机制，这些底线不能省。

今晚就能做的三件事

第一件事，把你最近一个月重复做过三次以上的手工任务列出来，挑一个写成一版最小的 SKILL.md，用规范的标准格式，跑一遍真实任务验证它是否被正确加载和执行。你不用等平台支持，Claude Code 和 Cursor 现在就能直接用。

第二件事，把 description 的写法当成头等大事来打磨。写完先自己读一遍开头 57 个字符，问自己一句，如果我是个对项目一无所知的 Agent，看到这句话会不会知道什么时候该用这个技能。这个动作比优化正文更值钱。

第三件事，给你的技能目录初始化 git 仓库，哪怕只有你一个人用。版本历史是技能质量的保险丝，等技能数量超过十个，你会发现没有版本管理的技能库根本不敢改，而不敢改的技能库会慢慢腐烂。

我判断未来一年内，Skills 会像 MCP 一样从开发者的玩具变成生产环境的标配，区别只是 MCP 统一的是连接层，Skills 统一的是知识层。工具会换、模型会换、平台会换，但一套结构化的操作手册体系会沉淀下来，成为 Agent 时代最持久的资产。现在开始写第一个 SKILL.md，成本几乎为零，收益却会随着技能库的积累指数增长。