Google A2A 是什麼？Agent2Agent 協定、Agent Card、MCP 與企業治理

Google A2A 是什麼？Agent2Agent 協定、Agent Card、MCP 與企業治理

先講結論：A2A 是 agent-to-agent 的互通協定，讓不同框架與供應商的 agent 發現彼此、委派任務並交換結果；MCP 處理 agent-to-tool，兩者都不能取代身份、權限、稽核與人工治理。

Q：Google A2A 是什麼？
A：A2A（Agent2Agent）是讓不同框架、供應商與部署環境的 AI agent 互相發現、委派任務、交換訊息與成果的開放標準。

Q：Agent Card 做什麼？
A：Agent Card 描述遠端 agent 的能力、端點、輸入／輸出與互動方式，讓呼叫方在委派前知道可用能力與安全設定。

Q：A2A 和 MCP 有什麼不同？
A：MCP 偏向 agent 與工具、API、資料和資源的連接；A2A 偏向一個 agent 與另一個具不同責任邊界的 agent 協作，兩者互補。

Q：Task、Message、Artifact 是什麼？
A：Message 傳遞互動內容，Task 表示可追蹤的工作狀態，Artifact 表示完成後交付的檔案、結構化資料或其他成果。

Q：為什麼需要非同步與串流？
A：長任務可能超過單次請求時間，SSE、推播與任務狀態讓呼叫方能取得進度、部分成果與完成結果。

Q：A2A 會自動建立信任嗎？
A：不會。身份驗證、授權、資料最小化、輸出驗證、服務等級、人工審批與失敗補償仍需由應用系統設計。

Q：A2A 適合哪些企業場景？
A：可用於跨供應商客服、採購、旅行規劃、資料分析或多代理工作流，但每個委派動作都要明確定義資料、租戶與權限邊界。

Q：導入 A2A 要先測什麼？
A：先盤點 agent 能力、Agent Card、任務 schema、身份與權限，再測試重試、逾時、部分完成、惡意輸入、artifact 驗證與稽核。

Q：如何查版本與相容性？
A：以 A2A 官方文件、正式規格、官方 SDK 與供應商支援矩陣為準；目前官方文件已提供 v1.0 相關內容，示範 Codelab 仍不等於生產保證。

A2A（Agent2Agent）是為 AI agent 之間的互通而設計的開放協定。當企業同時使用不同模型、框架、雲端、語言與供應商時，真正困難的問題不只是「模型能不能呼叫工具」，還包括一個 agent 如何發現另一個 agent 的能力、如何交付任務、如何取得進度、如何接收檔案或結構化結果，以及如何在不讀取對方內部記憶與工具的情況下協作。

本文以 2026 年 8 月 25 日可查到的官方文件為界，整理 A2A 的定位、Agent Card、Message、Task、Artifact、JSON-RPC、Server-Sent Events、非同步通知、驗證、MCP 分工與企業治理。A2A 文件本身會持續演進，文章中的版本、SDK、延伸功能與雲端整合都應以官方最新文件為準；本文不把協定存在，直接推論成所有 agent 都相容，也不把示範 Codelab 當成生產環境部署保證。

先看A2A 官方文件首頁建立整體概念，再看What is A2A、核心概念與正式規格核對名詞。若需要把協定放進實際雲端情境，再參考Google Codelab 的 purchasing concierge 範例，並把教學環境與自己的安全邊界分開。

A2A 的定位與 agent 對 agent 的邊界

可以先用一個簡化的系統圖理解：模型負責推理，agent 負責把推理接上任務、工具、資料與權限，而 A2A 處理不同 agent 之間的溝通。A2A 官方文件把它定位為讓獨立、甚至彼此不透明的 agent 系統互相發現與協作的共同語言。這裡的「不透明」很重要，因為呼叫方不必知道遠端 agent 使用哪個模型、哪種記憶體、哪個內部工具或哪一個框架，才能提出一個可被處理的任務。

例如，旅行規劃 agent 可以把「找出符合預算與時間的行程」交給住宿 agent、交通 agent 與活動 agent。每個遠端 agent 可以保留自己的資料、工具與工作流程，只透過共同協定交換必要的訊息、任務狀態與結果。這與把所有工具塞進一個巨大 agent 不同：A2A 的價值在於讓責任、能力與部署邊界可以分開，再用明確的互通介面連接。

