MCP 與 A2A 協議實戰：讓 Agent 從「只會讀 code」變成「能操作整個開發環境」

Agentic Engineering 實戰手冊第 9 / 14 篇

這是「Agentic Engineering 實戰手冊」系列的第九篇。上一篇：CLAUDE.md 大師班

那一刻，我覺得未來到了（然後 Agent 把我的 Email 刪了）

第一次設定好 Chrome DevTools MCP，讓 Claude Code 直接操作我的瀏覽器的時候，我覺得這就是未來。Agent 可以自己開網頁、截圖、填表單、甚至跑 Lighthouse audit。

然後它在操作過程中，不小心把我正在寫的一封 email 給清空了。

那封 email 我寫了快半小時。

這個事件完美地總結了 MCP 的兩面性：它讓 agent 的能力從「讀 code 寫 code」跳躍到「操作你的整個開發環境」，但這種能力帶來的風險也呈指數級增長。

A2A 則是讓多個這樣的強大 agent 可以互相對話。想像不只一個 agent 有能力操作你的環境，而是一群。興奮嗎？害怕嗎？兩者都是正確的反應。

MCP：AI 的 USB-C

什麼是 MCP

Model Context Protocol（MCP）是 Anthropic 在 2024 年底提出的開放協議。最簡單的理解方式：

MCP 之於 AI agent，就像 USB-C 之於你的設備——一個統一的接口，讓任何 agent 可以連接任何工具。

在 MCP 之前，每個 AI 工具有自己的 plugin 系統。Cursor 有自己的 extension、ChatGPT 有自己的 Plugins、Claude 有自己的 tools。如果你想讓你的工具同時被三個 AI 使用，你得寫三套整合。

MCP 統一了這個介面。你寫一個 MCP server，所有支援 MCP 的 AI agent 都能用。

2025 年，MCP 被 Anthropic 捐給了 Linux Foundation 旗下的 AAIF（AI Alliance for Interoperability Foundation）。到了 2026 年，它已經被所有主要 AI 公司採用——Anthropic、OpenAI、Google、Microsoft、Amazon。SDK 的月下載量超過 9700 萬次（Python + TypeScript）。

它已經不是「Anthropic 的東西」了。它是產業標準。

MCP 的架構

你的 AI Agent（Claude Code / Cursor / etc.）
    ↕  MCP Protocol（JSON-RPC over stdio/HTTP）
MCP Server（一個小程式，暴露 tools 給 agent）
    ↕  實際操作
External System（Database / API / Browser / etc.）

MCP Server 就像一個翻譯官：它把外部系統的能力「翻譯」成 agent 能理解的 tool definition（輸入什麼、輸出什麼、做什麼），agent 就可以自主決定什麼時候呼叫哪個 tool。

MCP v2 的重要更新

MCP v2（2026 年初發布）帶來幾個重要改進：

Streamable HTTP transport：不再只限於 stdio，支援 HTTP 直接連接，更適合遠端部署
Multimodal 支援：可以傳遞 images、video、audio，不只是文字
OAuth 2.1 認證：標準化的認證流程，讓企業環境更容易導入
Elicitation：agent 可以透過 MCP 向用戶提問，實現更自然的互動

我的 Production MCP Stack

一年下來，我試過超過 20 個 MCP server。留下來持續在用的只有 5 個。

Tier 1：每天都用

Chrome DevTools MCP

用途：操控瀏覽器。截圖、填表單、跑 Lighthouse audit、監控 network requests。

使用場景：

自動跑 visual regression test（截圖 → 比對）
幫我在 NotebookLM 上自動操作（產生摘要素材）
填寫重複的表單（測試環境的 seed data）

踩過的坑：

Agent 不知道頁面載入需要時間，常常在 DOM 還沒渲染完就嘗試操作 → 需要在 prompt 裡提醒「等 page load 完」
開太多 tab 會讓 agent 搞混 → 限制每次只操作一個 tab
那封被刪的 email → 現在我永遠在 incognito window 裡讓 agent 操作

Notion MCP

用途：讀寫 Notion databases。我的 task management、knowledge base、project brief 都在 Notion 上。

使用場景：

讓 agent 直接讀取 Jira ticket 的內容（我用 Notion 做 task sync）
寫 session 總結到 Notion daily log
查找之前做過的決策紀錄

踩過的坑：

Notion API 的 block 格式很複雜，agent 常常建出格式不對的內容 → 我寫了一個 notion-block-format skill 來幫助它
Rate limiting：太頻繁的 API 呼叫會被 throttle

Tier 2：每週用幾次

Sentry MCP

用途：查詢 production error。Agent 可以直接搜尋 issues、看 stack trace、分析 error patterns。

Canva MCP

用途：產生社群圖片素材。Agent 可以生成設計、匯出不同格式。

Tier 3：偶爾用

自建的公司 API MCP

為工作專案自建的 MCP server，連接內部 API。讓 agent 可以查詢內部系統的資料。

MCP 的「少即是多」原則

重要的經驗：不要一次掛太多 MCP servers。

每個 MCP server 的 tool definition 都會佔用 context window。掛 10 個 MCP server，可能光是 tool descriptions 就佔了 context 的 15-20%。而且 agent 面對太多 tool 選項時，選擇的準確率會下降。

我的原則：一個 session 掛 3-5 個最相關的 MCP server。其他的，需要的時候再啟用。

自建 MCP Server 的經驗

什麼時候該自建

內部 API 整合：你的公司系統不會有現成的 MCP server
客製化的工作流：現成的 MCP server 不支援你需要的操作
效能優化：通用的 MCP server 可能做了太多你不需要的事

