當(dāng)下AI領(lǐng)域最炙手可熱的概念，莫過(guò)于MCP。MCP 指的是Model Context Protocol（模型上下文協(xié)議）。令人意外的是，一個(gè)協(xié)議系統(tǒng)的熱度，甚至蓋過(guò)了OpenAI發(fā)布的最新模型，成為行業(yè)討論的焦點(diǎn)。

隨著Manus的爆火，全球開(kāi)發(fā)者對(duì)Agent技術(shù)的熱情空前高漲。MCP作為Agent工具調(diào)用的“統(tǒng)一協(xié)議”，短短兩個(gè)月內(nèi)即獲得了OpenAI、Google等主要AI公司的支持，從一個(gè)邊緣技術(shù)規(guī)范一躍成為AI生態(tài)的底層標(biāo)準(zhǔn)。

它的崛起速度之快，堪稱AI基礎(chǔ)設(shè)施領(lǐng)域的“現(xiàn)象級(jí)事件”。而開(kāi)發(fā)者社區(qū)也涌現(xiàn)出各種MCP服務(wù)，仿佛它已是AI工具調(diào)用的“終極答案”。

然而，當(dāng)最初的狂熱稍退，我們不得不面對(duì)更復(fù)雜的問(wèn)題：MCP真的適用于所有場(chǎng)景嗎？它是否被賦予了過(guò)高的期待？

本文將從MCP的起源出發(fā)，剖析其核心價(jià)值與局限性，澄清常見(jiàn)誤解，并探討它的未來(lái)發(fā)展方向。我們的目的并非否定MCP的價(jià)值，而是希望回歸理性——只有明確它的實(shí)際定位和適用邊界，才能真正發(fā)揮它的潛力。畢竟，技術(shù)史上從不缺少“神話”，而真正的進(jìn)步，往往始于祛魅之后的清醒認(rèn)知。

一、MCP的本質(zhì)：統(tǒng)一的工具調(diào)用協(xié)議

1. 什么是MCP？

MCP是一種開(kāi)放的技術(shù)協(xié)議，旨在標(biāo)準(zhǔn)化大型語(yǔ)言模型（LLM）與外部工具和服務(wù)的交互方式。你可以把MCP理解成像是一個(gè)AI世界的通用翻譯官，讓AI模型能夠與各種各樣的外部工具"對(duì)話"。

2. 為什么需要MCP？

在MCP出現(xiàn)之前，AI工具調(diào)用面臨兩大痛點(diǎn)：

• 第一是接口碎片化：每個(gè)LLM使用不同的指令格式，每個(gè)工具API也有獨(dú)特的數(shù)據(jù)結(jié)構(gòu)，開(kāi)發(fā)者需要為每個(gè)組合編寫定制化連接代碼；
• 第二是開(kāi)發(fā)低效：這種"一對(duì)一翻譯"模式成本高昂且難以擴(kuò)展，就像為每個(gè)外國(guó)客戶雇傭?qū)俜g。

而MCP則采用了一種通用語(yǔ)言格式（JSON - RPC），一次學(xué)習(xí)就能與所有支持這種協(xié)議的工具進(jìn)行交流。一個(gè)通用翻譯器，不管什么LLM，用上它就能使用工具 / 數(shù)據(jù)了。

這就是MCP的全部功能。

2. MCP的工作原理

MCP的技術(shù)架構(gòu)可以簡(jiǎn)單理解為一個(gè)由三個(gè)核心部分組成的系統(tǒng)：MCP Host、MCP Client和MCP Server。這三部分共同工作，讓AI模型能夠順暢地與外部世界交流。

要準(zhǔn)確理解MCP的角色，我們可以將其比作現(xiàn)代企業(yè)環(huán)境中的一個(gè)通信系統(tǒng)。

在這個(gè)比喻中，用戶扮演著企業(yè)高管的角色，負(fù)責(zé)理解用戶需求并做出最終決策。，大模型（如Claude或GPT）理解高管的指令，規(guī)劃任務(wù)步驟，判斷何時(shí)需要使用哪些外部服務(wù)，并最終整合信息為高管提供答案。Agent系統(tǒng)則是真正的私人助理或執(zhí)行秘書去執(zhí)行，而MCP則像是秘書使用的標(biāo)準(zhǔn)化通信平臺(tái)或企業(yè)服務(wù)接入系統(tǒng)，它不做決策，只負(fù)責(zé)按照秘書的指示，以統(tǒng)一的格式和協(xié)議與各種服務(wù)提供商交流。

