同一份操作手册两个 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 都算不上一个合格的数字员工。维度MCPAgent Skills定位工具层连接外部数据与服务知识层教 Agent 怎么做核心问题能做什么应该怎么做载体MCP Server Tool 定义SKILL.md 辅助文件复用方式跨客户端连接同一服务跨客户端加载同一技能包典型场景查数据库、读写文件、调 API代码审查、文档生成、数据处理流程两者目前的发展阶段也不同。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 多个 SkillAnthropic 自己内部也有几百个在活跃运行没有分层结构和统一格式这种规模的管理根本不可能实现。我用一个真实的对比来说明分层前后的差异。以前我让 Agent 做代码审查得在每次对话里重复粘贴审查规则一次粘贴遗漏一条审查标准就悄悄漂移。现在我把审查规则写成一个 SKILL.mdAgent 每次接到审查任务都会加载同一份标准审查风格稳定得像同一个人写的这是 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成本几乎为零收益却会随着技能库的积累指数增长。 同一份操作手册两个 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 都算不上一个合格的数字员工。维度MCPAgent Skills定位工具层连接外部数据与服务知识层教 Agent 怎么做核心问题能做什么应该怎么做载体MCP Server Tool 定义SKILL.md 辅助文件复用方式跨客户端连接同一服务跨客户端加载同一技能包典型场景查数据库、读写文件、调 API代码审查、文档生成、数据处理流程两者目前的发展阶段也不同。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 多个 SkillAnthropic 自己内部也有几百个在活跃运行没有分层结构和统一格式这种规模的管理根本不可能实现。我用一个真实的对比来说明分层前后的差异。以前我让 Agent 做代码审查得在每次对话里重复粘贴审查规则一次粘贴遗漏一条审查标准就悄悄漂移。现在我把审查规则写成一个 SKILL.mdAgent 每次接到审查任务都会加载同一份标准审查风格稳定得像同一个人写的这是 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成本几乎为零收益却会随着技能库的积累指数增长。 
