AI Native 应用的 UI 层该怎么设计？从 AG-UI 到 Agent 直出 HTML 的思考

qhvssonic

306人浏览 · 2026-05-14 07:52:17

qhvssonic · 2026-05-14 07:52:17 发布

引言

2025 年以来，围绕 AI Agent 的 UI 交互协议和框架密集涌现：CopilotKit 推出 AG-UI（Agent-Generated UI）协议，Google 开源 A2UI（Agent to UI）声明式协议，各大厂商也在探索自己的 Agent 前端方案。这些协议和框架的核心问题是：Agent 的输出如何以最优方式呈现给人类？

与此同时，Anthropic Claude Code 团队的实践揭示了另一条路径——让 Agent 直接输出完整的 HTML 页面，绕过中间协议层，由模型自身承担数据、展示和交互逻辑的全部职责。

这三种路线代表了 AI Native 应用 UI 层设计的不同哲学。本文将对比分析它们的设计思路、适用场景和技术权衡，探讨未来可能的演进方向。

一、当前主流方案：结构化协议路线

1.1 AG-UI 的设计哲学

AG-UI（CopilotKit 推出）协议的核心思想是关注点分离：

Agent（后端）→ 结构化数据/事件流 → 协议层 → 前端渲染引擎 → UI 组件

Agent 负责决策和数据生成，前端负责将结构化数据映射为具体的 UI 组件。协议层定义了两者之间的通信规范，包括：

事件类型：文本流、工具调用、状态更新等
UI 指令：Agent 可以"建议"使用某种 UI 组件（如表格、图表）
状态同步：前端操作结果如何回传给 Agent

1.2 A2UI 的设计哲学

A2UI（Google 开源）采用了一种不同但同属结构化路线的方案。它是一个声明式的 JSON 流协议，Agent 通过流式发送 JSON 消息来描述 UI 结构：

Agent → JSON 流（createSurface / updateComponents / updateDataModel）→ 客户端渲染引擎 → 原生组件

A2UI 的核心设计原则包括：

UI 结构与数据分离：通过 updateComponents 定义结构，updateDataModel 填充数据
流式渐进渲染：客户端逐条解析 JSON 消息，增量构建 UI
跨平台原生渲染：同一套 JSON 描述可在 Web、移动端、桌面端渲染为原生组件
安全性优先：不执行任意代码，仅通过声明式描述生成 UI

值得注意的是，A2UI v0.9 采用了"prompt-first"设计——协议 schema 直接嵌入模型的 prompt 中，模型按照示例和 schema 描述生成 JSON，而非依赖结构化输出约束。这使得协议的表达力更强，但也需要更复杂的后验证机制。

1.3 结构化路线的共同优势

可控性强：前端团队完全掌控最终渲染效果，可以确保一致的设计语言、可访问性标准和性能表现。

安全性高：Agent 输出的是结构化数据而非可执行代码，不存在 XSS 等代码注入风险。

跨平台能力：同一份结构化描述可以在不同平台渲染为原生组件（A2UI 的核心卖点）。

可维护性好：UI 组件独立于 Agent 逻辑，可以独立迭代和测试。

性能可优化：前端可以做增量更新、虚拟滚动等优化，不依赖 Agent 的输出效率。

1.4 结构化路线的共同局限

表达力受限于预定义组件：Agent 只能使用协议已定义的组件类型。如果 Agent 想表达一种全新的可视化形式，需要先扩展协议和组件目录。

创新瓶颈：每一种新的交互模式都需要协议层和渲染层同步更新，迭代速度受限于标准化进程。

Agent 能力浪费：现代大模型完全有能力生成高质量的 HTML/CSS/JS，但在结构化协议模式下，这一能力被人为限制了。

协议复杂度：A2UI 的 v0.9 已经需要多个 schema 文件（common_types、basic_catalog、server_to_client 等），协议本身的学习和维护成本不低。

二、新兴路线：Agent 直出 HTML

2.1 设计哲学

Agent 直出 HTML 的路线则完全不同：

Agent → 完整 HTML（含 CSS + JS）→ 沙箱渲染 → 用户交互 → 结果回传 Agent

Agent 同时承担了"后端逻辑 + 前端实现"的双重角色，输出的不是结构化数据，而是可直接渲染的完整页面。