在MCP出現(xiàn)之前，AI與外部工具的交互就像是處在通信標(biāo)準(zhǔn)混亂的時(shí)代。每當(dāng)秘書（Agent）需要聯(lián)系不同部門或外部供應(yīng)商時(shí)，都必須使用不同的通信設(shè)備或軟件：給財(cái)務(wù)部打電話需要座機(jī)，聯(lián)系IT部門需要用Slack，預(yù)訂會(huì)議室要用Outlook，訂餐則需要使用外賣App。每個(gè)系統(tǒng)都有不同的操作界面、不同的數(shù)據(jù)格式和不同的通信協(xié)議，秘書必須熟悉所有這些不同的系統(tǒng)才能高效工作。對(duì)開(kāi)發(fā)者而言，這意味著為每個(gè)工具單獨(dú)編寫連接代碼，既費(fèi)時(shí)又缺乏可擴(kuò)展性。

MCP的出現(xiàn)改變了這一局面。它就像是一個(gè)統(tǒng)一的企業(yè)通信平臺(tái)，無(wú)論秘書需要聯(lián)系哪個(gè)部門或服務(wù)商，都可以使用同一個(gè)系統(tǒng)，遵循同一套通信協(xié)議。

MCP的技術(shù)架構(gòu)由三個(gè)核心組件構(gòu)成：

• MCP Host （執(zhí)行環(huán)境） 就像是企業(yè)的辦公環(huán)境和基礎(chǔ)設(shè)施。它提供了高管辦公和秘書工作的場(chǎng)所，是一切活動(dòng)的發(fā)生地。在實(shí)際應(yīng)用中，Claude Desktop、Cursor這類AI應(yīng)用就是典型的Host，它們提供了用戶與AI交互的界面和環(huán)境，同時(shí)也為Agent和MCP Client提供了運(yùn)行空間。
• MCP Client （通信樞紐） 像是秘書（Agent）使用的標(biāo)準(zhǔn)化供應(yīng)商。它不參與決策，不理解任務(wù)本質(zhì)，只負(fù)責(zé)按照秘書的指示，以正確的格式和協(xié)議與各種服務(wù)提供商通信。MCP Client是一個(gè)純技術(shù)組件，處理通信協(xié)議、數(shù)據(jù)格式轉(zhuǎn)換和連接管理等底層問(wèn)題。
• MCP Server （服務(wù)終端） 就像是各個(gè)專業(yè)部門或外部服務(wù)提供商，每一個(gè)都負(fù)責(zé)特定類型的服務(wù)。有的提供數(shù)據(jù)分析（如財(cái)務(wù)部），有的提供信息檢索（如資料室），還有的提供內(nèi)容生成（如市場(chǎng)部）。在MCP架構(gòu)中，每個(gè)Server提供特定類型的功能：工具、資源或提示。

在MCP出現(xiàn)之前，當(dāng)秘書需要完成高管的多項(xiàng)任務(wù)時(shí)，必須切換使用多種通信工具和系統(tǒng)，熟悉各自不同的操作方式。例如，預(yù)訂會(huì)議室需要登錄內(nèi)部系統(tǒng)A，獲取財(cái)報(bào)需要使用系統(tǒng)B，訂餐則需要撥打餐廳電話。開(kāi)發(fā)者則需要為每個(gè)工具單獨(dú)編寫連接代碼，效率低下且難以維護(hù)。

在MCP之后，秘書只需使用一個(gè)統(tǒng)一的通信平臺(tái)，就能以相同的方式聯(lián)系所有部門和服務(wù)提供商。開(kāi)發(fā)者也只需實(shí)現(xiàn)一次MCP接口，就能讓AI系統(tǒng)與所有支持該協(xié)議的工具進(jìn)行交互。

3. MCP不是Function Call的替代，而是基于Function Call的工具箱

很多人認(rèn)為，MCP是對(duì)傳統(tǒng)Function Call的一種替代。

