上篇《A2UI初探：为什么前端不再需要手写UI代码了？》介绍了Google为啥推出A2UI协议，它与动态生成代码的区别，与Vibe Coding的差异，以及它的基本设计理念等。
本文是A2UI系列的第二篇，在AI生成UI这个新兴领域，各种协议、框架名词层出不穷，A2UI、AG-UI、CopilotKit常被混为一谈或错误比较，让开发者感到困惑。
本文将为你清晰勾勒出这片技术领域的“地图”与“经纬”。你会发现，它们并非互相替代的竞争对手，而是一套分工明确、协同作战的“技术栈组合拳”，共同构建起下一代AI应用的完整基石。
前端大叔经过一段时间研究，整理了A2UI系列文章，完整介绍它在AI应用中出现的逻辑和对应场景，它的设计理念、有了A2UI以后对前端工程师的影响，以及它与Vibe Coding的区别、与AG-UI的区别、与开发框架的关系等，最后分享一个真实的案例验证过程。
分层解构：AI应用的技术栈新范式
要理解这些技术，首先要建立分层思维。一个完整的、能生成动态UI的AI应用，通常包含以下几个层次：
• UI描述层 (What to Draw)：定义界面长什么样。规范组件、布局、样式和数据占位符。代表：A2UI， OpenJSON-UI。
• 通信与状态层 (How to Talk)：定义AI（Agent）与客户端（前端）如何对话。规范消息格式、事件流转、上下文同步。代表：AG-UI。
• 框架与运行时层 (How to Run)：提供开箱即用的SDK、工具和运行时环境，让开发者能快速集成上述协议。代表：CopilotKit。
• 基础设施层 (The Foundation)：包括大模型本身（GPT、Gemini、Claude）、工具调用协议、向量数据库等。代表：OpenAI API， MCP (Model Context Protocol)。
接下来我们深入剖析前面三层的典型代表。
A2UI深度剖析：UI描述层的“宪法”
现在，让我们从协议细节和生态对比的角度，更深入地审视A2UI。
A2UI协议的核心数据结构
一个A2UI描述文件，本质上是一个组件描述符（Component Descriptor）的数组。
每个描述符有三个关键部分：
- id: 全局唯一标识符，用于引用和更新。
- component: 组件类型和属性的具体定义。如 { "Button": { "label": "OK", "variant": "primary" } }。
- layout (可选): 描述该组件在父容器中的布局约束。
其精妙之处在于“引用”而非“嵌套”：
// 传统嵌套方式（非A2UI）：难以局部更新
{
"type":"Column",
"children":[
{
"type":"Text",
"content":"标题"
},
{
"type":"Row",// 要更新这个Row里的内容，必须替换整个Column
"children":[...]
}
]
}
// A2UI扁平引用方式：
[
{"id":"col1","component":{"Column":{"children":{"explicitList":["title","row1"]}}}},
{"id":"title","component":{"Text":{"text":"标题"}}},// 可独立更新
{"id":"row1","component":{"Row":{"children":{"explicitList":["..."]}}}}// 可独立更新
]
与OpenJSON-UI的对比
OpenAI曾提出过 OpenJSON-UI 的概念，两者目标相似，但设计哲学不同：
| 特性 | A2UI (Google) | OpenJSON-UI (OpenAI) |
|---|---|---|
| 设计重心 | 安全与流式生成。强调白名单组件和增量更新。 | 表达力与丰富性。旨在更细致地描述复杂UI状态和交互。 |
| 数据结构 | 扁平化引用。利于独立更新和流式传输。 | 可能更偏向嵌套。更贴近实际的UI树状结构，直观但更新粒度可能较粗。 |
| 组件模型 | 强类型化。组件类型和属性有严格约束。 | 可能更灵活。允许更多自定义组件和属性。 |
| 生态现状 | 已开源，与Google AI Studio、Gemini API集成紧密，有CopilotKit等实现。 | 更多是一个概念展示，未成为正式、开源的规范。 |
| 适用场景 | 对安全性、性能和实时性要求极高的企业级、生产级应用。 | 快速原型、对UI表现力要求极高、且安全环境可控的场景。 |
简单来说，A2UI更像“工业标准”，严谨可靠；OpenJSON-UI更像“概念艺术”，自由奔放。 目前看来，A2UI因其开源和明确的实施路径，在开发者社区中获得了更强的势头。
AG-UI深度剖析：通信层的“外交官”与“邮差”
如果A2UI是书写好的“信件内容”，那么AG-UI (Agent-User Interaction Protocol) 就是负责将这封信安全、准时、有序送达的邮政系统。
AG-UI解决的核心问题
在A2UI出现之前，AI与前端通信是“各显神通”的混乱状态：WebSocket消息格式自定义、REST轮询、Server-Sent Events……缺乏标准导致：
- 状态同步困难
- 错误处理不统一
- 难以实现断线重连和消息追溯
- 不同Agent和前端无法互通
AG-UI的目标就是标准化这条“通信管道”。
AG-UI协议的核心机制
- 双向事件流：定义了一套标准事件类型（如 session.update, ui.delta, user.action），让前端和Agent可以相互发送和理解这些事件。
- 会话与上下文管理：每个交互会话有唯一ID，消息携带上下文信息，确保多轮对话中UI状态的一致性。
- 流式传输支持：原生支持像打字机一样逐字输出文本，或像A2UI那样逐条输出UI组件描述。
- 安全与认证：规定了连接建立时的认证方式和消息的签名验证。
关键认知：AG-UI不关心负载内容
这是最重要的点。AG-UI规定信封的格式、邮票怎么贴、邮编怎么写，但不关心信封里装的是A2UI的JSON，还是纯文本，抑或是图片数据。它是一个传输容器。
// 一个通过AG-UI通道发送的A2UI消息示例
{
"type": "ui.delta", // AG-UI定义的事件类型
"session_id": "sess_123",
"payload": { // 载荷（Payload）可以是任何东西，这里装的是A2UI
"type": "surfaceUpdate", // A2UI定义的消息类型
"components": [...]
}
}
CopilotKit深度剖析：框架层的“瑞士军刀”
理解了A2UI（内容）和AG-UI（管道），CopilotKit的角色就非常清晰了：它是一套集大成的开源框架，将AG-UI协议具体实现，并集成了对A2UI等UI描述协议的原生支持，让开发者能“一站式”构建AI功能。
CopilotKit的四大核心模块
1. @copilotkit/react (前端SDK)：提供React Hooks（如useCopilotChat）和组件（如），让你几行代码就能在应用中嵌入一个可对话的AI助手界面，并自动处理与后端的AG-UI通信。2. @copilotkit/backend (后端SDK)：提供与前端对应的服务端代码，轻松将你的AI逻辑（如调用OpenAI API）接入AG-UI通信框架。3. A2UI渲染器与工具：CopilotKit内置了一个A2UI渲染引擎，并提供了强大的 A2UI Composer（composer.copilotkit.ai）在线工具，让你可以可视化地拖拽组件、编辑属性，实时生成A2UI JSON，极大降低了学习和使用A2UI的门槛。4. 工具调用与集成：方便你将外部API、数据库查询等功能，以“工具”的形式暴露给AI Agent调用。
为什么CopilotKit重要？
它极大地降低了集成AI功能的技术门槛和开发成本。没有它，开发者需要自己：
- 实现WebSocket连接管理
- 设计消息协议
- 处理会话状态
- 编写A2UI渲染器
- 集成工具调用链
而CopilotKit让你可以专注于两件事：你的业务逻辑和你的用户体验。
拥抱组合，而非选择
回到最初的问题：A2UI, AG-UI, CopilotKit，谁是未来？
成年人不做选择题，它们的组合体，才是未来。
- 当你需要定义UI时，你关注 A2UI。
- 当你需要建立通信时，你关注 AG-UI。
- 当你需要快速上手、全栈集成时，你使用 CopilotKit。
它们共同描绘了一个标准化、模块化、可互操作的AI应用开发未来。作为开发者，我们的最佳策略不是押注某一个，而是理解这一整套分层协议栈，从而能够灵活选用最合适的工具，构建出强大、安全、可维护的下一代智能应用。
在这个新世界里，最重要的技能将是“理解协议，并善用框架”。
本系列说明：完整介绍A2UI在AI应用中出现的逻辑和对应场景，它的设计理念、有了A2UI以后对前端工程师的影响，以及它与Vibe Coding的区别、与AG-UI的区别、与开发框架的关系等，最后分享一个真实的案例验证过程。本文是第二篇，敬请期待下一篇分享真实案例。
本文作者：一只大叔
本文原载：公众号“木昆子记录AI”
