MCP is Dead. Long Live the CLI.
2 個月前，Eric Holmes 為 MCP 定義了結局。因為 LLM 本來就很會用命令列，搞一層協議根本是多此一舉。
因為 MCP 本身就有 Token 成本、伺服器啟動卡死、OAuth 認證反覆彈窗、權限只能全有或全無……等等問題，幾乎所有人都非常認同 Eric 的這個觀點。
然後這週，Anthropic 發了一篇長篇部落格：《Building Agents That Reach Production Systems with MCP》。標題沒有直說，但翻譯一下就是：你們罵得對，我們改了，而且想清楚了 MCP 到底該做什麼。
Eric 說 MCP 已死的理由，都沒問題
大型語言模型天生就會用命令列介面（CLI），不需要什麼 MCP。
用 CLI 指令掛了，在終端機跑同樣的指令就能看到一模一樣的輸出。但如果 MCP 報錯了，那紀錄檔就不好追了。
CLI 還有成熟的 Unix 管道組合能力， grep | jq | awk 這種組合非常方便，不是一個 MCP 伺服器能輕易複製的。
但 Anthropic 說：你只看到了一半
Anthropic 把 AI 代理接外部系統的路徑分成三條：
直接 API 呼叫： 簡單場景可以，但十幾個整合做下來，M×N 的組合爆炸誰都扛不住。
命令列介面（CLI）： 在本地確實很猛。但有個致命限制：雲端 AI 代理、行動裝置、網頁版，根本沒有 Shell 可以用。
模型上下文協定（MCP）： 標準化協議，內建認證、服務發現、豐富語意。是為生產級雲端 AI 代理準備的。
關鍵在第二條。
當 AI 代理只在你終端機裡跑，比如 Claude Code 在本地幫你寫程式，CLI 就是最優解，沒什麼好爭的。但 AI 代理跑在雲上呢？跑在瀏覽器裡呢？跑在手機裡呢？
Claude 現在有 Cowork（雲端協作）、有 Managed Agents（託管代理）。這些東西不在你的 Mac 終端機裡，它們需要一種標準化方式連接外部系統。而 CLI 在這些環境裡根本跑不起來。
MCP 不是來取代 CLI 的，是來覆蓋 CLI 到不了的地方。
這個定位一理清，之前大部分的爭論其實就自動消解了。
技術改進
這次 Anthropic 給出了幾個 MCP 的改進方案。
工具搜尋——工具按需載入
之前 MCP 最常被罵的問題之一：伺服器註冊一堆工具，所有 schema 全塞進上下文視窗，工具一多 Token 就爆了。
新方案是按需搜尋——根據使用者意圖動態載入需要的工具，不相關的根本不載入。
帶來的結果是：工具定義的 Token 消耗減少 85% 以上。
程式化工具呼叫——沙箱裡先處理再回傳
另一個痛點：AI 代理調用完工具，原始 JSON 全量塞回上下文，大量垃圾資訊佔著 Token。新方案是在程式碼沙箱裡先做過濾和聚合，只把有用的資訊給模型。
帶來的結果是：複雜工作流程的 Token 消耗減少約 37%。
技能包 + MCP = 殼層
技能包教 AI 代理「怎麼做」（流程知識），MCP 給 AI 代理「用什麼做」（工具接入）。兩者打包成外掛程式分發。
例如：一個 K8s 維運外掛程式：技能包裡寫好排查流程和最佳實踐，MCP 提供 kubectl 工具。AI 代理裝上就能幹活。
以後 MCP 伺服器甚至可以自帶技能包，客戶端連上就自動獲得操作知識。
每月 3 億次下載。你說它死了？
部落格裡提了一個數字——MCP 現在每月超過 3 億次下載。
被罵成這樣，用的人還是越來越多。
說到底，事實確實如此。CLI 在本地場景確實更舒服，但當你的 AI 代理需要上雲、需要跨平台、需要對接十幾個 SaaS 服務，除了 MCP，沒有更好的標準化選擇。
這跟當年 REST vs GraphQL 的爭論有點像。GraphQL 剛出來也被罵：「HTTP 夠用了，搞這麼複雜幹嘛？」結果呢，複雜場景下該用的還是在用。
寫在最後
從結果來看，MCP is dead 這場爭論是好事。因為它倒逼著 Anthropic 想清楚了定位：
MCP 不是萬能的，是給雲端生產級 AI 代理用的標準化連接層。
本地場景，CLI 該上就上，沒人攔著。
有時候一個技術方案被社群猛烈質疑，不一定是壞事。至少比悶著頭做、沒人用強多了。