但 A2A 不是「讓 AI 自動互相聊天」的魔法，也不是完整的企業流程引擎。它定義溝通與任務交換的格式，並提供發現、認證、串流與非同步操作的共同模型；實際的商業規則、資料授權、風險審批、人工覆核、服務等級與失敗補償，仍然要由應用系統設計。若公司沒有先定義誰可以委派什麼任務，協定再標準化也只會讓錯誤更容易跨系統傳播。

A2A 與 MCP 的分工

MCP 常被用來處理 agent 或模型如何連接工具、資料與資源；A2A 則聚焦 agent 與另一個 agent 如何互相溝通與協作。可以把 MCP 想成「我如何使用外部工具或資料」，把 A2A 想成「我如何請另一個具有不同能力與責任邊界的 agent 幫忙」。兩者可以放在同一個系統中，但層次與信任關係不一樣。

Google Codelab 的 A2A 入門案例也把這個分工說得很清楚：MCP 著重連接工具與資料，A2A 著重 agent 之間的互動。遠端 agent 可以自己使用 MCP 讀取資料或呼叫工具，而呼叫方只看到它對外提供的 agent 能力。這種封裝對企業有好處，因為資料持有者可以控制 agent 的內部工具與憑證，不必把資料庫、第三方 API token 或內部提示詞交給每一個上游系統。

不過，「MCP 管工具、A2A 管 agent」仍然只是第一層理解。實作上可能有一個 agent 透過 MCP 取得資料，再透過 A2A 把經過授權的結果交給另一個 agent；也可能一個 A2A 任務的 artifact 需要由下游服務寫回企業系統。此時仍要另外設計資料最小化、輸出驗證、權限傳遞、稽核紀錄與錯誤回滾，不能因為兩個協定都有標準，就假設整條鏈路天然安全。

Agent Card 與遠端 agent 發現

Agent Card 是 A2A 用來描述 agent 能力與互動入口的重要文件。它可以向客戶端說明 agent 的名稱、描述、服務 URL、支援的介面與能力、可接受的輸入／輸出形式、認證需求與技能。客戶端先取得 Agent Card，再判斷這個遠端 agent 是否適合處理某個任務，這比把每個服務的能力硬編碼在呼叫方裡更容易維護。

但 Agent Card 不是「可信任證書」本身，也不是把敏感內部資訊放上網的藉口。A2A 的Agent Discovery 文件談到標準化的發現方式與 well-known 位置；企業仍要考慮 DNS、TLS、簽章、服務註冊、版本、租戶隔離與存取政策。Agent Card 應該描述可對外承諾的能力，不應洩漏內部主機、資料表、私密提示詞、長期 token 或未公開的攻擊面。

發現流程也需要防止「能力聲稱」與「實際行為」不一致。客戶端可以先讀取 Agent Card，再以低風險的 capability probe 或測試任務確認介面；對高風險操作，還需要人工核准與更強的認證。若 Agent Card 宣稱支援檔案、串流或某個技能，但實際回應不符合規格，呼叫方應把它視為相容性與信任失敗，而不是無限重試。

Message、Task、Artifact 的工作描述

A2A 不只交換一段文字。Message 是參與者之間的訊息，可能包含文字、檔案或結構化資料；Task 則代表一個需要被追蹤的工作，通常有自己的識別與生命週期；Artifact 是 agent 在任務過程中產生的結果，例如文件、資料表、檔案或結構化輸出。把這些概念分開，能讓呼叫方知道「現在是在說明需求」「任務正在執行」「已有部分產出」「工作已完成」還是「工作失敗」。

這種 task model 對長時間工作特別重要。若遠端 agent 需要查詢多個系統、等待人工確認或處理大型檔案，單一 HTTP request 可能不適合承載整個生命週期。呼叫方應保存 task ID、當前狀態、最後更新時間、來源訊息與 artifact 版本，並決定在網路中斷後如何重新取得狀態。不要把一個「200 OK」直接當成工作已完成，因為 HTTP 回應成功與業務任務成功是兩個不同層次。

Artifact 也需要內容驗證與來源標記。下游 agent 收到一份報告，不代表報告中的每個數字都已經核准；收到一個 API payload，不代表可以直接寫進生產資料庫。實際應用可以要求 artifact 帶有 schema、版本、產生者、時間戳、權限範圍與驗證狀態，並在跨信任邊界時重新檢查，而不是把遠端 agent 的自然語言輸出當成已驗證資料。

JSON-RPC、HTTP 與 SSE：A2A 的傳輸邏輯

