作者 | 云昭

出品 | 51CTO技術(shù)棧（微信號(hào)：blog51cto）

現(xiàn)在的MCP乃至大模型開(kāi)發(fā)圈，就像尿了褲子！一開(kāi)始熱乎乎的，然后就開(kāi)始難受了！

近日，一篇有關(guān)MCP深度批判的博客文章《A Critical Look at MCP》在網(wǎng)絡(luò)上走紅。

圖像

MCP的熱度暴漲十足，它甚至有望成為一種席卷全球的生態(tài)級(jí)別的協(xié)議，是一件有目共睹的事情。

這篇文章的作者Rasmus Holm，是一家創(chuàng)業(yè)公司CTO，三個(gè)星期前，他想在自己的實(shí)際環(huán)境中親自上手實(shí)操一番MCP，結(jié)果大失所望。

Rasmus在這篇文章中非常細(xì)節(jié)，甚至可以說(shuō)把MCP的內(nèi)褲都扒光了一遍，不管是協(xié)議層還是傳輸層都把文檔中許多“雷點(diǎn)”都篩了出來(lái)。

Rasmus在文中難掩憤怒：自己本意并非想攻擊MCP協(xié)議，但實(shí)在是忍無(wú)可忍，不吐不快！

“我真心希望這只是我技術(shù)不到位的問(wèn)題，并希望自己是誤解了什么?！?/p>

1.低質(zhì)的MCP文檔，像大模型生成的一樣！

Rasmus在摘要中首先痛斥了自己所看到的大模型圈內(nèi)一眾普遍現(xiàn)象：低質(zhì)量的開(kāi)發(fā)文檔——

“IBM 最近發(fā)布了他們自己的 MCP‘正交標(biāo)準(zhǔn)’，稱為代理通信協(xié)議 (ACP)，緊接著谷歌宣布了Agent2Agent (A2A)。MCP 服務(wù)器和客戶端每天都在構(gòu)建和發(fā)布……

然而，各大廠商花幾十億美元訓(xùn)練和調(diào)教模型，結(jié)果卻讓實(shí)習(xí)生寫(xiě)文檔，提供粗糙的 SDK，幾乎沒(méi)有實(shí)現(xiàn)指導(dǎo)。”

“讓我震驚的是，整個(gè)LLM生態(tài)工程實(shí)踐的成熟度非常糟糕！”

可讓Rasmus失望的是，即便是期望值如此之高的MCP，居然也沒(méi)有避開(kāi)這樣的“惡習(xí)”，出現(xiàn)了很多奇怪的設(shè)計(jì)決策、糟糕的文檔，以及更糟的協(xié)議規(guī)范。

例如，打開(kāi)MCP的官方文檔modelcontextprotocol.io，“你會(huì)發(fā)現(xiàn)文檔寫(xiě)得一團(tuán)糟”，而且Rasmus順帶懟了幾乎所有 LLM 廠商，“這些廠商似乎在比誰(shuí)寫(xiě)得更讓人迷惑看不懂”。

具體比如，規(guī)范完全忽略了協(xié)議中的重要細(xì)節(jié)，也沒(méi)有任何會(huì)話流程的例子。整站的重點(diǎn)都不是幫你了解協(xié)議，而是引導(dǎo)你去用他們的 SDK 教程。

此外，所有示例服務(wù)器都用 Python 或 JavaScript 編寫(xiě)，這兩種語(yǔ)言都是部署到別人電腦上的噩夢(mèng)。所以示例都提供了 Docker 鏡像，開(kāi)發(fā)者心里也是有數(shù)的。

關(guān)于這一點(diǎn)，Rasmus認(rèn)為MCP團(tuán)隊(duì)沒(méi)有注意到在編寫(xiě)本地MCP服務(wù)器時(shí)，人們未必會(huì)首選Python語(yǔ)言，比如作者本人就選擇了用Go語(yǔ)言來(lái)構(gòu)建，任何嘗試運(yùn)行HuggingFace項(xiàng)目的人都該能夠深有體會(huì)。

相信大家都知道，教程上Python的pip安裝雖然寫(xiě)的簡(jiǎn)單，但實(shí)際對(duì)于非主攻Python的人而言，簡(jiǎn)直是一場(chǎng)噩夢(mèng)。

 想一想，你上一次運(yùn)行 ??pip install?? 沒(méi)遇到依賴地獄是什么時(shí)候？作者如是說(shuō)：你要是真打算在本地跑 MCP，不是該選 Rust、Go，或者至少 Java、C# 這類更通用的語(yǔ)言嗎？

