講完怎麼用 Google ADK 打造單一 Agent 後，今天我們進入多 Agent 協作

今天介紹什麼

1. 名稱：代理對代理通訊協定（Agent-to-Agent Protocol, A2A）
2. 官方網站：https://a2a-protocol.org
3. 開源組織：由 Google 發起並貢獻託管於 Linux 基金會（Linux Foundation）之開放標準（現由 Agentic AI Foundation 共同治理）

為什麼要用這個？

前兩天我們介紹了如何使用 Google 代理開發套件（Agent Development Kit, ADK）來定義單一代理（Agent）、掛載工具以及處理對話流程。

然而，當系統規模擴展到企業級應用時，單一代理往往難以承擔所有專業責任。許多開發者常問：「既然在單一專案內寫多個子代理（Subagents）也能達成任務分工，為什麼科技巨頭們還要共同制定 A2A 協定？」

想像一個典型的軟體開發團隊情境：專案中通常有負責系統規劃與模組切分的軟體架構師、專精漏洞挖掘與合規檢查的資安工程師，以及負責撰寫測試與自動修補程式碼的後端工程師。

1. 情境 A（單一專案內部）：如果這三種角色的 AI 代理全由內部同一個團隊在同一個專案 Repo 內維護，使用同一種程式語言開發且運行在同一個進程或主機上，使用一般的內部函式呼叫或子代理（Subagents）機制就完全足夠。
2. 情境 B（跨雲端跨企業）：但若資安審查代理是由外部獨立的專業資安廠商以 SaaS 形式託管，架構代理運行在自家的公有雲，兩邊使用不同程式語言開發（例如一個用 Python、一個用 Go），且雙方受限於合規與營業秘密不能直接互訪記憶體與內部邏輯——這時就無法直接用物件指標或內部函式互通，而需要一套全業界通用的開放通訊標準。

這就是 A2A 的核心價值：它解決的不是單一專案內部的函式分工，而是跨系統、跨組織、跨框架的代理自主協作。

A2A 核心架構與技術亮點

1. 代理名片機制（Agent Card）

每個遵循 A2A 規範的代理微服務，都會在公開端點提供一份標準的「代理名片」（正式標準端點為 /.well-known/agent-card.json）。

這張名片就像是 AI 的數位營業執照，內容記載：

1. 代理身分與版本資訊：名稱、描述、提供者與版本
2. 支援的技能清單（Skills）：該代理能處理的業務能力
3. 輸入與輸出資料合約規格（Schema）：資料交換欄位與格式定義
4. 傳輸協議與通訊支援：基於 HTTP(S) 的 JSON-RPC 2.0，並支援 SSE（Server-Sent Events）串流模式

呼叫端代理不需要在程式碼中寫死對方的內部邏輯，只需在網路上讀取對方的名片，即可動態辨識能力並發起任務委派。

2. 同儕協商與自癒式退件修訂迴圈（Revision Loop）

過去傳統的單向流水線架構中，下游一旦發現產出有誤，通常只能中斷並交由人類手動介入修改。

A2A 支援雙向同儕狀態交換與任務生命週期管理。以審核流程為例：

1. 當審核代理檢查出文案字數超標、格式不符或缺少必備標籤時，可以直接回傳退件修訂狀態（REVISION_REQUESTED）並附帶具體修正建議。
2. 負責產出的代理收到通知後，會在背景自動重新調整並再次送審。

在成果呈報給使用者之前，代理群內部就已自動完成校正與品質把關。

3. 打破技術藩籬與供應商綁定

A2A 協定是由 Google 發起並託管於 Linux 基金會的開放標準，獲得 AWS、微軟（Microsoft）、Salesforce、SAP、思科（Cisco）與 IBM 等科技巨頭共同支持。

無論代理底層是用 Python、Go、Java 撰寫，或是部署在 Google Cloud、AWS 甚至地端伺服器，只要遵循 A2A 協定規範，就能無縫互相委派任務。

4. 零信任架構下的隱私隔離

代理之間溝通時，不需要公開各自內部的提示詞（Prompt）或私有記憶體，僅針對協定定義的輸入與輸出合約進行資料交換。不同企業的 AI 可以在完全不洩漏商業機密的前提下完成跨組織商業協商。

A2A 與常見技術的定位差異

A2A 與模型上下文協定（Model Context Protocol, MCP）的分工

1. 模型上下文協定（MCP）：主要定位為 Agent-to-Tool（代理對工具/資料），解決單一代理如何存取資料庫、讀取檔案或呼叫外部 API。
2. 代理對代理通訊協定（A2A）：主要定位為 Agent-to-Agent（代理對代理/協同），解決不同獨立代理之間如何分發任務、協商與驗收成果。

總結說明：在實務架構中，代理通常透過 MCP 取得資料與本機工具，再透過 A2A 與外部同儕代理協作。

A2A 與單體子代理（Subagents）的本質區別

1. 子代理（Subagent）：屬於主從從屬關係（Master-Slave），生命週期與母體程式綁定，通常在同一進程內運作，無法脫離單一專案獨立存在。
2. A2A 代理（Autonomous Peer）：屬於獨立運行的雲端微服務，各自具備獨立的網路網址、運算資源、安全憑證與服務水準協議（SLA），可同時被多個不同系統調度。

