它不是另一個 API，而是溝通的「標準語言」
MCP (Model Context Protocol) 是一種開放通訊協定，由 Anthropic 提出，目標是讓 AI 模型（如 Claude）能與外部工具、資料來源和開發環境以統一方式互動。如果你用過 OpenAI 的 function calling 或自訂插件，MCP 就是這類功能的標準化版本——它定義了 AI 如何發起請求、工具如何回應，以及雙方如何處理錯誤。
為什麼你需要理解 MCP？
假設你正在寫一個自動化腳本，需要 AI 讀取本地日誌檔、查詢資料庫，然後根據結果修改程式碼。傳統做法是為每個動作寫自訂 API，但 MCP 提供了一個統一協定，讓 AI 直接發現並呼叫這些能力。它的核心好處是降低整合成本：工具開發者只要實作一次 MCP server，就能被任何支援 MCP 的 AI 客戶端使用。
MCP 的實際運作：從發起到回應
MCP 使用客戶端-伺服器模型，但角色與傳統 Web API 相反：
- AI 客戶端（如 Claude Desktop、VS Code 擴充套件）扮演 MCP 客戶端，它負責與使用者互動，並向外部工具發送請求。
- 工具服務（如檔案系統、資料庫查詢器）被包裝成 MCP 伺服器，每個伺服器暴露一組「工具」（tools）和「資源」（resources）。
一個典型流程如下：
- 啟動與協商：AI 客戶端啟動後，連線到已設定的 MCP 伺服器。伺服器會發送其能力清單，例如「我可以讀取檔案」、「我可以執行 SQL 查詢」。
- 使用者請求：使用者輸入「幫我檢查昨天伺服器的錯誤日誌，然後摘要給出原因」。
- AI 規劃：AI 解析需求，決定呼叫哪個 MCP 工具。它會產生一個結構化請求，例如
read_file(path="/var/log/nginx/error.log")。 - 伺服器執行：MCP 伺服器收到請求，執行對應操作（讀取檔案），並將結果傳回。
- AI 整理回應：AI 接收結果，可能再呼叫另一個工具（如資料庫查詢），最後用自然語言回覆使用者。
整個過程中，MCP 確保請求與回應格式一致，錯誤處理（如權限不足、檔案不存在）也遵循協定。
真實場景：用 MCP 自動除錯
我曾在一個專案中設定 MCP 讓 AI 直接操作 Docker 容器。具體做法是寫一個 MCP 伺服器，暴露兩個工具：exec_container（在容器內執行指令）和 read_logs（讀取容器日誌）。當我遇到容器崩潰時，只需問「看看 container abc 的崩潰日誌，並檢查記憶體使用量」，AI 就會依序呼叫 read_logs 和 exec_container，然後回報結果。這節省了我手動切換視窗、輸入指令的時間。
最容易踩的坑：權限與安全邊界
MCP 最大的風險是賦予 AI 過多操作權限。由於協定本身不強制安全限制，常見的失敗場景包括：
- 權限洩漏：如果你讓 AI 透過 MCP 存取檔案系統，它就能讀取所有檔案。若程式碼中存在敏感資訊（如 API key），可能被意外暴露。
- 無限迴圈：一個工具輸出被另一個工具當作輸入，形成不斷回呼的迴圈。例如，AI 讀取一個包含「另請閱讀 file B」的檔案，於是自己呼叫自己讀取 B，B 又指向 A，導致請求堆疊。
- 副作用失控：AI 呼叫一個寫入工具（如修改設定檔或傳送郵件），但未經使用者確認。
如何避免？
- 最小權限原則：每個 MCP 伺服器只賦予必要權限。例如，讀取日誌的伺服器不應該有寫入能力。
- 加入人工審核：在伺服器端實作「需要批准」的緩衝區，對高風險操作（如寫入、刪除）要求使用者手動確認。
- 設定逾時與計數：限制一次對話中工具呼叫的最大次數，或為每個呼叫設定逾時，防止無限迴圈。
失敗時的替代方案
MCP 並非適合所有場景。當面臨以下情況時，應考慮其他方案：
- 需要嚴格的事務控制：MCP 請求是獨立的，沒有跨請求的事務支援。若工具鏈必須保證原子性（例如轉帳扣款 + 通知），使用傳統 API 組合更可靠。
- 即時性要求高：MCP 的呼叫延遲包含 AI 的規劃時間和網路往返，不適合毫秒級回應的場景。
- 工具數量極大：如果一次要暴露上百個工具，AI 在規劃時可能困惑，選擇錯誤工具的機率上升。此時應考慮對工具分組，或改用專用代理（agent）。
下一步：從理解到實作
如果你打算在自己的專案中導入 MCP，可以先從小型工具開始：
- 使用 Python SDK（官方提供）快速建立一個簡單的檔案讀取伺服器。
- 在 Claude Desktop 或 VS Code 的 Cline 擴充套件中設定該伺服器。
- 讓 AI 執行一些低風險操作（如讀取專案中的特定檔案），觀察行為。
當你熟悉基本流程後，可以挑戰更複雜的整合，例如連結資料庫或雲端服務。記得持續監控安全邊界，別讓 AI 擁有超乎預期的控制權。
暂无评论，快来发表你的见解吧