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是怎麼火起來的？
MCP是什麼，本質解決了什麼核心矛盾？
MCP能否撼動甚至顛覆Function Call的地位？
目前跟MCP類似的大模型協議有哪些？MCP離成為“事實標準”還有多遠？
MCP對現有的技術生態有什麼影響？

一、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 可以給大模型提供：

額外的參考資料，如使用 RAG、聯網搜尋來增強大模型的回覆。
呼叫工具的能力，從而實現 Agent。如提供檔案操作工具、爬蟲工具、瀏覽器操作工具（Manus使用的Brower Use）。

回顧 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則擅長“複雜任務外包”：模型像“指揮官”下達需求（如抓取網頁），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規範派系

OpenAPI/Swagger：通用API描述標準，需開發者手動定義介面與邏輯，缺乏AI原生設計。
GraphQL：靈活的資料查詢協議，但需預定義Schema，動態上下文擴充套件能力不足。
企業私有協議：如OpenAI Plugins、Google Vertex AI工具鏈，封閉性強，生態割裂。

AI專用框架派系

LangChain工具庫：提供500多個工具整合，但依賴開發者編碼適配，維護成本高。
Zapier式低程式碼平臺：透過視覺化流程連線工具，但功能深度受限，難以滿足複雜場景。

從這裡面找一個潛在對手，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 注入新工具，效果恐更不理想。」

一些現實的挑戰是：

工具描述與 Agent 系統提示詞需深度耦合
當前 MCP 需要本地部署服務，使用門檻高
缺乏服務端部署能力，難以應對規模化需求
許可權驗證等安全問題尚未解決（MCP在H1的計劃中準備解決）

開放式的討論並沒有給出答案，就像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對互動層的解耦：