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 延伸到操作外部系統，但風險不是抽象的「指數成長」，而是取決於它拿到哪些帳號、資料與寫入權限。

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 年底，Anthropic 把 MCP 捐給 Linux Foundation 新成立的 AAIF（Agentic AI Foundation）。多家模型、雲端與開發工具廠商已經支援或參與生態，但每個 client 實作的功能與安全邊界仍不完全相同。

它已經不是只能綁 Anthropic 產品的私有介面；更精確地說，它是一個快速普及、由基金會治理的開放協議。採用度很高，不代表所有 server 都同樣成熟。

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 規格使用日期版號，例如 2025-11-25，不是「v2」。功能也分散在不同修訂加入：目前穩定規格包含 authorization 改進、elicitation、tool calling 與實驗性 tasks 等；標準 transport 則是 stdio 與 Streamable HTTP。

因此看到某個 client 或 server 宣稱「支援 MCP」，還要再問三件事：支援哪個 protocol revision、哪些 capabilities、用哪種 transport。不能用一個「v2」標籤把 OAuth、multimodal 與 elicitation 全部當成必備功能。

我的 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 → 現在改用獨立瀏覽器 profile 與測試帳號。Incognito 只是不保留一般瀏覽資料，不能取代權限隔離與操作前確認

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。

Tool 名稱與描述需要讓 client／模型知道；不同產品可能延後載入完整 schema，所以不能用固定的 15–20% 估算。比較穩定的風險是：工具越多，權限面與選錯工具的可能性越大，也更難排查哪個連線失效。

我的原則：只開當前任務需要的 server。有時是一個，有時超過五個；數量不如最小權限、描述清楚與連線可觀測重要。

自建 MCP Server 的經驗

什麼時候該自建

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

什麼時候不該自建

已有可信且維護中的 MCP server：先確認發布者、權限範圍、更新頻率與原始碼，不要把「社群有做」等同官方背書
Tool 的使用頻率很低：自建的維護成本不值得
只是固定、低頻的 API 呼叫：直接用既有 SDK 或受控 HTTP client 可能更簡單；但仍要處理 schema、認證、audit log 與錯誤，不是「讓 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

Agent2Agent Protocol（A2A）是 Google 在 2025 年 4 月提出的協議。2025 年 6 月，Google 把規格、SDK 與工具捐給 Linux Foundation 的獨立 Agent2Agent project。它與 AAIF 旗下的 MCP 都在 Linux Foundation 生態中，但不是一開始就屬於同一個專案。

如果 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 年發展到 v1.0，官方也提供多語言 SDK、Inspector 與相容性測試相關工作。本文初稿寫的 v0.3 已經過期。

v1.0 代表規格進入穩定里程碑，不代表你的供應商、認證與觀測工具都已成熟。是否能上 production，要看實際互通測試、失敗恢復、安全需求與團隊維運能力，不能只看版本號。

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

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

為什麼？因為我現在的流程在單一信任邊界內，用 webhook 與檔案已經夠用；引入 A2A 會多出 discovery、認證、版本協商與觀測成本，還沒有對應收益。這是我的需求判斷，不是說 A2A v1.0 不能進 production。

當你需要跨框架、跨廠商，甚至跨組織交換長任務時，A2A 的價值才會明顯。至於哪些 coding agent 會在何時互通，應以各產品正式支援為準，不先替它們寫 roadmap。

MCP vs A2A：互補而非競爭

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

	MCP	A2A
連接什麼	Agent ↔ Tool	Agent ↔ Agent
比喻	USB-C（設備接周邊）	Wi-Fi（設備互聯）
目前規格	日期版號，穩定版 `2025-11-25`	v1.0
治理	Anthropic 發起 → Linux Foundation AAIF	Google 發起 → Linux Foundation Agent2Agent project
適用判斷	工具整合有明確需求時	跨 agent 互通有明確需求時
你現在該用嗎	先做權限與 server 評估	先做互通與維運成本評估

實際場景：

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

畫成圖會更清楚——兩種協議是往不同方向長的：

flowchart LR
    CC["Claude Code<br/>我的 coding agent"]
    CC -->|"MCP"| T1["Chrome"]
    CC -->|"MCP"| T2["Notion"]
    CC -->|"MCP"| T3["Sentry"]
    CC -.->|"A2A（未來）"| A1["Devin"]
    CC -.->|"A2A（未來）"| A2["OpenClaw"]

實線往下是 MCP：接的是沒有自主性的工具，我叫它做什麼它就做什麼。虛線往右是 A2A：接的是另一個會自己思考、自己決定怎麼做的 agent——對方不是被我呼叫的函式，而是一個我只能提出請求、無法控制其內部行為的對等系統。

兩者今天都可以用，也都可能不需要。差別在你要連的是工具，還是另一個獨立 agent 系統。

協議的理想 vs 現實

理想

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

現實

MCP 的現實問題：

Server 品質參差不齊——有些官方維護、品質高；有些社群貢獻、bug 多
認證與安全需要 client、server 和部署者一起做對；協議支援 authorization，不代表每個實作都安全
Tool discovery 不夠好——你得自己知道有什麼 MCP server 可以用

A2A 的現實問題：

v1.0 才剛成為穩定里程碑，各產品支援版本可能不同
跨廠商的認證、觀測、重試與長任務恢復仍要實測
官方 SDK 與工具已存在，但不會替你解決業務層的信任與責任邊界

我的建議

有清楚的工具整合需求再用 MCP——先從最小權限的一個 server 開始，記錄它能讀寫什麼
有跨 agent 互通需求再評估 A2A——先驗證兩端版本、認證、重試與人工接管
追蹤各自的官方規格與治理——不要用「MCP v2」或舊版 A2A 文章代替現行文件

Takeaway

MCP 把外部工具變成 agent 可呼叫的能力——先設 sandbox、最小權限、測試帳號與人工確認點，再依風險逐步開放。
A2A v1.0 為跨 agent 協作提供穩定規格里程碑——能不能進 production 取決於兩端實作與你的維運條件，不宜一概說現在太早或一定該上。
兩個協議互補：MCP 偏 agent-to-tool，A2A 偏 agent-to-agent。先從問題選協議，不要從熱門協議反推問題。

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