A2UI 协议完整指南：使用 Google A2UI 构建代理驱动 UI（2025）

🎯 核心要点（TL;DR）

• A2UI 协议是一个声明式 UI 协议，使 AI 代理能够生成丰富的交互式界面，这些界面可以在 Web、移动和桌面平台上原生渲染
• A2UI解决了多代理系统中安全、跨平台 UI 生成的关键挑战，无需执行任意代码
• Google 采用 A2UI 为 Opal、Gemini Enterprise 和 Flutter GenUI SDK 等生产系统提供支持，展示了企业级的可靠性
• A2UI 协议使用 JSON 消息来描述 UI 组件，实现 LLM 友好的生成，同时保持原生性能和样式
• A2UI将 UI 结构与应用程序状态分离，通过 JSON Pointer 绑定实现响应式更新和数据驱动的界面

目录

1. 什么是 A2UI 协议？
2. A2UI 如何工作？
3. 为什么使用 A2UI 协议？
4. A2UI 架构和核心概念
5. Google 的 A2UI 实现
6. A2UI vs. 其他代理 UI 解决方案
7. A2UI 入门
8. A2UI 开发最佳实践
9. 关于 A2UI 的常见问题
10. 结论和下一步

什么是 A2UI 协议？

A2UI (Agent to UI) 是一个专门为代理驱动界面设计的声明式 UI 协议。与依赖纯文本交互或嵌入式 HTML/JavaScript 的传统方法不同，A2UI 协议使 AI 代理能够生成丰富的交互式 UI，这些 UI 可以在多个平台（Web、移动、桌面）上原生渲染，而无需执行任意代码。A2UI 协议代表了 AI 代理与用户界面通信方式的根本性进步，为代理提供了一种标准化的方式来描述 UI 组件，客户端可以使用其原生框架进行渲染。

A2UI 解决的问题

传统代理交互效率低下：

用户："明天晚上 7 点预订一张 2 人桌"
代理："好的，是哪一天？"
用户："明天"
代理："什么时间？"

使用 A2UI，代理生成包含日期选择器、时间选择器和提交按钮的完整表单。用户与原生 UI 组件交互，而不是无休止的文本交换。

多代理系统中的挑战

在分布式代理架构中，代理通常在远程运行（不同的服务器、组织）。它们无法直接操作您的应用程序 UI——它们必须通过消息进行通信。在 iframe 中发送 HTML/JavaScript 等传统解决方案存在以下问题：

• 笨重且视觉上不连贯 - 造成令人不快的用户体验
• 安全复杂性 - 需要大量的沙箱和验证
• 样式不匹配 - 无法与您的应用设计系统集成

A2UI 协议通过将 UI 描述作为结构化数据传输来解决这个问题——像 JSON 一样安全，像代码一样表达力强。这种方法使 A2UI 特别适合安全和互操作性至关重要的多代理系统。

A2UI 协议如何工作

A2UI 协议使用 JSON 消息来描述 UI 组件。了解 A2UI 协议的工作原理对于构建代理驱动应用程序的开发人员至关重要：

{"surfaceUpdate": {"surfaceId": "booking", "components": [
  {"id": "title", "component": {"Text": {"text": {"literalString": "预订您的餐桌"}, "usageHint": "h1"}}},
  {"id": "datetime", "component": {"DateTimeInput": {"value": {"path": "/booking/date"}, "enableDate": true}}},
  {"id": "submit-btn", "component": {"Button": {"child": "submit-text", "action": {"name": "confirm_booking"}}}}
]}}

这些消息通过任何传输方式（A2A、AG UI、SSE、WebSockets）传输，客户端使用自己的原生组件进行渲染。结果：A2UI 让客户端完全控制安全性和样式，而代理生成的 UI 感觉完全原生。这就是 A2UI 协议的核心价值主张——安全、原生感觉的 UI 生成，可在任何平台和传输机制上工作。

A2UI 如何工作？

A2UI 消息流