A2A 官方規格把 HTTP(S) 作為傳輸基礎，並使用 JSON-RPC 2.0 的訊息格式處理請求與回應。這讓既有的網路、反向代理、TLS、身分驗證與可觀測性工具有機會接入，但不代表只要把 JSON 包在 HTTP 裡就完成 A2A。實作仍要符合方法、錯誤、任務狀態、內容型態與生命週期的規定，並處理逾時、重複請求與伺服器重啟。

對需要即時進度的任務，A2A 文件也描述 Server-Sent Events（SSE）串流。串流可以逐步送出任務狀態或 artifact 片段，讓前端不必一直輪詢；但 SSE 是傳輸方式，不是安全策略。部署者仍要設定連線上限、心跳、斷線重連、重複事件去重、權限檢查與敏感資料遮罩。若一個長連線能夠收到不該看到的任務事件，串流速度再快也是安全問題。

長時間或離線情境可以使用非同步操作與 push notification。這讓遠端 agent 在任務完成或需要下一步時，向客戶端提供更新；但 webhook URL 本身就是攻擊面。服務端要驗證來源、簽署事件、限制重播、保護租戶邊界、拒絕任意內網 URL，並把事件與原始 task 綁定。客戶端也要能處理事件遺失，不能假設 push 一定送達，因此通常仍需要以 task 查詢作為補救路徑。

企業導入 A2A 前，先畫出信任與責任邊界

企業最容易忽略的不是協定格式，而是「誰對結果負責」。假設客服 agent 委派退款 agent 處理客戶請求，退款 agent 又呼叫帳務 agent；若最後退款金額錯誤，不能只說是其中一個 agent 的模型決定。系統需要記錄原始請求、委派鏈、每個 agent 使用的能力、核准人、外部資料、工具動作、artifact 版本與最終寫入者，才能在事故後回答發生了什麼。

A2A 官方Enterprise Features頁面提供企業導入時應注意的方向，但企業自身仍需把它轉成控制項。至少要分開處理：服務發現與服務身分、使用者身分與 agent 身分、任務授權與工具授權、傳輸加密與資料保存、輸出驗證與人工覆核、租戶隔離與稽核追蹤。不要把「有認證」簡化成「所有行為都已授權」。

權限傳遞尤其需要清楚。上游 agent 可以把使用者的請求轉給下游 agent，但下游是否能代表該使用者讀取資料或執行副作用，必須由明確政策決定。短期 token、audience、scope、delegation chain 與到期時間都應被驗證；遠端 agent 不應收到不必要的長期憑證。若一個任務包含發信、付款、刪除、發布或修改生產資料，應設計 dry-run、preview、人工批准與可回滾步驟。

安全也不能只檢查網路層。Agent 可能受到 prompt injection、惡意 artifact、偽造 Agent Card、任務重播、資料外洩、工具混淆與供應鏈套件風險影響。A2A 提供共同互通語言，並不會替應用程式判斷文字是否可信。部署前應用合成測試、權限負面測試、錯誤回應測試、失敗注入與跨租戶測試，確認系統會在不確定時停止，而不是自動擴大委派範圍。

版本、延伸功能與相容性：不要把 demo 當成標準完成

A2A 文件首頁目前已提供版本、規格、SDK、tutorial、extension 與 governance 等入口。協定在發展中，文件首頁的「latest」方便讀者取得最新內容，但工程團隊不能讓生產系統無限制追隨 latest。應在專案中鎖定規格版本、SDK 版本、支援的 transport、認證模式與 extensions，並建立相容性測試，直到完成升級審查。

A2A 的roadmap可以幫助讀者理解協定社群如何處理治理、驗證、SDK 與社群最佳實務。roadmap 是方向與計畫，不是已交付的功能保證；同樣地，某個 SDK 有範例程式，也不代表所有伺服器、代理框架與雲端服務都能互通。文章、簡報與 benchmark 都應標示測試日期、版本與環境，避免把一次成功的 demo 寫成普遍相容性。

延伸功能要採取 opt-in 思維。若一個 agent 宣稱支援某個 extension，呼叫方應在 Agent Card、協定版本與實際 capability negotiation 中確認；必要時維持核心功能的 fallback。延伸功能如果改變資料格式、權限或任務狀態，就應有獨立的 schema、文件、測試與升級策略。否則一個看似方便的 extension 可能讓不同供應商之間形成新的鎖定。

從 Google Codelab 看 A2A 應用情境，但不要照抄到生產

Google Codelab 用 purchasing concierge 與 remote seller agent 示範 A2A 的互動方式，讓讀者看到一個 agent 如何與外部系統中的另一個 agent 協作。這種情境很適合理解 Agent Card、任務交付與多回合溝通，因為購物或旅遊類流程通常需要補問條件、等待回應、比較選項與回傳結果。

