編輯 | 伊風(fēng)

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

MCP（Model Context Protocol）其實并不新，它早在去年就由 Anthropic 正式提出。

但短短幾個月后，它的支持陣容迅速擴(kuò)展，從 Cursor、Zed 等新興工具，到谷歌、OpenAI 等頂級玩家，幾乎整個 LLM 工具鏈都開始圍繞 MCP 建設(shè)生態(tài)。

你有沒有想過一個問題：

為什么 MCP 之前的那些“前輩”都沒活下來，它卻突然火遍全場？

我們見過太多失敗的嘗試：Function Calling、LangChain、AutoGPT、Custom GPTs、Plugins……

MCP 真有什么技術(shù)上質(zhì)變的地方嗎？還是說它只是踩中了一個剛剛好的時機(jī)？

為什么Anthropic 能做成OpenAI做不成的事？

這個問題，今天在 Hacker News 上一篇爆火的帖子里被系統(tǒng)性地拆解了。

作者從模型能力、協(xié)議標(biāo)準(zhǔn)、開發(fā)體驗、生態(tài)勢能多個層面，把 MCP 能夠迅速爆火的“天時地利人和”理得明明白白。

更大膽的是，他還提出了一個斷言：MCP 將吞噬一切。

他說：

 “我們相信 MCP 會留下來：它已經(jīng)‘夠好’了，且好在了前人沒做到的地方。不僅我們這樣想，我們的 API-first 客戶也已經(jīng)將 MCP Server 視作 API 的核心部分。”

這篇帖子也引發(fā)了開發(fā)者的激烈討論，有人贊嘆 MCP 終于統(tǒng)一了接口調(diào)用的混亂局面，也有人冷笑——“這不就是個加了 decorator 的 tool calling 嗎？”

那 MCP 到底改變了什么？又是否真的值得我們?yōu)樗伦ⅲ?/p>

我們不妨從它的“失敗前輩”們說起。

一、過去的失?。篗CP的前輩們做錯了什么？

MCP 的定位是：“幫助你基于大語言模型（LLM）構(gòu)建智能代理和復(fù)雜工作流”。

如果你一直關(guān)注這類技術(shù)的發(fā)展，就會知道——這絕不是第一次有人嘗試用結(jié)構(gòu)化、自動化的方式，把外部世界連接到語言模型上。

過去的嘗試包括：

• Function/tool 調(diào)用：寫一個 JSON Schema，由模型來選擇函數(shù)。但每次請求都需要手動連接函數(shù)，還要你自己承擔(dān)重試邏輯的大部分實現(xiàn)。 
• ReAct / LangChain：讓模型輸出一個 Action: string，然后你得自己解析——經(jīng)常很不穩(wěn)定，調(diào)試也很困難。 
• ChatGPT 插件：功能豐富，但受限嚴(yán)重。你得自己搭建 OpenAPI 服務(wù)并通過 OpenAI 審核。 
• Custom GPTs：入門門檻更低，但仍然困于 OpenAI 的運行時環(huán)境。 
• AutoGPT、BabyAGI：雄心勃勃的代理框架，但配置繁復(fù)、循環(huán)混亂、錯誤層層疊加。

二、為什么是MCP殺出重圍？

拋開夸張的炒作，MCP 既不是魔法，也談不上什么技術(shù)革命。

但它確實簡單、有效、執(zhí)行得當(dāng)——關(guān)鍵是，它生逢其時。

1.模型終于夠好了

過去，工具調(diào)用的實際體驗可以用一個詞形容：混亂。

哪怕只是最基礎(chǔ)的功能，也要配合大量的錯誤處理——重試邏輯、字段校驗、異常提示，一步錯，步步錯，跑起來很費勁。

尤其是在智能體（Agent）場景下，對模型的魯棒性要求極高。

很多人都踩過坑：模型輸出一個莫名其妙的指令，導(dǎo)致后續(xù)對話徹底崩潰。我們通常叫這類問題“上下文污染”。