了解 A2UI 协议消息流对于在应用程序中实现 A2UI 至关重要。A2UI 协议定义了一系列描述 UI 结构、应用程序状态和渲染指令的 JSON 消息：

代理 (LLM) → A2UI 生成器 → 传输 (SSE/WS/A2A)
                                      ↓
客户端 (流读取器) → 消息解析器 → 渲染器 → 原生 UI

A2UI 协议中的核心消息类型

A2UI 协议规范定义了四种主要消息类型，这些类型构成了 A2UI 通信的基础。了解这些 A2UI 协议消息类型对于代理开发人员和客户端实现者都至关重要：

A2UI 组件结构：邻接表模型

与传统的嵌套 JSON 树不同，A2UI 使用邻接表模型——组件存储为带有 ID 引用的平面列表。这种设计选择使 A2UI 协议特别适合 LLM，这是使 A2UI 与其他 UI 生成方法区别开来的关键创新之一：

传统嵌套方法：

• 需要一次性完美嵌套
• 难以更新深度嵌套的组件
• 难以增量流式传输

A2UI 邻接表：

• ✅ 平面结构，易于 LLM 生成——这就是为什么 A2UI 协议如此适合 LLM
• ✅ 增量发送组件——A2UI 支持渐进式渲染
• ✅ 通过 ID 更新任何组件——A2UI 协议实现高效更新
• ✅ 结构和数据的清晰分离——A2UI 架构促进清晰的设计

示例：A2UI 组件定义

{
  "surfaceUpdate": {
    "components": [
      {"id": "root", "component": {"Column": {"children": {"explicitList": ["greeting", "buttons"]}}}},
      {"id": "greeting", "component": {"Text": {"text": {"literalString": "你好"}}}},
      {"id": "buttons", "component": {"Row": {"children": {"explicitList": ["cancel-btn", "ok-btn"]}}}},
      {"id": "cancel-btn", "component": {"Button": {"child": "cancel-text", "action": {"name": "cancel"}}}}
    ]
  }
}

A2UI 协议中的数据绑定

数据绑定是 A2UI 协议的核心功能。A2UI 使用 JSON Pointer 路径（RFC 6901）将 UI 结构与应用程序状态分离。这种分离是 A2UI 协议实现响应式更新的基础：

字面值（固定）：

{"text": {"literalString": "欢迎"}}

数据绑定值（响应式）：

{"text": {"path": "/user/name"}}

当 /user/name 更改时，组件会自动更新——无需重新生成组件。这种响应式绑定是 A2UI 协议的核心优势，展示了为什么 A2UI 对于动态、数据驱动的界面如此高效。A2UI 协议数据绑定系统使代理能够更新 UI 状态，而无需重新生成整个组件树。

为什么使用 A2UI 协议？

1. 安全性：声明式数据，而非代码

A2UI 协议传输声明式组件描述，而非可执行代码。代理从客户端的受信任目录请求组件，消除了代码执行风险。这使得 A2UI 非常适合代理跨信任边界运行的多代理系统。A2UI 协议的安全模型是其最重要的功能之一，能够从不信任的代理安全生成 UI。

💡 安全优势

与需要大量沙箱的基于 iframe 的解决方案不同，A2UI 组件由客户端使用自己的受信任组件进行渲染。代理从不执行代码——它只描述应该出现什么 UI。

2. 原生感觉和性能

A2UI 消除了 iframe 和视觉上的不连贯。客户端使用其原生 UI 框架（Angular、React、Flutter、SwiftUI）渲染 A2UI 消息，继承：

• 应用样式 - 完美的品牌一致性
• 可访问性 - 原生可访问性功能
• 性能 - 原生渲染性能

3. 跨平台可移植性

一个 A2UI 响应可在任何地方工作。相同的 JSON 消息在以下平台上渲染：

• Web：Lit、Angular、React（2026 年 Q1 推出）
• 移动：Flutter、SwiftUI、Jetpack Compose
• 桌面：Flutter、原生桌面框架

