A2A 協定是什麼？AI Agent 之間怎麼「找到彼此、談合作」，跟 MCP 有什麼不同

5天前

讀畢需時 7 分鐘

A2A（Agent2Agent）協定，是一套讓不同公司、不同框架打造出來的 AI Agent，能夠互相找到彼此、公開聲明自己能做什麼、並且把工作安全委派給對方執行的開放通訊標準。它由 Google 在 2025 年 4 月發起，同年 6 月捐贈給 Linux Foundation，2026 年 3 月推出第一個正式穩定版 v1.0，並在 2026 年 8 月 27 日以「Growth Stage（成長階段）」專案身分，加入新成立的 Agentic AI Foundation（AAIF），跟 Model Context Protocol（MCP）、開源 Agent 框架 goose、以及規範 Agent 行為的 AGENTS.md 並列為旗下專案。如果你已經讀過本站另一篇談 MCP 2026-07-28 規格改版的文章，可以先記住一句話：MCP 負責「Agent 怎麼連上自己的工具跟資料」，A2A 負責「不同公司做出來的 Agent，怎麼互相委派任務」。這篇文章把 A2A 到底怎麼運作、目前發展到哪一步，以及企業評估導入多 Agent 系統時該注意什麼，一次講清楚。

A2A 協定是什麼？跟 MCP 的分工在哪裡

A2A 官方部落格用「水平協作層」（horizontal orchestration layer）形容自己，對照 MCP 的「垂直整合層」（vertical integration layer）。MCP 定義的是一個 Agent 怎麼連上自己內部的工具、資料庫、檔案系統；A2A 定義的是不同公司、不同框架做出來的獨立 Agent，怎麼互相發現彼此的能力、委派任務、交換結果——而且不需要存取對方的原始碼、記憶或工具實作細節。A2A 官方規格把這條原則稱為「Opaque Execution（不透明執行）」：Agent 之間只根據對方公開宣告的能力合作，不用也不該互相打開對方的黑盒子。

核心概念一次搞懂：Agent Card、Task、Message、Part

A2A 協定圍繞幾個核心物件運作。Agent Card 是一份 JSON 格式的元資料文件，由 A2A Server（也就是被呼叫的那個 Agent）公開發布，內容宣告自己的身份、有哪些 Skills、服務端點網址，以及 Client 該用什麼方式驗證身份；按照協定慣例，這份卡片通常放在該 Agent 網域下的固定路徑。Task 是 A2A 的核心工作單位，有唯一 ID，狀態會隨處理進度改變，並且可以累積多輪對話歷史。Message 是 Client 與 Agent 之間一次溝通的最小單位，會標記發送者是 user 還是 agent。Part 則是 Message 或 Artifact 裡最小的內容單位，可以是純文字、檔案參照，或結構化的 JSON 資料——這讓 A2A 天生就能交換文字以外的內容，不只是聊天訊息。

Task 的生命週期：從送出到完成，中間會經過哪些狀態

官方規格為 Task 定義了九種狀態，你可以把它想成任務的進度條：剛送出時是「已提交」，開始處理後進入「執行中」，如果一切順利最後會走到「已完成」這個終止狀態；如果失敗、被取消，或 Agent 主動決定不執行，會分別停在「失敗」「已取消」「已拒絕」這幾個終止狀態。比較特別的是另外兩個「中斷狀態」：「需要輸入」跟「需要驗證」。前者讓 Agent 在處理到一半時，回頭跟 Client 要更多資訊（例如缺少的參數，或需要使用者確認），官方文件把這稱為支援 human-in-the-loop 情境的關鍵設計；後者則是 Agent 發現需要額外身份驗證才能繼續執行時使用。這套狀態機讓 A2A 可以處理長時間、跨越多輪對話的協作任務，而不是只能一問一答。

從 Google 捐贈到 v1.0：A2A 這一年怎麼走過來

A2A 由 Google 於 2025 年 4 月對外發布，當時就有 50 多個 launch partner 共同支持；同年 6 月，Google 把協定本身、規格文件與相關 SDK 都捐贈給 Linux Foundation，交由中立的開源基金會治理。2026 年 3 月，A2A 推出第一個正式穩定版 v1.0，補上了企業導入最在意的幾件事：用 JWS（RFC 7515）搭配 JCS canonicalization（RFC 8785）為 Agent Card 做加密簽章，讓 Client 能驗證這張卡片真的來自它宣稱的網域；同時改用「web 對齊」的架構，讓 A2A 流量可以套用一般 HTTP 服務熟悉的負載平衡與安全模式來擴展規模。到了 2026 年 4 月 9 日滿一週年這個時間點，Linux Foundation 公布的數據是：超過 150 個組織支持這套標準，核心程式庫在 GitHub 累積超過 22,000 顆星星，SDK 從最初只有 Python 一種語言，擴增到 Python、JavaScript、Java、Go、.NET 五種正式支援的語言。協定的範圍也從單純的溝通，延伸到經濟協作層——建立在 A2A 之上的 Agent Payments Protocol（AP2）讓 Agent 之間可以安全完成金流交易，官方統計已有超過 60 個支付與金融服務業的組織參與。

2026-08-27 新篇章：為什麼 A2A 加入 Agentic AI Foundation

2026 年 8 月 27 日，A2A 官方部落格宣布一項治理層面的變動：協定正式以「Growth Stage（成長階段）」專案身分，加入新成立的 Agentic AI Foundation（AAIF）。AAIF 同樣由 Linux Foundation 主導成立，A2A 在裡面跟 MCP、開源 Agent 框架 goose，以及約定 Agent 行為規範的 AGENTS.md 並列為旗下專案。官方部落格把這次調整定位為「中立治理」：讓 A2A 的技術路線圖由社群共同決定，不被單一供應商綁架，企業在評估要不要把多 Agent 系統押注在這套標準上時，可以更放心它不會因為某家公司改變策略而被迫轉向。要提醒的是，這是協定本身的治理架構調整，不等於你的公司導入 A2A 之後就自動具備完整的資料治理或法遵保障——這兩件事在概念上是分開的，下面會再提到。

