A2UI：让 AI Agent 自主构建用户界面的新范式

一句话定义：A2UI（Agent-to-User Interface）是一个开放协议，允许 AI Agent 通过结构化数据描述交互意图，由前端框架动态渲染 UI，实现"AI 驱动界面"。

一、A2UI 是什么

A2UI 不是 UI 框架，而是谷歌于 2025 年 12 月推出一套声明式接口协议。a2ui.org/

AI Agent 在执行任务时，可生成符合 A2UI Schema 的 JSON 对象，描述当前需要用户看到什么、输入什么、操作什么。前端运行时（如 Web App）接收该结构并动态渲染成真实 UI。

这类似于"AI 版本的 Virtual DOM"------Agent 声明意图，系统负责实现。

以下是 A2UI 渲染卡片的示例，展示了 A2UI 可以实现的各种 UI 组合。

在线效果预览：a2ui-editor.ag-ui.com/

二、A2UI 解决什么问题

想象一下，有一个Agent可以帮助你预订餐厅座位。如果只进行文字交流，可能会出现笨拙的来回沟通：

用户：（ 正在输入）"预订一张两人桌。"

Agent： "好的，哪一天？"

用户：（ 正在输入）"明天。"

Agent： "几点？"

用户：（ 输入）"大概7点"

Agent： "我们那时没有空房了，还有其他时间吗？"

用户：（ 正在输入）"你们什么时候有预订？"

Agent： "我们有 5:00、5:30、6:00、8:30、9:00、9:30 和 10:00 的空位，这些时间您方便吗？"

这可能既缓慢又低效。更好的体验是让Agent快速生成或使用包含日期选择器、时间选择器和提交按钮的简单表单。借助 A2UI，LLM 可以从组件库中构建定制的用户界面，从而为当前任务提供美观、易用且图形化的界面。

例如，除了上述基于文本的来回聊天之外，您还可以使用 A2UI 来构建此预订界面。下图展示了 A2UI 呈现的餐厅预订界面的一种可能效果，A2UI 的设计赋予前端应用程序对样式的高度控制权，因此还有许多其他可能性。

当前 AI 应用的交互瓶颈主要集中在 "效率低" 和 "不安全" 两大层面，A2UI 的设计恰好针对性破局：

痛点场景	传统文本交互模式	A2UI 解决方案
信息采集效率低	订座需多轮问答（"几位？几点？忌口？"）	直接生成含人数选择器、日历、下拉框的表单，用户一键确认
界面安全性差	AI 生成 HTML 可能包含恶意代码，存在注入风险	客户端仅用预批准组件库渲染，AI 无法控制像素或执行代码
跨端体验割裂	为 Web、iOS、Android 分别开发界面，成本高	一套 A2UI 描述自动适配多端原生组件，无需重复开发
等待体验差	需等待 AI 生成完整响应后才显示界面	流式输出界面片段，实时渲染，减少等待焦虑

三、A2UI 核心概念

组件结构（Component Structure）

{
    "id": "welcome",
    "component": {
        "Text": {
            "text": {
                "literalString": "Hello"
            },
            "usageHint": "h1"
        }
    }
}

每个组件都具有：

1. ID ：唯一标识符（"root"）

2. 类型 ：组件类型（Text，Button）

3. 属性：特定于该类型的配置

组件数据定义最佳实践： 使用语义提示，而非视觉属性。应该提供语义提示（usageHint），而不是视觉样式：

// ✅ Good: Semantic hint
{
  "component": {
    "Text": {
      "text": {"literalString": "Welcome"},
      "usageHint": "h1"
    }
  }
}

// ❌ Bad: Visual properties (not supported)
{
  "component": {
    "Text": {
      "text": {"literalString": "Welcome"},
      "fontSize": 24,
      "color": "#FF0000"
    }
  }
}

消息类型（Message Types）

服务器→客户端消息

• surfaceUpdate：定义或修改指定 Surface 中的 UI 组件，是构建 UI 结构的核心消息。
• dataModelUpdate：修改指定 Surface 的数据模型，组件通过数据绑定自动同步更新，无需重发 UI 结构。
• beginRendering：向客户端发送渲染信号，告知已接收足够初始化信息，可启动指定 Surface 的 UI 渲染。
• deleteSurface：移除指定 Surface 及其所有组件、数据模型，适用于关闭弹窗、页面导航等场景。