而實(shí)際上，兩者并非替代關(guān)系，而是緊密合作的關(guān)系。

Function Call是大型語(yǔ)言模型（LLM）與外部工具或API交互的核心機(jī)制。它是大模型的一個(gè)基礎(chǔ)能力，就是識(shí)別什么時(shí)候要工具，可能需要啥類型的工具的能力。

而MCP則是工具分類的箱子。因此MCP不是要取代Function Call，而是在Function Call基礎(chǔ)上，聯(lián)合Agent一起去完成復(fù)雜任務(wù)。

如果把整個(gè)工具調(diào)用的流程剖析開(kāi)來(lái)，實(shí)際是"Function Call + Agent + MCP系統(tǒng)"的組合。

用一句話說(shuō)清楚：大模型通過(guò)FunctionCall表達(dá)，我要調(diào)用什么工具，Agent遵循指令執(zhí)行工具的調(diào)用，而MCP則是提供了一種統(tǒng)一的工具調(diào)用規(guī)范。

用一個(gè)比喻來(lái)理解：老板（用戶）要喝咖啡，于是，在辦公室（MCP Host）里，辦公室主任（大模型）吩咐秘書（Agent）去買一杯美式（Function Call）。秘書（Agent）查了一下供應(yīng)商名冊(cè)，發(fā)現(xiàn)美式咖啡的供應(yīng)商已接入了美團(tuán)或公司統(tǒng)一采購(gòu)系統(tǒng)（實(shí)現(xiàn)了MCP Server），接著，秘書在采購(gòu)系統(tǒng)中找到供應(yīng)商（MCP Client）一鍵下單。

在過(guò)去沒(méi)有MCP時(shí)，大模型下發(fā)Function Call，Agent去執(zhí)行翻譯，直接連接到API去調(diào)用工具。因此，你得為每個(gè)API單獨(dú)設(shè)置對(duì)應(yīng)的調(diào)用模式，去單獨(dú)定義工具列表和調(diào)用模式，這樣Agent才知道怎么去翻譯。而有了MCP后，只是很多API都可以直接通過(guò)供應(yīng)商MCP Client一鍵下單了，Agent省力了。但大模型的Function Call沒(méi)有任何變化。還是{tool: “買加啡”, "type": "美式"}這個(gè)形式。

不過(guò)在過(guò)去，有人會(huì)把這一整套Function Call+ Agent +API的模式叫做一個(gè)Function Calling，所以會(huì)引起混淆。

通過(guò)區(qū)分Function Call和MCP，我們可以清晰地看出，MCP并不負(fù)責(zé)決定使用哪個(gè)工具，也不進(jìn)行任務(wù)規(guī)劃或理解用戶意圖。這些是Agent層面的工作。MCP只是提供了一個(gè)統(tǒng)一的工具接口，成為了產(chǎn)業(yè)內(nèi)認(rèn)可的工具調(diào)用標(biāo)準(zhǔn)協(xié)議。

二、MCP的開(kāi)發(fā)難題與市場(chǎng)亂局

1. 一宗罪：開(kāi)發(fā)的難題

今年2月以來(lái)，AI開(kāi)發(fā)社區(qū)掀起了一場(chǎng)"MCP淘金熱"。在沒(méi)有官方應(yīng)用商店的情況下，短短三個(gè)月就有數(shù)千個(gè)工具自發(fā)接入MCP協(xié)議。

這僅僅是一家MCP Server集成網(wǎng)站的量就超過(guò)一萬(wàn)種。這種野蠻生長(zhǎng)讓MCP迅速成為行業(yè)焦點(diǎn)，但也暴露了理想與現(xiàn)實(shí)之間的鴻溝——開(kāi)發(fā)者們最初將MCP視為"萬(wàn)能鑰匙"，實(shí)際使用后卻發(fā)現(xiàn)它更像是"專業(yè)扳手"，在某些場(chǎng)景下表現(xiàn)出色，在其他場(chǎng)合卻顯得水土不服。

