A2A Extensions 2026 年 9 月 9 日發布什麼？AI Agent 擴展機制與 JSON 協議詳解

閱讀前速覽

維度	說明
官方發布	2025-09-09 Google Developers Blog《A2A Extensions: Empowering Custom Agent Functionality》
核心產物	用 URI 標識的可選協議擴展：新資料、新約束、新 RPC、新狀態機
JSON 載體	Agent Card 的 capabilities.extensions[]
協商方式	HTTP 頭 A2A-Extensions，預設不啟動
2026 定位	A2A 負責 Agent 互操作；Extensions 負責領域定製；不替代 MCP 或 Function Calling

9 月 9 日發布了什麼？

A2A（Agent2Agent）本身已經規定了 Agent 如何發現彼此、傳送任務、串流回傳結果。但核心協議必須保持通用——它不可能內建「語音延遲廣播」「端對端追蹤」「零信任握手」這類垂直能力。2025 年 9 月 9 日，Google 工程師在官方博文裡給出的答案是：Extensions。

那天落地的不是某一個新 RPC，而是一整套開放擴展機制：

• 任何人都可以定義、發布、實作擴展，用唯一 URI 標識（建議帶版本號，如 https://example.com/ext/my-extension/v1）。
• Agent 在 Agent Card（一份描述能力的 JSON）裡宣告自己支援哪些擴展。
• Client 在單次請求上用 HTTP 頭按需啟動；未宣告的用戶端仍走核心協議，不被破壞。
• 官方同時給出 Hello World：給 Message / Artifact 的 metadata 打時間戳。

到 2026 年，規範已經寫進 A2A Extensions 專題，並出現治理框架（官方擴展使用 https://a2a-protocol.org/extensions/ 前綴）。下面按 JSON 協議把機制拆開。

A2A 協議與 Agent Card JSON

可以把 Agent Card 理解成 Agent 的「機器可讀名片」：名稱、描述、入口 URL、輸入輸出 MIME、技能列表，以及 capabilities。Extensions 掛在 capabilities 上，而不是另起一份檔案。

一份帶擴展的 Agent Card 大致如下（結構來自官方範例，欄位名以現行規範為準）：