客户端→服务器消息

• userAction ：用户交互事件，包含动作名称、surfaceId、触发组件 ID、时间戳和解析后的上下文数据。
• error：客户端错误反馈，可自定义错误信息内容，用于服务器调试。

完整流示例：

{"surfaceUpdate": {"components": [{"id": "root", "component": {"Column": {"children": {"explicitList": ["profile_card"]}}}}]}}
{"surfaceUpdate": {"components": [{"id": "profile_card", "component": {"Card": {"child": "card_content"}}}]}}
{"surfaceUpdate": {"components": [{"id": "card_content", "component": {"Column": {"children": {"explicitList": ["header_row", "bio_text"]}}}}]}}
{"surfaceUpdate": {"components": [{"id": "header_row", "component": {"Row": {"alignment": "center", "children": {"explicitList": ["avatar", "name_column"]}}}}]}}
{"surfaceUpdate": {"components": [{"id": "avatar", "component": {"Image": {"url": {"literalString": "https://www.example.com/profile.jpg"}}}}]}}
{"surfaceUpdate": {"components": [{"id": "name_column", "component": {"Column": {"alignment": "start", "children": {"explicitList": ["name_text", "handle_text"]}}}}]}}
{"surfaceUpdate": {"components": [{"id": "name_text", "component": {"Text": {"usageHint": "h3", "text": {"literalString": "A2A Fan"}}}}]}}
{"surfaceUpdate": {"components": [{"id": "handle_text", "component": {"Text": {"text": {"literalString": "@a2a_fan"}}}}]}}
{"surfaceUpdate": {"components": [{"id": "bio_text", "component": {"Text": {"text": {"literalString": "Building beautiful apps from a single codebase."}}}}]}}
{"dataModelUpdate": {"contents": {}}}
{"beginRendering": {"root": "root"}}

数据绑定（Data Binding）

数据绑定的两种方式

1. 字面量值（静态绑定）

直接指定固定值，无需关联数据模型，适用于静态内容（如标题、固定提示文本）。示例：

{"id": "title", "component": {"Text": {"text": {"literalString": "Welcome"}}}}

2. 路径值（动态绑定）

通过 path 关联数据模型中的具体路径，数据变化时组件自动更新，实现响应式效果。示例：

{"id": "username", "component": {"Text": {"text": {"path": "/user/name"}}}}

当服务器通过 dataModelUpdate 消息更新数据时，组件自动刷新展示内容。例如：

{"dataModelUpdate": {"path": "/user", "contents": [{"key": "name", "valueString": "Alice"}]}}

响应式更新与动态场景

1. 响应式更新

绑定数据路径的组件会监听对应数据的变化，当服务器通过 dataModelUpdate 消息更新数据时，组件自动刷新展示内容。例如：

• 初始数据 /order/status 为 "Processing..."，组件显示 "Processing..."；
• 服务器发送数据更新消息，将 /order/status 改为 "Shipped"，组件无需额外配置即自动显示 "Shipped"。

2. 动态列表渲染

通过 template 实现数组数据的批量渲染，核心配置包含：

• dataBinding：指定数据模型中的数组路径（如 /products）；
• componentId：指定列表项的模板组件 ID。示例：

{
  "id": "product-list",
  "component": {
    "Column": {
      "children": {"template": {"dataBinding": "/products", "componentId": "product-card"}}
    }
  }
}

当数据模型中 /products 数组新增、删除或修改元素时，客户端会自动同步更新列表渲染结果。

数据流（Data Flow）

1. 用户需求："预订明天晚上 7 点的 2 人餐桌"
2. 服务器通过 SSE 建立 JSONL 流连接，持续发送协议消息；
3. 服务器发送 surfaceUpdate 消息，定义预订表单的 UI 结构（含标题、客人数量输入框、确认按钮等组件）；

{"surfaceUpdate": {"surfaceId": "booking", "components": [
  {"id": "root", "component": {"Column": {"children": {"explicitList": ["header", "guests-field", "submit-btn"]}}}},
  {"id": "header", "component": {"Text": {"text": {"literalString": "Confirm Reservation"}, "usageHint": "h1"}}},
  {"id": "guests-field", "component": {"TextField": {"label": {"literalString": "Guests"}, "text": {"path": "/reservation/guests"}}}},
  {"id": "submit-btn", "component": {"Button": {"child": "submit-text", "action": {"name": "confirm", "context": [{"key": "details", "value": {"path": "/reservation"}}]}}}}
]}}

