在當前的人工智慧領域，一個概念正引起廣泛關注：MCP，或稱模型上下文協議（Model Context Protocol）。令人驚訝的是，圍繞這個協議系統的關注甚至超越了 OpenAI 最新的模型發布，成為行業討論的焦點。
Agent 技術的興起，受到 Manus 崛起的推動，激發了全球開發者的熱情。MCP 被定位為 Agent 工具調用的「統一協議」，迅速獲得了發展動力，並在短短兩個月內獲得了 OpenAI 和 Google 等主要人工智慧參與者的支持。這種快速崛起將 MCP 從一個相對默默無聞的技術規範轉變為人工智慧生態系統中的基礎標準，標誌著人工智慧基礎設施領域的一個「非凡事件」。
然而，隨著最初的興奮消退，關鍵問題浮出水面：MCP 真的普遍適用嗎？對其能力的期望是否被誇大了？
本文將深入探討 MCP 的起源，剖析其核心優勢和局限性，澄清普遍存在的誤解，並檢視其潛在的未來發展軌跡。目的不是要否定 MCP 的內在價值，而是要促進對其角色和界限更為務實的理解。只有透過這種清晰的認識，其潛力才能得到充分實現。
揭開 MCP 的面紗：一個統一的工具調用協議
定義 MCP
MCP 是一種開放的技術協議，旨在標準化大型語言模型 (LLM) 與外部工具和服務互動的方式。可以把它想像成人工智慧世界中的一個通用翻譯器，使人工智慧模型能夠與各種外部工具「對話」。它為 LLM 提供了一種通用的語言和結構，以便請求和利用不同應用程式和服務提供的功能。
對 MCP 的需求
在 MCP 出現之前，人工智慧工具調用一直受到兩個主要挑戰的困擾：
- 介面碎片化： 每個 LLM 都採用不同的指令格式，而每個工具 API 都有其獨特的數據結構。開發人員被迫為每種組合編寫自定義連接代碼，導致開發過程複雜且效率低下。
- 開發效率低下： 這種「一對一翻譯」的方法被證明成本高昂且難以擴展。這就像為每個外國客戶聘請一名專職翻譯，阻礙了生產力和敏捷性。
MCP 透過提供一個標準化的框架，讓 LLM 與外部工具互動，簡化了開發過程並實現了更大的可擴展性，從而解決了這些痛點。
理解 MCP 的功能
MCP 的技術架構可以概念化為一個包含三個核心元件的系統：MCP 主機（MCP Host）、MCP 客戶端（MCP Client）和 MCP 伺服器（MCP Server）。這些元素協同工作，以促進人工智慧模型與外部世界之間的無縫通信。
為了理解 MCP 的作用，請考慮一個現代企業環境。在這個類比中：
- 使用者代表高階主管，負責理解使用者需求並做出最終決策。
- 大型語言模型 (LLM)（如 Claude 或 GPT）理解主管指令，規劃任務步驟，確定何時利用外部服務，並整合資訊以提供答案。
- Agent 系統充當私人助理或執行秘書，按照指示執行任務。
- MCP 充當秘書使用的標準化通信平台或企業服務存取系統。它不做出決策，而是遵循指示，以統一的格式和協議與各種服務提供商通信。
在 MCP 之前，人工智慧與外部工具的互動就像一個混亂的通信標準時代。每次秘書（Agent）需要聯絡不同的部門或外部供應商時，他們都必須使用不同的通信設備或軟體。這需要熟悉各種系統，導致效率低下。開發人員必須為每個工具編寫單獨的連接代碼，導致時間浪費和可擴展性受限。
MCP 透過提供一個統一的通信平台來簡化這個過程，允許秘書使用相同的系統和通信協議聯絡任何部門或服務提供商。開發人員只需要實施一次 MCP 介面，使人工智慧系統能夠與所有支持該協議的工具互動。
MCP：一個建立在函數調用之上的工具箱
至關重要的是要理解，MCP 不是傳統函數調用的替代品；相反，它是一個增強其功能的補充元件。
函數調用是 LLM 與外部工具或 API 互動的核心機制。這是 LLM 的一項基本能力，使它們能夠識別何時需要工具以及需要哪種類型的工具。
MCP 充當工具分類系統，提供一個結構化的框架，用於組織和存取各種工具。因此，MCP 不會取代函數調用，而是與 Agent 協同工作以完成複雜的任務。
完整的工具調用過程涉及「函數調用 + Agent + MCP 系統」的組合。
本質上，LLM 透過函數調用表達調用特定工具的需求。Agent 按照指示執行工具調用，而 MCP 提供標準化的工具調用規範。
考慮以下類比：老闆（使用者）想要咖啡。在辦公室（MCP 主機）中，辦公室經理（LLM）指示秘書（Agent）購買一杯美式咖啡（函數調用）。秘書檢查供應商列表，發現一家美式咖啡供應商已與美團或公司統一採購系統（已實施 MCP 伺服器）整合。然後，秘書在採購系統（MCP 客戶端）中找到供應商並下訂單。
以前，如果沒有 MCP，當 LLM 發出函數調用時，Agent 會翻譯並直接連接到 API 以調用該工具。每個 API 都需要單獨的調用模式，並且需要為 Agent 解釋定義的工具列表和調用模式。透過 MCP，許多 API 可以直接透過供應商的 MCP 客戶端訂購，從而節省 Agent 的時間和精力。但是，LLM 的函數調用保持不變，仍然是 {tool: ‘buy coffee’, ‘type’: ‘Americano’} 格式。
透過區分函數調用和 MCP，可以清楚地看到，MCP 不決定使用哪個工具，也不處理任務規劃或使用者意圖。這些方面屬於 Agent 層的範圍。MCP 僅提供統一的工具介面，成為業界公認的標準協議。
MCP 的開發挑戰和市場前景
開發難題
自二月份以來，人工智慧開發社群目睹了一場「MCP淘金熱」。在沒有官方應用程式商店的情況下，數千種工具在三個月內自願與 MCP 協議整合。
這種快速增長將 MCP 推向了行業聚光燈，但也暴露了願望與現實之間的差距。開發人員最初將 MCP 視為「通用鑰匙」，但發現它更像是一個「專用扳手」，在某些情況下表現出色，但在其他情況下效果不佳。
MCP 的參與者可以分為本地客戶端應用程式、雲端客戶端應用程式和 MCP 伺服器開發人員。本地應用程式類似於本地人工智慧助理，而雲端客戶端應用程式類似於基於 Web 的 ChatGPT 版本。MCP 伺服器開發人員是工具的實際提供商，他們需要重新封裝其 API 以符合 MCP 規則。
MCP 的出現最初受到本地客戶端應用程式的歡迎，但雲端客戶端應用程式和 MCP 伺服器開發人員面臨挑戰。
MCP 起源於 Anthropic 的 Claude Desktop 應用程式，最初設計為調用本地文件和函數的介面協議，深深植根於客戶端的需求。
對於本地客戶端使用者來說，MCP 代表了一場革命，提供了一個無限可擴展的工具箱，允許使用者不斷擴展其人工智慧助理的功能。
Cursor 和 Claude Desktop 等本地客戶端應用程式已利用 MCP 使使用者能夠根據個人需求動態添加工具，從而實現人工智慧助理功能的無限擴展。
MCP 解決了本地客戶端開發中的一個核心痛點：如何使人工智慧應用程式能夠無縫地與本地環境和外部工具互動，而無需為每個工具開發單獨的介面。這種統一協議顯著降低了整合成本，為小型新創公司和個人開發人員提供了一條捷徑，可以用有限的資源構建功能豐富的人工智慧應用程式。
但是，當考慮伺服器端開發 (MCP 伺服器) 和雲端客戶端時，MCP 的吸引力會降低。早期版本的 MCP 為雲端伺服器（遠端）採用了雙連結機制，使用 SSE 長連接進行從伺服器到客戶端的單向訊息推送，並使用 HTTP 短連接發送訊息。
這種方法對於及時的使用者回饋和干預效果很好，但在伺服器端環境中產生了一系列工程挑戰。
首先，實施 MCP 介面代表大型企業服務提供商的額外工作量，而不一定會產生相應的利益。這些服務通常具有成熟的 API 系統，提供額外的 MCP 調整層可能只會增加維護成本，而不會創造實質性的價值。許多企業級應用程式更喜歡封閉、可控制的工具調用機制，而不是 MCP 的開放生態系統。
此外，為了處理高並發調用，MCP 服務通常需要擴展到多伺服器架構。MCP 的雙連接模型引入了跨機器尋址的複雜性。當在一個伺服器上建立長連接，並且請求路由到另一個伺服器時，需要一個額外的廣播佇列機制來協調這些分散式連接，從而顯著增加了實施難度和維護成本。
其次，MCP 在雲端應用程式領域存在局限性。雲端人工智慧 Agent（伺服器端 Agent）通常在無狀態服務中運行，在接受任務後處理任務，並在完成後釋放資源。在伺服器端使用 MCP 客戶端需要臨時創建 SSE 連結、發送工具調用請求、從 SSE 接收結果，然後關閉 SSE 連結，這是一種效率低下的方法，會增加複雜性並降低效能。在這種情況下，單個 RPC 請求應該足夠了。
在實踐中，使用 MCP 的雲端應用程式通常依賴於預設的工具集，並且不利用 MCP 的動態工具發現和靈活載入的簽名功能。
雲端環境的數據互動模式限制了 MCP 預期那樣自由使用工具的能力。它需要高度標準化的流程來調用特定的硬編碼工具，從而犧牲了靈活性。
MCP 團隊已證明對使用者回饋的反應能力。在收到伺服器端開發人員的回饋後，MCP 於 3 月 26 日更新了其協議，將原始 SSE 傳輸替換為可串流的 HTTP 傳輸。新協議支援僅需要單個工具調用請求的無狀態服務場景，以及以前透過 HTTP + SSE 雙連結滿足的即時推送需求。
這些改進表明，目前的 MCP 問題源於最初的設計限制，但並非無法克服。
市場的混亂
MCP 面臨的另一個挑戰是市場上許多實施方案的可用性較低。
目前的 MCP 市場正在經歷一個典型的技術炒作週期。與早期 App Store 的混亂情況類似，目前可用的數千種 MCP 工具中，只有不到 20% 具有實際價值。許多實施方案存在嚴重的問題，從簡單的配置錯誤到完全無法使用。有些實施方案在未經過充分測試的情況下匆忙上市，而另一些則是從未打算實際使用的實驗性產品。
一個更根本的問題是，市場可能不需要許多 MCP 實施方案。許多透過 MCP 提供的工具只是重新封裝的 API，這些 API 在 MCP 出現之前已經可用和使用，沒有增加任何獨特的價值。
例如，透過 MCP 提供了數十種搜尋服務，但其品質差異很大。有些服務可能不準確或速度慢，因此不如現有解決方案那麼理想。
此外，MCP 缺乏強大的評估系統，這使得 Agent 難以根據可靠的指標選擇最合適的工具。這種低效的選擇過程浪費了計算資源，延長了任務完成時間，並降低了使用者體驗。
缺乏評估系統使得 Agent 難以選擇最合適的工具。如果多個 MCP 服務提供具有相似名稱和描述的工具，則 Agent 可能難以選擇最佳選項，從而導致 Token 浪費和效率降低。
最成功的人工智慧應用程式通常採用相反的方法，提供更精確的工具，而不是更多的工具。例如，儘管 Manus 存在，但它選擇構建內部應用程式，而不是採用 MCP 協議。Manus 優先考慮調用準確性和穩定性，而不是與 MCP 生態系統整合。
像 Cursor 這樣的程式碼編輯器具有內建的開發功能，使得大多數外部 MCP 工具變得多餘。
目前 MCP 市場的混亂狀態不一定是失敗的跡象，而是任何新興技術生態系統發展的必要階段。歷史先例表明，這種最初的過度擴張將透過市場選擇機制逐漸趨於收斂，留下最有價值的元素。
這個過程將使業界能夠從目前的挑戰中學習，並創建一個更強大、更可靠的 MCP 框架。就像網路泡沫導致了電子商務和社群媒體領域的顛覆性創新一樣，MCP 趨勢可能會導致一個更精簡、更有價值的工具生態系統。
MCP 團隊對使用者回饋的開放態度令人鼓舞，業界需要更好的工具來評估和保證 MCP 服務的品質，這將有助於提高生態系統的可用性。
MCP 很好，但不是萬靈丹
上述問題來自 MCP 的局限性和缺點，突出了它可以實際實現的目標。然而，其他批評來自不切實際的期望。
最近的一項批評將 MCP 標記為有缺陷的協議，因為它沒有規定 LLM 和 MCP 之間的互動模式。
有些人期望 MCP 自動改進人工智慧系統決策或提高任務規劃效率。這種期望將工具與工匠混淆了。
問題源於認知失配——期望一個通信協議執行智慧系統的任務。這就像責怪 USB 沒有編輯照片或責怪 5G 標準沒有編寫程式碼。MCP 主要是一個標準化的「工具插座」，確保插頭相容性，而不是規定使用哪個設備或如何使用。
Agent 工具調用的有效性取決於工具選擇熟練程度、任務規劃技能和上下文理解等因素，這些因素都不屬於 MCP 的範圍。MCP 只保證標準化的工具介面，而不是如何選擇和組合這些工具。
我們經常在技術中尋找銀彈，普遍適用的解決方案。就像軟體工程的「沒有銀彈」公理一樣，人工智慧工具的使用沒有神奇的解決方案。一個強大的人工智慧系統需要設計的元件：用於理解和生成 LLM、用於規劃和執行的 Agent 框架，以及專注於統一工具介面的 MCP。
MCP 展示了良好的協議設計——專注於一個問題並很好地解決它，而不是所有問題。它的克制有助於它在客戶端工具整合方面取得進展。
阿里巴巴的 Qwen、百度的「新象」和字節跳動的扣子空間等實體都採用了 MCP 協議，試圖建立更高效的內部 MCP 生態系統。
然而，部署方面存在關鍵差異：百度和字節跳動更具侵略性。百度嘗試採用 C 端方法，透過「新象」整合多個人工智慧模型和外部工具，利用 MCP 協議，主要用於移動設備，以融入使用者的日常生活並鼓勵採用。
字節跳動的扣子空間有 60 多個 MCP 擴展外掛程式。透過網頁存取，它還推出了人工智慧原生 IDE Trae，它支持 MCP，主要針對生產力場景。
阿里巴巴將 MCP 協議整合到支付寶等產品中，實現一鍵式人工智慧工具調用，並開源了支持 MCP 協議的 Qwen3 模型，增強了其 Agent 功能。
騰訊雲開發人員發布了一個支持 MCP 外掛程式託管服務的人工智慧開發套件。騰訊雲的大模型知識引擎使使用者能夠調用 MCP 外掛程式。騰訊雲 CodeBuddy 推出的 Craft 軟體開發智慧 Agent 與 MCP 開放生態系統相容。此外，騰訊地圖和騰訊雲儲存也發布了自己的 MCP SERVER。
人工智慧工具的使用可能會從直接的單個工具操作演變為專業的 Agent 協作，就像程式設計風格從組裝語言演變為物件導向一樣。
在這個範例中，MCP 可能只會成為底層基礎設施的一部分，而不是面向使用者或開發人員的介面。更完整的計畫可能需要像 Agent to Agents (A2A) 這樣的架構，透過提高抽象層次來提高任務規劃和工具選擇效率。
透過將 MCP 還原到其「協議」角色，我們可以認識到它推動產業標準化的真正力量——這可能是技術演進中最珍貴的「去神秘化」時刻。