觀點 | Core

編輯 | 云昭

出品 | 51CTO技術棧（微信號：blog51cto）

過去一年，很多人把 MCP（Model Context Protocol）當成“Agent 時代的 Linux 級標準”。

但只要你真用過，就會發現一個殘酷現實：

它在 demo 里光鮮亮麗，一上生產就開始碎裂。一旦你想把它規模化，立刻原形畢露。

很明顯的一個例子：

一個 GitHub MCP server 可以暴露九十多個工具——光這些工具的 JSON schema 和描述就超過五萬 token，模型還沒開始認真思考你的問題，工作記憶已經被塞滿。

所以，當 Anthropic 推出 Skills 時，我并沒有把它當成新功能。直到 Anthropic 推出 Skills。那一刻，我突然意識到：

他們其實是在悄悄糾偏 MCP，而不是擴展 MCP。

1.MCP 最大的問題：不是工具，而是“過載”

其實，MCP 的理念本身并沒有錯，而且也很簡潔。

你運行一個或多個 MCP server。

每個 server 暴露一組工具；每個工具有 schema；客戶端把這些定義加載進模型的上下文，讓模型決定要不要調用、怎么調用。

理論上，這能給模型一個干凈、類型化的外部接口。

但在實際中，這個“干凈的接口”更像消防水管。問題在于：

它把所有工具一次性全塞進模型大腦里。然后出現三個可怕的連鎖反應：

1）上下文被工具 schema 擠爆

對話、任務信息、工具描述搶空間。你越用，越覺得模型“越聊越糊”。

所有工具 schema 都會在一開始被塞進上下文。不管你只是想讓模型讀個文件、查個數據庫，還是總結一段文字，它都得先翻遍整套工具清單、參數說明、描述文檔，才能決定什么可能有用。

2）多步驟工具調用準確率指數級下降

單次工具調用，90% 準確率聽起來不錯？但如果你要連續調用 5 次，那就是 0.9? ≈ 59%。無數 Reddit 帖子非常直白：隨著調用鏈增長，工具調用準確率指數級下降。

更嚴重的是，（1）和（2）還會導致一個組合拳：

• 大量上下文被 schemas 白白占掉，而很多工具根本不會被用到；
• 對話歷史、全局工具定義、任務上下文互相擠占空間；
• 多步驟流程開始時很穩，越往后越發散，因為模型逐漸忘記早期約束。

3）模型認知負載過大，直接失常

這個的真實案例就更多了。任務簡單、工具正確、流程清晰，卻因為“認知負載爆炸”而失敗。模型一邊推理、一邊規劃、一邊選工具，同時還得把整套工具宇宙放在腦袋里。

一句話總結：

按照今天大多數人使用 MCP 的方式，它暴露的不是工具。它暴露的是“過量信息”。

2.Anthropic 沒去修 MCP

有意思的是，Anthropic沒有去對 MCP 本身采取什么大動作。

他們解決的是那個真正壞掉的模式：靜態、一次性暴露所有內容。

這也就是前不久讓業界大贊的 Skills，它完全反了過來。

一個 Skill 就是一個文件夾。里面有一個帶 YAML 頭部的 SKILL.md（包括名稱、描述、元數據），后面跟指令、參考資料，以及可選的其他文件鏈接。

關鍵來了：

啟動時，agent 不會讀取所有技能內容。

它只加載每個技能的最小 metadata，并放進 system prompt。

這讓 Claude 只需要知道“什么技能可能相關”，而不用提前支付加載全部內容的成本。

當用戶提出請求時，Claude 會經過一個逐層展開的流程：

• 先看技能的名字和描述。
• 覺得某個技能相關，再用文件系統工具打開 SKILL.md。
• 如果里面引用了其他文檔（如 forms.md、reference.md），按需讀取。
• 技能里有腳本，就用代碼執行環境跑腳本，而不是用生成式 token 去模擬邏輯。

圖片

