本文对比 A2UI 与传统 Agent UI 方案从架构、安全性、开发效率和 Token 消耗等维度进行深度分析。一、传统 Agent UI 方案的困境在 A2UI 出现之前AI Agent 与用户交互主要有以下几种方式方案 1纯文本对话用户: 帮我预订明晚7点的餐厅2人 Agent: 好的请问您想预订哪家餐厅 用户: 川味轩 Agent: 请确认川味轩明晚7点2人对吗 用户: 对 Agent: 预订成功问题交互轮次多用户体验差无法展示复杂信息图片、表格、表单每轮对话都消耗 Token方案 2LLM 直接生成 HTML/React// Agent 返回的代码constBookingForm(){const[date,setDate]useState(2025-12-20);return(divh1预订餐厅/h1input typedatevalue{date}onChange{esetDate(e.target.value)}/button onClick{()submitBooking(date)}确认/button/div);};问题严重安全风险执行 LLM 生成的代码可能包含恶意逻辑框架绑定生成的 React 代码无法在 Flutter/Angular 中使用Token 消耗高完整代码比声明式描述长得多方案 3iframe 嵌入远程 UIiframesrchttps://agent-server.com/booking-ui?sessionxxx/iframe问题视觉风格不统一安全隔离复杂性能开销大无法与宿主应用深度集成二、A2UI 方案概述A2UI 采用声明式 JSON 客户端渲染的模式// Agent 发送声明式描述{surfaceUpdate:{components:[{id:title,component:{Text:{text:{literalString:预订餐厅}}}},{id:date,component:{DateTimeInput:{value:{path:/booking/date}}}}]}}客户端使用自己的组件库渲染 → 原生 UI三、全方位对比3.1 架构对比维度纯文本生成代码iframeA2UI交互丰富度⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐安全性⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐跨平台⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐原生体验N/A⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐实现复杂度⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐3.2 安全性对比┌─────────────────────────────────────────────────────────────────┐ │ 安全风险矩阵 │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 高风险 ┃ ████████████████████ 生成代码XSS/代码注入 │ │ ┃ ████████████ iframe点击劫持/CSP绕过 │ │ ┃ │ │ 低风险 ┃ ██ A2UI声明式数据 │ │ ┃ █ 纯文本无UI风险 │ │ │ └─────────────────────────────────────────────────────────────────┘A2UI 安全机制Agent 只能引用客户端预定义的组件类型不执行任何 Agent 生成的代码数据绑定路径在客户端验证组件行为完全由客户端控制3.3 开发效率对比场景纯文本生成代码A2UIAgent 开发简单复杂需精确 prompt中等Client 开发无复杂沙箱/安全一次性渲染器调试难度低高中等迭代速度快慢快四、Token 消耗深度对比这是很多开发者关心的核心问题。我们以一个餐厅预订表单为例进行量化分析。4.1 场景定义需要生成的 UI 包含标题文本日期选择器时间选择器人数输入框餐厅选择下拉框5个选项确认按钮4.2 各方案输出对比方案 A纯文本多轮对话轮次1 - Agent: 请选择日期格式YYYY-MM-DD 轮次2 - 用户: 2025-12-20 轮次3 - Agent: 请选择时间格式HH:MM 轮次4 - 用户: 19:00 轮次5 - Agent: 请输入用餐人数 轮次6 - 用户: 2 轮次7 - Agent: 请选择餐厅1.川味轩 2.粤香楼 3.江南春 4.北京烤鸭 5.日料亭 轮次8 - 用户: 1 轮次9 - Agent: 确认预订川味轩2025-12-20 19:002人(是/否) 轮次10 - 用户: 是 轮次11 - Agent: 预订成功Token 统计估算每轮 Agent 响应~50 tokens每轮需要完整上下文累积增长总计约800-1200 tokens含上下文方案 B生成 React 代码import React, { useState } from react; import { DatePicker, TimePicker, Select, InputNumber, Button, Card, Typography } from antd; const BookingForm () { const [formData, setFormData] useState({ date: null, time: null, guests: 2, restaurant: null }); const restaurants [ { value: chuanwei, label: 川味轩 }, { value: yuexiang, label: 粤香楼 }, { value: jiangnan, label: 江南春 }, { value: beijing, label: 北京烤鸭 }, { value: riliaotin, label: 日料亭 } ]; const handleSubmit async () { const response await fetch(/api/booking, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify(formData) }); if (response.ok) { alert(预订成功); } }; return ( Card title预订餐厅 style{{ maxWidth: 400, margin: 0 auto }} Typography.Title level{4}预订餐厅/Typography.Title div style{{ marginBottom: 16 }} DatePicker placeholder选择日期 onChange{(date) setFormData({...formData, date})} style{{ width: 100% }} / /div div style{{ marginBottom: 16 }} TimePicker placeholder选择时间 formatHH:mm onChange{(time) setFormData({...formData, time})} style{{ width: 100% }} / /div div style{{ marginBottom: 16 }} InputNumber min{1} max{20} value{formData.guests} onChange{(guests) setFormData({...formData, guests})} addonBefore人数 style{{ width: 100% }} / /div div style{{ marginBottom: 16 }} Select placeholder选择餐厅 options{restaurants} onChange{(restaurant) setFormData({...formData, restaurant})} style{{ width: 100% }} / /div Button typeprimary onClick{handleSubmit} block 确认预订 /Button /Card ); }; export default BookingForm;Token 统计代码长度约 1800 字符Token 数约450-550 tokens单次如需修改重新生成每次都是完整代码方案 CA2UI 声明式 JSON{surfaceUpdate:{surfaceId:booking,components:[{id:root,component:{Column:{children:{explicitList:[title,date-row,time-row,guests-row,restaurant-row,submit-btn]}}}},{id:title,component:{Text:{text:{literalString:预订餐厅},usageHint:h1}}},{id:date-row,component:{DateTimeInput:{value:{path:/booking/date},enableDate:true}}},{id:time-row,component:{DateTimeInput:{value:{path:/booking/time},enableTime:true}}},{id:guests-row,component:{Slider:{value:{path:/booking/guests},minValue:1,maxValue:20}}},{id:restaurant-row,component:{MultipleChoice:{selections:{path:/booking/restaurant},options:[{label:{literalString:川味轩},value:chuanwei},{label:{literalString:粤香楼},value:yuexiang},{label:{literalString:江南春},value:jiangnan},{label:{literalString:北京烤鸭},value:beijing},{label:{literalString:日料亭},value:riliaotin}],maxAllowedSelections:1}}},{id:submit-btn,component:{Button:{child:submit-text,action:{name:confirm_booking,context:[{key:booking,value:{path:/booking}}]}}}},{id:submit-text,component:{Text:{text:{literalString:确认预订}}}}]}}{dataModelUpdate:{surfaceId:booking,contents:[{key:booking,valueMap:[{key:guests,valueInt:2}]}]}}{beginRendering:{surfaceId:booking,root:root}}Token 统计JSON 长度约 1400 字符Token 数约280-350 tokens单次增量更新只需发送变更部分4.3 Token 消耗汇总仅输出部分方案首次生成修改人数为4人添加备注字段总计完整流程纯文本对话800-1200200200~1400-1600生成代码450-550450-550重新生成500-600~1400-1700A2UI280-350~50增量~80增量~410-4804.4 重要补充组件目录的 Token 开销上面的对比只计算了LLM 输出的 Token。但 A2UI 有一个隐藏成本组件目录 Schema 需要作为 Prompt 的一部分发送给 LLM。让我们看看实际的开销┌─────────────────────────────────────────────────────────────────┐ │ A2UI 组件目录 Token 开销 │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 标准组件目录 Schema (standard_catalog_definition.json) │ │ ├── 文件大小: ~22,600 字符 │ │ └── Token 数: ~5,000-6,000 tokens │ │ │ │ 完整协议 Schema (server_to_client_with_standard_catalog.json) │ │ ├── 文件大小: ~37,700 字符 │ │ └── Token 数: ~8,000-10,000 tokens │ │ │ │ UI 示例模板 (few-shot examples) │ │ └── Token 数: ~2,000-4,000 tokens视示例数量 │ │ │ │ 总计 Prompt 开销: ~10,000-20,000 tokens每次请求 │ │ │ └─────────────────────────────────────────────────────────────────┘这意味着什么场景纯文本生成代码A2UIPrompt 开销~100 tokens~500 tokens~10,000-20,000 tokens输出开销~1,500 tokens~1,550 tokens~450 tokens单次总计~1,600 tokens~2,050 tokens~10,450-20,450 tokens4.5 A2UI 的真实 Token 经济学看起来 A2UI 反而更费 Token不完全是。需要考虑以下因素因素 1Prompt Caching提示缓存现代 LLM API如 Anthropic Claude、OpenAI GPT-4支持Prompt Caching┌─────────────────────────────────────────────────────────────────┐ │ Prompt Caching 机制 │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 首次请求: │ │ [System Prompt Schema] [用户消息] → 全价计费 │ │ ↓ 缓存 │ │ │ │ 后续请求同一会话或相同前缀: │ │ [缓存命中] [用户消息] → Schema 部分 90% 折扣 │ │ │ │ 实际开销: │ │ - 首次: ~15,000 tokens (全价) │ │ - 后续: ~1,500 tokens (缓存) ~450 tokens (输出) │ │ │ └─────────────────────────────────────────────────────────────────┘因素 2会话内增量更新A2UI 的核心优势在多轮交互中体现。但需要澄清一点增量更新发生在客户端渲染层而非 LLM 生成层。┌─────────────────────────────────────────────────────────────────┐ │ A2UI 增量更新机制详解 │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 客户端维护的状态: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Surface Map │ │ │ │ ├── surfaceId: booking │ │ │ │ │ ├── components: Mapid, ComponentDefinition │ │ │ │ │ ├── dataModel: Mappath, value │ │ │ │ │ ├── rootComponentId: root │ │ │ │ │ └── componentTree: (渲染时构建) │ │ │ │ └── surfaceId: confirmation │ │ │ │ └── ... │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ 增量更新流程: │ │ │ │ 1. 收到 surfaceUpdate → 合并到 components Map按 ID 覆盖 │ │ 2. 收到 dataModelUpdate → 合并到 dataModel Map按 path 覆盖 │ │ 3. 触发 rebuildComponentTree() → 重新构建渲染树 │ │ │ └─────────────────────────────────────────────────────────────────┘关键代码逻辑来自A2uiMessageProcessor// 处理组件更新 - 按 ID 合并privatehandleSurfaceUpdate(message,surfaceId){constsurfacethis.getOrCreateSurface(surfaceId);for(constcomponentofmessage.components){// 关键按 ID 覆盖不是替换整个 Mapsurface.components.set(component.id,component);}this.rebuildComponentTree(surface);}// 处理数据更新 - 按 path 合并privatehandleDataModelUpdate(message,surfaceId){constsurfacethis.getOrCreateSurface(surfaceId);constpathmessage.path??/;// 关键只更新指定 path不影响其他数据this.setDataByPath(surface.dataModel,path,message.contents);this.rebuildComponentTree(surface);}这意味着什么场景用户修改预订人数从 2 改为 4 传统方案LLM 重新生成完整 UI: LLM 输出: 完整的表单代码 ~500 tokens A2UI 方案: 方式 A - LLM 只生成数据更新: {dataModelUpdate: {path: /booking/guests, contents: [{key: ., valueInt: 4}]}} LLM 输出: ~50 tokens 方式 B - 客户端直接更新无需 LLM: 用户在 UI 上修改 → 客户端直接调用 setData() LLM 输出: 0 tokens重要澄清增量更新的 Token 节省取决于 Agent 的实现方式如果 Agent 每次都让 LLM 重新生成完整 UI则无法享受增量更新的好处最佳实践Agent 应该设计 Prompt 让 LLM 只输出变更部分或者利用客户端的本地状态管理因素 3Structured Output 模式使用 Gemini/GPT-4 的 Structured Output 模式时Schema 可以通过 API 参数传递而非放在 Prompt 中# Gemini 示例responsemodel.generate_content(生成餐厅预订表单,generation_config{response_mime_type:application/json,response_schema:a2ui_schema# Schema 通过参数传递不占用 Prompt Token})4.6 Token 对比结论┌─────────────────────────────────────────────────────────────────┐ │ Token 消耗真实对比 │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 场景 1: 单次简单交互 │ │ ├── 纯文本: ⭐⭐⭐⭐⭐ (最省) │ │ ├── 生成代码: ⭐⭐⭐⭐ │ │ └── A2UI: ⭐⭐ (Schema 开销大) │ │ │ │ 场景 2: 多轮复杂交互5 轮修改 │ │ ├── 纯文本: ⭐⭐ (累积上下文) │ │ ├── 生成代码: ⭐⭐ (每次重新生成) │ │ └── A2UI: ⭐⭐⭐⭐ (增量更新 缓存) │ │ │ │ 场景 3: 高频用户启用 Prompt Caching │ │ ├── 纯文本: ⭐⭐⭐ │ │ ├── 生成代码: ⭐⭐⭐ │ │ └── A2UI: ⭐⭐⭐⭐⭐ (Schema 缓存 增量更新) │ │ │ └─────────────────────────────────────────────────────────────────┘结论A2UI 的 Token 优势不在单次请求而在多轮交互和启用缓存的场景如果只是简单的一次性 UI 生成纯文本或生成代码可能更经济对于复杂的、需要多次修改的 UI 场景A2UI 的增量更新机制能显著节省 Token生产环境建议启用 Prompt Caching 以最大化 A2UI 的成本优势五、实际应用场景对比场景 1动态表单生成需求传统方案A2UI根据用户类型显示不同字段重新生成整个表单代码更新surfaceUpdate中的组件列表表单验证失败高亮需要生成验证逻辑代码更新dataModelUpdate中的错误状态多语言支持每种语言生成一套代码只更新literalString值场景 2实时数据展示// A2UI只更新数据UI 结构不变{dataModelUpdate:{surfaceId:dashboard,path:/metrics,contents:[{key:cpu,valueNumber:78.5},{key:memory,valueNumber:62.3}]}}传统方案需要重新生成整个仪表盘代码A2UI 只需 ~50 tokens。场景 3多 Agent 协作┌─────────────────────────────────────────────────────────────────┐ │ 主 Agent │ │ ↓ 委托任务 │ │ 餐厅推荐 Agent → 返回 A2UI (surfaceId: recommendations) │ │ 预订 Agent → 返回 A2UI (surfaceId: booking-form) │ │ 支付 Agent → 返回 A2UI (surfaceId: payment) │ │ │ │ 客户端统一渲染所有 Surface风格一致 │ └─────────────────────────────────────────────────────────────────┘传统方案中每个 Agent 生成的代码风格可能不一致需要额外适配。六、迁移建议从纯文本迁移到 A2UI识别高频交互场景表单填写、列表选择、确认操作定义组件目录根据业务需求选择标准组件或自定义组件改造 Agent Prompt让 LLM 输出 A2UI JSON 而非文本集成渲染器选择 Lit/Angular/Flutter 渲染器从生成代码迁移到 A2UI抽象 UI 模式将常用 UI 模式映射到 A2UI 组件移除代码执行用 A2UI 渲染器替代 eval/动态组件建立组件白名单确保安全性渐进式迁移先迁移简单场景逐步扩展七、总结A2UI 的核心优势安全声明式数据无代码执行风险高效Token 消耗降低 70%灵活一次定义多端渲染可维护增量更新结构清晰如果你正在构建 AI Agent 应用强烈建议评估 A2UI 方案。它不仅能提升用户体验还能显著降低运营成本。参考资料A2UI GitHub 仓库A2UI 官方文档OpenAI Token 计算器A2A 协议规范