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 初稿发布