誰已經在用：雲端與企業採用現況

三大雲端供應商都已把 A2A 原生整合進自己的平台：Google Cloud 本身是 A2A 發起者；Microsoft 把 A2A 整合進 Azure AI Foundry 與 Copilot Studio；AWS 則透過 Amazon Bedrock AgentCore Runtime 支援 A2A Server。企業 SaaS 這一側，根據 AAIF 官方部落格的說法，ServiceNow、Salesforce、Atlassian、SAP 都已用 A2A 串接自家產品之間的工作流程；開發框架這一側，LangGraph、CrewAI、Pydantic AI、AG2、IBM BeeAI 都支援用 A2A 讓彼此做出來的 Agent 互相委派子任務。這份採用名單是 AAIF 官方部落格自己整理、並附上外部報導與 GitHub 討論串作為佐證，反映的是「哪些平台已經內建支援」，不代表每一家企業內部實際的部署深度都已達到大規模 production 等級，實際評估時建議直接向該廠商確認目前狀態。

企業評估導入前，你該檢查的三件事

第一，資安機制要看仔細——A2A v1.0 支援用 API Key、HTTP Auth、OAuth2、OpenID Connect、mTLS 等多種 SecurityScheme 宣告在 Agent Card 裡，加上 Agent Card 本身可以用簽章驗證來源，但這些都只是協定提供的「工具」，實際安全程度取決於你的供應商有沒有正確實作。第二，先確認供應商支援的是哪一種 protocol binding——A2A 同時定義了 JSON-RPC、gRPC、HTTP+JSON REST 三種綁定方式，不同供應商可能只支援其中一種，串接前務必先確認雙方講的是同一種語言。第三，也是最容易被忽略的一點：A2A 解決的是「Agent 怎麼找到彼此、怎麼溝通」，不等於自動解決「這筆資料能不能跨組織傳遞、要留存多久、哪個主管機關管得到」這類資料治理與法遵問題——如果你的公司正在準備因應台灣《人工智慧基本法》，這部分需要另外評估，可參考本站另一篇談企業合規準備的文章。

常見問題 FAQ

A2A 會取代 MCP 嗎？

不會。官方文件明確把兩者定位為互補而非取代關係：MCP 是「垂直」整合層，處理 Agent 怎麼連上自己的工具與資料；A2A 是「水平」協作層，處理 Agent 跟 Agent 之間怎麼互相委派任務。多數企業導入多 Agent 系統時，會同時用到兩者。

用 A2A 溝通的兩個 Agent，需要互相看到對方的內部記憶或工具嗎？

不需要。依照官方 Guiding Principle「Opaque Execution」，Agent 只根據對方公開宣告的 Agent Card 與交換的訊息合作，不需要也不應該存取對方內部狀態、規劃過程或工具實作細節。

Agent Card 放在哪裡？怎麼知道一個 Agent 支援哪些功能？

Agent Card 是一份 JSON 文件，公開發布在該 Agent 網域下的固定路徑，內容宣告身份、Skills、支援的傳輸協定與安全機制；v1.0 並支援用 JWS 搭配 JCS canonicalization 做簽章，讓 Client 能加密驗證這張卡片確實來自它宣稱的網域。

現在台灣企業有機會用到 A2A 嗎？

只要你用的多 Agent 框架或雲端平台已原生支援 A2A（例如 LangGraph、CrewAI、Azure AI Foundry、AWS Bedrock AgentCore），理論上就能透過 A2A 讓不同框架做出的 Agent 互相委派任務。實際導入前，建議先跟供應商確認他們支援的是哪一種 protocol binding。

A2A 本身有處理付款或交易的機制嗎？

A2A 核心規格本身沒有，但有一個叫 Agent Payments Protocol（AP2）的延伸專案，建立在 A2A 之上處理 Agent 之間的付款流程，官方統計已有 60 多個組織支持。AP2 是獨立於 A2A 核心規格之外的擴充，若你的使用情境涉及金流，建議另外查證 AP2 本身的規格與合規狀態。

這篇文章跟本站之前談 MCP 無狀態改版那篇會不會互相矛盾？

不會，兩篇談的是兩個不同但互補的協定：MCP 那篇聚焦 2026-07-28 版規格如何從有狀態改為無狀態，這篇聚焦 A2A 本身的協作模型與最新治理進展，建議合著讀，文末延伸閱讀已附上連結。

資料來源與查證日期

本文所有 A2A 協定沿革、版本細節與採用數字，皆於 2026 年 9 月 12 日查證自：The Linux Foundation 官方新聞稿《A2A Protocol Surpasses 150 Organizations...》（2026-04-09）；a2a-protocol.org 官方規格文件 Specification v1.0.0；a2a-protocol.org 官方部落格《A New Chapter for A2A: Joining the Agentic AI Foundation》（2026-08-27）。MCP 對照資訊查證自 modelcontextprotocol.io 官方架構文件與 blog.modelcontextprotocol.io 2026-07-28 規格說明（與本站另一篇 MCP 專文查證日期一致）。AAIF 部落格文章中引用的企業採用案例（ServiceNow、Salesforce、Atlassian、SAP 等）與框架支援清單，為該官方部落格自行整理並附外部報導佐證，本文如實轉述，未另外逐一查核各企業實際部署深度。