A2UI 与 Disco Browser：面向“千人千面”生成式 UI 的协议与浏览器新形态

Elysiane
0 阅读14分钟

A2UI 与 Disco Browser：面向“千人千面”生成式 UI 的协议与浏览器新形态

从“文本墙”到“生成式 UI”：A2UI 正在重塑 Agent 交互体验

image

原文链接:点击查看原文链接和作者互动

1. 背景与动机：当 Agent 遭遇交互瓶颈

在多智能体系统与大语言模型（LLM）应用日益普及的今天，我们常常会遇到一个尴尬的场景：AI Agent 虽然“聪明”，但与用户的沟通方式却显得“笨拙”。无论是预订一张机票、审批一项报销，还是完成一笔复杂的金融交易，传统基于文本的“问答游戏”暴露了诸多弊端：

  • 低效的“线性”交互：用户与 Agent 之间需要进行多轮对话才能确认所有必要信息，过程繁琐且耗时，仿佛在与一个没有“手脚”的客服沟通。
  • 高认知负荷：面对大段的文本或静态表格，用户需要自行梳理和筛选关键信息，难以进行快速决策和下一步操作。
  • 安全与信任的鸿沟：如果允许 Agent 直接生成并执行前端代码（如 HTML/JS），会带来严重的安全风险（如 XSS 攻击）。而采用 iFrame 等沙箱方案，又会破坏应用的视觉一致性和用户体验，且资源开销巨大。

A2UI 的诞生，正是为了解决这一核心矛盾：如何在不牺牲安全性的前提下，赋予 Agent 生成丰富、动态、原生 UI 的能力，从而突破“文本墙”的交互瓶颈。

2. 核心设计哲学：安全如数据，表现胜代码

A2UI 的设计巧妙地平衡了安全性与表现力，其核心思想可以概括为“声明式 JSON + 客户端原生渲染”。这套“建筑师与施工队”的协作模式是理解 A2UI 的关键所在。

image

这种“逻辑与渲染分离”的架构带来了四大核心优势：

  1. 安全优先 (Security First)：由于 Agent 只传递纯粹的 JSON 数据而非可执行代码，从根本上杜绝了 UI 注入攻击的可能。客户端只渲染其“组件目录 (Catalog)”中预先批准的、安全的组件。
  2. LLM 友好 (LLM-Friendly)：协议采用扁平化的组件列表和简单的 ID 引用，而非复杂的嵌套树。这种结构更易于大语言模型（LLM）逐步生成和修改，非常适合流式传输场景。
  3. 框架无关与跨平台 (Framework-Agnostic & Cross-Platform)：同一份 A2UI JSON 负载可以在任何集成了相应渲染器的客户端上运行，无论是 Web、Android 还是 iOS。这实现了真正的“一次生成，处处渲染”。
  4. 渐进式渲染 (Progressive Rendering)：通过 JSONL (JSON Lines) 格式进行流式传输，客户端可以随着消息的到达逐步构建和更新 UI，为用户提供近乎实时的响应体验，避免了“白屏等待”。

3. 协议与消息模型：Agent 如何“说”UI

A2UI 的核心是一套定义清晰的流式协议，它通过四种主要的消息类型，让 Agent 能够精确地控制客户端的 UI 渲染过程。所有消息通过 SSE (Server-Sent Events) 以 JSONL 格式单向从服务器（Agent）流向客户端。

四大核心消息类型

  1. surfaceUpdate (表面更新)

    • 作用：定义或更新一个或多个 UI 组件。这是构建 UI 结构的基础。所有组件以扁平列表的形式发送，通过 id 建立层级关系。

  2. dataModelUpdate (数据模型更新)

    • 作用：更新与 UI 解耦的数据。例如，改变一个文本标签的内容或更新一个列表的数据源。这种分离使得数据更新非常高效，无需重新发送整个 UI 结构。

  3. beginRendering (开始渲染)

    • 作用：通知客户端已经拥有足够信息，可以开始进行首次渲染。这可以防止界面因组件未加载完而出现“闪烁”或内容不完整的情况。

  4. deleteSurface (删除表面)

    • 作用：明确指示客户端移除某个 UI 区域（Surface）及其所有相关组件和数据，用于动态管理界面和回收资源。
