編輯｜冷貓

OpenClaw 已經(jīng)爆火了好一陣子了。

大部分感興趣的用戶都已經(jīng)嘗試過「養(yǎng)龍蝦」的操作，也有一部分人已經(jīng)尋求徹底卸載，斬斷與AI的孽緣。

這陣風有隱隱消退的趨勢。但使用過 OpenClaw 的朋友們有沒有發(fā)現(xiàn)，OpenClaw 不支持 MCP 協(xié)議

模型上下文協(xié)議（Model Context Protocol，簡稱 MCP），在2024 年 11 月由 Anthropic 推出。推出后，MCP 在開發(fā)者和 AI 社區(qū)中迅速獲得了廣泛關(guān)注，被視為大模型通信和交互的標準協(xié)議。

但時間僅過了一年多，MCP 似乎已經(jīng)銷聲匿跡了，就連 MCP 協(xié)議的「一周年紀念日」卻在一片寂靜中度過。從發(fā)布以來，MCP 的「builder 多于 user」、「舊瓶裝新酒」的質(zhì)疑始終存在。

而現(xiàn)在，MCP 似乎正在走向消亡。昨天，Perplexity 的聯(lián)合創(chuàng)始人和 CTO Denis Yarats 在其公司內(nèi)部表示，他們正在放棄 MCP，轉(zhuǎn)而使用 API 和 CLI

諷刺的是，這似乎是近期 MCP 聲量最高的事件，引發(fā)了網(wǎng)友們的討論。

網(wǎng)友們的想法都挺一致的，尤其是 Skills 逐漸占據(jù)了智能體應(yīng)用的主場后，MCP 似乎早就應(yīng)該消失了。

除了 Perplexity 以外，曾經(jīng)對 MCP 集成的全面支持，甚至實現(xiàn)了 OAuth 和動態(tài)客戶端注冊的 AI 聊天工具 Duetchat ，在 v2 版本中，也徹底刪除了 MCP 集成的功能。

就連 Y Combinator 總裁兼 CEO Garry Tan 也直言不諱：MCP sucks！

那么，MCP 到底有哪些問題，導(dǎo)致誰都不待見呢？

MCP 的天生缺陷

MCP 協(xié)議的模式是：定義一組工具（帶有 Schema 的函數(shù)），將其注入 Agent 的上下文，然后讓 Agent 調(diào)用它們。

這種模式可行，但難以為繼。核心問題在于線性上下文成本。

你添加的每一個 MCP 工具，包括它的名稱、描述、參數(shù) Schema 和示例，都會占用 Agent 的上下文窗口。如果你連接 10 個服務(wù)，每個服務(wù)有 5 個工具，那么在 Agent 開始執(zhí)行任何任務(wù)之前，你就已經(jīng)燒掉了數(shù)千個 Token。

所以在使用MCP協(xié)議之前，我們只能選擇：

• 預(yù)先加載所有內(nèi)容：接受實際任務(wù)性能的下降（推理空間、對話歷史和工作記憶被擠占）。
• 限制集成數(shù)量：接受你的 Agent 只能與少數(shù)幾個服務(wù)通信的現(xiàn)實。
• 構(gòu)建動態(tài)工具加載：接受工具選擇中間件帶來的延遲和復(fù)雜性。

這些都不是理想方案。上下文窗口是 Agent 擁有的最寶貴的「房地產(chǎn)」，使用 MCP 協(xié)議是一種極大的浪費。

MCP 在日常使用中也存在幾點問題：

• 初始化極不穩(wěn)定：實際使用中經(jīng)常會因為 MCP 服務(wù)端沒能正常啟動而重啟 Claude Code 。有時重試能成，有時則得清空狀態(tài)推倒重來。
• 無休止的重新認證：如果你使用多個 MCP 工具，那么就需要在每個工具上都過一遍認證。
• 權(quán)限管理非黑即白：Claude Code 允許你通過名稱將 MCP 工具加入白名單，但也僅此而已。無法將操作限制在只讀范圍內(nèi)，也無法限制參數(shù)。

CLI 和 API，古法拯救世界

來自 Eric Holmes 的一篇博客指出了傳統(tǒng) CLI 在大模型智能體的強大能力。他認為，MCP 并沒有帶來任何實際價值。LLM 真正擅長靠自己搞清楚狀況。給它們一個 CLI 和一份文檔，它們就能如魚得水。

LLM 非常擅長使用命令行工具。它們在數(shù)以百萬計的 man 手冊、Stack Overflow 的回答以及充斥著 Shell 腳本的 GitHub 倉庫中接受過訓練。MCP 承諾提供一個更簡潔的接口，但在實踐中，我們?nèi)砸獙懲瑯拥奈臋n：每個工具的功能、接受的參數(shù)，更重要的是，何時去使用它。

當 Claude 對 Jira 執(zhí)行了某些出乎意料的操作時，我可以運行同樣的 jira issue view 命令，看看到底它看到了什么。輸入一致，輸出一致，沒有任何謎團。但在 MCP 下，工具僅存在于 LLM 的對話內(nèi)部。一旦出錯，就不得不去翻找復(fù)雜的 JSON 傳輸日志，而不是自己跑一遍命令。

最重要的差距是：CLI 是可組合的。我可以通過 jq 過濾數(shù)據(jù)，通過 grep 串聯(lián)邏輯，或者重定向到文件。這不僅是方便，通常也是唯一可行的方法。

如果使用 MCP，你要么將整個計劃全部塞進上下文窗口（既昂貴又往往不可行），要么在 MCP 服務(wù)端內(nèi)部構(gòu)建自定義的過濾功能。無論哪種方式，你都是在用更多的精力換取更差的結(jié)果。而 CLI 方案使用的是現(xiàn)成的、文檔齊全的工具，且人類和智能體（Agent）都能理解。

最好的工具是那些對人類和機器都好用的工具。CLI 已經(jīng)歷了數(shù)十年的設(shè)計迭代，它們可組合、可調(diào)試，并寄生于現(xiàn)有的認證體系。

MCP 試圖構(gòu)建一個更好的抽象層，但事實證明，我們已經(jīng)擁有一個足夠好的了

https://ejholmes.github.io/2026/02/28/mcp-is-dead-long-live-the-cli.html

https://x.com/dzhng/status/2029518820872945889