工具越多，風(fēng)險越大。于是大多數(shù) Agent 反而選擇了保守策略——縮短鏈路，避免做多錯多。

如今的新模型，已經(jīng)足夠強(qiáng)大。雖然仍不完美——更強(qiáng)的模型往往更慢，仍受限于上下文大小，信息過多時性能會下降——但已經(jīng)“好到可以用了”。

而一旦模型能力跨過這個臨界點，集成工具的復(fù)雜性就會顯著下降。

MCP 的登場，正好踩在了這個節(jié)點上。

2.協(xié)議夠?qū)嵱昧?/h4>

過去的工具接口都被綁定在特定技術(shù)棧里：

•  OpenAI 的 function calling 只能在他們自家 API 里用； 
•  ChatGPT 插件必須跑在他們的運行時中； 
•  LangChain 的工具深度耦合在提示循環(huán)里； 

你無法隨意將一個工具從 A 平臺搬到 B 平臺，每個平臺都得重新接線。

更糟的是，不同平臺對 JSON Schema 等規(guī)范的支持也略有差異。想要支持重試，你還得自己搞清楚怎么拼接提示信息、觸發(fā)新的一輪生成，而且每個平臺的做法都“略微不一樣”——足夠令人抓狂。

還有些隱性坑，比如：同樣的提示詞，在不同平臺表現(xiàn)差異巨大，都是因為消息處理細(xì)節(jié)不同。

MCP 提供了一種共享的、與廠商無關(guān)的協(xié)議。你定義一次工具，任何支持 MCP 的 LLM 代理都能使用它。

當(dāng)然，兼容性問題并沒有完全解決。目前想讓 MCP 同時在所有平臺順利跑通，依然具有挑戰(zhàn)性。尤其在初期沒有認(rèn)證標(biāo)準(zhǔn)，導(dǎo)致集成更加困難。

但 MCP 的承諾很重要：只要你符合 MCP 標(biāo)準(zhǔn)，其它問題就變成了“別人的 bug”。當(dāng)你不再需要對抗整個世界去實現(xiàn)某個想法時，創(chuàng)新速度會自然提升。

 MCP協(xié)議雖然不完美，但“已經(jīng)足夠好”。它作為一個抽象層，明確劃清了工具與代理之間的界限，讓工具開發(fā)者專注于工具，代理開發(fā)者專注于代理。

3.工具鏈夠易用了

MCP 提供的開發(fā)工具鏈足夠直觀、質(zhì)量上乘，也足夠易上手。多語言 SDK 提供良好支持，不管你用什么技術(shù)棧都能方便集成。

無需多余搭建，無需自己處理重試邏輯，無需操心代理連接。門檻變低，意味著構(gòu)建、共享、復(fù)用工具的速度都加快，可以部署到 CLI、IDE、代理、Web 服務(wù)等各種環(huán)境。

你可以很快開始，并立刻看到效果。

這里有個小結(jié)論：開發(fā)者體驗至關(guān)重要。平臺能否被廣泛采用，有時只取決于那一點點摩擦是否被消除了。

4.勢頭夠強(qiáng)勁了

不出所料，任何協(xié)議的成功都需要猛烈的上升態(tài)勢和開發(fā)者中的口碑宣傳。

一個協(xié)議的價值，來自于客戶端和服務(wù)端的廣泛支持。

在客戶端，MCP 已獲得廣泛采納：OpenAI Agent SDK 和 Google DeepMind 全面支持，Cursor、Cline、Zed 等主流代理工具已完成集成。

在服務(wù)端，MCP也在加速入場。越來越多 API-first 公司將自家服務(wù)封裝成 MCP 工具。即使沒有官方 MCP 工具，也有第三方服務(wù)填補(bǔ)空白。

除了 MCP 核心軟件之外，豐富的獨立生態(tài)也在迅速崛起：

