在科技圈，MCP（Model Context Protocol，模型上下文協議）正迅速成為 AI 領域的熱門話題。從 OpenAI 到谷歌，再到 Anthropic，各大 AI 巨頭紛紛投入這一“大模型 USB-C”的懷抱。

本文通過 5000 字的深度分析，詳細探討了 MCP 的起源、核心價值、與現有技術（如 Function Call）的對比，以及其對現有技術生態的影響。

———— / BEGIN / ————

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時代的交互事實標準還有多遠？。

//章節速覽

1. MCP是怎么火起來的？

2. MCP是什么，本質解決了什么核心矛盾？

3. MCP能否撼動甚至顛覆Function Call的地位？

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

5. 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對交互層的解耦：

• 傳統GUI困境：需為不同平臺（Web/iOS/Android）開發獨立界面組件，維護成本占開發資源的60%；

• MCP+LUI優勢：開發者只需用自然語言描述功能需求（如生成周報圖表），MCP自動匹配數據庫查詢、可視化工具等Server，并通過協議標準化輸出結果。

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

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

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

本文來自微信公眾號：鵝廠技術派，作者：鵝廠技術派

想第一時間掌握AI動態、工具干貨？掃碼加入共學交流群，一起偷跑不掉隊！

———— / 推薦閱讀 / ————