在人工智能領(lǐng)域，大模型的交互和應(yīng)用一直是技術(shù)發(fā)展的關(guān)鍵。近期，MCP（Model Calling Protocol）作為一種新興的標(biāo)準(zhǔn)化交互協(xié)議，迅速吸引了全球技術(shù)圈的關(guān)注。從OpenAI到谷歌，各大AI巨頭紛紛投入MCP的懷抱，試圖通過這一協(xié)議實(shí)現(xiàn)大模型間的無縫交互。本文將深入剖析MCP的起源、核心價(jià)值、與現(xiàn)有技術(shù)的對(duì)比，以及它對(duì)未來技術(shù)生態(tài)的潛在影響，探討MCP是否真的有可能成為“AI界的HTTP”。

To MCP or not to MCP?

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

作為大模型間標(biāo)準(zhǔn)化交互的嘗試，MCP被寄予“AI界的HTTP”厚望，但AI領(lǐng)域從來不乏“核彈級(jí)技術(shù)”。其爆火究竟是走向共識(shí)還是曇花一現(xiàn)？對(duì)于技術(shù)決策者而言，MCP能否真正跨越概念到落地的鴻溝或許更加值得關(guān)注。

MCP爆火一個(gè)月后，本文從關(guān)鍵問題切入：為何這項(xiàng)技術(shù)能引發(fā)巨頭爭奪？它距離定義AI時(shí)代的交互事實(shí)標(biāo)準(zhǔn)還有多遠(yuǎn)？。

//章節(jié)速覽

• MCP是怎么火起來的？
• MCP是什么，本質(zhì)解決了什么核心矛盾？
• MCP能否撼動(dòng)甚至顛覆Function Call的地位？
• 目前跟MCP類似的大模型協(xié)議有哪些？MCP離成為“事實(shí)標(biāo)準(zhǔn)”還有多遠(yuǎn)？
• MCP對(duì)現(xiàn)有的技術(shù)生態(tài)有什么影響？

一、MCP是怎么火起來的？

從Github的Star History和Google搜索趨勢上看，MCP的確是全球范圍內(nèi)AI新貴，尤其是兩個(gè)觀測不同熱度指標(biāo)的曲線，竟然呈現(xiàn)出高度相似的增長態(tài)勢，這代表MCP在同時(shí)吸引圈內(nèi)人和圈外人的關(guān)注。

MCP的爆火大概有三個(gè)階段。

去年11月由Anthropic發(fā)布以來，MCP迅速吸引技術(shù)極客與開源社區(qū)開發(fā)者，其核心價(jià)值在于解決AI工具集成的“最后一公里”問題。開發(fā)者通過封裝Slack、Notion等工具構(gòu)建MCP Server，驗(yàn)證協(xié)議在各種場景的可行性。這個(gè)階段的局限性在于，多數(shù)實(shí)踐聚焦于個(gè)人效率工具，尚未觸及企業(yè)級(jí)復(fù)雜場景。例如BlenderMCP項(xiàng)目通過自然語言操控3D建模工具，雖在GitHub三天斬獲3.8k星標(biāo)，但主要服務(wù)于獨(dú)立開發(fā)者群體。

第一次破圈在于3月上旬，主要來源于“標(biāo)準(zhǔn)之辯”和“Manus發(fā)布”。3月11日。LangChain 聯(lián)合創(chuàng)始人 Harrison Chase 與 LangGraph 負(fù)責(zé)人 Nuno Campos 圍繞 MCP是否就成為未來AI交互事實(shí)標(biāo)準(zhǔn)展開激辯，雖然沒有結(jié)論，但很大程度上激發(fā)了大家對(duì)MCP的想象空間。這場辯論的同時(shí)，LangChain 還在網(wǎng)上發(fā)起了投票，40% 參與者支持 MCP 成為未來標(biāo)準(zhǔn)。

第二天，Manus框架發(fā)布。Manus雖未直接采用MCP技術(shù)，但其引發(fā)的“3小時(shí)復(fù)刻開源”事件，客觀上推動(dòng)更多團(tuán)隊(duì)關(guān)注協(xié)議標(biāo)準(zhǔn)化價(jià)值。另一方面，Manus展現(xiàn)的多Agent協(xié)同能力精準(zhǔn)契合了用戶對(duì)AI生產(chǎn)力的終極想象。當(dāng)前LLM的主流交互形態(tài)仍以ChatBot為主，雖然其Function Call機(jī)制已展示了連接外部數(shù)據(jù)的可能性，但由于需要復(fù)雜的技術(shù)對(duì)接，實(shí)際應(yīng)用始終存在門檻。

