摘要
AI 代理人 (AI agent) 的快速普及帶來了企業內自動化和效率提升的巨大機會。然而，要掌握這個機會，有一個根本的挑戰：互通性（interoperability）。由不同框架、不同供應商或不同平台開發出來的 AI agent 經常在孤立的環境中運作，彼此無法有效地溝通或協作。企業必須能夠解決這個 AI agent 散落各方的問題，才能夠真正打造出能處理複雜工作流程的複合代理系統。針對這一挑戰，Google 在其 Cloud Next 2025 會議上推出了 Agent2Agent (A2A) 協議。作為一個開放標準，A2A 的目的是為 AI 代理人提供一種彼此溝通的通用語言，使它們能夠互相發現、安全通訊、交換訊息，並在各種企業系統中協調行動。同時，業界也見證了 Anthropic 的 Model Context Protocol (MCP) 的崛起，MCP 是一個專注於連接 AI 模型和代理與外部工具和數據源的開放標準。
這篇文章深入分析 Google 的 A2A 協議，檢視其技術架構、設計原則和使用案例。並且將 A2A 與 Anthropic 的 MCP 進行比較，闡明了這兩個標準在不斷發展的 AI 代理人生態系統中的獨特但互補的角色。雖然 Google 將 A2A 和 MCP 定位為互補，但開發者社群對於存在兩個標準的必要性和潛在重疊仍有一些疑慮。這篇文章還探討了目前 A2A 的早期採用情況，尤其是 Google 高調宣布超過 50 個產業內合作夥伴的大力支持。最後，我們詳細介紹實作的資源，研究了實際應用的場景，並討論了對企業 AI 未來的戰略影響。
互通性的需求為 A2A 和 MCP 奠定了基礎
目前企業 AI 環境的特點是快速創新，但有明顯的碎片化。組織部署各種 AI 代理人，包括客服聊天機器人、數據分析助手、以及後端流程自動化工具等等。但這些技術通常來自不同的供應商、或是用不同的框架所開發出來。這些 AI agent 通常在各自的技術範圍內運作，形成了所謂的「智慧孤島」，彼此無法互通。對於想要進一步提昇流程自動化的企業，這種互通性的缺乏對於跨部門或是跨系統整合形成了一個主要障礙。
這種整合挑戰通常被描述為「M×N 問題」：將 M 個不同的 AI 模型或 AI 代理人與 N 個不同的工具、數據源或其他 AI 代理人整合，需要大量的客製化點對點串接。而每一次串接都需要冗長的開發工作。這種複雜性限制了 AI 部署的可擴展性，阻礙了 AI agent 有效協作的能力，最終就影響到 AI 投資的 ROI。
為了克服這些限制，業界自然馬上意識到標準化的需求。標準協議可以提供一個通用的方式，使不同團隊或供應商使用不同技術構建的 AI agent 能夠無縫地發現對方（agent discovery）、交換訊息和協調行動。這種標準化對於降低整合成本、提高開發效率、在共同框架內促進創新，以及釋放多代理系統的真正潛力至關重要，使專業 AI agent 能夠協作以完成複雜任務。
Google 的 A2A 和 Anthropic 的 MCP 等協議的出現，代表 AI 代理人的一個重要轉折點。AI 領域的早期重點往往集中在增強個別模型和代理的功能。然而，隨著企業更廣泛地部署這些 AI agent，「智慧孤島」的狀況變得更明顯。專門針對 AI agent 間通訊 (A2A) 和 AI agent 與工具/數據互動 (MCP) 標準的引入，反映了市場認知到協作和整合架構對於提供可擴展企業價值至關重要。這代表了從客製化解決方案邁向標準化的架構，為更強大、相互連接、且真正自動化的企業內 AI 佈署打下基礎。
✦延伸閱讀：AI Agent 是什麼？與 AI 助理、Chatbot 差異比較和應用場景解析
Google 的 Agent2Agent (A2A) 協議：技術深度解析
起源、願景和開放方式
Google 在 Cloud Next 2025 正式發布了 Agent2Agent (A2A) 協議，將其定位為一個新的開放標準，目的是要促進各種 AI 代理人生態彼此間的互通性，明確的目標是要使 AI 代理人，無論其底層框架、供應商來源或部署環境是什麼，都能夠有效彼此溝通和協作。
從一開始，A2A 就被定位為一個協作、社群驅動的計畫。Google 推出該協議時宣布獲得了 50 多家技術合作夥伴的支持和貢獻，包括主要企業軟體供應商、平台提供商和領先的服務整合商。這個廣泛的聯盟凸顯了產業對此類標準的需求，以及 Google 培育 A2A 廣泛生態系的策略。Google 透過 GitHub (google/A2A) 提供了 A2A 協議規範、文件和程式碼範例。
A2A 的核心願景是建立一個標準化的通訊層，允許 AI agent 在各種企業平台和應用程式中安全地交換訊息和協調行動。通過提供「通用語言」，A2A 旨在打破目前限制多 AI agent 系統的孤島，實現更複雜的自動化和協作。
重要的是，Google 始終將 A2A 定位為 Anthropic 的 Model Context Protocol (MCP) 的互補，而非競爭對手：MCP 專注於連接 AI agent 和工具與數據，而 A2A 則是專為 AI agent 之間的互動而設計。
核心架構與組件
A2A 協議定義了一個基於 Web 標準的 AI agent 互動框架，其架構包括幾個關鍵元素：
- 客戶端/伺服器角色：A2A 交互發生在兩個 AI agent 之間，通常指定為「客戶端 agent」和「遠端 agent」。客戶端 agent 發起任務請求，而遠端 agent 接收請求並嘗試透過提供訊息或執行動作來完成這個請求。這些角色不一定是固定的，在更複雜的互動過程中可能會有一些變化。
- 代理卡片（能力發現）：A2A 協議的其中一個基礎元素是「代理人卡片（agent card）」。簡單來說就是描述這個 AI agent 可以做什麼的「名片」，通常以 JSON 格式在已知路徑（/.well-known/agent.json）提供。代理卡片描述了 AI agent 的身份、能力（技能）、接收 A2A 請求的端點 URL、所需的認證方法，以及可支援的模態（modality, 如文字、聲音、圖片、影像）。客戶端 agent 使用這些卡片找到能夠執行特定任務的遠端 agent。這種發現機制不同於預先配置的靜態連接、而是在動態執行時才去看看有哪些 AI agent 現在可以被調用。畢竟在大型企業的環境中，許多 AI agent 隨時會加入、離開、或頻繁更新功能，這種動態查找的方式對於構建適應性強和可擴展的多代理人系統非常重要，允許 AI agent 即使是在不斷更新的環境之下，也能夠與其他 AI agent 進行各種即時協作。
- 任務生命週期：A2A 中的中心交互單元是「任務」。客戶端通過發送包含其生成的唯一任務 ID 的請求（例如，tasks/send）來啟動任務。任務按照定義明確的生命週期，具有不同的狀態：已提交（已接收但未開始）、工作中（處理中）、需要輸入（代理需要客戶端提供更多訊息）、已完成（成功完成）、失敗（無法恢復的錯誤）和已取消（提前終止）。這種狀態管理允許持續的追蹤和協調，支援即時完成的快速任務，以及可能需要長時間運行的任務。如果任務進入需要輸入的狀態，客戶端可以發送與同一任務 ID 相關的後續狀態消息，再提供必要的訊息。
- 數據格式（訊息、部分、成品）：任務內的通信通過客戶端（角色：「用戶」）和遠端代理（角色：「代理」）之間交換的訊息（Messages）進行。每則訊息包含一個或多個部分（Parts），這是內容的基本單位。A2A 定義了標準部分類型：TextPart 用於純文本，FilePart 用於傳輸文件，DataPart 用於結構化 JSON 數據，通常用於表單或結構化輸入/輸出。AI agent 在任務期間生成的最終輸出或結果被封裝在「成品（Artifacts）」中，這些 Artifacts 當中也包含 Parts。代理卡片、任務、訊息、部分和成品的精確結構和格式在 JSON 規範中都有正式的定義，如此可以確保一致性，並實現不同 AI agent 之間的互通性。
- 通訊方法：A2A 利用標準 Web 協議進行傳輸。初始請求，如獲取代理卡片或通過 tasks/send 啟動任務，使用 HTTP(S)。對於需要即時更新的長時間運行的任務，支持串流功能的伺服器可以使用 tasks/sendSubscribe 方法。在這種模式下，伺服器使用伺服器發送事件 (SSE) 向客戶端推送更新，通常包含 TaskStatusUpdateEvent 或 TaskArtifactUpdateEvent 訊息。此外，A2A 支援推送通知，支援 pushNotifications 功能的伺服器可以主動向客戶端在配置期間提供的 webhook URL 發送任務更新 (tasks/pushNotification/set)。
- 安全性：安全性是 A2A 的一項核心設計原則，提供適合企業的預設安全環境。其中，代理卡片指定了存取遠端代理服務的身份驗證要求，允許 AI agent 決定誰可以跟自己互動。A2A 被設計成與各種標準身份驗證的方案對齊，例如 OpenAPI 定義的規格。
✦延伸閱讀：Google Agentspace 是什麼？整合 AI 搜尋與 AI Agent 打造智慧知識管理平台
關鍵設計原則
A2A 協議的開發由五個關鍵原則指導，反映了 Google 在擴展 AI agent 系統和企業部署需求方面的廣泛經驗：
- 擁抱代理能力：A2A 設計讓 AI agent 能夠自然地在通常是非結構化的模態中進行協作。這超越了簡單的函式調用或工具使用，使 AI agent 能夠協調複雜的任務（即使它們不共享記憶、內部工具或上下文）。這個原則的主要目的是實現真正的多代理人場景，讓 AI agent 更像是彼此協作的實體，而不僅僅是一堆可調用的工具而已。
- 建立在現有標準之上：A2A 刻意利用已經被廣泛採用和熟悉的 Web 標準，包括 HTTP、伺服器發送事件 (SSE) 和 JSON-RPC 等等。這一個設計原則主要目的是在降低採用的門檻，使開發人員更容易將 A2A 能力整合到既有 IT 環境中，並利用現有的基礎設施和技能。
- 預設的安全性：安全性在企業環境中終究是最重要的角色，A2A 從一開始就納入了對企業級認證和授權的支援。與 OpenAPI 認證方案等標準對齊，提供了一個熟悉且穩健的基礎，用於保障 AI agent 彼此互動的安全性。
- 支援長時間運行的任務：企業工作流程通常涉及需要相當長時間的流程，可能需要數小時或數天，也可能需要人工干預或複雜的研究。A2A 明確設計用於靈活處理這些長時間運行的任務，提供即時反饋、狀態更新、和非同步完成的機制。
- 模態不可知：AI agent 的世界早已經超越一般文字的格式。A2A 通過支持各種模態，包括音頻和視頻流，以及文本和結構化數據如 Web 表單。A2A 允許 AI agent 協商適當的通訊格式和用戶界面功能（如支持 iframe、影片播放器），確保更豐富和更靈活的互動。
這些設計原則共同指向一種務實的開發理念。通過將 A2A 基於熟悉的技術並直接解決企業核心的需求，例如安全、長時間運行的流程和多樣化數據類型，Google 打算建立一個不僅強大，而且相對容易被企業採用和整合的協議，讓 Google Cloud 目標企業客戶群和合作夥伴加速採用 A2A。
Anthropic 的 Model Context Protocol (MCP)：上下文 AI 的基礎
Google 的 A2A 是專注在 AI agent 彼此之間的通訊，而 Anthropic 的 Model Context Protocol (MCP) 則是將 AI 模型或 AI agent 連接到外部數據和工具。兩者有雷同之處，但不完全重疊。
目的與架構
Anthropic 在 2024 年末推出的 MCP 是一個開放標準，目的是要標準化 AI 應用程式（包括聊天機器人、IDE 助手、自定義代理和其他 LLM 驅動的工具）與外部系統連接的方式。其主要目的是提供一個通用介面，常被比作 AI 的「USB 接口」，允許任何符合標準的 AI 模型或應用程式在不需要特定串接程式碼的情況下，無縫地連接到任何符合標準的數據來源或工具。
MCP 直接解決了 M×N 串接問題，其中 M 個 AI 模型需要連接到 N 個不同的工具或數據源。相較於需要 M×N 個客製化串接，MCP 則是提供 M+N 的解決方案：工具/數據來源提供商實作 N 個 MCP 伺服器，而 AI 應用程式開發人員實作 M 個 MCP 客戶端。然後，任何客戶端都可以透過 MCP 與任何伺服器互動。
MCP 的架構基於客戶端-伺服器模型：
- MCP 主機（host）：這是終端用戶互動的主要對象，主要就是一個 AI 應用程式或環境（例如，Claude Desktop 應用程式、IDE 外掛、自定義 LLM 應用程式等等）。主機管理 MCP 客戶端的生命週期，執行安全策略和用戶同意，並協調整體互動。
- MCP 客戶端（client）：運行在主機內，每個客戶端維護一個與特定 MCP 伺服器專用的一對一連接。它根據 MCP 規範處理協議通信、能力協商、請求轉發和處理伺服器的回應。
- MCP 伺服器（server）：一個輕量級程式或包裝器，根據 MCP 標準讓外部系統（如數據庫、API、本地文件系統或特定工具）可以被存取。它充當外部資源與 MCP 客戶端之間的橋樑。
客戶端和伺服器之間的通信使用 JSON-RPC 2.0 協議。
核心基元（primitives）與功能
MCP 定義了一組核心消息類型，稱為「基元（primitives）」，這些基元定義了客戶端和伺服器之間的互動：
伺服器端基元：定義了伺服器可以提供給客戶端/主機的內容：
- 資源（Resources）：代表伺服器可以提供的結構化數據或上下文訊息，以豐富 AI 模型的理解（例如，文件片段、資料庫查詢結果、文件內容）。這些通常由應用程式或用戶控制，以提供相關上下文。
- 提示（Prompts）：預先定義好的模板或指令，引導用戶或 AI 模型如何有效使用伺服器的資源或工具。這些通常由用戶控制，允許用戶調用特定的、優化的互動。
- 工具（Tools）：AI 模型可以決定通過伺服器調用的可執行函式或動作（例如，發送電子郵件、查詢 API、跑腳本、搜尋資料庫）。工具使用通常由 AI 模型本身作為其推理過程的一部分控制。
客戶端基元：這些定義了主機/客戶端可以提供給伺服器的能力：
- 根（Roots）：代表主機應用程式環境的入口點，如本地文件系統中的特定目錄，伺服器可能被授予存取權限。存取需要明確的用戶同意。
- 採樣（Sampling）：一種強大的機制，允許伺服器請求主機 AI 模型基於提供的提示生成文字。這使得複雜的多步驟推理成為可能，伺服器端的流程可能需要 AI 執行子任務或生成中間文本。Anthropic 強烈建議所有採樣請求都需要明確的人工批准，以防止造成意外的後果或失控的流程。
✦延伸閱讀：什麼是 Model Context Protocol ( MCP )？AI 整合標準完整指南
安全與信任考量
鑑於 MCP 使 AI 模型能夠通過工具存取潛在敏感數據和執行任意程式碼，安全和信任是至關重要的設計考量。協議規範概述了關鍵原則：
- 用戶同意和控制：用戶必須被告知並明確同意通過 MCP 執行的所有數據存取和操作。主機應用程式負責提供明確的界面來審查和授權這些活動，確保用戶保有控制權。
- 數據隱私：主機應用程式必須在向 MCP 伺服器揭露任何用戶數據（例如，通過 Resources 或 Roots）之前獲得明確的用戶同意。數據傳輸必須安全處理，具有適當的權限控制。
- 工具安全：調用工具代表潛在的程式碼執行，必須極其謹慎對待。除非伺服器本身經過驗證和信任，否則伺服器提供的工具描述應被視為不可信。在調用任何工具之前，必須獲得明確的用戶同意。
- LLM 採樣控制：用戶必須明確批准伺服器對主機 LLM 進行採樣的任何請求。用戶應控制是否允許採樣、使用的特定提示以及伺服器可以存取的結果。
要注意 MCP 協議本身不強制執行這些安全原則；它仰賴主機、客戶端和伺服器組件內部實作的同意流程、授權檢查和安全最佳實作。例如，身份驗證明確超出 MCP 規範範圍的話，必須由外部的提供商處理。
MCP 的安全模型對主機應用程式寄予相當大的責任。作為管理客戶端連接和用戶同意的中央協調者，主機充當主要看門人。這意味著 MCP 交互的整體安全性很大程度上取決於主機的實作。主機應用程式中的漏洞或有缺陷的安全實作，可能導致 MCP 伺服器進行未經授權的訪問或操作，從而形成漏洞。
解讀 A2A 和 MCP 的關係
雖然 Google 的 A2A 和 Anthropic 的 MCP 的目的都是透過開放協議解決 AI agent 生態系中的整合挑戰，但它們著重不同的層面。
互補角色：代理人協作搭配工具/數據存取
Google 和 Anthropic，以及許多產業觀察者，將 A2A 和 MCP 定位為互補而非競爭的標準，它們在 AI agent 技術當中的不同層級運作：
- MCP 專注於將單一 AI agent 或 LLM 應用程式連接到其外部環境：它提供了標準化「管道」，使 AI agent 可以訪問數據來源（資料庫、文件）和使用工具（API、函數）。在 A2A 文件中使用的類比中，MCP 提供了「扳手」，允許 AI agent（如機械師）與特定工具互動。
- A2A 專注於實現獨立 AI agent 之間的互動：它提供了 AI agent 互相發現、協商任務、交換訊息和協作工作流程的協議。繼續這個類比，A2A 促進了「機械師之間的對話」，允許多個代理作為團隊合作。
Google 的 A2A 文件中描述的汽車修理店場景：MCP 將是專門代理（例如，「升降控制代理」，「扳手轉動代理」）用來與其特定物理或數字工具（「平台升高 2 米」，「扳手轉動 4 毫米」）互動的協議。另一方面，A2A 將管理最終用戶和主要「機械師代理」（「我的車發出嘎嘎聲」）之間的互動，以及機械師代理與其他獨立代理之間的通信，如「零件供應商代理」（「你有零件 #XYZ 庫存嗎？」）。
技術比較：架構、通信、重點
雖然兩種協議都利用 JSON-RPC 並追求開放性，但它們的具體架構、功能和重點領域有顯著不同。
表 1：A2A 與 MCP 功能比較
| 功能 | Google Agent2Agent (A2A) | Anthropic Model Context Protocol (MCP) |
|---|---|---|
| 主要目的 | AI agent 間通訊、協作、協調 | 代理/LLM 與工具/數據來源整合 |
| 關鍵互動 | 獨立 AI 代理人之間 | AI 應用程式（主機/客戶端）與外部資源（伺服器）之間 |
| 主要行為者 | A2A 客戶端代理、A2A 遠端代理 | MCP 主機、MCP 客戶端、MCP 伺服器 |
| 核心概念 | 代理卡片（發現）、任務（生命週期）、消息、部分、成品 | 資源（數據）、提示（模板）、工具（動作）、根（主機訪問）、採樣（LLM 調用） |
| 通信 | HTTP(S)、伺服器發送事件 (SSE) 用於流式傳輸、可選推送通知 | 通過各種傳輸方式的 JSON-RPC 2.0（標準輸入輸出、HTTP/SSE） |
| 發現機制 | 公共代理卡片（/.well-known/agent.json） | 伺服器在客戶端連接時廣播其能力 |
| 安全重點 | 代理身份驗證/授權（在代理卡片中指定）、安全交換 | 主機管理的用戶同意，用於數據訪問、工具使用、採樣；工具安全 |
| 發起者 | Google 主導的開源倡議 | Anthropic 主導的開源倡議 |
| 數據重點 | 代理人之間交換消息、任務狀態、成品 | 向模型提供上下文數據（資源）、啟用操作（工具） |
| 控制流 | 基於任務的生命週期、客戶端/遠端代理之間的協商 | 主機編排客戶端-伺服器連接；模型可以調用工具 |
產業觀點與潛在未來
儘管 Google 和 Anthropic 明確定位，但兩個不同協議解決類似問題的狀況，還是引發了 AI 社群內的熱議。一些開發人員表達了對單一統一協議的偏好，質疑是否有必要區分 AI agent 間通訊和 AI agent 與工具通訊，而分開制定兩套標準？
然而，其他人看到了這樣做的明確價值，認為 A2A 在更高抽象層次運作，適合協調公司級代理之間的複雜工作流程，而 MCP 提供了構建和存取底層工具和數據來源的精細機制。一些人樂觀地將 A2A 視為可能代表「AI agent 的 HTTP 時刻」，能夠建立廣泛的互連 AI agent 生態系統，而非孤立的孤島。
Google 採取的是多管齊下的戰略。
透過與重要合作夥伴支持推出 A2A，同時宣布在其自身工具（如 Agent Development Kit (ADK) 和 Gemini 模型）中支持 MCP，達到兩全其美。這種雙重方法允許 Google 迎合不斷增長的 MCP 生態系統，同時又積極推廣 A2A。Google 將 Google Cloud 定位為這些協議的中心樞紐，能夠管理複雜、異質的多代理系統，無論最終哪些特定代理人框架或工具主導市場，Google 都會是贏家。
值得注意的是，Anthropic 和 OpenAI 等關鍵參與者在 A2A 初始發布合作夥伴的名單中中缺席，引發了對於共識的質疑，以及持續競爭標準的風險問題，未來還是取決於開發者實際願意採用哪些標準。
A2A 生態系：採用與早期實作
任何新協議，關鍵的成功因素是其周遭生態系的強度和廣度，而 Google 在推出 A2A 時馬上強力展示了產業的興趣。
合作夥伴和產業支持
A2A 協議宣布獲得了 50 多家技術合作夥伴和服務提供商的支持，包括主要企業軟體供應商、雲服務提供商、AI 新創和全球的系統整合商。
一些知名品牌包括：
- 企業 SaaS/平台供應商：Salesforce、SAP、ServiceNow、Box、Atlassian、MongoDB、Intuit、PayPal、Workday。
- AI/ML 公司和框架：Cohere、Langchain。
- 全球系統整合商 (GSIs) / 顧問公司：Accenture、Deloitte、BCG、Capgemini。
使用案例聚焦（Google 提及的合作夥伴）
鑑於 A2A 才剛剛發表，詳細的實作案例還沒有很多，但以上提及的合作夥伴讓我們有更多 A2A 應用的想像空間：
- SAP：被認定為 A2A 協議的創始貢獻者。SAP 設想 A2A 使不同解決方案和環境中的 AI 代理能夠協作，這對執行業務流程至關重要。一個具體例子涉及在 Gmail 中發起的客戶糾紛：SAP 的 AI 助手 Joule 作為通過 A2A 的編排者，與訪問 BigQuery 中交易數據的 Google 代理協調，驗證糾紛並推薦解決方案，消除了手動系統切換。SAP 還將 Google Gemini 模型整合到其 BTP Generative AI Hub 中。SAP 經常被列為關鍵支持者。
- Salesforce：Google 強調了其 Gemini AI 與 Salesforce 的 Agentforce 平台的整合。A2A 被視為可以在 Salesforce 生態系統內實現「代理間智慧交接」等功能。
- Box：透過 A2A 整合 katanemo/archgw 這樣的項目，允許 AI agent 在 Box 內協作處理安全內容管理和文件共享工作流程。
- Atlassian：認為像 A2A 這樣的標準化協議對於其 Rovo 代理人成功發現、協調和與其他代理推理至關重要，實現更豐富的大規模委派和協作。
- ServiceNow：潛在使用方式涉及自動化 IT 運營工作流程，例如資產管理 AI agent 使用 A2A 請求採購代理為新員工訂購硬體。
- Accenture、Deloitte、BCG、Capgemini：這些 GSIs 作為合作夥伴和服務提供商參與。它們的角色可能專注於為企業客戶提供多代理策略建議，納入 A2A 和實施利用該協議進行跨平台代理協作的解決方案。
✦延伸閱讀：Google Cloud Next 2025 發表會重點整理：Gemini 2.5、多代理平台亮相
開發者實作 A2A 的狀況
Google 提供了一系列資源，幫助開發人員理解、實驗和實作 A2A 協議。
資源
- 官方 GitHub 存儲庫（google/A2A）：這是 A2A 協議的中心樞紐。它託管官方技術文件、定義協議結構的正式 JSON 規範和各種程式碼範例。
- 技術文件網站：可通過 GitHub 存儲庫訪問，該網站提供概念概覽、指南和協議功能的詳細解釋。
- JSON 規範：存儲庫中的專用部分包含正式定義代理卡片、任務、消息、部分和成品結構的 JSON 模式，這對確保互通性至關重要。
程式碼範例、SDKs 和框架整合
為了加速採用，Google 發布了實用範例和整合：
- 範例實作：存儲庫包括 Python 和 JavaScript 中的範例 A2A 客戶端和伺服器程式碼，展示了發送、接收和管理任務的核心機制。雖然基本 README 提供了連結，但特定實施細節需要探索連結的程式碼目錄。
- 示範：提供了一個範例多代理 Web 應用程式和命令行界面（CLI）工具（Python 和 JS），以展示 A2A 的運作。
- 代理框架整合：認識到開發人員通常使用現有代理框架，Google 提供了範例整合，展示如何納入 A2A：
- Google Agent Development Kit (ADK)：Google 自己的開源框架，用於構建代理和多代理系統，為 Gemini 和 Vertex AI 優化。ADK 原生支持 A2A，也包含對 MCP 的支持。
- CrewAI：範例展示與這個流行的協作代理框架整合。
- LangGraph：範例展示如何將 A2A 與 LangGraph 一起使用，LangGraph 是一個用於構建有狀態、多角色 LLM 應用程式的函式庫。
- Genkit (Firebase)：提供了 Genkit 的整合範例，Genkit 是 Firebase 生態系統中用於構建 AI 驅動功能的框架。
- 相關 Google Cloud 工具：Google 正在將 A2A 嵌入其更廣泛的 AI 平台產品中：
- Agent Garden：ADK 和 Vertex AI 內可訪問的預構建 AI agent 範例、模式和工具集合。
- Agent Engine：Vertex AI 內的完全託管代理運行時環境，用於部署、測試、擴展和管理使用 ADK 等框架構建的自定義代理。
- Agentspace：一個企業平台，結合搜尋、對話式 AI 和代理（包括第三方和自定義代理，可能通過 A2A 通信），為員工提供綜合訊息和行動能力。
這一全面的資源套件——包括協議規範、文件、多樣化程式碼範例、框架整合和管理部署工具——展示了 Google 對開發者賦能的承諾。通過提供不僅是標準，還有構建、測試和部署支持 A2A 的 AI agent 的工具，Google 希望減少開發人員採用 A2A 的摩擦力，並將協議緊密整合到其自身的 Google Cloud AI 生態系統中，特別是 Vertex AI。這種整體方法尋求使 A2A 成為構建複雜、協作代理系統的實用且有吸引力的選擇。
A2A 實踐：應用實例與潛力
通信協議的真正價值在於它啟用的應用。A2A 設計用於解鎖目前分散式系統難以實現的複雜多代理工作流程。早期範例和合作夥伴討論凸顯出 A2A 可能產生重大影響的幾個關鍵領域：
轉變企業工作流程
許多核心業務流程涉及多個步驟、系統和部門。A2A 提供了一種跨越這些邊界佈署 AI agent 的方式：
- 招聘：這是一個經常被引用的例子。招聘經理可以任務分配給主要代理（例如，在 Google Agentspace 內）尋找候選人。然後該代理將使用 A2A 與專業遠程代理互動：一個從各種平台尋找候選人，另一個通過與日曆系統互動檢查可用性並安排面試，或是啟動背景調查。A2A 為這種協調努力提供了通信骨幹。
- 客戶服務和支援：解決客戶問題通常需要來自多個後端系統的訊息或操作。支持 A2A 的客戶服務代理可以通過與其他代理協調處理糾紛。例如，它可能請求連接到資料庫的代理提供交易數據（如 SAP/BigQuery 範例）或透過與財務代理通信觸發退款流程。
- IT 運營和員工入職：自動化複雜的 IT 流程是另一個關鍵應用。例如，員工入職涉及人力資源、IT 和設施。佈署讓 AI Agent 可以使用 A2A 向人力資源代理（創建記錄）、IT 代理（準備筆記本電腦、創建帳戶）和設施代理（分配辦公桌、發放門禁卡）發送任務，通過 A2A 狀態更新追蹤進度。同樣，資產管理代理可以通過 A2A 自動提出硬體採購。
- 供應鏈和物流：A2A 可以實現供應鏈中的動態協調。監控物流的代理可能檢測到運輸延遲。它可以使用 A2A 查詢 CRM 代理以識別受影響的客戶，然後任務分配給運營代理重新計算時間表，可能觸發通知。訂單管理代理可以通過 A2A 直接查詢物流代理獲得即時更新。
- 財務和計費：代理可以在財務流程中協作。識別計費錯誤的支持代理可以通過 A2A 直接聯繫財務代理解決問題並啟動退款。財務軟體代理可以使用 A2A 協作進行更自動化的記賬或稅務流程。
實現複雜的多代理人協作
除了簡化現有工作流程外，A2A 旨在實現更複雜的協作形式：
- 研究與開發：複雜的研究任務可以分解並分配給專業代理。主要研究助手代理可以接收高級請求（例如，總結特定領域的趨勢）。然後它可以使用 A2A 委托子任務：任務分配給數據抓取代理收集相關文章，總結代理處理文本，以及報告撰寫代理格式化最終輸出。代理可以協作處理如新藥發現等任務，檢索分子數據，運行模擬，並通過 A2A 報告進度。Google 的 Agent Garden 包括範例，如專為此類綜合任務設計的 Deep Research Assistant 代理。
- 醫療保健：醫療保健中的潛力涉及代理在功能之間協作以優化複雜流程，如收入週期管理或索賠操作，可能主動識別和解決瓶頸。A2A 可以促進分析不同數據模態（文本記錄、圖像、音頻諮詢）的代理之間的通信，提供更全面的視圖。
- 智慧個人助手：未來的個人助手可以利用 A2A 編排複雜請求，調用專業代理網絡。例如，計劃國際旅行可能涉及主助手使用 A2A 查詢航班預訂代理、行程優化代理和實時翻譯代理。
在這些不同的用例中，一個共同的主題浮現：A2A 主要被定位為協調跨越不同系統、部門或專業代理能力的複雜、多步驟工作流程的解決方案。核心價值主張在於自動化和精簡目前分散、手動或需要昂貴定制整合的流程。A2A 旨在提供必要的標準化通訊結構，使這些不同的 AI agent 能夠作為一個統一、自動化的團隊運作。
戰略意義：為什麼 A2A 很重要
Agent2Agent 協議的引入對 AI 的發展、企業自動化和競爭環境帶來了重大的戰略影響。
邁向真正的 AI agent 互通之路
A2A 如果被廣泛採用，將可能成為更高度連結和流暢的 AI 生態系的基礎，超越目前孤立代理能力的狀態。支持者希望 A2A 可能成為代理的「HTTP 時刻」或「通用語言」，使無縫通訊和協作成為可能，就像 Web 協議推動了網際網路的增長。實現真正的互通性被視為釋放多代理系統全部潛力的關鍵。
對 AI 戰略、開發和部署的影響
A2A 等標準的可用性可能從根本上改變組織如何處理 AI 戰略和開發：
- 降低複雜度和成本：通過提供通用通信框架，A2A 旨在大幅減少代理之間定制、點對點整合的需求，降低開發時間和持續維護成本。
- 增加靈活性和選擇：企業可以獲得從不同供應商選擇一流代理或在內部開發專業代理的自由，知道它們可以通過 A2A 互操作，從而減少供應商鎖定。
- 加速部署：標準化通信可以加速複雜多代理系統的部署，因為整合變得更簡單和可預測。
- 促進創新：通用協議可以創建更有活力的生態系統，鼓勵開發人員構建可以輕鬆插入更大協作工作流程的專業代理。
- 設計思維轉變：架構師和開發人員將需要從設計單個代理轉變為設計協作系統，考慮代理如何發現、協商和協調任務。
挑戰與未來之路
儘管有很大的潛力，A2A 在成為廣泛採用的標準的道路上還面臨幾個挑戰：
- 採用障礙：成功取決於超越一開始 50 多個合作夥伴的支持。開發人員和組織需要被說服投入時間和資源實作 A2A，特別是考慮到 MCP 和其他潛在其他選項。
- 標準化爭論：A2A 和 MCP 的同時存在可能讓「協議戰爭」發生。對許多開發人員來說，理想情況當然是一個一統天下的單一協議。
- 技術成熟度：作為新宣布的協議，A2A 需要時間發展成熟。規範需要向穩定的 1.0 版本（計劃於年內晚些時候推出）精煉。流式和推送通知的可靠性，以及身份驗證和授權的精確實作細節等需要進一步鞏固和實際測試。
- 治理和安全：管理複雜性、確保可審計性，以及防止大規模、動態多代理系統中的意外負面後果，仍然是一個重大挑戰，無論使用何種通訊協議。穩健的治理框架將是不可少的。
結論和建議
Google 的 Agent2Agent (A2A) 協議作為一項重要且及時的倡議出現，目的是要解決 AI agent 快速落地時互通性的關鍵挑戰。透過提出 AI agent 間通信、發現和協調的開放標準，A2A 尋求打破目前限制企業內多代理系統潛力的技術孤島。其架構建立在熟悉的 Web 標準（如 HTTP 和 JSON-RPC）之上，其核心概念如用於發現的代理卡片和用於協作的定義任務生命週期，提供了一個結構化框架，使複雜的互動成為可能。
A2A 明確定位為與 Anthropic 的 Model Context Protocol (MCP) 互補，MCP 處理代理與其工具/數據源的連接，而 A2A 促進代理之間的通訊。這種分層方法，如果被採用，將可能為更模組化、可擴展和靈活的企業 AI 架構鋪平道路。
建議
對於開發人員：
- 探索和實驗：參與 A2A GitHub 存儲庫以了解規範和文件。實驗提供的 Python 和 JavaScript 程式碼範例，以掌握核心機制。
- 利用框架：利用 Google 的 ADK、LangGraph 或 CrewAI 等框架的範例整合，了解 A2A 如何適合現有開發模式。
- 提供反饋：通過開源渠道提供反饋並可能貢獻程式碼或範例，參與協議的發展。考慮 A2A 如何在目前或未來項目中實現代理之間的新形式協作。
對於產品經理和架構師：
- 識別機會：評估現有企業工作流程，特別是涉及多個系統或手動交接的工作流程，這些可能是使用支持 A2A 的多代理系統自動化的主要候選。
- 評估整合策略：比較使用 A2A（可能與 MCP 一起）與替代整合方法（自定義 API、擴展現有協議）的潛在利益和複雜性。
- 關注供應商採用的狀況：追蹤與您組織相關的關鍵企業供應商（例如，SAP、Salesforce、ServiceNow）提供的平台和工具中 A2A 的採用和支援。
對於企業領導者：
- 了解戰略潛力：認識到代理互通性，由 A2A 和 MCP 等協議實現，是下一代企業自動化和 AI 驅動效率的關鍵推動因素。
- 審計和規劃：對現有 AI 代理部署進行審計，以識別通訊瓶頸和跨代理協作的機會。在未來 AI 平台決策和供應商選擇中考慮協議標準化和供應商對互通性的支援。
- 與專業機構合作：與技術合作夥伴和顧問公司（如 Accenture、Deloitte 等合作夥伴）合作，探索潛在的 A2A 實作策略，並了解設計和管理多代理系統的最佳實務。
而 A2A 和 MCP 真正讓 AI agent 彼此能夠輕易溝通，帶領人類社會邁向一個「多代理人」的時代，未來 AI 彼此溝通協調即可以完成大部分工作，人類就（再想想要幹嘛好了）。
接下來的幾年，所有的網路服務都必須改變成「AI ready」的形式，網路不再是「網站互連」，而是「AI 互連」，人類偶爾介入指揮一下。
當數位的世界都是 AI agent 在彼此協作的時候，人類文明的網路新時代就真正到來了。
儘管 A2A 目前仍處於早期階段 ，有興趣的企業歡迎與 Google Cloud 技術夥伴、2025 年台灣唯一獲得「Google Cloud Partner of the Year」殊榮的 iKala 聯絡，我們能協助企業進行 Google Agentspace 和 A2A 前期技術評估與導入規劃，歡迎聯繫我們，搶先體驗智慧轉型的全新可能！
