A2UI与AG-UI协议对比：从渲染权归属到安全落地的实践指南

一、教程目标

本教程旨在帮助开发者、技术负责人以及企业架构师理解两类AI界面协议——A2UI与AG-UI——在设计理念、渲染权归属、安全边界和工程落地上的关键差异。完成阅读后，你将能够：

1. 准确区分“Agent生成完整界面代码”与“Agent描述界面意图、客户端负责渲染”两种模式；
2. 理解动态界面生成中XSS、任意代码执行和品牌一致性问题的根源；
3. 掌握在不同业务场景下选择哪种协议更合适的判断方法；
4. 建立一套从安全评估、架构设计到验证排查的落地流程。

本教程不依赖任何特定云厂商或商业产品，所有概念均基于业界通用协议设计思路和前端安全实践展开。

二、适用场景

在进入具体对比之前，先明确这两类协议通常被用在什么场景。如果你的业务符合以下任意一条，本文内容将对你直接有用：

• 你正在构建一个由大模型驱动的对话式应用，Agent需要根据用户意图动态生成表单、选择器、按钮等交互组件；
• 你的前端团队担心AI生成的界面代码可能引入安全漏洞或破坏视觉规范；
• 你需要在“快速交付动态界面”和“保持客户端可控、安全、品牌统一”之间做出架构权衡；
• 你正在评估是否应该让Agent输出完整的界面描述代码，还是只输出结构化的组件意图描述。

简单来说，凡是涉及“AI生成界面”与“客户端渲染执行”之间的信任边界问题，都属于本教程的讨论范围。

三、前置准备

理解本文需要具备以下基础：

• 对前端渲染的基本流程有概念，比如什么是DOM、事件绑定、客户端渲染与服务器端渲染的区别；
• 了解大模型输出不可信这一基本前提——模型生成的内容可能包含恶意脚本、异常结构或不符合预期的数据；
• 对“协议”一词有通用理解：协议约定了Agent与客户端之间交换信息的格式、字段含义和渲染责任划分。

你不需要熟悉任何特定框架或云平台。文中涉及的代码示例均为通用伪代码或结构示意，不依赖具体产品。

四、核心概念：渲染权归属决定协议性质

在对比A2UI与AG-UI之前，必须先理解一个根本问题：谁拥有最终渲染权。

这个问题的本质是：当Agent需要向用户展示一个交互界面时，它输出的内容是“完整的、可执行的界面代码”，还是“对界面意图的结构化描述”。

agent-">4.1 模式一：Agent输出完整界面代码

在这种模式下，Agent直接生成一段包含布局、样式、事件处理逻辑的代码片段。客户端拿到后，通过动态渲染引擎执行，生成可见界面。

这种方式的优势是灵活度极高。Agent可以自由组合任意组件，甚至在协议允许范围内创建全新的交互模式。但代价同样明显：

• 安全风险：Agent生成的内容可能夹带脚本逻辑，例如内联事件处理器onclick="..."或<script>标签。由于大模型输出本质上是不可信的，客户端执行这段代码等同于把任意代码执行能力暴露给了不可信输入源。
• 品牌一致性风险：Agent拼凑出来的视觉风格往往与产品既有的设计系统不一致。用户能直接感知到“崩坏感”，信任度下降。
• 维护成本：客户端需要处理各种异常结构、未预期的样式组合和事件绑定冲突。

4.2 模式二：Agent描述界面意图，客户端负责渲染

在这种模式下，Agent不生成可直接执行的界面代码，而是输出结构化的意图描述。例如，用户说“我要订下周三去上海的机票”，Agent判断需要日期选择器和提交按钮，于是输出：

{
  "components": [
    {"type": "date-picker", "id": "departure_date", "label": "出发日期"},
    {"type": "submit-button", "id": "submit_order", "label": "提交订单"}
  ]
}

客户端拿到这个描述后，从本地既有的组件库中查找对应的date-picker和submit-button，以受控方式渲染。Agent只描述需要什么类型的组件，不控制组件内部实现、样式细节或事件逻辑。

这是A2UI与AG-UI最核心的分野所在。

五、A2UI与AG-UI的定位差异

在去除具体品牌后，我们可以用以下通用方式理解两者：

5.1 A2UI倾向：结构化意图描述，客户端保有最终渲染权

A2UI类协议的核心思想是限制Agent的表达能力，将渲染权牢牢握在客户端手中。Agent只能从预定义的组件类型集合中选择，输出的JSON或类似结构必须通过客户端的校验层，非法组件类型、未预期的字段、越权的属性都会被拒绝。