•  工具注冊表（如 awesome-mcp-servers、smithery.ai、postman、glama.ai） 
•  第三方服務(wù)（如 Cloudflare、Vercel） 
•  教程（glama.ai、Towards Data Science） 
•  在線課程、活動等（Hugging Face） 

這些動量不是一夜之間建立的。Anthropic 團(tuán)隊付出了大量努力，撰寫優(yōu)質(zhì)文檔、舉辦技術(shù)講座、組織線下活動，甚至直接與企業(yè)合作，為 MCP 構(gòu)建了一個已然具有吸引力的生態(tài)。

隨著 MCP 成為主流，基礎(chǔ)模型提供商未來可能會直接在訓(xùn)練中加入 MCP 使用模式的數(shù)據(jù)。這將反過來提升模型處理工具和代理任務(wù)的能力，鞏固 MCP 作為未來 API 接入思維方式的地位。

三、開發(fā)者爭論：MCP也是“重復(fù)造輪子”，如果消亡也不會奇怪！

到這里，我們已經(jīng)梳理作者認(rèn)為 MCP 能爆火的多個原因。但在開發(fā)者社區(qū)，對 MCP 的看法仍然分歧明顯。

不少人承認(rèn) MCP 的確降低了接入工具的門檻，讓復(fù)雜任務(wù)更容易落地。比如有位開發(fā)者提到，他們用 MCP 接入了 50 多個內(nèi)部工具，Agent幾秒鐘就能自動完成本該幾小時的 Jira 和 Confluence 瀏覽總結(jié)，對業(yè)務(wù)效率的提升非常實在。

但也有許多老牌程序員對 MCP 抱有強(qiáng)烈的保留意見。他們的核心觀點是：MCP 不是突破，而是在重復(fù)造輪子。

一位資深開發(fā)者在評論中這樣寫道：

只是因為現(xiàn)在所有用戶側(cè)工具都支持 MCP，我才會用 MCP。

一旦業(yè)界選定了一個“正?！钡慕y(tǒng)一標(biāo)準(zhǔn)，我會立刻把 MCP 扔掉，因為 MCP 并沒有帶來任何我用標(biāo)準(zhǔn) API 做不到的東西。

我經(jīng)歷過從 EDI 到 EJB、XML-RPC 等整個演變過程。我們行業(yè)總愛造新 API 接口，但要么沒設(shè)計好，要么難以復(fù)用。這種“無視已有經(jīng)驗，另起爐灶”的情況我早已見怪不怪。

只要出現(xiàn)一個更合理、可集成性強(qiáng)的替代方案，我會毫不猶豫地徹底換掉 MCP。企業(yè)領(lǐng)域很多人想法都一樣——畢竟我們花了幾十年構(gòu)建完善的 API 管理系統(tǒng)，而 MCP 把這一切都搞亂了。

這番話引起了不少共鳴。另一位用戶回復(fù)道：

完全同意，雖然我理解 MCP 在用戶端工具方面的價值，但很多人似乎是在“重新造輪子”，因為他們根本不懂 REST。用 LLM 發(fā)起一個定義良好的 REST 請求，其實并不難。

更有人拋出了一個更具未來感的判斷：

如果未來 LLM 支持直接發(fā) HTTP 請求，我不會驚訝 MCP 會因此消亡，或者至少大幅減少使用場景。 因為如果你訓(xùn)練 LLM 直接調(diào)用 REST API，那 MCP 很多用例就沒意義了。

或許，MCP 的成功并不是因為它有多先進(jìn)，而是它剛好出現(xiàn)得足夠及時——踩在了模型能力提升、工具生態(tài)爆發(fā)、標(biāo)準(zhǔn)化需求集中的那個臨界點上。

但如果有一天，LLM 真能直接聯(lián)網(wǎng)、調(diào)用 API、讀寫文件……我們還會需要 MCP 嗎？

你怎么看？歡迎在評論區(qū)聊聊你的看法，或者分享你使用 MCP 的踩坑與收獲。

參考鏈接：https://www.stainless.com/blog/mcp-is-eating-the-world--and-its-here-to-stay