夜雨聆风2026 年，你不再需要为每个功能写一个前端页面。你只需要告诉 AI 你想要什么，它会把界面「画」给你看。
前端曾经是一成不变的。设计师画图，工程师实现，用户看到什么就是什么。
这个时代结束了。
2026 年正在交付的交互界面，有一部分是由 AI 智能体实时绘制的——根据你真正提出的需求，动态生成。你要一个表格？直接给你一个表格。不是一段描述表格的文字。
这就是 Generative UI（生成式用户界面）——让 AI 智能体不再只是「说」文字，而是可以「画」出有丰富变化的交互界面。
但这并不是只有一条路。业界已经演化出了三种截然不同的构建模式，而大多数团队甚至在不知道「自己选了哪条路」的情况下就上路了。
01 协议栈：三条「高速公路」
在深入三种模式之前，先理解底层的通信协议。三条协议，各司其职：
- MCP（Model Context Protocol）
：连接智能体与工具 - A2A（Agent-to-Agent）
：连接智能体与智能体 - AG-UI（Agent-User Interaction）
：连接智能体与用户
AG-UI 是核心承载层。 它基于 SSE（Server-Sent Events）传输流式数据，承载了工具调用、A2UI 界面模式、MCP App 事件、状态增量等一切与用户交互相关的内容。状态双向流动：用户编辑，智能体看到；智能体变更，用户看到。
A2UI 是 Google 制定的标准规范，定义了智能体如何以 JSON Schema 的形式输出 UI。它运行在 AG-UI 之上，由 CopilotKit 等框架在产线中落地。
你不需要自己写解析器。CopilotKit 作为 AG-UI 客户端，自动解码整个流。
02 三种模式，大多数团队都搞混了
随便问十个开发者「什么是 Generative UI」，你会得到十个不同的答案。大部分人描述的，只是他们当前框架默认支持的那一种。
实际上只有三种。从「更多控制」到「更多自由」排列：
- 受控模式（Controlled）
：你预先构建好组件，智能体选择渲染哪个 - 声明式模式（Declarative / A2UI）
：智能体输出 Schema，你的应用映射到组件 - 开放模式（Open-ended）
：智能体直接写原始 HTML，在沙箱中渲染
2026 年的每一个 Gen UI 框架，都落在这条光谱上的某个位置。区别是架构性的，不是表面的。每种模式在规模化时，会以不同的方式「崩坏」。
03 受控模式：前端掌控一切
这是大多数团队的起点。也是大多数团队卡住的地方。
做法很简单：你预先构建一个 React 组件，绑定到一个工具名称上。智能体调用那个工具，组件就在聊天界面中以内联方式渲染，智能体的参数作为 props 传入。
一个前端 Hook，零智能体代码。就这么简单。
Hook 将工具注册到 CopilotKit 运行时，运行时通过 AG-UI 将工具告知智能体。当智能体调用它时，参数流式传入，你的组件以内联方式渲染。不需要写 Python 工具、不需要接线 Schema、不需要新增 API 路由。
你的设计系统保持主导权。
Token 税：被忽视的成本
每注册一个组件，它就会占据智能体的上下文窗口——在用户还没说话之前。一个典型的工具描述加上 JSON Schema 大约 400 个 token。25 个组件意味着每次请求都要支付 10,000 个 token 的「税」。
更糟的是，智能体会选错组件。太多组件看起来太像了。饼图和环形图都在「展示比例」，它猜一个。
什么时候值得加智能体端状态
共享状态是唯一值得写 Python 工具的场景。智能体写入 session 状态，UI 的其他部分订阅并重新渲染，无需第二次 LLM 调用。固定一个指标，仪表盘更新；添加一行，表格重绘。
受控模式的决策指南
适合：10 个以内的高价值流程。设计精度至关重要。你明确知道需要哪些 UI。
不适合：你的代码量随用例线性增长。25 个组件 = 25 个工具定义，占据每次智能体对话。
会崩在哪里：智能体选错组件。两个工具描述语义重叠。超过 15 个工具后，其中两个大概率读起来都像「展示数据」。修复方法：重写描述，命名用户意图而非视觉效果。「当用户要求比较整体的各部分比例时使用」胜过「渲染饼图」。
04 声明式模式：智能体输出 Schema，你只负责映射
这是大多数产线智能体应用最终需要的模式。
智能体输出一个 JSON Schema 描述 UI。 你的应用有一个组件目录，将 Schema 节点映射到 React（或 Svelte、Flutter，任何框架）。一个工具，多种 UI。
A2UI 是标准规范，CopilotKit 提供运行时，ADK 运行智能体，AG-UI 是传输层。
智能体工具按顺序返回三个操作：创建表面、推送组件树、推送数据。
这是真实的函数，不是伪代码。运行时中间件检测到工具结果中的 a2ui_operations 容器，将表面转发到前端。添加酒店？新的 Schema 文件。一个新函数，不同的表面 ID。零额外前端工作。
固定 Schema vs 动态 Schema
- 固定 Schema
：组件树存在于 JSON 文件中，你写的。智能体只填充数据。 - 动态 Schema
：一个次级 LLM 根据对话上下文，每轮动态编写组件树。Google ADK 展示了两者。
组件目录就是合约
定义列出智能体允许输出的组件，使用 Zod Schema 约束 props。渲染器填充 React。拼写错误会变成构建错误，而不是空白屏幕。
Token 经济学
50 种卡片类型还是 500 种，智能体只看到一个函数。每个对话回合的 token 消耗保持恒定，随组件库增长不增加。
可扩展到任何渲染框架，因为它只是 JSON。任何已经支持 AG-UI 的智能体，零日即可驱动 A2UI。你不需要修改智能体代码来接线。
代价：LLM 掌控布局。每次运行的输出在你的目录范围内会有变化。如果你要交付法律声明、营销页面或任何要求像素级精确的场景，这不是你的篮子。
声明式是为长尾而生的模式。 仪表盘、结果页、表单、卡片、小部件。
声明式模式的决策指南
适合：你的用例比你有时间预构建的要多。你在意原型阶段之后的 Token 经济学。
会崩在哪里：你构建了一个自定义 FlightCard，但每个航班都渲染成基础目录的通用卡片。控制台没有报错。原因是智能体端的 CATALOG_ID 和前端 createCatalog 的 catalogId 不匹配。前端不认识智能体指向的目录，回退到基础目录。两端字符串必须完全一致。
05 开放模式：没有目录，没有规则
这是另一个极端。没有目录，没有 Schema。只有一张空白画布。
这个桶里有两个子模式：
MCP Apps
一个 MCP 服务器暴露 UI 表面，由智能体驱动。Excalidraw 是最令人印象深刻的例子——智能体获得画布的完全控制权，从你的上下文中绘制图表，掌控画板上的每一个像素。
从零实现客户端协议极其痛苦，所以 CopilotKit 提供了 MCPAppsMiddleware。附加到你的智能体，指向任何 MCP Apps 服务器。
启动 MCP Apps Showcase，你就能在聊天窗口内预订航班和酒店。同样的中间件，真实的 MCP 服务器。
更进一步：AI MCP App Builder 让智能体在 E2B 沙箱中编写一个全新的应用，然后实时渲染。
沙箱化 HTML
智能体直接写原始 HTML。你的应用在沙箱化 iframe 中渲染，防止它劫持会话。
运行时注册一个 HTML 渲染工具，通过 AG-UI 发送给智能体。智能体调用它，传入任意 HTML。智能体端不需要定义 HTML 工具——运行时注入。
智能体端的指令是真正干活的部分：
没有这些样式规则，模型会默认使用训练数据中与当天prompt最相符的审美。有了它们，大多数时候你得到接近品牌风格的结果。但不总是。
品牌一致性困境
作者曾尝试将开放模式作为智能体的主要 UI。一周后撤回了。
周二「新粗野主义」，周三「iOS 4 克隆」。提示词中的样式规则可以引导智能体靠近你的品牌，但无法保证。品牌一直在变，产品感觉不严肃。
开放模式不是没用。是用错了地方。
唯一正确的场景：一次性交互，用户不关心界面长什么样，也永远不会再看第二次。「展示电子如何工作」「给我一张最近 10 次查询的奇怪柱状图」「可视化这个 API 响应」——Google AI Overviews 里那种东西。
开放模式的决策指南
适合：一次性查询。一次性可视化。沙箱实验。永远不要作为主要交互界面。
会崩在哪里：iframe 渲染了，但按钮不响应点击，表单不提交。沙箱标志太紧，或者太松导致浏览器拒绝。设置 iframe sandbox 为允许脚本和允许表单。仅此而已。永远不要 allow-same-origin。
06 如何选择：一张决策树
在写代码之前，先跑一遍决策树：
- 设计师对这个流程有像素级精确的原型？
→ 受控模式 - 有几十种卡片类型或小部件要交付？
→ 声明式模式 - 一次性的、用完即弃的可视化？
→ 开放模式 - 拿不准？
→ 默认声明式。为前 3 个核心流程升级到受控模式。永远不要默认开放模式。
如果你已经在生产环境中了，但不确定自己落在哪里——数一下渲染工具的数量。超过 15 个，你在受控模式，撞墙不远了。这周就开始接入 A2UI。
三种模式，三种赌注
真正的错误不是选错了模式，而是根本不知道自己做了一个选择。
大多数团队默认走向受控模式，因为框架默认就是受控模式。他们在 25 个组件时撞墙，然后转向开放模式，因为它在 Demo 里看起来很诱人。这两次都不是决策，都是漂移。
有意识地选择。 把模式匹配到问题上。受控模式用于需要精确的流程。声明式模式用于长尾。开放模式用于一次性的。
参考资料
三种模式的完整参考代码在 awesome-llm-apps 的 Generative UI Agents 章节中。克隆你需要的，移除你不需要的。
本文编译自 Shubham Saboo（@Saboo_Shubham_）发布的深度技术文章，原文在 X 平台获得 1184 次点赞、3765 次收藏。Generative UI 正在重塑前端开发的底层范式——不是又一个框架，而是一种全新的交互哲学。
关注我们，获取更多 AI 前沿技术解读。
