使用模型上下文協議 (MCP) 徹底改變 AI Agent 工具互動
AI Agent 的發展日新月異，這也驅使我們需要更複雜的方法，讓這些 Agent 可以與外部工具和資料互動。過去，將大型語言模型 (LLM) 與外部工具整合是一個複雜且零散的過程。如今，模型上下文協議 (Model Context Protocol, MCP) 作為一種變革性的解決方案應運而生。MCP 為各種模型上的 AI Agent 工具調用提供了一種標準化、簡化且具有前瞻性的方法，為可擴展、安全且可互操作的工作流程鋪平了道路。
傳統 AI 工具整合的挑戰
在 MCP 出現之前，LLM 依賴於臨時的、特定於模型的整合來存取外部工具。諸如 ReAct、Toolformer、LangChain 和 LlamaIndex 以及 Auto-GPT 等方法雖然具有創新性，但卻導致程式碼庫零散且難以維護。每個新的資料來源或 API 都需要自己的封裝器，並且必須對 Agent 進行專門的訓練才能使用它。這種方法產生了孤立、非標準的工作流程，突顯了對統一解決方案的需求。
- 臨時整合： LLM 傳統上使用客製化的、特定於模型的整合來存取外部工具。
- 零散的程式碼庫： 每個新的資料來源或 API 都需要自己的封裝器，導致程式碼複雜且難以維護。
- 非標準工作流程： 孤立的工作流程使得跨不同模型和工具實現無縫整合變得困難。
模型上下文協議 (MCP) 簡介
模型上下文協議 (MCP) 標準化了 AI Agent 發現和調用外部工具及資料來源的方式。MCP 是一個開放協定，它定義了 LLM 主機和伺服器之間一個通用的基於 JSON-RPC 的 API 層。MCP 的作用如同「AI 應用程式的 USB-C 連接埠」，它提供了一個通用介面，任何模型都可以使用它來存取工具。這使得組織的資料來源和 AI 驅動的工具之間能夠建立安全、雙向的連接，從而取代了過去零碎的連接器。
MCP 的主要優勢
- 將模型與工具分離： Agent 可以連接到 MCP 伺服器，而無需特定於模型的提示或硬編碼的函式調用。
- 標準化介面： MCP 提供了一個通用的介面供模型存取工具，從而簡化了整合過程。
- 安全連接： 實現了資料來源和 AI 驅動的工具之間的安全、雙向連接。
- 通用可存取性： 任何模型都可以使用 MCP 來存取工具，使其成為一種通用的解決方案。
Agent 無需編寫特定於模型的提示或硬編碼函式調用，只需連接到一個或多個 MCP 伺服器，每個伺服器都以標準化的方式公開資料或功能。Agent (或主機) 從伺服器檢索可用工具的清單，包括它們的名稱、描述以及輸入/輸出模式。然後，模型可以按名稱調用任何工具。這種標準化和重用是相較於先前方法的關鍵優勢。
MCP 定義的核心角色
MCP 的開放規範定義了三個核心角色：主機 (Host)、客戶端 (Client) 和伺服器 (Server)。
- 主機： LLM 應用程式或使用者介面 (例如，聊天 UI、IDE 或 Agent 編排引擎)，使用者與之互動。主機嵌入 LLM 並充當 MCP 客戶端。
- 客戶端： 主機內實現 MCP 協議的軟體模組 (通常透過 SDK)。客戶端處理訊息傳遞、身份驗證以及編組模型提示和回應。
- 伺服器： 提供上下文和工具的服務 (本地或遠端)。每個 MCP 伺服器都可以封裝資料庫、API、程式碼庫或其他系統，並向客戶端宣告其功能。
MCP 明確地受到了 IDE 中使用的語言伺服器協定 (LSP) 的啟發：正如 LSP 標準化了編輯器查詢語言特性的方式一樣，MCP 標準化了 LLM 查詢上下文工具的方式。透過使用通用的 JSON-RPC 2.0 訊息格式，任何遵守 MCP 的客戶端和伺服器都可以互操作，無論使用的程式語言或 LLM 如何。
技術設計與架構
MCP 依賴 JSON-RPC 2.0 來傳輸三種類型的訊息：請求、回應和通知，從而允許 Agent 執行同步工具調用並接收非同步更新。在本地部署中，客戶端通常會產生一個子進程並透過 stdin/stdout (stdio 傳輸) 進行通訊。相反，遠端伺服器通常使用帶有伺服器發送事件 (Server-Sent Events, SSE) 的 HTTP 來即時串流訊息。這種靈活的訊息傳遞層確保可以調用工具並傳送結果，而不會阻塞主機應用程式的主要工作流程。
每個伺服器都會公開三個標準化的實體：資源、工具和提示。
- 資源： 可提取的上下文片段，例如文字檔案、資料庫表或快取的文件，客戶端可以按 ID 檢索。
- 工具： 具有明確定義的輸入和輸出模式的具名函式，無論是搜尋 API、計算器還是客製化的資料處理常式。
- 提示： 可選的、更高級別的範本或工作流程，用於引導模型完成多步驟互動。
透過為每個實體提供 JSON 模式，MCP 使任何有能力的大型語言模型 (LLM) 都能夠解釋和調用這些功能，而無需客製化的解析或硬編碼的整合。
模組化設計
MCP 架構將關注點在三個角色之間進行了清晰的分離。主機嵌入 LLM 並編排對話流程，將使用者查詢傳遞到模型中並處理其輸出。客戶端本身實現 MCP 協議，管理所有訊息編組、身份驗證和傳輸細節。伺服器宣告可用的資源和工具，執行傳入的請求 (例如，列出工具或執行查詢)，並傳回結構化的結果。這種模組化設計，包含主機中的 AI 和 UI、客戶端中的協定邏輯以及伺服器中的執行，確保系統保持可維護、可擴展且易於發展。
互動模型與 Agent 工作流程
在 Agent 中使用 MCP 遵循一個簡單的發現和執行模式。當 Agent 連接到 MCP 伺服器時，它首先調用 list_tools() 方法來檢索所有可用的工具和資源。然後，客戶端將這些描述整合到 LLM 的上下文中 (例如，透過將它們格式化到提示中)。模型現在知道這些工具的存在以及它們所採用的參數。
簡化工作流程
- 發現： Agent 連接到 MCP 伺服器，並使用
list_tools()方法檢索可用工具和資源的清單。 - 整合： 客戶端將這些描述整合到 LLM 的上下文中。
- 執行： 當 Agent 決定使用工具時，LLM 會發出一個結構化的調用 (例如，一個具有
call: tool_name, args: {...}的 JSON 物件)。 - 調用： 主機將其識別為工具調用，並且客戶端向伺服器發出相應的
call_tool()請求。 - 回應： 伺服器執行該工具並傳回結果。然後，客戶端將此結果饋送到模型的下一個提示中，使其顯示為額外的上下文。
當 Agent 決定使用工具時 (通常由使用者的查詢提示)，LLM 會發出一個結構化的調用 (例如，一個具有 \"call\": \"tool_name\", \"args\": {…} 的 JSON 物件)。主機將其識別為工具調用，並且客戶端向伺服器發出相應的 call_tool() 請求。伺服器執行該工具並傳回結果。然後，客戶端將此結果饋送到模型的下一個提示中，使其顯示為額外的上下文。此協議透明地處理發現→提示→工具→回應的迴圈。
實作與生態系統
MCP 與實作無關。官方規範在 GitHub 上維護，並且提供了多種語言的 SDK，包括 TypeScript、Python、Java、Kotlin 和 C#。開發人員可以使用他們喜歡的堆疊編寫 MCP 客戶端或伺服器。例如，OpenAI Agents SDK 包括一些類，這些類可以從 Python 輕鬆連接到標準 MCP 伺服器。InfraCloud 的教學示範了如何設定一個基於 Node.js 的檔案系統 MCP 伺服器，以允許 LLM 瀏覽本地檔案。
不斷成長的生態系統
- 語言 SDK： 提供 TypeScript、Python、Java、Kotlin 和 C# 版本。
- 開源伺服器： Anthropic 已經發布了許多流行的服務的連接器，包括 Google Drive、Slack、GitHub、Postgres、MongoDB 以及使用 Puppeteer 的 Web 瀏覽等等。
- 整合平台： Claude Desktop、Google 的 Agent 開發工具包和 Cloudflare 的 Agents SDK 都整合了 MCP 支援。
- Auto-Agents： Auto-GPT 可以插入 MCP，從而實現動態工具發現和利用。
一旦一個團隊為 Jira 或 Salesforce 建立了一個伺服器，任何相容的 Agent 都可以使用它而無需重新工作。在客戶端/主機方面，許多 Agent 平台都整合了 MCP 支援。Claude Desktop 可以連接到 MCP 伺服器。Google 的 Agent 開發工具包將 MCP 伺服器視為 Gemini 模型的工具提供者。Cloudflare 的 Agents SDK 添加了一個 McpAgent 類，以便任何 FogLAMP 都可以成為具有內建身份驗證支援的 MCP 客戶端。即使是像 Auto-GPT 這樣的自動 Agent 也可以插入 MCP：Agent 不再需要為每個 API 編寫特定的函式，而是使用 MCP 客戶端函式庫來調用工具。這種朝向通用連接器的趨勢承諾了一種更模組化的自主 Agent 架構。
在實踐中，這個生態系統使得任何給定的 AI 助理都能夠同時連接到多個資料來源。人們可以想像這樣一個 Agent，它在一個會話中，使用一個用於公司文件的 MCP 伺服器，另一個用於 CRM 查詢，還有一個用於裝置上的檔案搜尋。MCP 甚至可以優雅地處理命名衝突：如果兩個伺服器各自都有一個名為「分析」的工具，客戶端可以對它們進行命名空間 (例如，「ImageServer.analyze」與「CodeServer.analyze」)，以便兩者都保持可用而不發生衝突。
相較於先前範例的優勢
MCP 帶來了先前方法所缺乏的幾個關鍵優勢：
- 標準化整合： MCP 為所有工具提供了一個協定。
- 動態工具發現： Agent 可以在執行時發現工具。
- 互操作性和重用： 同一個工具伺服器可以為多個 LLM 客戶端提供服務。
- 可擴展性和維護： MCP 大大減少了重複的工作。
- 可組合的生態系統： MCP 實現了一個獨立開發的伺服器市場。
- 安全性和控制： 該協定支援清晰的授權流程。
主要優勢總結
- 統一協定： MCP 為所有工具提供了一個單一、標準化的協定，簡化了開發並消除了對客製化解析邏輯的需求。
- 執行時發現： Agent 可以動態地發現可用的功能，從而消除了在添加新工具時重新啟動或重新編程的需求。
- 模型不可知： MCP 允許同一個工具伺服器為多個 LLM 客戶端提供服務，從而避免了供應商鎖定並減少了重複的工程工作。
- 減少重複： 開發人員可以為檔案搜尋等任務編寫一個單一的 MCP 伺服器，使所有模型上的所有 Agent 受益。
- 開放生態系統： MCP 鼓勵建立一個開放的連接器市場，類似於 Web API。
- 授權流程： MCP 支援清晰的授權流程，相較於自由形式的提示，增強了可審計性和安全性。
產業影響與真實世界應用
MCP 的採用正在迅速增長。主要的供應商和框架已經公開投資 MCP 或相關的 Agent 標準。各組織正在探索使用 MCP 將內部系統 (例如 CRM、知識庫和分析平台) 整合到 AI 助理中。
具體用例
- 開發人員工具： 程式碼編輯器和搜尋平台利用 MCP 使助理能夠查詢程式碼儲存庫、文件和提交歷史記錄。
- 企業知識與聊天機器人： 服務台機器人可以透過 MCP 伺服器存取 Zendesk 或 SAP 資料，回答有關未解決工單的問題或根據即時企業資料產生報告。
- 增強的檢索增強生成 (RAG)： RAG Agent 可以將基於嵌入的檢索與專門的 MCP 工具結合起來，用於資料庫查詢或圖形搜尋。
- 主動助理： 事件驅動的 Agent 監控電子郵件或任務串流，並透過調用日曆和筆記工具 (透過 MCP) 自主排程會議或總結操作項目。
在每種情況下，MCP 都使 Agent 能夠跨多樣化的系統進行擴展，而無需重寫整合程式碼，從而提供可維護、安全且可互操作的 AI 解決方案。
與先前範例的比較
MCP 統一並擴展了先前的方法，在一個協定中提供了動態發現、標準化模式和跨模型互操作性。
- 相對於 ReAct： MCP 使用 JSON 模式為模型提供了一個正式的介面，使客戶端能夠無縫地管理執行。
- 相對於 Toolformer： MCP 將工具介面完全從模型中外部化，從而實現對任何已註冊工具的零樣本支援，而無需重新訓練。
- 相對於框架函式庫： MCP 將整合邏輯轉移到一個可重用的協定中，從而使 Agent 更加靈活並減少了程式碼重複。
- 相對於自主 Agent： 透過使用 MCP 客戶端，此類 Agent 不需要用於新服務的客製化程式碼，而是依賴於動態發現和 JSON-RPC 調用。
- 相對於函式調用 API： MCP 將函式調用推廣到任何客戶端和伺服器，並支援串流、發現和多工服務。
局限性與挑戰
儘管 MCP 前景光明，但它仍在成熟中：
- 身份驗證與授權： 當前的解決方案需要從外部分層 OAuth 或 API 金鑰，這可能會使沒有統一身份驗證標準的部署變得複雜。
- 多步驟工作流程： 編排長時間運行的、有狀態的工作流程通常仍然依賴於外部排程器或提示鏈，因為該協定缺乏內建的會話概念。
- 大規模發現： 在大型環境中，管理許多 MCP 伺服器端點可能會很繁瑣。
- 生態系統成熟度： MCP 是一個新事物，因此並非每個工具或資料來源都已存在連接器。
- 開發開銷： 對於單一、簡單的工具調用，與快速、直接的 API 調用相比，MCP 設定可能感覺很繁重。