过去一年，AI 应用的 UI 正在变得越来越奇怪。

一边是大模型能力突飞猛进，一边却是满屏的对话框、气泡、Markdown。

你让 AI 帮你填表，它回你一段文字； 你让 AI 帮你选方案，它列一堆列表； 你让 AI 真正“做事”，最后还得人自己点、自己填、自己确认。

问题不在模型，而在 UI。

直到 Google 最近开源了一个东西，很多工程师才突然意识到：

原来 AI 和界面之间，一直缺一个“像 LSP 一样的协议层”。

这个东西，叫 A2UI。

一、为什么现在的 AI UI 本质上是“退化的”

现在大多数 AI 应用的交互模式，本质只有一种： 文本输入 → 文本输出。

即便你看到按钮、卡片、表格，那也往往是“前端工程师提前写死的 UI”，AI 只是填内容。

这会带来三个长期被忽略的问题。

第一，AI 不知道“界面是什么”。

它只能描述界面，却不能真正“构建界面”。

第二，跨端体验极其割裂。

Web 是一套，App 是一套，桌面端再一套，同一个 AI 能力，要被 UI 拆三次。

第三，也是最致命的：

AI 想参与复杂流程，但 UI 把它挡在了外面。

所以我们看到大量“看起来很聪明、用起来很累”的 AI 产品。

Google 显然不打算继续在这个状态里打补丁。

二、A2UI 到底是什么？

A2UI 是一个让 AI 用 JSON“声明界面语义”，而不是“生成界面代码”的协议。

注意这几个关键词： 既不是不是 HTML ，也不是 React ，当然不是 Flutter ，更加不是“让 AI 写前端”。

而是：用结构化 JSON 描述“这是什么界面”。

AI 只负责说清楚三件事：

这里有哪些组件

它们的层级关系是什么

用户操作后意味着什么

至于“怎么画出来”，完全交给客户端。

如果你是程序员，可以直接类比一个东西：

A2UI ≈ UI 层的 LSP（Language Server Protocol）

三、为什么说它像 LSP，而不是前端框架

在 LSP 出现之前，每个编辑器都要为每种语言单独适配。

LSP 出现之后：

语言服务器只关心“语义”

编辑器只关心“展示”

A2UI 做的是同一件事，只不过对象从“代码”变成了“界面”。

Agent 输出的，是协议级 JSON

客户端决定，用 Web、PC 还是移动端渲染 。

按钮在不同平台长得不一样，但“这是一个按钮”这件事是确定的

这带来的变化非常关键。

AI 第一次不需要关心 UI 技术栈

前端第一次不用担心 AI 输出“不可控代码”

产品第一次可以真正做到“一套智能，多端一致”

这不是优化，这是分层方式的改变。

四、为什么 Google 坚持用 JSON，而不是让 AI 写代码

原因只有一个词：可控性。

让 AI 生成 HTML / JS，本质上是执行外来代码

安全、稳定、可预测性全部失控

而 A2UI 的思路是：

客户端提前声明“我允许哪些组件存在” ，AI 只能在这个白名单里组合 ，任何未注册的能力，直接无效。

这意味你可以像维护 API 一样维护 UI 能力 ，意味着 AI 永远不可能“越权画界面” ，意味着企业级应用第一次敢把 UI 交给 Agent。

这也是为什么 A2UI 一开始就强调：

声明式无脚本无执行能力

它天生就是为生产环境设计的。

五、A2UI 真正影响的，不只是 UI

很多人看到 A2UI，第一反应是： “哦，又一个 UI 协议。”

但真正重要的，不在 UI，而在Agent 能力边界的变化。

当 AI 能直接“生成界面”时，意味着：

流程不再是： AI 建议 → 人理解 → 人操作

而是： AI 判断 → AI 生成操作界面 → 人只负责确认

你会发现，AI 不再只是“助手”，而是流程的第一作者。

六、A2UI 会不会成为事实标准？

短期看，它还很早，生态也不完整。

但中长期看，它踩中了一个几乎不可回避的趋势：

AI 应用一定会从“对话中心”走向“任务中心”。

而任务，一定需要结构化 UI。

无论最后是不是 A2UI 胜出，这一层协议都会出现。

Google 只是第一个把这件事摆到台面上的公司。

如果你是开发者，现在理解 A2UI， 不是为了立刻用它， 而是为了提前看懂：下一代 AI 应用，UI 是怎么被重新定义的。

总结

A2UI 不只是一个 UI 协议，它是在回答一个问题： 当 AI 真正开始“做事”，人类该如何与它协作？