对比分析

Microsoft 把 Skill 放到 MCP 上之后，发现文档为什么还是 JSON？SEP-2640、skill://index.json 与 skills/list

截至 2026 年 9 月 22 日：Microsoft 9 月 16 日的演示把专家循环收进父 Agent 按需加载的 MCP Skill。说明书可以是 Markdown，发现合同仍是 JSON。SEP-2640 是 Accepted，不是 Final——skill://index.json 与 skills/list 同时在跑。

先给结论：Skill 搬上 MCP 之后，说明书可以是 Markdown，发现合同仍是 JSON。2026 年 9 月 16 日，Microsoft Agent Framework 的 Tommaso Stocchi 发了一篇对照：滑雪场顾问从「每个专家各跑一个模型」改成「父 Agent 按需加载 Skill，再直接调 MCP 工具」。服务还是分布式的，推理收回父上下文。本站 9 月 11 日的《MCP / Skills / Tools / Subagents》讲的是四层分工；这篇只补 11 日之后发生的事：发现文档长什么样、SEP-2640 卡在哪、以及你为什么还要先核一份 JSON。

这篇按 2026 年 9 月 22 日写。SEP-2640（Skills Extension）在 9 月 3 日被记为 Accepted，不是 Final。Microsoft 演示钉的是历史 Draft 的 skill://index.json。新草案改成 skills/list / skills/get。两套发现形状同时在跑，兼容性比「Skill 取代了 Agent」更值得先看。

9 月 16 日到底发了什么

Stocchi 的原文标题是 From Specialist Agents to Distributed Skills over MCP。滑雪场顾问原来通过 A2A 叫四个专家：天气、安全、滑雪教练、缆车排队。每个专家自带指令、工具和一轮模型循环。第二条路径把同一批领域服务改成 MCP Provider：各发一份描述、SKILL.md、带类型的 MCP 工具。顾问用 MAF 的 SkillsProvider 和 MCPSkillsSource 做发现与加载；SkillToolsMiddleware 在 load_skill 成功后，把该 Provider 的工具挂到下一轮模型。

网络研究仍是普通 Agent 工具。这是刻意的混合：该自主的继续自主，该变成能力的就变成 Skill。四个 MCP 端点在 /skillsmcp。资源面上通常只有：

skill://index.json
skill://<skill-name>/SKILL.md

skill:// 标识的是已经连上的 MCP 连接里的资源，不是主机名，也不能让 Skill 正文自己再开一条网。认证、传输、授权仍在基础设施和代码里，不在 Markdown 里。

不是 MCP 取代 A2A

原文把边界写得很干净。A2A 把任务交给另一个推理循环；Distributed Skill 把能力和操作交给当前推理循环。一张表就够：

关心的事Agent 当工具（A2A）Distributed Skill
父 Agent 发现什么一个可调用的专家 Agent一份可加载的能力
专家指令跑在哪专家自己的模型上下文父 Agent 的模型上下文
谁选领域操作专家模型父模型
远端执行什么专家循环 + 它的工具MCP 工具 + 背后的服务
仍然分布式的是Agent、服务、数据Skill Provider、服务、数据

Agent Card 的名字和描述变成发现条目；系统提示词变成 SKILL.md；工具参数变成 MCP 的 input / output Schema；业务服务留在工具处理函数后面。Card 上的端点、认证、传输能力不要写进 Skill 描述。这和本站 11 日那篇一致：Skills 是说明书，MCP 是插座，Tools 是契约。变的是说明书怎么被发现，不是三层并成一层。

发现合同：skill://index.json

编排器不需要每次请求都吃下全部说明书。它需要一份够用来路由的目录。演示里天气 Provider 的索引是：

{
  "$schema": "https://schemas.agentskills.io/discovery/0.2.0/schema.json",
  "skills": [
    {
      "name": "weather",
      "type": "skill-md",
      "description": "Weather intelligence agent providing real-time conditions, forecasts, and storm alerts for the ski resort",
      "url": "skill://weather/SKILL.md"
    }
  ]
}

这是 Agent Skills 的发现索引，再加 MCP 语义：url 是资源 URI，不是 https 主机。$schema 指向 schemas.agentskills.io 的 discovery 0.2.0。描述回答「何时用这份能力」；SKILL.md 回答「怎么用」——点名 weather_forecast 这类操作，区间、单位、禁止编造观测。操作本身的类型和范围，仍由 MCP tools/list 给出的 JSON Schema 说了算。

父 Agent 启动时通过 MCP 拉目录和 tools/list。模型第一眼只看到 Skill 摘要和加载助手，看不到全部操作 Schema。调用 load_skill("weather") 之后，中间件才把该组工具挂上。工具出现在上下文里，不等于已经执行。

SEP-2640：Accepted，不是 Final

SEP-2640 是 Extensions Track 上的 Skills 绑定：用 MCP Resources 提供 Agent Skills，扩展标识 io.modelcontextprotocol/skills。目录结构、YAML frontmatter、渐进披露，仍归 Agent Skills 规范；SEP 只定运输。

截至 Stocchi 文中 9 月 10 日的核对：9 月 3 日修订把状态写成 Accepted，发现面改成 skills/list 和 skills/get（可分页，条目带 uri、解析后的 frontmatter、带 sha256: digest 的资源清单）。对应 PR 当时仍未合并。演示钉的是更早的 Draft：读 skill://index.json，不实现那两个新方法。孵化仓库仍标 Experimental。

所以不要把二手报道里的「9 月 13 日 Final」写进生产清单。2026 年 9 月 22 日能确定的是：Accepted、未 Final、两套发现形状并存。把 Draft 索引当成「核心 MCP 必选项」，和原文自己的脚注相反。

