今年以來，一個技術新詞成了各家大廠競相追捧的繆斯——MCP（Model Context Protocol，模型上下文協議）。對于MCP，各家大廠不僅紛紛“伸臂擁抱”、迅速接入，還不吝贊揚。百度董事長李彥宏盛贊稱“MCP讓AI更懂外部世界，更容易獲得信息，更自由地調用工具，是AI發展的一大步”，并表示“百度會幫助開發者積極全面地擁抱MCP”。字節跳動旗下云平臺火山引擎總裁譚待也給予了肯定，認為MCP像互聯網早期的HTML 和 HTTP 等協議，將對推動外部應用的發展起到至關重要的作用。

那么這個迷倒眾多大廠的新詞，究竟是何方神圣？

一，魅力何來？

還得從MCP的原理說起。通俗地解釋，MCP是幫助Deepseek、豆包等大模型快速對接地圖、編程工具、文檔等外部應用的通信協議，可以幫 “AI大腦”以更便捷的方式裝上“手腳”，從而形成不僅能“思考”還能指揮應用“行動”的智能體。

近期最出名的智能體莫過于Manus，雖然它并非以MCP的方式連接，卻也讓世界見識了大模型連上應用后的廣大神通——比如一聲令下就能從零開始做出一款飛機大戰游戲。這本質上是智能體在收到人類命令后，由大模型規劃問題解決的思路及步驟，并選擇有助于實現目標的多個外部應用，再指導外部應用逐步產出所需的結果。

以上是從普通用戶的視角出發。若從開發者的角度來看，MCP是在智能體開發過程中各方可遵循的協議。只要所選用的大模型和外部應用都加入了這一協議，就能實現一鍵調用，可省去大量的代碼編寫工作。正如MCP的提出公司Anthropic在官網中所聲明的：MCP 提供了一種將 AI 模型連接到不同數據源和工具的標準化方式，可類比于USB-C 提供了一種將設備連接到外圍設備和配件的標準化方式。在這一架構中，大模型應用程序是客戶端（MCP Client），外部應用是服務器（MCP Server），一個MCP Client往往可連接多個MCP Server。

實際上，在2024年11 月被提出的MCP并不是第一個大模型通信協議。早在2023年6月，OpenAI就發布了同類協議Function Call。然而，人們發現Function Call存在諸多問題，其中最重要的是每個大模型和每個應用的參數結構和返回格式等都不統一，導致每次連接都得經歷一次代碼開發，效率較低。

而在Function Call提出之前，大模型也可與傳統API交互來調用外部應用，只是成功概率不高。因為傳統API需要精確的參數格式、嚴謹的錯誤處理協議以及精準的響應解析，而這恰恰是存在概率輸出現象的大模型所難以做到的，所以二者常常對接不上并導致工作流程崩潰。

相較之下，MCP則要友好得多。如果以女孩比喻，MCP相比“前任”協議可算是“賢惠”（運作靠譜，大模型與外部應用可順暢連接）、“美麗”（模式簡約，不用編寫大段代碼）又“開明”（足夠開放，讓各大廠能無憂接入），難怪讓國內外的AI大廠“不得不愛”。

而再更深一層來看，MCP施展魅力的背后，是Anthropic與OpenAI在這一輪AI開發者生態的爭奪。目前看來，隨著MCP力壓Function Call，Anthropic也在與OpenAI的巔峰對決中扳回了一局。

二，大廠花式“把妹”

2025年以來，隨著Manus等智能體的全球爆火，初創時默默無聞的MCP逐漸受到關注，各家AI大廠紛紛拜倒在其石榴裙下。僅在3月份，MCP服務器“集散地Smithery上的MCP發現平臺服務器創建量就實現了3倍以上的增長。

MCP作為誕生于美國的“洋妞”，率先擁抱她的是近水樓臺的美國大廠。比如3 月 27日，OpenAI宣布核心開發工具 Agent SDK支持 MCP 服務協議——這樣一來，相當于OpenAI憑借自身的行業地位，將MCP托舉成為AI領域的基礎設施。而在短時間內，谷歌、微軟、亞馬遜等巨頭也陸續接入。

沒多久，想MCP的風就刮到了中國——4月以來國內科技大廠幾乎無一例外地對其展開“花式追求”，以期在智能體生態中占據優勢。

百度大概是最高調的追求者。在發聲上由一號人物李彥宏親自示好，在行為上也不遺余力。不僅旗下的大模型服務與開發平臺千帆和AI編碼工具Comate大力接入MCP，還將體系內最重磅的應用——百度搜索、地圖、文庫、網盤等——進行了MCP化。此外，還在百度搜索設置了MCP server發現平臺，能夠索引全網的優質MCP server。

相較之下，阿里的行動算是四平八穩。官宣時管理者也發聲了，不過是部門高管；大模型服務平臺百煉、旗下重磅應用支付寶和高德地圖也接入MCP了，但更核心的應用如淘天等還在觀望；盡管宣傳旗下所有服務會走向AI Agent化并上架智能體市場，但速度相較百度還是略遜一籌。