當(dāng)MCP通過聊天界面實(shí)現(xiàn)“對(duì)話即操作“的革新體驗(yàn)——用戶親眼見證輸入框指令直接觸發(fā)文件管理、數(shù)據(jù)調(diào)取等系統(tǒng)級(jí)操作時(shí)，那種“AI真的能幫我動(dòng)手干活”的認(rèn)知革命才真正爆發(fā)。正是這種顛覆性體驗(yàn)的反向賦能，使得Manus的發(fā)布成為了帶火MCP的關(guān)鍵推手。

隨后，OpenAI的官宣下場，讓大家看到了“AI界HTTP”成為現(xiàn)實(shí)的可能。當(dāng)這個(gè)占據(jù)全球40%模型市場份額的巨頭宣布支持協(xié)議，意味著MCP開始具備類似HTTP的底層基礎(chǔ)設(shè)施屬性，MCP正式進(jìn)入大眾視野，熱度持續(xù)走高，指數(shù)級(jí)飆升。

二、MCP是什么，本質(zhì)解決了什么核心矛盾？

MCP通過Client、Host、Server將大模型與外部交互抽象成了“客戶端-服務(wù)器”架構(gòu)。任何支持 MCP 的 AI 應(yīng)用（MCP Host）均可直接配置并使用應(yīng)用市場的MCP Server（官方、三方），無需預(yù)編碼適配，類似于 USB 設(shè)備插入即用。當(dāng)LLM需要完成特定任務(wù)時(shí)，可以像“即插即用”般調(diào)用這些模塊，實(shí)時(shí)獲得精準(zhǔn)的上下文支持，從而實(shí)現(xiàn)能力的彈性擴(kuò)展。

在更廣闊的視角看待，MCP 其實(shí)是Prompt Engineering 發(fā)展的產(chǎn)物。大模型是 AI 應(yīng)用的大腦，Prompt 則負(fù)責(zé)給大模型指引和參考資料。使用 Prompt Engineering 加速大模型應(yīng)用的落地是如今的主流做法。具體而言，結(jié)構(gòu)化的 Prompt 可以給大模型提供：

額外的參考資料，如使用 RAG、聯(lián)網(wǎng)搜索來增強(qiáng)大模型的回復(fù)。

調(diào)用工具的能力，從而實(shí)現(xiàn) Agent。如提供文件操作工具、爬蟲工具、瀏覽器操作工具（Manus使用的Brower Use）。

回顧 Function call或者RAG，都需要手工地執(zhí)行工具檢索、手工地將信息加入到 prompt 中，prompt 本身也需要精心地手工設(shè)計(jì)。尤其是不同大模型的Function call遵循不同的調(diào)用結(jié)構(gòu)和參數(shù)格式，彼此之間基本無法互通。

MCP的爆發(fā)源于它擊中了Prompt Engineering的核心矛盾——?jiǎng)討B(tài)意圖理解與靜態(tài)工具調(diào)用之間的割裂。傳統(tǒng)開發(fā)模式下，F(xiàn)unction call需要開發(fā)者預(yù)先編寫工具調(diào)用邏輯、設(shè)計(jì)Prompt模板、手動(dòng)管理上下文，這一過程不僅效率低下，還導(dǎo)致AI應(yīng)用難以規(guī)?；?。

三、MCP能否撼動(dòng)甚至顛覆Function Call的地位？

先說結(jié)論，顛覆不好說，但會(huì)把“Function Call們”卷起來。

Function Call本質(zhì)上是某些大模型（如 GPT-4）提供的專有能力，允許 AI 通過結(jié)構(gòu)化請(qǐng)求調(diào)用外部工具（例如查詢天氣、執(zhí)行計(jì)算）。宿主應(yīng)用收到請(qǐng)求后執(zhí)行操作并返回結(jié)果。其核心是模型廠商內(nèi)部的功能擴(kuò)展接口，無統(tǒng)一標(biāo)準(zhǔn)，實(shí)現(xiàn)依賴特定廠商。