在MCP的所有參與者中，可以分為本地客戶端應(yīng)用、云端客戶端應(yīng)用和MCP服務(wù)端開(kāi)發(fā)者。本地應(yīng)用就是類似本地的AI助手，云端客戶端則是類似于ChatGPT的網(wǎng)頁(yè)版，而MCP服務(wù)器開(kāi)發(fā)者，則是工具的真正供給方。他們需要把自由的API重新做一遍符合MCP規(guī)則的包裝盒接入。在MCP剛剛上線的時(shí)間內(nèi)，最開(kāi)心的是本地客戶端應(yīng)用，而云端客戶端應(yīng)用和MCP服務(wù)器開(kāi)發(fā)者就不太舒服了。要理解這一點(diǎn)，得回到MCP的緣起。

MCP的起源始于Anthropic的Claude Desktop應(yīng)用，它最初是為了調(diào)用本地文件和功能而設(shè)計(jì)的接口協(xié)議，深深植根于客戶端的需求土壤中。

因此對(duì)于本地客戶端用戶來(lái)說(shuō)，MCP是一場(chǎng)革命，它提供了無(wú)限擴(kuò)充的工具箱，允許用戶不斷擴(kuò)展AI助手的能力邊界。本文作者Kongjie認(rèn)為，"對(duì)于桌面端Agent來(lái)講，這個(gè)MCP用起來(lái)其實(shí)會(huì)很爽很順，因?yàn)槭菫樗可矶ㄗ龅墓ぞ摺?

所以本地客戶端應(yīng)用如Cursor和Claude Desktop在使用MCP方面大放異彩，它們利用MCP讓用戶能夠根據(jù)個(gè)人需求動(dòng)態(tài)添加工具，實(shí)現(xiàn)了AI助手能力的無(wú)限擴(kuò)展。

它解決了本地客戶端開(kāi)發(fā)中的一個(gè)核心痛點(diǎn)：如何讓AI應(yīng)用能夠與本地環(huán)境和外部工具無(wú)縫交互，而無(wú)需為每個(gè)工具單獨(dú)開(kāi)發(fā)接口。這種統(tǒng)一的協(xié)議極大地降低了整合成本，特別是對(duì)于小型創(chuàng)業(yè)公司和個(gè)人開(kāi)發(fā)者，MCP提供了在有限資源條件下構(gòu)建功能豐富AI應(yīng)用的捷徑。

然而，當(dāng)我們將目光轉(zhuǎn)向服務(wù)端開(kāi)發(fā)（MCP Server）和云端客戶端時(shí)，MCP的光芒開(kāi)始黯淡。MCP早期對(duì)于云端服務(wù)器（remote）采用了一種雙鏈接機(jī)制，一條是SSE的長(zhǎng)鏈接，單向的從服務(wù)端到客戶端的推送消息用，還有另一條發(fā)消息的http常規(guī)請(qǐng)求短鏈接。

這種方法對(duì)用戶及時(shí)反饋和中途干預(yù)來(lái)講效果很好，這種需要服務(wù)器處理的環(huán)境中創(chuàng)造了一系列工程挑戰(zhàn)。

MCP Host 和 MCP Server信息溝通是雙向的。首先，對(duì)于大型企業(yè)服務(wù)提供商，實(shí)現(xiàn)MCP接口意味著額外的工作負(fù)擔(dān)，而這些工作可能并不帶來(lái)相應(yīng)的回報(bào)。由于這些服務(wù)通常已經(jīng)有成熟的API體系，再額外提供MCP適配層往往只是增加了維護(hù)成本，而非創(chuàng)造實(shí)質(zhì)性價(jià)值。事實(shí)上，許多企業(yè)級(jí)應(yīng)用更傾向于使用封閉、可控的工具調(diào)用機(jī)制，而非MCP倡導(dǎo)的開(kāi)放式生態(tài)系統(tǒng)。

而且對(duì)于這些大型企業(yè)服務(wù)供應(yīng)商來(lái)講，為了應(yīng)對(duì)高并發(fā)調(diào)用，MCP服務(wù)往往需要擴(kuò)展到多服務(wù)器架構(gòu)。此時(shí)，MCP的雙連接模型引入了跨機(jī)器尋址的復(fù)雜性。當(dāng)長(zhǎng)連接建立在一臺(tái)服務(wù)器上，而請(qǐng)求可能被路由到另一臺(tái)服務(wù)器時(shí)，就需要額外的廣播隊(duì)列機(jī)制來(lái)協(xié)調(diào)這些分散的連接，大大增加了實(shí)施難度和維護(hù)成本。

