文｜鄧詠儀

編輯｜蘇建勛

大模型的風(fēng)，如今又刮到了一個新名詞上：MCP。

AI圈中不缺新鮮事，但這次不一樣，互聯(lián)網(wǎng)仿佛又回到了十多年前的春天。“現(xiàn)在，基于MCP開發(fā)智能體，就像2010年開發(fā)移動APP。”4月25日，百度董事長李彥宏在百度Create大會上說到。

如果還沒有聽過MCP，但你肯定聽過上一個熱詞：Agent（智能體）。2025年初，中國初創(chuàng)公司Manus的爆火，把這個名詞瞬間推到了大眾面前。

“真·能干活的AI”，是Agent爆火的關(guān)鍵。在這之前，大模型可以答疑解惑，但它只是一個簡單的對話窗口，依賴于模型接受過的訓(xùn)練，大模型內(nèi)的數(shù)據(jù)往往不是最新的，如果只有大模型本體，調(diào)用外部工具，要經(jīng)歷非常繁瑣的過程。

MCP這個概念，就和Agent密不可分。MCP是Agent愿景得以實現(xiàn)的的重要路徑——大模型可以自由地調(diào)用支持MCP協(xié)議的外部工具，完成更具體的任務(wù)。

現(xiàn)在，包括高德地圖、微信讀書在內(nèi)的應(yīng)用，就已經(jīng)紛紛推出官方的MCP Server（服務(wù)器），這意味著，所有開發(fā)者都可以像搭積木一樣，先確定自己用什么大模型，而后調(diào)用高德地圖、微信讀書的MCP服務(wù)器，大模型就可以完成查詢地圖等等任務(wù)。

從2月開始，一場MCP浪潮已經(jīng)如火如荼地席卷全球。

幾乎所有大廠—— OpenAI、谷歌、meta，以及國內(nèi)的阿里、騰訊、字節(jié)、百度等等，紛紛宣布支持MCP協(xié)議，也都推出了自家的MCP平臺，邀請各路開發(fā)者、應(yīng)用服務(wù)商進駐。

如果復(fù)盤2024年國內(nèi)AI領(lǐng)域討論得最火的名詞，“超級應(yīng)用”肯定算其中一個。人們普遍認為，2024年會迎來AI應(yīng)用的大繁榮，但并沒有如預(yù)期般快速發(fā)展。AI領(lǐng)域的創(chuàng)新生態(tài)，更多還是星星點點地散落在各處。

正因如此，MCP的爆火，不亞于春秋戰(zhàn)國時期，秦始皇一掃六合的意義——統(tǒng)一各國的書寫、交通、度量標準，從而大大方便了經(jīng)濟和商品往來。

不少市場評價認為，隨著MCP等協(xié)議逐漸成為共識和趨勢，2025年會迎來一場真正意義上的AI應(yīng)用大爆發(fā)。

MCP，AI的“超級外掛”

事實上，MCP并不是一個新事物，早在2024年11月，就已經(jīng)由Anthropic宣布推出。

MCP的全稱是“Model Context Protocol”，即模型上下文協(xié)議。這是一項開放標準，基于大模型的應(yīng)用如果支持了MCP協(xié)議，就像學(xué)會了一門標準化“語言”，和外界的數(shù)據(jù)源、工具等等進行互動。

如果你覺得這個解釋依然復(fù)雜，那么可以看看手機、電腦上的數(shù)據(jù)接口——MCP相當于給大模型裝上了一個“萬能插座”，定義了一個標準的“USB接口”。

有了這個接口，開發(fā)者得以有章法地，在更標準化的框架和約定下進行應(yīng)用開發(fā)，對接不同的數(shù)據(jù)源和工作流。

在MCP成為趨勢之前，開發(fā)AI應(yīng)用的門檻一直在高位。

如果一位開發(fā)者想開發(fā)一個AI旅游助手，需要讓大模型至少完成幾項工作：查看地圖、在網(wǎng)絡(luò)上查找攻略、結(jié)合用戶需求撰寫一份新的旅游計劃。

那么，為了讓大模型順利能夠查詢地圖，在瀏覽器上查找現(xiàn)有的攻略。開發(fā)者所經(jīng)歷的開發(fā)過程是這樣的：

首先，每個AI提供商（OpenAI、Anthropic等）對Function Calling的實現(xiàn)略有不同。如果中間涉及兩個大模型的切換，那開發(fā)者還需要為不同模型重寫適配代碼，相當于幫大模型寫一個外部工具的“使用手冊”，大模型才能學(xué)會用更好的prompt調(diào)用外面的工具。否則，模型輸出的結(jié)果準確度會直線下降。

