編輯 | 伊風(fēng)

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

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

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

你有沒有想過一個(gè)問題：

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

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

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

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

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

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

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

他說：

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

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

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

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

一、過去的失敗：MCP的前輩們做錯(cuò)了什么？

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

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

過去的嘗試包括：

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

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

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

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

1.模型終于夠好了

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

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

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

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

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

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

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

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

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

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

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

你無法隨意將一個(gè)工具從 A 平臺(tái)搬到 B 平臺(tái)，每個(gè)平臺(tái)都得重新接線。

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

還有些隱性坑，比如：同樣的提示詞，在不同平臺(tái)表現(xiàn)差異巨大，都是因?yàn)橄⑻幚砑?xì)節(jié)不同。

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

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

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

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

3.工具鏈夠易用了

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

只是因?yàn)楝F(xiàn)在所有用戶側(cè)工具都支持 MCP，我才會(huì)用 MCP。

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

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

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

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

完全同意，雖然我理解 MCP 在用戶端工具方面的價(jià)值，但很多人似乎是在“重新造輪子”，因?yàn)樗麄兏静欢?REST。用 LLM 發(fā)起一個(gè)定義良好的 REST 請求，其實(shí)并不難。

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

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

或許，MCP 的成功并不是因?yàn)樗卸嘞冗M(jìn)，而是它剛好出現(xiàn)得足夠及時(shí)——踩在了模型能力提升、工具生態(tài)爆發(fā)、標(biāo)準(zhǔn)化需求集中的那個(gè)臨界點(diǎn)上。

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

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

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

本文轉(zhuǎn)載自51CTO技術(shù)棧，作者：伊風(fēng)