但 Codelab 的價值是教學，不是企業風險評估。真實交易場景還要加上價格與庫存時間點、使用者確認、付款權限、退款政策、個人資料、供應商責任、超時補償與人工客服。示範中能完成一次請求，不代表在高併發、重複訊息、惡意輸入、下游故障或部分成功時仍然正確。導入前應把每一個副作用改成可預覽、可確認、可稽核、可撤銷的工作流。

Google Developers Blog 的AI agent protocols 指南也把 A2A 放在更大的 agent protocol 生態裡討論，包含 MCP 與其他協定的分工。這種生態視角很有用，因為企業通常不會只使用一個協定；真正的架構問題是如何把協定組合成清楚的邊界，並在每一個邊界上保留可觀察、可驗證與可停止的控制。

A2A 對 AI agent 團隊的實際檢查清單

如果團隊準備建構第一個 A2A prototype，可以先問八個問題。第一，遠端 agent 的能力與責任是否能用 Agent Card 清楚描述？第二，哪些輸入是文字，哪些是結構化資料或檔案？第三，任務何時算開始、等待、完成或失敗？第四，artifact 如何驗證與版本化？第五，MCP、A2A 與應用 API 的邊界在哪裡？第六，誰能委派、誰能批准、誰能執行副作用？第七，串流、重連、push 與重試如何避免重複？第八，哪個人或團隊對最後結果負責？

測試時不要只測 happy path。至少加入不支援的能力、過期 Agent Card、錯誤認證、無效 schema、重複 task、下游逾時、串流中斷、artifact 被竄改、webhook 重播、跨租戶查詢與人工拒絕。每一個案例都要有明確的停止結果，例如拒絕、暫停、轉人工或安全回滾，而不是用一段模糊的錯誤文字讓上游 agent 自己猜下一步。

觀測資料也應服務於除錯與治理，不是單純收集更多 token。保留 task ID、parent task、agent ID、協定版本、Agent Card hash、工具動作、輸出 schema、延遲、錯誤類型與人工決策，可以幫助團隊回答「哪一個邊界失效」。對敏感內容則要採最小化與遮罩，並按照資料保存政策處理；可追蹤不等於可以無限制保存全部對話。

結語：A2A 的價值在於把多 agent 協作變成可治理的介面

A2A 的核心貢獻，不是再增加一個 AI 名詞，而是把 agent 對 agent 的互動拆成可描述、可發現、可追蹤與可驗證的協定。Agent Card 說明能力與入口，Message 傳遞需求，Task 管理工作生命週期，Artifact 承載可檢查的產出，JSON-RPC、HTTP、SSE 與非同步通知支援不同的運行節奏；MCP 則可以在另一層連接工具與資料。

真正的導入難題仍在治理：誰能委派、誰能代表使用者、哪些結果需要人審、如何隔離資料、如何驗證遠端 agent、如何處理版本與失敗。A2A 可以降低不同 agent 互通的重複成本，卻不會替企業決定信任與責任。讀者下一次看到「agent interoperability」或「multi-agent protocol」時，可以先問它描述的是通訊格式、能力發現、任務生命週期、工具連接，還是業務治理；把這些層次分清楚，才不會把協定 demo 誤認成可靠的生產系統。

官方來源與延伸閱讀

• A2A 官方文件首頁
• A2A：What is A2A
• A2A：核心概念
• A2A：Agent Discovery 與 Agent Card
• A2A：Enterprise Features
• A2A：Streaming 與非同步操作
• A2A：A2A 與 MCP 的分工
• A2A：正式協定規格
• A2A：官方 roadmap 與治理方向
• Google Developers Blog：AI agent protocols 指南
• Google Open Source Blog：A2Family
• Google Codelabs：A2A purchasing concierge

把 A2A 接回 Alphabet 財報：協定採用不等於營收因果

Google A2A 若只被當成另一個 AI 名詞，讀者會錯過它真正的產品位置：A2A 負責讓不同代理彼此發現、交換能力與協作任務，Agent Card 讓服務端公開可理解的能力邊界；MCP 則更像單一代理與工具、資料來源之間的連接方式。A2A 官方文件把 Agent Card、Task、訊息與企業級安全分開說明，這讓「互通」可以被拆成協定、身分、授權、觀測與失敗處理，而不是只看一次示範是否成功。

