第十六节 Agent 界面技术选型深度对比：

A2UI vs AG-UI vs Vercel AI SDK

AI 智能体（AI Agent）领域的竞争焦点早已不止于选择哪个大模型或如何编排工具调用（Tool Use）。

🤜

2026 年，最激烈的战场转向了一个看似简单实则极难的问题：Agent 应该如何渲染用户界面？三种根本不同的方案应运而生——Google 的 A2UI 声明式协议（Declarative Protocol）、CopilotKit 的 AG-UI 事件传输协议（Event Transport Protocol）以及 Vercel 的 AI SDK RSC 生成式 UI（Generative UI）。

本文从架构层面进行严谨对比，帮助你为智能体工作流（Agentic Workflow）选择正确的技术基座。

核心摘要

核心要点

•

A2UI 是格式，AG-UI 是传输，Vercel AI SDK RSC 是框架——三者处于技术栈的不同层，并非直接竞争关系。

•

A2UI 在跨平台和安全性上胜出——数据与代码分离的设计使其成为唯一适用于不受信任多 Agent 场景的方案。

•

AG-UI 在实时通信上胜出——其事件流模型以低延迟处理文本增量、工具调用和状态同步。

•

Vercel AI SDK RSC 在 React 简洁性上胜出——但被官方标记为实验性，且仅限于 Next.js 服务端环境。

•

生态正在融合——CopilotKit 内置了 A2UI 集成，Vercel 发布了 json-renderer 概念验证，Oracle 的 Agent Spec 也引用了声明式 UI 模式。

Agent 界面问题

传统软件从应用状态渲染 UI。而 Agent 驱动的应用引入了一种根本不同的范式：由 Agent 自身决定展示什么 UI。天气 Agent 不只是返回文字——它生成温度图表。机票 Agent 不只是描述可选航班——它渲染一张可操作的选择卡片。

这意味着 Agent 需要一种方式来表达 UI 意图，这种方式比纯文本更丰富，但比执行任意代码更安全。三种方案各自反映了关于"渲染决策应该放在哪里"的不同哲学：

飞书文档 - 图片

如果你对更广泛的 Agent 架构还不太熟悉，可以阅读我们的 2026 AI Agent 框架对比，了解位于这些 UI 协议之上的后端编排层。

三种方案概览

A2UI：声明式 JSON 格式（载荷）

A2UI（Agent-to-UI）是一个规范（Specification）而非一个库。它定义了一种用 JSON 描述 UI 组件的格式。Agent 输出一份 JSON 蓝图，列出组件、属性及其关系。客户端渲染器根据这些描述将其映射为当前平台的原生控件。

json

代码块

JSON

{"type": "a2ui","components": [{"type": "card","title": "Flight SFO → JFK","children": [{ "type": "text", "content": "Departure: 2026-04-25 08:30" },{ "type": "button", "label": "Book Now", "action": "book_flight" }]}]}

关键设计决策：A2UI 将数据与代码分离。JSON 中不包含任何可执行逻辑。客户端自行决定如何用自己的组件库渲染 card 或 button。这使得 A2UI 在跨信任边界的场景下是安全的——远程 Agent 无法向你的应用注入代码。

AG-UI：事件传输协议（管道）

AG-UI（Agent-User Interaction Protocol）由 CopilotKit 创建，定义了消息在 Agent 后端与前端之间的流动方式。它是一个传输协议，拥有丰富的事件分类：文本增量（Text Delta）、工具调用（Tool Call）、状态更新（State Update）和生命周期事件（Lifecycle Event）。可以将其理解为"增强版 SSE"——专为 Agent 交互的流式、双向通信场景设计。

typescript

代码块

TypeScript

// AG-UI event typestype AGUIEvent =

| { type: "TEXT_MESSAGE_START"; messageId: string }

| { type: "TEXT_MESSAGE_CONTENT"; delta: string }

| { type: "TOOL_CALL_START"; toolCallId: string; name: string }

| { type: "TOOL_CALL_ARGS"; delta: string }

| { type: "STATE_DELTA"; delta: object }

| { type: "RUN_STARTED" | "RUN_FINISHED" };

AG-UI 不规定渲染什么，只规定如何传递渲染指令。这正是它与 A2UI 互补的原因——AG-UI 可以将 A2UI 载荷作为工具调用或自定义事件的内容进行传输。

