A2UI v1.0 已适合生产吗？

尚未。它仍是候选设计，在上游明确稳定前应放在显式版本路由之后。

新生产项目应该选择哪个版本？

默认选择 v0.9.1；若目标宿主强制要求 v0.8，则按产品边界兼容，并在部署前核验渲染器与宿主支持范围。

A2UI v0.9.1 生产版与 v1.0 候选版：迁移决策指南

2026 年 8 月的 A2UI 版本决策不是简单的“新旧选择”，而是 v0.8 旧版、v0.9.1 生产版和 v1.0 候选版之间的兼容决策。将三者混用会直接影响版本协商、消息解析、渲染状态和产品集成。

当前生产基线

v0.9.1 是当前面向生产的版本。它将媒体类型统一为 application/a2ui+json，并明确 surfaceId 只需在 Surface 活跃期间唯一；Surface 删除后可以复用。v0.9 与 v0.9.1 处于同一稳定兼容线。

生命周期消息与 v0.8 不同。v0.9.1 使用 createSurface、updateComponents、updateDataModel 和 deleteSurface；v0.8 使用 surfaceUpdate、dataModelUpdate、beginRendering 和 deleteSurface。应通过版本协商选择信封结构，不能只看组件负载猜测版本。

v1.0 候选设计改变了什么

候选版不仅是重命名。它探索通过 actionId 关联同步 actionResponse，通过 callFunction 与 functionResponse 调用渲染器函数，并允许一个 Surface 混合兼容 Catalog。createSurface 还可以同包携带初始组件与数据，减少生命周期往返。

Catalog 通过父子组合约束获得更明确的安全边界；术语也转向 Agent 与 Renderer，更符合双方不一定对应传统服务端和客户端的部署现实。

这些能力有价值，但候选状态意味着 Schema 和迁移细节仍可能变化。v1.0 试验应放在转换器或隔离传输路由之后。

可审计的迁移顺序

按协议版本盘点宿主、Agent、渲染器、Catalog、历史记录与测试样例。
固定渲染器和 Schema 版本，避免协议边界使用浮动依赖。
增加显式版本协商与文本降级。
在单一边界转换信封，不把版本判断散落到业务组件。
测试半包、重复投递、非法路径、过期 Action、Surface 删除和 ID 复用。
按宿主能力逐步发布，并记录校验失败与不支持 Catalog 的遥测。

Gemini Enterprise 当前仍为注册的 A2A Agent 记录 v0.8 边界。这是产品约束，不代表整个协议仍停留在 v0.8。参见Google 产品兼容指南和版本参考。

生产结论

宿主和渲染器支持时，新项目使用 v0.9.1；只有明确产品边界要求时才维护 v0.8；v1.0 用于评估和迁移准备，不应成为未声明的生产依赖。

版本选择不能替代安全工程。仍需校验准确 Schema、限制 Catalog 与资源、净化 URL、在服务端授权 Action，并保留可访问的降级路径。完整要求见生产安全清单。