4. 服务器发送 dataModelUpdate 消息，初始化数据（日期时间：2025-12-16T19:00:00Z，客人数量：2）；

{"dataModelUpdate": {"surfaceId": "booking", "path": "/reservation", "contents": [
  {"key": "datetime", "valueString": "2025-12-16T19:00:00Z"},
  {"key": "guests", "valueString": "2"}
]}}

5. 服务器发送 beginRendering 消息（指定根组件 ID 和目录 ID），客户端渲染预订表单；

{
    "beginRendering": {
        "surfaceId": "booking",
        "root": "root"
    }
}

6. 客户端从根组件开始，递归通过 ID 查找组件，解析数据绑定，调用组件目录生成原生 UI； 7. 用户修改客人数量为 3（客户端本地更新数据模型，无需立即通知服务器）

7. 用户点击 "确认"，客户端发送 userAction 消息，携带更新后的预订详情；

{
    "userAction": {
        "name": "confirm",
        "surfaceId": "booking",
        "context": {
            "details": {
                "datetime": "2025-12-16T19:00:00Z",
                "guests": "3"
            }
        }
    }
}

9. 服务器处理后，通过 SSE 流发送surfaceUpdate/dataModelUpdate或 deleteSurface 消息删除预订表单 UI，客户端更新缓冲并重新渲染。

{"deleteSurface": {"surfaceId": "booking"}}

数据流流程图：

Agent (LLM) → A2UI Generator → Transport (SSE/WS/A2A)
                                      ↓
Client (Stream Reader) → Message Parser → Renderer → Native UI

四、A2UI vs AI 生成 HTML

很多人会疑惑 "为什么不直接让 AI 生成 HTML？"，两者的本质差异在于 "安全可控性" 和 "跨端适配性"，具体对比如下：

对比维度	A2UI	AI 直接生成 HTML
安全性	仅用预批准组件库，无代码执行风险，防注入攻击	可能包含恶意脚本（如
跨端兼容性	自动适配 Web / 移动端 / 桌面端原生组件，体验一致	HTML 需额外适配不同设备，易出现样式错乱
维护成本	组件统一管理，更新只需修改客户端库	每个 HTML 界面需单独调试，兼容性问题多
LLM 友好性	扁平 JSON 结构，支持增量生成，降低 LLM 负担	需生成完整 HTML 结构，易出现语法错误（如标签未闭合）

A2UI 的核心适用场景：

场景类型	具体示例	选择 A2UI 的核心原因
企业级工具	员工报销表单、客户信息录入界面	统一多端体验，规避 HTML 代码注入风险，符合企业安全规范
生活服务交互	机票预订、餐厅订座、酒店选房	标准化组件（日历、下拉框、数字输入），流式渲染减少等待
智能助手界面	语音助手的可视化交互（如智能家居控制）	增量更新界面，适配手机 / 智能音箱屏 / 车载屏等多终端
低代码平台	AI 驱动的快速表单生成工具	组件可复用，无需调试 HTML 兼容性，降低开发成本

AI 生成 HTML 的核心适用场景：

场景类型	具体示例	选择 AI 生成 HTML 的核心原因
静态内容展示	个人博客文章、产品介绍页、活动海报页	快速生成富文本排版，支持自定义 CSS 样式，无需跨端
临时原型验证	产品经理快速制作 Web 界面原型	无需学习 A2UI 协议，直接生成可预览的 HTML，迭代快
简单营销页面	限时优惠弹窗、问卷星样式表单（仅 Web）	定制化样式（如渐变按钮、动态文字），适配 Web 端视觉需求
小体量个人项目	个人简历页、收藏夹页面	开发成本低，无需集成 A2UI 渲染器，直接部署即可

选型决策原则：

1. 终端范围：需跨端（Web / 移动端 / 桌面端）→ 选 A2UI；仅 Web 端 → 可考虑 HTML；
2. 安全与合规：企业级应用 / 面向公网 → 选 A2UI；个人项目 / 内部临时页面 → 可 HTML；
3. 交互类型：标准化表单 / 选择交互 → 选 A2UI；定制化展示 / 简单排版 → 可 HTML。

