5000 字深度長文：詳解科技圈爆火的 MCP

To MCP or not to MCP?

在 OpenAI 宣佈支持 MCP 之後，谷歌也沒猶豫太久。4 月 4 日，Gemini 宣佈在官方 API 文檔中添加了使用 MCP 的範例。至此，OpenAI、谷歌、Anthropic 等 AI 巨頭全部投入這個「大模型 USB-C」的懷抱。

作爲大模型間標準化交互的嘗試，MCP 被寄予 “AI 界的 HTTP” 厚望，但 AI 領域從來不乏 “核彈級技術”。其爆火究竟是走向共識還是曇花一現？對於技術決策者而言，MCP 能否真正跨越概念到落地的鴻溝或許更加值得關注。

MCP 爆火一個月後，本文從關鍵問題切入：爲何這項技術能引發巨頭爭奪？它距離定義 AI 時代的交互事實標準還有多遠？。

一、MCP 是怎麼火起來的？

從 Github 的 Star History 和 Google 搜索趨勢上看，MCP 的確是全球範圍內 AI 新貴，尤其是兩個觀測不同熱度指標的曲線，竟然呈現出高度相似的增長態勢，這代表 MCP 在同時吸引圈內人和圈外人的關注。

MCP 的爆火大概有三個階段。

去年 11 月由 Anthropic 發佈以來，MCP 迅速吸引技術極客與開源社區開發者，其核心價值在於解決 AI 工具集成的 “最後一公里” 問題。開發者通過封裝 Slack、Notion 等工具構建 MCP Server，驗證協議在各種場景的可行性。這個階段的侷限性在於，多數實踐聚焦於個人效率工具，尚未觸及企業級複雜場景。例如 BlenderMCP 項目通過自然語言操控 3D 建模工具，雖在 GitHub 三天斬獲 3.8k 星標，但主要服務於獨立開發者羣體。

第一次破圈在於 3 月上旬，主要來源於 “標準之辯” 和“Manus 發佈”。3 月 11 日。LangChain 聯合創始人 Harrison Chase 與 LangGraph 負責人 Nuno Campos 圍繞 MCP 是否就成爲未來 AI 交互事實標準展開激辯，雖然沒有結論，但很大程度上激發了大家對 MCP 的想象空間。這場辯論的同時，LangChain 還在網上發起了投票，40% 參與者支持 MCP 成爲未來標準。

第二天，Manus 框架發佈。Manus 雖未直接採用 MCP 技術，但其引發的 “3 小時復刻開源” 事件，客觀上推動更多團隊關注協議標準化價值。另一方面，Manus 展現的多 Agent 協同能力精準契合了用戶對 AI 生產力的終極想象。當前 LLM 的主流交互形態仍以 ChatBot 爲主，雖然其 Function Call 機制已展示了連接外部數據的可能性，但由於需要複雜的技術對接，實際應用始終存在門檻。

當 MCP 通過聊天界面實現 “對話即操作 “的革新體驗——用戶親眼見證輸入框指令直接觸發文件管理、數據調取等系統級操作時，那種 “AI 真的能幫我動手幹活” 的認知革命才真正爆發。正是這種顛覆性體驗的反向賦能，使得 Manus 的發佈成爲了帶火 MCP 的關鍵推手。

隨後，OpenAI 的官宣下場，讓大家看到了 “AI 界 HTTP” 成爲現實的可能。當這個佔據全球 40% 模型市場份額的巨頭宣佈支持協議，意味着 MCP 開始具備類似 HTTP 的底層基礎設施屬性，MCP 正式進入大衆視野，熱度持續走高，指數級飆升。

二、MCP 是什麼，本質解決了什麼核心矛盾？

MCP 通過 Client、Host、Server 將大模型與外部交互抽象成了 “客戶端 - 服務器” 架構。任何支持 MCP 的 AI 應用（MCP Host）均可直接配置並使用應用市場的 MCP Server（官方、三方），無需預編碼適配，類似於 USB 設備插入即用。當 LLM 需要完成特定任務時，可以像 “即插即用” 般調用這些模塊，實時獲得精準的上下文支持，從而實現能力的彈性擴展。

在更廣闊的視角看待，MCP 其實是 Prompt Engineering 發展的產物。大模型是 AI 應用的大腦，Prompt 則負責給大模型指引和參考資料。使用 Prompt Engineering 加速大模型應用的落地是如今的主流做法。具體而言，結構化的 Prompt 可以給大模型提供：

回顧 Function call 或者 RAG，都需要手工地執行工具檢索、手工地將信息加入到 prompt 中，prompt 本身也需要精心地手工設計。尤其是不同大模型的 Function call 遵循不同的調用結構和參數格式，彼此之間基本無法互通。