簡單總結(jié)，就是大模型在和外界交互時，缺少統(tǒng)一標準，導(dǎo)致代碼復(fù)用性太低。AI應(yīng)用生態(tài)的發(fā)展就會自然滯后。

“對于任何一個大模型應(yīng)用開發(fā)者，在MCP出現(xiàn)之前，開發(fā)者不僅需要懂大模型，也需要自己做二次開發(fā)，把外部的工具嵌入到自己的應(yīng)用中。并且，工具的性能如果不好，開發(fā)者自己還需要去研究，究竟是應(yīng)用本身的問題，還是工具的問題。”阿里云魔搭社區(qū)算法技術(shù)專家陳子謙對《智能涌現(xiàn)》等媒體表示。

Manus也是一個典型例子。不久前，《智能涌現(xiàn)》也曾對Manus進行測評，哪怕只是寫一篇簡單的新聞，Manus很容易就需要調(diào)用十多種工具，比如開啟瀏覽器，瀏覽和抓取網(wǎng)頁、進行寫作、驗證和交付最終結(jié)果。

在每個環(huán)節(jié)里，如果Manus選擇要調(diào)用外部工具，那么就需要編寫一個“函數(shù)”，用來安排外部的工具如何運行。結(jié)果就是，Manus常常因為任務(wù)過載而中止任務(wù)，也是因為單個任務(wù)所消耗的Token太多了。

但在MCP之后，最核心的轉(zhuǎn)變就是：開發(fā)者不需要對外部工具的性能負責(zé)，只需要對應(yīng)用本身做維護和調(diào)試，大大減少了開發(fā)工作量。

相對應(yīng)的，生態(tài)中的一個個單點Server，則會維護好自己的MCP服務(wù)——比如支付寶、高德地圖等等應(yīng)用方，維護好自己的MCP服務(wù)器，更新到最新版本，等待開發(fā)者來接入即可。

不過，MCP生態(tài)還相當早，現(xiàn)在也遠不是一個完美方案。已經(jīng)有不少開發(fā)者表示，MCP有點為建標準而建——API也許是更簡潔的方案。而如果MCP服務(wù)器并非官方推出，也沒有人精心維護，那么接入MCP的的安全性、服務(wù)穩(wěn)定性也不容樂觀。

盡管如此，MCP可以說是第一個真正意義上爆火出圈的調(diào)用工具協(xié)議，它的效應(yīng)也在快速顯現(xiàn)。據(jù)MCP社區(qū)PulseMCP統(tǒng)計，全球已經(jīng)有超過4000個MCP服務(wù)器上線，而這一數(shù)字還在迅速增長中。

但在MCP之后，最核心的轉(zhuǎn)變就是：開發(fā)者不需要對外部工具的性能負責(zé)，只需要對應(yīng)用本身做維護和調(diào)試，大大減少了開發(fā)工作量。

相對應(yīng)的，生態(tài)中的一個個單點Server，則會維護好自己的MCP服務(wù)——比如支付寶、高德地圖等等應(yīng)用方，維護好自己的MCP服務(wù)器，更新到最新版本，等待開發(fā)者來接入即可。

聽上去很理想，但MCP生態(tài)還相當早，現(xiàn)在也遠不是一個完美方案。

已經(jīng)有不少開發(fā)者表示，MCP有點為了建立標準而建——在那之前，API已經(jīng)是更簡潔的方案了，大模型也已經(jīng)可以通過很多協(xié)議調(diào)用API，MCP有一種畫蛇添足之感。

現(xiàn)在大公司們發(fā)布的MCP服務(wù)，基本都由廠商自己定義，可以被LLM調(diào)用什么功能，以什么樣的方式調(diào)度。但同樣的問題也會出現(xiàn)在MCP上——大公司很大概率不會把最核心、最實時的信息給你。

而如果MCP服務(wù)器并非官方推出，也沒有人精心維護，那么接入MCP的的安全性、服務(wù)穩(wěn)定性也不容樂觀。

獨立開發(fā)者唐霜就分享了自己遇到的案例：某度地圖的MCP Server，工具不足20個，有5個要求傳入經(jīng)緯度，再來一個查天氣，要求用戶提供行政區(qū)劃ID來查詢天氣，但卻沒有提供如何獲取這些ID的方法或文檔。解決方案只能是用戶回到這一服務(wù)商的生態(tài)中，按部就班獲取信息與權(quán)限

如此看來，MCP的爆火只是表面，但背后的博弈遠未結(jié)束——大模型廠商雖愿意提供MCP服務(wù)，但主動權(quán)仍然抓在廠商手中，沒有人愿意為Anthropic的生態(tài)做嫁衣。如果沒有心思好好提供服務(wù)，開發(fā)者反倒要做雙倍的工作，這個生態(tài)的邏輯也不會存在。

