从聊天机器人到仪表板：Google 的 A2UI 协议如何重新定义人工智能代理能向你展示的内容

快速回答： A2UI（Agent-to-UI，代理到用户界面）是 Google 创建的一个开源协议，使 AI 代理能够生成丰富、交互式的用户界面——表单、图表、地图、仪表板——而不是纯文本响应。A2UI 于 2025 年 12 月发布（v0.8 公开预览），允许代理发送声明式 JSON 组件描述，客户端应用程序将其渲染为本机交互式小部件。对于数据团队来说，这意味着 AI 可以输出可探索的仪表板，而不是要点摘要，从而改变我们与 AI 进行数据分析和可视化的交互方式。

1. 你的 AI 代理一直在说话，而它本应展示

聊天机器人范式从未为数据设计

让通用助手分析季度销售数据。你会得到什么？一堵文字墙。要点。可能是一个你需要复制到笔记本中才能看到图表的代码块。模型可能理解你的数据——但它通常以最原始的格式回答：段落。

自 2022 年以来，我们通过一个线性、纯文本的聊天窗口与功能强大的模型进行交互——这与经典的 IRC 形态相同。系统可以推理复杂数据集、标记异常并提出建议——然而界面只是一个你从上到下阅读然后忘记的滚动消息列表。

2025 年 12 月，Google 开源了 A2UI（Agent-to-UI）——一个允许代理生成丰富、交互式用户界面（而非纯文本）的协议。表单、日期选择器、图表、地图、仪表板——由代理即时生成，在你的应用程序中本地渲染。

实际演示令人信服：Google 展示了一个餐厅查找代理生成带有日期选择器、时间选择器和提交按钮的预订表单——而不是许多聊天机器人为一次简单预订所需的痛苦的多消息文本来回。对于数据团队，其含义更为尖锐：代理可以生成一个 可探索的仪表板，而不是数据的描述。

2. 什么是 A2UI？通俗易懂的解释

让代理构建界面而非书写段落的协议

A2UI（Agent-to-UI）是一个开源协议，允许代理发送 声明式 UI 描述——描述按钮、表单、图表、地图和布局的 JSON 消息——到客户端，客户端将其渲染为本机交互式组件。可以将其视为“针对代理的 HTML”，具有更强的安全性和可移植性默认值。

A2UI 解决的问题：信任边界

我们正处于多代理系统时代。不同服务器和不同供应商的代理进行协调。它们不能直接接触你的 UI。

旧模式？在 iframe 内传输原始 HTML 或 JavaScript——笨重、视觉上脱节且存在安全隐患。A2UI 的方法：传输行为类似 数据 但读起来像 设计 的 UI。代理发送 JSON 蓝图；客户端使用自己的本机小部件渲染它。

工作原理：三条消息模式

surfaceUpdate

描述 UI 组件树——显示什么。这里一个日期选择器，那里一个图表，下面一个提交按钮。

dataModelUpdate

提供应用程序状态——显示什么数据。图表系列、地图坐标、表单默认值。

beginRendering

触发渲染——何时显示。客户端将组件与数据组装并显示界面。

对于餐厅预订示例：代理发送描述日期选择器、时间选择器、人数下拉框和提交按钮的 JSON。客户端使用自己的 UI 框架（React、Angular、Flutter、Lit）渲染每个部分，应用自己的样式和无障碍标准，呈现一个连贯的表单。没有 iframe。没有外部代码执行。

三个核心设计原则

安全第一

声明式数据，而非可执行代码。代理从 受信任的目录 请求组件——与传输不透明脚本相比，降低了任意代码执行风险。

原生感觉

无 iframe。客户端使用自己的 UI 框架渲染，因此生成的 UI 可以继承应用程序样式、无障碍和性能特性。

LLM 友好结构

带有 ID 引用的扁平组件列表比临时的标记混合体更易于模型生成、纠正和渐进式流式传输。

生态系统（v0.8 公开预览）

A2UI 处于 v0.8 公开预览 阶段，以 Apache 2.0 许可证发布。Lit、Angular 和 Flutter（通过 Google 的 GenUI SDK）有稳定的渲染器。React 支持计划于 2026 年第一季度推出，SwiftUI 和 Jetpack Compose 计划于第二季度推出。该协议支持多种传输方式，包括 A2A 协议、AG UI、SSE 和 WebSocket。

首日生态系统合作伙伴包括 CopilotKit/AG UI（兼容层）、Opal（AI 迷你应用）、Gemini Enterprise 和 Flutter 的 GenUI SDK。这是 Google 对 开放标准 的赌注，用于代理驱动的界面——对数据可视化影响重大。

3. 为什么聊天机器人在数据分析中失败：五堵墙

聊天窗口是探索数据的错误界面