这种可移植性是 A2UI 协议的关键差异化因素。当您使用 A2UI 构建时，您同时为所有平台构建。A2UI 协议规范确保代理可以生成一次 UI，并在任何地方工作。

4. LLM 友好设计

A2UI 协议针对 LLM 生成进行了优化。这种 LLM 友好的设计使 A2UI 对 AI 代理应用程序如此有效：

• 平面组件列表 - 使用 A2UI 协议易于增量生成
• 基于 ID 的引用 - 易于纠正 A2UI 组件树中的错误
• 可流式传输格式 - 随着 A2UI 组件的生成进行渐进式渲染
• 结构化输出 - 自然适合 LLM 结构化生成能力，使 A2UI 成为 AI 代理的理想选择

5. 框架无关

A2UI 发送抽象组件树。客户端将这些映射到其原生小部件，实现：

• 框架选择 - 使用您首选的 UI 框架与 A2UI 协议
• 自定义组件 - 使用特定领域的小部件扩展 A2UI
• 设计系统集成 - 使用 A2UI 样式功能完美匹配您的品牌

A2UI 协议的框架无关性意味着您不会被锁定在任何特定的技术栈中。A2UI 可以与您选择的任何框架一起工作。

A2UI 架构和核心概念

三层架构

A2UI 协议将关注点分离为三个不同的层。这种架构分离是 A2UI 工作原理的基础：

1. UI 结构 - 通过 A2UI 协议中的 surfaceUpdate 定义组件
2. 应用程序状态 - 通过 A2UI 协议中的 dataModelUpdate 定义数据模型
3. 客户端渲染 - A2UI 消息的原生组件映射和渲染

这种分离实现了：

• 数据绑定 - 在 A2UI 中无需重新生成组件的响应式更新
• 可重用模板 - 一个模板，多个数据实例与 A2UI 协议
• 清晰的架构 - A2UI 系统中代理和客户端之间的清晰边界

A2UI 协议的三层架构确保 UI 结构、状态和渲染保持独立，使 A2UI 灵活且可维护。

A2UI 标准目录

A2UI 协议定义了一个按用途组织的标准组件目录。此 A2UI 标准目录提供了所有 A2UI 客户端必须支持的通用组件集：

A2UI 中的自定义组件

除了标准目录之外，A2UI 还支持特定领域需求的自定义组件。A2UI 协议扩展模型允许：

• 图表和可视化 - 使用 A2UI 自定义组件进行自定义数据显示
• 地图和位置 - 使用 A2UI 协议进行地理界面
• 专用小部件 - A2UI 应用程序中特定行业的组件

自定义组件从客户端的渲染器向代理进行广告，在保持 A2UI 协议安全性的同时实现扩展性。这使得 A2UI 可以适应任何领域或用例。

使用 A2UI 进行渐进式渲染

A2UI 协议支持流式传输和渐进式渲染。这种渐进式渲染能力是 A2UI 的关键功能：

{"surfaceUpdate":{"surfaceId":"main","components":[...]}}
{"dataModelUpdate":{"surfaceId":"main","contents":[...]}}
{"beginRendering":{"surfaceId":"main","root":"root-component"}}

用户看到 UI 实时构建，而不是等待完整响应——这是由 A2UI 实现的重大 UX 改进。A2UI 协议流式传输格式使这种渐进式渲染成为可能，允许 A2UI 客户端在生成 UI 时显示它。

Google 的 A2UI 实现

Google 从一开始就是 A2UI 的核心贡献者，A2UI 为 Google 的多个生产系统提供支持。Google 对 A2UI 协议的投资证明了该协议的生产就绪性和企业价值。Google 的 A2UI 实现展示了 A2UI 协议如何扩展以服务数百万用户：

Google Opal：AI 小程序平台

Opal 使数十万人能够使用自然语言构建、编辑和共享 AI 小程序。Opal 团队使用 A2UI 为其动态、生成式 UI 系统提供支持。

Opal 如何使用 A2UI：

