當下AI領域最炙手可熱的概念，莫過于MCP。MCP 指的是Model Context Protocol（模型上下文協議）。令人意外的是，一個協議系統的熱度，甚至蓋過了OpenAI發布的最新模型，成為行業討論的焦點。

隨著Manus的爆火，全球開發者對Agent技術的熱情空前高漲。MCP作為Agent工具調用的“統一協議”，短短兩個月內即獲得了OpenAI、Google等主要AI公司的支持，從一個邊緣技術規范一躍成為AI生態的底層標準。

它的崛起速度之快，堪稱AI基礎設施領域的“現象級事件”。而開發者社區也涌現出各種MCP服務，仿佛它已是AI工具調用的“終極答案”。

然而，當最初的狂熱稍退，我們不得不面對更復雜的問題：MCP真的適用于所有場景嗎？它是否被賦予了過高的期待？

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

一、MCP的本質：統一的工具調用協議

1. 什么是MCP？

MCP是一種開放的技術協議，旨在標準化大型語言模型（LLM）與外部工具和服務的交互方式。你可以把MCP理解成像是一個AI世界的通用翻譯官，讓AI模型能夠與各種各樣的外部工具"對話"。

2. 為什么需要MCP？

在MCP出現之前，AI工具調用面臨兩大痛點：

• 第一是接口碎片化：每個LLM使用不同的指令格式，每個工具API也有獨特的數據結構，開發者需要為每個組合編寫定制化連接代碼；
• 第二是開發低效：這種"一對一翻譯"模式成本高昂且難以擴展，就像為每個外國客戶雇傭專屬翻譯。

而MCP則采用了一種通用語言格式（JSON - RPC），一次學習就能與所有支持這種協議的工具進行交流。一個通用翻譯器，不管什么LLM，用上它就能使用工具 / 數據了。

這就是MCP的全部功能。

2. MCP的工作原理

MCP的技術架構可以簡單理解為一個由三個核心部分組成的系統：MCP Host、MCP Client和MCP Server。這三部分共同工作，讓AI模型能夠順暢地與外部世界交流。

要準確理解MCP的角色，我們可以將其比作現代企業環境中的一個通信系統。

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

在MCP出現之前，AI與外部工具的交互就像是處在通信標準混亂的時代。每當秘書（Agent）需要聯系不同部門或外部供應商時，都必須使用不同的通信設備或軟件：給財務部打電話需要座機，聯系IT部門需要用Slack，預訂會議室要用Outlook，訂餐則需要使用外賣App。每個系統都有不同的操作界面、不同的數據格式和不同的通信協議，秘書必須熟悉所有這些不同的系統才能高效工作。對開發者而言，這意味著為每個工具單獨編寫連接代碼，既費時又缺乏可擴展性。

MCP的出現改變了這一局面。它就像是一個統一的企業通信平臺，無論秘書需要聯系哪個部門或服務商，都可以使用同一個系統，遵循同一套通信協議。

MCP的技術架構由三個核心組件構成：

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

在MCP出現之前，當秘書需要完成高管的多項任務時，必須切換使用多種通信工具和系統，熟悉各自不同的操作方式。例如，預訂會議室需要登錄內部系統A，獲取財報需要使用系統B，訂餐則需要撥打餐廳電話。開發者則需要為每個工具單獨編寫連接代碼，效率低下且難以維護。

在MCP之后，秘書只需使用一個統一的通信平臺，就能以相同的方式聯系所有部門和服務提供商。開發者也只需實現一次MCP接口，就能讓AI系統與所有支持該協議的工具進行交互。

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

很多人認為，MCP是對傳統Function Call的一種替代。

而實際上，兩者并非替代關系，而是緊密合作的關系。

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

而MCP則是工具分類的箱子。因此MCP不是要取代Function Call，而是在Function Call基礎上，聯合Agent一起去完成復雜任務。

如果把整個工具調用的流程剖析開來，實際是"Function Call + Agent + MCP系統"的組合。

用一句話說清楚：大模型通過FunctionCall表達，我要調用什么工具，Agent遵循指令執行工具的調用，而MCP則是提供了一種統一的工具調用規范。

用一個比喻來理解：老板（用戶）要喝咖啡，于是，在辦公室（MCP Host）里，辦公室主任（大模型）吩咐秘書（Agent）去買一杯美式（Function Call）。秘書（Agent）查了一下供應商名冊，發現美式咖啡的供應商已接入了美團或公司統一采購系統（實現了MCP Server），接著，秘書在采購系統中找到供應商（MCP Client）一鍵下單。

在過去沒有MCP時，大模型下發Function Call，Agent去執行翻譯，直接連接到API去調用工具。因此，你得為每個API單獨設置對應的調用模式，去單獨定義工具列表和調用模式，這樣Agent才知道怎么去翻譯。而有了MCP后，只是很多API都可以直接通過供應商MCP Client一鍵下單了，Agent省力了。但大模型的Function Call沒有任何變化。還是{tool: “買加啡”, "type": "美式"}這個形式。

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

