使用者痛点一：界面仍然老旧，却被标榜为“AI 生成”。老实说，很多团队在引入 Agent 后只是让它在聊天框里输出文字。导致信息被压缩成线性文本，无法发挥结构化展示的优势。

使用者痛点二：安全审计成本飙升。开放式生成 HTML/CSS/JS 时需要额外的沙箱、审计流水线，导致开发与运维成本大幅上升。

使用者痛点三：Token 消耗不可控。不同 UI 描述格式的 token 开销差异巨大，在高并发场景下直接影响云费用。

2024 年 5 月，Andrej Karpathy 在推特上回应了一个 LLM 的 GUI 演示。附了一句评价："像一辆无马车厢——它在新的范式里精确地复制了旧的界面。"他要说的不是 Demo 做得不好。而是我们正处在一个过渡期：Agent 已经能动态生成界面了但这些界面看起来还是我们熟悉的按钮、表单、图表，与三十年前的 GUI 没什么区别。

这正是生成式 UI 领域的主要张力所在。技术水平已经越过临界点，但我们对"界面应该长什么样"的想象仍被旧范式牢牢抓住。

聊天框的尽头

这不是设计选择，而是技术债。LLM 默认输出文本，前端默认渲染文本，两者之间没有中间地带。于是信息被迫坍缩成线性文字流——哪怕是需要表格对比的数据、需要可视化的趋势、需要分步确认的操作流程。

使用者痛点四：信息结构化缺失导致业务决策慢。当信息本身具有结构时用结构化界面呈现天然比纯文本好。表格比段落更擅长对比，图表比数字更擅长趋势，表单比指令更擅长引导操作。聊天框的问题不在于它"不够好"，而在于它在很多场景里恰恰是错误的媒介。

于是生成式 UI 要回答的问题变得清晰了：当 Agent 不只是"回答问题"而是"完成任务"时界面形态需要与之匹配。

从三种模式来看。控制权如何重新分配

CopilotKit 在 2023 年的开发者教程里提出了一个实用的分类框架，把生成式 UI 按"谁控制什么"切成了三种模式。Open-UI 在同年 9 月的状态报告里进一步把这个框架提炼为两个独立维度：传输和生成。

使用者痛点五：缺少统一模型导致团队沟通成本高。不同项目使用不同维度描述方式，使得跨团队协作出现概念冲突。

说到静态模式，Agent 选组件。前端决定一切

这是最保守的一端。前端团队把所有可能用到的组件提前建好，Agent 的任务只是从目录里挑一个、填上数据。Agent 不决定布局、不决定样式，甚至不决定"这个场景该用什么组件"——它只是给某个已注册的工具调用返回一个组件选择。

你在 CopilotKit 里用 useFrontendTool 做的事，就是这个模式。工程上几乎零风险：没有代码生成，没有沙箱，没有额外安全审计负担。代价是每出现一个新的答案形态。就需要一个新组件——目录靠 PR 增长，不靠 prompt。据 CopilotKit 官方自述，已有超过 80% 的财富 500 强公司在用它做 Agent 的 UI 层。老实说，

适用场景：答案形态有界限。如客服面板、财务仪表盘、预设工作流审批。一旦布局空间开放，它会成为瓶颈。

声明式模式这方面，Agent 编排布局。前端执行渲染

当前大多数生产程序实际落地的位置。Agent 不直接输出 HTML/CSS/JS，而是输出结构化 UI 描述。前端收到后用自己的组件库和设计程序渲染成真实界面。

控制权分配：

• 前端拥有设计程序：颜色、间距、字体、品牌调性均由前端决定，不受 Agent 干预。老实说，
• Agent 拥有布局权：决定使用卡片还是表格、数据横排还是纵排。还有是否需要交互控件，

This "我定规则。你定编排" 分工，是2023 年生成式 UI 主流平衡点。安全性来源于简单事实：Agent 只能渲染目录里已有的组件；目录即权限模型——不存在的组件，Agent 编不出来。

使用者痛点六：缺乏目录治理导致权限失控。

The Google A2UI 路线示例：

• CreateSurface,。

The Vercel json-render 方法则支持同一套 spec 渲染到 Web 仪表盘、邮件、PDF 或终端，实现跨渠道复用。

使用者痛点七：Token 成本直线上升——每省一次 token，都直接体现在财务报表上。话说回来，

开放式模式的观点是，Agent 写界面前端做容器

This is most aggressive end. No component catalog。no schema constraints. Agent directly outputs full HTML/CSS/JS;front‑end renders it inside a sandboxed iframe.

• Google Gemini Dynamic View；CopilotKit 的 {...} + LangGraph Agent 能生成 Three.js 场景或 D3 力学模拟等完整交互页面。

使用者痛点八：视觉一致性缺失与安全审计难度倍增。

• A) 没有设计令牌继承 → 品牌失衡； B) 沙箱隔离数据交互 → 延迟升高；C) 完整页面 token 消耗远高于声明式 spec；D) 同一 prompt 多次生成结果不一致 → 可预测性差。其实，

The Open‑UI hybrid solution registers a GeneratedView component whose sole prop is an HTML string generated by Agent. Normal flows stay within catalog;only when catalog truly cannot cover a layout does “escape hatch” open,keeping security audit focused on a single component.

说到一图胜千言，三种模式的实际形态

// Agent 返回工具调用
{
"toolCall": "render_ui","component": "RevenueChart","props": {
"regions":,"revenue":
}
}
// 前端直接使用预定义 React

{
"createSurface":"s1"。"rootId":"c0"
}
{
"updateComponents":},{"id":"c1","kind":"Heading","props":{"text":"Q1 各区域营收"}},{"id":"c2","kind":"BarChart","props":{"dataPath":"/data/series"}}
]
}
{
"updateDataModel":{
"/data/series":
}
}