MCP 的核心優(yōu)勢在于統(tǒng)一了各家大模型原本差異化的 Function Calling 標(biāo)準(zhǔn)，形成通用協(xié)議。它不僅支持 Claude，還能兼容市面上幾乎所有主流大模型，堪稱 AI 領(lǐng)域的“USB-C 接口”?；跇?biāo)準(zhǔn)化通信規(guī)范（如 JSON-RPC 2.0），MCP 解決了模型與外部工具、數(shù)據(jù)源間的兼容性問題，開發(fā)者只需按協(xié)議開發(fā)一次接口，即可被多模型調(diào)用。

也是由于兩者都能實(shí)現(xiàn)與外部數(shù)據(jù)的聯(lián)動(dòng)，MCP在剛問世時(shí)，開發(fā)者常糾結(jié)“它是Function Call的簡化版，還是AI交互的HTTP標(biāo)準(zhǔn)？”但隨著生態(tài)發(fā)展，MCP相比Function Call的開放性優(yōu)勢逐漸被認(rèn)知的更加清晰：

Function Call的“私有協(xié)議困局”，類似手機(jī)廠商的私有快充協(xié)議，主流AI廠商各自定義封閉的調(diào)用協(xié)議（JSON Schema、Protobuf等），導(dǎo)致開發(fā)者為不同平臺(tái)重復(fù)開發(fā)適配邏輯。切換AI服務(wù)商時(shí)，工具調(diào)用體系需“推倒重來”，跨平臺(tái)成本高企，拖慢AI能力的規(guī)?；涞?。  

MCP通過統(tǒng)一通信規(guī)范和資源定義標(biāo)準(zhǔn)，MCP讓開發(fā)者“一次開發(fā)，全平臺(tái)通用”——同一工具可無縫適配GPT、Claude等不同模型。這如同AI世界的“書同文、車同軌”，終結(jié)“重復(fù)造輪子”的窘境。  

但Function Call仍是高頻輕量任務(wù)的“王者”：它像模型的“貼身助手”，也是 MCP 協(xié)議鏈接各方的基礎(chǔ)，運(yùn)行時(shí)直接調(diào)用（如快速計(jì)算、簡單查詢），響應(yīng)極快。  

而MCP則擅長“復(fù)雜任務(wù)外包”：模型像“指揮官”下達(dá)需求（如抓取網(wǎng)頁），MCP Server作為“快遞員”按需響應(yīng)，通過HTTP/SSE協(xié)議“送貨上門”，全程無需開發(fā)者手動(dòng)干預(yù)。

可以預(yù)見的是，MCP短期內(nèi)不會(huì)顛覆Function Call，但會(huì)倒逼其進(jìn)化 。當(dāng)模型自帶工具的豐富度追上MCP，開發(fā)者還需要費(fèi)力搭建專用Server嗎？答案或許是不一定。但至少，MCP的出現(xiàn)讓Function Call們不得不“卷”起來——推動(dòng)工具調(diào)用更標(biāo)準(zhǔn)化、更便捷。  

Function Call是AI的“即時(shí)小助手”，MCP是“按需響應(yīng)的快遞員”——兩者更好的模式是協(xié)同發(fā)展。

Function Call代表“代碼控”思維：開發(fā)者需精細(xì)控制工具細(xì)節(jié)；而MCP轉(zhuǎn)向“意圖派”模式：開發(fā)者只需定義能力邊界，具體執(zhí)行由大模型動(dòng)態(tài)決策。兩者并存，讓開發(fā)者既能享受高頻任務(wù)的高效，又能解鎖復(fù)雜場景的靈活性。  

四、目前跟“MCP”類似的大模型協(xié)議有哪些？MCP離成為“事實(shí)標(biāo)準(zhǔn)”還有多遠(yuǎn)？

都說MCP像當(dāng)年的HTTP協(xié)議，其實(shí)上一個(gè)和MCP這么像的還是LSP——語言服務(wù)器協(xié)議。

在2016年LSP發(fā)布之前，開發(fā)工具生態(tài)可以用“各自為政”來形容。在傳統(tǒng)開發(fā)范式下，集成開發(fā)環(huán)境（IDE）與主流代碼編輯器（如VSCode、Sublime、VIM等）必須為Java、Python、C++等不同編程語言重復(fù)開發(fā)語法解析、代碼補(bǔ)全、調(diào)試支持等核心功能，這不僅造成巨大的資源浪費(fèi)，更導(dǎo)致開發(fā)者體驗(yàn)的割裂。而LSP的革命性突破，在于創(chuàng)建了編輯器前端與語言后端解耦的標(biāo)準(zhǔn)化通信架構(gòu)——通過定義JSON-RPC規(guī)范下的跨進(jìn)程交互協(xié)議，使得語言智能服務(wù)能夠以可插拔的方式適配任意編輯器，聽著是不是和MCP異曲同工？

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