要把協定放回公司基本面，可以對照 Alphabet 2025 年 10-K，而不是把 A2A 的推出直接寫成營收來源。SEC 申報表列 2025 年合併營收 4,028.36 億美元、營業利益 1,290.39 億美元；Google Cloud 營收年增 155 億美元、增幅 36%，Cloud 營業利益則由 2024 年 61.12 億美元升至 2025 年 139.10 億美元。這些數字描述的是 Alphabet 整體與 Google Cloud 的經營結果，不能證明其中任何增長由 A2A 單獨造成；合理的研究假設是，若互通協定降低企業整合成本，它可能增加雲端平台、資安、資料與代理服務的可部署範圍，仍要靠後續產品採用與分部揭露驗證。

從 Agent Card 到企業治理：把產品路徑寫成可檢查流程

A2A 的商業化路徑可以拆成五段：第一，服務端發布 Agent Card，清楚寫出能力、輸入、輸出與認證要求；第二，協調代理發現適合的合作代理；第三，以 Task 與訊息交換工作狀態，而不是把所有資料塞進單一 prompt；第四，透過 MCP 或其他工具連接企業資料與動作；第五，把授權、稽核、成本、延遲與失敗重試留在可觀測的治理層。每一段都能形成產品指標，也都可能成為風險入口。

Google Developers Blog 與 A2A Codelab 適合用來確認示範流程，但示範不等於生產承諾。企業導入時還要問：Agent Card 是否會洩露敏感能力？跨代理任務如何驗證呼叫者與資料權限？MCP 工具失敗時是否能回復或人工接手？若答案只有「模型會自己判斷」，那仍不是可治理的企業系統。A2A 的價值因此不只在連線數，而在於能否把跨公司、跨雲與跨工具的責任邊界寫清楚。

把品牌名、公司名、產品名與財務訊號接起來

閱讀本篇時可依序看四層：品牌層是 Google／Alphabet 的平台與開放協定敘事；公司層是 Google Services、Google Cloud 與 Alphabet-level AI 研發的分部邊界；產品層是 A2A、Agent Card、Task、MCP 與 Codelab；財務層則對照營收、Cloud 利潤與成本。這種順序能避免把開放標準的社群熱度直接當成股東回報，也能讓讀者知道下一步該找什麼證據：採用者、續約、Cloud 消費、資安事故與分部揭露。

延伸閱讀可對照 Michael Dell 的直銷與 Build-to-Order 供應鏈、台灣 AI 供應鏈與 NVIDIA Vera Rubin、富邦金控與日盛整併的客戶視角及寶佳林氏家族與資本市場演化。它們分別提供平台交付、台灣硬體供應鏈、金融治理與家族資本的比較座標。

本段資料來源：A2A 官方文件、Agent Card 與 Task 概念、A2A enterprise-ready 指南、A2A 與 MCP 分工、Google Developers Blog 協定指南、Google Codelab及Alphabet 2025 Form 10-K。財務數字是 2025 年度官方申報值；A2A 採用與營收之間仍是待驗證假設，不是投資建議。

圖片 provenance：原文章 Google Developers Blog 示意圖來源為 Google 官方儲存檔；本輪另加入原創概念圖，將品牌、協定、雲端分部與治理檢查連成讀者路徑，不把它冒充 Google 官方架構圖。

先把 A2A 的六個實體拆開

「Google A2A」很容易被寫成一個泛泛的 AI 產品名，但讀者其實會同時遇到六種不同實體：A2A 是 agent-to-agent 互通協定；Agent Card 是描述遠端 agent 能力與入口的文件；Message、Task、Artifact 是一次協作中不同生命週期的資料實體；MCP 是另一個常被一起使用、但負責工具與資料連接的協定；Google、Alphabet、雲端服務與各家 agent framework 則是可能採用、實作或展示這些協定的公司與產品環境。若不先拆開，就會把開放規格、雲端產品、教學範例與企業部署保證混在一起。
本輪補充以A2A 官方文件首頁、Agent Discovery、Enterprise Features、A2A 與 MCP 分工、Google Developers Blog 的 agent protocols 指南、Google Codelab與Alphabet 2025 Form 10-K為來源邊界。這些頁面可以支持協定概念、示範情境與公司公開財務資料，但不支持所有供應商已相容、所有 agent 都安全互通，或 A2A 單獨造成任何營收結果。

協定實體：A2A 的邊界是跨 agent 溝通，不是整個 AI 產品