聊天适用于问答、写作和代码生成。但对于应该是 空间性、交互性和可视化 的分析，它表现糟糕。以下是五堵墙——以及生成式 UI 方法如何解决每一堵。

墙 1：文本墙

让聊天机器人分析一万行销售数据。你可能会得到许多段落的要点。人类视觉处理在模式识别上比阅读密集文本快得多。一个设计良好的图表可以在不到一秒的时间内传达需要几分钟解析为散文的信息。

你需要的替代方案： 带有悬停详情、向下钻取和日期过滤器的交互式图表。

墙 2：线性墙

聊天是顺序的——每条消息争夺注意力。你无法同时看到销售趋势、客户细分和利润分析。分析是空间性的，而不仅是时间性的。

你需要的替代方案： 一个多面板仪表板，视图并排显示并响应式更新。

墙 3：交互墙

只想看第三季度？你输入“过滤到第三季度”。代理可能重新生成整个分析。想看六月放大？又一条消息。与去年比较？又一条消息。应该 一次点击 的交互变成了 一句话、一次调用、一次完整重写。

你需要的替代方案： 立即响应的原生下拉框、范围选择器和切换开关。

墙 4：探索墙

分析是非线性的：跟踪异常、转向、后退、尝试另一个角度。聊天线程是永久且顺序的——你不能像在仪表板的有状态控件中那样“撤销”探索。

你需要的替代方案： 具有撤销、重做和分支探索的交互式状态。

墙 5：展示墙

你找到了洞见——但产物是一个冗长的聊天线程。很难将其导出为仪表板或幻灯片就绪的故事。

你需要的替代方案： 可导出的仪表板、可下载的图表和产品支持下的单击幻灯片生成。

底线：聊天优化的是 对话，而非 探索。A2UI 是通向匹配分析师实际工作方式的界面的途径之一。

4. A2UI 用于数据可视化：RizzCharts 示例

Google 已经展示了代理构建的分析界面

代理发出声明式组件描述。客户端将其渲染为本机交互式小部件。

RizzCharts 是什么

RizzCharts 是 Google 的官方 A2UI 示例——一个 AI 驱动的电商仪表板，展示了可视化的生成式 UI 范例。其交互模型不同于以聊天为先的工具：

• 用户：“按类别显示销售细分”→ 代理生成一个交互式环形图，带有向下钻取，本地渲染。
• 用户：“是否有异常门店？”→ 代理生成带有高亮标记和工具提示的地图。
• 用户点击一个分段→ 仪表板向下钻取到子类别，无需新的聊天轮次。

客户端中没有来自代理包的代码执行，没有 iframe——声明式 JSON 作为原生组件渲染。代理（示例中的 Gemini 加上 Google ADK）通过 get_sales_data 和 get_store_sales 等工具获取数据，然后使用 surfaceUpdate → dataModelUpdate → beginRendering 流程构建 A2UI 负载。

为什么这很重要

代理不仅以文本分析数据——它还在创建用户可以探索的界面。将结构从状态分离意味着图表可以在新数据到达时响应式更新。相同的 JSON 可以针对 Web、移动和桌面表面。自定义目录可以用领域组件扩展 A2UI：财务图表、医疗时间线、工程图表、地理空间图层。

局限性

A2UI 是一个 协议，而非产品。它定义了代理如何通信 UI——而不是必须在 UI 存在之前发生的清洗、统计、图表类型选择和设计推理。一个完整的可视化工作流仍然需要一个智能层，决定 显示什么 和 为什么。

5. 从协议到产品：生成式 UI 数据平台的样子

A2UI 定义传输；智能是价值集中所在

A2UI 针对最后一英里：将交互式 UI 从代理送到屏幕。完整的管道仍然需要超越传输的深度：

1. 数据理解——解析 CSV、Excel、JSON、PDF；推断架构；检测列类型；处理编码边缘情况。
2. 数据清洗——标准化日期；处理空值；处理异常值；解决不一致。
3. 统计分析——分布、相关性、趋势、异常、增长——判断哪些是有趣的。
4. 图表选择与设计——将图表类型与意图匹配；调色板；视觉层次；响应式布局。
5. 交互式生成——过滤器、向下钻取、工具提示、有助于理解的动画。
6. 导出与展示——PPT、PDF、PNG、SVG 或面向不同受众的嵌入。

A2UI 帮助步骤 5 到达客户端。步骤 1–4 和 6 仍然需要任何协议都无法替代的领域智能。这一差距是标准与产品之间的区别。

ChartGen AI 如何实现这一理念

在 ChartGen AI，我们一直在构建同样的生成式 UI 理念——不是因为我们专门发送 A2UI 线路格式，而是因为我们共享这一信念：代理应该输出交互式可视化工作区，而不是关于图表的段落。