MCP 的爆發源於它擊中了 Prompt Engineering 的核心矛盾——動態意圖理解與靜態工具調用之間的割裂。傳統開發模式下，Function call 需要開發者預先編寫工具調用邏輯、設計 Prompt 模板、手動管理上下文，這一過程不僅效率低下，還導致 AI 應用難以規模化。 

三、MCP 能否撼動甚至顛覆 Function Call 的地位？

先說結論，顛覆不好說，但會把 “Function Call 們” 捲起來。

Function Call 本質上是某些大模型（如 GPT-4）提供的專有能力，允許 AI 通過結構化請求調用外部工具（例如查詢天氣、執行計算）。宿主應用收到請求後執行操作並返回結果。其核心是模型廠商內部的功能擴展接口，無統一標準，實現依賴特定廠商。

MCP 的核心優勢在於統一了各家大模型原本差異化的 Function Calling 標準，形成通用協議。它不僅支持 Claude，還能兼容市面上幾乎所有主流大模型，堪稱 AI 領域的 “USB-C 接口”。基於標準化通信規範（如 JSON-RPC 2.0），MCP 解決了模型與外部工具、數據源間的兼容性問題，開發者只需按協議開發一次接口，即可被多模型調用。

也是由於兩者都能實現與外部數據的聯動，MCP 在剛問世時，開發者常糾結 “它是 Function Call 的簡化版，還是 AI 交互的 HTTP 標準？” 但隨着生態發展，MCP 相比 Function Call 的開放性優勢逐漸被認知的更加清晰：

Function Call 的 “私有協議困局”，類似手機廠商的私有快充協議，主流 AI 廠商各自定義封閉的調用協議（JSON Schema、Protobuf 等），導致開發者爲不同平臺重複開發適配邏輯。切換 AI 服務商時，工具調用體系需 “推倒重來”，跨平臺成本高企，拖慢 AI 能力的規模化落地。  

MCP 通過統一通信規範和資源定義標準，MCP 讓開發者 “一次開發，全平臺通用”——同一工具可無縫適配 GPT、Claude 等不同模型。這如同 AI 世界的 “書同文、車同軌”，終結 “重複造輪子” 的窘境。  

但 Function Call 仍是高頻輕量任務的 “王者”：它像模型的 “貼身助手”，開發者預先定義函數並打包進模型，運行時直接調用（如快速計算、簡單查詢），響應極快。  

而 MCP 則擅長 “複雜任務外包”：模型像 “指揮官” 下達需求（如抓取網頁），MCP Server 作爲 “快遞員” 按需響應，通過 HTTP/SSE 協議“送貨上門”，全程無需開發者手動干預。 

可以預見的是，MCP 短期內不會顛覆 Function Call，但會倒逼其進化 。當模型自帶工具的豐富度追上 MCP，開發者還需要費力搭建專用 Server 嗎？答案或許是不一定。但至少，MCP 的出現讓 Function Call 們不得不 “卷” 起來——推動工具調用更標準化、更便捷。  

Function Call 是 AI 的 “即時小助手”，MCP 是 “按需響應的快遞員”——兩者更好的模式是協同發展。

Function Call 代表 “代碼控” 思維：開發者需精細控制工具細節；而 MCP 轉向 “意圖派” 模式：開發者只需定義能力邊界，具體執行由大模型動態決策。兩者並存，讓開發者既能享受高頻任務的高效，又能解鎖複雜場景的靈活性。  

四、目前跟 “MCP” 類似的大模型協議有哪些？MCP 離成爲 “事實標準” 還有多遠？

都說 MCP 像當年的 HTTP 協議，其實上一個和 MCP 這麼像的還是 LSP——語言服務器協議。

在 2016 年 LSP 發佈之前，開發工具生態可以用 “各自爲政” 來形容。在傳統開發範式下，集成開發環境（IDE）與主流代碼編輯器（如 VSCode、Sublime、VIM 等）必須爲 Java、Python、C++ 等不同編程語言重複開發語法解析、代碼補全、調試支持等核心功能，這不僅造成巨大的資源浪費，更導致開發者體驗的割裂。而 LSP 的革命性突破，在於創建了編輯器前端與語言後端解耦的標準化通信架構——通過定義 JSON-RPC 規範下的跨進程交互協議，使得語言智能服務能夠以可插拔的方式適配任意編輯器，聽着是不是和 MCP 異曲同工？

可以說，MCP 的設計靈感很大程度上來源於 LSP，兩者的理念非常相似，都將 M*N 的難題簡化成了 All in One。

LSP 畢竟是解決編程語言和編程環境交互的，除此之外與 MCP 類似的技術協議大致可分爲兩類，各自代表不同技術路徑，但對比 MCP 都呈現一定的劣勢。

傳統 API 規範派系

AI 專用框架派系

從這裏面找一個潛在對手，OpenAPI 似乎能掰掰手腕。

但事實上， OpenAPI 作爲 API 定義的事實標準，爲 MCP 提供了基礎架構而非競爭關係。

