A2UI：但 Google 把它写成协议后，模型和交互的最后一公里被彻底补全

说句有点酸但也很真实的话：A2UI 这条路，我相信不少人（包括你、也包括我）早就在脑子里推演过了——“别让模型吐代码，吐个 UI 描述，然后客户端用自己的组件去画”。这不是多么玄的发明，甚至有点像常识。

其实，我不太喜欢 Google 的材料设计，丑死了

其实，我不太喜欢 Google 的材料设计，丑死了

我一直喜欢的是 shadcn 的这套风格

图片

我前期实现的大体思路也是基于 json 去描述 UI 该长什么样子，然后结合数据。渲染出界面.

可现实就是这么不讲道理：当它停留在“我们内部有个想法/有个实现”，外界不会把它当成标准；当它变成大厂公开的协议、仓库、文档、版本号，你会明显感觉到——认可度、传播速度、生态跟进，全部换挡了。你不是在羡慕它的技术，你是在羡慕它的“公信力杠杆”。

当然，不得不承认的是，Google 比咱想的确实更加全面。

人家甚至还提供了生产组件工具

图片

体验地址：

https://a2ui-composer.ag-ui.com/

先说结论：A2UI 不是“更好的 UI”，是“更容易被相信的 UI 方案”

A2UI 这类协议，厉害的点不在 UI 有多炫，而在它把一件很难说清的事，说清了：Agent 到底怎么把“可交互界面”交付给用户，而且还要跨端、跨团队、跨安全边界。

很多团队在 demo 阶段会走捷径：模型吐一段 HTML/React，前端直接渲染。爽是爽，但你心里清楚——越接近线上，越不敢这么玩。因为“让不受控输入生成并执行代码”这件事，安全、合规、审计、维护，全都是雷。

A2UI 的路线是：让 Agent 只输出“声明式描述”（数据），真正画 UI 的责任回到客户端；客户端只渲染你允许的组件，Agent 想象力再丰富也只能在你划的框里跳舞。

听起来普通？对，普通到你会说“我早就想过”。但它被写成协议后，普通就变成了可复制、可讨论、可合作的东西。

其实很关键的一点是：你缺的可能不是脑子，是扩音器

我见过太多类似的瞬间：

• 你脑子里有个靠谱方案，但你说出来像“个人观点”；
• 大厂写成 RFC/Spec/Repo，它就像“行业方向”。

这个差距不全是技术差距，而是组织能力差距：能不能把抽象概念落成一套清晰的结构、边界、术语、版本节奏，以及可用的参考实现。大厂做这件事，天然更容易被信任。

所以你的情绪我完全理解：不是服技术，是服“别人信他”。

但反过来，这也是机会——当方向被验证后，你可以更快把它用在自己的产品里，而且不用再跟同事争“这是不是歪门邪道”。大厂替你完成了“合理化”。

A2UI 的核心套路

别把它当成神秘协议，拆开看就三件事：

1）Agent 输出的是“意图”，不是实现细节

它不应该告诉你怎么布局每个像素、怎么写 CSS、怎么写事件回调代码。它只表达：我想要一个表单、一个列表、一组按钮，它们大概是什么层级关系、数据是什么、用户点了之后回传什么事件。

你会发现：这反而更贴合模型的强项——模型擅长决定“问什么、展示什么、下一步是什么”，不擅长当一个审美稳定的前端切图仔。

2）客户端握着组件白名单（catalog）

这是整个安全边界的核心：你允许哪些组件，允许哪些属性，允许哪些事件，全部由客户端决定。

这一步不酷，但它决定了你敢不敢上线。也是你把风险和责任牢牢握在手里的方式。

3）渲染器负责“翻译”

同一份描述，在 Web 上可以翻译成 React 组件，在移动端翻译成 Flutter/原生控件。协议只负责“讲清楚要什么”，不负责“长什么样”。

这点对你吐槽 Material 特别重要：A2UI 并不等于 Material。你完全可以用 shadcn/ui 去画——只要你的渲染器把抽象组件映射到 shadcn 的实现，视觉就跟着你的设计系统走。

我反而想泼个冷水：最容易翻车的不是协议，而是你怎么设计 catalog

很多人会犯一个“看起来很工程、其实很坑”的错误：把 catalog 做成低层控件超市。

给模型一堆 Button、Input、Row、Column、Spacer……然后让它自由发挥。结果就是：

• • UI 每次长得都不一样，像随机生成；
• • 交互风格飘来飘去；
• • props 和事件一多，安全审计成本爆炸；
• • 你越放开，越难维护，越难统一。

更稳的做法反而“反直觉”：把 catalog 往上抽，给模型业务组件/场景组件。

比如你给它 AddressForm、UserPicker、RefundCard 这种组件。模型只负责选择组件、填数据、响应事件。UI 一致性会好很多，产品体验也更像“人做的”，而不是“模型拼的”。

这也是你能把“我早就想过”真正变成可落地方案的关键一步：不是想法，是边界。

我为什么还是有点不爽

不爽的点很简单：你明明知道这事不难，但你也知道“别人更愿意听 Google 的”。

承认这点其实挺解脱的。因为你不需要再用情绪对抗现实，你可以把情绪变成策略：

• 既然协议被认可，那就借势；
• 既然你不喜欢 Material，那就把渲染层换成你喜欢的设计系统；
• 既然你早就想过，那你更应该把它做得更“实用”，而不是更“宏大”。

讲白了：大厂提供共识，你提供体验和工程细节。

给你一个很现实的落地路线

如果你真想把这套东西用起来，而且不想陷入“大工程焦虑”，可以按这个顺序：

• 先做一个极小的 catalog（5～10 个组件），把端到端跑通：描述 → 渲染 → 事件回传 → UI 更新。
• props 一开始就收紧，尤其是任何可能注入富文本/HTML 的字段，别贪方便。
• 优先支持“增量更新”，别每次全量重绘；不然对话一长 UI 抖得像抽风。
• 早一点引入“场景组件”，把一致性、校验、埋点封装进去；这一步做完，你会突然感觉系统变稳了。