工具合同仍是 JSON Schema

天气预测在演示里是带 Range(1, 24) 的 hours，并开了 UseStructuredContent。SDK 发出工具定义，处理函数先校验范围，再交给领域服务。SKILL.md 指导选哪把工具；它不代替参数 Schema，也不代替服务端校验。

权威操作定义来自 tools/list。执行走 tools/call。说明书走 resources/read。三跳都是 JSON-RPC。Skill 可以说「要分页」，但不能替你持久化 cursor；可以说「要审批」，但不能替你做授权。这和《Tool Calling 为什么依赖 JSON Schema》是同一层：散文指导选路，合同挡住非法参数。

三对测量：更快，不一定更省 token

同一句提示词（考虑天气和等待时间，我该从哪开始？），同一套 Aspire 应用，gpt41，三对新鲜对话。A2A 路径 6 / 6 / 7 次模型调用（专家可并行）；Skills 路径每次 3 次：先 load_skill，再直接打 MCP 操作，再出最终答复。客户端墙钟均值大约 6.35 秒对 15.48 秒。

token 没有变少。三轮合计，Skills 侧观察到约 13,533，A2A 约 11,134，多大约 22%。更少的模型跳数，不等于更小的累计上下文——说明书、分组 Schema、结果会在三次调用里叠上去。A2A 的缓存计数不完整，这不是账单对比，更不是对照实验。原文自己写了：这是三对示意，不证明同样正确或完整。

能带走的结构观察只有一句：少掉的是嵌套专家循环，不是 JSON 往返。发现索引、工具 Schema、结构化结果，跳数还在，只是从「每个专家各讲一遍」收成「父上下文里的几份合同」。

两套发现形状，主机对不上

2026 年 8–9 月已经能看见裂口。Microsoft.Agents.AI.Mcp 的 UseMcpSkills 仍读 skill://index.json；只实现 skills/list 的 Server，它会记「没有 index 资源」。按新草案只发索引、不声明扩展也不做 digest 的 Server，对新主机又是隐形。有的主机已经把基于索引的 Server 标成 legacy。

落地时不要赌「哪边会赢」。目录小，可以两套都提供：一份 Draft 索引给旧客户端，skills/list / skills/get 给声明了扩展的主机。索引缺失或为空，不得被主机当成「这个 Server 没有 Skill」——草案写过，大目录、动态生成的目录允许部分枚举。

你还要在本地核的三份 JSON

  1. 发现文档。skill://index.json 或 skills/list 的条目：name、type、description、url / uri。对照 $schema。多余键、空描述、把 https 主机写进 url，都是路由错误，不是文案问题。
  2. 工具 Schema。从 tools/list 拿出 inputSchema。必填写满，additionalProperties: false，枚举和范围收紧。Skill 正文点到的工具名，必须和清单里的名字一致。
  3. 结构化结果。演示开了 Structured Content。回给父模型的 output 仍应是合法 JSON，再按 Schema 验。不要把整行数据库或堆栈回灌回去。见《Agents API 之后为什么更需要 JSON》。

用本地 JSON 工具看发现文档

接到 MAF 或任何 Host 之前，先在浏览器里摊开三份文本：发现索引、一条 tools/list 里的 Schema、一次样本 tools/call 的 arguments。

  • JSON 校验 — 文法是否合法；有 Schema 就一起核字段、必填、多余键。
  • JSON 格式化 — 把压成一行的 index 展开，看 url 是不是真的 skill://。
  • JSON Diff — 对比 Draft 索引条目和 skills/list 条目，避免两套目录各说各话。

数据不离开浏览器。发现合同稳定了，再让父 Agent 去加载 SKILL.md。说明书可以改措辞；字段名和 URI 不应跟着周更。

常见问题 FAQ

SEP-2640 现在是不是已经 Final？

不是。9 月 3 日修订记为 Accepted。Microsoft 9 月 10 日核对时尚有 PR 未合并。演示用的是历史 Draft 的 skill://index.json。不要按「已经 Final」去砍旧客户端。

Distributed Skill 会取代 A2A 吗？

不会一刀切。需要独立生命周期、私有上下文或专用模型的，仍应是 Agent。只需要说明书加操作的，才迁成 Skill。原文把网络研究留作 Agent 工具，就是这个意思。

skill:// 是不是一个要解析的网址？

不是。它标识已配置 MCP 连接上的资源。Skill 正文不能用它改去连另一台主机。

有了 SKILL.md，还要 JSON Schema 吗？

要。Markdown 指导选工具和解释结果。参数类型、范围、必填仍由 tools/list 的 Schema 和你的二次校验负责。

只实现 skill://index.json 够不够？

对目前部分 Microsoft 客户端够。对新草案主机不够。目录小就两套都提供；只做一套，会在另一半主机上隐形。

Skills 路径更省钱吗？

演示里墙钟更快，观察到的 token 大约多 22%，且不是对照实验。先比路由和结构化结果对不对，再谈账单。

总结

9 月 16 日这篇演示，没有宣布「Agent 过时了」。它宣布的是：不需要嵌套推理的能力，可以只分发说明书和操作，发现面用 JSON。服务边界还在。少掉的是专家模型循环。你还握着的是发现索引、工具 Schema、结构化结果。

SEP-2640 仍是 Accepted。Draft 索引和 skills/list 暂时会一起活着。先在本地校验工具里把三份 JSON 看平，再接到 Host。11 日那篇分层没有作废；作废的是「Skill 只是本地文件夹」这一条默认。模型和 harness 会换版本；name、url、inputSchema 不应跟着一起松。