編輯 | 伊風

出品 | 51CTO技術棧（微信號：blog51cto）

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

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

你有沒有想過一個問題：

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

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

MCP 真有什么技術上質變的地方嗎？還是說它只是踩中了一個剛剛好的時機？

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

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

作者從模型能力、協議標準、開發體驗、生態勢能多個層面，把 MCP 能夠迅速爆火的“天時地利人和”理得明明白白。

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

他說：

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

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

那 MCP 到底改變了什么？又是否真的值得我們為它下注？

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

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

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

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

過去的嘗試包括：

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

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

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

但它確實簡單、有效、執行得當——關鍵是，它生逢其時。

1.模型終于夠好了

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

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

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

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

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

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

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

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

2.協議夠實用了

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

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

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

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

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

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

當然，兼容性問題并沒有完全解決。目前想讓 MCP 同時在所有平臺順利跑通，依然具有挑戰性。尤其在初期沒有認證標準，導致集成更加困難。

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

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

3.工具鏈夠易用了

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

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

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

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

4.勢頭夠強勁了

不出所料，任何協議的成功都需要猛烈的上升態勢和開發者中的口碑宣傳。

一個協議的價值，來自于客戶端和服務端的廣泛支持。

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

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

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

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

這些動量不是一夜之間建立的。Anthropic 團隊付出了大量努力，撰寫優質文檔、舉辦技術講座、組織線下活動，甚至直接與企業合作，為 MCP 構建了一個已然具有吸引力的生態。

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

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

到這里，我們已經梳理作者認為 MCP 能爆火的多個原因。但在開發者社區，對 MCP 的看法仍然分歧明顯。

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

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

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

只是因為現在所有用戶側工具都支持 MCP，我才會用 MCP。

一旦業界選定了一個“正常”的統一標準，我會立刻把 MCP 扔掉，因為 MCP 并沒有帶來任何我用標準 API 做不到的東西。

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

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

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

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

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

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

或許，MCP 的成功并不是因為它有多先進，而是它剛好出現得足夠及時——踩在了模型能力提升、工具生態爆發、標準化需求集中的那個臨界點上。

但如果有一天，LLM 真能直接聯網、調用 API、讀寫文件……我們還會需要 MCP 嗎？

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

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

本文轉載自51CTO技術棧，作者：伊風