背景
当前仓库已经明确从 A2A 0.3 升级到 1.0,且该升级视为 breaking change。
本仓库后续不再为 0.3 保留兼容胶水、过渡包装或双轨 contract。旧版本可通过 release/tag 继续服务既有使用者;main 上的新版本应直接按照 A2A 1.0 的最佳实践收敛 extensions 设计、声明、发现、协商与披露模型。
当前仓库在 extensions 方向的一个关键问题是:虽然已经建立了较完整的 extension contract 体系,但 extension identity 仍然强绑定到 GitHub blob/main 文档地址,且 public Agent Card 对 provider-private/operator-sensitive capability 的公开面仍然偏大。这些做法可以工作,但不适合作为 A2A 1.0 长期稳定形态。
参考伞 issue:
官方参考:
总体原则
- 以 A2A 1.0 当前官方文档为最佳实践基线,而不是继续沿用 0.3 时代的过渡设计。
- 不再考虑 0.3 兼容;不新增任何过渡性 alias、双写、双读或兼容解释层。
- 保留“通过 Agent Card 声明 extensions”的标准路径,不把 extensions 退化成仅靠 README/OpenAPI 才能发现的私有 contract。
- 将 extension identity 与源码仓库路径解耦,避免把协议标识长期绑定到 GitHub
blob/main。
- 保持 public Agent Card 最小披露;更详细或更敏感的 provider-private contract 走 authenticated extended card。
- breaking change 允许直接改到位,不为旧 consumer 保留额外负担。
本仓库需要解决的核心问题
1. extension identity 不应绑定 GitHub 文档页面
当前 extension URI 直接使用 GitHub blob/main 文档地址。该方案存在以下问题:
- 协议 identity 与源码托管路径强耦合
- 仓库改名、迁移、私有镜像、文档重构都会影响 contract 稳定性
- deployer 无法在不暴露源码仓库地址的前提下复用同一能力模型
- 不符合“稳定 URI / permanent identifier”方向
目标方向:
- 使用稳定的、可长期治理的 extension URI
- 优先考虑可控 HTTPS 命名空间或 permanent identifier(如
w3id 风格)
- 如需保留 GitHub 文档,仅作为 spec 承载页,不再作为 extension identity 本身
2. public Agent Card 与 authenticated extended card 的披露边界需要重新收敛
当前 public Agent Card 虽然已经做了参数瘦身,但仍然直接公开了较多 provider-private/operator-sensitive extension capability。
目标方向:
- public Agent Card 仅保留低敏、共享、基础 discoverability 所需的 extension 声明
- provider-private、operator-scoped、deployment-conditional extension 改为在 authenticated extended card 中声明详细能力
- 不再让 anonymous discovery 默认暴露过厚的私有 control-plane capability 面
3. extension 规范页面与标准协商路径需要对齐
目标方向:
- extension specification 明确回答:identity、versioning、params schema、activation、dependencies、security、披露边界
- 对请求级协商路径进行统一梳理,确保声明、请求、响应回显、运行时行为一致
- 避免“文档是一个体系、Agent Card 是一个体系、OpenAPI 又是另一个体系”的漂移
建议拆分阶段
阶段 0:定 A2A 1.0 extension 最佳实践基线
需要产出:
- 本仓库的 extension URI 命名与稳定性原则
- public vs authenticated extended card 的披露分层规则
- provider-private / shared / deployment-conditional 的分类规则
- extension specification 的规范模板
阶段 1:重做 extension identity 与文档托管边界
需要落地:
- 从 GitHub
blob/main URI 迁移到稳定 extension URI
- 定义旧 URI 是否完全移除,还是仅在 release 线保留历史实现
- 同步更新 Agent Card、authenticated extended card、OpenAPI、测试与文档
阶段 2:重构 card 披露面与标准声明路径
需要落地:
- 重新审查哪些 extension 应出现在 public Agent Card
- 重新审查哪些 extension 仅应在 authenticated extended card 声明详细 contract
- 保持“extension 通过 Agent Card 声明”的主路径,不退化为仅靠 OpenAPI 暴露
阶段 3:统一 request-scoped negotiation 与 contract 一致性
需要落地:
- 审查
A2A-Extensions / request-scoped activation 的运行时行为
- 对齐 Agent Card、OpenAPI、运行时响应头、错误处理与文档描述
- 清理旧有兼容思维下残留的 envelope / family / taxonomy 假设
建议拆分子任务
验收标准
- 新版本不再依赖 GitHub
blob/main 文档地址作为 extension identity。
- extension URI、spec、Agent Card、OpenAPI、运行时协商行为在 A2A 1.0 语义下自洽。
- public Agent Card 的披露面收缩到最小必要 discoverability。
- 更详细或更敏感的 provider-private contract 通过 authenticated extended card 暴露。
- 仓库对 0.3 不再保留额外兼容设计负担。
背景
当前仓库已经明确从 A2A 0.3 升级到 1.0,且该升级视为 breaking change。
本仓库后续不再为 0.3 保留兼容胶水、过渡包装或双轨 contract。旧版本可通过 release/tag 继续服务既有使用者;
main上的新版本应直接按照 A2A 1.0 的最佳实践收敛 extensions 设计、声明、发现、协商与披露模型。当前仓库在 extensions 方向的一个关键问题是:虽然已经建立了较完整的 extension contract 体系,但 extension identity 仍然强绑定到 GitHub
blob/main文档地址,且 public Agent Card 对 provider-private/operator-sensitive capability 的公开面仍然偏大。这些做法可以工作,但不适合作为 A2A 1.0 长期稳定形态。参考伞 issue:
官方参考:
总体原则
blob/main。本仓库需要解决的核心问题
1. extension identity 不应绑定 GitHub 文档页面
当前 extension URI 直接使用 GitHub
blob/main文档地址。该方案存在以下问题:目标方向:
w3id风格)2. public Agent Card 与 authenticated extended card 的披露边界需要重新收敛
当前 public Agent Card 虽然已经做了参数瘦身,但仍然直接公开了较多 provider-private/operator-sensitive extension capability。
目标方向:
3. extension 规范页面与标准协商路径需要对齐
目标方向:
建议拆分阶段
阶段 0:定 A2A 1.0 extension 最佳实践基线
需要产出:
阶段 1:重做 extension identity 与文档托管边界
需要落地:
blob/mainURI 迁移到稳定 extension URI阶段 2:重构 card 披露面与标准声明路径
需要落地:
阶段 3:统一 request-scoped negotiation 与 contract 一致性
需要落地:
A2A-Extensions/ request-scoped activation 的运行时行为建议拆分子任务
blob/mainidentity 迁移到稳定 URI验收标准
blob/main文档地址作为 extension identity。