最近一个Agent项目，整个页面只有一个输入框作为交互入口，但是需要在页面上有丰富的动态展示。这个从原理上来说不难，就是通过自然语言理解，将用户的意图转化为固定格式的结构，前端拿到这个结构去渲染对应的界面动态即可。
自己写固然可以，但是界面千变万化，不能把1000种可能都定义好结构来处理吧。于是便去搜索有没有相应的方案，果然Google早就制定了相关的协议规范-A2UI。
你让 AI「帮我订一家明天晚上 7 点的餐厅」，它回你一段文字；但如果它能直接生成一个预订表单，你改人数、点确认，界面就把订单发回给 AI------这种交互正在成为现实。背后的关键，是一个叫 A2UI 的新协议。这篇文章基于 A2UI 官方资料，聊聊它解决了什么问题、怎么运作、以及为什么值得关注。
01-一个绕不开的问题：AI 只能「说」，不能「画」
现在的 AI 应用，绝大多数交互都发生在聊天框里：AI 输出文字，你复制、粘贴、再手动去别的页面操作。原因很简单------AI 生成的界面很难安全地送到用户面前。
让 AI 生成界面的两条老路都有硬伤。一是让 AI 直接写代码、由客户端执行，灵活但极其危险：任意代码执行意味着注入攻击、数据泄露都防不住，信任边界直接被击穿。二是让开发者针对每个场景手写界面，安全但毫无弹性：AI 每次输出的内容不同，静态页面根本跟不上。
A2UI 官网把这个矛盾总结成一个问题：AI 如何跨信任边界安全地传递富界面？答案不是执行代码，也不是放弃界面，而是让 AI 说一门「通用界面语言」。
02-A2UI 是什么：界面世界的 HTML
A2UI 的全称是 A Protocol for Agent-Driven Interfaces，直译就是「Agent 驱动界面的协议」。它让 AI 以声明式组件描述的方式输出界面，客户端再用自己的原生组件把它们渲染出来。AI 不写代码，只发数据。
理解 A2UI 最直观的方式是类比：A2UI 之于 Agent 界面，就像 HTML 之于网页。网页时代，服务器发 HTML，浏览器负责渲染；Agent 时代，AI 发 A2UI 消息，渲染器负责把它变成真正的界面。协议是语言，Agent 是服务器，渲染器是浏览器。
出身也值得一提：A2UI 由 Google 发起，CopilotKit 和开源社区共同贡献，采用 Apache 2.0 协议，代码在 GitHub 上活跃迭代。当前生产版本是 v0.9.1，v1.0 已经进入候选阶段------它不是概念 Demo，而是一套正在落地的标准。
03-四个关键词，看懂它的设计思路
安全优先。A2UI 是纯声明式数据，不是可执行代码。AI 只能使用组件目录里预先批准的组件，想注入一个恶意元素都没门。这是它与「让 AI 写代码」路线的根本区别。
对 LLM 友好。协议采用扁平、可流式输出的 JSON 结构，AI 可以分块生成界面，不必一次性输出完美 JSON。这对大模型来说是质变------生成一个嵌套十层的 JSON 树容易翻车，生成一组扁平的组件清单则轻松得多。
框架无关。同一份 A2UI 响应，可以在 React、Angular、Flutter 甚至原生移动端上渲染。AI 只负责描述界面长什么样，具体用什么框架的技术栈渲染，由客户端自己决定。
渐进式渲染。界面消息像聊天流一样边生成边推送，用户看到的是界面一点点搭建起来，而不是对着转圈等待完整响应。
04-它怎么工作：从一句话到一张可交互的表单
A2UI 的交互循环是闭环的。用户发消息给 AI；AI 生成描述界面的 A2UI 消息；消息流式传到客户端；客户端用原生组件渲染；用户操作界面、把动作发回给 AI；AI 再回传更新后的界面消息。
协议核心是三种消息：createSurface 创建一个界面区域并指定组件目录，updateComponents 增删改界面里的组件，updateDataModel 更新数据模型。界面结构用「邻接表模型」组织------所有组件放在一个扁平列表里，用 ID 互相引用，而不是嵌套的 JSON 树。
为什么不用嵌套树？因为嵌套结构要求 AI 一次生成完美层级，深层组件的更新也很麻烦。扁平的 ID 引用让 AI 可以逐条增量输出、按 ID 精准更新任意组件，还天然把「界面结构」和「应用数据」分开了。
官方文档用餐厅订座演示完整流程：用户说「订 2 人、明晚 7 点的桌」；AI 生成一个包含标题、人数输入框和确认按钮的预订界面；用户把人数改成 3；点确认后，动作连同表单数据一起发回给 AI；AI 完成预订，发消息关闭界面。整个过程中，AI 没有写一行代码，却交付了一个可交互的完整界面。
05-生态现状：谁能渲染、怎么传输
渲染端，Google 官方维护 React、Lit、Angular 和 Flutter（GenUI SDK）四套渲染器，覆盖 Web、移动和桌面；SwiftUI、Jetpack Compose 的官方支持在规划中。社区也在快速跟进：Vercel 的 json-render、字节跳动的 Lynx、以及覆盖鸿蒙的 AGenUI 都已加入。
传输端，A2UI 刻意保持传输无关------任何能承载 JSON 的通道都行。最受关注的是与 A2A 协议的配合：A2A 是 Agent 之间的标准化通信协议，如果系统已经在用 A2A，集成 A2UI 几乎是自动完成的。官方还维护了组件目录机制：先用基础目录起步，生产环境则定义自己应用的设计系统目录，把 AI 的创造力约束在自家组件库里。
版本的演进也透露了方向。v0.8 时代强调「结构化输出」，v0.9 转向「Prompt-First」（提示词优先），v1.0 候选版则加入了 actionResponse，让客户端可以同步调用 AI 的能力------双向交互能力正在补全。
06-这件事意味着什么
对普通用户来说，AI 应用正在从「聊天窗口 + 文字回复」走向真正的应用界面。以后问 AI 要一个数据分析，它可能直接给你一张可交互的图表；问地理位置，它直接嵌入地图组件------官方 Demo 里已经演示了这样的场景。
对开发者来说，交付界面这件事的形态在改变：从「写页面」变成「定义组件目录」，设计系统第一次成为约束 AI 的边界。你不再需要为每个场景手写 UI，但要花更多精力打磨那套 AI 只能使用的组件库。
对行业来说，MCP 解决了 AI「能做什么」，A2UI 解决的是 AI「怎么呈现」。当 AI 既能调用工具、又能生成界面，Agent 化应用才真正长成完整形态。聊天或许仍是入口，但答案会越来越多地以界面呈现。
总结
A2UI 想回答的，是 AI 时代一个朴素的问题：既然 AI 能思考、能行动，为什么不能直接把它思考的结果以界面呈现给你。用声明式数据替代代码执行，用组件目录守住信任边界，用扁平结构迁就大模型------这套设计谈不上炫技，却处处务实。
协议还很年轻，生态正在生长，但它指向的方向很明确：未来 AI 应用的交互，不会只停留在文字里。谁先学会让 AI「画」界面，谁就可能在下一轮 AI 应用竞争中拿到先手。