A2A 可以處理 agent 如何被發現、如何交換訊息、如何交付與追蹤任務，以及如何回傳檔案或結構化產出；它不會替企業決定產品策略、資料治理、人工審批或商業責任。協定可以定義共同語言，卻不能保證使用共同語言的每一方都有同樣的服務品質、資料權限或錯誤處理。
所以「支援 A2A」應該被拆成可驗證的欄位，而不是一個 marketing badge。團隊至少要問：支援哪一個規格版本？能發布和讀取哪一種 Agent Card？接受哪些 Message part？Task 是否有完整生命週期？Artifact 是否能被引用、更新和驗證？支援 JSON-RPC、SSE 或非同步通知的哪一段？認證、授權、租戶隔離與錯誤碼由誰負責？只有這些答案明確，兩個 agent 才能被稱為在某個具體範圍內相容。
官方文件的 latest 入口方便閱讀，但生產環境不應把它當成永遠不變的介面。應在部署記錄中鎖定規格版本、SDK release、支援的 extension、測試日期與相容性矩陣；升級時重新跑負面測試與跨版本測試。版本資訊本身是一個工程實體，不能被省略在「A2A 已採用」這種籠統句子後面。

Agent Card 實體：能力描述、服務入口與信任不是同一張證書

Agent Card 的用途，是讓呼叫方在委派前取得遠端 agent 的可讀能力描述，例如名稱、描述、服務 URL、技能、輸入輸出形式、支援介面與認證要求。它把「這個服務能做什麼」從呼叫方硬編碼裡抽出來，讓能力發現可以隨服務更新。但能力描述不是自動產生的信任證書，更不是把內部提示詞、主機、資料表、長期 token 或所有可用工具列給陌生人的理由。
可以把 Agent Card 想成服務目錄與契約摘要，而不是授權結果。客戶端讀到某個 agent 支援報價或退款，只能知道它聲稱提供該能力；真正發送任務前，仍要確認服務身分、TLS、簽章、租戶、使用者 scope、資料區域與人工核准政策。對高風險技能，可先用低權限 capability probe 或 dry-run 驗證，不要一看到 Card 就直接交出真實交易資料。
Agent Card 也需要版本與變更治理。若 Card 新增不相容的必填欄位，舊客戶端可能在解析階段失敗；若 Card 保留相同技能名稱但改變副作用，呼叫方可能在不知情下執行新行為。企業可以保存 Card hash、抓取時間、來源主體與批准狀態，把能力宣告變成可稽核的配置，而不是每次請求都盲信遠端內容。

Task 與 Artifact 實體：一次請求不是一次成功

Message 表達參與者之間的內容；Task 表達需要被追蹤的工作；Artifact 表達工作中產生的文件、檔案、資料或結構化結果。三者分工的價值，是把「我想要什麼」「現在做到哪裡」「已經產出什麼」分開。對長時間或需人工確認的流程，單一 HTTP 200 不能證明業務任務完成；客戶端要能以 task ID 查詢狀態、取得最新 artifact，並知道最後更新時間與失敗原因。
Task 狀態也應和副作用狀態分開。例如一個 agent 可能已完成研究報告，但尚未寫入 CRM；可能已產生付款建議，但等待人員核准；可能已將檔案上傳到暫存區，但病毒掃描尚未完成。若所有狀態都被壓成 success，上游 agent 很容易把未核准的產出繼續往下傳。應用層可以為每個 artifact 加上 schema、版本、產生者、時間戳、來源、驗證狀態與允許用途。
Artifact 不只是輸出格式，也是一個資料治理邊界。下游 agent 收到一份自然語言摘要，不等於摘要中的數字已經獲得財務核准；收到一個 JSON，不等於可以直接寫進生產資料庫；收到一張圖片或檔案，不等於可以永久保存。跨 agent 傳遞前後都要重新檢查 schema、權限、敏感欄位與資料保留期限，並能在內容不符合時拒絕或轉人工。

MCP 與 A2A 實體：工具連接和代理委派各自負責什麼

