生成式 UI：框架、协议与实现类型
生成式 UI 是由 AI 根据用户的上下文、意图和数据，实时动态地创建和调整的用户界面，目标是提供适应用户需求与场景的个性化体验。
Generative UI 的核心是从”设计界面”转变为”设计能够生成界面的系统”。
| GenUI 优点 | GenUI 挑战 |
|---|---|
| 个性化：提供针对用户角色、偏好和工作流程定制的界面。 快速原型设计：即时从提示生成 UI，加速设计迭代过程。 动态适应性：用户界面可根据上下文或用户行为实时改变。 设计到开发成本降低：缩小设计、开发和部署之间的差距。 | 质量控制风险：生成的 UI 不一定符合品牌或无障碍标准。 安全问题：运行时生成的动态用户界面引入了风险。 性能开销：若未经过优化，实时生成可能会拖慢性能表现。 用户体验一致性：若缺乏约束，界面体验可能不一致。 |
目前 GenUI 做得比较好的产品：
| Gemini-Visual Layout | 灵光-全模态内容 | Gemini-Dynamic View | 灵光-闪应用 | |
|---|---|---|---|---|
| 截图 |  |  |  |  |
| 主要目标 | “看”：优化信息的阅读和浏览体验。 | “用”：通过交互来探索数据或完成任务。 | ||
| 原理 | 将文本、图片、视频进行美学排版，整理成模块化卡片。 | LLM/Agent 实时编写代码，生成一个可交互可独立部署的 html， iframe 嵌入到页面中呈现 | ||
| 典型场景 | 旅游攻略、产品对比、购物清单、灵感搜集。 | 交互式图表、计算器、学习模拟器、个性化选品。 |
生成式 UI 如何工作
GenUI 解读意图（来自用户指令、系统状态或历史数据）并生成相应的界面组件。
- 用户输入或上下文触发：可以是文本指令、语音命令，或诸如用户行为、应用状态等上下文数据。
- AI 推理：模型解析输入，以理解用户的意图。
- 界面生成：系统根据意图编排或直接生成定制的 UI 元素。
- 渲染与执行：使用前端框架（如 React）渲染 UI，并动态连接到业务逻辑或 API。
其中也包括自适应的界面更新 adaptive UI，根据不断变化的用户需求来调整界面。
关键要素
Agent 协议和框架
生成式 UI 的核心是 Agent 驱动的动态界面生成与交互。Agent 是决策核心，其框架定义了能力边界，协议则保障了交互的稳定性与扩展性。
| 维度 | 框架/协议相关要素 | 对应的生成式 UI 能力 | 典型示例 |
|---|---|---|---|
| 核心驱动逻辑 | 框架的核心模块（意图识别、任务规划、工具调用、上下文记忆） | 动态理解用户需求，智能规划界面组件与布局，实现个性化交互 | 用户输入“生成数据分析仪表盘”，Agent 解析需求后规划图表、筛选器等组件生成适配界面 |
| 通信交互保障 | 核心协议（Function Call、JSON Schema、gRPC） | 确保 Agent 与前端、后端、第三方工具的信息传递准确，界面渲染正常 | Agent 按 JSON Schema 输出组件描述，前端精准解析并渲染；多 Agent 协作时通过协议高效传递信息 |
| 场景适配扩展 | 框架扩展性设计（模块化、插件机制、多记忆模块） | 适配多终端（PC/移动端）、多业务场景（电商/医疗/办公），对接多数据源 | Agent 加载数据库插件，使生成式 UI 对接业务数据库；切换记忆模块实现用户偏好记忆 |
| 可靠性与安全 | 安全机制（权限校验、任务审核、上下文隔离）；协议规范约束（参数校验、格式限制） | 规避生成内容不可控、权限滥用等风险，保障界面生成与交互安全 | 通过协议限定 Agent 可调用工具列表；通过框架权限模块控制数据访问范围，防止恶意组件生成 |
Agent 协议
用来“让不同Agent/组件能互通”的消息/事件/数据格式规范——Agent 之间怎么对话、前后端怎么对话、UI 怎么描述、事件怎么流、用什么传输等等。
目前主流的协议包括：
| 特性 / 协议 | MCP | Agent2Agent (A2A) | Agent Protocol |
|---|---|---|---|
| 核心目标 | 连接 LLM 与数据/工具 (Universal Adapter) | Agent 间协作与发现(Interoperability) | 标准化 Agent 控制 API (REST Interface) |
| 架构模式 | 中心化 Client - Server：含 Host（统筹）、Client（通信代理）、Server（能力提供）三大组件 | 去中心化 P2P 对等架构，以 Agent 为核心，通过 Agent Card 实现动态发现与直连 | 任务导向的 Client-Server 模式，侧重于任务生命周期管理 |
| 通信协议 | Client - Host - Server | HTTP + JSON | REST API (OpenAPI Spec) |
| 传输层 | Stdio (本地), HTTP+SSE (远程) | HTTP / WebSocket | HTTP (REST) |
| 典型用例 | 让 Claude 读取本地 Git 仓库或 PostgreSQL | 多 Agent 寻找彼此并协作 | AutoGPT 跑分评测 |
| 主要维护者 | Anthropic (Open Source) | Google / Linux Foundation | AI Engineer Foundation |
MCP：“Agent/AI 应用 ↔ 工具/数据”的连接协议
A2A：“Agent 彼此聊天协作”的 agent-to-agent 通信协议
Agent UI 协议
Agent 与 UI 层、上下游系统的 “通信规则”，确保各方数据传递和指令交互的一致性、准确性。
| 概念 | MCP | MCP Apps | A2A | A2UI | AG-UI |
|---|---|---|---|---|---|
| 作用 | 定义 Agent 如何调用外部工具 / 数据源（tool/data） | 把 “工具返回交互 UI” 标准化进 MCP（ui://、可审计、双向通信） | 让不同 AI Agent 互相发现、握手并协作完成任务的通信协议 | Agent 输出 JSON 描述意图，客户端用原生组件渲染（跨端、安全、非任意代码） | 让 Agent App 可靠地 “边跑边同步”：生命周期、文本流、工具调用、状态快照 / 增量等统一成事件流 |
| 生态位 | 工具连接层 (Connector) | 能力提供方 (Provider) | 协作层 (Network) | 渲染层标准 (Spec) | 展示层 (Vision) |
| 层级 | Agent ↔ 工具的连接层 | MCP 的 UI 标准 | Agent 间协作层 | UI 描述 / DSL 层 | 运行时交互 / 会话协议层 |
| 简单类比 | “Agent 的工具插座：Agent 想查数据，MCP 帮它插对数据库的接口” | “带 USB 接口的智能设备：比如支持 AI 读取的数据库软件，既能返回数据也能给 Agent 展示操作界面” | “AI 界的微信 / Slack：我不会订票，但能发消息给‘订票 Agent’让它做” | “Agent 发乐谱 (JSON)，浏览器用钢琴 (React/Flutter) 把它弹出来” | “魔法报纸：内容和排版根据看报人的操作自动变化，边看边更新” |
Agent 框架
用来“写/跑 agent 逻辑”的代码库或运行时——编排、多 agent 协作、工具调用、状态/记忆、容错、部署等
- LangChain / LangGraph：面向生产的 agent 编排/运行时与图式工作流。
- AutoGen：多 agent 会话/协作框架。
- CrewAI：多 agent 编排框架。
- Google ADK：Google 的 agent 开发/部署框架。
Agent UI 框架
是界面开发的 “骨架” 与 “能力引擎”，定义了 Agent 如何与 UI 组件联动、如何驱动界面动态生成和交互
Agent UI 框架/SDK
- Vercel AI SDK（含 UI 能力）：更偏“AI 应用开发工具箱”，把工具调用结果映射到前端 UI 的路径很成熟，但它本身不等同“agent 编排框架”。
- assistant-ui / CopilotKit / Tambo / Crayon：主要解决“怎么把 agent 交互做成产品级 UI”，属于 UI SDK/前端框架范畴。
- Chainlit / Streamlit / Gradio：更像“快速把 agent 跑起来给人用”的 UI 容器/原型框架。
- Open WebUI ：成品外壳/平台型 UI。
生成式 UI 的实现类型
| A. 客户端代码生成 （Micro-App） | B. 服务的驱动的结构化 UI （SDUI / DSL / Catalog） | C. 工件编辑器 （Canvas Editor） | |
|---|---|---|---|
| 核心逻辑 | 写代码 | 填参数 | 改文档（Edit Artifact） |
| 代表产品 / 框架/协议 | Claude Artifacts；Gemini Dynamic View；蚂蚁灵光-闪应用 | Gemini Visual Layout；蚂蚁灵光-对话；A2UI | Gemini Canvas；OpenAI Canvas |
| LLM 输出什么 | 可执行前端代码 | 结构化 JSON/DSL：组件树 / 布局 / 数据绑定 / 动作（输出意图和参数，不是代码） | 对文档 / 代码状态的编辑指令（diff/patch/ 重构）、可运行的代码 / 内容 |
| 前端渲染什么 | 沙箱里跑的独立小应用 | 本地预置的组件库（Design System）拼装出的 UI 原生 / 网页 | 编辑器 + 运行容器 |
| 交互闭环怎么做 | UI 事件在沙箱内部处理；需要时把状态 / 结果回传对话 | UI 事件编码成结构化消息回给 agent；agent 决策后输出新的 JSON/patch | 用户选区 / 标注 → 模型做局部修改 → 持续迭代 |
| 实现模式 | iframe/webview sandbox；CSR 运行 + 热更新 | - CSR 映射（客户端服务器渲染映射）； - 跨端 native renderer； - RSC stream 也能做但少见 | LLM 拥有对文档 / 代码状态的读写权限。编辑器模型 + 预览容器；Web 常是 CSR；代码预览可能用 sandbox / 容器 |
| 优势 | 自由度极高：能做新交互、游戏、复杂可视化 | 稳定、安全、品牌统一、跨端、可治理；在 schema 约束下低幻觉、可校验 | 最适合长任务、局部编辑、版本化与协作 |
| 代价 | - 稳定性（代码报错 / 样式崩） - 安全（执行不可信代码） - 一致性（风格分裂） - 成本（token / 推理） | - 创造力受组件库限制； - 要维护 catalog/schema/renderer； - 复杂交互要扩展协议 | - 不一定 “每轮都生成 UI”； - 更像创作环境； - 实现细节复杂 |
- CSR（Client-Side Rendering）：客户端渲染模式下，LLM 输出 JSON 数据，前端根据预定义映射表决定渲染哪个组件。逻辑位于客户端。
- RSC（React Server Streaming）：在服务器模式下，LLM 在服务器生成 React 组件并流式传输到前端渲染结果。客户端无需将数据映射到组件，只需接收 UI 树。
Q&A
MCP Apps 和 A2UI 有什么不同？
- MCP Apps：先定义组件/App。
- A2UI：由模型实时驱动生成的动态 UI 的协议。
| 维度 | MCP Apps | A2UI |
|---|---|---|
| 基本形态 | 在 MCP 上扩展获取 “UI 资源” 能力 | Agent 输出声明式 JSON UI 蓝图，客户端以本地组件库渲染 |
| 架构 | 以 HTML/JS 为主的 “远端 UI”，把可交互页面作为一种可获取的资源，嵌入 Agent 对话 / 工作流中 | 以数据描述 UI + 客户端原生渲染为核心，确保跨端一致性与安全可控 |
| 功能定位 | 让工具调用不仅返回文本和数据，也能返回可交互界面 | 告诉前端“要什么样的界面”（声明式、跨端渲染），让应用能够接入可由 Agent 生成的界面。 |
| 适用于 | 更适合“工具侧提供 UI 模板”，Host 加载呈现；可做“开箱即用”的工具 UI。 | 更适合“Agent 按上下文生成 UI 意图”，Host 负责渲染与交互闭环。 |
| 设计表现力 | UI 作为资源（页面）返回，表现力可以接近 Web 上限（图表、动画、媒体、复杂布局均可） | 组件树声明式 JSON，Agent 能直接“表达 UI 意图”。表现力取决于 Host 组件库丰富度。更适合做“增量更新 UI”（修改某字段、局部刷新、动态添加组件）。 |
| 关键机制 | - MCP Server 预声明 UI 资源，并把 UI 与 Tool 元数据关联 - Host 在需要时拉取 UI 内容（text/html）并渲染 - UI 通常以 iframe 沙箱方式运行，隔离宿主环境 - UI 与宿主 / 工具之间通过 MCP 的 JSON-RPC 通道进行双向通信 | - Agent 回复不发送 HTML / 可执行代码，而是发送 UI 组件树的 JSON 描述（结构、属性、事件等） - Host / 客户端内置组件目录和渲染器，将 JSON 映射为 Web/Flutter/iOS/Android 等平台的原生组件 - 传输层可与 A2A、AG-UI 或其他消息管道结合，强调 “格式标准化 + 传输解耦” |
| 典型场景 | 对话内嵌业务 UI：权限配置、审批流、客服信息收集、运维操作面板等。 工具结果可视化：数据分析图表、报表、仪表盘的交互呈现。 复杂输入收集：多字段表单、多步骤 wizard、批量选择等。 | 即时生成表单/控件：预订、填报、筛选、对比等对话场景中动态生成 UI。 跨端一致体验：同一套 UI 描述可落地到 Web/Flutter/移动原生。 多代理协作：子代理能产出 UI 蓝图，被主代理/宿主理解与组合（更利于互操作）。 |
| 开发优势 | - 前端门槛低，Web 技术栈成熟。 - UI 表达力强，易做复杂界面与快速迭代。 - 对已有 MCP 系统可渐进增强（兼容纯文本）。 | Host 提供组件库与渲染器，Agent 输出 JSON 蓝图： - 原生渲染一致性好，可访问性与平台体验更统一。 - 组件化扩展清晰：新增组件类型即可扩展表达力。 - 可用模板 + 数据减少 LLM 结构生成难度。 |
| 挑战 | 跨宿主一致性与样式融合需要额外工程。安全审核与沙箱策略需要严格执行。 | 需要理解并实现组件映射/渲染层（初期成本较高）。规范早期阶段可能存在变动，需跟进版本演进。 |
- MCP 解决 Agent 如何调用外部工具/数据源的问题，属于 Agent ↔ 工具 的连接层。
- A2UI 让 agent 输出声明式 JSON UI 意图，客户端用本地组件库渲染，属于UI 描述/DSL 层。
两者可以同时存在：一个用于“工具自带的交互面板”，一个用于“Agent 临场生成的跨端界面”。
Agent skills 和 A2UI 有什么不同？
- Agent skill：让 agent “会做事”（把任务变成可复用、可执行、可观测的能力单元）。
- A2UI：让 agent “会表达界面”（把 UI 变成可控的声明式意图，让客户端拼装）。
| 维度 | Agent skill | A2UI |
|---|---|---|
| 核心问题 | 任务怎么做、怎么稳定做、怎么复用 | UI 怎么说、怎么安全渲染、怎么交互闭环 |
| 所在层 | 行为/流程层（planning → tool use → state） | 呈现层（UI intent → renderer → event loop） |
| 面向对象 | Agent 自身能力（步骤、策略、边界、容错） | 客户端 UI 组件目录（catalog）+ UI 描述（DSL/JSON） |
| 输出形态 | 通常是：计划/步骤、工具调用、状态更新、产物 | 通常是：组件树描述、数据绑定、事件定义、增量 patch |
| 稳定性来源 | SOP/策略约束、工具契约、重试回退、测试与监控 | schema 约束、catalog 白名单、renderer 控制、事件协议 |
| 失败模式 | 做错事：调用错工具、流程跑偏、状态不一致 | 表达不对：组件选错、参数不对、布局不佳（但不会“跑崩”） |
| 治理方式 | 版本管理、评测、回放、权限/工具白名单 | schema 校验、catalog 版本、渲染兜底、禁用任意代码 |
| Token 成本 | 主要花在推理与工具编排 | 主要花在 UI 描述（可通过短 ID/patch 大幅压缩） |
| 典型用途 | 把“复杂任务”封装成可调用能力（像函数/流程） | 把“下一步交互”变成 UI（卡片/表单/对比/向导等） |
Skill = 行为逻辑 + UI 合约（A2UI 风格）+ 事件回路
把 A2UI 当作某些 skill 的“输出/交互壳”：
- skill 负责：识别意图 → 拉数据/调用工具 → 产出“候选方案/状态”
- A2UI 负责：把候选方案变成 UI（对比卡、筛选器、Stepper、确认面板）
- 用户点选/提交 → 事件回流 → skill 继续执行下一步
© 00RSS