Anthropic 最新博客：MCP 沒死，它又來了
整理版優先睇
MCP 絕地反擊：Anthropic 透過 Tool Search 與代碼編排，解決 Token 膨脹痛點並確立雲端 Agent 標準。
這篇文章針對 Anthropic 最新發布的博客《Building agents that reach production systems with MCP》進行了深度解讀。背景源於過去數月開發者社羣（如 Perplexity CTO、ScaleKit 等）對 MCP 協議的強烈質疑，認為其 Token 消耗過高、嚴重污染上下文，甚至預言 CLI 才是 Agent 的終局。作者透過對比自身過往觀點與 Anthropic 的最新回應，探討 MCP 如何在爭議中尋找生存空間。
文章的核心結論是：MCP 並未被棄用，而是找到了其「該待的地方」。Anthropic 承認了 CLI 在本地環境的優勢，但強調在雲端生產環境（如 Claude Managed Agents）中，MCP 仍是唯一的標準化接入層。透過引入 Tool Search 和程序化調用等新技術，MCP 正在大幅縮小與 CLI 的成本差距，並與 Skills 框架走向融合。
- 成本優化：引入 Tool Search 機制，讓 Agent 按需加載工具定義，將 Token 消耗降低 85% 以上，解決了以往「說明書比活兒長」的尷尬。
- 架構演進：推崇「代碼編排」模式（如 Cloudflare 案例），僅暴露 search 和 execute 兩個工具，讓 Agent 寫腳本處理數據，而非將原始數據塞回上下文。
- 場景劃分：明確本地開發環境適合 CLI + Skills，而雲端、移動端等無文件系統環境則是 MCP 的核心戰場。
- 生態融合：MCP 不再孤軍奮戰，而是與 Skills 配合，MCP 負責底層連接與認證，Skills 負責高層業務邏輯編排。
- 行動建議：開發者應將 MCP 服務器設計得像 CLI 一樣簡潔，避免細粒度 API 堆砌，優先考慮意圖導向的工具設計。
Anthropic 官方博客原文
Building agents that reach production systems with MCP
Cloudflare 代碼編排模式
僅暴露 search 和 execute 兩個工具，覆蓋 2500+ API 端點，將工具定義壓縮至 1K tokens。
從「棄子論」到「生存戰」：MCP 的信任危機
過去一個月，MCP 遭遇了嚴重的口碑滑鐵盧。ScaleKit 的測試顯示，使用 GitHub MCP 服務器的成本比直接用 CLI 高出 17 到 32 倍。Perplexity 的 CTO 甚至直言，內部正遠離 MCP，因為它佔用了超過 70% 的上下文窗口。
Anthropic 的反擊：Tool Search 與程序化調用
面對社羣的質疑，Anthropic 給出了技術解法。首先是 Tool Search，讓 Agent 先描述意圖，系統再動態匹配工具，這直接砍掉了 85% 的無效 Token 消耗。
「別讓模型當搬運工，讓它寫代碼。」
另一個關鍵是「程序化工具調用」。工具返回的結果不再直接丟回給模型，而是在沙箱裡進行過濾和聚合，只把最終結果返回。這讓 MCP 的 Token 消耗雖然仍高於 CLI，但已縮小到同一個數量級。
雲端 Agent 的標準化接入層
為什麼不乾脆全部改用 CLI？Anthropic 指出了一個現實：生產級 Agent 越來越多跑在雲端（Managed Agents）或手機 Web 端。這些環境沒有本地文件系統，無法執行 CLI 命令。
// 傳統模式：暴露 2500 個 API 端點 (Token 爆炸)
// 優化模式：僅暴露兩個核心工具
{
"tools": [
{ "name": "search_api", "description": "根據需求搜索相關 API 文檔" },
{ "name": "execute_script", "description": "在服務端沙箱執行編排代碼" }
]
}這種「代碼編排」模式證明瞭：好的 MCP 服務器應該借鑒 CLI 的哲學，保持接口壓扁、功能組合，而非簡單的 API 搬運。
未來圖景：MCP 與 Skills 的共生
最終，MCP 與 Skills 的關係被重新定義：MCP 負責「能力連接」（如連上數據庫、認證權限），而 Skills 負責「業務編排」（告訴 Agent 如何具體完成任務）。
Anthropic 最近出咗篇 Blog，標題叫《Building agents that reach production systems with MCP》，翻譯過嚟即係：《構建能觸達生產系統嘅 Agent：MCP 實踐指南》。
喺我舊年 11 月嘅文章《MCP 或者會變棄子》同埋上個月嘅文章《所有軟件，都會為 Agent 重寫》、《釘釘飛書集體棄用 MCP，CLI 先至係 Agent 嘅終局》入面，我一直喺度講緊一個觀點：
CLI + Skills 先至係 Agent 連接外部系統嘅正路，因為 MCP 又貴又慢仲好佔 Context（上下文）。
但係今日，MCP 嘅親生老竇 Anthropic 自己出嚟再一次幫 MCP 講嘢。
佢又唔係話「你哋錯咗」，佢係話：「你哋提出嗰啲問題，我哋有答案喇。」
01之前傾過啲咩
喺呢度補返個前情提要先。
過去一個幾月，社群對 MCP 嘅批評主要集中喺三件事上面。
ScaleKit 做咗一組嚴謹嘅 Benchmark，攞 GitHub 官方嘅 MCP Server 同 gh CLI 做對照，跑咗 75 輪實驗。
結果係 CLI 喺 Token 消耗上平咗 10 到 32 倍，按月計，每個月 1 萬次操作，CLI 大約 3.2 美金，MCP 大約 55.2 美金。足足有 17 倍嘅成本差距。
問題出喺 Schema 膨脹上面。
GitHub 嘅 MCP Server 帶咗 43 個工具定義，每次對話都要將呢 43 個工具嘅完整描述全部塞晒入 Context。你只係想查吓個 Repo 嘅語言，但模型要先讀完晒所有 43 個工具嘅說明書。單單一個工具嘅定義就佔咗 4,026 Tokens。
Perplexity 嘅 CTO Denis Yarats 亦都表態話：Perplexity 內部正喺度遠離 MCP，原因係 72% 嘅 Context Window（上下文窗口）俾 MCP 佔用咗。
龍蝦之父 Peter 亦都喺 Podcast 入面痛批 MCP：
“ MCP 預設會污染你嘅 Context（上下文），加上大部分 MCP 都做得唔好，總括嚟講唔係一個好有用嘅範式。
而釘釘同埋飛書都係不約而同咁避開 MCP，直接將產品「壓扁」做 CLI。喺三藩市街頭嘅隨機調查入面，CLI 攞到 17 票，而 MCP 淨係得 3 票。
當時我哋嘅結論係：MCP 唔會死，但佢會退返去佢應該待嘅地方。
而 CLI，將會成為 Agent 操作所有軟件嘅預設介面。接住落嚟，成個 SaaS 嘅 API surface，將會全部暴露成 CLI。
02Anthropic 嘅回應
而今日呢篇 Blog，就係 Anthropic 重新定義緊乜嘢係 MCP「應該待嘅地方」。
Blog 一開頭就擺咗個框架：Agent 連接外部系統有三條路，分別係直連 API、CLI 同埋 MCP，各有各嘅適用場景。
直連 API 適合簡單、一對一嘅場景。但如果你有 10 個 Agent 要接 10 個服務，咁就係 100 個唔同嘅整合方案，每個都要單獨搞認證同埋工具描述。呢個就係經典嘅 M×N 問題。
CLI 喺 Local（本地）同埋 Sandbox（沙箱）環境入面確實係比較合適。Agent 天生就係講 Command Line 語言，--help 就已經可以自描述，jq 就做到過濾，用 pipe 就可以組合。呢一點 Anthropic 係承認嘅。
但 Blog 入面話鋒一轉：生產級嘅 Agent 越嚟越多係跑喺 Cloud（雲端）上面。
Claude Cowork、Claude Managed Agents、流動端、Web 端……呢啲環境入面冇本地文件系統，跑唔到 CLI。而 MCP 嘅定位，正正就係為咗呢個場景服務：一個遠端伺服器，通殺所有 Client（客戶端）。
Claude、ChatGPT、Cursor、VS Code，一個 MCP 伺服器就搞掂晒。
Blog 入面俾出嘅一個數據係：MCP SDK 嘅月下載量由年初嘅 1 億升到去 3 億。
社群點樣爭論係一回事，但事實上係：用腳投票嘅人越嚟越多。
03Token 解決方案
呢部分應該算係成篇 Blog 入面，最關鍵嘅部分。
之前社群鬧得最勁嘅就係 token 膨脹。Anthropic 今次就直接畀咗兩個解決方法。
第一個叫 Tool Search。
之前嘅做法係將所有工具定義一股腦塞晒入上下文。43 個工具，55,000 tokens，仲未開始做嘢，工作台就已經畀說明書堆滿晒。
而家嘅做法係按需求載入。Agent 先描述佢想做啲咩，系統喺執行嗰陣搜尋相關工具，只係將配對到嗰幾個拉入嚟。
Blog 入面畀出嚟嘅測試數據係：工具定義嘅 token 消耗減少咗 85% 以上，工具選擇嘅準確率亦都冇下降。
工具要按意圖分組，唔好按 API 分。
而之前 ScaleKit 測出嚟 GitHub MCP 查 Repo 語言要 44,026 tokens，CLI 只要 1,365 tokens，差咗 32 倍。如果 Tool Search 可以斬咗 85% 嘅工具定義 token，咁 MCP 嘅總消耗大概可以降到 10,000 tokens 左右。
同 CLI 嘅差距，由 32 倍縮到大約 7 倍。
雖然仲係貴過 CLI，但起碼唔再係一個數量級嘅差距。
第二個解決方法叫程序化工具調用。
呢個思路其實同《MCP 或將成棄子》入面嘅核心洞察算係一脈相承：唔好等模型做搬運工，要等佢寫 Code。
工具返回嘅結果唔再直接掉返畀模型，而係喺 Code 執行沙盒入面處理。Agent 可以喺沙盒入面做 Loop、過濾、聚合，只係將最終結果返傳去上下文。
Blog 入面話呢個方案，喺複雜嘅多步工作流上面減少咗大約 37% 嘅 token 消耗。
兩個方案加埋一齊，MCP 嘅 token 問題雖然未徹底解決，但確實同 CLI 差唔係太遠喇。
04Cloudflare 嘅實踐
Blog 入面有個關於 Cloudflare 嘅案例，我哋可以一齊睇吓。
Cloudflare 嘅 MCP server，覆蓋咗大約 2,500 個 API endpoint。如果按傳統做法，將呢 2,500 個 endpoint 嘅工具定義全部塞晒入 context（上下文），嗰個畫面真係「靚」到唔敢睇……
而 Cloudflare 嘅做法係只係開放 2 個工具：search 同埋 execute。
Agent 首先用 search 搵到需要嘅 API，然後寫一段短嘅 script，經 execute 喺 server 端嘅 sandbox 入面跑。成個工具定義，只係佔大約 1K tokens。
呢種模式叫「程式碼編排」。
相比之下，CLI + Skill 嘅思路係：Skill 話畀 Agent 知「點樣做」，CLI 提供「用咩做」，Agent 寫 code 調用，中間嘅數據唔會經過 context。而 Cloudflare 呢個 MCP 方案，亦可以話係將 CLI 嘅哲學搬咗入 MCP 協議入面。
分別在於：佢係喺雲端跑，行嘅係 MCP 協議，而唔係本地嘅 command line。
所以，Anthropic 真正想講嘅係：MCP 同 CLI 唔係對立嘅，好嘅 MCP server 應該要好似 CLI 咁樣去設計。
05Skills 轉正
Blog 入面專門有一節講 MCP 同 Skills 嘅關係。
Anthropic 嘅講法係：MCP 管「能力」，Skills 管「編排」。
MCP 令 Agent 可以連去 Snowflake、Databricks、BigQuery 呢啲服務，Skills 就話畀 Agent 知應該點樣用呢啲連接去完成具體任務。
Claude 嘅數據 plugin 就係一個例子：10 個 Skills + 8 個 MCP servers 打包埋一齊，覆蓋咗 Snowflake、Databricks、BigQuery、Hex 等平台。
而值得留意嘅係，Canva、Notion、Sentry 呢啲第三方服務商，已經開始喺發佈 MCP server 嘅同時附帶埋 Skills 喇。
MCP 社區甚至喺度開發緊一個 extension，等 Skills 可以直接由 MCP server 分發，API 升級嗰陣 Skills 就會自動跟住更新版本。
回頭睇吓 Peter 喺 podcast 入面講嘅：
“ MCP 推動咗好多公司去做 API，呢樣係好事。我而家可以睇住一個 MCP，然後將佢整成 CLI。
而家 Anthropic 嘅態度係：你講得啱，Skills 確實係唔可以缺少。但 MCP 唔需要被取代，佢可以同 Skills 一齊推出、共存。
06MCP 嘅地盤
將呢篇 Blog 同我哋之前嘅文章一齊睇，其實又唔係矛盾。
我哋話 MCP 有三個問題：token 貴、schema 臃腫、唔可以組合。
Anthropic 呢篇 Blog 比咗三個對應嘅答案：Tool Search 解決 schema 臃腫（減咗 85%），程序化調用解決唔可以組合（由 Agent 寫 code 處理），代碼編排模式解決 token 貴（Cloudflare 嗰 2 個工具覆蓋咗 2500 個端點）。
我哋話 CLI + Skills 先係正路。Anthropic 亦都冇反駁，反而係將 Skills 寫入官方實踐 Blog 入面，仲比埋 MCP + Skills 嘅打包方案。
但 Anthropic 加咗一條唔同嘅觀點：當 Agent 喺雲端行緊，CLI 掂唔到嘅地方，MCP 就係唯一嘅選擇。
你個 Agent 喺 Claude Cowork 入面行，喺 Managed Agents 入面行，或者喺手機行，佢冇 Terminal，冇文件系統，冇辦法 pip install 一個 CLI。呢個時候一個標準化嘅遠端 MCP 伺服器，加埋 OAuth 認證同 Vaults 憑證管理，確實係更加通用同埋合理嘅方案。
所以目前嚟睇，接落嚟嘅發展大概係咁：
本地開發環境 → CLI + Skills，輕量、快、Context（上下文）乾淨。
雲端生產環境 → MCP + Skills，標準化、跨平台、認證齊全。
簡單場景 → 直連 API，唔好搞咁多嘢。
所以，MCP 並冇死到。
佢當然唔係萬能方案，但佢正喺度成為雲端 Agent 嘅標準化接入層。
◇ ◆ ◇
相關連結：
• Anthropic Blog 原文：https://claude.com/blog/building-agents-that-reach-production-systems-with-mcp
Anthropic 最新發了篇博客，標題叫《Building agents that reach production systems with MCP》，翻譯過來是：《構建能觸達生產系統的 Agent：MCP 實踐指南》。
在我去年 11 月的文章《MCP 或將成棄子》和上個月的文章《一切軟件，都將為 Agent 重寫》、《釘釘飛書集體拋棄 MCP，CLI 才是 Agent 的終局》中，我一直在闡述一個觀點：
CLI + Skills 才是 Agent 連接外部系統的正道，因為 MCP 又貴又慢還佔上下文。
但今天，MCP 的親爹 Anthropic 自己出來再一次為 MCP 說話了。
它倒不是說「你們錯了」，它說的是：「你們提的那些問題，我們有答案了。」
01之前聊過什麼
這裏來補一下前情提要。
過去一個多月，社區對 MCP 的批評集中在三件事上。
ScaleKit 做了一組嚴格的 benchmark，拿 GitHub 官方 MCP 服務器和 gh CLI 做對照，跑了 75 輪實驗。
結果是 CLI 在 token 消耗上便宜 10 到 32 倍，按月算，每月 1 萬次操作，CLI 大約 3.2 美元，MCP 大約 55.2 美元。17 倍的成本差距。
問題出在 schema 膨脹上。
GitHub 的 MCP 服務器帶了 43 個工具定義，每次對話都得把這 43 個工具的完整描述全塞進上下文。你只是想查個倉庫語言，但模型得先讀完所有 43 個工具的說明書。光是一個工具的定義就佔了 4,026 tokens。
Perplexity 的 CTO Denis Yarats 也表態稱：Perplexity 內部正在遠離 MCP，原因是 72% 的上下文窗口被 MCP 佔掉了。
龍蝦之父 Peter 也在播客裏對痛批 MCP：
“ MCP 默認污染你的上下文，加上大部分 MCP 做得不好，總體來說不是一個很有用的範式。
而釘釘和飛書也是不約而同繞開 MCP，直接把產品「壓扁」成了 CLI。在舊金山街頭的隨機調查裏，CLI 得了 17 票，MCP 僅有 3 票。
當時我們的結論是：MCP 倒是不會死，但它會退到它該待的地方。
而 CLI，將成為 Agent 操作一切軟件的默認界面。接下來，整個 SaaS 的 API surface，將全都暴露成 CLI。
02Anthropic 的回應
而今天的這篇博客，則是 Anthropic 在重新定義什麼是 MCP「該待的地方」。
博客開篇先擺了一個框架：Agent 連接外部系統有三條路，直連 API、CLI、MCP，各有各的適用場景。
直連 API 適合簡單的、一對一的場景。但如果你有 10 個 Agent 要接 10 個服務，那就是 100 個不同的集成方案，每個都要單獨搞認證和工具描述。這就是經典的 M×N 問題。
CLI 在本地和沙箱環境裏確實更合適。Agent 天生就說命令行語言，--help 就能自描述，jq 就能過濾，pipe 就能組合。這一點 Anthropic 是承認的。
但博客裏話鋒一轉：生產級 Agent 越來越多的，正在跑在雲上。
Claude Cowork、Claude Managed Agents、移動端、Web 端……這些環境裏沒有本地文件系統，跑不了 CLI。而 MCP 的定位，則恰恰就是為這個場景服務的：一個遠程服務器，通吃所有客戶端。
Claude、ChatGPT、Cursor、VS Code，一個 MCP 服務器全覆蓋。
博客裏給出的一個數據是：MCP SDK 的月下載量從年初的 1 億漲到了 3 億。
社區怎麼爭論是一回事，但事實上則是：用腳投票的人越來越多了。
03Token 解法
這應該算是整篇博客中，最為關鍵的部分了。
之前社區罵得最狠的就是 token 膨脹。Anthropic 這次則直接給了兩個解法。
第一個叫 Tool Search。
之前的做法是把所有工具定義一股腦塞進上下文。43 個工具，55,000 tokens，還沒開始幹活，工作台就被說明書堆滿了。
現在的做法是按需加載。Agent 先描述它想做什麼，系統在運行時搜索相關工具，只把匹配的幾個拉進來。
博客給出的測試數據是：工具定義的 token 消耗減少了 85% 以上，工具選擇的準確率沒有下降。
工具要按意圖分組，別按 API 分。
而之前 ScaleKit 測出來 GitHub MCP 查倉庫語言要 44,026 tokens，CLI 只要 1,365 tokens，差 32 倍。如果 Tool Search 能砍掉 85% 的工具定義 token，那 MCP 的總消耗大概能降到 10,000 tokens 左右。
跟 CLI 的差距，從 32 倍縮到了大約 7 倍。
還是比 CLI 貴，但至少不是一個數量級的差距了。
第二個解法叫程序化工具調用。
這個思路其實跟《MCP 或將成棄子》中的核心洞察算得上是一脈相承：別讓模型當搬運工，讓它寫代碼。
工具返回的結果不再直接丟回給模型，而是在代碼執行沙箱裏處理。Agent 可以在沙箱裏循環、過濾、聚合，只把最終結果返回到上下文。
博客裏說這個方案，在複雜多步工作流上減少了約 37% 的 token 消耗。
兩個方案疊加起來，MCP 的 token 問題雖然沒有徹底解決，但確實離 CLI 差的並不太多了。
04Cloudflare 的實踐
博客裏有個關於 Cloudflare 的案例，我們可以來看一下。
Cloudflare 的 MCP 服務器，覆蓋了大約 2,500 個 API 端點。如果按傳統方式，把這 2,500 個端點的工具定義全塞進上下文，那畫面簡直就是美到不忍直視了……
而 Cloudflare 的做法是隻暴露 2 個工具：search 和 execute。
Agent 先用 search 找到需要的 API，然後寫一段簡短的腳本，通過 execute 在服務端沙箱裏跑。整個工具定義，只佔大約 1K tokens。
這個模式叫「代碼編排」。
相較而言，CLI + Skill 的思路是：Skill 告訴 Agent「怎麼幹」，CLI 提供「用什麼幹」，Agent 寫代碼調用，中間數據不經過上下文。而 Cloudflare 這個 MCP 方案，也可以說是把 CLI 的哲學搬進了 MCP 協議裏。
區別在於：它跑在雲端，走的是 MCP 協議，而不是本地的命令行。
所以，Anthropic 真正想說是：MCP 和 CLI 不是對立的，好的 MCP 服務器應該像 CLI 一樣設計。
05Skills 轉正
博客專門有一節講 MCP 和 Skills 的關係。
Anthropic 的說法是：MCP 管「能力」，Skills 管「編排」。
MCP 讓 Agent 能連上 Snowflake、Databricks、BigQuery 這些服務，Skills 告訴 Agent 該怎麼用這些連接來完成具體任務。
Claude 的數據插件就是一個例子：10 個 Skills + 8 個 MCP servers 打包在一起，覆蓋了 Snowflake、Databricks、BigQuery、Hex 等平台。
而值得留意的是，Canva、Notion、Sentry 這些第三方服務商，已經開始在發佈 MCP 服務器的同時附帶 Skills 了。
MCP 社區甚至在開發一個擴展，讓 Skills 可以直接從 MCP 服務器分發，API 升級的時候 Skills 自動跟着更新版本。
回看 Peter 在播客裏說的：
“ MCP 推動了很多公司去做 API，這是好的。我現在可以看一個 MCP 然後把它做成 CLI。
而現在 Anthropic 的態度是：你說得對，Skills 確實不可或缺。但 MCP 不需要被替換掉，它可以和 Skills 一起發佈、共存。
06MCP 的地盤
把這篇博客和我們之前的文章一起來看，其實也並不矛盾。
我們說 MCP 有三個問題：token 貴、schema 臃腫、不可組合。
Anthropic 這篇博客給了三個對應的回答：Tool Search 解決 schema 臃腫（減 85%），程序化調用解決不可組合（讓 Agent 寫代碼處理），代碼編排模式解決 token 貴（Cloudflare 的 2 個工具覆蓋 2500 端點）。
我們說 CLI + Skills 才是正道。Anthropic 也並不反駁，而是把 Skills 寫進了官方的實踐博客中，還給出了 MCP + Skills 的打包方案。
但 Anthropic 加了一條不一樣的點：當 Agent 跑在雲上，CLI 夠不到的地方，MCP 是唯一的選擇。
你的 Agent 跑在 Claude Cowork 裏，跑在 Managed Agents 裏，跑在手機上，它沒有終端，沒有文件系統，沒法 pip install 一個 CLI。這時候一個標準化的遠程 MCP 服務器，加上 OAuth 認證和 Vaults 憑證管理，確實是更為通用和合理的方案。
所以目前來看，接下來的圖景大概是這樣：
本地開發環境 → CLI + Skills，輕量、快速、上下文乾淨。
雲端生產環境 → MCP + Skills，標準化、跨平台、認證完備。
簡單場景 → 直連 API，別瞎折騰。
所以，MCP 並沒有死。
它當然並非萬能方案，但它正在成為雲端 Agent 的標準化接入層。
◇ ◆ ◇
相關連結：
• Anthropic 博客原文：https://claude.com/blog/building-agents-that-reach-production-systems-with-mcp