LSP畢竟是解決編程語言和編程環(huán)境交互的，除此之外與MCP類似的技術(shù)協(xié)議大致可分為兩類，各自代表不同技術(shù)路徑，但對(duì)比MCP都呈現(xiàn)一定的劣勢。

傳統(tǒng)API規(guī)范派系

• OpenAPI/Swagger：通用API描述標(biāo)準(zhǔn)，需開發(fā)者手動(dòng)定義接口與邏輯，缺乏AI原生設(shè)計(jì)。
• GraphQL：靈活的數(shù)據(jù)查詢協(xié)議，但需預(yù)定義Schema，動(dòng)態(tài)上下文擴(kuò)展能力不足。
• 企業(yè)私有協(xié)議：如OpenAI Plugins、Google Vertex AI工具鏈，封閉性強(qiáng)，生態(tài)割裂。

AI專用框架派系

• LangChain工具庫：提供500多個(gè)工具集成，但依賴開發(fā)者編碼適配，維護(hù)成本高。
• Zapier式低代碼平臺(tái)：通過可視化流程連接工具，但功能深度受限，難以滿足復(fù)雜場景。

從這里面找一個(gè)潛在對(duì)手，OpenAPI似乎能掰掰手腕。

但事實(shí)上， OpenAPI作為API定義的事實(shí)標(biāo)準(zhǔn)，為MCP提供了基礎(chǔ)架構(gòu)而非競爭關(guān)系。

在API 管理公司CEO Speakeasy Batchu看來：“從OpenAPI規(guī)范到MCP的跨越非常小——前者本質(zhì)上是MCP所需信息的超集，我們只需將其與LLM專用參數(shù)（如語義描述、調(diào)用示例）封裝為實(shí)時(shí)服務(wù)?！边@種設(shè)計(jì)差異揭示了二者本質(zhì)區(qū)別：OpenAPI是靜態(tài)接口說明書，而MPC是動(dòng)態(tài)執(zhí)行引擎。當(dāng)AI代理通過MCP服務(wù)器發(fā)起請(qǐng)求時(shí)，其實(shí)時(shí)交互能力可動(dòng)態(tài)適配上下文變化，例如自動(dòng)補(bǔ)全參數(shù)缺失的API調(diào)用，這種“活的規(guī)范”特性解決了傳統(tǒng)集成中模型無法理解API架構(gòu)信息的致命缺陷。

前文的提到的“標(biāo)準(zhǔn)之辯”也深入探討了各種可能性。

正方的觀點(diǎn)主張：「MCP 的核心價(jià)值在于：讓用戶為不可控的 Agent 添加工具。例如在使用 Claude Desktop、Cursor 等應(yīng)用時(shí)，普通用戶無法修改底層 Agent 的代碼，但通過 MCP 協(xié)議就能為其擴(kuò)展新工具?！?/p>

核心的技術(shù)支撐是：MCP提供標(biāo)準(zhǔn)化的工具描述框架、支持通過提示詞 (prompt) 引導(dǎo)工具調(diào)用，以及基礎(chǔ)模型的工具調(diào)用能力本身也在持續(xù)進(jìn)化

反方認(rèn)為，「現(xiàn)有模型在專為特定工具集優(yōu)化的 Agent 中，工具調(diào)用正確率僅 50%。若強(qiáng)行通過 MCP 注入新工具，效果恐更不理想?！?/p>

一些現(xiàn)實(shí)的挑戰(zhàn)是：

• 工具描述與 Agent 系統(tǒng)提示詞需深度耦合
• 當(dāng)前 MCP 需要本地部署服務(wù)，使用門檻高
• 缺乏服務(wù)端部署能力，難以應(yīng)對(duì)規(guī)模化需求
• 權(quán)限驗(yàn)證等安全問題尚未解決（MCP在H1的計(jì)劃中準(zhǔn)備解決）

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

對(duì)了，Speakeasy Batchu對(duì)此也有看法——“我相信，一段時(shí)間內(nèi)會(huì)出現(xiàn)一些模式之爭，直到最終形成像 OpenAPI 這樣的標(biāo)準(zhǔn)”。

此時(shí)，Batchu還不知道十幾天后OpenAI和谷歌都宣布支持MCP。