把 MCP 和 A2A 放在同一張架構圖中，不代表它們是競爭產品。A2A 聚焦一個 agent 如何和另一個具有不同責任邊界的 agent 協作；MCP 通常用來讓 agent 或模型連接工具、資料與資源。實務上可以是一個上游 agent 透過 A2A 委派給遠端 agent，而遠端 agent 內部再用 MCP 查詢資料或呼叫工具。上游看到的是遠端能力與任務結果，不必拿到遠端資料庫憑證或所有內部提示詞。
這種分層可以降低耦合，但也會增加追蹤難度。一次外部請求可能經過 A2A task、下游 agent 的 MCP tool call、第三方 API、資料庫與人工審批；如果只記錄最後回答，事故後無法知道哪一層產生錯誤。企業應保留可去識別的委派鏈、agent ID、tool action、scope、artifact hash、時間、延遲與錯誤類型，並根據敏感度遮罩輸入內容。
權限也不能沿著協定名稱自動繼承。上游 agent 有權讀取一份資料，不代表它能把相同權限轉授給遠端 agent；遠端 agent 能查詢資料，不代表它能替上游執行刪除、付款、寄信或發布。每次跨邊界委派都要重新判斷 audience、scope、到期時間、使用者意圖與副作用，並且對高風險工具提供 preview、人工批准和可回滾路徑。

Google、Alphabet、Cloud 與 A2A：品牌關係不等於產品歸屬或財務因果

讀者看到 Google Developers Blog、Google Codelab 與 Alphabet 10-K 時，應把它們放在三個不同層次。Google 的開發者文章與 Codelab 是技術教學與示範入口；A2A 官方文件是協定概念與規格入口；Alphabet Form 10-K 是上市公司層級的財務與風險申報。三者可以互相對照，但不能把教學範例直接寫成 Alphabet 的客戶採用證據，也不能把 Alphabet 的 Google Cloud 成長直接寫成 A2A 的營收。
更精確的寫法是：A2A 可以被視為讓多 agent 系統更容易互通的一項開放協定；Google 的公開文件把它放進 agent protocol 與雲端開發者生態；Alphabet 的年度申報則提供 Google Cloud 和整體公司的財務背景。至於 A2A 對雲端消費、平台黏著、合作夥伴數、部署成本或企業續約的實際影響，仍需要後續採用資料、產品揭露或獨立研究。品牌共現只證明內容關聯，不證明因果。
這條邊界也適用於投資閱讀。若一篇文章從 A2A 的社群關注直接跳到「Alphabet 將因此受惠」或「某家供應商會被淘汰」，就跨越了協定到財務結果之間的多個未驗證節點。讀者應要求看到可量化的採用、收入、成本、毛利、客戶留存或風險資料，而不是只看協定頁瀏覽量或一個 Codelab 是否能跑通。

企業實體：誰可以委派、誰承擔最終責任

一個企業 A2A 系統通常包含使用者、上游協調 agent、下游專業 agent、工具服務、資料所有者、平台團隊與人工審批者。這些角色不應被稱為一個模糊的 AI。例如客服 agent 委派退款 agent，退款 agent 再使用帳務工具；若退款金額錯誤，系統必須知道原始使用者意圖、委派鏈、每個 agent 的能力、核准人、最後寫入者與可回滾動作。協定提供互通格式，企業仍需設計責任矩陣。
導入前可以建立 agent registry：每個 agent 有 owner、用途、資料分類、服務 URL、Card 版本、認證方式、可執行副作用、SLO、成本中心、日誌保存期限與停用程序。對外部 agent 還要記錄供應商、地區、合約、資料處理條件、版本升級通知和事故聯絡人。這些欄位把「我們有很多 agent」轉成可以審核、移交與撤銷的企業資產。
治理不是讓所有任務都慢到不能用，而是把風險分層。純讀取、低敏感的摘要可以使用自動流程；含有個資、財務、醫療、法務或外部發布的任務則需要更強的身分、最小權限、人工確認、輸出驗證與審計。若一個 agent 無法回答自己正在代表誰、要做什麼副作用、使用哪個資料來源和何時停止，系統就不應給它更大的委派範圍。

相容性實體：從 capability badge 走向可重跑測試

「支援 A2A」至少應由一組可重跑測試定義：能否取得合法 Agent Card、能否拒絕過期或偽造 Card、能否完成基本 Message、能否建立與查詢 Task、能否傳遞 Artifact、能否在 SSE 中處理斷線與重連、能否在錯誤認證時拒絕、能否在不支援 extension 時安全降級。測試結果要記錄協定版本、SDK、伺服器、模型、網路與資料環境，否則一次 demo 不能代表下一次仍相容。
負面測試比 happy path 更能說明系統是否可治理。加入無效 schema、重複 task、過期 token、跨租戶 ID、惡意 artifact、未知方法、下游逾時、webhook 重播、人工拒絕與部分成功，觀察系統是否會停止、轉人工、回滾或清楚回報。不要讓上游 agent 在錯誤回應時自行猜測下一步，更不要用無限重試把一個權限錯誤放大成服務事故。
版本升級也應被當作相容性交易。新規格可能改善串流、驗證或治理，但同時改變欄位、錯誤碼或狀態語意。升級前先保留舊版 client、建立雙版本測試、跑資料與權限負面案例，再決定 rollout 範圍；如果新的 extension 只在部分服務存在，就保持核心協定 fallback。開放協定不等於無成本的相容性。

