Google推出A2UI Express推理格式，并演示受限布局决策路径

谷歌十月二十七日公布的 A2UI 更新，改变的是智能体在生成界面时首先输出的格式。原先模型要直接写嵌套的 JSON 传输消息；现在可先输出更紧凑的 A2UI Express，再由 SDK 的确定性代码编译成标准 A2UI 消息。客户端仍先公布受信任组件目录，渲染端仍接收原有协议。格式说明和编译器依据同一目录结构生成，因此模型不能通过 Express 指向目录外的组件或属性。这是推理输出格式的调整，不是让智能体任意创造没有获批的界面控件。

谷歌称，在其测试中，Express 为同类界面生成的文本单位最多比直接 JSON 少三倍，延迟最多缩短三倍。原文提到用 Gemini 3.5 Flash 在五十一项任务上比较直接 JSON、Express 与另外两种候选语法，也比较是否启用思考模式。“最多”是厂商观测中的有利情形，不代表任何模型、目录、屏幕或网络条件都能重复。Express 使用接近程序语句的紧凑写法，SDK 再把它转成经过结构验证的消息。结构能解析也不代表界面内容和业务动作一定正确；数据绑定、组件目录设计与模型选取布局仍需检查。

原文列出 Python、TypeScript 与 Dart 的 A2UI 智能体 SDK 支持 Express。Python 与 TypeScript 可逐块流式处理直接 JSON；Express 则在模型完整回复后编译。Python SDK 的宏还允许模型只给已有订单等资料的标识，由应用代码取出权威数据并填入界面，而非要求模型凭记忆编造金额或状态。比较两种模式时，应区分首个可见元素出现时间、完整回复时间和可交互的有效界面完成时间。只测模型吐出首个字符的速度，不足以说明用户最终得到的界面更快或更准确。

文章另介绍结构预先确定的界面。开源示例 Apparite 让 Jev 决策模型回答一组有类型的布局问题，再由代码组装组件树，较小的 Gemini 模型只写文字。在十一条提示的一次运行中，组件树于九十二到二百九十八毫秒显示，完整屏幕耗时零点八到一点七秒。谷歌说这种决策路径最快可达八十倍，但它依赖提前写好的语法与有限布局；示例仅有九种屏幕原型和十二种组件块，样本也小。A2UI 智能体 SDK 目前没有内置决策模型推理格式，因此不能把该示例的速度直接算到 Express 身上。

如何选用取决于产品任务。如果设置页或结算页的结构已知，约束式决策路径可能更合适；若要在获批组件目录内灵活组合界面，Express 保留更多表达能力。开发者也可自定义推理语法和转换器，沿用相同的传输协议与渲染器。不过，“可交换”要求同时维护格式提示、编译器及验证，否则模型输出可能与组件契约偏离。真正的工程评估应在自家任务上同时记录有效率、数据正确性、交互完成时间及错误恢复。谷歌的数字是产品方测试与演示，不构成独立跨产品排名。

这篇公告与过去介绍 A2UI 协议本身的报道主题不同：新信息是模型输出层可以替换，以及 Express 与预先定义布局的性能取舍。语言上也必须区分文本单位与加密代币，文中所谓 token 是模型生成的文本计量单位；八十倍数字属于另一种受约束的决策模式，不属于所有使用 A2UI 的应用。这些边界若在摘要中丢失，会使开发者误判接入成本和实际可用范围。

原文的示例还说明，界面数据并非只能由模型直接写入。宏可以从应用已有的订单资料填充值，决策模型负责在已批准的布局中选项，文本模型再补上说明文字。若把三个角色混成一个“模型自动生成完整业务界面”的说法，就会遮住数据权威性和可审计性。上线前应对无权限数据、缺失字段与格式错误分别做失败测试，并记录编译器是否拒绝目录外属性。以上是根据公告机制提出的评估方法，不是声称谷歌已经替每个使用方完成了这些测试。

因此，性能结论始终须连同具体任务和限定条件阅读。