也就是說，上下文是按需分層加載，而不是一次全塞。

你可以把整個流程理解為：

Skills 是前端的“檢索層”，MCP 是后端的“工具層”。

3.Skills = 檢索，MCP = 工具，

如果你做過RAG，會有一種熟悉感。在 RAG 里，你不會把整個知識庫塞進上下文，而是索引存放，按需檢索。

Skills 對工具和流程知識做的就是同樣的事：

• “索引”是技能的 metadata：名稱、描述、標簽
• “文檔”是 SKILL.md 以及相關文件
• “回答步驟”由技能里的指令、代碼，以及必要時的 MCP 調用組成

不用再把 MCP 的所有工具 schema 都扔給模型。你把它們綁定到具體工作流里：

• “PDF 填表”技能：知道該用哪個 server 和哪個腳本
• “營銷分析”技能：用 Python 處理 CSV，只在需要時調用工具
• “微博到新聞稿”技能：包含你寫作風格的示例和輔助代碼

模型不需要懂所有工具。

它只需要選對技能，技能負責 orchestrate（編排）后續步驟。

這樣一來，流程就變成了：

• 檢索相關技能
• 加載必要的指令和參考
• 用代碼執行確定性操作
• 最后再調 MCP 作為外部接口

Anthropic沒有選擇讓 Skills 去替代 MCP，而是讓 Skills 去馴服 MCP。

4.真正構建 Agent，如何選擇對的工具更重要

做 demo 時，MCP 看起來毫無問題。上下文夠大、任務短、工具少。但一旦進入以下場景：

多租戶系統、長對話、高風險流程（合規、金融、安全）、多 agent 網絡（工具套工具）

“裂縫”就會立刻出現：

• 模型亂選工具，自己覺得合理但開發者覺得離譜
• 參數看著符合 schema，但業務邏輯完全不對
• 工作流第一天正常，第七天漂移，因為歷史對話在和工具 schema 搶上下文

你可以打補丁：

• 縮短 schema
• 拆分 server
• 優化描述文案
• 加“監督 agent”糾偏

但這些都沒有解決核心問題：

模型在開始執行任務之前，就被迫理解整個工具生態。

Skills 把思維模型改了：

從 “模型必須理解所有工具”變成 “模型只需選對技能，由技能帶入需要的內容”。

這才像是一個正常的系統。也更接近我們培訓新同事的方式：不會把整套 wiki 扔給 TA，而是按任務逐步打開。

Skills 正是把這種模式產品化。

5.一個更健康的方向：檢索和編排

所以，現在看來，Anthropic 處理這件事的方式非常值得欣賞。

他們沒有發一篇《MCP 的現狀》，沒有宣稱 MCP 已死，也沒有指責用戶的瘋狂涌入而導致上下文爆炸。

他們只是悄悄推出一種機制，承認大型工具生態的真實復雜度，讓 agent 能在不被壓垮的情況下使用它。

Skills 是可組合的、可移植的、高效的，也能結合代碼執行提高可靠性。

更重要的是，它們承認了許多 agent 構建者的共同體驗：

未來的 agent 靠的不是“更多工具”，而是“更合理的工具關系”。

一個把檢索和編排放在首位的關系；

一個把上下文當成稀缺資源的關系；

一個 MCP 依然存在，但它不再壓在模型胸口喘不過氣的關系。

Anthropic 沒拋棄 MCP。他們讓 MCP 活了下來。

對于正在構建真實 agent 的人來說，這比任何協議更新都更重要。

從MCP 到 Skills，可以看出，未來的 Agent 不在于“工具越多越好”。而在于編排技術：

哪些技能被檢索到？哪些指令被加載？哪些腳本被執行？哪些工具被調用？什么時候被調用？

這是一個值得持續關注和投入的地方。

參考鏈接：??https://medium.com/@cdcore/mcp-is-broken-and-anthropic-just-admitted-it-7eeb8ee41933??

本文轉載自??51CTO技術棧??，作者：云昭