⚡ 站長快讀:核心重點
- 文章屬性:規格解析 / 概念解釋
- 核心結論:A2A 協議是 Linux Foundation 託管的開放標準,負責「AI Agent 對 AI Agent」的溝通;MCP 負責「Agent 對工具」,兩者互補,不是二選一。
- 適用對象:想搞懂多代理系統怎麼串起來的開發者、IT 決策者,以及被 MCP、A2A、AP2 一堆縮寫搞混的人
📌 快速答案
一句話答案:A2A 協議是 Linux Foundation 託管的開放標準,讓不同廠商與框架打造的 AI Agent 能互相發現、委派任務、交換結果,與 MCP 互補而非競爭。
🔍 故事的起點:AI 之間也需要一個共通語言
2024 年底 Anthropic 丟出 MCP,解決了「AI 怎麼接工具」。2025 年 4 月,Google 丟出 A2A,想解決下一個問題:當每家公司都有自己的 AI Agent,它們要怎麼互相講話?
這個問題比想像中難。你的採購 Agent 用 LangGraph 寫、供應商的物流 Agent 跑在 ServiceNow、銀行的對帳 Agent 是 SAP 內建的。三家的內部記憶體、提示詞、工具鏈完全不能互通,也沒有人願意把這些交出去——那是商業機密。
A2A 的設計前提就寫在官方文件的第一行:讓「不透明的代理應用程式」(opaque agentic applications)能互通。不必攤開肚子,只要交換得了任務與結果。
本文想講清楚三件多數中文文章沒講的事:
- A2A 跟 MCP 常被寫成競爭關係——但兩者現在都是 Linux Foundation 專案,官方明白寫著「互補,不是取代」。
- v1.0 是一次破壞性改版,不是版號往上跳而已;列舉式的欄位、方法名稱、URL 路徑全變了。
- 生態裡最關鍵的一塊至今沒有標準——代理註冊中心(registry)的 API,規格書自己承認還沒定。
🧪 原理拆解
Agent Card:代理的數位名片
A2A 的一切從一張 JSON 開始。官方把它叫 Agent Card,直白說就是代理的數位名片,內容包含:
| 欄位 | 內容 |
|---|---|
| Identity | 名稱、描述、供應者資訊 |
| Service Endpoint | 這個代理的服務網址 |
| Capabilities | 支援串流、推播通知等能力 |
| Skills | 代理會做哪些事(含輸入輸出模式與範例) |
一張典型的名片長這樣(節錄):
{
"name": "logistics-agent",
"description": "查詢出貨進度與預估到貨日",
"capabilities": { "streaming": true },
"skills": [
{ "id": "track", "name": "追蹤包裹", "inputModes": ["text"] }
]
}客戶端代理讀完這張卡,才知道對方適不適任、該怎麼組請求、要用什麼驗證方式。沒有 Agent Card,就沒有 A2A。
三種發現方式,以及還沒被標準化的那一種
官方文件列出三種找到 Agent Card 的策略:
- Well-Known URI(推薦給公開代理):代理把名片放在
https://{網域}/.well-known/agent-card.json,遵循 RFC 8615。客戶端直接發一個 HTTP GET 就拿到。 - Curated Registry(企業與市集):中介的註冊中心收集名片,客戶端用「技能」「標籤」去查。
- Direct Configuration(私有/開發):寫死在設定檔或環境變數裡。
📋 重點摘要
- Well-Known URI 最簡單,一行
curl就能驗證對方有沒有支援 A2A。 - 註冊中心是企業場景的主力,但目前的 A2A 規格並未規定註冊中心的標準 API——這句話是官方自己寫的。
- 名片裡可能含內部網址與敏感技能描述,官方建議用 mTLS、IP 限制或 OAuth 2.0 保護端點,並用「已驗證擴充名片」提供詳細版本。
- 官方明確反對把靜態密鑰塞進 Agent Card,要用帶外(out-of-band)動態憑證。
任務生命週期:Message 與 Task 的分界
代理收到訊息後,官方規定它只有兩種回法:
回一個無狀態的 Message:適合一問一答、講完就結束的互動。
開一個有狀態的 Task:適合需要追蹤的長工作。Task 會走完一段生命週期,最後停在中斷狀態(input-required、auth-required)或終結狀態(completed、canceled、rejected、failed)。
串起這一切的是 contextId。它把多個 Task 與 Message 綁在同一段對話脈絡裡,讓「訂機票 → 依機票訂飯店 → 依飯店加訂 SPA」這種依賴鏈能被追蹤。
這裡有個容易忽略的設計:任務不可變。Task 一旦進入終結狀態就不能重啟,任何後續修改都必須在同一個 contextId 底下開新的 Task,並用 referenceTaskIds 指回原任務。
💡 為什麼要這樣做? 官方給的理由是可追溯性:每一份產出(artifact)都能對應到一個明確的工作單位,編排系統不用去猜「這個結果是第幾次改的」。代價是簡單互動也會產生一堆 completed task 物件,所以規格允許代理選擇當「純 Message 代理」「純 Task 代理」或「混合型代理」。
🔀 A2A 與 MCP 到底差在哪
先給結論:MCP 管 Agent 怎麼接工具,A2A 管 Agent 怎麼接 Agent。
官方文件用一句話定調:「MCP 用在單一代理層級的工具與脈絡整合;A2A 聚焦代理之間的溝通與協調。實務上很多系統兩個都會用——代理內部用 MCP,代理之間用 A2A。」
| 面向 | MCP | A2A |
|---|---|---|
| 連接對象 | 代理 ↔ 工具/資料源 | 代理 ↔ 代理 |
| 對方是誰 | 你自己接上的資料庫、API | 別家公司、別種框架的代理 |
| 核心物件 | Tool、Resource、Prompt | Agent Card、Task、Artifact |
| 是否揭露內部 | 你自己的工具,你自己清楚 | 刻意不揭露(opaque) |
如果你還沒把 MCP 搞清楚,建議先看站長寫的 MCP 是什麼?Model Context Protocol 讓 AI 接上你的工具與資料,再回頭讀本文會順很多。順帶一提,再往下一層就是 Function Calling:AI 怎麼呼叫外部工具——三者是同一疊架構的不同樓層,不是三個競品。
官方還特別列了一段「A2A 不是什麼」,值得抄下來:
- 不是代理開發框架(LangGraph、CrewAI、ADK 那類),A2A 是它們之間的通訊層。
- 不是子代理或工具呼叫協定,代理怎麼叫自己的子代理、怎麼呼叫工具,用框架原生機制或 MCP。
- 不是 MCP 的替代品。
- 不是即時通訊軟體,它是機器對機器的協定,不是 Slack。
🆕 v1.0 改了什麼:這是破壞性改版
A2A v1.0 是第一個穩定、可用於正式環境的版本,由八家科技公司組成的技術指導委員會(AWS、Cisco、Google、IBM Research、Microsoft、Salesforce、SAP、ServiceNow)背書。
官方形容 v1.0「重的是成熟度而非重新發明」,但翻開遷移文件會發現改動並不小:
| 類別 | v0.3.0 | v1.0 |
|---|---|---|
| 方法名稱 | message/send、tasks/get | SendMessage、GetTask |
| 列舉值 | kebab-case | SCREAMING_SNAKE_CASE |
| 型別判別 | kind 判別欄位 | 改用 JSON 成員名稱 |
| HTTP 路徑 | POST /v1/message:send | 移除 /v1 前綴 |
📋 重點摘要
- Signed Agent Cards:用 JWS 加上 RFC 8785 的 JSON 正規化,對名片做密碼學簽章,讓對方能驗證「這張卡真的是那個網域發的」。跨組織互動前先建立信任,這是企業場景的關鍵。
- 多租戶:所有請求訊息新增
tenant欄位,單一端點可以安全承載多個代理。 - 安全流程現代化:新增 OAuth 2.0 裝置碼流程(RFC 8628)與 PKCE 支援,移除已棄用的 implicit 與 password 流程。
- 三種綁定正式化:HTTP+JSON、gRPC、JSON-RPC 三種協定綁定都有正式規格與等價性保證;最簡單的形式,一個 HTTP 請求就能開始一次 A2A 互動。
- 新增
ListTasks:v0.3 沒有這個操作,v1.0 補上並支援游標分頁。
好消息是遷移不必一次切換。官方說 AgentCard 的演進是向後相容的,代理可以同時宣告支援 v0.3 與 v1.0,客戶端漸進遷移。
📊 生態現況:誰在用、用在哪
以下數字全部來自 Linux Foundation 2026 年 4 月 9 日的官方公告,是 A2A 交給基金會託管滿一年的盤點:
- 支持組織從 2025 年 4 月的 50 多家成長到超過 150 家,包含 AWS、Cisco、Google、IBM、Microsoft、Salesforce、SAP、ServiceNow。
- 核心 repo 突破 22,000 顆 GitHub star;SDK 從單一 Python 擴張到五種正式環境可用的語言(另有 JavaScript、Java、Go、.NET;官網現另列 Rust)。
- 雲端平台已內建:Microsoft 把 A2A 整進 Azure AI Foundry 與 Copilot Studio,AWS 透過 Amazon Bedrock AgentCore Runtime 支援。
- 垂直產業實際上線:供應鏈、金融服務、保險、IT 維運。
- 延伸出的 AP2(Agent Payments Protocol) 處理代理發起的交易,已有逾 60 家支付與金融機構表態支持。
時間線補一下:Google 於 2025 年 4 月發布 A2A;同年 6 月 23 日在 Open Source Summit North America 上,Linux Foundation 宣布接手成為專案新家,當時支持廠商已破百家。
⚠️ 三個容易誤會的地方
「A2A 是 Google 的東西」 — 起源是 Google,但 2025 年 6 月已捐給 Linux Foundation,治理由跨公司技術指導委員會負責,授權是 Apache 2.0。把它當成單一廠商協定會低估它的中立性。
「有 A2A 就不用 MCP 了」 — 兩者現在都掛在 Linux Foundation 底下,官方公告把它們並列為「可互通多代理系統的基礎層」。實務上是代理內部用 MCP、代理之間用 A2A。
「代理互通了,資安就交給協定」 — 協定管的是身分驗證與傳輸信任(簽章名片、mTLS、OAuth)。至於「別人的代理送來一段文字,你的代理讀了會不會被牽著走」,那是另一個沒被解決的問題,參考站長寫的 提示詞注入攻擊是什麼?AI Agent 的頭號資安風險與防禦入門。代理越能互相委派任務,注入的爆炸半徑就越大。
💡 總結:一個舊劇本的新一輪
站長我在這行看過幾次「協定戰爭」:USB 之前有一堆專有連接埠、即時通訊之前有 ICQ/MSN/Yahoo 各自為政。每一次的收斂路徑都很像——先是巨頭各推各的,再來是某一家把規格捐給中立基金會,最後由市佔與工具鏈決定誰活下來。
A2A 走得比多數人預期快。從發布到捐給 Linux Foundation 只花兩個月,到 v1.0 穩定版一年,而且是在競爭對手一起坐進技術指導委員會的情況下。這種速度通常代表產業真的痛。
但我會提醒一件事:協定成熟 ≠ 應用成熟。A2A 解決的是「怎麼把話講清楚」,沒解決「該不該相信對方講的話」。註冊中心的 API 至今沒標準化,代表「我要怎麼找到一個可信的陌生代理」這個問題,現階段還是靠白名單和商業合約在撐。
真正的考驗會在第一次跨組織的代理事故發生時到來——某個代理讀了不該讀的內容,委派出了不該委派的任務,而責任邊界在協定裡沒有定義。到那時,大家才會開始認真讀 Signed Agent Cards 那一章。
🔬 證據等級 E3:本文所有技術描述、版本差異與採用數據,均引自 A2A 官方文件(a2a-protocol.org)與 Linux Foundation 官方公告,非站長第一手實測;文中未進行任何 A2A 代理部署實驗。
❓ 常見問題
Q:A2A 協議跟 MCP 我該先學哪一個?
先學 MCP。MCP 解決的是你自己一個代理怎麼接工具與資料,門檻低、立刻有用。A2A 要到「你需要跟別人的代理協作」時才有意義,而那通常是組織級的需求。
Q:v0.3 的代理升到 v1.0 會壞掉嗎?
互動協定確實有破壞性變更(方法改名、列舉值改成大寫底線、kind 欄位移除)。但 AgentCard 是向後相容的,代理可以同時宣告支援 v0.3 與 v1.0,讓客戶端漸進遷移,不必單點切換。官方 SDK 也保證 v1.0 代理能與舊版共存。
Q:小公司或個人開發者用得到 A2A 嗎?
現階段誠實說:不太用得到。A2A 的價值來自跨組織、跨框架協作,單人專案裡的代理直接用框架原生機制就好。真正的入場時機,是當你要把服務暴露給別家公司的代理呼叫時——那時候先做的是 Well-Known URI 上放一張 Agent Card。
Q:A2A 會不會像很多協定一樣,兩年後就沒人提了?
不確定,但訊號偏正面:中立基金會治理、八家對手公司共治、三大雲端已內建、SDK 涵蓋五種以上語言。反過來看風險:註冊中心尚未標準化、企業實際採用仍集中在少數垂直產業。建議以 28 天到一季為週期回頭看官方 roadmap 的進展。
🔗 延伸閱讀
- RAG 是什麼?搞懂 AI 為什麼要「先翻資料再回答」,少騙人又能附出處
- 推理模型是什麼?搞懂思考模型跟一般模型差在哪、為何又慢又貴
- Prompt Caching 是什麼:AI API 費用怎麼一口氣省一半以上
- 你跟 AI 說的話會被拿去訓練嗎?四大 AI 助理隱私設定一次關
📎 參考資料來源
📖 第一級|標準組織與官方文件:
- A2A Protocol 官方首頁 — 2026-07-10 查證
- A2A Protocol|Announcing Version 1.0 — 2026-07-10 查證
- A2A Protocol|What’s New in v1.0 — 2026-07-10 查證
- A2A Protocol|Agent Discovery — 2026-07-10 查證
- A2A Protocol|Life of a Task — 2026-07-10 查證
- Linux Foundation|A2A Protocol Surpasses 150 Organizations(2026-04-09) — 2026-07-10 查證
- Linux Foundation|Launches the Agent2Agent Protocol Project(2025-06-23) — 2026-07-10 查證
⚠️ 本文核心事實以第一級來源為準。
📅 本文查證戳記:2026-07-10 依據 A2A v1.0 官方規格與 Linux Foundation 公告撰寫。
A2A 規格仍在演進,若你在後續版本看到與本文不符的官方說法,歡迎在留言區回報。