Google 于 2025 年 12 月正式推出 A2UI 协议（Agent-to-User Interface，智能体到用户界面协议），并在官方开发者博客上发布了介绍文章《Introducing A2UI: An open project for agent-driven interfaces》。
各路博主和大V也都有介绍，但很多和官网逻辑一样，只是正面描述这个协议有多么牛、多么先进，看完觉得好厉害，但不是很清楚这玩意的作用，到底是因为什么背景才要动态生成UI？和现在最火的Vibe Coding生成前端代码有什么区别？
所以找了组里前端大叔经过一段时间研究，整理了A2UI系列文章，完整介绍它在AI应用中出现的逻辑和对应场景，它的设计理念、有了A2UI以后对前端工程师的影响，以及它与Vibe Coding的区别、与AG-UI的区别、与开发框架的关系等，最后分享一个真实的案例验证过程。
引言：从Chatbox到智能界面，AI应用形态的演进与困境
先回顾一下AI应用界面的演进史
• 第一阶段：对话盒子（Chatbox）时代
早期的AI助手，无论是豆包还是千问，大多被限制在一个简单的对话框中。用户输入文字，AI返回文字或预设的卡片。界面是静态的、预定义的，交互形式单一。
• 第二阶段：定制化插件与固定面板
随着Copilot、ChatGPT插件的出现，AI开始拥有专属的UI区域。例如，代码助手能在IDE侧边栏显示补全建议，设计工具能生成固定的调整面板。但这些界面仍然是开发人员预先编写好的，只是根据上下文显示不同内容。
• 第三阶段：动态界面生成的萌芽
现在我们正进入最激动人心的阶段：用户用自然语言描述需求，AI实时生成完整的、可交互的界面。
想象这些场景：
- 你对项目管理AI说：“创建一个下周团队冲刺计划看板，包含任务卡片、负责人标签和燃尽图。”
- 对数据分析AI说：“给我展示上季度销售Top 5产品的对比柱状图，旁边加上趋势预测线。”
- 对个人助手AI说：“我要订今晚7点两人位的意大利餐厅，显示评分、价格和可预订时段。”
在这些场景中，用户需要的不仅仅是AI的回答，而是要一个完整的交互界面，针对这种场景，目前有以下两种主流实现方式。
• 方案一：传统深度定制开发（成本太高）
当前绝大多数企业在尝试在产品中加入AI功能时，所采用的最普遍、最直接的模式：为每一个独立的AI功能点，开发一个或多个完整的、定制化的前端页面。
这种模式的运作逻辑是线性的：产品经理定义场景，设计师产出高保真原型，前端工程师“翻译”与实现，AI作为后端服务接入。在这种模式下，AI与UI的关系是割裂且固化的：
- 页面是“死”的：页面的整体结构、布局、组件间关系在开发完成时就已经冻结。用户看到的是一个静态的、预制的容器。
- AI是“填充物”：AI的作用仅限于向这个静态容器里“灌入”文本内容或JSON数据。如果用户的需求从“分析销售数据”变成“对比销售与市场数据”，前端需要重新设计、重新开发一个全新的页面。
- 创新成本高昂：每一个新的AI交互想法，无论是一个简单的表单还是一个复杂的仪表盘，都意味着从产品设计到前端开发的全链路投入。这导致AI功能的迭代速度极慢，试错成本极高。
本质上，这种“页面级定制开发”模式，是用工业时代“模具化生产”的思维，去应对信息时代“个性化、即时性”的AI需求。 它生产的是“功能”，而非“能力”。前端工程师的角色被牢牢锁定在为每一个确定性的功能，编写确定性的页面代码。
• 方案二：Agent动态生成前端代码（动态但危险）
更激进的做法是：让Agent直接动态生成HTML、CSS、JavaScript代码，然后返回到前端动态执行。这确实灵活，但在安全与工程化层面存在四大根本性挑战：
1）安全黑洞：信任边界的缺失
想象一下Agent返回了一段看似正常的HTML代码，但其中可能隐匿着精心伪装的恶意脚本（XSS攻击）。
<!-- AI可能生成这样的“危险”代码 -->
<div>
正常界面内容...
<script>
// 隐蔽的恶意脚本
fetch('/steal-cookie?data=' + document.cookie);
</script>
</div>
企业级应用对安全性要求极高，针对这种情况，要么是投入巨大精力进行沙箱隔离，要么就干脆禁止此类动态执行。这严重限制了AI在界面生成领域的应用潜力，安全是创新的前提。
2）一致性灾难：设计系统的崩坏
现代前端开发早已进入“组件化”和“设计系统”时代，以确保品牌体验的统一。然而，AI生成的代码是“野性”的。它可能使用随机的类名、不统一的间距系统、甚至是过时的交互模式。结果就是，生成的每个界面都像是一个独立的“视觉孤岛”，与产品整体风格格格不入，后期的视觉还原与维护成本极高。
3）维护噩梦：动态代码的不可调试性
“这个输入框为什么不验证？”、“列表翻页在哪里卡住了？”——当界面由AI动态生成时，传统的调试工具（如React DevTools, Vue DevTools）几乎失效。开发者难以追踪组件的生命周期、状态流向和事件冒泡。更糟糕的是，由于代码是动态拼接的，版本控制、Code Review和自动化测试这些现代软件工程的基石都变得异常困难。
4）体验割裂：等待的焦灼
当前的AI交互，通常是“用户提问 -> AI思考（数十秒）-> 返回完整答案或界面”。在等待AI“绞尽脑汁”生成完整JSON或代码的过程中，用户面对的是一个空白的屏幕。这种体验与我们所期待的即时、流畅、渐进式的数字体验背道而驰。我们无法实现那种“边思考边呈现”、“先出骨架再填血肉”的优雅交互。
A2UI核心设计理念：构建可信的AI-UI桥梁
正是在这样的背景下，Google开源的A2UI协议应运而生。它提出了一种革命性的思路：不让AI写“代码”，而是让AI写“图纸”。
A2UI定义了一种声明式的、结构化的UI描述语言（基于JSON）。AI的任务不再是生成可直接执行的HTML/CSS/JS，而是生成一份详细的“UI图纸说明书”。前端则持有一套安全可信的“渲染引擎”，负责将这份图纸安全地转化为真实界面。
这完美解决了前述困境：
- 安全可控：图纸只描述“要一个圆形按钮”，不包含“如何画圆”的潜在恶意代码。渲染引擎确保最终渲染的按钮是安全的。
- 无限灵活：图纸可以描述任何界面组合，只要渲染引擎支持的“基础图形”（组件）足够丰富。无需为每个业务场景预开发专用组件。
- 实时动态：图纸可以分片、流式传输，实现“边设计边渲染”的流畅体验。
理念一：安全第一 ， 从“执行代码”到“描述意图”
这是A2UI最根本的哲学转变。它不再让AI输出可直接执行的
技术实现示例（javascript）：
// AI生成的A2UI JSON（安全，仅描述）
{
"id": "submitBtn",
"component": {
"Button": { // 仅当‘Button’在Catalog中才渲染
"label": "提交",
"variant": "primary",
"onClick": { // 事件被定义为一个描述对象，而非函数
"action": "submitForm",
"payload": { "formId": "userInfo" }
}
}
}
}
// 前端Catalo g映射与安全渲染
const CATALOG = {
'Button': (descriptor) => {
const btn = document.createElement('button');
btn.textContent = descriptor.label;
btn.className = `btn btn-${descriptor.variant}`;
// 安全地绑定事件：将描述对象转为对本地安全函数的调用
btn.addEventListener('click', () => {
window.dispatchEvent(new CustomEvent('a2ui-action', {
detail: descriptor.onClick
}));
});
return btn;
}
};
通过这种方式，AI的“创作权”被限制在组合与配置预先审核过的安全积木上，彻底根除了执行任意恶意代码的可能。
理念二：流式生成 ， “边想边画”的智能体验
A2UI采用了创新的 “拍平”数据结构（Flattened Structure） 。传统的UI树（如React的虚拟DOM）是深度嵌套的，必须等待整棵树构建完成才能渲染。而A2UI将所有组件存储在一个扁平的字典中，通过id相互引用。
这带来了革命性的优势：
- 增量渲染：AI可以先发送{“id”: “header”, “component”: {“Header”: {…}}}，前端立即渲染一个页头；再发送{“id”: “loading”, “component”: {“Spinner”: {…}}}，在内容区显示加载动画。界面是“生长”出来的，而非“跳出来”的。
- 精准更新：只需更新特定id的组件描述，即可实现局部UI刷新，性能极高。
- 容错性更强：即使某个组件的描述有误或延迟，也不影响已渲染部分的稳定性。
理念三：协议驱动 ， 标准化的消息机制
A2UI定义了三种核心消息类型，构成UI生成的生命周期：
- surfaceUpdate：UI结构的“建筑师”。负责创建、更新或删除组件。类比于设计师在交付设计稿。
- dataModelUpdate：UI内容的“填充者”。负责向已定义的结构中注入数据。例如，将用户列表数据填充到表格组件。类比于后端API返回数据。
- beginRendering：UI展示的“发令枪”。当AI发送完初始的结构和数据后，发出此指令，前端才开始正式渲染第一帧。这确保了首屏的完整性，避免了布局抖动。
这套机制使得AI与前端之间的协作变得可预测、可调试、可监控。
前端开发者的华丽转身：从“码农”到“架构师”**
**
看到这里，很多前端同学都在担心自己的职业前景，我的看法是：A2UI不会让前端开发者失业，而是会重塑和提升我们的职业价值。
新角色一：企业级可信组件库的“首席建造师”
未来我们的核心竞争力，在于构建那些被录入A2UI Catalog的高阶业务组件。这些组件不仅是美观的Button、Input，更是富含业务逻辑的复合体：
- DataTableWithAI：一个不仅能展示数据，还能响应自然语言查询（如“找出销售额最高的产品”）的智能表格。
- WorkflowApprovalCard：一个集成了审批流状态、操作历史、附件预览和AI建议（如“根据历史，此类申请通常需要补充XX材料”）的复杂卡片。
- ConversationalForm：一个能将传统枯燥表单，转化为多轮对话式填写的交互容器。
你的工作，将从“实现产品经理画的原型”，升级为“设计并实现供AI使用的乐高积木”。
新角色二：人机交互与Agent流程的“编排大师”
当UI可以动态生成时，交互设计的概念被极大扩展。前端开发者需要深入思考：
- 如何设计引导语，让AI生成最符合用户当前意图的界面？
- 如何定义多步骤流程中，界面状态如何随Agent的“思考”而平滑过渡？
- 如何为视障用户设计一套可通过A2UI动态生成的、适配屏幕阅读器的界面描述规则？
新角色三：A2UI运行时与工具的“核心开发者”
你需要开发或深度定制：
- 高性能A2UI渲染引擎：如何最优化地解析JSON、 diff 变更、批量更新DOM？
- 跨平台渲染器：如何让同一份A2UI JSON描述，在Web、小程序、乃至原生App上都能渲染出体验一致的界面？
- 开发与调试工具链：A2UI版本的“Redux DevTools”，用于实时监控AI发送的消息流、可视化组件树、调试数据绑定。
展望：声控万物，手势成界——A2UI启发的未来
A2UI不仅是一项技术协议，更是一个关于未来的隐喻。我感觉它预示着一种更加自然、语境感知、动态适配的人机交互方式。
想象这些场景：
- 语音购物：你对客厅的智能助手说：“我想看看适合夏天徒步的鞋子，预算一千左右。” 面前的电视或AR眼镜上，立即通过A2UI流式生成一个包含筛选条件、商品卡片、对比功能的交互界面。
- 车内办公：你用手势在空中划出一个区域，说：“把昨晚写的项目周报放这里，再在旁边开一个今天的日程表。” 车窗或挡风玻璃上，两个并排的、可操作的UI模块即刻呈现。
- 无障碍设计：对于一位只能使用开关控制的用户，AI通过A2UI生成一个极简的、超大焦点区域的线性操作界面，每个操作都通过一次开关点击完成。
在这些场景中，A2UI协议就是那个将用户的意图（语音、手势、环境）转化为具体界面元素的无声翻译官和高效执行者。
结语：拥抱变化，定义未来
A2UI的出现，是前端工程化与AI能力融合的必然产物。它解开了束缚AI在UI领域施展拳脚的安全枷锁，也为我们前端开发者打开了通往更高价值赛道的大门。
我们正站在一个时代的拐点。
未来，最抢手的前端人才，或许不是那些最擅长手写CSS Hack的人，而是那些最懂如何设计让AI安全、高效地“造物”的规则的人。
改变已至，未来已来。
而A2UI，正是我们手中一张清晰的航海图。
备注：“动态UI生成”与“AI辅助编程”的区别
这里需要特别澄清一个常见误解：
- AI Coding：开发者通过AI Coding工具，生成静态的、一次性的业务代码（如一个React组件），经过Code Review、测试后部署，代码是固定的。它可以用于传统业务系统和网站的开发，不要求一定是AI类应用。
- 动态UI生成：AI根据每次不同的用户请求，实时生成不同的界面。代码/界面是动态的、一次性的、上下文相关的。它主要是针对AI类应用场景，服务端一定要包含LLM和智能体，才能够动态理解用户意图，动态决策如何展示结果。
前者是开发工具，后者是产品能力。前者生成的是要长期维护的源代码，后者生成的是即时消费的运行时界面，这是本质的不同。
本系列说明：完整介绍A2UI在AI应用中出现的逻辑和对应场景，它的设计理念、有了A2UI以后对前端工程师的影响，以及它与Vibe Coding的区别、与AG-UI的区别、与开发框架的关系等，最后分享一个真实的案例验证过程。本文是第一篇，敬请期待后续。
本文作者：一只大叔
本文原载：公众号“木昆子记录AI”