在 API 管理公司 CEO Speakeasy Batchu 看來：“從 OpenAPI 規範到 MCP 的跨越非常小——前者本質上是 MCP 所需信息的超集，我們只需將其與 LLM 專用參數（如語義描述、調用示例）封裝爲實時服務。” 這種設計差異揭示了二者本質區別：OpenAPI 是靜態接口說明書，而 MPC 是動態執行引擎。當 AI 代理通過 MCP 服務器發起請求時，其實時交互能力可動態適配上下文變化，例如自動補全參數缺失的 API 調用，這種 “活的規範” 特性解決了傳統集成中模型無法理解 API 架構信息的致命缺陷。

前文的提到的 “標準之辯” 也深入探討了各種可能性。

正方的觀點主張：「MCP 的核心價值在於：讓用戶爲不可控的 Agent 添加工具。例如在使用 Claude Desktop、Cursor 等應用時，普通用戶無法修改底層 Agent 的代碼，但通過 MCP 協議就能爲其擴展新工具。」

核心的技術支撐是：MCP 提供標準化的工具描述框架、支持通過提示詞 (prompt) 引導工具調用，以及基礎模型的工具調用能力本身也在持續進化

反方認爲，「現有模型在專爲特定工具集優化的 Agent 中，工具調用正確率僅 50%。若強行通過 MCP 注入新工具，效果恐更不理想。」

一些現實的挑戰是：

開放式的討論並沒有給出答案，就像 Langchain 在 x 上發起的投票一樣。將近 500 位投票者，其中有 40% 參與者支持 MCP 成爲未來標準，並沒有取得壓倒性的勝利。

對了，Speakeasy Batchu 對此也有看法——“我相信，一段時間內會出現一些模式之爭，直到最終形成像 OpenAPI 這樣的標準”。

此時，Batchu 還不知道十幾天後 OpenAI 和谷歌都宣佈支持 MCP。

五、MCP 對現有的技術生態有什麼影響？

MCP“萬能插頭” 優勢讓開發 AI 應用進一步解耦，大大降低了技術門檻，讓 “人人都是 AI 開發者” 變得觸手可及。

對 AI 廠商而言，技術重心從工具適配轉向協議兼容。MCP 協議如同 AI 領域的 “通用插座”，使得模型廠商只需確保與協議標準的兼容性，就能自動接入所有 MCP 生態工具。例如 OpenAI 通過支持 MCP 協議，其模型無需單獨開發接口即可調用 GitHub、Slack 等數千種工具服務。這種轉變讓大模型廠商能夠專注於核心算法優化，而非重複開發工具適配層。

對工具開發者而言，MCP 實現了 “一次開發、全生態通用” 的技術普惠。開發者將功能封裝爲 MCP Server 後，就能被所有兼容協議的 AI 應用調用。如 PostgreSQL 官方開發的數據庫 Server 已被 500 多個 AI 應用集成，而無需針對每個模型單獨適配。這讓所有應用都找到了快速 AI 化的路徑，就像十幾年前 “所有行業都值得用互聯網重做一遍” 一樣；現在，所有產品都值得做一次 MCP 適配改造。

(幾天之前，MCP server 的總體數字還是 6800)

對應用開發者而言，MCP 打破了技術能力的邊界，並加速交互範式從 GUI（圖形界面）向 LUI（語言界面）的躍遷 。通過協議標準化，開發者無需理解底層技術細節即可組合各類資源：教育機構用自然語言指令調用多語種資料庫生成定製教案，零售企業通過語音指令整合 ERP 系統和 AI 模型管理庫存。MCP 的協議兼容性使得自然語言交互可直接映射到具體功能實現，例如騰訊地圖 MCP Server 支持用戶用 “找附近人均 200 元的川菜館” 等口語化指令完成複雜搜索，替代傳統 GUI 中的多級菜單操作。這種轉型在製造業尤爲顯著——某工廠工程師通過語音指令調度 MCP 連接的設備集羣，響應速度比傳統工控界面提升 5 倍。

LUI 開發效率的革命性提升也得益於 MCP 對交互層的解耦：

這種轉型或許正在重構人機交互的底層邏輯。就像 iPhone 用觸摸屏取代鍵盤，MCP 協議通過統一的功能調用標準，使自然語言成爲連接用戶意圖與系統能力的 “終極接口”。

MCP 的崛起標誌着 AI 發展進入生態競爭新階段。正如 HTTP 協議奠定互聯網基石，MCP 正在構建智能時代的 “數字神經系統”。其價值或許不僅在於技術規範本身，更在於開創了開放協作的新範式——讓模型、工具、數據在統一協議下自由流動。

MCP 是否能一統天下尚未可知，但這顯然讓我們離 AGI 又近了一步。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/tlggowR3x3DOgBPZSZQybg

猜你喜歡