什麼時候不該自建

已有成熟的開源 MCP server：GitHub、Slack、Notion 等都有官方或社群維護的
Tool 的使用頻率很低：自建的維護成本不值得
可以用 HTTP Request 替代：如果只是呼叫一個 REST API，agent 通常可以直接用 fetch

架構要點

一個 MCP server 的核心就三件事：

Tool Definition：這個 tool 叫什麼、做什麼、接收什麼 input、回傳什麼 output
Input Validation：用 Zod 或 JSON Schema 驗證 agent 傳來的 input
Error Handling：明確的錯誤訊息，讓 agent 知道出了什麼問題

// 一個最小的 MCP tool 長這樣（概念示意）
{
  name: "query_orders",
  description: "Query recent orders from internal system",
  inputSchema: {
    type: "object",
    properties: {
      status: { type: "string", enum: ["pending", "shipped", "delivered"] },
      limit: { type: "number", default: 10 }
    }
  }
}

關鍵：description 寫得好不好，直接影響 agent 會不會正確使用這個 tool。這跟寫 spec 的邏輯一樣——越精確，agent 的表現越好。

A2A：Agent 之間的共同語言

什麼是 A2A

Agent-to-Agent Protocol（A2A）是 Google 在 2025 年 4 月提出的協議，後來捐給了 Linux Foundation AAIF（跟 MCP 同一個組織）。

如果 MCP 是「agent 跟工具對話」，A2A 就是「agent 跟 agent 對話」。

具體來說，A2A 解決三個問題：

Discovery：Agent A 怎麼知道 Agent B 存在、它會什麼？
Communication：Agent A 怎麼把任務發給 Agent B？
Collaboration：兩個 Agent 怎麼在一個任務上協作？

A2A 的核心概念

Agent Card：每個 agent 的「名片」，描述它的能力、支援的 input/output format、認證方式
Task：agent 之間傳遞的工作單元
Message / Artifact：任務過程中的通訊內容和產出物

目前的生態

A2A 在 2026 年 3 月已經發展到 v0.2。50+ 合作夥伴包括 Salesforce、PayPal、Deloitte、Box 等企業。IBM 的 ACP（Agent Communication Protocol）也已經合併進 A2A。

但說實話——A2A 目前還在非常早期。大部分的「支援 A2A」是概念驗證層級，不是 production 層級。

我目前怎麼用（或者說，還沒怎麼用）

坦白說，我日常工作裡還沒有真正的 A2A 使用場景。我的 multi-agent 架構——Claude Code + OpenClaw + n8n——它們之間的「通訊」是透過共享的 Markdown 檔案和 n8n webhook，不是透過 A2A 協議。

為什麼？因為 A2A 目前的基礎設施還不夠成熟。Agent Card 的 discovery 機制、認證流程、error handling——這些在 production 環境裡都還不夠穩定。

但我認為 A2A 在 12 個月內會變得重要。當 Claude Code 可以透過 A2A 直接跟 Devin 協作——一個負責前端、一個負責後端——那會是 multi-agent 的真正突破。

MCP vs A2A：互補而非競爭

這兩個協議經常被拿來比較，但它們解決的是不同的問題：

	MCP	A2A
連接什麼	Agent ↔ Tool	Agent ↔ Agent
比喻	USB-C（設備接周邊）	Wi-Fi（設備互聯）
目前成熟度	Production-ready	Early stage
主導者	Anthropic → AAIF	Google → AAIF
採用度	97M+ downloads	50+ partners（概念驗證）
你現在該用嗎	是	觀望，但要了解

實際場景：

Claude Code（我的 coding agent）
  ├── 透過 MCP → 操作 Chrome、讀寫 Notion、查 Sentry
  └── 未來透過 A2A → 跟 Devin 協作、跟 OpenClaw 交換 research 結果

MCP 是今天就能用的工具。A2A 是明天會需要的基礎設施。

協議的理想 vs 現實

理想

任何 agent 可以無縫連接任何工具（MCP），任何 agent 可以無縫跟任何其他 agent 協作（A2A）。一個統一的生態系，interoperable、secure、efficient。

現實

MCP 的現實問題：

Server 品質參差不齊——有些官方維護、品質高；有些社群貢獻、bug 多
認證和安全仍在完善中——OAuth 2.1 剛加入 v2，很多 server 還沒支援
Tool discovery 不夠好——你得自己知道有什麼 MCP server 可以用

A2A 的現實問題：

還在 v0.2——API 隨時可能改
缺乏 production 級別的 reference implementation
大部分 partners 是「承諾支援」而非「已經整合」

我的建議

現在就開始用 MCP——從 2-3 個最相關的 server 開始，逐步擴展
A2A 先了解概念，不急著整合——它的 API 還在變，過早投入可能做白工
關注 AAIF 的動態——兩個協議都在同一個組織下，未來的整合方向值得追蹤

Takeaway

MCP 讓 agent 從「只會讀 code」升級到「能操作你的整個開發環境」——但能力越大，風險越大。設好 sandbox 和 permission boundary（詳見 Agent 安全網設計），然後大膽使用。
A2A 讓 multi-agent 協作有了標準協議——但目前還在早期。值得了解概念和追蹤進度，但還不是 production 導入的時機。
兩個協議互補：MCP 管 agent-to-tool，A2A 管 agent-to-agent。它們一起構成了 agentic engineering 基礎設施的兩根支柱。MCP 是今天就能用的，A2A 是為明天準備的。

上一篇：CLAUDE.md 大師班 下一篇：Multi-Agent 編排實戰