Affordable and efficient Sora video watermark removal. Sign up now and get 1 free credits!
A2A Protocol

A2UI 协议:2026 年代理驱动界面完整指南

MILO
Share
The A2UI Protocol: A 2026 Complete Guide to Agent-Driven Interfaces

A2UI 协议:2026 年代理驱动界面完整指南

🎯 核心要点(TL;DR)

  • 安全优先的生成式 UI: A2UI 是一个基于 JSON 的声明式协议,使 AI 代理能够在 Web、移动和桌面平台上生成丰富、交互式且安全的用户界面(UI)[1]。
  • 解决"聊天墙"问题: 它通过允许代理请求特定的 UI 组件(表单、按钮、图表)来收集输入或呈现复杂结果,弥合了对话式 AI 和结构化交互之间的差距,超越了笨拙的纯文本响应 [2]。
  • 解耦架构: 该协议严格分离了 UI 结构("什么",由代理生成)和 UI 实现("如何",由客户端的原生渲染器控制),确保安全性、品牌一致性和跨平台可移植性 [1] [5]。

目录

  1. 什么是 A2UI 以及它为什么重要?
    1. 定义代理到用户界面(A2UI)
    2. 为什么纯聊天会失败:"聊天墙"问题
  2. 核心理念:安全性、解耦和可移植性
    1. A2UI 如何实现安全性(数据与代码)
    2. A2UI 交互循环:发出、渲染、信号、推理
    3. A2UI 与 HTML/iFrames 对比:信任边界比较
  3. A2UI 在代理生态系统中的位置
    1. A2UI 与 AG-UI:互补层
    2. 实际经验:构建自定义渲染器
  4. 🤔 常见问题(FAQ)
  5. 结论和行动建议

什么是 A2UI 以及它为什么重要?

定义代理到用户界面(A2UI)

A2UI(代理到用户界面)协议是 Google 引入的一个开源规范,用于标准化 AI 代理如何传达其生成用户界面的意图 [1]。它被设计为一种"通用 UI 语言",代理可以"说"给任何客户端应用程序 [3]。

与代理可能输出原始 HTML 或依赖预构建静态 UI 的传统方法不同,A2UI 使用声明式 JSON 格式来描述所需的 UI 组件(例如,CardTextFieldButton)以及填充它们的数据 [4] [5]。托管代理的客户端应用程序然后使用其自己的原生组件集(例如,React 组件、Flutter 小部件)来渲染此 JSON 描述 [1]。

这种方法是一个关键的架构转变,将显示什么的责任移交给代理,同时将如何显示的控制权牢牢掌握在客户端应用程序手中。

为什么纯聊天会失败:"聊天墙"问题

代理系统通常在生成文本方面表现出色,但当任务需要结构化输入或复杂输出时,它们很快就会遇到一个称为**"聊天墙"**的限制 [2]。

例如,一个负责预订餐厅座位的代理通常会导致缓慢、容易出错的文本交换:"哪一天?" -> "什么时间?" -> "没有空位,试试另一个时间?" [1]。这种来回交流对用户来说效率低下且令人沮丧。

A2UI 通过允许代理在需要的确切时刻动态生成操作界面——一个带有日期选择器、时间选择器和提交按钮的简单表单——来解决这个问题 [2]。从纯对话界面到结构化交互界面的这种转变,定义了下一代代理驱动应用程序。

核心理念:安全性、解耦和可移植性

A2UI 的设计植根于三个核心原则,这些原则解决了构建跨不同平台和信任边界运行的多代理系统的挑战 [5]。

A2UI 如何实现安全性(数据与代码)

A2UI 最重要的创新是其安全优先的方法,这在来自不同、可能不受信任的组织协作的"多代理网格"中至关重要 [1]。

历史上,允许远程源渲染 UI 意味着发送可执行代码(HTML/JavaScript)并将其沙箱化在 iframe 中,这在视觉上是脱节的,并引入了安全复杂性 [1]。A2UI 通过成为声明式数据格式,而不是可执行代码来避免这种情况 [5]。

客户端应用程序维护一个**"受信任、预批准的 UI 组件目录"**(例如,CardButtonTextField)。代理只能请求从此目录中渲染组件。这种机制有助于降低 UI 注入和其他漏洞的风险,使代理的输出"像数据一样安全,但像代码一样富有表现力" [1] [4]。