• 快速原型设计 - 使用 A2UI 协议快速构建和测试新的 UI 模式
• 用户生成的应用程序 - 任何人都可以使用 A2UI 创建具有自定义 UI 的应用程序
• 动态界面 - UI 使用 A2UI 协议自动适应每个用例

Opal 的成功展示了 A2UI 在面向用户的应用程序中的强大功能。A2UI 协议使 Opal 能够为 AI 生成的应用程序提供灵活、安全的平台。

"A2UI 是我们工作的基础。它使我们能够灵活地让 AI 以新颖的方式驱动用户体验，而不受固定前端的限制。其声明式性质和安全性重点使我们能够快速安全地进行实验。"

— Dimitri Glazkov，Opal 团队首席工程师

Gemini Enterprise：自定义业务代理

Gemini Enterprise 使企业能够构建强大的自定义 AI 代理。A2UI 正在集成，以允许企业代理在业务应用程序中渲染丰富的交互式 UI。

Gemini Enterprise 中的 A2UI 用例：

• 数据输入表单 - 使用 A2UI 协议进行结构化数据收集的 AI 生成表单
• 审批仪表板 - 使用 A2UI 进行审查和审批流程的动态 UI
• 工作流自动化 - 使用 A2UI 协议为复杂任务提供分步界面
• 自定义企业 UI - 使用 A2UI 为特定行业需求定制界面

Gemini Enterprise 采用 A2UI 展示了 A2UI 协议如何实现企业级代理应用程序。A2UI 集成使 Gemini Enterprise 代理能够为业务工作流生成丰富的交互式 UI。

"我们的客户需要他们的代理不仅仅是回答问题；他们需要代理引导员工完成复杂的工作流。A2UI 将允许在 Gemini Enterprise 上构建的开发人员让他们的代理生成任何任务所需的动态、自定义 UI，从数据输入表单到审批仪表板，大大加速工作流自动化。"

— Fred Jabbour，Gemini Enterprise 产品经理

Flutter GenUI SDK：跨平台生成式 UI

Flutter GenUI SDK 使用 A2UI 作为底层协议，用于服务器端代理和 Flutter 应用程序之间的通信。当您使用 GenUI 时，您实际上是在使用 A2UI。

GenUI 从 A2UI 中受益：

• 跨平台支持 - 使用 A2UI 协议在 iOS、Android、Web、桌面上使用相同的代理
• 原生性能 - 使用 A2UI 在每个平台上原生渲染 Flutter 小部件
• 品牌一致性 - 通过 A2UI 协议使 UI 匹配您的应用设计系统
• 服务器驱动的 UI - 使用 A2UI 代理控制显示的内容，无需应用更新

Flutter GenUI SDK 使用 A2UI 展示了 A2UI 协议如何实现跨平台生成式 UI。A2UI 集成使 GenUI 成为构建 AI 驱动的 Flutter 应用程序的强大工具。

"我们的开发人员选择 Flutter 是因为它让他们能够快速创建在每个平台上都感觉良好的表达力强、品牌丰富、自定义的设计系统。A2UI 非常适合 Flutter 的 GenUI SDK，因为它确保每个平台上的每个用户都能获得高质量的原生感觉体验。"

— Vijay Menon，Dart & Flutter 工程总监

Google 的内部代理采用

随着 Google 在公司范围内采用 AI，A2UI 为 AI 代理提供了一种标准化的方式来交换用户界面，而不仅仅是文本。Google 内部使用 A2UI 协议展示了其在大规模代理系统中的价值：

• 多代理工作流 - 多个代理使用 A2UI 协议为同一表面做出贡献
• 远程代理支持 - 在不同服务上运行的代理可以通过 A2UI 提供 UI
• 标准化 - 跨团队的通用 A2UI 协议减少了集成开销
• 外部暴露 - 内部代理可以轻松使用 A2UI 对外暴露（例如，Gemini Enterprise）

