A2A 協定：MCP 之後，多個 AI 代理怎麼互相對話與協作

一家做電商的客戶，半年內導入了四個 AI 代理：一個跑在客服系統裡回答問題，一個掛在行銷平台上寫文案，一個接在 ERP 旁邊看庫存，還有一個是外包夥伴提供的物流查詢代理。單獨看每一個都聰明，湊在一起卻像四個講不同方言的部門，客服代理算出「這位客人很可能要退貨」，卻沒有任何管道把這個判斷交給庫存代理去預留調撥；行銷代理想針對低庫存商品停投廣告，得靠工程師手寫一段 API 把兩邊接起來。每多接一對，就多一段客製膠水程式碼，維護成本像滾雪球。

問題的根不在哪個代理不夠強，而在它們之間沒有共通語言。這正是 A2A（Agent2Agent，代理對代理）協定要解的事：讓不同廠商、不同框架寫出來的 AI 代理，能用一套標準互相發現彼此的能力、指派任務、回報結果，而不必為每一對關係重寫一次膠水。如果你讀過我們談 MCP 讓代理接上工具 的那篇，A2A 是它自然的下一章：上一篇談的是「一個代理怎麼接上外部工具」，這一篇談的是「一個代理怎麼接上另一個代理」。兩者合起來，才構成多代理系統完整的通訊層。

為什麼不乾脆做一個什麼都會的「超級代理」就好？

每次跟客戶談多代理，最先被問的都是這句：與其讓一堆代理互相喊話，不如把功能全塞進一個無所不能的大代理，不是更單純嗎？聽起來合理，實務上有幾個結構性理由讓「單一超級代理」很難走遠。

第一，能力邊界會互相稀釋。一個代理塞進太多職責，提示詞和工具清單會膨脹到互相干擾，客服的語氣要求可能污染財報分析的嚴謹度，工具一多，模型選錯工具的機率也跟著上升。把職責切開、各司其職，每個代理的行為反而更可預測，這跟我們在 代理工具使用邊界設定 裡談的收斂原則是同一套邏輯。

第二，組織與廠商邊界是現實。企業裡的代理不會都出自同一個團隊，客服代理可能是 SaaS 廠商提供的，內部知識代理是自己用開源框架搭的，物流代理則屬於外部合作夥伴，你根本沒有權限也沒有意願把別人的代理拆進自己的大代理。多代理協作接受了這個現實：讓各自擁有的代理保留邊界，只在需要時對話。

第三，獨立擴縮與維運。把功能拆成獨立代理，就能各自更新、各自擴容、各自監控。行銷代理要換模型時，不會逼得客服代理一起重測；某個代理掛了，其他的還能運作。這跟微服務取代單體應用的道理一樣，只是主角換成了會自己判斷的代理。

第四，這是 2026 的產業共識方向。從各大雲廠到開源社群，賭的都是「多個專職代理協作」而非「一個巨獸包辦」。當基礎設施、標準、工具鏈都往多代理靠攏，逆勢自建大一統代理，等於放棄整個生態的紅利。台灣企業要落地，可以先看我們整理的 台灣企業 AI 代理導入指南 對照自己的組織現況。

那 A2A 到底是什麼？它解決了哪一段？

A2A 是一套開放協定，最早由 Google 在 2025 年 4 月 9 日發布，一開始就帶著 50 多家技術夥伴，包括 Atlassian、Box、Cohere、Intuit、LangChain、MongoDB、PayPal、Salesforce、SAP、ServiceNow、Workday，以及 Accenture、Deloitte、McKinsey 等一線顧問服務商。同年 6 月 23 日，Google 把 A2A 捐給 Linux Foundation 中立託管，讓它從「某一家的協定」變成「產業共有的標準」。它刻意建立在 HTTP、Server-Sent Events（SSE）、JSON-RPC 這些既有網路標準之上，目的就是好接進企業現有的 IT 骨架，而不是逼大家換一套新東西。

A2A 的運作可以拆成三個核心概念，理解了這三個，大致就懂它在做什麼。

能力發現：Agent Card。每個 A2A 代理會對外發布一份叫 Agent Card 的 JSON 文件，寫清楚自己是誰、會做哪些技能（skills）、服務端點在哪、要用什麼方式認證、支不支援串流。另一個代理要找幫手時，就是靠讀這張卡片來判斷「這個代理能不能做我這件事」。這解掉了多代理最前端的問題：代理彼此根本不認識，要先有一套標準的自我介紹格式，才談得上協作。