開放路線的再一次勝利

不過，為什么MCP現(xiàn)在才火起來？

在Anthropic剛推出MCP協(xié)議的初期，其實關(guān)注者寥寥。當時，只有有限的應(yīng)用支持MCP協(xié)議，比如Anthropic自家的Claude Desktop。開發(fā)者們也沒有形成一個統(tǒng)一的AI開發(fā)生態(tài)，基本屬于各自閉門造車的狀態(tài)。

是因為開發(fā)者群體的接納，MCP才開始慢慢走到舞臺中心。2025年2月開始，AI編程領(lǐng)域的一眾明星應(yīng)用——包括Cursor、VSCode、Cline等等，紛紛宣布支持MCP協(xié)議，這讓MCP協(xié)議聲名鵲起。

在開發(fā)者群體中掀起聲浪之后，真正引爆MCP協(xié)議的，是大模型廠商們的接入。

關(guān)鍵性的一步，無疑是3月27日，OpenAI宣布支持MCP協(xié)議，緊隨其后的則是Google。

Google CEO 桑達爾·皮查伊曾在X上表達過對MCP的糾結(jié)。3月31日，他發(fā)了條推特，表示：“接入MCP還是不接入MCP，這是個問題。”但發(fā)完這條推特短短4天后，Google也宣布接入MCP。

△X（Twitter）

大廠們最終都選擇擁抱MCP，這和DeepSeek沖擊硅谷的故事異曲同工：接入MCP，本質(zhì)上也是大模型廠商在生態(tài)戰(zhàn)略上的轉(zhuǎn)向——與其各自為政，不如求同存異，擁抱一套更開放的協(xié)議，集體把蛋糕做大。

過去兩年中，大模型廠商在AI戰(zhàn)略的布局上，往往都還是想圈占地盤為主。這個邏輯和互聯(lián)網(wǎng)的發(fā)展歷史別無二致，比如蘋果，成為平臺廠商，建立起強大的開發(fā)者生態(tài)，而非單純提供單點的產(chǎn)品服務(wù)，才能逐步建立起壟斷性的優(yōu)勢。

OpenAI也是學(xué)著蘋果這么做的。

在接入MCP協(xié)議之前，OpenAI開發(fā)者生態(tài)的路線，總體從開放逐漸走向封閉。ChatGPT Plugins在2023年3月上線，當時的Plugins，還允許第三方開發(fā)者為ChatGPT添加特定功能，也支持同時使用多個插件，是一個較為開放的擴展生態(tài)系統(tǒng)。

但在2024年1月推出GPTs及商店后，OpenAI很快終止了Plugins的服務(wù)。GPTs被設(shè)計成一個更封閉的商店模式——GPTs只能在OpenAI平臺上運行，從模型到應(yīng)用全部由OpenAI控制，通過平臺抽成獲利。而開發(fā)者也需要針對ChatGPT這一個平臺開發(fā)，開放程度相當有限。

截至目前，OpenAI的GPTs生態(tài)效果并不如人意，商店中充斥著大量低質(zhì)的簡單套殼應(yīng)用，商業(yè)化閉環(huán)也遠未跑通。

Anthropic的MCP協(xié)議，很多思路也并非行業(yè)首創(chuàng)。OpenAI推出的Function Calling，其實同樣是大模型調(diào)用外部工具的一個主流標準，MCP的許多技術(shù)思路，也和Function Calling一脈相承。

但MCP在產(chǎn)品層面做得更用戶友好。Function Calling的問題在于，開發(fā)者還需要做二次編程和大量的適配工作，但MCP讓服務(wù)方將這些需求打包成一個個的“樂高積木”，大大降低了AI應(yīng)用的開發(fā)門檻。

而且，MCP還擁有一個最核心的優(yōu)勢：它更開放、抽象程度更高。MCP只是一個網(wǎng)絡(luò)協(xié)議，并且沒有對底層的模型作限制，任何AI模型或平臺，都可以基于MCP進行交互，也適用于云端或本地的多種部署形式。

MCP足夠開放，也并不會讓任何一家大廠獨大，這大廠們都能找到一個比較舒服的位置和心態(tài)，接入這套協(xié)議。

某種程度上，這也是Anthropic用更開放的姿態(tài)，以奪回開發(fā)者生態(tài)的嘗試——OpenAI的封閉戰(zhàn)略，則再一次被證明是戰(zhàn)略上的誤判。對于仍處早期的前沿科技行業(yè)而言，從DeepSeek到如今的MCP，無一不告訴我們：開放、開源的路線，依舊是當下的最優(yōu)解。