其次，在云端應(yīng)用領(lǐng)域，MCP也有很大的局限性。云端AI Agent（服務(wù)端Agent）通常運(yùn)行在無(wú)狀態(tài)的服務(wù)中，任務(wù)接受之后它進(jìn)行處理，結(jié)束后便釋放資源。在服務(wù)端使用MCP Client時(shí)需要臨時(shí)創(chuàng)建一個(gè)SSE鏈接，發(fā)送工具調(diào)用請(qǐng)求，從SSE獲得結(jié)果再關(guān)閉掉SSE鏈接，實(shí)在是屬于一種很雞肋的做法，復(fù)雜度增加了，性能也下降了，而這種場(chǎng)景下，理應(yīng)只需要一個(gè)單次的RPC請(qǐng)求就解決問(wèn)題。

實(shí)際上云端應(yīng)用在用MCP時(shí)，大多還是用的預(yù)設(shè)的工具集，而沒(méi)有用到MCP的招牌能力——?jiǎng)討B(tài)工具發(fā)現(xiàn)和靈活加載功能。

Kongjie認(rèn)為，"云端本身的數(shù)據(jù)交互模式，導(dǎo)致雖然MCP希望能達(dá)成工具的自由使用，但實(shí)際上用不上。還是必須用非常規(guī)范的流程去調(diào)用特定的寫死的工具，喪失了靈活性的初衷。"

值得稱贊的是，MCP團(tuán)隊(duì)對(duì)用戶反饋保持開(kāi)放態(tài)度。在收到服務(wù)端開(kāi)發(fā)者的反饋后，MCP在3月26號(hào)更新了協(xié)議，使用streamable HTTP的transport替代了原來(lái)的SSE transport。這樣一來(lái)，新的協(xié)議既支持僅需要單次調(diào)用工具請(qǐng)求的無(wú)狀態(tài)服務(wù)場(chǎng)景，也兼容了原來(lái)通過(guò)http + SSE 雙鏈接才能滿足的實(shí)時(shí)推送的訴求。

這說(shuō)明，當(dāng)下的一些MCP的問(wèn)題，源于其最初目的的限制，但并非不可解。

2. 二宗罪：市場(chǎng)的亂局

另一個(gè)MCP面對(duì)的問(wèn)題可能就比較普遍了：現(xiàn)在市面上的MCP可用性太低。

當(dāng)前MCP市場(chǎng)正經(jīng)歷著典型的技術(shù)炒作周期。就像當(dāng)年App Store剛上線時(shí)的混亂景象，如今數(shù)千個(gè)MCP工具中，真正具備實(shí)用價(jià)值的不足二成。騰訊開(kāi)發(fā)者victor的觀察一針見(jiàn)血：“很多MCP，實(shí)際上都沒(méi)有真的做MCP。”

victor表示，他試用了300多個(gè)MCP項(xiàng)目，但約有80%的MCP服務(wù)器存在嚴(yán)重問(wèn)題，從簡(jiǎn)單的配置錯(cuò)誤到完全無(wú)法使用的情況不等。這些工具有的是因急于上線而未經(jīng)充分測(cè)試，有的則是開(kāi)發(fā)者實(shí)驗(yàn)性質(zhì)的產(chǎn)物，從未打算投入實(shí)際使用。

而更嚴(yán)重的問(wèn)題是，其中大部分MCP可能市場(chǎng)根本就不需要。如Kong所言："真正有用的，能夠繼續(xù)解決問(wèn)題的那些工具本來(lái)在當(dāng)它還是一個(gè)API的時(shí)候，別人也去用了。然后現(xiàn)在大家發(fā)現(xiàn)MCP有市場(chǎng)，就做了一個(gè)簡(jiǎn)單封裝，但它本來(lái)沒(méi)有什么特別的用。"

比如說(shuō)現(xiàn)在MCP提供的搜索服務(wù)可能就有數(shù)十家之多。而在《Evaluation Report on MCP Servers》論文中，作者對(duì)此類服務(wù)做了一些評(píng)測(cè)，發(fā)現(xiàn)水平差異非常大。其中像Exa Search又不準(zhǔn)，時(shí)間又差。如果有最好的Bing Web Search，誰(shuí)會(huì)用它呢？