这种设计直接回应了安全与品牌一致性问题：

• 因为客户端只接受白名单组件，Agent无法注入任意脚本或内联事件；
• 因为客户端负责从设计系统中取用组件，渲染结果天然符合品牌规范；
• 因为渲染器是客户端自有的，事件绑定、数据流、无障碍支持都在可控范围内。

5.2 AG-UI倾向：追求动态生成能力，引入代码执行风险

AG-UI类协议则更强调动态性和自由度。它允许Agent生成更接近完整UI逻辑的内容，包括布局结构、样式定义以及一定程度的交互行为。客户端需要将这段内容当作可执行主体来处理。

这种设计的初衷是让Agent能够应对协议未预定义的场景。比如，某天用户的需求无法用既有组件库完全表达，AG-UI类协议允许Agent拼装出新的界面形态。

但正如本教程开头所述，这等于把XSS和任意代码执行的攻击面主动引入到客户端的信任边界内。你无法在不执行的情况下预先判断这段内容是否安全，因为大模型的输出本质上是不可信的。

六、实施步骤：如何选择并落地合适的协议

下面给出一套可操作的决策与落地流程。

步骤1：评估你的信任边界

问自己一个问题：你愿意让客户端在多高的权限级别下执行Agent的输出？

如果客户端是浏览器页面，执行任意脚本意味着攻击者可能窃取用户会话、操作用户数据。如果客户端是企业内部管理后台，风险可能相对可控，但依然存在。

操作建议：在文档中明确列出客户端当前的权限能力（如可访问的Cookie、本地存储、API Token等），并假设Agent输出内容可能含有恶意代码。评估如果这段代码被执行，最坏情况是什么。

步骤2：盘点你的组件库覆盖范围

列出你的前端设计系统中有哪些可复用组件。例如：

• 日期选择器
• 下拉选择器
• 输入框
• 提交按钮
• 表格
• 卡片
• 弹窗
• 文件上传

判断标准：如果你的业务场景90%以上都能由这些组件拼装完成，那么采用A2UI类协议（结构化意图描述）是更安全、更可维护的选择。如果你的业务频繁需要非常规界面形态，且你愿意为此承担代码执行风险并投入额外的安全审计资源，再考虑AG-UI类协议。

步骤3：设计协议字段与校验规则

无论选择哪种模式，都需要明确Agent输出格式和客户端校验逻辑。

A2UI类协议示例设计：

字段名        类型      必填   说明
type         string   是     组件类型，必须在客户端白名单内
id           string   是     组件唯一标识，用于事件回传
label        string   否     组件显示文案
props        object   否     组件属性，必须符合该组件的属性schema
children     array    否     子组件列表，仅容器类组件允许包含

校验规则：

• 客户端解析JSON后，逐字段校验；
• type不在白名单内，直接丢弃整个响应并返回错误提示；
• props中包含未在schema中声明的字段，拒绝渲染；
• 任何字段值包含<script、javascript:、onclick等危险模式，视为非法输入，记录告警日志。

AG-UI类协议示例设计：由于允许更高自由度，校验逻辑通常更复杂，往往需要引入沙箱机制。一般会采用以下通用做法：

• 在独立沙箱环境（如隔离的iframe或专用执行容器）中运行时生成的代码；
• 限制沙箱的网络访问、存储访问和DOM访问范围；
• 对所有输出内容做静态扫描，检测常见攻击模式；
• 设置最大渲染节点数量，防止资源耗尽。

步骤4：建立事件回传机制

动态生成的界面需要与后端Agent进行交互。无论是表单提交还是选择变更，事件都应以结构化形式回传给Agent，而不是执行客户端本地代码。

通用流程示意：

1. 客户端检测到组件事件（如用户点击提交按钮）；
2. 客户端构造一个事件对象，包含组件id、事件类型和组件当前值；
3. 客户端将该事件对象发送给Agent服务；
4. Agent根据事件对象中的意图信息，决定下一步动作（如调用订票接口、继续追问用户等）。

这种方式确保了客户端只负责捕获和传递用户输入，业务逻辑和后续决策仍在Agent侧完成，进一步减少了界面层的执行权限。

步骤5：结果验证

完成协议对接后，需要验证以下三件事。

验证一：安全边界测试

构造包含恶意负载的Agent输出，例如：

