- 8 min read

【A2A 系列 #2】深入剖析 A2A：如何讓 AI Agent 彼此溝通與分工？

深入 A2A 協議的技術細節，從 Google A2A Protocol 規範到實際的多代理架構設計，帶你了解 Agent 與 Agent 之間如何安全、可靠地協作完成複雜任務。

AI AI Agent A2A LLM MCP

本文為 A2A 系列第二篇。建議依序閱讀： → 【A2A 系列 #1】從對話到協作：為何 A2A (Agent to Agent) 是 AI 演進的終局之戰？

上一篇我們聊了 A2A 協議的背景與動機：為什麼多 Agent 協作是 AI 演進的必然方向、為什麼我們需要一套通用的溝通標準。這一篇，我們要捲起袖子，直接看協議本身是怎麼設計的。

A2A 協議的核心，可以用五個元件來理解：Agent Card、Task、Message、Part、Artifact。這五個元件，分別對應了多 Agent 協作中的幾個根本問題：

元件問題角色定位
Agent CardWho — 你是誰，你能做什麼？定義與發現
TaskWhat — 這次要完成什麼任務？任務調度
MessageHow — 雙方怎麼溝通、交換資訊？通訊交互
PartHow — 訊息與產物的最小組成單元內容封裝
ArtifactOutput — 任務產生了什麼結果？產出交付

接下來，我們一個一個深入拆解。

Agent Card：Agent 的履歷

想像你是一個企業的 HR，需要在眾多求職者中找到最適合的人選。你會怎麼做？看履歷。

Agent Card 就是 A2A 協議中的「AI Agent 履歷」 —— 一份 JSON 文件，描述一個 Agent 的身分、能力、端點位置與安全需求，讓其他 Agent（或協調器）能夠「找到我」並知道「我能做什麼」。

按照 A2A 規範，Agent Card 存放在一個約定的位置：https://{server_domain}/.well-known/agent-card.json

這個設計借鑒了 Web 生態中 .well-known 目錄的慣例（如 robots.txt），讓 Agent 的發現（Discovery）可以標準化、自動化。

Agent Card 的結構

一份完整的 Agent Card 包含以下幾個核心區塊：

{
  "name": "OpenSearch Expert Agent",
  "version": "1.0.0",
  "description": "專精於 OpenSearch 叢集架構、Query DSL 優化及向量搜尋的技術專家。",
  "provider": {
    "name": "YourOrg Tech",
    "url": "https://yourorg.com"
  },
  "url": "https://api.yourorg.com/a2a/opensearch-agent",
  "documentationUrl": "https://docs.yourorg.com/opensearch-agent",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "skills": [
    {
      "id": "query-optimization",
      "name": "Query DSL 優化",
      "description": "分析並優化複雜的 OpenSearch 查詢語句以提升效能。"
    },
    {
      "id": "vector-search-setup",
      "name": "向量搜尋配置",
      "description": "設定 k-NN 插件與向量索引架構。"
    }
  ],
  "interfaces": [
    {
      "type": "JSON_RPC_2_0",
      "url": "https://api.yourorg.com/a2a/opensearch-agent"
    }
  ]
}

讓我們逐一拆解每個欄位的用途：

1. 基礎資訊（name、version、description）

最直覺的部分 —— Agent 叫什麼名字、目前是哪個版本、用一段話描述自己能做什麼。description 欄位尤其重要，因為協調 Agent（Orchestrator）往往會根據這段描述，決定要不要把任務委派給這個 Agent。

2. 提供者（provider）

定義是誰開發和維運這個 Agent。在企業環境中，這個欄位讓你一眼看出某個 Agent 的「責任歸屬」是哪個團隊或組織 —— 這對建立信任、追蹤問題、管理生命週期都至關重要。

3. 能力宣告（capabilities）

A2A 預設的通訊模式是輪詢（Polling） —— 呼叫方送出任務後，持續主動查詢任務狀態，直到完成。這是最基本、相容性最廣的互動方式。

capabilities 宣告的則是 Agent 是否支援更進階的通訊模式：

  • streaming：是否支援串流回應（SSE），任務執行中即時推送進度，呼叫方不需持續輪詢
  • pushNotifications：是否支援 Webhook 主動通知，Agent 完成後主動回呼，適合長時間非同步任務

這兩個開關，直接影響呼叫方（Caller）能夠選擇什麼樣的互動模式。

4. 技能列表（skills）

如果說 description 是一段「自我介紹」，那 skills 就是履歷上的「專業技能欄」。每個 skill 包含：

  • id：機器可讀的唯一識別符（供程式碼引用）
  • name：人類可讀的技能名稱
  • description：詳細說明這個技能具體能做什麼、在什麼情境下使用

協調 Agent（Orchestrator） 可以利用 skills 做更精準的任務路由：比起把整個任務交給「我大概能處理」的 Agent，不如找到技能描述最吻合的那一個。就像招募人才時，你會優先選擇「履歷上白紙黑字寫著具備此能力」的候選人，而不是「感覺應該做得到」的人。

通訊介面（interfaces）

宣告 Agent 支援哪種通訊協議，目前 A2A 支援三種：

  • JSON_RPC_2_0：最常見的選擇，基於 HTTP 的 JSON-RPC 2.0 協議
  • REST_API：傳統 RESTful 介面
  • GRPC：高效能的 gRPC 二進制協議（適合低延遲、高吞吐量場景）

