A2A Protocol 技术文档
核心主题
扩展与协议绑定治理

扩展与协议绑定治理

A2A 组织为扩展 和自定义协议绑定 建立了统一的治理框架。本文定义在 A2A 组织内提议、开发、晋升和维护这些制品的正式流程。

任何人都可以独立开发和发布扩展或自定义协议绑定。这里描述的层级与生命周期，仅适用于托管在 a2aproject GitHub 组织下的制品。

层级

在 a2aproject 组织内，扩展和自定义协议绑定都采用两级体系。仓库命名和 URI 前缀因类型而异：

扩展自定义协议绑定
官方仓库前缀ext-{name}cpb-{name}
实验性仓库前缀experimental-ext-{name}experimental-cpb-{name}
官方 URI 前缀https://a2a-protocol.org/extensions/https://a2a-protocol.org/bindings/

URI 命名空间

官方 URI 前缀是规范的命名空间标识，用于为扩展和自定义协议绑定分配全局唯一的 URI。智能体和客户端在 Agent Card、请求头和协议消息中引用这些 URI，以声明并协商支持情况。

前缀下的具体 URI 标识一个特定的制品，并在适用时标识其版本，例如 https://a2a-protocol.org/extensions/{name}/v1 或 https://a2a-protocol.org/bindings/{name}/v1。这些 URI 只是标识符，并不要求能通过 HTTP 访问。

官方（Official）

官方制品在 a2aproject GitHub 组织下开发和维护，由技术指导委员会（TSC）正式推荐。每个仓库都在 MAINTAINERS.md 中指定了维护者。

要求：

  • 规范必须使用与核心规范相同的措辞规范（RFC 2119 ）；
  • 必须采用 Apache 2.0 许可；
  • 必须至少有一个参考实现；
  • 应在 A2A 网站上有配套文档。

实验性（Experimental）

实验性制品为社区贡献者提供孵化通道，让他们在晋升为官方之前对想法进行原型验证和协作。

创建要求：

  • 实验性仓库只能在 A2A 维护者的赞助下创建；
  • 赞助维护者负责实验性制品的初期监督；
  • 实验性仓库必须在 README 中清楚标明其实验性/非官方状态；
  • 任何发布的软件包必须使用能清楚表明实验性质的命名；
  • TSC 保留监督权，包括归档或移除实验性仓库的权力。

生命周期

扩展和自定义协议绑定经历以下阶段。

提议阶段

任何社区成员都可以提议一个扩展或自定义协议绑定：

  1. 提交 Issue：在主仓库 a2aproject/A2A 中创建 Issue，说明：
    • 摘要：扩展的目的，或绑定所对应的传输方式与用例；
    • 动机：说明为什么无法用核心协议或既有的标准绑定实现；
    • 初步的技术方案或规范草案。
  2. 社区讨论：提议开放给社区反馈和完善。

维护者赞助

提议要进入实验性状态，需要：

  1. 获得赞助人：一位 A2A 维护者必须同意赞助该提议；
  2. 创建仓库：赞助维护者在 a2aproject 下创建 experimental-ext-* 或 experimental-cpb-* 仓库；
  3. 监督：赞助维护者提供初期监督，确保与 A2A 设计原则一致。

实验性开发

处于实验性状态期间：

  • 贡献者对规范和参考实现进行迭代；
  • 早期采用者可以使用该实验性制品，但需要理解会出现破坏性变更；
  • 收集并吸纳社区反馈；
  • 实验性仓库必须清楚标明其非官方状态。

晋升为官方

要把实验性扩展或绑定晋升为官方，需要：

  1. 成熟度要求：
    • 至少一个生产级质量的参考实现；
    • 满足 A2A 标准的文档；
    • 社区采用或关注的证据；
    • 维护者对持续维护的明确承诺。
  2. 晋升提议：在 a2aproject/A2A 中创建 Issue，包含：
    • 对实验性仓库及其实现的引用；
    • 社区反馈与采用情况的摘要；
    • 官方制品的拟任维护者。
  3. TSC 投票：
    • 提议被列入 TSC 会议议程；
    • 法定人数：至少 50% 的 TSC 表决成员出席；
    • 通过条件：需要出席成员的多数票同意（依据 A2A 治理规则）；
    • TSC 可以在最终投票前要求修订。
  4. 接受：
    • （扩展）仓库从 experimental-ext-* 重命名为 ext-*，并在 A2A 网站的扩展页面添加文档；
    • （自定义协议绑定）仓库从 experimental-cpb-* 重命名为 cpb-*，并在 A2A 网站的自定义协议绑定页面添加文档。

官方后的迭代

成为官方之后，扩展和绑定仍可继续迭代：

  • 仓库维护者负责日常治理；
  • 变更应通过相关工作组协调（如果存在）；
  • 破坏性变更需要新的标识符；
  • 破坏性变更需要 TSC 审查；
  • 维护者应与 SDK 维护者协调实现更新。

晋升为核心协议

部分扩展最终可能转变为核心协议特性，部分自定义协议绑定也可能转变为核心绑定。这通过既有的 A2A 规范增强流程管理：

  • 按标准的规范变更流程提交提议；
  • 提议引用官方扩展或绑定及其采用情况；
  • 适用标准法定人数和多数票要求的 TSC 投票；
  • 并非所有扩展或绑定都适合纳入核心，许多会长期保持扩展或自定义绑定的形态。

SDK 支持

扩展与官方自定义协议绑定的 SDK 支持要求不同，反映了它们在协议生态中角色的差异。

扩展：A2A SDK 可以实现扩展。如果实现：

  • 扩展必须默认禁用，需要显式启用；
  • SDK 文档应列出所支持的扩展；
  • SDK 维护者对扩展支持决策拥有完全自主权；
  • 扩展支持不是协议一致性所必需的。

官方自定义协议绑定：A2A SDK 应实现官方自定义协议绑定。如果实现：

  • 自定义协议绑定必须默认禁用，需要显式启用；
  • SDK 文档应列出所支持的自定义协议绑定；
  • SDK 维护者对绑定支持决策拥有完全自主权；
  • 自定义协议绑定支持不是协议一致性所必需的。

法律要求

许可

官方扩展和自定义协议绑定必须采用 Apache 2.0 许可，与 A2A 核心项目保持一致。

贡献者授权

向官方 A2A 扩展或自定义协议绑定仓库提交贡献，即表示贡献者声明：

  1. 他们具有授予相关权利的法律权限；
  2. 贡献是原创作品，或他们拥有足够的权利提交该内容；
  3. 他们向 Linux Foundation 及接收方授予永久、全球范围、非排他、免版税的许可，用于使用、复制、修改和分发该贡献。

反垄断

扩展和自定义协议绑定的开发者确认：

  • 他们可能与其他参与者存在竞争；
  • 他们没有义务实现任何扩展或绑定；
  • 他们可以自由开发相互竞争的扩展或绑定；
  • 官方扩展或绑定的地位不构成排他性关系。

来源：A2A 官方文档 · Extension and Protocol Binding Governance

自定义协议绑定