// 示例：一个简单的 A2UI 消息流 (JSONL 格式)
{"surfaceUpdate": {"surfaceId": "main", "components": [{"id": "greeting", "component": {"Text": {"text": {"path": "/welcome_message"}}}}]}} // 1. 定义一个文本组件，其内容绑定到数据模型
{"dataModelUpdate": {"surfaceId": "main", "contents": [{"key": "welcome_message", "valueString": "欢迎使用 A2UI"}]}} // 2. 为数据模型提供具体内容
{"beginRendering": {"surfaceId": "main", "root": "greeting"}} // 3. 通知客户端开始渲染
组件目录与数据绑定
  • 组件目录 (Component Catalog)：Agent 并非可以随心所欲地生成任何组件。客户端会维护一个“白名单”，即组件目录，其中定义了所有允许使用的组件及其属性。在通信开始时，双方会通过“目录协商”机制确认本次交互可用的组件集，确保了安全性和一致性。
  • 数据绑定 (Data Binding)：组件的属性（如文本内容、图片 URL）可以绑定到数据模型中的特定路径。当 dataModelUpdate 消息传来时，所有绑定了相应数据的组件都会自动更新，实现了 UI 的响应式变化。

4. 架构与渲染链路：端到端流程解析

A2UI 的端到端工作流程清晰地展示了其“逻辑与渲染分离”的设计思想，整个过程可以分解为三个主要阶段：

image

  1. 生成阶段 (Agent Backend)

    • AI Agent（通常由 Gemini 等 LLM 驱动）根据用户请求和上下文，生成或填充一份描述 UI 意图的 A2UI JSON 负载。这份负载遵循 A2UI 协议规范，定义了组件结构、数据绑定和交互行为。

  2. 传输阶段 (Transport Layer)

    • 生成的 JSONL 数据流通过一个标准化的传输协议发送给客户端。A2UI 本身不限定传输方式，可以灵活地与 A2A (Agent-to-Agent)、AG-UI (Agent-to-User Interaction) 等协议协同工作，或直接通过 HTTP SSE 传输。

  3. 渲染阶段 (Client Frontend)

    • 客户端的 A2UI 渲染器 (Renderer) 接收并解析 JSONL 数据流。
    • 它将解析出的组件描述和数据模型变化存入状态管理器。
    • 组件映射器根据协商好的组件目录 (Catalog)，将抽象的组件描述（如 "component": "Text"）映射到客户端原生的 UI 组件（如一个 Angular 的 或一个 Flutter 的 Text()）。
    • 最终，界面由这些安全、高性能的原生组件构成，并自动继承客户端应用的主题、样式和可访问性特性，保证了无缝的用户体验。

image

图 2｜ Agentic 应用栈与 AG-UI 的位置关系

这种设计取舍的核心在于：将 UI 的“安全与表现”完全交由客户端掌控，Agent 只负责“思考和指挥”，从而在灵活性和安全性之间取得了最佳平衡。

5. 生态协同与定位：A2UI 与它的“伙伴们”

A2UI 并非一个孤立的协议，它的价值在于能够融入更广泛的 Agent 生态系统，与其他协议协同工作，共同构建完整的 AI 应用。理解 A2UI 与 A2A、AG-UI、MCP-UI 等“伙伴们”的关系至关重要。

详细可以参考查看：AG-UI and A2UI: Understanding the Differences | CopilotKit

image

与 A2A 和 AG-UI 的配合：内容与管道的关系