任務生命週期。A2A 把一次協作抽象成一個有唯一 ID、有狀態的「任務（Task）」。任務會在幾個明確定義的狀態間流轉：已提交（submitted）、處理中（working）、完成（completed）、失敗（failed）、取消（canceled），還有需要補輸入（input-required）、需要認證（auth-required）、被拒絕（rejected）這些中斷或終止狀態。因為狀態是標準化的，委派方隨時查得到「我丟出去那件事現在到哪了」，長時間的任務也能透過串流或 webhook 推播進度，而不是丟出去就石沉大海。

訊息與產出物。協作過程中來回的對話叫 Message，最終交付的成果叫 Artifact。規格特別強調：溝通用 Message，但真正的任務結果應該用 Artifact 回傳，兩者分開，讓「過程」和「交付」清清楚楚。認證方面，A2A 支援 API key、HTTP 認證、OAuth 2.0、OpenID Connect、mutual TLS 多種機制，方便對接企業既有的身分系統。到 2026 年中，A2A 規格已經推進到 1.0.0 正式版，代表核心介面趨於穩定。

A2A 和 MCP 到底誰管什麼？一張表看懂分工

這是最多人搞混的一段。簡單記一個方向感：MCP 是垂直的，A2A 是水平的。MCP 讓「一個代理」往下接到外部工具與資料（查資料庫、呼叫 API、讀文件）；A2A 讓「一個代理」往旁邊接到「另一個代理」，把某段工作委派出去。Google 在 A2A 的官方發布文裡講得很白：「A2A 是一套開放協定，補完 Anthropic 的 Model Context Protocol（MCP），MCP 為代理提供有用的工具與情境。」兩者不是二選一，而是拼在一起才完整。

放進開頭那個電商例子就很清楚：客服代理用 MCP 去讀訂單資料庫（垂直取用工具），判斷客人可能退貨後，再用 A2A 把「請預留調撥庫存」這件任務丟給庫存代理（水平委派）。少了 MCP，代理拿不到資料；少了 A2A，代理各做各的、無法接力。值得一提的是，2025 年 12 月 Linux Foundation 成立了 Agentic AI Foundation（AAIF），把 MCP 正式納入託管，白金會員橫跨 AWS、Anthropic、Google、Microsoft、OpenAI、Block、Bloomberg、Cloudflare，等於把這兩條協定線收攏到同一個中立治理的傘下，對企業來說是「賭這套標準不會突然消失」的一個定心丸。

A2A 現在到底多成熟？誰在用、跑在哪裡？

談標準，最怕押到一個沒人用的規格。A2A 這一年的成長曲線可以拿來當參考。根據 Linux Foundation 在 2026 年 4 月 9 日（A2A 滿一週年）發布的公告，支持組織已從 2025 年 4 月的 50 多家成長到超過 150 家，核心程式庫 GitHub 星數突破 22,000，SDK 從單一 Python 擴展到 Python、JavaScript、Java、Go、.NET 五種生產級語言，並已整合進三大公有雲的代理平台。

雲端整合的現況是：Microsoft 把 A2A 接進 Azure AI Foundry 與 Copilot Studio，AWS 接進 Amazon Bedrock AgentCore Runtime，Google Cloud 則是深度整合。Linux Foundation 的公告也點名，A2A 已在供應鏈、金融服務、保險、IT 維運等產業有實際的生產部署，不再只是實驗室裡的展示。對台灣企業技術決策者來說，這代表一件務實的事：不管你主要用哪一朵雲，A2A 大概率已經是平台原生支援的選項，導入的門檻比一年前低了不少。

企業導入 A2A，實務上要盯哪幾件事？

標準成熟不等於閉著眼睛上。以我們幫客戶落地的經驗，A2A 真正的難點不在接得起來，而在治理與資安。

信任邊界要先畫。A2A 的價值是讓代理能把任務委派出去，但這也意味著你把一部分決策權和資料存取往外延伸。哪個代理能呼叫哪個代理、能傳哪些欄位的資料、對方回來的結果要不要人工覆核，這些得在導入前就定義清楚。A2A 規格支援 OAuth 2.0、OpenID Connect、mTLS 等認證，但認證只擋「是不是本人」，擋不了「這個人該不該做這件事」，後者是治理設計的責任，可以參考我們談 企業 AI 代理資安與存取控制 的整理。