再比如，在一開(kāi)始Rasmus實(shí)現(xiàn)HTTP協(xié)議時(shí)，就感到必須反向工程整個(gè)傳輸機(jī)制。因?yàn)槲臋n里完全沒(méi)說(shuō)清楚 SSE 的細(xì)節(jié)，甚至連MCP自己的工具都沒(méi)支持“Streamable HTTP”，一個(gè)典型的例子是??npx @modelcontextprotocol/inspector@latest??，如果你一不留神，很可能會(huì)因?yàn)槔e(cuò)了版本導(dǎo)致失敗。

還有，架構(gòu)理清了還不算完。因?yàn)椴还苁欠?wù)器還是客戶端，你都會(huì)實(shí)現(xiàn)MCP都是個(gè)巨大的工程。因?yàn)?SSE / Streamable HTTP 都試圖模擬套接字行為，卻又不是套接字等等，諸如這些問(wèn)題簡(jiǎn)直把人逼瘋。

2.制造了太多地獄級(jí)問(wèn)題MCP的HTTP傳輸方式應(yīng)被徹底拋棄！

MCP號(hào)稱是AI時(shí)代的標(biāo)準(zhǔn)化接口，如同可以連接各種工具的“USB-C”。然而Rasmus經(jīng)過(guò)一番實(shí)踐，從協(xié)議層到傳輸層，都狠狠給MCP了一記耳光。

協(xié)議層方面，Rasmus指出，MCP其實(shí)是一個(gè)基于JSON-RPC的協(xié)議，定義了一些預(yù)設(shè)方法和端點(diǎn)，供 LLM 使用?！半m然這篇文章不是專門批評(píng)協(xié)議本身，但它也存在不少問(wèn)題?！?/p>

不過(guò)Rasmus更想吐槽的問(wèn)題還是在傳輸層。

這個(gè)“可在多種傳輸協(xié)議上運(yùn)行的新協(xié)議”，聽(tīng)起來(lái)非常刺激，然而Rasmus經(jīng)過(guò)一番實(shí)操之后實(shí)錘了MCP的的“言過(guò)其實(shí)”——

MCP當(dāng)前建議的HTTP傳輸方式，不管是SSE + HTTP 還是所謂的“Streamable HTTP”，都應(yīng)該被徹底拋棄，不如改用類似stdio的東西，比如WebSocket。

具體來(lái)講，Rasmus指出，SSE 模式上出現(xiàn)的問(wèn)題集中在文檔缺失、實(shí)現(xiàn)復(fù)雜、服務(wù)端需要綁定多個(gè)連接。典型的錯(cuò)誤就是，一個(gè)請(qǐng)求寫(xiě)到 A 服務(wù)器，SSE 卻連在 B 服務(wù)器上？必須加消息隊(duì)列。

而“Streamable HTTP”的問(wèn)題則在于，復(fù)雜度“更上一層樓”，控制流程比前者更混亂，安全隱患更大。

這就會(huì)導(dǎo)致相對(duì)應(yīng)的API設(shè)計(jì)堪比地獄級(jí)難度。

此外，不得不提的就是安全問(wèn)題。比如：會(huì)話狀態(tài)難管理，容易被劫持、中斷或攻擊；多入口擴(kuò)大攻擊面；實(shí)現(xiàn)復(fù)雜，掩蓋惡意行為等等。

此外，MCP協(xié)議在授權(quán)上面也頗為混亂。如果你仔細(xì)查看，你就會(huì)發(fā)現(xiàn)MCP標(biāo)準(zhǔn)規(guī)定非常、荒唐——

• STDIO：從環(huán)境變量取憑證，隨便你
• HTTP：必須實(shí)現(xiàn) OAuth2

為啥 HTTP 就要強(qiáng)制走 OAuth2，STDIO 卻可以用 API Key？什么道理呢？不知道。主打一個(gè)隨意。

3.三個(gè)協(xié)議，只有“本地”相對(duì)靠譜！其余兩個(gè)都是錯(cuò)誤實(shí)現(xiàn)

這里具體展開(kāi)看一下。據(jù)官方文檔顯示，MCP 目前支持的主要傳輸方式有兩種，也可以說(shuō)是三種：標(biāo)準(zhǔn)輸入輸出（stdio）、HTTP + SSE，還有一種則是所謂的“Streamable HTTP”。