五、MCP對(duì)現(xiàn)有的技術(shù)生態(tài)有什么影響？

MCP“萬能插頭”優(yōu)勢讓開發(fā)AI應(yīng)用進(jìn)一步解耦，大大降低了技術(shù)門檻，讓“人人都是AI開發(fā)者”變得觸手可及。

對(duì)AI廠商而言，技術(shù)重心從工具適配轉(zhuǎn)向協(xié)議兼容。MCP協(xié)議如同AI領(lǐng)域的“通用插座”，使得模型廠商只需確保與協(xié)議標(biāo)準(zhǔn)的兼容性，就能自動(dòng)接入所有MCP生態(tài)工具。例如OpenAI通過支持MCP協(xié)議，其模型無需單獨(dú)開發(fā)接口即可調(diào)用GitHub、Slack等數(shù)千種工具服務(wù)。這種轉(zhuǎn)變讓大模型廠商能夠?qū)Ｗ⒂诤诵乃惴▋?yōu)化，而非重復(fù)開發(fā)工具適配層。

對(duì)工具開發(fā)者而言，MCP實(shí)現(xiàn)了“一次開發(fā)、全生態(tài)通用”的技術(shù)普惠。開發(fā)者將功能封裝為MCP Server后，就能被所有兼容協(xié)議的AI應(yīng)用調(diào)用。如PostgreSQL官方開發(fā)的數(shù)據(jù)庫Server已被500多個(gè)AI應(yīng)用集成，而無需針對(duì)每個(gè)模型單獨(dú)適配。這讓所有應(yīng)用都找到了快速AI化的路徑，就像十幾年前“所有行業(yè)都值得用互聯(lián)網(wǎng)重做一遍”一樣；現(xiàn)在，所有產(chǎn)品都值得做一次MCP適配改造。

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

對(duì)應(yīng)用開發(fā)者而言，MCP打破了技術(shù)能力的邊界，并加速交互范式從GUI（圖形界面）向LUI（語言界面）的躍遷 。通過協(xié)議標(biāo)準(zhǔn)化，開發(fā)者無需理解底層技術(shù)細(xì)節(jié)即可組合各類資源：教育機(jī)構(gòu)用自然語言指令調(diào)用多語種資料庫生成定制教案，零售企業(yè)通過語音指令整合ERP系統(tǒng)和AI模型管理庫存。

MCP的協(xié)議兼容性使得自然語言交互可直接映射到具體功能實(shí)現(xiàn)，例如騰訊地圖MCP Server支持用戶用“找附近人均200元的川菜館”等口語化指令完成復(fù)雜搜索，替代傳統(tǒng)GUI中的多級(jí)菜單操作。這種轉(zhuǎn)型在制造業(yè)尤為顯著——某工廠工程師通過語音指令調(diào)度MCP連接的設(shè)備集群，響應(yīng)速度比傳統(tǒng)工控界面提升5倍。

LUI開發(fā)效率的革命性提升也得益于MCP對(duì)交互層的解耦：

• 傳統(tǒng)GUI困境：需為不同平臺(tái)（Web/iOS/Android）開發(fā)獨(dú)立界面組件，維護(hù)成本占開發(fā)資源的60%；
• MCP+LUI優(yōu)勢：開發(fā)者只需用自然語言描述功能需求（如生成周報(bào)圖表），MCP自動(dòng)匹配數(shù)據(jù)庫查詢、可視化工具等Server，并通過協(xié)議標(biāo)準(zhǔn)化輸出結(jié)果。

這種轉(zhuǎn)型或許正在重構(gòu)人機(jī)交互的底層邏輯。就像iPhone用觸摸屏取代鍵盤，MCP協(xié)議通過統(tǒng)一的功能調(diào)用標(biāo)準(zhǔn)，使自然語言成為連接用戶意圖與系統(tǒng)能力的“終極接口”。

MCP的崛起標(biāo)志著AI發(fā)展進(jìn)入生態(tài)競爭新階段。正如HTTP協(xié)議奠定互聯(lián)網(wǎng)基石，MCP正在構(gòu)建智能時(shí)代的“數(shù)字神經(jīng)系統(tǒng)”。其價(jià)值或許不僅在于技術(shù)規(guī)范本身，更在于開創(chuàng)了開放協(xié)作的新范式——讓模型、工具、數(shù)據(jù)在統(tǒng)一協(xié)議下自由流動(dòng)。

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