2.2 这一路线的优势

表达力无上限：Agent 可以生成任何形式的可视化和交互，不受预定义组件的约束。

创新零成本：Agent 想到一种新的信息展示方式，可以立即实现，无需等待工程团队支持。

上下文利用充分：Agent 可以根据当前对话的完整上下文，定制最适合此刻需求的界面形态。

迭代速度极快：用户对界面不满意，一句 Prompt 即可调整，无需走开发流程。

2.3 这一路线的局限

安全风险：生成的 JavaScript 可能包含恶意或错误代码，需要严格的沙箱隔离。

一致性难保证：每次生成的 UI 风格可能不同，难以维持统一的产品体验。

性能不可控：Agent 生成的代码质量参差不齐，可能存在性能问题。

可访问性缺失：难以保证每次生成的 HTML 都符合 WCAG 标准。

不可审计：生成的代码难以进行安全审计和合规检查。

三、三种路线的本质差异

从更抽象的层面看，三种路线的分歧在于一个根本问题：谁来决定 UI 的形态？

维度	AG-UI	A2UI	Agent 直出 HTML
UI 决策者	前端工程师（预定义组件）	协议+组件目录（预定义）	Agent（实时生成）
输出格式	事件流 + 结构化数据	JSON 流（声明式）	完整 HTML/CSS/JS
灵活性	受限于组件库	受限于组件目录	理论上无限
跨平台	依赖前端实现	原生支持	仅 Web
安全性	高（数据隔离）	高（声明式，无代码执行）	需要沙箱保障
一致性	高（设计系统保证）	高（组件目录约束）	低（每次可能不同）
迭代速度	慢（需工程支持）	中（需扩展目录）	快（Prompt 即改）
适用场景	面向终端用户的产品	跨平台 Agent 应用	内部工具、探索性任务

四、融合方案：分层架构的可能性

在实际工程中，三种路线并非互斥。一种可能的融合架构是分层设计：

4.1 三层 UI 架构

┌─────────────────────────────────────────────┐
│  Layer 3: Agent 自由生成区（沙箱 HTML）        │
│  - 探索性可视化、一次性工具、原型              │
├─────────────────────────────────────────────┤
│  Layer 2: 结构化协议渲染（AG-UI / A2UI）       │
│  - 标准交互组件、数据展示、跨平台 UI          │
├─────────────────────────────────────────────┤
│  Layer 1: 固定 UI 框架（应用 Shell）           │
│  - 导航、布局、认证、全局状态                 │
└─────────────────────────────────────────────┘

Layer 1：应用的固定框架，由前端团队维护，提供稳定的导航、布局和全局功能。

Layer 2：Agent 通过结构化协议（AG-UI 或 A2UI）与前端通信，使用预定义组件展示标准化内容。适用于高频、标准化的交互场景。A2UI 在此层的优势在于其跨平台原生渲染能力——同一份 JSON 描述可以在 Web、iOS、Android 上渲染为各自的原生组件。

Layer 3：Agent 在隔离沙箱中自由生成 HTML，用于探索性、一次性的复杂可视化和交互。适用于低频、高定制化的场景。

4.2 协议层的演进方向

在这一融合架构下，AG-UI 和 A2UI 等协议可能需要扩展以支持"逃逸到自由 HTML"的能力：

1. 沙箱渲染指令

{
  "type": "render_html",
  "content": "<html>...</html>",
  "sandbox": {
    "permissions": ["scripts", "forms"],
    "deny": ["network", "storage", "top-navigation"]
  },
  "callback": {
    "type": "message",
    "format": "json"
  }
}

Agent 可以通过协议请求渲染一段 HTML，同时声明所需权限和回调方式。

2. UI 状态订阅

{
  "type": "subscribe_ui_state",
  "target": "sandbox_1",
  "events": ["slider_change", "drag_end", "form_submit"],
  "throttle_ms": 200
}

Agent 可以订阅沙箱内 UI 的状态变化，实现实时响应。

3. 渐进式增强

Agent 首先通过结构化协议输出基础内容，如果检测到客户端支持沙箱渲染，则追加增强的 HTML 版本。这确保了向后兼容性。

五、对现有框架和协议的影响

5.1 AG-UI 需要适配的方向