然而這三個(gè)協(xié)議具體真實(shí)的支持程度如何？作者一條條都過(guò)了一遍，給出了自己的評(píng)價(jià)：stdio是目前最靠譜的傳輸方式！

并進(jìn)一步解釋了原因：

就像很多 2005 年之后的應(yīng)用一樣，MCP 聲稱是“本地優(yōu)先”的協(xié)議。這一點(diǎn)從傳輸協(xié)議的設(shè)計(jì)上就能看出 —— 它明顯是為本地開(kāi)發(fā)者工具準(zhǔn)備的，比如本地 IDE，或者更現(xiàn)實(shí)點(diǎn)說(shuō)，是 Cursor 和 Windsurf。

然而，靠譜并不意味著沒(méi)問(wèn)題?！巴ㄟ^(guò)stdio意味著啟動(dòng)一個(gè)本地MCP Server，把服務(wù)器的stdout/stdin接到客戶端上，然后開(kāi)始發(fā)送JSON，同時(shí)用stderr做日志。這種方式違背了 Unix/Linux 使用這些流的初衷——它們本是單向的，但MCP變成了雙向通信。”

盡管有批評(píng)之處，但作者對(duì)這種做法表示理解，這樣做是為了更簡(jiǎn)單、容易推理、跨平臺(tái)無(wú)需額外配置，而不需要管socket。

而接下來(lái)的兩個(gè)遠(yuǎn)程傳輸協(xié)議的方式，Rasmus則完全表示不解！HTTP 傳輸方式就很混亂了。這是兩個(gè)版本的“錯(cuò)誤實(shí)現(xiàn)”！

• 使用 Server-Sent Events (SSE) 來(lái)流式傳輸數(shù)據(jù)；
• “Streamable HTTP” —— 這是一個(gè)杜撰的詞，用 REST 方式包裹 SSE，但增加了大量復(fù)雜度和邊緣情況。

總結(jié)來(lái)說(shuō)，MCP團(tuán)隊(duì)不想用 WebSocket，于是“造了一個(gè) WebSocket”，然后美其名曰“Streamable HTTP”，讓它聽(tīng)起來(lái)像是被廣泛接受的做法。

作者還深扒MCP團(tuán)隊(duì)在Github上PR #206 中試圖解釋為何不用 WebSocket，但論證非常牽強(qiáng)。評(píng)論區(qū)也有人表達(dá)了相同的不滿。

4.整個(gè)大模型開(kāi)發(fā)生態(tài)像是在尿褲子

“我試圖用 Go 實(shí)現(xiàn)一個(gè) MCP Server —— 結(jié)果簡(jiǎn)直就是精神摧殘。”

Rasmus的心情可以用“崩潰”二字來(lái)形容。他甚至毫不客氣地把MCP甚至整個(gè)模型圈的這種現(xiàn)象比喻為“在尿褲子” —— 現(xiàn)在熱乎乎的，但之后會(huì)很難受。

Ras并對(duì)MCP協(xié)議給出了三點(diǎn)統(tǒng)一行為模式的建議：

• 協(xié)議只有一個(gè)：JSON-RPC
• 首選傳輸方式：Stdio
• HTTP 模式下，該用 WebSocket 模擬 stdio，而不是玩花的

尤其關(guān)于最后一點(diǎn)，Rasmus解釋到，因?yàn)閃ebSocket 完全可以做同樣的事情，而且更合理，支持雙向、去中心化的會(huì)話狀態(tài)管理，避免各種邊角問(wèn)題。

按照MCP官方所強(qiáng)調(diào)的——

客戶端和服務(wù)器可實(shí)現(xiàn)任何自定義傳輸協(xié)議，MCP 協(xié)議是傳輸無(wú)關(guān)的，只要支持雙向消息交換即可。
—— modelcontextprotocol.io

我們應(yīng)該為最常見(jiàn)的使用場(chǎng)景做優(yōu)化，而不是為邊角情況做妥協(xié)。

5.MCP的替代方案與補(bǔ)充

IBM 和 Google 推出的 ACP 與 A2A 實(shí)際上是 MCP 的變體。MCP 是“讓 LLM 使用 API”，ACP/A2A 則是“讓 LLM 使用 Agent”。

A2A 的很多功能其實(shí) MCP 也能做。IBM 甚至表示：

Agent 可以被視為 MCP 的資源，也可以作為工具調(diào)用
—— IBM / agentcommunicationprotocol.dev