通過區分Function Call和MCP，我們可以清晰地看出，MCP并不負責決定使用哪個工具，也不進行任務規劃或理解用戶意圖。這些是Agent層面的工作。MCP只是提供了一個統一的工具接口，成為了產業內認可的工具調用標準協議。

二、MCP的開發難題與市場亂局

1. 一宗罪：開發的難題

今年2月以來，AI開發社區掀起了一場"MCP淘金熱"。在沒有官方應用商店的情況下，短短三個月就有數千個工具自發接入MCP協議。

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

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

MCP的起源始于Anthropic的Claude Desktop應用，它最初是為了調用本地文件和功能而設計的接口協議，深深植根于客戶端的需求土壤中。

因此對于本地客戶端用戶來說，MCP是一場革命，它提供了無限擴充的工具箱，允許用戶不斷擴展AI助手的能力邊界。本文作者Kongjie認為，"對于桌面端Agent來講，這個MCP用起來其實會很爽很順，因為是為它量身定做的工具。"

所以本地客戶端應用如Cursor和Claude Desktop在使用MCP方面大放異彩，它們利用MCP讓用戶能夠根據個人需求動態添加工具，實現了AI助手能力的無限擴展。

它解決了本地客戶端開發中的一個核心痛點：如何讓AI應用能夠與本地環境和外部工具無縫交互，而無需為每個工具單獨開發接口。這種統一的協議極大地降低了整合成本，特別是對于小型創業公司和個人開發者，MCP提供了在有限資源條件下構建功能豐富AI應用的捷徑。

然而，當我們將目光轉向服務端開發（MCP Server）和云端客戶端時，MCP的光芒開始黯淡。MCP早期對于云端服務器（remote）采用了一種雙鏈接機制，一條是SSE的長鏈接，單向的從服務端到客戶端的推送消息用，還有另一條發消息的http常規請求短鏈接。

這種方法對用戶及時反饋和中途干預來講效果很好，這種需要服務器處理的環境中創造了一系列工程挑戰。

MCP Host 和 MCP Server信息溝通是雙向的。首先，對于大型企業服務提供商，實現MCP接口意味著額外的工作負擔，而這些工作可能并不帶來相應的回報。由于這些服務通常已經有成熟的API體系，再額外提供MCP適配層往往只是增加了維護成本，而非創造實質性價值。事實上，許多企業級應用更傾向于使用封閉、可控的工具調用機制，而非MCP倡導的開放式生態系統。

而且對于這些大型企業服務供應商來講，為了應對高并發調用，MCP服務往往需要擴展到多服務器架構。此時，MCP的雙連接模型引入了跨機器尋址的復雜性。當長連接建立在一臺服務器上，而請求可能被路由到另一臺服務器時，就需要額外的廣播隊列機制來協調這些分散的連接，大大增加了實施難度和維護成本。

其次，在云端應用領域，MCP也有很大的局限性。云端AI Agent（服務端Agent）通常運行在無狀態的服務中，任務接受之后它進行處理，結束后便釋放資源。在服務端使用MCP Client時需要臨時創建一個SSE鏈接，發送工具調用請求，從SSE獲得結果再關閉掉SSE鏈接，實在是屬于一種很雞肋的做法，復雜度增加了，性能也下降了，而這種場景下，理應只需要一個單次的RPC請求就解決問題。

實際上云端應用在用MCP時，大多還是用的預設的工具集，而沒有用到MCP的招牌能力——動態工具發現和靈活加載功能。

Kongjie認為，"云端本身的數據交互模式，導致雖然MCP希望能達成工具的自由使用，但實際上用不上。還是必須用非常規范的流程去調用特定的寫死的工具，喪失了靈活性的初衷。"

值得稱贊的是，MCP團隊對用戶反饋保持開放態度。在收到服務端開發者的反饋后，MCP在3月26號更新了協議，使用streamable HTTP的transport替代了原來的SSE transport。這樣一來，新的協議既支持僅需要單次調用工具請求的無狀態服務場景，也兼容了原來通過http + SSE 雙鏈接才能滿足的實時推送的訴求。

這說明，當下的一些MCP的問題，源于其最初目的的限制，但并非不可解。

2. 二宗罪：市場的亂局

另一個MCP面對的問題可能就比較普遍了：現在市面上的MCP可用性太低。

當前MCP市場正經歷著典型的技術炒作周期。就像當年App Store剛上線時的混亂景象，如今數千個MCP工具中，真正具備實用價值的不足二成。騰訊開發者victor的觀察一針見血：“很多MCP，實際上都沒有真的做MCP。”

victor表示，他試用了300多個MCP項目，但約有80%的MCP服務器存在嚴重問題，從簡單的配置錯誤到完全無法使用的情況不等。這些工具有的是因急于上線而未經充分測試，有的則是開發者實驗性質的產物，從未打算投入實際使用。