Google 内部采用 A2UI 展示了 A2UI 协议如何实现跨不同代理系统的标准化和互操作性。A2UI 方法允许 Google 团队构建无缝协作的代理。

"就像 A2A 让任何代理无论平台如何都能相互对话一样，A2UI 标准化了用户界面层，并通过编排器支持远程代理用例。这对内部团队来说非常强大，使他们能够快速开发代理，其中丰富的用户界面是常态，而不是例外。随着 Google 进一步推进生成式 UI，A2UI 为在任何客户端上渲染的服务器驱动 UI 提供了完美的平台。"

— James Wren，AI Powered Google 高级工程师

A2UI vs. 其他代理 UI 解决方案

A2UI vs. AG UI / CopilotKit

AG UI / CopilotKit 提供了一个全面的框架，用于构建具有零日 A2UI 兼容性的代理应用程序。

它们如何协同工作：

• AG UI 擅长在自定义前端和专用代理之间创建高带宽连接
• A2UI 支持从第三方代理渲染动态 UI
• 组合：开发人员获得 AG UI 的状态同步以及 A2UI 渲染以实现多代理支持

何时直接使用 A2UI：

• 构建跨信任边界的多代理平台
• 需要代理到 UI 通信的标准协议
• 需要 React 之外的跨平台支持

何时将 AG UI 与 A2UI 一起使用：

• 构建全栈 React 应用程序
• 需要状态同步和聊天历史管理
• 希望与现有 React 代码库无缝集成

A2UI vs. MCP Apps

模型上下文协议 (MCP) Apps 将 UI 视为资源（通过 ui:// URI 访问），在沙箱 iframe 中渲染预构建的 HTML 内容。

A2UI 的不同之处：

• A2UI 采用"原生优先"方法——代理发送原生组件的蓝图
• A2UI UI 完美继承主机应用的样式和可访问性
• A2UI 消息轻量级，编排代理可以理解
• A2UI 实现更好的多代理协作

何时使用 A2UI：

• 需要与主机应用样式进行原生 UI 集成
• 构建带有编排器的多代理系统
• 需要跨平台一致性

何时使用 MCP Apps：

• 需要在沙箱 iframe 中完全隔离 UI
• 预构建的 HTML 界面足够
• 仅在 MCP 生态系统内工作

A2UI vs. 平台特定解决方案

像 OpenAI ChatKit 这样的工具在特定生态系统内提供高度集成的体验来部署代理。

A2UI 优势：

• 框架无关 - 适用于 Web、Flutter、原生移动
• 企业网格 - 专为 A2A 和跨信任边界通信而设计
• 客户端控制 - 客户端控制样式以实现视觉一致性
• 开源 - Apache 2.0 许可证，社区驱动

何时使用 A2UI：

• 在多个平台上构建自己的代理表面
• 需要跨不同代理平台的互操作性
• 需要品牌一致性和设计系统集成

A2UI 入门

路径 1：构建主机应用程序（前端）

将 A2UI 渲染集成到您现有的应用程序中，或构建新的代理驱动前端。

选择渲染器：

快速设置示例（Angular）：

npm install @a2ui/angular

通过 SSE、WebSockets 或 A2A 连接到代理消息，并自定义样式以匹配您的品牌。

路径 2：构建代理（后端）

创建一个为任何兼容客户端生成 A2UI 响应的代理。

选择您的框架：

在您的 LLM 提示中包含 A2UI 模式，生成 JSONL 消息，并通过 SSE、WebSockets 或 A2A 流式传输到客户端。

路径 3：使用现有框架

通过内置支持的框架使用 A2UI：

• AG UI / CopilotKit - 具有 A2UI 渲染的全栈 React 框架
• Flutter GenUI SDK - 跨平台生成式 UI（内部使用 A2UI）

A2UI 开发最佳实践

1. 组件设计

✅ 应该：

• 使用描述性 ID："user-profile-card" 而不是 "c1"
• 保持层次结构浅层
• 使用数据绑定将结构与内容分离
• 使用模板重用组件