Rasmus認(rèn)為，ACP 更像是 IBM 推廣其 BeeAI agent 構(gòu)建工具的手段。

這兩種協(xié)議最大的貢獻(xiàn)：更清晰的傳輸層設(shè)計(jì) 和 Agent 的發(fā)現(xiàn)機(jī)制。

6.網(wǎng)友：的確，文檔難懂是LLM廠商的通病等MCP適配器出來(lái)之后就好了

整篇文章，Rasmus可謂是直言直語(yǔ)，在一篇叫好聲中，點(diǎn)出了MCP協(xié)議目前存在的大量問(wèn)題：文檔規(guī)范成熟度不夠、協(xié)議層面的實(shí)現(xiàn)不合理、本地實(shí)現(xiàn)工程難度大等等。

正是因?yàn)閷?shí)際所感，這一篇激情吐槽在Hackernews上引起了網(wǎng)友的共鳴，1天之內(nèi)迅速引起了多達(dá)317條的評(píng)論。

很多網(wǎng)友就像被打開(kāi)了“話閘”一樣，紛紛表示：現(xiàn)在大模型開(kāi)發(fā)相關(guān)的文檔寫(xiě)得很差！

更有網(wǎng)友曝料：MCP spec [0] 里到處都是 LLM 的痕跡。他們幾乎都在用 LLM 來(lái)寫(xiě)文檔，但這仍然是個(gè)很糟糕的主意。

甚至這位網(wǎng)友打趣地說(shuō)道：事實(shí)上，濫用大模型來(lái)構(gòu)建規(guī)范比濫用它們來(lái)避免編寫(xiě)優(yōu)秀的文檔要糟糕得多，因?yàn)閷?duì)于規(guī)范和 RFC 來(lái)說(shuō)，編寫(xiě)規(guī)范的過(guò)程才是關(guān)鍵所在。

為什么這么確定？

這位網(wǎng)友解釋道：最終，MCP 規(guī)范是 LLM 的產(chǎn)物的最大標(biāo)志不是它有些不連貫，或者它完全由項(xiàng)目符號(hào)列表組成，或者它具有那種獨(dú)特的平淡風(fēng)格：而是它顯示出相對(duì)于我們對(duì)主要規(guī)范的期望而言，它幾乎沒(méi)有經(jīng)過(guò)人類思考。

因?yàn)橐话愣?，一份高可讀的合格的輸出文檔，通常還要努力找出你當(dāng)前思維的所有缺陷、不足和不完整之處。你需要批判性地閱讀規(guī)范，識(shí)別邊緣情況，并不斷修改規(guī)范，直到它能夠解答規(guī)范設(shè)計(jì)人員和相關(guān)社區(qū)的所有疑問(wèn)。

當(dāng)然，還有不少網(wǎng)友相信MCP團(tuán)隊(duì)的成員，相信他們會(huì)快速跟進(jìn)，修改文章中所提到問(wèn)題。因?yàn)锳nthropic中確實(shí)有一些很敏銳的人才！

此外，也有海外的網(wǎng)友提到了DeepSeek的開(kāi)源文檔同樣也有不少讓人讀不懂的地方。主要還是因?yàn)閮?nèi)容翻譯方面太過(guò)“Chinglish”的原因。

不過(guò)，話說(shuō)回MCP，有網(wǎng)友表示，對(duì)于更多MCP服務(wù)器構(gòu)建的大眾程序員而言，現(xiàn)在還是太難了，只需要有人會(huì)編寫(xiě)一個(gè)MCP適配器，讓Claude使用OpenAPI即可，因?yàn)檫@樣大家就可以忘掉MCP的存在了！

不得不說(shuō)，這也是一枚典型的“等等黨”了！

最后，MCP如火如荼，但小編了解到一些業(yè)內(nèi)人士仍在持懷疑或觀望的態(tài)度，一方面是因?yàn)锳nthropic的生態(tài)能否大成，突圍OpenAI尚未可知，另一方面則在于MCP協(xié)議目前尚存在不少局限性，比如本文提到的主打本地而不能遠(yuǎn)程、安全問(wèn)題等等。

那么，問(wèn)題來(lái)了，咱們?nèi)绾慰创齊asmus有關(guān)MCP的無(wú)情痛批呢？

參考鏈接：

??https://raz.sh/blog/2025-05-02_a_critical_look_at_mcp??

??https://news.ycombinator.com/item?id=43945993??

本文轉(zhuǎn)載自??51CTO技術(shù)棧??，作者：云昭