每個介面都附帶一個 url，告知呼叫方「要去哪裡找我」。

Agent Card 的設計哲學

Agent Card 的核心設計哲學是 「讓機器能夠自動發現與評估 Agent」。

在傳統的 API 世界裡，開發者需要手動閱讀文件、手動整合。但在多 Agent 協作中，協調 Agent（Orchestrator） 必須能夠在 執行時期（Runtime） 動態地找到合適的 Agent、評估它的能力、決定是否委派任務 —— 這一切都必須自動化，不能依賴人工介入。

Agent Card 讓這件事成為可能：它是機器可讀的、結構化的、可被程式化解析的。這就是為什麼它存放在 .well-known 這個約定位置，就像 HTTP 協議的 robots.txt 一樣，任何遵守規範的 Agent 都知道去哪裡查。

Task：Agent 的工單

如果說 Agent Card 定義了「誰能做什麼」，那 Task 就是實際的「工單」 —— 協調 Agent 與執行 Agent 之間的核心協作單元。

Task 是 A2A 協議中最重要的資料結構，它封裝了一次「委派與執行循環」的全部上下文：

Task = 意圖（Intent）+ 脈絡（Context）+ 交付標準（Definition of Done）

Task 的結構

A2A 協議溝通元件總覽

元資料（metadata）

記錄 Task 本身的狀態管理資訊：

  • taskId：全域唯一識別符，讓任何 Agent 都能引用、查詢這個任務
  • status：目前的執行狀態（submitted、working、completed、failed、cancelled…）
  • createdAt、updatedAt：時間戳，供稽核與追蹤使用

對話記錄（messages[]）

Agent 間交換意圖與結果的訊息序列，封裝了完整的對話流（Flow）。每一條 Message 都有 role 屬性（user 或 agent），讓任何閱讀 Task 的一方能夠清楚分辨「誰說了什麼」。

Message 支援多輪對話 —— 如果執行 Agent 需要更多資訊才能繼續（例如「請問你要查詢哪個時間區間的資料？」），它可以透過 Message 向協調端請求澄清，Task 狀態會進入 input-required，等待回應後再繼續。

執行產物（artifacts[]）

Task 執行過程或結束後產生的實體，封裝了：

  • 執行結果：任務完成後的輸出（如分析報告、生成的程式碼、查詢結果）
  • 日誌（Logs）：執行過程中的追蹤記錄
  • 系統狀態快照：某個時間點的系統狀態截圖（適合需要稽核的場景）

Part：訊息與產物的最小單元

無論是 Message 還是 Artifact，它們的實際內容都是由一個或多個 Part 組成的。

Part 是 A2A 協議中粒度最細的資料容器，支援四種類型：

類型說明使用場景
TextPart純文字字串自然語言訊息、說明文字
BinaryPart二進制資料（Base64 編碼）圖片、PDF、任意二進制檔案
UrlPart外部資源連結指向大型檔案、雲端儲存的連結
DataPart結構化 JSON機器可解析的資料、API 回應

為什麼需要 Part 這個層次？

你可能會想：直接把內容放進 Message 或 Artifact 不就好了，為什麼還要多一層 Part？

想像一個資料分析 Agent 交付了一份市場報告，這份報告裡面可能有：

  • 一段文字摘要（TextPart）
  • 一份數據表格（DataPart）
  • 一張圖表（BinaryPart）
  • 原始資料的下載連結（UrlPart）

這四樣東西合在一起才叫「這份報告」。如果 Artifact 只能放一種格式，你就得拆成四個 Artifact —— 但它們明明描述的是同一件事。

Part 就是為了解決這個問題：讓一個 Artifact 可以同時裝下不同格式的內容，但在外部看起來仍然是一個完整的產出物。

小結

A2A 協議用五個精心設計的元件，回答了多 Agent 協作中最核心的問題：

  • Agent Card：我是誰、我能做什麼、去哪裡找我 —— 讓 Agent 的發現與信任建立可以自動化
  • Task：這次要完成什麼 —— 提供任務協作的完整上下文，支援狀態追蹤與多輪對話
  • Message：我們怎麼溝通 —— 封裝對話流與狀態更新，支援澄清與協商
  • Part：訊息與產物的最小組成單元 —— 靈活封裝純文字、Binary、URL、結構化 JSON 等各種內容格式
  • Artifact：任務產出了什麼 —— 以 Part 為單位組合，交付完整的執行結果

回到第一篇提到的那個比喻：秦始皇書同文、車同軌，不是為了讓每個人都說一樣的方言，而是定義一套所有人都看得懂、用得了的共同語言。A2A 做的事情本質上一樣 —— 它不規定你的 Agent 內部怎麼思考、用什麼模型，只定義 Agent 與 Agent 之間要說什麼、怎麼說。格式統一了，協作才能規模化。

在下一篇，我們將進一步探討 A2A 協議中的安全機制與身份驗證，以及如何在實務中建構一個真正可信賴的多 Agent 系統。

下一篇：【A2A 系列 #3】Task 狀態機與安全架構：讓多 Agent 協作真正可信賴

如果這篇文章對你有幫助，歡迎分享給對 AI Agent 感興趣的朋友。

← 返回 Blog