生成式 UI 概述
理解从受控、声明式到开放式界面的生成式 UI 光谱
生成式 UI（Generative UI）是指智能体的输出呈现出超越纯文本界面的任意模式。智能体不再是将一段文字流式传输到聊天气泡中，而是驱动表单、卡片、仪表盘和交互式控件。这让你的 UI 能够像传统应用程序那样传达结果，同时由智能体决定展示什么内容以及何时展示。
生成式 UI 并不是单一的技术。它横跨一个由一个核心问题所定义的光谱：谁来构建界面？ 在光谱的一端，你编写每一个组件，智能体仅在它们之间进行选择。在光谱的另一端，界面完全在你的应用程序外部创建。沿着光谱向前推进，是用可预测性来换取更广泛的表现力范围。
生成式 UI 光谱
该光谱涵盖了从对每个像素的完全控制到智能体的完全自主，主要采用三种方法：
更高控制度
更高自主性
从左到右，可预测性以及针对每项功能的工程成本均会下降，而智能体的表现力范围则会扩大。无障碍访问（Accessibility）和视觉一致性在最左侧最容易保证，而在最右侧最难保证。
受控（Controlled）
你负责编写组件，智能体选择渲染哪一个组件以及传递什么数据。这提供了最高的可预测性以及对品牌形象和无障碍访问的最严格控制，代价是必须为你希望暴露的每项功能编写相应的组件。它是生成式 UI 的主力方案，非常适合高流量、对品牌形象至关重要且布局必须精确的界面区域，例如机票和预订确认单。你的组件库就是边界：智能体只能渲染你已交付的内容。受控生成式 UI 涵盖了组件作为工具（components as tools）、工具调用渲染、状态渲染和推理。
有关详细信息，请参阅 受控生成式 UI。
声明式（Declarative）
智能体输出结构化规范（Specification），前端根据你预先注册的组件目录来组装界面。该目录充当了护栏和边界：智能体可以自由编排和组合你的组件，但不能超出你批准的集合范围。这正是长尾场景的用武之地。它以像素级的精确控制换取了覆盖广度，适用于次要交互、内部工具和仪表盘——在这些场景中，展示有用的内容比精确的控制更为重要。声明式生成式 UI 通过 json-render 涵盖了这种模式；通过 CopilotKit 集成的 Google A2UI 也提供了类似的形式，并支持动态和固定模式（schema）变体。
开放式（Open-ended）
智能体完全掌控画布。界面是在你的应用程序外部创建的（例如由 MCP 服务器创建），并在沙箱中进行渲染。这提供了最广泛的表现力范围，无需在你的前端编写任何代码即可添加新的界面功能，非常适合一次性可视化和定制化答案——在这些场景中，一个令人惊喜且足够好的结果胜过一个可预测的结果。这也是最具实验性的方法：确定性最低，也最难保证无障碍访问、一致性和安全性，因此 UI 必须被隔离。沙箱和你的 Prompt 就是其边界。
有关详细信息，请参阅 开放式生成式 UI。
选择合适的方法
从你对界面的约束需求程度出发：
| 如果你需要…… | 选择 |
|---|---|
| 为已知的一组输出保证品牌形象、布局和无障碍访问 | 受控 |
| 允许智能体仅使用经批准的组件来组合新颖的布局 | 声明式 |
| 展示由第三方构建的界面，而无需自行开发 | 开放式 |
为整个产品只选用单一方法是最常见的错误。实际应用通常会融合多种方法，并将各个界面区域与其具体目的相匹配：受控组件用于高流量、对品牌至关重要的核心功能，声明式组合用于次要交互的长尾场景，而开放式嵌入用于第三方功能。单个会话可以在这三者之间自由切换。
该光谱同样适用于聊天之外的场景。这三种方法不仅能描述聊天记录中的生成式界面，同样适用于移动端以及 Slack 或电子邮件等交互界面。
探索光谱
编写组件；由智能体挑选要渲染的组件以及要传递的数据。
智能体输出规范；由前端根据已注册的目录进行组装。
渲染在别处创建的 UI，例如沙箱化的 MCP Apps。