大模型 Agent 的输出长期被困在”返回文字”的牢笼里：订餐场景要反复多轮问答而不是一个日期选择器，餐厅列表只能返回地址而不是地图，选项只能罗列文字而不能交互。这种体验瓶颈的根源在于：旧方案让 Agent 返回 HTML/JS 片段会引入 XSS 风险，且无法保证 UI 与宿主应用的设计语言一致。

**A2UI 是一个开放协议**，由 Google 联合 Flutter 团队共同开发。它让 Agent 返回的不再是文本或代码，而是一棵描述性 JSON 组件树（Card、ChoicePicker、Image 等），以及承载数据的独立 data model。三大特性让它真正可落地：声明式而非可执行式——客户端只渲染预批准目录中的组件，杜绝了远程代码注入；流式友好——扁平化小消息格式，LLM 可以边推理边吐组件，客户端即时渲染；框架无关——同一套 A2UI payload 可以在 Lit、Angular、Flutter 或原生移动端渲染，Agent 端完全无感知。协议栈中，A2UI 作为 Cargo 层，承载于 A2A 协议之上。接入 Gemini Enterprise 时，GE 自带 A2UI 渲染器，你只需提供 A2A 端点和 A2UI payload，其余两层（App Experience 和 Pixel Drawing）全部由 GE 托管。

对在 Google Cloud 上构建 Agent 的开发者来说，这篇文章的核心价值不在于”Agent 需要 UI”这个共识，而在于它提供了一条**零前端框架门槛**的落地路径：用 ADK 开发 A2A Agent，部署在 Cloud Run 上，通过 `make register-gemini-enterprise` 直接注册进 GE。这意味着团队不需要绑定任何前端技术栈，GE 的设计系统自动接管渲染。参考仓库里的餐厅查找 Agent 用 Google Maps Embed iframe 做了实时地图演示——API key 在服务端注入，LLM 永远不接触敏感凭证。这种架构把”让 Agent 有 UI”这件事从全栈工程问题简化成了纯后端配置问题。