而更嚴重的問題是，其中大部分MCP可能市場根本就不需要。如Kong所言："真正有用的，能夠繼續解決問題的那些工具本來在當它還是一個API的時候，別人也去用了。然后現在大家發現MCP有市場，就做了一個簡單封裝，但它本來沒有什么特別的用。"

比如說現在MCP提供的搜索服務可能就有數十家之多。而在《Evaluation Report on MCP Servers》論文中，作者對此類服務做了一些評測，發現水平差異非常大。其中像Exa Search又不準，時間又差。如果有最好的Bing Web Search，誰會用它呢？

而且，現在MCP也缺乏評價體系。這導致Agent無法依靠可靠的指標來選擇最適合的工具，只能通過反復嘗試或基于模糊的描述做出決策。這種低效的選擇過程不僅浪費計算資源，還延長了任務完成時間，降低了用戶體驗。

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

因此，那些最成功的AI應用往往采取了相反的路徑——它們不是提供更多的工具，而是提供更精準的工具。比如Manus，在MCP已經存在的情況下，其實根本沒有采用這一協議，而是選擇內建應用。因為它只有幾十種工具，為了提高調用準確度和穩定性，不如自己去單獨寫。

而Cursor這樣的代碼編輯器已經內置了最常用的開發功能，使得大多數外部MCP工具顯得多余。在作者使用Cursor時，雖然開啟了幾十個MCP，但真正能用到的鳳毛麟角。

但MCP市場當前的混亂狀態并非失敗的標志，而是任何新興技術生態系統必經的成長階段。

從歷史經驗來看，這種初期的過度膨脹往往會通過市場自然選擇機制逐漸收斂，留下真正有價值的部分。就像互聯網泡沫之后留下了改變世界的電子商務和社交媒體一樣，MCP熱潮過后可能會形成一個更加精簡但更有實質價值的工具生態系統。

這個過程中，至少Anthropic團隊也能從善如流，像victor建議的那樣“在協議規范上，要求接入協議的服務能保證參數和工具的質量。”這樣才能讓MCP的生態變得真正“可用”。

三、MCP很好，但它不是萬靈藥

以上兩種MCP體驗的批評，確實來自于MCP自身的限制和短板。也是其能力可完成的范圍。但在當前，還有一類對MCP的批評，明顯是由于人們對它賦予了不太恰當的期待。

在近期一篇大火的MCP批判文章中，作者認為，MCP就是一個殘缺的協議，因為它沒有規定大語言模型和MCP的交互模式。

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

因此，當前對MCP的批評存在一個根本性的認知錯位——人們期待一個通信協議能完成智能系統的全部工作。這就像指責USB接口不能自動修圖，或是埋怨5G標準不會編寫代碼。MCP本質上只是一套"工具插座"的標準規范，它的使命是確保插頭能順利插入，而非決定用哪個電器、怎么使用電器。

Agent調用工具的效果受到諸多因素制約——工具選擇能力、任務規劃能力、上下文理解能力——而這些能力的培養與提升，都不在MCP的職責范圍內。MCP只承諾提供統一的工具接口，而不承諾這些工具將被如何選擇和組合。

在技術演進的長河中，我們總是傾向于尋找一勞永逸的解決方案，一種可以解決所有問題的銀彈。但如同軟件工程中著名的"沒有銀彈"論斷，AI工具調用領域同樣不存在萬能的解決方案。一個真正強大的AI系統需要多個精心設計的組件協同工作：大語言模型提供基礎理解和生成能力，Agent框架負責任務規劃和執行邏輯，而MCP則專注于提供統一的工具調用接口。

它展示了良好的協議設計哲學——關注一個問題并解決好它，而非嘗試解決所有問題。正是這種克制，使得MCP能夠在客戶端工具集成領域取得實質性進展。

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

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

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

而字節跳動的扣子空間集成超過 60 款 MCP 擴展插件，主要入口為網頁端，還推出了支持 MCP 的 AI 原生 IDE——Trae，主要瞄準工作場景和生產力場景。

阿里在支付寶等產品中集成了 MCP 協議，實現了 AI 工具的一鍵調用，4 月 29 日開源 Qwen3 系列模型也支持 MCP 協議，增強其Agent 能力。

騰訊云開發者發布了AI開發套件，支持MCP插件托管服務；騰訊云大模型知識引擎支持用戶調用MCP插件；騰訊云代碼助手CodeBuddy推出的Craft軟件開發智能體，可兼容MCP開放生態。另外，騰訊地圖、騰訊云存儲也發布了自己的MCP SERVER。

但正如編程范式從匯編語言進化到面向對象一樣，AI工具使用也可能從直接操作單一工具進化到與專業化Agent的協作。

在這種新范式下，MCP可能只是底層基礎設施的一部分，而不是用戶或開發者直接面對的界面。更全面的方案可能需要結合像Agent to Agents（A2A）這樣的架構，通過抽象層次提高任務規劃和工具選擇的效率。

當我們將MCP放回"協議"的本位，反而能看清其推動行業標準化的真實力量——這或許才是技術演進中最珍貴的"祛魅時刻"。