Q1 各区域营收

The token cost gap becomes pronounced at scale. In Open‑UI’s benchmark across seven typical scenarios。OpenUI Lang DSL consumed ~45 k tokens while an equivalent JSON spec used ~55 k tokens—a ~22% increase. Pure HTML in open mode can balloon to>100 k tokens for same visual output.

常用方法

1. 从声明式开始，不要一上来就开放式： 组件目录约束不是限制，而是安全基座。只有目录里的组件才能被 Agent 调用，从根本上消除“奇怪代码”风险。
   • *注册时写清楚用途与约束*——文字描述比 TypeScript 类型更能帮助 LLM 正确使用组件。
2. 状态反馈循环不可跳步： 每一次使用者对生成组件的交互都必须回写到 Agent 上下文。否则后续响应基于过期状态，这往往导致任务失败或错误展示。
   • *实现方式*——CopilotKit sharedState / AG‑UI STATE_DELTA / A2UI updateDataModel 都提供双向同步机制。
3. 元数据比更好原始数据： 让 Agent 输出渲染指令，客户端自行拉取真实数据。这既省 token，也避免了数据误写风险。
   • *示例*这方面，“render Chart component with dataPath '/sales/q1'”。
4. “逃生舱口”集中管理： 若业务必须使用开放式 HTML。请把它封装成目录里的唯一 {" "}component，仅此入口接受审计，其余方法仍走声明式安全方法。
   • *好处*——安全审计聚焦单一点，可快速定位异常代码片段。
5. 持续监控 Token 消耗： 为不同 UI 描述格式设定预算阈值。并通过 CI 报告异常增长，以防止意外成本飙升。
   • *工具*—Open‑AI usage API + 自建监控仪表盘.

常见误区澄清

• "AG‑UI、A2UI、MCP Apps 是竞争关系，三选一。" —— 它们位于协议栈不同层次；AG‑UI 为传输层，A2UI/MCP Apps 为载荷层。同一个 Agent 可以同时使用多种载荷向不同宿主发送 UI。
• "生成式 UI 等于让 LLM 直接输出 HTML。" —— 开放式 HTML 是一种可选方案，但并非默认；声明式 DSL 在生产环境中的采用率明显更高，因为它更安全、更省 token、更易保证视觉一致性。
• "生成式 UI 是前端工程师的替代品。" —— 正相反，它把工作推向更上游——从“写页面”转向“定义机器可读且受约束的组件目录”。并负责验证流水线与双向状态同步。

至于短暂性的哲学，当界面用完就消失

The earlier discussion focused on “how to generate”. The deeper question is lifecycle—how long should se generated interfaces live?

• 传统观念： 界面像建筑物，需要数月设计开发后长期运营；使用者学习并依赖它们，这是默认假设，即持久性=默认值。
• 生成式 UI 翻转假设： 每一次任务对应一个临时 UI；任务结束后该 UI 即溶解，为下一任务重新组装。

Nielsen Norman Group 在2023 年提出 “outcome‑oriented design”，将设计师角色从“绘制组件”转向“定义约束和护栏”：哪些信息必须展示？哪些可以省略，哪些绝对不能泄露？话说回来，“短暂 UI”已从材料实验走向软件工程日常。工程含义：

• 视觉一致性仍需保持，却不能靠每次全量生成 HTML 来实现 —→ 声明式模式成为首选。
• 每一次交互都要回写至 Agent 上下文 —→ 状态同步成为主要成本。按理说，
• Token 与延迟随描述格式变化显著 —→ 格式选择即成本决策。其实，

前端工程师变成了什么

If Agents can pick components,orchestrate layouts and even write full pages。role of front‑end engineers must evolve.

• 角色上移： 从实现单页 JSX 转向 建立机器可读且受约束 的组件目录。
  • 目录既要足够通用覆盖多数场景，又要足够约束防止奇怪组合 —— 平衡本身是一门新技能。怎么说呢，
• 验证流水线升级：
  • Schema 校验 – 输出 JSON 合法性
  • 白名单校验 – 引用组件是否存在
  • 跨渲染目标兼容性检测
  • 降级策略 – 前端拒绝布局时 Agent 能否回退
• 状态管理双向流动： 前端不再是唯一状态源；Agent 上下文与客户端共享 State Delta／updateDataModel 等事件，实现实时同步。
  • CopilotKit sharedState 、AG‑UI STATE_DELTA 、A2UI updateDataModel 都是实现手段。
• 从“写 UI”到 “引导 UI 的生成”： 看似职责减少，却实质提高至程序抽象层次是一次真正意义上的升级。

说到协议栈，管道和载荷分工

内容格式 —— JSON 树 / Component Spec / iframe URI 等具体语义模型。 A2UI 使用 createSurface / updateComponents / updateDataModel 三类消息描述完整页面结构。 Open‑JSON‑UI 用统一 JSON schema 描述卡片·列表·图表等，可渲染至 Web Dashboard / Email / PDF 等多目标。 MCP Apps 用 ui://resourceURI 将完整页面资源交付给外部宿主，宿主以 sandboxed iframe 渲染。 同一 Agent 可通过 AG‑API 把 A2UI payload 发给内部程序，又通过 MCP Apps 把一样逻辑投递到第三方网站。实现 协议层复用 + 内容层自由切换

/参考来源/ * Google Research – “Generative UI…” * CopilotKit – “The Developer’s Guide…” * Open‑AI – “State of Generative U​I…” * Sunpeak – “MCP Apps vs A​A​U​I…老实说，” * Nielsen Norman Group – “Generative U​I and Outcome-Oriented Design” * Medium iSolutions – “Ephemeral U​I in AI Generated Interfaces” * Google Cloud – “What is Generative U​I?，”