研究截点：2026 年 8 月 6 日。 本报告将 Generative User Interface 译为“生成式用户界面”或“生成式界面”，简称 Gen UI。其严格含义不是“让模型写一次前端代码”，而是：系统根据当前任务、上下文、用户状态与可用工具，在设计时或运行时生成、选择、组合和持续更新交互界面。Google 的 A2UI 将其实现为代理发送声明式 UI 意图、客户端以可信原生组件渲染；AG-UI 负责代理与前端之间的双向事件流；MCP Apps 则通过 MCP 工具返回可在沙箱 iframe 中运行的交互应用。三者分别解决 界面描述、交互传输、工具与应用封装，目前正在形成互补而非相互替代的协议栈。

本研究的核心结论如下。

成熟度采用本报告统一尺度：M1 研究原型、M2 公开预览、M3 可用于受控生产、M4 已形成较成熟生产生态。成熟度是依据版本状态、官方支持、集成数量、兼容性和实际产品采用情况作出的分析估计，不等同于项目方承诺。

Gen UI 生态常把四种不同能力混为一谈。它们的数据流、风险和适用场景差异很大。

Vercel AI SDK 将工具调用结果映射为 React 等框架组件，适合“有限且可预测”的生成式界面；A2UI 让代理输出声明式 JSON，宿主使用自己的原生组件库呈现；MCP Apps 则允许工具声明 ui:// HTML 资源，由宿主在沙箱 iframe 内渲染并与工具双向通信。OpenTiny 和百度 COSUI 代表较有价值的中文开源路线：前者提供 Vue/Angular 双渲染器并兼容 OpenAI 风格接口，后者同时支持 Markdown 扩展协议和 JSON 动态协议，并覆盖移动 H5 与桌面端。

时间线上几个关键变化值得强调。A2UI 于 2025 年 12 月公开，至 2026 年 8 月当前稳定版本为 v0.9.1，v1.0 仍是候选版，项目明确标注为早期公开预览；AG-UI 已支持约 16 类标准事件，并与 LangGraph、Google ADK、Microsoft Agent Framework、CrewAI 等多种代理框架集成；MCP Apps 已形成规范、SDK 与多种参考应用，但不同宿主的支持范围仍不一致。

协议与互操作层

开发框架与参考实现

横向看，A2UI 与 json-render 解决“模型如何描述界面”，AG-UI 解决“代理运行如何与界面同步”，MCP/MCP Apps 解决“如何连接业务能力以及如何交付复杂微应用”。对大型系统而言，不宜强行选择单一协议，而应将三层解耦。Google 也已公开讨论 A2UI 与 MCP Apps 的混合模式：声明式组件负责原生体验，iframe 应用负责复杂、状态密集或第三方界面。

Gen UI 的模型层主要由四类技术组合而成。第一类是通用 LLM 的结构化输出和工具调用；第二类是能理解截图、设计稿和运行结果的多模态模型；第三类是针对 UI 协议、组件语义和交互状态专门微调的模型；第四类是通过编译器、渲染截图、多模态判别器或人工偏好执行迭代优化的生成—验证循环。UICoder 使用编译器与多模态模型自动筛选训练样本；UI2Code-N 将生成、编辑和视觉抛光合并为交互式过程，四轮抛光在其真实 UI 基准上带来约 12% 提升；Macaron-A2UI 则通过 LoRA 监督微调与奖励驱动强化学习学习 A2UI 协议和何时生成或抑制 UI。

推荐流水线不是“一次提示直接输出页面”，而是先判定是否需要 UI，再检索设计系统、工具权限和用户配置，生成交互计划与状态机，随后输出受约束的组件树；输出必须经过 Schema 验证、动作授权、可访问性检查和视觉回归，才能渐进渲染。用户操作通过 AG-UI、SSE 或 WebSocket 回到代理状态图，涉及支付、删除、发送、签署等高风险动作时进入显式确认节点。A2UI 的结构—数据分离和四类流式消息、AG-UI 的状态 Patch 与生命周期事件、LangGraph 的中断/恢复能力，分别对应这条流水线中的不同责任。

数据要求随路线而异。

评测指标必须跨越五层。 语法层检查 JSON/协议有效率和编译成功率；视觉层检查布局、元素召回、文本、颜色和渲染相似度；交互层检查任务完成率、错误恢复、状态一致性和跨屏导航；UX 层检查耗时、点击数、对话轮数、SUS、NASA-TLX、学习性和偏好；治理层检查 WCAG、权限越界、隐私泄漏、暗黑模式和理由—实现一致性。Design2Code 使用 CLIP、元素位置/文本/颜色匹配并以人工判断验证排序；A2UI-Bench进一步覆盖 UI 触发/抑制、跨轮一致性、协议正确性、功能质量和体验；Design Theater 则引入 Thinking Fidelity、Principle Adherence 和 Design Homogeneity 三类指标。

