加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象你在做一款 AI 旅行助手。用户说"帮我订下周三去上海的三天行程"，Agent 很快把文本答复打了出来——一段markdown列表，三家酒店的价格对比，最后一句"需要我帮你预订吗？"。用户盯着屏幕，心里想的是：能不能直接把日期选择器、预算滑块、酒店对比卡片直接推到我面前？
这就是生成式 AI 的一个结构性尴尬。LLM 极其擅长生成文本和代码，但当 Agent 位于远程服务端、或者跨越了信任边界时，它很难直接向用户端交付一套可交互、够原生、且安全的界面。
过去的两种解法各有硬伤：受控方案要求开发者把每个组件都预先写好，Agent 只能在菜单里点菜，自定义能力被锁死；开放方案让 Agent 直接吐出 HTML/JS/Dart 代码塞进 iframe 沙箱，灵活是灵活了，但界面和设计系统脱节，而且执行的是模型写的代码，安全风险实在。
A2UI 想走的是中间那条路。
A2UI（Agent-to-User Interface）是 Google 于 2025 年 12 月开源的一套规范与库。它的核心主张只有一句：Agent 不发送代码，只发送描述 UI 意图的 JSON。
具体机制是这样的：客户端应用维护一份"可信组件目录"（Catalog），比如 Card、Button、TextField、Slider 这些预先审核过的组件；Agent 只能从目录里挑选并组装，不能凭空发明新组件。这样即使 Agent 来自第三方、甚至是恶意的，它能做的最坏的事情，也不过是"请给我一个按钮"——而不会是"请在你的页面里执行这段脚本"。
UI 结构被表达为一个扁平的组件列表，组件之间通过 ID 相互引用。这种设计对 LLM 极其友好：模型可以增量式地、一块一块地把 UI 吐出来，客户端边收边渲染，用户看到的是渐进式展开的界面，而不是一段长时间的空白等待。
架构上分为四步：生成（Agent 产出 A2UI JSON）→ 传输（经 A2A、AG-UI 等协议下发）→ 解析（客户端 Renderer 读取）→ 渲染（映射到本框架原生组件）。
上图是 A2UI Basic Catalog 中各类组件的实际渲染效果——同一份 JSON，客户端用自己的组件库画出来。
从 Agent 生成 JSON 到客户端渲染的完整链路，中间可插任意传输协议。
这是 A2UI 最有说服力的地方。同一份 A2UI 响应，可以渲染在：
@a2ui/web_core 核心库a2ui_flutter）、SwiftUI、Jetpack Compose它不是 iframe 套壳，而是真正调用宿主的原生组件——继承你的设计系统、你的无障碍语义、你的性能特性。
官方 Composer 工具：可视化拖拽组件、实时预览 A2UI 渲染结果。
对 AI 爱好者来说，最快的路径其实是看 demo：
Agent 动态生成计算器界面的过程。
多组件、有状态、增量更新的复杂案例。
对 AI 开发者，集成成本比想象的低：
# Web 端：装渲染器
npm install @a2ui/react @a2ui/web_core
# Agent 端：装 SDK
pip install a2ui-agent-sdk
然后让 LLM 以结构化输出产出 A2UI JSON，走 A2A / AG-UI 发给客户端即可。如果你的 Agent 框架已经支持 AG-UI（Google ADK、LangGraph、Mastra、Strands、CrewAI 都支持），接入几乎零成本。
但也要坦白说门槛所在：这是一个 monorepo，4687 个文件，横跨 TypeScript、Python、Dart、Swift、Kotlin 五门语言。你只想在 React 里用，就别去 clone 整个仓库——直接装 npm 包就好。反过来，如果你要做的是"纯 React 单聊天窗口、把工具结果渲染成自己的组件"这种轻量场景，A2UI 可能** overkill**了：官方 README 自己也承认"you may not need A2UI for a React-only chat"。它的价值在多平台复用、远程 Agent、跨信任边界时才真正显现。
规范仍在剧烈演进。 v0.8 是遗留版本，v0.9.1 是当前生产版本，v1.0 还是候选版本（Release Candidate）。Google 在博客里直言"Expect changes"。仓库里同时躺着 v0_8、v0_9、v0_9_1、v1_0 四套目录，连 Flutter 包都分 a2ui_flutter 和 example_v0_9 两套示例——对早期采用者是实实在在的心智负担。
它不是框架，是协议。 官方明确"A2UI is NOT a framework"。这意味着它不替你解决样式问题——客户端控制一切样式，服务端只有限的服务端样式能力。你想要一套精致的排版，还是得自己在客户端调。
生态碎片化风险。 社区渲染器（Vue、终端、CopilotKit 的版本）由第三方维护，版本兼容矩阵会随时间变得棘手。
性能开销在增量流式场景。 扁平组件列表 + ID 引用虽然对 LLM 友好，但对客户端渲染器来说，每次增量更新都要做一次 diff 和重建，比直接发 DOM 指令更重。
A2UI 的真正野心，是成为 Agent 交互层的"HTTP"——像 HTTP 之于 Web 页面那样，成为 AI 界面交换的通用语。
Google 内部已经在自家产品里使用 A2UI，包括 Gemini Enterprise 的对外 Agent 暴露。CopilotKit 基于 AG-UI 构建了完整的 A2UI 运行时，并提供 React、Angular、Vue、Slack 多端渲染器。AG-UI 官方 CLI 甚至提供一条命令：
npx create-ag-ui-app@latest
就能生成一个支持 A2UI 渲染的完整 Agent 应用脚手架。
17001 star、1373 fork、103 位贡献者、19 条 CI 工作流、Apache-2.0 协议——这个由 Google 背书、社区共同维护的标准，正把"生成式 UI"从各家自研的私有格式，推向一个可以互相通信的公共层。
可以预期的是：随着 MCP、A2A、AG-UI 三条传输线路的成熟，Agent 界面将像 API 一样被复用和组合。而 A2UI 在这里扮演的角色，是确保这份复用的安全性与原生感。
项目地址：https://github.com/a2ui-project/a2ui 官网：https://a2ui.org/ 许可：Apache-2.0 当前版本：v0.9.1（生产版）/ v1.0（RC）