從0到1玩轉MCP：AI的「萬能插頭」，程式碼手把手教你！

選自Towards Data Science

作者：Sandi Besen

機器之心編譯

在人工智慧飛速發展的今天，LLM 的能力令人歎為觀止，但其侷限性也日益凸顯 —— 它們往往被困於訓練資料的「孤島」，無法直接觸及即時資訊或外部工具。

2024 年 11 月，Anthropic 推出了開源協議 MCP（Model Context Protocol，模型上下文協議），旨在為 AI 模型與外部資料來源和工具之間的互動提供一個通用、標準化的連線方式。MCP 的開源性質也迅速吸引了開發社群的關注，許多人將其視為 AI 生態系統標準化的重要一步。

MCP 的好處之一是它們能讓 AI 系統更安全。當大家都能用到經過嚴格測試的工具時，公司就不必「重複造輪子」，這樣既減少了安全隱患，也降低了惡意程式碼出現的可能。

隨著 MCP 的逐漸普及，其影響力開始在行業內顯現。2025 年 3 月 27 日，OpenAI 也開始支援 MCP 了。

谷歌似乎也在考慮是否加入 MCP 大家庭：

仔細看 MCP 的相關資料，會發現明視訊記憶體在資訊斷層。雖然有很多解釋「它能做什麼」的概述，但當你真想了解它是「怎麼運作的」時，資料就變得稀少了 —— 特別是對非專業開發者來說。目前的資料不是過於表面的介紹，就是太過深奧的原始碼。

近日，一篇部落格以淺顯易懂的方式講解了 MCP，讓各種背景的讀者都能理解它的概念和功能，讀者還可以跟著程式碼進行實踐。

部落格連結：https://towardsdatascience.com/clear-intro-to-mcp/

讓我們跟隨部落格一探究竟（注：本文程式碼截圖可能不完整，詳見原文）。

透過類比理解 MCP：餐廳模型

首先，讓我們將 MCP 的概念想象成一家餐廳，其中：

主機（Host）＝餐廳建築（智慧體程式執行的環境）
伺服器（Server）＝廚房（工具發揮作用的地方）
客戶端（Client）＝服務員（傳送工具請求的角色）
智慧體（Agent）＝顧客（決定使用哪種工具的角色）
工具（Tools）＝食譜（被執行的程式碼）

現在，我們來看看這家餐廳的「崗位要求」：

主機（Host）

智慧體執行的環境。類比餐廳建築，在 MCP 中，它是智慧體或 LLM 實際執行的位置。如果在本地使用 Ollama，使用者即為主機；若使用 Claude 或 GPT，則 Anthropic 或 OpenAI 為主機。

客戶端（Client）

負責從智慧體傳送工具呼叫請求的環境。相當於將顧客訂單傳遞至廚房的服務員。實際上是智慧體執行的應用程式或介面，客戶端透過 MCP 將工具呼叫請求傳遞給伺服器。

伺服器（Server）

類似廚房，儲存各種「食譜」或工具。集中管理工具，使智慧體能夠便捷訪問。伺服器可以是本地的（使用者啟動）或遠端的（由提供工具的公司託管）。伺服器上的工具通常按功能或整合方式分組，例如，所有 Slack 相關工具可集中於「Slack 伺服器」，或所有訊息工具可集中於「訊息伺服器」。這種組織方式取決於架構設計和開發者偏好。

智慧體（Agent）

系統的「大腦」，由大語言模型驅動，決定呼叫哪些工具完成任務。當確定需要某工具時，向伺服器發起請求。智慧體無需原生理解 MCP，因為它透過每個工具關聯的元資料學習使用方法。工具關聯的元資料指導智慧體如何呼叫工具及執行方式。需注意，平臺或智慧體必須支援 MCP 才能自動處理工具呼叫，否則開發者需編寫複雜的轉換邏輯，包括從架構解析元資料、以 MCP 格式形成工具呼叫請求、將請求對映至正確函式、執行程式碼，並以符合 MCP 的格式將結果返回給智慧體。

工具（Tools）

執行具體工作的函式，如呼叫 API 或自定義程式碼。工具存在於伺服器上，可以是：

使用者建立並託管在本地伺服器的自定義工具
他人在遠端伺服器上託管的預製工具
他人建立但使用者在本地伺服器託管的預製程式碼