以常见格式上传数据并用自然语言描述你想要的内容。系统旨在提供可探索的仪表板——而不是仅聊天的答案。六个专门代理覆盖整个管道：

规划代理

将请求分解为子任务并决定需要哪些可视化。

数据清洗代理

架构推断、空值处理、日期标准化、异常值检测。

数据分析代理

统计、模式检测、相关性分析、洞察生成。

可视化代理

图表类型选择、布局、调色板、响应式仪表板组合。

网页搜索代理

在相关时使用基准和市场背景进行外部丰富。

PPT 生成代理

将图表和洞察转化为具有叙事流程的可展示幻灯片。

输出应该是一个 画布，你可以点击、过滤、钻取和导出——生成式 UI 应用于数据可视化工作流。

共同理念：对于数据，代理生成的 UI 胜过代理生成的文本

无论传输方式是 A2UI 的声明式 JSON 还是多代理可视化堆栈，洞察都是一样的：

对于分析，正确的产物通常是 界面，而非段落。

• 代理提议 UI： 与数据集匹配的图表类型、布局和交互——用户不应微观管理“制作条形图”。
• 默认交互式： 悬停、钻取、过滤——不是埋在聊天中的静态截图。
• 原生质量： 表面应该读起来像为决策构建的仪表板，而不是带有附件的消息。

6. 未来：代理驱动的界面对于数据团队意味着什么

对 2026–2027 年的三个预测

以聊天为先的工具将添加生成式 UI 层。 许多分析产品仍默认使用文本加静态图像。到 2027 年底，更多产品将把交互式仪表板作为一等输出——而像 A2UI 这样的开放标准减少了这种情况发生的锁定。

分析师的工作从构建转向策展。 当代理组成仪表板时，人类通过提问、验证洞察和塑造叙事来引领——编辑判断多于手动图表组装。

领域特定目录成为护城河。 协议是开放的；竞争优势集中在 受信任的组件库 和 领域智能——团队依赖的风险热图、群体视图、地理收入图和其他专门基元。

你现在可以做什么

• 开发者： 立即使用 A2UI（v0.8）、ADK 和 Gemini 尝试用声明式 JSON 构建代理驱动的表面。
• 分析师： 使用已经将仪表板视为主要输出的工具，如 ChartGen AI。
• 产品领导者： 评估内部工作流应从以聊天为先的提示转向以 UI 为先的探索——投资回报体现在探索速度和决策质量上。

7. 常见问题

什么是 A2UI？

A2UI（Agent-to-UI）是 Google 的一个开源协议，允许代理发送描述 UI 组件（表单、图表、地图、仪表板）的声明式 JSON，客户端使用本机小部件渲染。公开预览在 v0.8（2025 年底）左右，采用 Apache 2.0 许可证。

什么是生成式 UI？

生成式 UI 意味着模型根据提示动态创建布局和交互元素，而不仅仅是填充固定模板。A2UI 是一个针对 多代理 和 跨信任边界 场景的协议。

为什么聊天机器人在数据分析中薄弱？

它们将分析序列化为线性文本。探索受益于空间布局、直接操作和视觉。常见痛点包括文本墙、线性、缓慢的交互循环、有限的探索状态和弱展示产物。

代理如何生成交互式仪表板？

像 A2UI 这样的协议携带组件和绑定数据的声明式描述。客户端渲染原生控件。生产质量仍然依赖于上游的清洗、分析和设计智能——而不仅仅是传输。

A2UI 和生成式 UI 有什么区别？

生成式 UI 是广义概念。A2UI 是一个具体的开放方法，强调声明式数据而非可执行代码、跨客户端可移植性以及组织间更安全的协作。

8. 停止阅读关于你的数据——开始探索它

最佳的 AI 数据分析是一种体验，而不仅仅是对话

Google 的 A2UI 将从业者已经感受到的东西形式化：洞察渴望界面——过滤器、悬停、比较——而不仅仅是段落。

聊天时代证明了模型可以理解数据。文本仍然是深度探索的默认 表面 的错误选择：你无法过滤一个段落，钻取一个要点，或悬停一个句子以获取血统。

A2UI 提供了传输故事。生成式 UI 提供了产品理念。多代理系统承载了决定可视化什么的推理。它们共同勾勒出下一个时代：默认交互式、视觉化和可探索的分析。

无论你是直接采用 A2UI、使用共享这一理念的平台，还是自己构建——方向是明确的。AI 辅助分析的未来不仅是一个聊天线程。它是一个你可以导航的体验。

在 ChartGen AI 上尝试你自己的文件：描述问题，根据你的行验证数字，然后探索画布，而不是以消息形式重新阅读相同的摘要。