而且，現(xiàn)在MCP也缺乏評(píng)價(jià)體系。這導(dǎo)致Agent無(wú)法依靠可靠的指標(biāo)來(lái)選擇最適合的工具，只能通過(guò)反復(fù)嘗試或基于模糊的描述做出決策。這種低效的選擇過(guò)程不僅浪費(fèi)計(jì)算資源，還延長(zhǎng)了任務(wù)完成時(shí)間，降低了用戶體驗(yàn)。

據(jù)Kong表示，“如果選了多個(gè)MCP服務(wù)，其中重名，描述相似的工具太多，Agent不知道選哪個(gè)，也沒(méi)有排名。只能一個(gè)個(gè)試，很浪費(fèi)token，也效率很低。”

因此，那些最成功的AI應(yīng)用往往采取了相反的路徑——它們不是提供更多的工具，而是提供更精準(zhǔn)的工具。比如Manus，在MCP已經(jīng)存在的情況下，其實(shí)根本沒(méi)有采用這一協(xié)議，而是選擇內(nèi)建應(yīng)用。因?yàn)樗挥袔资N工具，為了提高調(diào)用準(zhǔn)確度和穩(wěn)定性，不如自己去單獨(dú)寫。

而Cursor這樣的代碼編輯器已經(jīng)內(nèi)置了最常用的開(kāi)發(fā)功能，使得大多數(shù)外部MCP工具顯得多余。在作者使用Cursor時(shí)，雖然開(kāi)啟了幾十個(gè)MCP，但真正能用到的鳳毛麟角。

但MCP市場(chǎng)當(dāng)前的混亂狀態(tài)并非失敗的標(biāo)志，而是任何新興技術(shù)生態(tài)系統(tǒng)必經(jīng)的成長(zhǎng)階段。

從歷史經(jīng)驗(yàn)來(lái)看，這種初期的過(guò)度膨脹往往會(huì)通過(guò)市場(chǎng)自然選擇機(jī)制逐漸收斂，留下真正有價(jià)值的部分。就像互聯(lián)網(wǎng)泡沫之后留下了改變世界的電子商務(wù)和社交媒體一樣，MCP熱潮過(guò)后可能會(huì)形成一個(gè)更加精簡(jiǎn)但更有實(shí)質(zhì)價(jià)值的工具生態(tài)系統(tǒng)。

這個(gè)過(guò)程中，至少Anthropic團(tuán)隊(duì)也能從善如流，像victor建議的那樣“在協(xié)議規(guī)范上，要求接入?yún)f(xié)議的服務(wù)能保證參數(shù)和工具的質(zhì)量。”這樣才能讓MCP的生態(tài)變得真正“可用”。

三、MCP很好，但它不是萬(wàn)靈藥

以上兩種MCP體驗(yàn)的批評(píng)，確實(shí)來(lái)自于MCP自身的限制和短板。也是其能力可完成的范圍。但在當(dāng)前，還有一類對(duì)MCP的批評(píng)，明顯是由于人們對(duì)它賦予了不太恰當(dāng)?shù)钠诖?/p>

在近期一篇大火的MCP批判文章中，作者認(rèn)為，MCP就是一個(gè)殘缺的協(xié)議，因?yàn)樗鼪](méi)有規(guī)定大語(yǔ)言模型和MCP的交互模式。

很多人期待MCP能夠一勞永逸的自動(dòng)改善AI系統(tǒng)的決策能力，或者提升任務(wù)規(guī)劃的效率。但這種訴求實(shí)際上是在錯(cuò)誤地將工具與工匠混為一談。

因此，當(dāng)前對(duì)MCP的批評(píng)存在一個(gè)根本性的認(rèn)知錯(cuò)位——人們期待一個(gè)通信協(xié)議能完成智能系統(tǒng)的全部工作。這就像指責(zé)USB接口不能自動(dòng)修圖，或是埋怨5G標(biāo)準(zhǔn)不會(huì)編寫代碼。MCP本質(zhì)上只是一套"工具插座"的標(biāo)準(zhǔn)規(guī)范，它的使命是確保插頭能順利插入，而非決定用哪個(gè)電器、怎么使用電器。