如何協同工作

下面詳細介紹 MCP 的具體工作流程：

伺服器註冊工具：每個工具都需定義名稱、描述、輸入 / 輸出模式及函式處理程式（執行程式碼），並註冊到伺服器。這一過程通常透過呼叫特定方法或 API，向伺服器宣告「這是一個新工具及其使用方式」。

伺服器暴露元資料：伺服器啟動或智慧體連線時，透過 MCP 協議暴露工具元資料（包括模式和描述）。

智慧體發現工具：智慧體透過 MCP 查詢伺服器，瞭解可用工具集。智慧體從工具元資料中學習如何使用每個工具。這一過程通常在系統啟動時或新工具新增時觸發。

智慧體規劃工具使用：當智慧體確定需要某個工具（基於使用者輸入或任務上下文）時，會按照標準化的 MCP JSON 格式構建工具呼叫請求，包含工具名稱、符合工具輸入模式的引數及其他必要元資料。客戶端作為傳輸層，透過 HTTP 將 MCP 格式的請求傳送至伺服器。

翻譯層執行：翻譯層接收智慧體的標準化工具呼叫（透過 MCP），將請求對映到伺服器上對應的函式，執行該函式，將結果格式化回 MCP 格式，然後傳送回智慧體。抽象化 MCP 的框架可以完成所有這些工作，開發者無需編寫翻譯層邏輯（這聽起來是個令人頭疼的事情）。

MCP Brave 搜尋伺服器的 Re-Act 智慧體程式碼示例

為了理解 MCP 的實際應用效果，我們可以使用 IBM 的 beeAI 框架，該框架原生支援 MCP 併為我們處理轉換邏輯。如果你計劃執行這段程式碼，你需要：

克隆 beeAI 框架倉庫以獲取此程式碼中使用的輔助類： https://github.com/i-am-bee/beeai-framework ；
建立一個免費的 Brave 開發者賬戶並獲取 API 金鑰（有免費訂閱可用，需要信用卡）；
建立一個 OpenAI 開發者賬戶並生成 API 金鑰；
將你的 Brave API 金鑰和 OpenAI 金鑰新增到倉庫 Python 資料夾級別的 .env 檔案中；
確保你已安裝 npm 並正確設定了路徑。

示例 .env 檔案

示例 mcp_agent.ipynb

1. 匯入必要的庫

2. 載入環境變數並設定系統路徑（如有需要）

3. 配置日誌記錄器

4. 載入輔助函式如 process_agent_events、observer，並建立 ConsoleReader 例項

process_agent_events：處理智慧體事件並根據事件型別（如錯誤、重試、更新）將訊息記錄到控制檯。它為每種事件提供有意義的輸出，以幫助跟蹤智慧體活動。
observer：監聽來自發射器的所有事件，並將它們路由到 process_agent_events 進行處理和顯示。
ConsoleReader：管理控制檯輸入 / 輸出，允許使用者互動並透過帶有色彩編碼角色的方式顯示格式化訊息。

5. 設定 Brave API 金鑰和伺服器引數。

Anthropic 有一個 MCP 伺服器列表：https://modelcontextprotocol.io/examples

6. 建立一個 Brave 工具，它將啟動與 MCP 伺服器的連線，發現工具，並將發現的工具返回給智慧體，以便它決定對於給定的任務應該呼叫哪個工具。

在此情況下，Brave MCP 伺服器上可發現 2 個工具：

brave_web_search：執行帶分頁和過濾的網頁搜尋
brave_local_search：搜尋本地商家和服務

（可選）檢查與 MCP 伺服器的連線，並在將其提供給智慧體之前確保它返回所有可用的工具。

輸出

7. 編寫建立智慧體的函式

分配一個 LLM
建立一個 brave_tool () 函式的例項，並將其分配給 tools 變數
建立一個 re-act 智慧體，並給它分配選擇的 llm、tools、記憶體（以便它可以進行持續的對話）
向 re-act 智慧體新增系統提示

注意：您可能會注意到在系統提示詞中添加了一句話：「If you need to use the brave_tool you must use a count of 5.」這是一個臨時解決方案，因為在 Brave 伺服器的 index.ts 檔案中發現了一個錯誤。使用者將為該倉庫貢獻程式碼來修復它。