{
  "type": "date-picker",
  "props": {"onClick": "alert(document.cookie)"}
}

在A2UI类协议下，这段输出应被校验层拒绝，客户端不渲染该组件，并产生一条安全告警日志。

在AG-UI类协议下，如果采用沙箱执行，alert(document.cookie)不应获取到真实的Cookie值，或者沙箱直接阻断脚本执行。如果以上目标未达成，说明你的安全边界存在问题。

验证二：品牌一致性测试

让Agent针对同一个需求生成多个不同版本，观察渲染结果是否始终符合设计规范。在A2UI类协议下，由于渲染由客户端从本地组件库完成，视觉风格应与设计系统完全一致。如果发现偏差，需要检查客户端渲染器是否正确引用了组件库。

验证三：动态意图覆盖度

构造真实业务需求，统计Agent通过协议成功表达意图的比例。如果大量需求无法通过白名单组件表达，且你无法扩展组件库，则需要重新评估是否需要在局部场景引入更灵活的协议变体。

七、常见问题与排查

问题1：Agent输出的JSON格式正确，但组件渲染不出来

原因分析：可能是客户端组件白名单中没有对应的type实现，或者组件props中存在未预处理的字段类型。

排查思路：

1. 查看客户端日志中是否有校验失败记录；
2. 确认组件注册表中是否存在该type对应的实现；
3. 检查props中的数值类型、嵌套结构是否符合schema定义。

问题2：安全测试中恶意脚本被成功执行

原因分析：常见原因包括：客户端在渲染前未做完整校验；动态渲染引擎自身存在漏洞；或者信任边界配置过宽，沙箱未限制全局对象访问。

解决思路：

1. 在渲染入口前强制增加一道白名单校验，确保任何Agent输出都必须通过；
2. 升级或更换动态渲染引擎，或为渲染器添加额外的输入净化层；
3. 检查沙箱配置，限制对window、document、localStorage等全局对象的访问。

问题3：界面能正常显示，但事件回传后Agent没有响应

原因分析：事件对象中缺少必要字段，或Agent侧没有正确解析事件意图。

排查思路：

1. 在客户端侧确认事件对象是否包含组件id、事件类型和当前值；
2. 在Agent服务侧添加日志，确认是否收到事件请求；
3. 检查Agent与客户端之间的事件协议版本是否一致。

八、优化建议

8.1 安全层面

• 即使选择了A2UI类协议，也不要完全信任Agent输出，至少在传输层增加消息完整性校验；
• 记录所有被拒绝的Agent输出，作为安全审计的依据；
• 定期更新组件白名单和schema，封堵可能被利用的危险属性字段。

8.2 性能层面

• 对Agent输出的结构做大小限制，避免过大的组件树导致客户端渲染卡顿；
• 对高频出现的组件类型做客户端缓存，减少重复解析开销；
• 如果使用沙箱执行，限制沙箱内代码的运行时长和内存配额。

8.3 可维护性层面

• 将Agent可用的组件类型、字段schema和校验规则维护在统一配置中，保证客户端与服务端一致性；
• 协议版本要显式声明，便于后续升级时平滑过渡；
• 为组件定义提供清晰的文档说明，方便Agent侧理解可用的组件能力边界。

8.4 稳定性层面

• 对Agent输出解析失败、校验失败、沙箱执行异常等场景设计降级策略，例如回退到一个简单的文本确认界面；
• 设置超时机制，防止Agent长时间无响应导致界面卡死；
• 建立监控指标，统计协议解析成功率、拒绝率和平均渲染耗时。

九、总结

A2UI与AG-UI的本质区别不在于它们叫什么名字，而在于渲染权归属和信任边界的位置。A2UI类协议通过限制Agent只能输出组件意图描述，将渲染权保留在客户端，从根本上规避了不可信大模型输出带来的代码执行风险，并保证了品牌一致性。AG-UI类协议则追求更高的界面自由度，但代价是需要承担沙箱执行、安全扫描和维护成本。

选择哪条路线，取决于你的业务对动态性的需求程度，以及你愿意为安全边界投入多少工程资源。无论选择哪种，都应当建立完善的校验机制、事件回传机制和测试验证流程，将“不可信输入”与“可信客户端执行环境”之间的边界管理作为系统工程来对待。

后续可以继续关注的方向包括：组件schema设计规范、沙箱最小权限配置实践、AI界面生成的审计与可追溯机制，以及动态界面与权限控制体系的集成方法。