2026年9月28日 星期一

MCP：Agent 時代的 USB-C——從 Anthropic 實驗到產業基礎設施

前言

2024 年 11 月，Anthropic 開源了一個看似不起眼的協議：Model Context Protocol（MCP）。不到兩年，它從「Anthropic 的一家實驗」變成 Linux Foundation 旗下 Agentic AI Foundation（AAIF）治理的產業標準，SDK 月下載量從 10 萬衝到上億，Forrester 預測 2026 年將有 30% 的企業應用廠商內建 MCP server。這篇文章完整拆解 MCP 的技術架構、生態現況、企業落地模式與安全治理，並附上實作入門。

一、MCP 解決什麼問題

傳統上，AI 應用每接一個外部系統就要寫一份專屬整合：行事曆一份、郵件一份、資料庫一份……N 個應用 × M 個服務 = N×M 份整合程式碼，越接越重。MCP 把它變成 N+M：N 個 client 實作加上 M 個 server 實作，中間用統一協議對接。Anthropic 官方給的比喻是「AI 應用的 USB-C」。

二、架構：Host、Client、Server 三件套

  • Host：使用者操作的應用程式，例如 Claude Desktop、Cursor、VS Code。
  • Client：Host 內部維護的協議客戶端，與 Server 保持一對一連線。
  • Server：提供能力的服務端，對外暴露三種原語：
    • Tools：可被模型呼叫的函式（查資料、寫檔案、打 API）。
    • Resources：唯讀的上下文資料（檔案內容、資料庫 schema）。
    • Prompts：可重用的提示模板。

傳輸層早期是 stdio（本地）與 SSE（遠端）；2026 年的規範已收斂到 Streamable HTTP，並走向 stateless 核心設計。

三、2026 的關鍵轉折：從公司協議到中立基礎設施

  • 2025 年 12 月：Anthropic 把 MCP 捐給新成立的 Agentic AI Foundation（AAIF，Linux Foundation 旗下的 directed fund），共同創辦人包括 Anthropic、Block 與 OpenAI，Google、Microsoft、AWS、Cloudflare、Bloomberg 表態支持。MCP 從此不再是一家公司的協議（Anthropic 公告）。
  • 2026 年 5 月：MCP Dev Summit North America 上，AAIF 公布 1.1 億月下載、170 個成員組織、1200 人與會（AAIF 回顧）。
  • 2026 年 7 月：第五版規範（2026-07-28）發布——stateless 核心、Tasks 與 Apps 擴充正式畢業、OAuth 2.0 / OIDC 授權強化。Anthropic 同步公布月下載突破 4 億（年增約 4 倍），Claude connector 目錄超過 950 個 server。
  • 2026 年 7 月：Google、Microsoft、Salesforce、Snowflake、ServiceNow 宣布共組企業 AI 後端協議聯盟（The Information 報導），被解讀為對 Anthropic 與 OpenAI 主導的 agent 基礎設施的制衡。有趣的是，這五家同時都是 AAIF 成員——用 Tech-Reader 的話說，「在基金會裡合作，在市場上廝殺」。

四、企業落地：從實驗到生產的三個模式

  1. 直連模式：開發者本機或小團隊直接連 MCP server，上手最快，但最難治理。
  2. Gateway／Proxy 模式：企業在中間架一層 MCP gateway，統一處理 SSO、授權、稽核軌跡（audit trail）與速率限制。2026 年預計 75% 的 API gateway 廠商會支援 MCP 功能，這正成為企業導入的主流姿勢。
  3. Registry 模式：內部維護 server 目錄，搭配 namespace 驗證（GitHub OAuth／OIDC、DNS／HTTP 網域驗證）防止冒充。

Token 經濟學：MCP 協議封裝本身每個 tool call 只多 15–60 個 token；真正的成本是塞在 system prompt 裡的 tool schema 膨脹。業界解法是 deferred loading——按需載入，用到的工具才把 schema 攤開。

五、安全與治理：不能跳過的一課

  • 每多接一個 tool，就是多一個 prompt injection 與資料外洩的攻擊面。Agent 每執行一次任務可能呼叫 5–10 個工具，任何一環出錯都會被放大。
  • 現實缺口：僅約 8.5% 的公開 MCP server 實作了規範要求的 OAuth 2.1 授權標準，生態熱度與安全成熟度之間還有落差。
  • 實務清單：最小權限的 tool 授權、server 身份驗證、完整的 audit log、敏感操作保留 human-in-the-loop 確認。

六、MCP vs A2A：互補，不是競爭

Google 在 2025 年推出的 Agent2Agent（A2A）協議同樣捐給了 Linux Foundation。兩者定位很清楚：MCP 是 tool-to-agent（agent 如何呼叫工具），A2A 是 agent-to-agent（不同廠商、不同框架的 agent 如何透過 Agent Card 互相發現能力並協作）。2026 年業界的共識是兩者互補，而非零和競爭。

七、實作入門：十分鐘建一個 MCP server（Python）

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("demo")

@mcp.tool()
def add(a: int, b: int) -> int:
    """兩數相加"""
    return a + b

@mcp.resource("config://app")
def get_config() -> str:
    """回傳應用設定"""
    return '{"env": "prod"}'

if __name__ == "__main__":
    mcp.run(transport="stdio")

一個常被低估的細節：tool 的 docstring 會直接變成模型看到的 schema 描述。把 docstring 寫清楚，就等於做了一半的 prompt engineering。

八、結論：什麼時候該用 MCP

  • 你的 agent 需要接 3 個以上外部系統 → 用 MCP 省下 N×M 整合債。
  • 團隊或企業內多人共用工具 → 走 gateway + registry 模式，治理先行。
  • 還在 prototype、只有 1–2 個工具 → 直接寫 function calling 也無妨，不必為協議而協議。

MCP 已經過了「要不要學」的階段，現在的問題是「怎麼在生產環境管好它」。先把 gateway、授權與稽核想清楚，再談規模化。

參考來源

張貼者： 於

沒有留言:

張貼留言

訂閱： 張貼留言 (Atom)