MCP協議：AI Agent怎麼跟外部世界說話

一個Agent的邊界困境

你有沒有想過一個問題：為什麼現在的AI助手，哪怕模型本身能力很強，用起來還是經常感覺被「關在籠子裡」？

你讓它幫你查一下今天的股價——它說不知道，因為沒有即時資料。你讓它看看你的GitHub倉庫裡有沒有安全漏洞——它說看不到，因為沒有存取權限。你讓它幫你發一封郵件——它給你生成了草稿，還是得你自己去發。

模型能力不是問題，問題是工具接入。

這就是MCP（Model Context Protocol，模型上下文協議）要解決的事。

MCP是什麼，一句話說清

MCP是Anthropic在2024年末提出的開放協議，解決的是AI Agent和外部工具之間的標準化連接問題。

以前，每個AI產品要接入一個外部工具，都得自己造輪子：定義工具描述格式、處理認證、解析返回值。20個產品接同一個工具，就要寫20套程式碼，維護20套介面。既浪費，又碎片化。

MCP的思路是：把這件事標準化。工具提供方實作一個MCP Server，AI應用方整合一個MCP Client，兩邊按同一套協議通訊——工具描述、呼叫格式、返回格式，全都統一。

就像HTTP統一了Web通訊一樣，MCP想統一Agent和工具之間的通訊。

架構：三個角色

MCP生態裡有三個角色：

MCP Host（宿主）：就是你在用的AI應用，比如Claude Desktop、Cursor、OpenClaw。它執行著MCP Client，負責和Server通訊，把工具的能力暴露給模型。

MCP Server：工具的實作端。一個MCP Server可以暴露多個工具（Tools）、資源（Resources）和提示詞範本（Prompts）。比如GitHub MCP Server可以暴露「列出PR」「建立Issue」「讀取檔案」這些工具。

MCP Client：內嵌在Host裡，按MCP協議和Server通訊。

它們之間的通訊走JSON-RPC 2.0，底層可以是本地的stdio（標準輸入輸出）或者遠端的HTTP+SSE（伺服器推送事件）。

AI應用（Host）
   ↓ MCP Client
   ├── 本地Server A（stdio）
   ├── 本地Server B（stdio）
   └── 遠端Server C（HTTP/SSE）

本地Server透過行程間通訊，幾乎零延遲；遠端Server走網路，適合雲端服務。

工具呼叫的完整流程

還是拿「幫我查今日AAPL股價」這個需求來說：

• 使用者發訊息給AI
• AI（LLM）識別到這個任務需要即時股價資料，決定呼叫get_stock_price工具
• MCP Client向已連接的Server發出工具呼叫請求（JSON-RPC）
• MCP Server（股票資料服務）執行查詢，返回結果
• 結果注入AI的上下文，AI基於真實資料給出回答

整個過程對使用者透明，就像跟一個真的知道即時股價的人在聊天。

關鍵點在第2步——模型是自主決定用哪個工具的。不是使用者說「用工具查一下」，而是模型自己判斷任務需要什麼能力，然後去呼叫。這才是Agent行為，而不是普通的function calling。

MCP和Function Calling的區別

很多人會問：OpenAI的Function Calling不是也能調工具嗎？MCP有什麼不同？

Function Calling是模型層面的能力——讓模型能輸出結構化的工具呼叫請求。但工具本身的定義、管理、執行，每個應用還是要自己搞定。

MCP是生態層面的協議——它不取代Function Calling（實際上MCP工具的呼叫還是走Function Calling），它解決的是工具的發現、描述、生命週期管理這些更上層的問題。

類比一下：Function Calling是「你能打電話了」，MCP是「電話簿＋通話協議＋電信業者接入規範」。

三種能力：Tools / Resources / Prompts

MCP Server可以暴露三類東西：

Tools（工具）：可以執行操作的函式，比如發郵件、查資料庫、呼叫API。這是最核心的能力。

Resources（資源）：可以讀取的資料來源，比如檔案系統、資料庫記錄、API回應。資源是唯讀的，不會產生副作用。

