1次搭建完勝1億次編碼，MCP矽谷瘋傳！Anthropic協議解鎖智慧體「萬能手」

新智元報道

編輯：編輯部 HNY

【新智元導讀】AI智慧體領域Type-C來了！Manus及其開源復現誕生，一夜捧紅了MCP，工具呼叫/訪問外部資料，一個協議就夠了。

上一週，智慧體迎來里程碑式的一週。

從Manus及其開源復現，到Opera的瀏覽器操作AI智慧體、AI工作伴侶Archer，再到多種個人專案，將Agent推向熱議風口。

在處理動輒需要十幾甚至幾十分鐘的複雜任務時，涉及到3個核心能力：

規劃
工具使用
記憶

其中，第二趴是讓智慧體「動起來」的關鍵，真正與現實世界進行互動。

舉個例子，當前最強的開源復現OWL在查詢倫敦今日放映的電影時，AI智慧體主動呼叫Chrome搜尋工具後，精準返回影院的即時資訊。

而最火的開源專案OpenMauns，在查詢Karpathy個人資訊主頁資訊時，也是基於強大的工具使用能力。

這些案例生動地證明了，工具使用，能讓智慧體跳出空想侷限，進化出會做事的能力。

而作為最強的標準化介面協議，MCP也在一夜間爆紅矽谷，無人不知。

對於圈外的人來說，可能對此有所陌生。而它的本質，就是智慧體系統的一種。

一次搭建，代替1億次配置

去11月，Anthropic首次提出「模型上下文協議」，即MCP，賦予了Claude模型超級能力，一次構建，讓AI與工作流深度整合。

其主要優勢如下：

開發簡化：一次編寫，多次整合，無需為每個新整合重寫定製程式碼
靈活性：切換AI模型或工具時，不需要複雜的重新配置
即時響應：MCP連線保持活躍狀態，支援即時上下文更新和互動
安全性和合規性：內建訪問控制機制和標準化的安全實踐
可擴充套件性：隨著AI生態系統的擴充套件，只需連線新的MCP伺服器即可輕鬆新增新功能

用通俗的話講，MCP就像是專為AI應用設計的通用介面，類似我們日常使用的USB-C。

正如USB-C簡化了不同裝置與計算機的連線方式，MCP簡化了AI模型與資料、工具和服務之間的互動方式。

透過MCP，AI助手不僅能夠「讀懂」程式碼，還能「理解」團隊討論、涉及文件等外部資訊，提供更加精準的回答。

MCP是一種標準化協議，用於連線AI智慧體與各種外部工具和資料來源

相比之下，在沒有MCP之前，AI助手要想與外部工具互動，必須透過編寫程式碼並呼叫API，這意味著每一種具體的連線都需要提前手動程式設計，效率低下且耗時費力。

更棘手的是，每個AI助手與每個外部工具之間都需要單獨進行配置。如果有1000個AI助手和1000個外部工具，理論上需要編寫1000×1000=100萬個獨立的連線程式碼，工作量簡直是個天文數字。

打個比方：API就像是不同的門，其中每扇門都有自己獨特的鑰匙和使用規則：

傳統API要求開發人員為每個服務或資料來源編寫定製化的整合程式碼

而MCP的出現就像為AI助手和外部系統打造了一套通用的「標準語言」，堪稱是智慧體生態的一次「標準化革命」。

一旦某個AI助手實現了MCP協議，它就能透過這個協議無縫連線上成千上萬的外部工具，無需再為每種連線單獨編寫程式碼。

同樣，外部工具（比如郵件、天氣應用等）也只需搭建一次MCP伺服器，之後所有支援MCP的AI助手都可以直接與之互動。

假如有1萬個AI助手和1萬個外部工具。在MCP模式下，每方只需實現一次協議，總共只需2萬次配置。

而按照傳統編碼方式，每種AI助手與每種外部工具都要單獨對接，那將是1萬×1萬=1億次配置！

這直接使配置效率提高了不止一個維度。

MCP的靈活性也非常突出，它既可以在雲端執行，也可以在本地裝置上部署，適應性極強。

可以說，MCP就像為AI助手和外部系統之間架設了一條高速路，取代了過去需要技術人員一橋一橋手工搭建的低效模式。

什麼是MCP？

正如前文所說，MCP（Model Context Protocol）是一種新的開放協議，目的是為LLM提供標準化的上下文資訊傳遞方式，從而實現AI智慧體與外部資料及工具的結合。

和傳統的API相比，MCP的區別在於：

單一協議：MCP作為一種標準化的「通用介面」，整合一個MCP意味著可以訪問多個工具和服務，而不僅僅是單一服務。
動態發現：MCP允許AI模型動態發現並與可用工具互動，無需預先設定每個整合的固定程式碼。
雙向通訊：MCP支援持續、即時的雙向通訊——類似於WebSockets。AI模型既可以獲取資訊，也可以即時觸發操作。

其中，即時雙向通訊的機制如下：

拉取資料：LLM向伺服器查詢上下文資訊。例如，檢視你的日曆安排。
觸發操作：LLM指示伺服器執行具體操作。例如，重新安排會議、傳送電子郵件。

不過，如果應用場景需要精確、可預測的互動模式，並有嚴格的限制條件，傳統API可能更為適合。

MCP提供了廣泛、動態的能力，非常適合需要靈活性和上下文感知的場景，但對於高度受控的、確定性的應用可能不是最佳選擇。

在以下情況下推薦使用傳統API：

需要精細控制和高度特定、受限的功能場景
追求效能最佳化而需要緊密耦合的系統
要求最高可預測性和最小上下文自主性的應用

架構

MCP採用簡單的客戶端-伺服器架構模式：

MCP主機：需要訪問外部資料或工具的應用程式（如Claude Desktop或AI驅動的整合開發環境）
MCP客戶端：與MCP伺服器維持專屬的一對一連線
MCP伺服器：輕量級伺服器，透過MCP協議提供特定功能，連線到本地或遠端資料來源
本地資料來源：MCP伺服器安全訪問的檔案、資料庫或服務
遠端服務：MCP伺服器訪問的基於網際網路的外部API或服務

將MCP比作一座橋樑可以更清晰地理解：MCP本身不處理複雜邏輯；它只是協調AI模型和各種工具之間的資料和指令流通。

具體來說，伺服器就是與API進行互動的東西。它可以在遠端伺服器上（例如，在雲上），或者在你的本地系統上。

它包含了所有系統上需要與之互動進而採取行動的程式碼，比如傳送Slack訊息、建立檔案等等。

如下圖所示，可以透過MCP服務，呼叫GitHub API在倉庫裡建立程式碼檔案。

MCP客戶端負責與伺服器進行通訊。客戶端的一個非常酷的特點是它可以同時與多個伺服器進行互動。

所以你可以設定專門的伺服器來處理GitHub互動和Slack互動，然後把它們接入同一個客戶端。

最重要的，協議是使一切運作的關鍵。可以將它視為一種永遠不會改變的通用語言，MCP伺服器和MCP客戶端都能使用。

它就像USB介面一樣，用於將MCP客戶端連線到MCP伺服器。

USB介面讓手機連線到筆記型電腦，MCP協議讓你可以將第三方API連線到桌面應用程式。

針對各種型別的MCP客戶端，Total TypeScript的作者Matt Pocock還進行了一波對比。

可以看到，Claude Desktop和Continue支援資源、提示、工具，功能很全面。5ire和BeeAI Framework就比較有限，工具支援還可以，但其他方面基本不行。Cline也支援資源和工具，但不支援提示。Cursor和Emacs Mcp主要支援工具，其他功能都不行，適合簡單工具操作。