Stanford GenUI 的自动评测显示，GenUI 在任务效率、可用性、学习性和情感安全等指标上均高于 GPT-4o 传统对话基线；这些是模型判分而非直接生产 KPI，因此应与真实任务实验配套使用。

延迟与计算权衡呈明显的表达力阶梯。组件选择通常只需一次工具决策；声明式生成需要输出组件树、数据绑定和 Patch；开放式代码生成还需安装依赖、编译、截图检查和修复。Stanford 原型的多轮迭代在部分情况下需要数分钟，UI2Code-N 的结果也表明增加测试时迭代会提高质量，但同时增加计算和等待。渐进流式渲染、缓存常用组件树、小模型负责 UI 触发与布局、大模型仅处理复杂规划，是降低感知延迟的主要手段。

以下是面向工程规划而非行业统计的 p95 初始目标值：

这些目标应按模型、地区、缓存命中、工具延迟和界面复杂度重新压测，不应被视为现有项目的公开承诺。

下表区分了 已部署产品、官方客户案例、受控研究和开源演示。未披露数字的案例明确标注为“无公开可审计指标”，避免将宣传描述误当作实证结论。

这些案例显示出一个一致规律：收益最高的不是“让页面更漂亮”，而是把原本隐含在长文本里的选择、状态、比较、确认和下一步行动转化为直接可操作控件。 Stanford 研究中，详细请求比简短请求更偏好 GenUI；Figma Make 的显著收益来自将需求、设计上下文、原型和反馈放进同一工作区；可访问性案例的价值则来自根据具体障碍重新组织输入与信息，而非简单更换颜色或字号。

与此同时，生成界面“看起来完成”不能等同于“工作流完成”。Design Theater 的跨工具测试表明，结构和样式通常比功能行为更可靠：五种工具的跨工具平均理由—实现一致性在结构任务中为 0.79、样式任务为 0.81，而功能任务降至 0.66；功能性 UX 原则是最容易被遗漏的部分。

Gen UI 扩大了传统代理系统的攻击面，因为模型不只生成答案，还决定用户看到什么控件、哪些数据被突出、哪些动作可执行。最重要的风险包括：从检索内容或工具结果进入的提示注入；模型生成 HTML/JavaScript 引起的 XSS、数据外传和供应链风险；界面诱导用户批准高风险动作；错误状态同步造成重复支付或误删除；生成结果冒充系统级提示；以及设计精美导致用户对错误结果产生过度信任。Stanford 研究也明确指出，生成式界面可能引入可访问性失败、说服操纵、偏见和“精致输出带来的过度信任”。

控制强度应与生成自由度成反比。

A2UI 的安全优势来自代理不发送可执行代码，而是发送由宿主可信组件目录解释的 UI 意图；MCP Apps 则以沙箱 iframe 换取更高表达力。二者都不能替代服务端授权：前端隐藏按钮、禁用按钮或模型声称“已获批准”均不应作为权限依据。

状态所有权必须明确划分。业务记录、权限、订单和持久数据应由服务端及其数据库负责；输入焦点、展开状态等短暂 UI 状态由客户端负责；需要跨设备恢复的草稿和流程状态应通过明确的数据模型持久化，而不是依赖模型聊天上下文。OpenAI Apps SDK 的官方模式同样强调业务数据、短暂 UI 状态和持久状态的分离。

可访问性方面，单纯要求模型“遵循 WCAG”并不可靠。生成流水线应至少包含语义结构检查、键盘导航、焦点顺序、可见焦点、对比度、表单标签、错误说明、动态区域通知、缩放与重排测试，并使用真实屏幕阅读器进行人工验证。研究表明，Gen UI 有机会在运行时重构界面以适应盲人、低视力和老年用户，但这种适配应建立在 WCAG 2.2、原生语义和用户明确偏好之上，而不是替代基础合规。

生产治理还应保留每次界面生成的模型版本、提示模板、组件目录版本、Schema、工具调用、用户确认和最终事务结果。由于界面会随上下文变化，传统“发布一个固定页面”的审查方式已经不足；必须能够回放某一用户在某一时刻具体看到了什么界面，以及该界面为何触发了某个动作。

界面触发决策仍缺乏成熟标准。 当前研究已证明详细、复杂和交互密集请求更适合 Gen UI，但何时应保持纯文本、何时提供简单组件、何时生成完整应用，仍主要依赖提示规则或模型自判。未来需要公开的“UI 触发—抑制”数据集，衡量过度生成率、遗漏率、用户打断率和认知负担。Macaron-A2UI 已将 UI triggering 与 suppression 纳入基准，但真实世界覆盖仍有限。