字節則像低調卻務實的暗戀者——目前旗下的大模型服務平臺火山方舟、AI協同辦公平臺扣子空間、AI 編程工具Trae均可調用MCP，不過旗下大部分重要應用的MCP化還未見可外部調用的官宣，且未開展整體宣傳。

目前最佛系的大概是騰訊，可類比為一位資源深厚而行事淡定的富二代。目前官方僅以簡單的短資訊官宣騰訊云大模型知識引擎及軟件開發智能體Craft支持MCP協議。

在這些花式的背后，可以看出各家大廠都依托自身既有的大模型服務平臺快速搭建了自己的MCP Client體系，但對MCP Server的推出卻進度不一。大部分大廠即使推出了旗下應用的MCP版本，目前也僅限于在自家平臺上調用。

實際上，MCP Server的開發更為簡單，只需利用官方提供的Python SDK做一層MCP的適配，核心代碼不過短短幾行，對于各大廠而言并無技術難度。那么，百度之外的各家大廠為何對既有應用的似有顧慮？

也許因為這將是一場刀刃向內的變革。目前各大廠旗下的核心應用都肩負用戶抓手及流量變現主場的使命，若后續用戶習慣改為從智能體統一進入、減少對各個應用的直接使用。對大廠而言也會是顛覆性的挑戰。

如此看來，大廠們對MCP的追求頗有些心猿意馬：既想牽住美人的手、成為智能體生態舞會中最深耀眼的舞者，但又怕她尖銳的指甲勾破自家流量變現的華袍。

三，女神的煩惱

即使已貴為AI界萬人瞻仰的“新晉女神”，MCP也有著自己的煩惱。

從自身看，目前的MCP市場存在著亂象。

有騰訊開發者表示，他曾試用300多個MCP項目，其中約80%存在嚴重問題，從簡單的配置錯誤到嚴重的完全無法使用等情況都存在。而那可用的少數也未必好用，因為其背后的公司未必甘心將給出最核心、最實時的功能無償奉上。

而雪上加霜的是，目前還缺乏對MCP組件的評價體系——由于缺少分類排名等可靠指標，也暫無機制驗證MCP組件的描述與實質是否相符，智能體無從判斷哪個是最好用或最適合的外部應用，只能反復嘗試或根據模糊的描述“開盲盒”，效率不高。

此外，安全隱患也是無法回避的問題。

首先，大模型本身的幻覺輸出及數據泄露等風險問題，而MCP組件也可能被黑灰產利用而導致用戶敏感信息泄露，比如打著提供信息的幌子私下收集用戶隱私等。以上問題在智能體的應用中可能被進一步放大。

其次，靠MCP串聯起的多智能體協模式，可能導致訪問控制漏洞的出現——比如多智能體可能在交互過程中因訪問相同資源而產生一些沖突，進而產生訪問控制級聯失控并影響整體的系統穩定性。

而與此同時，有業內人士指出，在智能體業務高歌猛進的當下，許多智能體創業公司對安全性問題的認知還尚淺，有些甚至沒有配備專職安全團隊。由此，這些公司目前交付的相關產品是否具備足夠的安全性并通過安全測試，又是否存在可被惡意利用的漏洞，都還存在一定疑慮。

實際上，以上兩方面問題主要并非MCP協議本身的原因，更多要歸咎為市場發展初期難以避免的混沌。而隨著市場的逐漸成熟，大概率會沉淀下真正有價值的應用生態，就像當初PC互聯網和移動互聯網泡沫后留下了經歷考驗的幾大巨頭。

而從外部看，MCP并非不可替代。

4月9日，谷歌推出了A2A（Agent 2 Agent）協議——這是一種智能體之間的通信協議。雖然MCP是智能體與外部應用間的通信協議，與A2A看似在應用場景上有所差異，并且谷歌目前以“互補”形容二者關系，但二者都是智能體搭建過程中的API調用協議，本質相近。

同時，正如國盛證券所指出的，在“工具也可能被封裝為智能體”的復雜局勢下，A2A與MC存在一定程度的功能重疊，因此也存在相互替代的可能性。這也許反映了谷歌與Anthropic都在搶占智能體生態的制高點，若再考慮到這兩家公司間的投資關系，另一種可能性也許是A2A與MCP在未來融為一體。

而市場玩家總是“花心”的，一旦出現被行業更廣泛接受的協議，“移情別戀”是可以預測的結果——就像當時各方從Function Call轉向MCP一樣。這樣來看，MCP目前的“大眾情人”位置并不穩固。

結尾

在這場對MCP跨越國界的“狂熱追求”背后，既有技術進化帶來的必然相遇，也有生態爭奪、資本逐利與新事物不完善間的微妙博弈。但別忘了，這也許是一場沒有終曲的舞會。當強大的更通信協議橫空出世，當更安全的生態規則重塑行業，MCP的“白月光”濾鏡也許終會褪去。而AI智能體的未來，注定屬于那些能直擊人類需求本質的“破局者”。