❌ 不应该：

• 使用深度嵌套的组件结构
• 硬编码应该数据绑定的值
• 创建过于特定于一个用例的组件

2. 数据绑定

✅ 应该：

• 使用细粒度更新——仅更新更改的路径
• 按域组织数据（用户、购物车、UI）
• 在发送前预计算显示值（货币、日期）

❌ 不应该：

• 当只有一个字段更改时更新整个数据模型
• 在同一路径中混合不相关的数据
• 发送需要格式化的原始数据

3. 消息流式传输

✅ 应该：

• 增量流式传输组件以实现渐进式渲染
• 在 dataModelUpdate 之前发送 surfaceUpdate
• 使用 beginRendering 通知 UI 准备就绪

❌ 不应该：

• 在发送任何消息之前等待完整响应
• 在组件定义之前发送数据更新
• 忘记通知渲染完成

4. 错误处理

✅ 应该：

• 跳过格式错误的消息并继续处理
• 为网络中断显示错误状态
• 允许代理在错误后重新发送或恢复

❌ 不应该：

• 因单个格式错误的消息而崩溃
• 在重新连接期间丢失用户上下文
• 忽略来自客户端的错误反馈

5. 性能优化

✅ 应该：

• 为 16ms 渲染周期批处理更新
• 使用差异仅更新更改的属性
• 进行细粒度的数据模型更新

❌ 不应该：

• 发送冗余的组件更新
• 当一个组件更改时更新整个表面
• 忽略客户端渲染能力

关于 A2UI 的常见问题

Q: 什么是 A2UI 协议？

A: A2UI 协议是一个声明式 UI 协议，使 AI 代理能够生成丰富的交互式用户界面。代理发送描述 UI 组件的 JSON 消息，客户端使用其原生 UI 框架进行渲染。A2UI 专为多代理系统设计，其中代理需要跨信任边界生成 UI，同时保持安全性和原生性能。

Q: A2UI 与发送 HTML 有何不同？

A: 与 HTML/JavaScript 方法不同，A2UI 协议传输声明式组件描述，而非可执行代码。客户端使用自己的受信任组件渲染 A2UI 消息，消除了安全风险。A2UI 还提供原生样式集成、跨平台可移植性，以及比基于 iframe 的 HTML 解决方案更好的性能。

Q: A2UI 仅适用于 Web 应用程序吗？

A: 不是。A2UI 专为跨平台使用而设计。相同的 A2UI 消息在 Web（Lit、Angular、React）、移动（Flutter、SwiftUI、Jetpack Compose）和桌面平台上渲染。这种可移植性是 A2UI 协议的核心优势。

Q: 我可以将自定义组件与 A2UI 一起使用吗？

A: 可以。A2UI 支持标准目录之外的自定义组件。客户端在其渲染器中注册自定义组件类型，代理可以将它们与标准组件一起使用。自定义组件通过成为客户端受信任目录的一部分来维护安全性。

Q: A2UI 如何处理实时更新？

A: A2UI 协议使用带有 JSON Pointer 路径的数据绑定。当应用程序状态通过 dataModelUpdate 更改时，绑定到这些路径的组件会自动更新，无需重新生成组件。这种响应式绑定实现了高效的实时更新。

Q: A2UI 支持哪些传输协议？

A: A2UI 消息可以通过任何传输协议传输：

• A2A 协议 - 用于多代理系统
• AG UI - 双向、实时通信
• SSE（服务器发送事件） - 单向流式传输
• WebSockets - 全双工通信
• REST - 请求-响应（可行但尚不可用）

Q: A2UI 是开源的吗？

A: 是的。A2UI 在 Apache 2.0 许可证下开源。Google 一直是核心贡献者，该项目欢迎社区贡献。您可以在 GitHub 上找到源代码并进行贡献。

Q: Google 如何使用 A2UI？

A: Google 在生产系统中使用 A2UI，包括：

