9 月 13 日，模型上下文协议（MCP）正式合并了 Skills 扩展（SEP-2640），给这套已经铺得很开的智能体工具协议补上了第三层能力。在此之前，MCP 只有两层：Tools 回答「智能体能做什么」，Resources 回答「智能体能访问什么」。缺的是第三样——怎么把工具和资源组合成一套完整、可复用、可分发的工作流。过去这部分知识散落在文档、README 和各种提示词文件里，没有一种可验证、可传输的标准格式。
新扩展只新增了三个协议方法，而且都建立在既有的 Resources 原语之上，没有发明新的传输机制。skills/list 一次性枚举服务端暴露的全部技能，每个条目带着 URI、完整元信息和一份含 SHA-256 摘要与体积的文件清单，一次调用就能建起本地注册表；skills/get 按 URI 取回单个技能，摘要对不上时可以刷新重取；resources/directory/read 则是可选的目录浏览，让技能指令可以引用某个文件夹里的模板。技能条目本身是一个结构化对象：URI、元信息（名称与描述）、以及资源清单（每个文件带摘要与体积），可选的组织前缀让命名空间保持清晰。
和工具、资源不同，技能的最大不同在于「可校验」。读取文件的动作本身不做激活，激活走宿主自己的技能加载路径——那里会校验摘要、检查授权、记录来源。每一个被读出的文件，都要对照清单里的摘要与体积核对一遍，对不上就拒绝。这意味着一份技能从作者手里发出去，到在别人的智能体里跑起来，中间多了一道完整性闸门：你拿到的不只是「一段能用的指令」，而是一个带指纹、可追责的包。
把时间线拉回上周，微软在 Agent Framework 1.19.0 里把技能档案限定为 ZIP 格式并强制摘要校验，思路如出一辙。一边是协议层（MCP SEP-2640）把技能的「长相」标准化，一边是框架层（微软 1.19）把技能的「完整性」管起来——协议与框架在同步补同一块短板：让可复用工作流既能分发，又不被悄悄篡改。对开发者来说，好处是技能可以在不同 MCP 兼容的智能体之间迁移；代价是以后发技能不能只扔个 SKILL.md，得把摘要与清单一并交付。
也要看到边界。SEP-2640 解决的是「技能包本身可信」，不解决「技能内容是否正确」——一个从源头就被投毒的技能，摘要再对也救不回来，源头治理仍靠生态与审核。目录浏览、摘要校验这些机制，落地到具体宿主还有大量实现细节；不同服务商对「授权」的定义若不统一，跨平台迁移仍会卡在信任链上。更现实的观察是：MCP 正从「连工具的协议」演成「连工作流的协议」，它在悄悄对标的不只是工具调用，而是 A2A 那种智能体间协作协议的领地。智能体能不能跑起来、跑得稳，正在从各家各管的私活，变成一层有标准的公共基础设施。
对做智能体产品的团队，这一版协议值得认真对待：现在就把技能做成「带摘要清单的可分发单元」，比将来被协议倒逼返工要省事。当技能可以像依赖包一样被安装、校验和追溯，智能体的工程化才算真正有了零件标准。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。