A2UI 交互循环:发出、渲染、信号、推理

A2UI 引入了一个动态的、活跃的交互循环,它摆脱了传统聊天的静态请求-响应模型 [2]。此循环定义了代理和客户端之间的契约:

📊 实施流程

graph TD
    A[用户发送消息: Book a table] --> B(Agent Reasoning: Needs structured input);
    B --> C{Emit: A2UI JSON Message};
    C --> D[Renderer Client Receives JSON];
    D --> E[Render: Native UI Form Date Picker];
    E --> F[User Interact: Selects Time Clicks Book];
    F --> G{Signal: Typed userAction Event};
    G --> H[Agent Consumes Event and Reasons];
    H --> C;
    H --> I[Agent Responds with Text or New UI];
  1. 发出(Emit): 代理发送一个 JSONL 消息,描述所需的 UI 结构和数据绑定。
  2. 渲染(Render): 客户端的渲染器将抽象的 JSON 组件映射到原生小部件(例如,Flutter、React)并显示它们。
  3. 交互(Interact): 用户与渲染的 UI 交互(例如,点击按钮、填写表单)。
  4. 信号(Signal): 渲染器将交互作为类型化的 userAction 事件发送回代理,而不是自由格式的文本 [2]。
  5. 推理(Reason): 代理使用结构化事件并相应地更新 UI,重新启动循环。

A2UI 与 HTML/iFrames 对比:信任边界比较

A2UI 与远程 UI 渲染的旧方法之间的根本区别在于信任边界和控制 [3]。

特性 A2UI 协议 HTML/iFrames
数据格式 声明式 JSON/JSONL 命令式 HTML + CSS + JavaScript
安全性 :仅允许预批准的组件,无任意代码执行 [1] :本质上是远程代码执行,依赖沙箱(iFrame)[3]
跨平台性 :同一 JSON 可在 Web、移动、桌面上原生渲染 [5] :依赖浏览器引擎,难以实现原生外观和感觉 [1]
样式控制 完全由客户端控制:确保品牌一致性 [1] 难以控制:iFrame 内容通常与宿主应用视觉脱节 [1]
LLM 友好性 :JSONL 结构简单,易于 LLM 增量生成 [5] :生成复杂的、无错误的 HTML/CSS/JS 难度大 [3]

A2UI 在代理生态系统中的位置

A2UI 并非旨在取代现有的代理框架,而是作为可互操作的生成式 UI 响应的专门协议 [1]。它适合更广泛的代理通信标准生态系统。

A2UI 与 AG-UI:互补层

由 CopilotKit 开发的代理-用户交互协议(AG-UI)经常与 A2UI 一起讨论。它们是互补层,而不是竞争技术 [4]。

  • A2UI(UI 规范): 定义内容——描述 UI 组件及其布局的结构化数据。
  • AG-UI(传输协议): 定义运行时——轻量级、基于事件的协议,处理双向、实时通信,在代理和前端之间传输 A2UI 消息和用户操作 [4]。

在实践中,代理可能使用 A2UI 来描述 UI 意图,并使用 AG-UI 将该意图流式传输到客户端并接收用户的结构化响应 [4]。

实际经验:构建自定义渲染器

经验(E): 开发人员已经在采用 A2UI 的核心模式。即使在对所有框架的官方支持之前,声明式、代理生成的 UI 的概念已被证明是有价值的。

💡 专业提示

A2UI 的可扩展性: 协议的设计允许自定义组件。如果客户端需要专门的组件(例如,自定义图表或 Google Maps 组件),代理可以请求它,前提是客户端已在其受信任目录中注册了该组件 [1]。这对企业应用程序至关重要。

例如,一位开发人员基于 A2UI 模式实现了一个自定义 React 渲染器,以修复他们的 AI 购物代理 LogiCart [6]。代理根据用户意图动态切换 UI:"产品搜索"意图渲染比较表,而"DIY 项目"意图渲染交互式时间线/清单 [6]。这个实际应用展示了代理即时决定界面结构的能力。

⚠️ 注意

