A2A 是什麼？為什麼 MCP 不是 AI Agent 的全部，下一場戰爭其實是 agent 對 agent
前提
排除
A2A 是什麼？為什麼 MCP 不是 AI Agent 的全部，下一場戰爭其實是 agent 對 agent
一句話結論：如果上一篇講的是「為什麼 coding agent 常常會回到 CLI，而不是把所有工具都包成 MCP」，那這一篇要回答的就是另一個更大的問題：當 agent 不只要叫工具，而是要叫別的 agent 時，誰來負責？ 這也是 A2A 開始變重要的原因。MCP 解的是 agent 對工具，A2A 想解的是 agent 對 agent。兩者不是互斥，而是 AI agent stack 開始分層的訊號。
Premise（前提）
- 你已經大概知道
MCP在做什麼，或至少看過最近關於MCP vs CLI的討論。 - 你現在想往前看一步：如果工具層不是全部，那多個 agent 之間到底怎麼協作？
- 你關注的不只是單一產品功能，而是 AI agent 生態會不會長出類似網際網路協議的分工。
- 你是開發者、產品人，或對 AI 產業方向有判斷需求的人，不想只看 buzzword。
- 你想知道接下來一年，
A2A是不是只是另一個新縮寫，還是真的代表新的戰場。
Exclusions（排除）
- 你現在只想知道怎麼寫 A2A server/client：你需要的是實作教學，不是這篇。
- 你只在意單一 agent 怎麼接資料庫、檔案或 API：那你更該先看
MCP，不是這篇。 - 你只想看「Google 又出新東西」的新聞摘要：這篇重點不是發表會 recap，而是判斷它在整個 stack 裡的角色。
- 你期待單一協議一統天下：這篇的結論剛好相反，未來更像分層協議共存。
- 你完全不在意 agent orchestration、delegation、long-running task、或跨組織協作：那
A2A對你現在的價值不高。
先講結論：A2A 之所以重要，不是因為它要取代 MCP
很多人第一次看到 A2A，第一反應是：
所以這是下一個 MCP？還是 Google 版 MCP？
這個理解很容易，但也很容易錯。
因為從官方定位來看，A2A 處理的不是同一個問題。
它的核心描述很直接：
an open standard that enables seamless communication and collaboration between AI agents
換句話說，A2A 想做的不是讓模型更容易叫工具，而是讓：
- 不同框架做的 agent
- 不同公司做的 agent
- 跑在不同伺服器上的 agent
- 屬於不同組織的 agent
可以有一種比較標準化的方式互相溝通、發現能力、委派工作、回報長任務結果。
所以你不能把它理解成「另一個 tool calling 規格」。
更準的說法是：
MCP 把世界裡的外部能力暴露成 agent 可用的工具；A2A 則想讓 agent 本身成為可被別的 agent 調用的合作單位。
這個差異看起來抽象，但它其實非常重要。
為什麼 MCP 不夠？
這不是說 MCP 不好，而是它本來就不是為了所有事情設計的。
MCP 最擅長的是：
- tool exposure
- data / resource access
- workflow integration
- 結構化能力暴露
也就是說，它很適合做：
- 查資料庫
- 拿文件
- 用搜尋工具
- 接第三方服務
- 把既有 workflow 變成 agent 可調用能力
但當你遇到下面這種場景時，事情就開始變了：
- 一個 travel agent 要找 flight agent、hotel agent、currency agent 一起完成任務
- 一個企業內部 orchestrator agent 要把任務分給法務 agent、財務 agent、採購 agent
- 一個 coding agent 想委派另一個專門做測試、另一個專門做 review
在這種情況下，如果你還把「另一個 agent」包成普通 tool 來用，會開始出現幾個問題：
1. agent 不是普通工具
工具通常比較像：
- stateless
- 單次呼叫
- 功能邊界明確
- 回傳格式固定
但 agent 往往不是這樣。
agent 更像：
- 有自己的能力描述
- 可能需要多輪互動
- 可能要澄清需求
- 可能執行很久
- 可能回傳的是 task 狀態、artifact、stream，而不是單一結果
也就是說，把 agent 硬包成 tool，有時候會把它的能力壓扁。
2. point-to-point integration 很快會失控
如果每個 agent 之間都自己接：
- 一套自定義 API
- 一套自定義 auth
- 一套自定義 status callback
- 一套自定義 streaming
那你很快就會掉進 integration hell。
這也是 A2A 官方文件一直強調的點：
沒有標準時，跨 agent 協作會變成大量 bespoke integration。
3. 長任務與 opaque collaboration 不是 MCP 的主場
A2A 官方文件強調幾個關鍵字：
- long-running operations
- streaming
- opaque execution
- capability discovery
這些東西其實都在說同一件事：
A2A 想讓 agent 保留自己的自治與內部邏輯，同時又能被別的 agent 當成合作對象。
這和 tool calling 的心智模型不太一樣。
A2A 到底在解什麼問題？
如果你把官方文件讀白話一點，A2A 在解的大概是四件事。
1. agent discovery
別的 agent 怎麼知道你會什麼？
A2A 的答案是：
讓 agent 透過類似 Agent Card 這樣的方式公開自己的能力描述、連線資訊、支援模態與安全需求。
這很像把「可被合作的能力」標準化，而不是靠人手動寫 integration doc。
2. agent collaboration
不是每個問題都該由一個巨型 agent 全包。
很多真實場景更像：
- 一個總控 agent 接到任務
- 它判斷需要哪些專門 agent
- 它把任務分派出去
- 再把結果整理回來
如果沒有標準化的協作方式，這種架構很快會變得又脆又難維護。
3. long-running task lifecycle
很多 agent 工作不是 request/response 一次結束，而是：
- submitted
- working
- partial artifacts
- completed
這也是 A2A 特別強調 streaming、SSE、async execution 的原因。
它不是只想傳一個結果，而是想描述一個任務生命週期。
4. opaque execution
這是我覺得最容易被低估的一點。
A2A 官方文件反覆強調：agent 可以互相合作，但不需要暴露內部記憶、工具或 proprietary logic。
這件事很重要，因為現實世界裡很多 agent 不會願意把自己的：
- prompt
- memory
- internal tools
- business logic
- 專有資料流程
全部攤給別人看。
所以 A2A 的思路不是「把大家都攤平」，而是：
讓 agent 像 service 一樣可以被合作，但不必失去邊界。
這篇真正想講的是：AI agent stack 正在長出分工
如果你把最近幾個協議放在一起看，畫面就會比只看 MCP 清楚很多。
目前最容易理解的分法大概是：
- agent-to-tool：
MCP - agent-to-agent：
A2A - agent-to-user interaction：
AG-UI
AG-UI 官方文件甚至直接把這三層並列，說它們是 complementary protocols，而且一個 agent 往往會同時用到三者。
這個訊號很重要，因為它意味著：
AI 生態不是在等一個單一終極協議，而是在長出像網路協議棧一樣的分層。
這也讓我更不相信下面這種說法：
下一個標準會把全部問題一次解完
我反而更相信未來會長得像這樣：
- 你用
CLI或MCP處理工具層 - 你用
A2A處理 agent collaboration - 你用
AG-UI處理前端互動與 event flow
也就是說，真正的戰爭不是「誰一統」，而是：
誰先在自己的那一層變成預設。
那 A2A 真的會成嗎？
這裡我會保守一點，不會直接喊它一定會贏。
我看好它的理由
1. 問題真的存在
agent-to-agent collaboration 不是假需求。
只要 multi-agent、delegation、cross-org workflow 持續存在，這層就需要某種標準化。
2. 它的問題定義很清楚
很多新協議失敗，是因為問題本身模糊。
但 A2A 的問題其實很明確：
- agent 怎麼被發現？
- agent 怎麼被調用？
- 長任務怎麼追蹤？
- 不透明邏輯怎麼被保留？
這些都是真問題。
3. 它不是硬和 MCP 搶同一個位置
這反而是它比較有機會活下來的地方。
如果它想當「更好的 MCP」，那會很辛苦；但如果它定位成 MCP 補不到的那一層，合理性就高很多。
我保留的地方
1. 真正採用速度還不明朗
一個協議寫得漂亮，不代表會形成真正採用。
關鍵還是要看：
- 主流 agent framework 有沒有內建
- 大型平台有沒有默認支持
- 開發者有沒有感覺「不用不行」
2. 很多團隊短期內會先用內部私規撐
這點很現實。
很多團隊在 agent 還沒成熟前，未必會急著上 A2A，可能先自己做內部 orchestration 與 callback。
3. 它容易被過早神化
這也是我現在最警惕的地方。
如果社群開始把 A2A 講成「未來 agent internet 的終極答案」，那它就很容易重演 MCP 先被吹高、再被 backlash 的路。
真正值得追的，不是 A2A 這個名字，而是這種問題開始被獨立對待
即使你最後不押 A2A 本身，我還是認為這個題目值得關注。
因為它代表一件更大的事：
市場已經不再假設「一個 agent + 一堆 tools」就能解決所有場景。
當這件事開始被廣泛承認後，很多設計思路都會變：
- orchestration 不再只是 prompt engineering
- delegation 不是把別人包成一個 function 就好
- multi-agent 不是 marketing 詞，而是架構問題
- 互通性不只是 tool calling，而是 agent calling
這也是為什麼我會說：
如果上一篇 MCP vs CLI 在講的是工具層分裂，這一篇 A2A 真正在講的是：
agent 本身開始被視為網路上的一級公民。
最後的低後悔建議
如果你只想抓最實用的結論，我會這樣建議：
- 如果你還在單一 agent + tool 的階段：先把
CLI/MCP想清楚，不必急著上A2A。 - 如果你已經在做 multi-agent orchestration：開始關注
A2A，因為你很可能已經踩在它要解的問題上。 - 不要把
A2A當成另一個 buzzword 收藏：真正要觀察的是，主流框架與平台會不會把 agent discovery、task lifecycle、opaque collaboration 變成默認能力。 - 重新理解 AI agent 戰爭：不是模型戰被協議戰取代，而是整個 stack 開始長出更多值得搶的位置。
如果你問我這篇真正想給你的結論是什麼，我會用一句話收掉：
MCP 不是 AI agent 的全部；當 agent 開始真的要和 agent 協作時，A2A 代表的是下一層戰爭。
資料來源說明
本文主要根據以下公開資料整理：
- A2A 官方文件：
What is A2A? a2a-protocol.org與 A2A 官方 README- AG-UI 官方文件：
MCP, A2A, and AG-UI - 既有 MCP 官方文件與相關開發者文件
這些協議與採用情況仍在快速變動，這篇更適合拿來建立判讀框架，而不是當成最終定論。