A2UI 渲染器路线图：React 与 v1.0 当前状态

[!IMPORTANT] **2026 年 8 月 24 日更新：**官方仓库将 v0.9.1 标记为当前生产版本线，v1.0 仍是候选规范。本文已删除早期没有兑现的预测日期，改为可核验的当前状态。

现在真正需要回答的问题已经不是“React 什么时候发布”，而是团队应选择哪个协议版本、哪条渲染器路径，以及如何管理升级。A2UI 已有活跃的 v0.9 规范、v1.0 候选规范、官方渲染器开发指南，以及展示多种 Web 实现的 Composer 工具。

当前协议状态

官方仓库明确区分三个版本线：

• v0.9.1 是当前生产版本。
• v1.0 是候选规范，正式采用前仍可能变化。
• v0.8 作为旧版保留，供已有集成维护。

这一差异比发布日期预测更重要。不同版本之间的消息名和组件结构已经变化，因此 Agent 不能向另一个版本的渲染器发送载荷。提示词、Schema、Fixture、传输层、Catalog 与客户端必须固定同一版本。协议升级应作为兼容性项目处理，并配套明确测试。

当前渲染器选择

官方项目记录了现有渲染器实现，并提供自定义渲染器指南。对于 Web 应用，官方指南建议在适用时使用项目的 Web Core，避免从头实现消息处理。宿主应用仍负责组件目录、设计系统、Action 处理、校验策略与安全边界。

A2UI Composer 及其 Theater 可以检查生成界面，并比较受支持渲染器的输出。当前 Composer 提供 Angular、Lit 和 React 相关体验。这能反映现有生态，但生成结果仍需按应用实际使用的协议和 Catalog 校验。

Flutter 仍适合跨平台应用；Web 团队可以使用已有渲染器，也可以把协议接入自己的组件系统。选择依据应包括 Catalog 覆盖、无障碍、框架约束、维护责任与宿主需要的控制程度。

React 团队现在应做什么

React 团队应直接评估当前实现，不应继续围绕已经过期的预测日期设计。建议从小范围验证开始：

1. 默认固定 A2UI v0.9.1；只有明确评估时才使用 v1.0 候选版。
2. 使用现有无障碍组件定义小型、宿主自有的 Catalog。
3. 每条 Agent 消息改变应用状态前都完成校验。
4. 将声明式 Action 映射到经过审查的应用函数，禁止执行 Agent 提供的代码。
5. 测试流式传输、重复更新、删除、重连、不支持组件和失败降级。
6. 保存代表性消息流 Fixture，用于后续升级对比。

A2UI 的价值在于把声明式界面数据与宿主原生组件分离。React 渲染器应保持这一边界，不能把载荷直接变成原始 HTML，也不能让模型任意导入组件。

如何评估 v1.0

v1.0 候选版适合设计验证，但“候选”不等于生产兼容保证。应对比它与 v0.9.1 的 Schema 和生命周期，列出影响 Catalog 或传输层的全部破坏性变化，并将候选版实验与生产消息流隔离。

采用 v1.0 前，至少需要分版本 Schema、通过的契约 Fixture、渲染器兼容性、迁移文档和可执行回滚路径。不要把发布季度写进永久 URL 或长期文档 slug；状态比主题本身变化得更快。

更可靠的路线图策略

路线图把预测写成承诺时会迅速过期。更稳定的策略是：

• 以官方仓库和分版本规范为准；
• 生产环境只使用一个固定且经过测试的版本线；
• 候选版本独立评估；
• 从当前文档和代码核验渲染器能力；
• 过期日期明确标记为历史信息；
• 保留常青 URL，通过页面元数据记录更新。

本文保留原路由，以维持已有链接和搜索信号，但标题与正文已改为当前主题，不再延续失效季度预测。实现细节参见什么是 A2UI、消息参考和生产就绪指南。