Prompts（提示詞範本）：Server可以提供預定義的提示詞範本，讓AI應用可以複用專業化的提問方式。比如程式碼審查Server提供「code-review」範本，裡面已經包含了審查要求。

這三類能力組合起來，一個MCP Server就能提供相當完整的「專業域服務」。

實際生態：已經有哪些MCP Server

2025年，MCP生態擴張很快。截至2026年初，常用的開源MCP Server包括：

• 檔案系統：讀寫本地檔案、目錄操作
• 資料庫（PostgreSQL / SQLite）：執行SQL查詢、讀取schema
• 程式碼平台（GitHub / GitLab）：PR操作、Issue管理、程式碼搜尋
• 通訊工具（Slack / Gmail）：發訊息、讀郵件
• 搜尋（Brave Search / Perplexity）：即時網路搜尋
• 瀏覽器控制（Playwright）：開啟網頁、截圖、填表單
• 記憶系統（Memory / Knowledge Graph）：持久化記憶、知識圖譜查詢

Anthropic官方維護了一批參考實作，第三方社群也在快速貢獻。ClawHub上已經有200+ MCP相關的技能包。

我們在SFD實驗室的實踐

SFD實驗室跑著13個協作Agent，每個Agent都有自己的工具集。我們從去年開始逐步把工具接入方式從「手寫function call schema」遷移到MCP。

幾個實際感受：

工具復用變容易了。以前小章魚（後端Agent）和小灰狼（全端Agent）都需要存取資料庫，得各自維護一套工具描述。現在共用一個PostgreSQL MCP Server，兩邊都能用，更新一次全部生效。

除錯比以前好做。MCP的JSON-RPC通訊是明文的，出問題時直接看日誌就知道Client發了什麼、Server返回了什麼。以前工具呼叫失敗了很難定位是模型沒調對還是工具實作有bug。

踩過的坑：本地stdio Server在行程管理上要小心。Server異常退出後，Host不會自動重連，需要手動重啟或者加健康檢查腳本。我們有一次小猎鷹（安全稽核Agent）的GitHub MCP Server靜默死了，連續兩次稽核任務都失敗，排查了快半小時才發現是Server行程掛了。

安全邊界：必須知道的風險

MCP帶來便利的同時，安全風險也是真實的。

工具權限過大：一個能讀寫檔案系統的MCP Server，如果Agent被注入惡意指令，可能被誘導刪除檔案或洩漏敏感資料。我們的原則是：每個Server只開放最小權限，讀和寫分開，正式資料庫只給讀取權限。

提示注入攻擊：如果Agent的工具能讀取外部內容（比如爬蟲），外部內容裡可能藏有「ignore previous instructions」之類的注入。我們在抓取外部資料的Agent上都套了一層moltguard做過濾。

Server可信度：用第三方MCP Server時，要審查它的程式碼。你不知道一個遠端MCP Server的服務端在做什麼——它可能在記錄你的所有請求，或者返回被篡改的資料。

安全這件事，MCP本身不管，靠的是使用者的設計規範。

2026年值得關注的方向

遠端MCP（HTTP+SSE）的成熟：目前大多數MCP Server還是本地執行的，遠端Server的生態剛起步。一旦遠端MCP成熟，「Agent即服務」的模式就能跑通——你不需要在本地部署任何Server，直接連雲端服務。

MCP的安全標準化：現在MCP沒有內建的認證標準，靠的是HTTP Basic Auth或者環境變數傳Token。社群在討論更統一的方案，這塊2026年可能有進展。

Agent間的MCP：一個Agent作為另一個Agent的MCP Server——這個模式正在被探索。在我們的多Agent協作裡，這有很大的想象空間。

SFD編者注

我們實際體會是：MCP是個方向正確、規範合理的協議，但生態還在早期。真正用起來，你會發現不少Server的穩定性參差不齊，文件也不夠完整。

建議的姿勢是：先從Anthropic官方的參考Server開始用，穩定性有保障；社群Server用之前先看程式碼；自己寫Server時，先只暴露讀取操作，等測試穩定後再開放寫入操作。

MCP的價值不在於它現在有多完善，而在於它是一個大家都在往裡投入的標準。越來越多的工具在支援它，這件事本身就有價值。