五、A2UI 的优缺点

优势：

1. LLM友好，开发高效：声明式结构+扁平组件列表，适配LLM流式生成，降低UI定义编写与AI生成难度。
2. 安全优先：声明式设计从根源规避代码执行风险，适合企业级应用；
3. 跨平台兼容：抽象组件与原生实现解耦，一套服务端逻辑可适配Web、Flutter等多平台，复用性强。
4. 渲染体验流畅：JSONL/SSE流式传输支持渐进式渲染，无需等待完整响应，减少加载等待感。
5. 更新轻量化：UI结构与数据分离，后续仅需发送数据更新消息，无需全量重发组件，传输高效。
6. 通信稳健：单向主数据流+独立交互反馈，单条消息错误不影响整体，支持网络重连与纠错。

不足：

1. 客户端开发成本高：需实现协议解析、组件映射、数据绑定等核心引擎，跨平台适配细节复杂。
2. 灵活度受限：组件与数据格式严格遵循目录规范，自定义组件需提前协商，非标UI迭代不便。
3. 传输依赖强：依赖SSE/WebSocket流式通道，消息顺序影响渲染效果，需处理乱序、丢包问题。
4. 复杂场景适配不足：对拖拽、实时协作等复杂交互，及毫秒级高频更新（如实时图表）支持有限。
5. 调试难度大：流式消息分散，问题可能涉及LLM生成、服务端发送、客户端解析等多环节，定位复杂。
6. 处于早期阶段：部分功能（如复杂数据绑定）可能不完善。

七、适用场景

A2UI 协议的核心优势集中在 LLM 驱动的流式 UI 生成、跨平台复用、渐进式渲染 场景，特别适合：

• 基于 AI 生成的动态界面（如 AI 助手生成的表单、报告、个性化页面）；
• 多平台同步的轻量化应用（如跨端工具类 App、简单数据展示界面）；
• 对加载体验要求高、无需复杂交互的场景（如内容浏览、表单提交、查询结果展示）。

而在以下场景中需谨慎选择：

• 复杂交互密集型应用（如游戏、视频编辑、可视化设计工具）；
• 快速迭代的非标 UI 场景（如高频更新的营销活动页面）；
• 客户端开发资源有限、无法承担协议解析引擎开发的项目。

八、社区活跃度与支持

前端渲染器支持：

七、未来展望：A2UI 将如何改变 AI 交互？

1. "即时应用" 成为可能：无需下载 App，AI 可根据需求实时生成轻量级界面（如临时报销表单、行程规划页），实现 "用完即走"；
2. Skill+A2UI 的组合范式：后端用 "Skill"（功能标准化封装），前端用 A2UI 生成界面，开发者只需聚焦核心逻辑，无需关注界面实现；
3. 补齐 AI 交互短板： 解决传统 Agent 仅靠文本 "傻聊" 的低效问题，让 AI 能动态生成图形界面（如订座表单、确认卡片），实现 "高带宽" 交互，从 "人适应机器" 转向 "机器适应人" 。
4. 生态整合深化：与 A2A（Agent-to-Agent）协议联动，实现 "代理协作生成界面"（如旅行代理调用航班代理的 Skill，同时生成统一预订界面）。

总结：A2UI 的核心价值 ------ 让 AI 从 "会聊" 到 "会做"

A2UI 的本质不是颠覆现有图形界面，而是用 AI 赋能交互 ------ 让界面从 "写死的代码" 变成 "动态响应需求的工具"。对于普通用户，它意味着 "少打字、多确认" 的高效体验；对于开发者，它代表 "一次逻辑开发，多端界面复用" 的效率革命。未来的 AI 不仅能理解你的需求，更能直接递上 "最趁手的工具界面"，这或许就是 "机器适应人" 的交互终极形态之一。

对于正在构建 Agent 的工程师来说，这是一个重要的架构参考。这种解耦让前端能掌握视觉风格，后端专注逻辑，彻底告别让 LLM 粗暴生成 HTML 的草莽时代。作为开发者可以关注 A2UI 的演进，这是未来 AI 原生应用的标准配置。

相关资料：

• developers.googleblog.com/introducing...
• github.com/google/A2UI...