把 A2A 轉成讀者可用的架構檢查表

閱讀或評估一個 A2A 方案時，可以沿著五個問題走。第一，這個頁面描述的是規格、SDK、雲端產品、Codelab 還是公司財務？第二，遠端 agent 的能力如何被發現，Card 是否有版本與信任來源？第三，一次工作如何在 Message、Task 與 Artifact 之間流動？第四，MCP、資料庫、API 與 A2A 的權限邊界在哪裡？第五，失敗、人工批准、資料保留、成本和最終責任由誰處理？回答完，泛泛的「多 agent 互通」就會變成可檢查的系統。
若要做小型 prototype，先選無副作用、低敏感、可重跑的任務，例如查詢公開資料、產生草稿或整理檔案索引；把真實付款、刪除、發布、對外寄信與生產資料寫入留在 dry-run 或人工批准後。這樣可以先驗證 Agent Card、Task、Artifact、錯誤和可觀測性，再逐步增加權限，而不是把示範專案直接接上企業資料庫。
內部連結也應沿著實體，而不是只沿著 AI 關鍵字。與 A2A 共同人物、共同規格、共同工具、共同雲端產品、共同企業治理或同一個 agent workflow 的文章才值得優先互鏈；若另一篇只有泛泛討論生成式 AI，沒有共享實體或讀者下一步，就不應因標籤相同而硬接。內容網路的目標是幫助讀者繼續驗證系統，而不是堆疊技術名詞。
最小可行的驗收紀錄，應把每次測試的請求主體、Card snapshot、Task ID、Artifact hash、授權 scope、工具呼叫、人工決策、錯誤與回滾結果放在同一條關聯鏈上。這樣遇到「看起來完成、實際未落地」的案例時，團隊可以定位是發現、委派、工具、資料、審批還是發布階段出錯；讀者也能分辨一個可重現的互通證據，和只展示成功畫面的行銷敘事。

來源邊界與結論

本次追加直接核對 A2A 官方文件、Agent Discovery、Enterprise Features、A2A 與 MCP 分工、Google Developers Blog、Google Codelab，以及 Alphabet 2025 Form 10-K。它們共同支持協定定位、Agent Card 與任務概念、企業導入考量、示範情境和公司申報的財務背景；它們不單獨支持所有 agent 已互通、某個供應商的生產 SLA、A2A 的單獨營收貢獻、模型品質或未公開的企業客戶數。
A2A 最值得理解的地方，是它把 agent 對 agent 的關係拆成可以描述、追蹤和治理的介面；真正的工程價值取決於版本、身分、授權、資料、工具、artifact 驗證、失敗處理與責任矩陣是否一起落地。把 Google／Alphabet、A2A 協定、MCP、Cloud、Codelab 和財報放回各自的實體層，讀者才能知道哪些是技術事實，哪些是企業假設，哪些還需要後續採用與財務證據，而不把一個協定名稱誤當成完整產品或投資結論。

本段來源：A2A 官方文件首頁；Agent Discovery；Enterprise Features；A2A 與 MCP；Google Developers Blog agent protocols 指南；Google Codelab；Alphabet 2025 Form 10-K。本文未將協定採用直接延伸為營收、流量、ROI 或生產部署保證。

A2A 與 MCP 互補，但互通不等於自動可信

A2A 主要處理獨立 Agent 之間的發現、委派、任務狀態與結果交換；MCP 則更常用來連接 Agent 與工具、資料或資源。兩者可以一起組成企業 Agent 架構，但協定互通只解決「怎麼說話」，不會自動解決身份、授權、資料最小化、結果驗證與責任歸屬。

Agent Card 應被視為能力與安全條件的公開描述，而不是可信任證書。企業部署要驗證端點、認證方案、版本、輸入／輸出範圍、工具副作用、日誌與撤銷流程；也要留意規格治理與版本演進。實作請以A2A 官方協定文件及相容實作的版本說明為準。

• 分工：什麼任務適合 A2A，什麼資料存取適合 MCP？
• 安全：Agent Card、身份、授權與密鑰如何被驗證？
• 治理：跨代理錯誤、爭議、審計與人工接管如何處理？