• Opal - 为数十万用户提供服务的 AI 小程序平台
• Gemini Enterprise - 具有丰富 UI 的自定义业务代理
• Flutter GenUI SDK - 跨平台生成式 UI 框架
• 内部代理系统 - 跨 Google 团队的标准化 UI 协议

Q: 我可以在现有的 React 应用程序中使用 A2UI 吗？

A: 可以，有两种方式：

1. AG UI / CopilotKit - 具有内置 A2UI 支持的全栈 React 框架
2. React Renderer - 原生 React 渲染器，2026 年 Q1 推出

Q: 是什么使 A2UI 适合 LLM？

A: A2UI 协议使用平面邻接表模型而不是嵌套树，使 LLM 更容易增量生成。组件通过简单的 ID 标识，错误易于纠正，格式支持流式传输以实现渐进式渲染。

结论和下一步

A2UI 协议代表了 AI 代理生成用户界面方式的根本性转变。通过将 UI 结构与应用程序状态分离并使用声明式 JSON 消息，A2UI 实现了安全、原生、跨平台的 UI 生成，感觉与您的应用程序集成。A2UI 协议正在改变开发人员构建代理驱动应用程序的方式，Google 对 A2UI 的生产使用验证了其方法。

A2UI 的主要优势

1. 安全性 - 使用 A2UI 协议的声明式数据，无代码执行
2. 原生性能 - 通过 A2UI 使用客户端的 UI 框架进行渲染
3. 跨平台 - 一个 A2UI 协议，多个平台
4. LLM 友好 - 使用 A2UI 针对 AI 代理生成进行优化
5. 生产验证 - 使用 A2UI 协议为 Google 的 Opal、Gemini Enterprise 和 Flutter GenUI 提供支持

这些优势使 A2UI 成为构建代理驱动应用程序的首选协议。A2UI 协议以其他解决方案无法匹配的方式结合了安全性、性能和可移植性。

入门

对于前端开发人员：

• 选择支持 A2UI 协议的渲染器（Lit、Angular 或 Flutter GenUI）
• 为您的框架安装 A2UI 渲染器包
• 连接到代理消息并使用 A2UI 自定义样式

对于代理开发人员：

• 选择支持 A2UI 协议的框架（Python ADK、Node.js A2A SDK）
• 在 LLM 提示中包含 A2UI 模式以生成 A2UI 消息
• 使用 A2UI 协议生成 JSONL 消息并流式传输到客户端

对于平台构建者：

• 探索 A2UI 规范以了解 A2UI 协议详细信息
• 为 A2UI 构建自定义渲染器或扩展现有渲染器
• 为开源 A2UI 社区做出贡献

无论您的角色如何，开始使用 A2UI 协议都很简单。A2UI 生态系统为每个用例提供工具和文档。

资源

• 文档：A2UI Docs
• GitHub：google/A2UI
• 快速入门：尝试交互式演示
• 社区：加入讨论并分享您的项目

A2UI 的未来

随着 AI 代理变得更加强大和广泛，对标准化 UI 生成协议的需求也在增长。A2UI 协议有望成为代理驱动界面的标准，使新一代应用程序能够无缝生成丰富的交互式 UI，在每个平台上都感觉原生。Google 采用 A2UI 以及不断增长的 A2UI 生态系统展示了该协议的潜力。

无论您是在构建下一代 AI 驱动的应用程序、将代理集成到现有平台，还是创建新的代理编排系统，A2UI 都提供了协议、工具和社区，使代理驱动的 UI 成为现实。A2UI 协议是代理驱动界面未来的基础，现在是开始使用 A2UI 构建的时候了。

准备好使用 A2UI 构建了吗？ 从快速入门指南开始，或探索组件库以查看 A2UI 的实际应用。A2UI 协议已准备好用于生产，Google 使用 A2UI 的成功证明了其价值。加入 A2UI 社区，立即开始构建下一代代理驱动的应用程序。

A2UI 协议完整指南：使用 Google A2UI 构建代理驱动 UI（2025）