Vercel AI SDK RSC：服务端渲染 React 组件（框架）

Vercel AI SDK RSC 采取了截然不同的路径。它不通过声明式描述 UI，而是由大模型触发工具调用来执行服务端函数，这些函数返回真正的 React Server Components（RSC）。RSC 流将序列化的 JSX 传输到客户端，客户端对其进行水合（Hydrate）以生成交互式组件。

typescript

代码块

TypeScript

// Vercel AI SDK RSC approachconst result = await streamUI({

model: openai("gpt-4o"),

messages,

tools: {

showFlightCard: {

parameters: z.object({ flight: z.string(), departure: z.string() }),

generate: async function* ({ flight, departure }) {

yield ;

const details = await getFlightDetails(flight);

return ;

});

这种方案很强大——但与 React、Next.js 和受信任的服务端环境深度耦合。大模型并不生成任意 JSX，而是从预定义的工具中进行选择。但其渲染管线要求在 Node.js RSC 环境中执行服务端代码，客户端必须是 React，且服务端必须受信任。

架构深度对比

三种方案的根本差异在于渲染决策发生在哪里，以及 UI 数据如何从 Agent 到达屏幕。

A2UI：传输无关的渲染

A2UI 的架构刻意做了分层。Agent 生成一份符合 A2UI 规范的 JSON 文档。这份 JSON 可以通过任何传输方式发送——HTTP、WebSocket、AG-UI 事件流，甚至 MCP 工具响应。客户端渲染器是一个平台特定的库，将 A2UI 组件类型映射为原生控件。

这种传输无关的设计意味着 A2UI 同样适用于 React Web 应用、基于 SwiftUI 的 iOS 原生应用或使用 Jetpack Compose 的 Android 应用。同一份 Agent 输出在任何平台都能原生渲染。更多细节可参阅我们的 A2UI 协议深度解析。

AG-UI：结构化事件流

AG-UI 定义了精确的事件生命周期。一次运行以 RUN_STARTED 开始，经过 TEXT_MESSAGE_* 和 TOOL_CALL_* 事件，包含用于共享状态同步的 STATE_DELTA，最终以 RUN_FINISHED 结束。这种结构为前端提供了对渐进式渲染、加载状态和错误处理的细粒度控制。

该协议同时支持服务端到客户端的流式推送和客户端到服务端的消息（用户中断、确认），实现了真正的双向通信。这对于需要人工介入的智能体工作流至关重要——用户可能需要审批工具执行或在流式过程中提供输入。

Vercel RSC：服务端组件生成

Vercel 的方案利用 React Server Components 模糊了数据获取与渲染之间的边界。当大模型调用工具时，对应的服务端函数可以访问数据库、API 和密钥，然后返回完全渲染好的组件。客户端接收到序列化的 React 树，无需原始数据即可完成水合。

对于单服务器架构而言，这很优雅。但它带来了紧耦合：渲染逻辑必须在 Node.js RSC 环境中执行，客户端必须是 React，服务端必须受信任（因为它会根据大模型的工具调用执行任意代码）。

全维度对比

安全性分析

安全性是三种方案差异最大的维度。在 Agent 日益自主化、多 Agent 系统逐渐成为标配的背景下，核心问题是：一个恶意或被入侵的 Agent 能对你的 UI 做什么？

A2UI：数据与代码分离

A2UI 的安全模型是结构性的。JSON 载荷只包含组件描述（数据），绝不包含可执行代码。客户端渲染器拥有一个有限的组件类型目录。如果 Agent 发出 { "type": "evil_script", "code": "..." }，渲染器会直接忽略它。

这使得 A2UI 成为唯一可以安全渲染来自不受信任的远程 Agent UI 的方案。在通过 A2A（Agent-to-Agent）通信编排的多 Agent 系统中，运行在第三方服务器上的子 Agent 可以向宿主应用发送 A2UI 载荷，完全没有代码注入风险。

code

代码块

Plain Text

Untrusted Agent → A2UI JSON → ✅ Safe: client ignores unknown types

Untrusted Agent → Vercel RSC → ❌ Not applicable: requires server trust

Untrusted Agent → AG-UI Events → ⚠️ Safe if app code validates events

Vercel AI SDK RSC：信任服务端

Vercel RSC 的安全假设是服务端受信任。工具函数在服务端执行代码、访问密钥并返回已渲染的组件。当你控制服务器时这是安全的——但这意味着你无法渲染来自不完全信任的 Agent 的 UI。

AG-UI：信任应用代码

AG-UI 的安全性取决于解释事件的应用代码。协议本身只是传输层——它不强制规定 TOOL_CALL 事件到达时应该做什么。如果应用盲目执行来自不受信任 Agent 的工具调用，它就是脆弱的；如果应用进行校验和沙箱化处理，它就是安全的。

跨平台与多 Agent 支持

跨平台支持是 A2UI 架构优势最具决定性的地方。考虑一个多 Agent 旅行规划系统：

每个远程 Agent 产出 A2UI JSON。宿主 Agent 将它们组合成统一布局。平台特定的渲染器展示原生控件——card 在 React 中变成，在 SwiftUI 中变成 CardView，在 Jetpack Compose 中变成 Card 可组合函数。

试想用 Vercel RSC 实现同样的效果：你需要为每个 Agent 部署一个 Next.js 服务器，并且所有客户端都必须是 React。仅用 AG-UI 的话，你需要自行定义 UI 格式。A2UI 格式 + AG-UI 传输 + 原生渲染器的组合，正是生态正在收敛的架构方向。

互补性洞察：A2UI + AG-UI

最重要的认知是：A2UI 和 AG-UI 不是竞争对手。它们解决的是不同层面的问题：

CopilotKit 第一时间认识到了这一点，并提供了一流的 A2UI 集成。你可以直接创建一个同时使用两者的项目：

bash

代码块

Bash

npx copilotkit@latest create my-app --framework a2ui

组合架构如下所示：

在这个架构中，Agent 将 A2UI JSON 作为工具调用的参数发出。AG-UI 以流式增量的方式将工具调用事件传输到前端。前端提取 A2UI 载荷并传递给平台特定的渲染器。用户交互通过 AG-UI 事件反向传回 Agent。

这不是理论构想——这正是 CopilotKit 的 A2UI 集成在生产中的工作方式。

如何选择？

选择 A2UI 的场景：

•

需要跨平台渲染（Web + 移动端 + 桌面端）

•

运行在多 Agent 环境中，Agent 来自不同的信任域

•

安全性至上——不能允许远程 Agent 执行代码

•

需要面向未来的格式，因为生态正在向标准收敛

•

正在构建托管第三方 Agent 的平台

选择 AG-UI 的场景：

•

需要 Agent 与前端之间的实时双向通信

•

已经在使用 CopilotKit，需要结构化的事件处理

•

应用需要 Agent 与 UI 之间的共享状态同步

•

需要人工介入控制（审批、拒绝、中断）

•

需要一个后端框架无关的传输层

选择 Vercel AI SDK（UI，非 RSC）的场景：

•

完全在 Next.js/React 中构建

•

只有单个 Agent 且服务端受信任

•

追求最快的 demo 交付速度，样板代码最少

•

UI 需求简单（聊天 + 少量自定义组件）

•

需要生产稳定性（AI SDK UI 是稳定版；RSC 是实验性的）

选择 A2UI + AG-UI 的场景：

•

正在构建具有丰富 UI 的生产级多 Agent 系统

•

同时需要跨平台渲染和实时流式传输

•

追求架构最合理的关注点分离

•

面向企业级场景，安全审计不可或缺

在开发过程中验证 Agent 的 JSON 输出是否符合 A2UI Schema 时，JSON 格式化工具可以帮助你检查和调试载荷。对于通过 AG-UI 事件流传输的数据，JSON Diff 工具可用于对比不同事件之间的状态增量。

生态融合趋势

Agent UI 领域正在快速融合。多个信号表明 A2UI 正在成为通用格式标准：

Vercel 的 json-renderer 概念验证。 Vercel 发布了一个概念验证项目，使用 Zod Schema 进行类型安全校验来渲染 A2UI 组件目录。这表明即使在 React 生态内部，声明式 JSON 格式也有其价值——尤其是对于大模型生成的 UI，结构化输出比自由形式的 JSX 更可靠。

CopilotKit 的 A2UI 集成。 CopilotKit 没有将 A2UI 视为 AG-UI 的竞争对手，而是提供了一流的集成支持，用生产代码验证了互补性的命题。

Oracle Agent Spec。 Oracle 的 Agent 规范引用了与 A2UI 兼容的声明式 UI 模式，释放出企业级采用声明式方案的信号。

AWS Bedrock AgentCore。 Amazon 的 AgentCore 基础设施支持多种 Agent 协议，其设计是 UI 格式无关的——天然适合 A2UI 的传输无关设计。

Google 的支持。 A2UI 源自 Google 的 DeepMind 和 Flutter 团队，在 A2A（Agent-to-Agent）协议规范中有交叉引用。Google 的多平台基因（Android、Web、Flutter、Fuchsia）使跨平台 UI 格式成为其战略优先事项。

趋势已经明朗：A2UI 作为格式标准，AG-UI 作为传输选项之一，平台特定渲染器负责最后一公里。Vercel AI SDK 大概率会原生支持 A2UI，而非继续推进 React 独占方案。

要深入了解 MCP 如何作为这些 UI 协议之下的工具与上下文层融入这个不断演进的生态，请参阅我们的 MCP 协议完整指南。

常见问题 (FAQ)

A2UI 和 AG-UI 有什么区别？

A2UI 是声明式 UI 格式——定义渲染什么（使用 JSON 组件描述）。AG-UI 是基于事件的传输协议——定义如何传递消息（Agent 后端与前端之间）。二者互补：AG-UI 可以将 A2UI 载荷作为工具调用参数承载。A2UI 专注于跨平台原生渲染和通过数据与代码分离实现的安全性，AG-UI 则专注于实时双向通信，包括文本流、工具调用和状态同步。

生成式 UI 应该选 A2UI 还是 Vercel AI SDK？

如果需要跨平台支持（Web、移动端、桌面端）、多 Agent 场景或跨信任边界的安全性，选 A2UI。如果完全在 Next.js/React 中构建且追求最简集成，选 Vercel AI SDK RSC。注意 Vercel 将 AI SDK RSC 标记为实验性，并推荐 AI SDK UI 用于生产工作负载。对于 2026 年大多数新项目，A2UI 是更安全的长期选择。

A2UI 和 AG-UI 可以一起使用吗？

可以，二者本身就是互补设计。AG-UI 作为传输层（管道），A2UI 作为 UI 格式（载荷）。CopilotKit 已提供生产就绪的 A2UI 集成：

bash

代码块

Bash

npx copilotkit@latest create my-app --framework a2ui

这会创建一个使用 AG-UI 传输 A2UI 载荷到 React 渲染器的项目脚手架。

2026 年哪种 Agent UI 方案最适合生产环境？

对于需要跨平台、多 Agent 的生产部署，A2UI + AG-UI 传输是最稳健的选择。对于只使用 React 的单 Agent 应用，Vercel AI SDK UI（稳定版，非 RSC）更成熟且集成更简单。生态正在向 A2UI 作为通用格式标准收敛，因此现在投入 A2UI 能获得最佳的长期灵活性。

Vercel AI SDK 支持 A2UI 吗？

Vercel 已发布基于 Zod Schema 的 json-renderer 概念验证项目，支持 A2UI 组件目录。这尚未成为 SDK 的一级特性，但它释放了融合信号——即使 Vercel 也认可需要一个声明式 UI 格式来配合其服务端渲染方案。预计未来的 AI SDK 版本会提供更深度的集成。

总结

Agent UI 问题包含三个层面——格式、传输和渲染——三种主流方案各自解决了其中一个层面。A2UI 定义通用格式。AG-UI 定义实时传输。Vercel AI SDK RSC 提供 React 特定的渲染快捷方式。

对于构建生产级多 Agent 系统、需要跨平台和跨信任边界工作的团队，A2UI + AG-UI 是应当采用的架构。对于完全在 Next.js 中工作且只有单个受信任 Agent 的团队，Vercel AI SDK UI 仍然是阻力最小的路径——但请关注 A2UI 集成即将登陆 SDK。

融合正在发生。问题不在于哪种方案会赢——而在于生态多快能统一到结合三者优势的分层架构上。选择你的层，然后开始构建。