A2UI 是什么？Agent 生成的界面为什么不直接使用 HTML？

知识点详解：让模型描述界面，为什么更容易管住？

先把三个参与者分开

假设咱们的资料助手需要用户挑选一份报告。

Agent 可以描述“显示三项，每项有标题和选择动作”。客户端收到以后，检查组件与数据，再让渲染器生成真正的界面。

这里分别有三个角色：Agent 提供描述，宿主检查能力边界，渲染器把描述变成平台上的控件。

模型没有必要自己决定每个 DOM 节点、CSS 规则和事件监听器。宿主也不需要把一段陌生脚本直接放进页面执行。

A2UI 官方说明围绕组件、数据和宿主渲染组织这套方式。具体报文在不同版本之间有变化，理解机制时应把版本和运行器区分清楚。

组件目录为什么重要？

应用支持什么控件，不能完全由模型临时决定。

假设当前客户端只支持文本、列表和按钮。模型提出一个未支持的“任意脚本执行组件”，宿主应该拒绝、降级或报告不支持，不能因为描述格式正确就执行它。

组件目录还可以规定参数。例如按钮需要一个合法动作名称，图片需要允许的来源。应用实际注册的组件代码由开发者维护，而不是每次由模型重新生成。

如果团队自己写的组件偷偷支持任意 HTML 或不受限链接，这套边界仍然会被打开。声明式协议减少了一部分执行面，组件实现的质量依旧重要。

结构和数据为什么值得分开？

资料选择界面的结构可能没有变化：列表里有三项，每项一个标题和一个选择按钮。

后来工具发现第二份资料的版本号变化，只更新对应数据即可。应用不必为了一个字段，重新接受一整段 HTML 和行为代码。

但这也带来了新的校验问题。结构引用的数据是否存在，字段类型是否正确，更新属于哪一个界面，都需要对应。

如果一个数据更新被应用到另一轮任务的界面，页面可能显示错报告。界面身份和数据绑定不是装饰字段，它们用来避免这种误配。

按钮描述和业务操作之间，还隔着后端检查

用户点击“选择报告”，应用可以把选中的对象 ID 交给 Agent 或服务端继续处理。

如果按钮表示“删除报告”，情况就不同了。需要重新检查对象归属、当前权限、操作范围以及是否要求确认。

描述里写了“允许删除”，不能直接成为授权依据。模型负责提出界面，用户动作表达意图，后端负责判断这项操作能否执行。

在当前例子里，把稳定报告 ID 传回去比只传一个标题更可靠。两份同名报告可能不是同一个对象。

A2UI 与 AG-UI 怎样配合？

可以通过交互连接传递界面描述、数据更新和用户动作。但 A2UI 的重点是“界面描述里表达什么”，AG-UI 的重点是“交互事件怎样往来”。

采用 A2UI 也不要求你把现有页面全部改成模型生成。固定的导航、账号页面和危险操作入口，完全可以继续使用应用自己写的界面。

让模型参与哪一块，要看它确实需要动态组织什么，而不是为了增加一个协议，把稳定页面也变成临时输出。

面试官继续追问

JSON 一定比 HTML 安全吗？

不能这么说。安全取决于解析、允许的能力和执行方式。JSON 里也可以描述危险动作或恶意地址，宿主仍要检查。

可以加入自己的组件吗？

可以围绕实际规范和渲染器能力扩展。但自定义组件会扩大宿主提供的能力范围，需要定义参数、事件和版本兼容，并检查实现边界。

所有客户端都能显示同样效果吗？

不能保证完全一致。平台、渲染器和组件支持不同，需要协商或降级。可移植的界面意图，不等于像素和交互体验完全相同。

面试速记卡

• A2UI：传递声明式界面、数据与相关动作描述。
• 宿主：选择受控组件，校验并渲染。
• 数据绑定：更新要对应正确对象与界面。
• 动作边界：点击表达意图，后端仍负责授权执行。
• 版本处理：按实际规范和渲染器核对，不混用旧报文。