增加"自由渲染区"的协议支持
定义沙箱权限模型
标准化 UI 事件回传格式
支持 Agent 声明"我想用 HTML 表达这部分内容"

5.2 A2UI 面临的挑战与机遇

A2UI 的声明式设计天然具备安全性优势，但也面临表达力的天花板：

挑战：

组件目录的扩展速度能否跟上 Agent 能力的增长
当 Agent 需要表达目录中不存在的可视化形式时，如何优雅降级
v0.9 的"prompt-first"方案增加了后验证复杂度

机遇：

跨平台原生渲染是 HTML 直出方案无法提供的能力
在移动端和桌面端场景中，A2UI 的声明式方案比 HTML 沙箱更轻量
可以作为 Layer 2 的标准选择，与 Layer 3 的 HTML 自由区互补

可能的演进：

在组件目录中增加"自定义渲染"类型，允许 Agent 在特定区域内嵌入 HTML
定义从 A2UI 声明式组件到 HTML 自由渲染的"升级路径"
与 AG-UI 在事件回传层面实现互操作

5.3 A2A 协议的关联

当多个 Agent 协作时（A2A 场景），一个 Agent 生成的 UI 描述可能需要被另一个 Agent “理解”。这要求：

UI 描述中嵌入语义化的元数据
Agent 间传递 UI 状态时有标准化的序列化格式
A2UI 的 JSON 格式在 Agent 间传递时比 HTML 更易解析

5.4 前端框架的适配

React、Vue 等框架需要提供：

安全的 iframe/Shadow DOM 沙箱组件
Agent 生成 HTML 与宿主应用的通信桥接
沙箱内容的生命周期管理（创建、更新、销毁）

六、工程实践建议

对于正在构建 AI Native 应用的团队，以下是分阶段的实践建议：

短期（现在可以做）

在现有应用中增加"HTML 预览"能力，允许 Agent 输出的 HTML 在沙箱中渲染
为内部工具场景尝试 Agent 直出 HTML 模式
评估现有设计系统是否有机器可读的描述格式

中期（6-12 个月）

设计分层 UI 架构，明确哪些区域由 Agent 自由控制
建立 Agent 生成 UI 的安全审计机制
开发 UI 状态回传的标准化接口

长期（1-2 年）

参与或关注 AG-UI 等协议对 HTML 渲染的标准化进程
构建 Agent UI 质量评估的自动化工具链
探索"设计系统即 Agent 约束"的新范式

七、结语

AI Native 应用的 UI 层设计正处于一个关键的分叉点。AG-UI 和 A2UI 代表的结构化协议路线提供了安全性、一致性和跨平台能力，Agent 直出 HTML 路线提供了灵活性和无限表达力。三者并非对立，而是服务于不同场景的互补方案。

未来最可能的演进方向是分层融合：固定框架提供稳定性，结构化协议（AG-UI/A2UI）处理标准交互和跨平台需求，沙箱 HTML 释放 Agent 的全部表达力。这要求协议设计者、前端工程师和 AI 工程师共同协作，定义新的边界和接口。

对于 AG-UI 和 A2UI 而言，忽视 Agent 直出 HTML 的趋势将面临被绕过的风险；而对于 HTML 直出的实践者而言，缺乏协议层的规范将限制其在生产环境和跨平台场景中的应用。找到三者的平衡点，是 AI Native 应用 UI 层设计的核心挑战。

本文为"AI 输出范式转变"系列文章第三篇。
第一篇：《当大模型不再吐 Markdown：从 Claude 团队的 HTML 实践看 AI 输出范式转变》
第二篇：《一次性 UI 的时代：AI 生成的"用完即弃"界面会颠覆前端开发吗？》

AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

Flutter+开源鸿蒙实战｜企业级工具APP Day2 全局网络封装与 Dio 拦截器实战（鸿蒙兼容版）

AtomGit开源社区

多车调度系统上位机

AtomGit开源社区

EtherCAT从站（LAN9252+STM32）配置全解析与优化指南

摘要：本文详细介绍了EtherCAT从站设备的配置参数及推荐设置，涵盖SlaveInformation、Generic、Hardware、EtherCATStateMachine、Synchronisation、Application、ProcessData和Mailbox等模块。针对STM32F412+LAN9252方案，提供了硬件访问文件、内存分配、同步机制等具体实现建议，并强调ECAT_Ma