现有评测过度重视首屏视觉。 Design2Code、ScreenBench 等推进了视觉还原，但真实应用的关键在于跨屏导航、错误状态、异步工具调用、撤销、权限和时间一致性。Design Theater 显示视觉和设计理由可能掩盖功能缺失；后续基准应在浏览器或移动模拟器中执行任务，而不只是比较截图。

协议碎片化与语义互操作仍未解决。 A2UI、json-render、OpenTiny Schema、COSUI JSON DSL 和其他项目对组件、动作、数据绑定和更新的定义不同。AG-UI 可以统一事件传输，却不能自动统一组件语义；MCP 能统一工具接口，也不能保证同一 UI 在不同宿主具有相同布局和交互。A2UI v1.0 仍处于候选阶段，说明跨版本演进本身就是生产风险。

设计系统与生成自由度存在结构性冲突。 目录越严格，界面越安全、统一和易测试，但创新空间越小；开放生成越灵活，越容易产生品牌漂移、重复组件和不可维护代码。未来较可能采用分层目录：基础组件、领域组件、经过签名的第三方组件和受隔离的开放画布，并让模型在不同信任区之间显式升级。

个性化需要同时解决偏好学习和隐私。 未来界面可能根据熟练度、设备、环境、视觉能力和任务历史调整信息密度与操作顺序，但系统需要区分“用户明确设置”与“模型推断”。高敏感属性不应通过行为轨迹暗中推断；个性化模型还需要支持查看、纠正、暂停和删除偏好。2026 年已有面向高效 Gen UI 个性化的研究，但统一评测和真实部署证据仍处于早期。

可访问性生成需要从组件合规走向任务可达。 一个页面即使通过自动 WCAG 检查，也可能因信息过载、操作路径过长或动态更新不可理解而不可用。C2C 电商研究提出“设计师从规定布局转向规定策略”的方向：为不同能力用户明确哪些信息必须保留、哪些步骤可拆分、如何提供替代输入和如何避免替用户做决定。

模型能力将从代码生成转向交互世界模型。 UI2Code-N 的多轮抛光、Macaron-A2UI 的跨轮一致性，以及语义中间层研究都指向同一趋势：模型需要理解用户意图、组件语义、状态转换和渲染结果，而不是只预测代码 Token。语义中间表示、可执行状态机、视觉反馈和基于任务成功的强化学习可能成为下一阶段核心。

真正的瓶颈将从生成转移到验证。 生成一个界面的边际成本正在快速下降，但验证其功能、权限、无障碍、品牌一致性和法规合规仍昂贵。Design Theater 的结论尤其说明，模型生成的解释不能作为验收证据；必须运行测试、检查 DOM/原生语义、执行用户任务并验证后端状态。

在无预算限制且目标平台未指定的情况下，建议采用 Web 优先、协议解耦、原生渲染、开放内容隔离 的参考架构：

该组合基于各协议公开职责作出：AG-UI 用于双向代理交互，A2UI 用于安全声明式界面，MCP 用于工具与数据，MCP Apps 用于需要 iframe 表达力的复杂应用。

第一阶段应只做“组件选择型 Gen UI”。 用现有设计系统定义 20–40 个高价值组件，例如结果卡、比较表、参数表单、计划步骤、审批卡和错误恢复卡。模型不得生成 HTML，只能调用经过服务端验证的工具和组件。先建立静态 UI 基线、任务成功率、完成时间、错误率和用户放弃率。

第二阶段引入声明式组件树。 在 A2UI 或 json-render 上实现组件目录版本、数据绑定、Patch、回退渲染和未知组件处理。每个组件必须带有权限级别、可访问性契约、允许属性、最大数据量和测试夹具。UI Schema 不应直接承载业务真相，所有交易状态仍由后端返回。

第三阶段连接持久代理工作流。 采用 AG-UI 与 LangGraph 类状态图，使长任务可暂停、恢复、重试和人工接管。计划、执行和确认应是不同 UI 状态；高风险操作显示完整对象、差异、影响范围和不可逆性，禁止仅用“继续”作为确认文案。

第四阶段才开放高自由度微应用。 仅在创意、模拟、可视化和数据探索场景启用 iframe 生成；默认禁止外网、任意存储、摄像头、麦克风、剪贴板和顶层导航。对依赖包建立允许清单与内容哈希，对生成代码执行静态扫描和资源限制。

建议将以下指标设为上线门槛，而不是仅衡量“界面是否漂亮”：

对不同使用场景，本报告给出的优先选择为：

最终实践原则是：生成布局可以概率化，业务状态必须确定化；展示可以自适应，授权不能自适应；模型可以提出动作，服务端必须决定动作是否允许；界面可以实时变化，但必须可解释、可回放、可撤销。