Google发布A2UI开放协议：以JSON描述UI，重塑AI代理交互生态
内容摘要
核心要点
Google Cloud发布了A2UI（Agent-driven User Interface）开放协议，旨在让AI代理动态生成丰富的交互式UI，而非仅返回文本或Markdown。A2UI的核心是声明式JSON payload，描述组件树（如Card、Button、ChoicePicker、Image）和独立的数据模型。关键特性：
- 声明式且不可执行：payload仅为数据，客户端仅渲染预批准目录中的组件，杜绝远程代理注入恶意代码或窃取凭证。
- 流式友好：格式为扁平JSON消息列表，LLM可增量输出，客户端逐步渲染，降低尾部延迟。
- 框架无关：同一响应可在Lit、Angular、Flutter或原生移动端渲染。
A2UI位于四层堆栈的“货运”层：应用体验（如CopilotKit、AG-UI）→像素绘制（Lit/Flutter）→对话管道（A2A协议）→货运（A2UI）。在Gemini Enterprise中，GE内置A2UI渲染器，开发者只需构建A2A端点并注册即可。运行时，GE将自身组件目录发送给代理，代理返回A2UI JSON，GE验证并原生渲染，用户交互后序列化回JSON发送给代理。参考实现使用ADK后端运行在Cloud Run，并通过Google Maps Embed iframe渲染地图组件，API密钥服务端注入。
重要性说明
Google推出A2UI，表面是提升代理交互体验，实则在防御Microsoft的Copilot和OpenAI的ChatGPT插件生态。通过将A2UI深度绑定Gemini Enterprise，Google试图锁定企业用户的agent部署到Google Cloud平台：代理必须遵循A2UI协议才能获得GE原生渲染，而GE是Google Cloud的SaaS产品，用户一旦采用，其agent工作流将依赖Google的渲染引擎和目录。
- 隐性锁定资产：开发者构建的A2UI agent中，UI组件目录由Google控制（如GE只支持特定组件），企业无法自由扩展或迁移到其他平台。虽然协议开放，但GE的渲染器是专有的，且组件目录更新节奏由Google决定，企业可能被迫跟随。
- 工程短板：A2UI的声明式JSON虽安全，但组件目录的预批准限制了UI复杂性。对于需要高度定制化UI（如实时仪表盘、复杂表单）的场景，开发者可能被迫回退到文本或Markdown，降低交互效率。此外，流式渲染虽降低尾部延迟，但JSON解析和渲染开销在大量组件时可能成为瓶颈，尤其在移动端。
- 防守合围：此协议直接对抗Microsoft的Adaptive Cards和OpenAI的function calling。Google通过开放协议吸引第三方，但实际生态控制权仍通过GE的渲染器掌握。
PRO 决策建议
【厂商】Microsoft/OpenAI/Anthropic应加速推广各自的agent UI标准（如Adaptive Cards、函数调用响应格式），并强调Google A2UI的生态锁定风险——GE渲染器是专有的，而A2UI组件目录由Google控制。同时，提供跨平台渲染器实现，让代理UI在非Google环境中同样原生。
【企业】CIO与架构师需进行零信任技术审计：评估A2UI agent是否深度绑定Gemini Enterprise。要求Google提供组件目录的开放扩展机制和第三方渲染器兼容性证明。避免将核心agent工作流完全依赖GE渲染器，应要求代理同时支持纯文本回退，确保跨平台可移植性。考虑使用AG-UI或CopilotKit等框架作为独立前端，降低供应商锁定。
【投资者】看穿Google的开放协议公关辞令：A2UI的真正价值在于巩固Gemini Enterprise的企业市场份额，而非推动行业标准化。长期关注Google Cloud的agent平台收入增速，若A2UI成为主流，将强化Google在AI Infra的供应商集中度风险。警惕竞争对手（如Microsoft）推出类似但更开放的标准。
觉得这篇分析有用？
每周收到3-5条AI基础设施关键信号 →
💬 评论 (0)