如何搭配 Google ADK 實作 A2A？

Google 官方的代理開發套件（ADK）原生支援 A2A 擴充套件，安裝方式如下：

pip install "google-adk[a2a]" uvicorn

1. 服務提供端（Exposing an Agent）

只需透過內建輔助函式 to_a2a，即可將既有的 ADK 代理轉為符合 A2A 規範的 ASGI 網路服務，並搭配 uvicorn 啟動：

import uvicorn
from google.adk.a2a.utils.agent_to_a2a import to_a2a

# 假設 root_agent 為既有定義好的 ADK 根代理
# to_a2a 會自動產出 /.well-known/agent-card.json 並建立 ASGI 應用
app = to_a2a(root_agent, port=8001)

if __name__ == "__main__":
    # 啟動伺服器，常駐監聽 8001 連接埠
    uvicorn.run(app, host="0.0.0.0", port=8001)

2. 客戶調用端（Consuming a Remote Agent）

若你的本機代理需要調用遠端由他人託管的 A2A 服務，ADK 提供了 RemoteA2aAgent 代理客戶端，讓遠端代理能像本地元件一樣被無縫掛載與調用：

from google.adk.agents.remote_a2a_agent import RemoteA2aAgent

# 透過遠端暴露的 Agent Card 註冊遠端代理
remote_security_checker = RemoteA2aAgent(
    name="RemoteSecurityChecker",
    agent_card_url="http://security-service.example.com:8001/.well-known/agent-card.json"
)

# 接著即可將 remote_security_checker 當成本地代理的子代理直接調度
root_agent.add_subagent(remote_security_checker)

在 GCP Agent Platform（原 Vertex AI）上設定與部署 A2A

在雲端生產環境中，Google Cloud 的 Agent Platform（核心託管引擎為 Vertex AI Agent Engine）提供了對 ADK 與 A2A 協定的原生支援，免去自行維護底層主機與網路負載平衡器的複雜度。

模式一：透過 Vertex AI Agent Engine 進行全託管部署（推薦）

這是最具彈性、開箱即用且原生整合 GCP 監控（Cloud Trace / Logging）的伺服器無知（Serverless）部署模式。

1. 前置準備與套件安裝

確保已完成 GCP 驗證並安裝相關支援庫：

gcloud auth application-default login
pip install "google-cloud-aiplatform[adk,agent_engines]"

2. 將 ADK Agent 發布至 Agent Engine

透過 vertexai.agent_engines 模組，可直接將 ADK 代理打包並發布至 GCP 雲端：

import vertexai
from vertexai import agent_engines
from google.adk.agents import Agent
from google.adk.apps import AdkApp

# 初始化 GCP 專案與區域
vertexai.init(project="your-gcp-project-id", location="us-central1")

# 1. 定義業務代理
architect_agent = Agent(
    name="SoftwareArchitectAgent",
    model="gemini-2.5-pro",
    instruction="你是一位專業的軟體架構師，負責審核系統架構與程式碼設計規範。"
)

# 2. 包裝為 AdkApp
app = AdkApp(agent=architect_agent)

# 3. 部署到 Vertex AI Agent Engine
remote_engine = agent_engines.create(
    agent_engine=app,
    display_name="software-architect-a2a-service",
    requirements=[
        "google-adk[a2a]",
        "google-cloud-aiplatform[adk,agent_engines]"
    ]
)

print(f"Agent Engine 部署成功！資源 ID：{remote_engine.resource_name}")

部署後，Agent Platform 會全自動維護 /.well-known/agent-card.json 端點，並支援與其他雲端代理透過 A2A 協定直接握手。

模式二：容器化部署至 Cloud Run

若你需要自訂網域名稱、搭配特定 VPC 內部私有網路，或偏好自訂 Docker 映像檔，可以選擇部署在 Cloud Run：

1. 撰寫進入點（main.py）

import os
import uvicorn
from google.adk.a2a.utils.agent_to_a2a import to_a2a
from my_agent import root_agent

# 讀取 Cloud Run 預設的 PORT 環境變數（8080）
port = int(os.environ.get("PORT", 8080))
app = to_a2a(root_agent, port=port)

if __name__ == "__main__":
    uvicorn.run(app, host="0.0.0.0", port=port)

2. 一鍵源碼部署至 Cloud Run

透過 Google Cloud CLI 直接打包源碼發布：

gcloud run deploy code-reviewer-agent \
  --source . \
  --region us-central1 \
  --allow-unauthenticated \
  --port 8080

部署完成後即可取得 HTTPS 網址，其他代理直接存取 https:///.well-known/agent-card.json 即可完成代理探索。

企業級安全：跨專案零信任驗證（Zero Trust）

在生產環境中，建議關閉公開未授權存取，改以 GCP 服務帳戶（Service Account）+ OIDC Token 進行身分鑑別：

1. 呼叫端代理在發起 A2A JSON-RPC 請求時，在 HTTP Header 注入 Identity Token：Authorization: Bearer $(gcloud auth print-identity-token)
2. 接收端的 Agent Engine / Cloud Run 會自動校驗憑證與 IAM 角色權限，落實跨團隊、跨雲端的零信任架構！