前阵子我在给自己的 Agent 加一块"结果展示"界面，遇到了一个绕不开的尴尬。
让模型直接生成一段 HTML 塞进页面？不安全。大模型的输出可能是任意代码，跨过信任边界就是注入攻击；让模型只回一段文字？又太简陋，浪费了它的能力。界面到底该以什么形态，从 AI 安全地交到用户手里——这件事当时没有标准答案。
我顺手把这几天研究的一个开源方案拆了一遍源码，得到一个挺清醒的观察——真正该跟 AI 讲的，不是"画什么"，而是"你能用什么"。
把界面降级成数据
与其让模型生成代码，不如让它发一段声明式的 JSON——描述界面的结构加数据，但不含任何可执行逻辑。真正把它画出来的，是你自己的客户端，用的是你自己的原生组件。
这套思路有个名字叫 A2UI（Agent-to-User Interface，智能体到用户的界面），来自 Google 联合开源社区推动的一个开放协议。它的核心主张很朴素——让 AI 说界面，而不是写界面。
关键词是"数据"。AI 说的是一段能被校验、能被解析的数据，而不是一段要被执行的东西。信任边界一下子变窄了，模型顶多让你画出一个不那么好看的面，却没法让你跑起一段不该跑的代码。
它靠两件事锁死风险
我读源码时，发现它把安全落在两个机制上。
第一是组件白名单。每个界面都绑定一份"组件目录"（Catalog），本质上是一张 JSON Schema，规定了模型这次能用哪些组件、哪些函数。生产项目几乎都会换成自己的——把你家的设计系统放进去，模型就只能在这些组件里挑，越界命令根本没得执行。这是它把"执行权"收走的关键。
第二是界面与数据分离。组件不写死内容，而是引用数据模型里的路径：
{ "id": "user_name", "component": "Text", "text": { "path": "/name" } }
数据模型里一改 name，所有绑定了它的组件自动刷新。界面是一层壳，数据是活的——改数据即改界面，模型只需要维护一份数据，不用一遍遍重画。
它怎么说界面：四种消息
模型到渲染器之间，是一条单向的 JSON 流，总共就四种消息——新建一块界面、往界面里加组件、往数据里写值、删掉一块界面。
妙处在于模型的输出被设计成扁平列表 + 编号引用，每一段都很小、很平。深层嵌套的 JSON 让模型一次生成对很难，但扁平列表方便它增量地往外吐——于是界面可以边生成边显示，用户不用干等。它不让模型一次想清楚一棵完整的树，而是让它一小块一小块地拼。
读这套东西，要连着实现一起读
如果你在考虑给 Agent 加界面，或者评估某个"AI 生成界面"的方案，可以先问四个问题：
- 它说的是数据还是代码？
- 它允许模型用的组件，是不是被白名单锁死？
- 界面和数据是不是分离的，改数据就能改界面？
- 协议的规范和实现，是不是在同一个版本？
我 clone 下来对着一份规范和一个 SDK 对照读，发现一个早期开源协议很常见的真相——规范往往跑在实现前面。 这套协议的 v1.0 已经是候选版，加了双向函数调用、单消息实例化界面这些能力，但核心 SDK 还走在旧版的主题和 capabilities 上。文档和代码说的不是一回事。
这算好事——规范负责探路，实现负责追赶，是大多数年轻协议的常态。但如果你拿文档去评估成熟度，会被误导。判断一个"让 AI 描述界面"的方案是否可信，不能只看它声称支持什么，要去看它今天实际能跑什么，最好的办法是打开源码，数一遍它实现了哪些消息、接了几种传输层。
无论协议怎么变，有一条线大概率不会变：信任边界和组件白名单，始终是把执行权留在客户端的关键。下一波 AI 应用里，能给你现场画出一个可用界面的 Agent 会越来越多，但界面的呈现权，终究要握在自己手里——让 AI 说数据，把画界面的权力，留给你自己的客户端。
作者｜随机比特