Agent調(diào)用工具的效果受到諸多因素制約——工具選擇能力、任務(wù)規(guī)劃能力、上下文理解能力——而這些能力的培養(yǎng)與提升，都不在MCP的職責(zé)范圍內(nèi)。MCP只承諾提供統(tǒng)一的工具接口，而不承諾這些工具將被如何選擇和組合。

在技術(shù)演進(jìn)的長(zhǎng)河中，我們總是傾向于尋找一勞永逸的解決方案，一種可以解決所有問(wèn)題的銀彈。但如同軟件工程中著名的"沒(méi)有銀彈"論斷，AI工具調(diào)用領(lǐng)域同樣不存在萬(wàn)能的解決方案。一個(gè)真正強(qiáng)大的AI系統(tǒng)需要多個(gè)精心設(shè)計(jì)的組件協(xié)同工作：大語(yǔ)言模型提供基礎(chǔ)理解和生成能力，Agent框架負(fù)責(zé)任務(wù)規(guī)劃和執(zhí)行邏輯，而MCP則專注于提供統(tǒng)一的工具調(diào)用接口。

它展示了良好的協(xié)議設(shè)計(jì)哲學(xué)——關(guān)注一個(gè)問(wèn)題并解決好它，而非嘗試解決所有問(wèn)題。正是這種克制，使得MCP能夠在客戶端工具集成領(lǐng)域取得實(shí)質(zhì)性進(jìn)展。

因此，不管是阿里的Qwen，還是百度的“心響”，字節(jié)的扣子空間，都擁抱了MCP協(xié)議，也試圖在內(nèi)部建立一個(gè)更高效的MCP生態(tài)空間。

雖然都有部署，但他們還是有比較明確的區(qū)別的，并非純粹“拿來(lái)主義”。

百度試圖從 C端切入， “心響”（Kokone）利用 MCP 協(xié)議整合多種 AI 模型和外部工具，主要面向手機(jī)端，目前仍只支持安卓系統(tǒng)，意圖將自身產(chǎn)品打入用戶的日常場(chǎng)景體驗(yàn)之中，培養(yǎng)用戶習(xí)慣。

而字節(jié)跳動(dòng)的扣子空間集成超過(guò) 60 款 MCP 擴(kuò)展插件，主要入口為網(wǎng)頁(yè)端，還推出了支持 MCP 的 AI 原生 IDE——Trae，主要瞄準(zhǔn)工作場(chǎng)景和生產(chǎn)力場(chǎng)景。

阿里在支付寶等產(chǎn)品中集成了 MCP 協(xié)議，實(shí)現(xiàn)了 AI 工具的一鍵調(diào)用，4 月 29 日開(kāi)源 Qwen3 系列模型也支持 MCP 協(xié)議，增強(qiáng)其Agent 能力。

騰訊云開(kāi)發(fā)者發(fā)布了AI開(kāi)發(fā)套件，支持MCP插件托管服務(wù)；騰訊云大模型知識(shí)引擎支持用戶調(diào)用MCP插件；騰訊云代碼助手CodeBuddy推出的Craft軟件開(kāi)發(fā)智能體，可兼容MCP開(kāi)放生態(tài)。另外，騰訊地圖、騰訊云存儲(chǔ)也發(fā)布了自己的MCP SERVER。

但正如編程范式從匯編語(yǔ)言進(jìn)化到面向?qū)ο笠粯樱珹I工具使用也可能從直接操作單一工具進(jìn)化到與專業(yè)化Agent的協(xié)作。

在這種新范式下，MCP可能只是底層基礎(chǔ)設(shè)施的一部分，而不是用戶或開(kāi)發(fā)者直接面對(duì)的界面。更全面的方案可能需要結(jié)合像Agent to Agents（A2A）這樣的架構(gòu)，通過(guò)抽象層次提高任務(wù)規(guī)劃和工具選擇的效率。

當(dāng)我們將MCP放回"協(xié)議"的本位，反而能看清其推動(dòng)行業(yè)標(biāo)準(zhǔn)化的真實(shí)力量——這或許才是技術(shù)演進(jìn)中最珍貴的"祛魅時(shí)刻"。