編輯｜冷貓

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

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

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

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

但時(shí)間僅過了一年多，MCP 似乎已經(jīng)銷聲匿跡了，就連 MCP 協(xié)議的「一周年紀(jì)念日」卻在一片寂靜中度過。從發(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 集成的全面支持，甚至實(shí)現(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)用它們。

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

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

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

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

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

MCP 在日常使用中也存在幾點(diǎn)問題：

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

CLI 和 API，古法拯救世界

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

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

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

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

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

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

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

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

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