{
  "name": "Magic 8-ball",
  "description": "An agent that can tell your future... maybe.",
  "version": "0.1.0",
  "url": "https://example.com/agents/eightball",
  "capabilities": {
    "streaming": true,
    "extensions": [
      {
        "uri": "https://example.com/ext/konami-code/v1",
        "description": "Provide cheat codes to unlock new fortunes",
        "required": false,
        "params": {
          "hints": [
            "When your sims need extra cash fast"
          ]
        }
      }
    ]
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain"],
  "skills": [
    {
      "id": "fortune",
      "name": "Fortune teller",
      "description": "Seek advice from the mystical magic 8-ball",
      "tags": ["mystical"]
    }
  ]
}

除錯這份 JSON 時，用 JSONSort 格式化 先確認括號與逗號，再對照 Schema 看 extensions[] 是否缺欄位。Agent Card 會在網路上公開，切勿把金鑰寫進 params。

擴展機制：宣告、預設關閉、按請求啟動

Extensions 的設計目標是擴展 A2A 而不撕裂核心標準。規範明確了幾條邊界：

1. 預設不啟動。 不認識擴展的用戶端仍能呼叫核心方法，獲得基線體驗。
2. Client 主動 opt-in。 在 HTTP 請求裡帶 A2A-Extensions，值為逗號分隔的 URI 列表。
3. Agent 忽略不支援的 URI，並在回應頭回顯實際啟動的擴展。
4. required: true 是硬依賴。 用戶端若不啟動或不遵守，Agent 應拒絕請求。資料展示類擴展不要標 required。

擴展可以依賴其他擴展（必需或可選）。規範要求在擴展說明書裡寫清依賴；啟動時由 Client 一併帶上依賴 URI。版本號應寫進 URI：破壞性變更必須換新 URI，Agent 不得悄悄回退到另一版本。

AgentExtension JSON 欄位詳解

規範還劃了一條紅線，避免擴展破壞核心型別校驗：不要給協議已定義的資料結構加減必填欄位，自訂屬性放進已有的 metadata map；不要往列舉裡加新值，額外語意同樣寫進 metadata。這兩條直接決定你的 JSON 該長什麼樣。

請求協商：HTTP 頭 + JSON-RPC 訊息

啟動發生在每一次 HTTP 請求上，而不是「連上就永久開啟」。典型請求（官方 Hello World 風格）：

POST /agents/eightball HTTP/1.1
Host: example.com
Content-Type: application/json
A2A-Extensions: https://example.com/ext/konami-code/v1

{
  "jsonrpc": "2.0",
  "method": "SendMessage",
  "id": "1",
  "params": {
    "message": {
      "messageId": "1",
      "role": "ROLE_USER",
      "parts": [{"text": "Oh magic 8-ball, will it rain today?"}]
    },
    "metadata": {
      "https://example.com/ext/konami-code/v1/code": "motherlode"
    }
  }
}

對應回應應回顯啟動成功的擴展：

HTTP/1.1 200 OK
Content-Type: application/json
A2A-Extensions: https://example.com/ext/konami-code/v1

{
  "jsonrpc": "2.0",
  "id": "1",
  "result": {
    "message": {
      "messageId": "2",
      "role": "ROLE_AGENT",
      "parts": [{"text": "That's a bingo!"}]
    }
  }
}

注意 params.metadata 的鍵是擴展 URI 加路徑後綴，而不是隨便起的短欄位名。這樣多個擴展可以同時往同一份 JSON-RPC 裡塞資料，而不會撞名。排查「擴展沒生效」時，先看請求頭有沒有帶 URI，再 diff 請求/回應 JSON——JSON Diff 很適合對比啟動前後的 metadata。

四類擴展：資料、Profile、方法、狀態機

規範故意把「擴展能做什麼」寫得很寬，但 2026 年能預見的用法可以收成四類：

• 資料型（Data-only）：只在 Agent Card 裡多暴露結構化資訊，不改變請求-回應流程。例如宣告 GDPR 合規欄位。這類不應標 required: true。
• Profile 型：給核心訊息疊加更嚴的結構或狀態約束，相當於給 A2A 套一層 profile。例如要求所有 parts 必須是符合某 Schema 的 DataPart；或在 TaskStatus.state === "working" 時用 metadata["generating-image"] 表示子狀態。
• 方法型（Extended Skills）：新增核心集合之外的 RPC。例如 task-history 擴展增加 tasks/search，讓 Agent 多一項「可檢索歷史任務」的技能。
• 狀態機型：給任務狀態機增加狀態或遷移。這是最容易踩紅線的一類，必須把新語意放進 metadata，而不是改核心列舉。

發布當天點名的落地案例

Google 博文沒有只講抽象機制，而是列了當時已經在用的擴展，方便對照 JSON 該承載什麼。

Traceability（可追溯）：核心訊息是 ResponseTrace——一份獨立於主協議的結構化日誌，記錄 Agent 採取的步驟。每個 Step 要麼是 ToolInvocation（調工具/API），要麼是 AgentInvocation（再調另一個 Agent）。步驟可以巢狀：下游 Agent 若也支援該擴展，其 trace 會掛在上游步驟裡，形成端對端呼叫樹。這對評估多 Agent 協作、定位錯誤至關重要，卻不必寫進 A2A 核心。

Twilio Latency Extension：語音 Agent（ConversationRelay）需要廣播延遲，以便挑選最適合的下游模型或優雅降級。延遲並不屬於 Agent Card 的核心欄位，Twilio 用擴展補上，是「領域資料不該汙染核心協議」的典型例子。

Identity Machines：用擴展做 Agent 之間的零信任握手。任務委派前按策略門檢查目的、預算、能力、模型、PII 狀態等自訂條件。JSON 在這裡承載的是策略上下文，而不是聊天文字。

博文還提到 Ethereum 的 ERC-8004 方向：用鏈上身分/聲譽/驗證註冊表給跨組織 Agent 建信任層。它不一定以 A2A Extension 形式發布，但說明同一問題——核心協議解決「怎麼說話」，擴展與外部標準解決「憑什麼信任」。

和 MCP、Function Calling 是什麼關係？

三套東西都輸出 JSON，但層級不同，2026 年不該互相替代：

常見架構是分層：MCP Server 提供工具 → 宿主把工具對應為模型的 Function Calling → 多個 Agent 之間用 A2A 派發任務，並用 Extensions 攜帶追蹤、延遲、身分等跨 Agent 資料。關於前兩層的 JSON 對比，見上一篇 MCP Tool Schema vs Function Calling。

用 JSON Schema 約束擴展資料

擴展規範應至少寫清：URI 列表、params 的 schema、Client/Agent 之間額外資料結構、新的請求-回應流。落地時建議：

• 為 AgentExtension.params 和 metadata 鍵各維護一份 JSON Schema。
• CI 裡用範例 payload 做校驗；把 Agent Card 當公開 API 契約。
• 擴展相關輸入一律視為不信任資料，先 parse 再 validate。

JSON Schema 寫法可參考本站 JSON Schema 完整教程。本地格式化、語法檢查與多版本 Diff，用 JSONSort 即可，不必把含策略或身分資訊的 Card 上傳到第三方站點。

常見誤區

• 把 Extension 當成「隨便加欄位」。 核心結構不能改；新資料進 metadata。
• 資料型擴展標 required。 會無謂拒絕大量用戶端。
• URI 不帶版本。 破壞性變更無處可逃，協商也會亂。
• 版本不匹配時回退到舊實作。 規範要求忽略該啟動請求，而不是偷偷相容。
• 新 RPC 繞過原有鑑權。 擴展方法必須走與核心方法相同的認證授權。
• 和 MCP 工具列表混為一談。 MCP 解決「有哪些工具」；A2A Extension 解決「兩個 Agent 怎麼按領域規矩說話」。

常見問題（FAQ）

A2A Extensions 是 2026 年 9 月 9 日發布的嗎？

官方博文日期是 2025 年 9 月 9 日。2026 年人們仍按這個日期檢索「發布了什麼」；機制本身已寫入現行 A2A 規範，並持續有治理與範例擴展（Traceability、Timestamp、Secure Passport 等）。

必須實作擴展才能用 A2A 嗎？

不必。擴展預設關閉。只有對方 Agent Card 把某擴展標為 required，你才必須按規範啟動並遵守。

擴展 JSON 應該放在訊息體還是 HTTP 頭？

啟動列表放在 A2A-Extensions 頭；擴展攜帶的業務資料放在 JSON-RPC params.metadata（或其他規範指定的位置）。頭負責協商，JSON 負責載荷。

如何除錯 Agent Card 和擴展 metadata？

在本地用 JSONSort 格式化 Card、校驗 Schema、diff 兩個版本的 extensions 陣列。不要把含身分或策略的 JSON 貼到線上工具。

結論

9 月 9 日發布的不是又一個廠商私有 API，而是 A2A 的開放擴展層：用 URI 命名能力，用 Agent Card JSON 宣告，用 A2A-Extensions 按請求啟動，用 metadata 承載領域資料。2026 年建構多 Agent 系統時：核心對話走 A2A，工具供給走 MCP，模型意圖走 Function Calling，垂直需求用 Extensions——四者各管一層，JSON Schema 作為參數與擴展資料的單一事實來源。

延伸閱讀

• Google：A2A Extensions 發布博文 2025-09-09 原文與案例
• A2A Extensions 規範專題 宣告、啟動、治理與限制
• MCP Tool Schema vs Function Calling 工具層 JSON 對比
• JSONSort 本地 JSON 工具箱 格式化、語法校驗、Diff

更新紀錄：2026-08-28 初稿發布