UX 一致性挑战: 开发社区提出的一个关键关注点是,在动态生成 UI 时保持一致的用户体验(UX)[4]。如果界面随着每次交互而剧烈变化,用户可能难以学习应用程序,这可能会阻碍"专家"用户的发展 [4]。开发人员必须确保其客户端渲染器强制执行强大的设计系统规则,以保持品牌和功能一致性。

🤔 常见问题(FAQ)

Q: A2UI 只是重新发明了 HTML 吗?

A: 不是。 虽然 A2UI 旨在实现跨平台 UI,但其核心目标是解决信任边界LLM 生成的问题 [3]。HTML 是一种命令式语言,包含可执行代码(JavaScript),这在多代理环境中存在巨大的安全风险。A2UI 是一种声明式数据格式(JSON),它仅描述 UI 的意图,而不是实现。客户端使用其原生、受信任的组件来渲染它,从而确保安全性、性能和原生外观 [1] [3]。

Q: A2UI 是否取代了现有的 UI 框架,如 React 或 Flutter?

A: 不会。 A2UI 是一个协议,而不是一个框架 [5]。它与现有的 UI 框架是互补的。React、Flutter、Angular 等框架仍然是构建客户端应用程序和 A2UI 渲染器的基础 [1] [5]。A2UI JSON 消息被发送到这些框架中运行的渲染器,渲染器负责将抽象的 A2UI 组件映射到具体的、原生或 Web 的 UI 组件 [5]。

结论和行动建议

A2UI 协议代表了代理应用程序演进的重要一步,提供了强大的 LLM 推理与结构化、交互式用户体验之间缺失的环节。通过优先考虑安全性、将代理的意图与客户端的实现解耦,以及采用可流式传输、LLM 友好的格式,A2UI 使开发人员能够超越"聊天墙",构建真正动态、跨平台的代理界面。

行动建议:

  1. 探索规范: 查看官方 A2UI 规范 以了解 JSONL 消息结构和组件模型 [5]。
  2. 实验渲染器: 如果您正在构建代理应用程序,请考虑为您选择的框架(React、Vue 等)实现自定义渲染器,以获得发出-渲染-信号-推理循环的实践经验 [6]。
  3. 集成传输协议: 研究 A2UI 如何与 AG-UI 或代理到代理(A2A)协议等传输协议集成,以处理动态 UI 更新所需的实时、双向通信 [4]。

参考文献

  • [1] Google A2UI Team. "Introducing A2UI: An open project for agent-driven interfaces." Google Developers Blog, Dec 15, 2025.
  • [2] #TheGenAIGirl. "A2UI: Understanding Agent-Driven Interfaces." Medium (Google Cloud), Dec 26, 2025.
  • [3] makeramen, codethief, et al. "A2UI: A Protocol for Agent-Driven Interfaces." Hacker News Discussion, Dec 16, 2025.
  • [4] pfthurley. "Google releases A2UI - How the new spec fits within the generative UI space." Reddit (r/AI_Agents), 18 days ago.
  • [5] A2UI.org. "A2UI Protocol v0.8 (Stable)." A2UI Specification.
  • [6] Equivalent_Fly_4683. "I implemented Google's new A2UI (Generative UI) pattern in React to fix my AI Shopping Agent." Reddit (r/SaaS), 15 days ago.
  • [7] CopilotKit. "Build with Google's new A2UI Spec: Agent User Interfaces with A2UI + AG-UI." CopilotKit Blog, Dec 17, 2025.

Related Articles

Explore more content related to this topic

A2A vs ACP Protocol Comparison Analysis Report

A2A (Agent2Agent Protocol) and ACP (Agent Communication Protocol) represent two mainstream technical approaches in AI multi-agent system communication: 'cross-platform interoperability' and 'local/edge autonomy' respectively. A2A, with its powerful cross-vendor interconnection capabilities and rich task collaboration mechanisms, has become the preferred choice for cloud-based and distributed multi-agent scenarios; while ACP, with its low-latency, local-first, cloud-independent characteristics, is suitable for privacy-sensitive, bandwidth-constrained, or edge computing environments. Both protocols have their own focus in protocol design, ecosystem construction, and standardization governance, and are expected to further converge in openness in the future. Developers are advised to choose the most suitable protocol stack based on actual business needs.

ACP
Read article