Microsoft 把 Skill 放到 MCP 上之後，發現文件為什麼還是 JSON？SEP-2640、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

發現檔案。skill://index.json 或 skills/list 的條目：name、type、description、url / uri。對照 $schema。多餘鍵、空描述、把 https 主機寫進 url，都是路由錯誤，不是文案問題。
工具 Schema。從 tools/list 拿出 inputSchema。必填寫滿，additionalProperties: false，列舉和範圍收緊。Skill 正文點到的工具名，必須和清單裡的名字一致。
結構化結果。演示開了 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 不應跟著一起松。