MCP 讓 AI agent 能連工具，A2A 則回答另一個問題：agent 和 agent 要怎麼溝通？
Google 推出的 Agent2Agent protocol（A2A）目標是讓不同框架、不同供應商、不同部署環境的 agents 能互相協作。這在企業場景很重要，因為未來不會只有一個全能 agent，而會有多個專職 agents。
A2A 和 MCP 差在哪？
| 協定 | 解決問題 |
|---|---|
| MCP | Agent 如何連接工具、資料、檔案、API |
| A2A | Agent 如何和其他 agent 協作、委派、回報任務 |
| WebMCP／NLWeb | 網站如何提供 agent 可讀介面 |
可以這樣理解：
- MCP 是「agent ↔ tool」。
- A2A 是「agent ↔ agent」。
兩者處理不同層次，可以互補使用。
A2A 適合什麼場景？
假設企業裡有多個 agents：
| Agent | 任務 |
|---|---|
| Sales agent | 整理客戶需求 |
| Finance agent | 檢查預算與付款條件 |
| Legal agent | 檢查合約條款 |
| Procurement agent | 找供應商並詢價 |
| IT agent | 建立系統帳號與權限 |
如果每個 agent 都是獨立孤島，跨部門流程仍要人手動接。A2A 的目標是讓 agents 能用共同語意協作，例如委派任務、等待長任務、回傳結果、要求人類確認。
它為什麼需要標準？
沒有標準時，每家平台都會做自己的 agent-to-agent API。結果就是：
- 每串接一個 agent 就要寫 adapter。
- 權限模型不一致。
- 任務狀態難追。
- audit log 分散。
- long-running tasks 難管理。
- 人類介入流程不一致。
A2A 嘗試把任務語意、訊息格式、協作方式標準化。
多 agent 的風險
多 agent 不代表更聰明。有時只是把錯誤放大。
常見風險：
- Agent 身份不清楚。
- 任務被錯誤委派。
- 權限過大。
- 多個 agent 互相重試造成成本失控。
- 責任鏈斷裂。
- 沒有人知道最後決策怎麼來。
- Prompt injection 從一個 agent 傳到另一個 agent。
所以 A2A 的導入重點是可控協作，不能只讓 agents 自由聊天。
協定解決了通訊格式，卻不會替團隊決定何時委派、交出多少資料或何時停止。若要把這些條件寫成可驗收規則，可以接著看 Google DeepMind 的 AI 委派研究；其中的任務契約、成本路由、最小資料揭露與上游覆核，正好補上 A2A 之外的決策層。
若 Agent 還需要呼叫資料庫、瀏覽器或企業工具，則應另外規劃 MCP 的工具連接與權限邊界。A2A 管 Agent 之間的交接，MCP 管 Agent 如何取得工具與上下文，兩層都要留下可追蹤紀錄。
企業導入檢查清單
| 問題 | 為什麼重要 |
|---|---|
| Agent 身份是否可驗證？ | 避免假 agent 或錯誤委派 |
| 權限是否最小化？ | Agent 只應做被授權任務 |
| 任務狀態是否可追蹤？ | 長任務需要 audit |
| 是否支援 human approval？ | 高風險流程不能全自動 |
| 錯誤如何回復？ | 多 agent 失敗可能連鎖 |
| 是否有成本上限？ | 防止重試風暴 |
和企業 agent 平台的關係
Google 在 Vertex AI、Gemini Enterprise、ADK、Agent Engine 裡推 agent 生態，A2A 是其中的互通層。
未來企業可能同時有：
- Google ADK agents。
- OpenAI Agents SDK agents。
- LangGraph agents。
- Salesforce agents。
- ServiceNow agents。
- 自建內部 agents。
A2A 的長期價值，就是讓這些 agents 不必靠一堆脆弱 webhook 串接。
結論
A2A 的出現，代表 AI agent 生態正在從單一工具，走向多 agent 協作。
MCP 讓 agent 連工具，A2A 讓 agent 連 agent。真正能不能進企業 production，不取決於協定名字，而取決於身份、授權、任務邊界、審計與 human-in-the-loop 是否設計好。
多 agent 是未來，但不是捷徑。先把單一 agent 做可靠，再談 agent-to-agent 協作。