容錯與重試要當一等公民。多代理協作是分散式系統，被委派的代理可能超時、可能失敗、可能回一個你沒預期的狀態。A2A 的任務生命週期已經把 failed、input-required 這些狀態標準化，但你的編排層要真的去處理它們，而不是只接 happy path。這套「預設會出錯」的設計思維，跟我們寫 n8n 韌性工作流與重試設計 的原則完全相通。

可觀測性不能省。當一件事跨越三四個代理，出問題時最痛的是「不知道卡在哪」。任務 ID、狀態流轉、每一跳的耗時都要留紀錄，否則除錯會變成大海撈針。導入前先想清楚監控與日誌怎麼收，比事後補救省太多。

算清楚值不值得。多代理協作有它的複雜度成本，不是每個場景都划算。導入前把預期省下的人力、換來的維運複雜度攤開來比，我們在 評估 AI 代理隱藏 ROI 那篇提供了一套算法，避免為了「用上最新標準」而過度工程。

該用 A2A、MCP、還是一條簡單的 API 就好？

選型的關鍵，是先認清你手上的問題屬於哪一類。以下四種情境幫你快速對號入座。

什麼時候該用 A2A

當你有「多個會自主判斷的代理」，而且它們來自不同廠商或不同框架，需要動態地互相委派任務時，A2A 是對的工具。典型訊號：代理 A 拿到任務後，要不要找代理 B、找誰、傳什麼，是視情況決定而非寫死的；或你需要跟外部組織的代理對接。你若正在用 Antigravity 這類多代理工作流工具 做編排，A2A 就是讓這些代理跨出單一工具邊界、跟外部代理對話的那層標準。

什麼時候該用 MCP

當你的問題是「單一代理需要接上外部工具或資料」時，用 MCP，不需要 A2A。查資料庫、呼叫內部 API、讀文件、接一個 SaaS 的功能，這些都是垂直取用，MCP 就是為此而生。細節與它跟傳統 API、CLI 的差別，我們在 MCP、API、CLI 怎麼選 講得很完整。多數企業其實是先把 MCP 用好，代理接得到自己該接的工具，之後才有必要往 A2A 走。

什麼時候一條簡單的 API 或自動化平台就夠

如果你要串的是「固定流程、規則明確、不太需要判斷」的整合，別急著搬代理協定，一條 REST API 或 n8n、Make、Zapier 這類自動化平台通常更划算也更好維護。判斷標準很簡單：這段流程需不需要 AI 去「決定下一步做什麼」？不需要的話，用 n8n、Make、Zapier 比較 裡的工具畫好流程就好，硬套 A2A 只是徒增複雜度。

什麼時候還太早、先別碰

如果你連第一個 AI 代理都還沒穩定跑在生產環境，或組織內只有單一廠商、單一框架的代理，現在導入 A2A 多半是提前優化。A2A 的甜蜜點是「異質、多代理、需要跨界協作」，這些條件還沒到之前，把力氣花在把單一代理和它的 MCP 工具鏈做紮實，投報率更高。標準會等你，急著上不會加分。想全面看懂多代理這波的來龍去脈，可以讀 代理革命的背景整理。

資料來源與延伸連結

本文所有數據與定義均來自下列官方或第一手來源，並經交叉查證，資訊查證於 2026 年 7 月 13 日；AI 代理協定生態變動快速，引用時請以來源頁面的最新版本為準。

• Google Developers Blog：Announcing the Agent2Agent Protocol (A2A)（2025-04-09，A2A 發布與互補 MCP 定位）
• Linux Foundation：A2A 一週年成長數據與雲端整合（2026-04-09）
• Linux Foundation：A2A 專案正式成立公告（2025-06-23）
• A2A 官方規格：Agent2Agent Protocol Specification（v1.0.0）
• Linux Foundation：Agentic AI Foundation（AAIF）成立，MCP 納入治理（2025-12-09）

延伸閱讀

• MCP、API、CLI 到底差在哪？2026 白話拆解
• 台灣企業 AI 代理導入指南
• n8n、Make、Zapier 自動化平台比較
• 2026 企業 AI 代理資安與存取控制

想把多個 AI 代理真正串成一條龍？

多代理協作的價值不在追最新標準，而在讓對的代理在對的時機接力做對的事。浪花科技幫台灣企業做 AI 代理與自動化開發，從單一代理的工具接入、到跨代理的 A2A 協調、再到治理與資安落地，用顧問視角陪你判斷什麼該上、什麼該緩。也可以看看我們的 企業系統客製與整合 怎麼把這些代理接進你既有的系統。想聊聊你手上那幾個「各說各話」的代理，直接跟我們聯絡，我們先幫你把問題盤清楚。