如果将 Agent 间的通信比作物流系统，那么 A2A 和 AG-UI 就是“运输管道”，而 A2UI 则是管道中流动的“货物”（即 UI 数据）。

  • A2A (Agent-to-Agent Protocol): 由 Google 推出的、用于不同 Agent 之间通信与协作的开放协议。它主要解决“Agent 如何指挥另一个 Agent 干活”的问题，涵盖任务派发、状态同步等。当一个 Agent 需要委托另一个远程 Agent 生成 UI 时，A2UI 负载就可以作为 A2A 消息的核心内容进行传递。
  • AG-UI (Agent-User Interaction Protocol): 由 CopilotKit 社区提出，专注于连接用户前端应用与后端 Agent 的运行时交互协议。它为状态同步、事件流、工具调用等高频、双向的人机协作场景提供了标准化方案。AG-UI 作为“管道”，可以高效地传输 A2UI 数据，并处理用户在 A2UI 界面上的交互事件。

简而言之：A2A 和 AG-UI 负责“如何传输”，而 A2UI 负责“传输什么”。三者结合，形成了一套完整的从 Agent 生成、跨 Agent 协作到最终用户呈现的标准化解决方案。

image

图 3｜ AG-UI 与 A2UI 的关系与 A2UI Compose，两者互补关系及基于 CopilotKit 的 UI 组合能力。

与 MCP-UI / Open-JSON-UI 的差异：原生渲染 vs. 沙箱展示

在生成式 UI 领域，除了 A2UI，还存在其他几种主流规范。它们在实现路径和设计取舍上各有不同。

特性A2UI (Google)MCP-UI (Microsoft + Shopify) / Open-JSON-UI (OpenAI)AG-UI (CopilotKit)
核心定位声明式 UI 数据格式UI 内容片段 (HTML/iFrame)Agent 与前端的运行时交互协议
渲染方式客户端原生渲染 (Native Rendering)沙箱化渲染 (Sandboxed)自身不负责渲染，作为传输管道
安全性高 (仅传输数据，组件由客户端控制)中/低 (可能执行外部代码，依赖沙箱隔离)安全性取决于其传输的内容
UI 一致性高 (完全继承原生应用主题和样式)低 (iFrame 风格通常与原生应用脱节)/
性能/资源高 (原生组件性能)低 (iFrame 开销较大)/
生态协同与 A2A、AG-UI 紧密集成通常作为 MCP 协议的扩展可承载 A2UI、MCP-UI 等多种数据格式
  • MCP-UI / Open-JSON-UI: 这类规范倾向于让 Agent 直接生成 HTML/CSS/JS 片段，然后由客户端在一个沙箱环境（如 iFrame）中进行渲染。这种方式虽然灵活，但也带来了安全隐患、视觉风格不统一和性能开销等问题。
  • A2UI 的选择: 相比之下，A2UI 坚持“原生优先”的道路，通过牺牲一定的任意表现力，换取了更高的安全性、性能和与宿主应用的无缝集成体验。这对于追求稳定性和品牌一致性的企业级应用尤其重要。

image

图 1｜ Generative UI 规格对比概览（社区资料），强调 A2UI 的声明式 JSON 与 MCP-UI / Open-JSON-UI 的 iframe/HTML 片段路径之间的差异。

6. “千人千面”的落地：AI 如何按需生成个性化 UI

A2UI 最具想象力的应用场景，莫过于实现真正“千人千面”的个性化用户界面。传统的软件界面是为“平均用户”设计的，而 A2UI 使 Agent 能够根据每个用户的具体业务、角色、偏好甚至当前对话的上下文，即时生成最合适的 UI。

个性化如何实现？

