作者 | 云昭

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

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

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

圖像

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

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

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

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

“我真心希望這只是我技術(shù)不到位的問題，并希望自己是誤解了什么。”

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

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

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

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

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

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

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

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

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

關(guān)于這一點，Rasmus認為MCP團隊沒有注意到在編寫本地MCP服務(wù)器時，人們未必會首選Python語言，比如作者本人就選擇了用Go語言來構(gòu)建，任何嘗試運行HuggingFace項目的人都該能夠深有體會。

相信大家都知道，教程上Python的pip安裝雖然寫的簡單，但實際對于非主攻Python的人而言，簡直是一場噩夢。

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

再比如，在一開始Rasmus實現(xiàn)HTTP協(xié)議時，就感到必須反向工程整個傳輸機制。因為文檔里完全沒說清楚 SSE 的細節(jié)，甚至連MCP自己的工具都沒支持“Streamable HTTP”，一個典型的例子是npx @modelcontextprotocol/inspector@latest，如果你一不留神，很可能會因為拉錯了版本導(dǎo)致失敗。

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

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

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

協(xié)議層方面，Rasmus指出，MCP其實是一個基于JSON-RPC的協(xié)議，定義了一些預(yù)設(shè)方法和端點，供 LLM 使用。“雖然這篇文章不是專門批評協(xié)議本身，但它也存在不少問題。”

不過Rasmus更想吐槽的問題還是在傳輸層。

這個“可在多種傳輸協(xié)議上運行的新協(xié)議”，聽起來非常刺激，然而Rasmus經(jīng)過一番實操之后實錘了MCP的的“言過其實”——

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

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

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

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

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

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

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

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

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

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

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

并進一步解釋了原因：

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

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

盡管有批評之處，但作者對這種做法表示理解，這樣做是為了更簡單、容易推理、跨平臺無需額外配置，而不需要管socket。

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

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

總結(jié)來說，MCP團隊不想用 WebSocket，于是“造了一個 WebSocket”，然后美其名曰“Streamable HTTP”，讓它聽起來像是被廣泛接受的做法。

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

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

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

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

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

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

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

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

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

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

5.MCP的替代方案與補充

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

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

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

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

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

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

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

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

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

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

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

為什么這么確定？

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

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

當(dāng)然，還有不少網(wǎng)友相信MCP團隊的成員，相信他們會快速跟進，修改文章中所提到問題。因為Anthropic中確實有一些很敏銳的人才！

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

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

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

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

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

參考鏈接：

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

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