此处手动加上提问A2A和A2UI，似乎是千人千面（界面）的底层协议？

  1. 动态组件选择与布局：Agent 可以根据任务的复杂度和数据量动态选择最合适的组件。例如，对于少量数据，它可能生成一个简洁的列表（List）；而面对海量数据，则会自动切换为功能更强大的数据表格（DataTable）或网格（Grid）布局。
  2. 数据驱动的 UI：通过强大的数据绑定能力，Agent 可以将用户的个人数据、业务数据与 UI 组件深度融合。一个面向销售的报表界面，可以自动填充该销售人员的业绩数据；一个项目管理界面，可以只显示与当前用户相关的任务。
  3. 样式主题与品牌一致性：通过 beginRendering 消息中的 styles 对象，Agent 可以影响 UI 的视觉风格（如主色调），但最终的渲染效果仍由客户端掌控。这确保了个性化 UI 不会脱离应用本身的品牌规范，实现了“戴着镣铐跳舞”的动态美学。
  4. 安全边界与治理：企业可以定义一套符合自身合规与安全要求的私有组件目录（Custom Catalog）。Agent 只能在这套受控的组件范围内生成 UI，确保了所有动态生成的界面都满足企业治理要求，这对于金融、医疗等高度管制的行业至关重要。

7. Google Labs：Disco 浏览器与 GenTabs 概览

Disco 是 Google Labs 最近推出的一款实验性浏览器，并非 Chrome 的普通版本更新，而是一个独立的 AI 浏览体验实验项目。其首个旗舰能力 GenTabs，面向复杂在线任务：将用户当前打开的一组标签页，以及与 Gemini 的聊天上下文，整理成一个可交互的 Web 应用，而不是再返回一段“文本墙”，具有浏览器上下文的web版灵光App？。

image

核心能力要点
  • “信息即界面”：在 Disco 中，网页和工具不再只是被动的信息来源，而会被织入到一个任务导向的界面里。GenTabs 会读取当前的标签页内容，并按需调用地图、日历等工具，将分散的信息与工具组合为交互式视图；每个生成出的模块都保留指向原始网页的链接，方便用户随时回到信息源。
Disco&A2UI
  • 共同指向生成式界面：A2UI 提供的是一种 声明式 UI 数据协议，以安全的 JSON 结构描述界面，由各端原生渲染器完成展示；Disco / GenTabs 则属于应用层实验，用生成式方式把“网页 + 对话上下文”转化为一个可立即使用的 Web 应用。二者都在推动从“纯文本输出”走向“生成式界面”的交互范式。
  • 协同路径：在更成熟的生态中，可以想象 Agent 既能像 Disco 一样理解浏览上下文，又能输出符合 A2UI 规范的结构化 UI 描述；这些 A2UI 消息通过 A2A / AG-UI 等传输协议送达不同终端，由各端渲染器转换为原生界面。Disco 展示的是“从内容生成界面”的一种路径，而 A2UI 提供的是“界面如何表达与分发”的统一语言，职责互补而非互斥。
状态

目前 Disco / GenTabs 仍处于 Google Labs 实验阶段，仅向一小部分用户灰度开放，优先在 macOS 上通过等待名单提供下载和体验。Google 明确将其定位为长期的探索性项目：通过真实使用反馈验证哪些生成式界面形态最有价值，再将成熟的能力迁移到更大规模的产品体系中，可以通过公布的视频。

小结：

从 A2UI 协议、A2A/AG-UI 协议栈，到 Flutter GenUI、Gemini Enterprise，再到 Disco 浏览器与 GenTabs 这样的前端实验，可以看出 Google 并不是零散地堆砌「AI 能力」，而是在系统性地搭一套从模型、协议、渲染到应用形态的完整棋局：一端用声明式 UI 规格把「界面」标准化为可交换的数据，另一端用浏览器与工具链持续试探未来的人机交互形态。无论这盘棋最终以何种产品落地，它已经在悄悄改变一个前提——AI 不再只是回答问题的「嘴」，而是能随场景即时生成、协同调度界面的「手脚」，而 Google 正试图掌握这一代 UI 范式的起点与话语权。

8. 引用与扩展阅读

avatar
文章
阅读
粉丝