生成式UI
定义
生成式UI，是指 Agent 在生成回复时，输出的不只是纯文本说明，还包括可被前端直接渲染的界面组件。
纯文本回复的典型形式，是“告诉用户结果是什么”；生成式 UI 的形式，则是“把结果直接显示成界面”。
在文中给出的能力描述里，Agent 的输出可以是 React 组件，例如图表、表格、按钮，而不是只返回“这里有一份销售趋势，你可以自己再做图”这样的文字说明。
因此，它与普通聊天式回答的关键区别，不在于内容主题是否复杂，而在于返回结果是否已经具备可呈现、可交互的 UI 结构。
在本文档中的语境
在《实战指南：用 CopilotKit 2 小时构建生产级 AI Agent - 今日头条 摘要》中，生成式UI 被归为 CopilotKit 的核心能力之一，与开箱即用的运行时、上下文感知式业务集成并列。
这一定义不是抽象概念，而是服务于 Agent-Native 应用开发的实际目标：让开发者把精力放在业务逻辑上，而不是围绕 AI 返回结果重复搭建展示层。
文中强调，过去 AI Agent 开发常见痛点之一是 UI 重复造轮子；而生成式 UI 的价值就在于，Agent 的结果可以直接以界面形式嵌入对话流，减少开发者额外为不同结果类型手写展示界面的工作。
在这个语境下，生成式UI 不是单独存在的前端特效，而是 Agent 响应链路的一部分：用户发起请求，Agent 识别意图并调用动作，动作返回数据和界面，前端将其直接渲染到对话中。
关键机制
1. 输出结构从“纯文本”扩展为“文本 + 组件”
文中最核心的实现点，是动作处理函数不必只返回字符串，也可以返回一个对象，其中同时包含：
text：给用户看的说明文字；generativeUI：可直接渲染的组件。
也就是说，Agent 的一次响应可以同时包含“解释”和“呈现”。文本负责说明当前结果，组件负责把结果以更适合理解和操作的方式展示出来。
这比纯文本更进一步：它不是让用户读完说明后再跳到别的页面查看，而是在对话现场把结果呈现出来。
2. 与业务动作绑定，而不是脱离数据源单独生成
文中的示例不是让模型凭空画图，而是把 生成式UI 与业务动作绑定。
以 get_sales_report 动作为例，其处理流程是：
- 动作被用户的自然语言请求触发；
- 处理函数调用接口
fetch('/api/sales/report')拉取销售数据； - 将接口响应解析为数据对象；
- 基于这批真实数据构造图表组件；
- 返回
text与generativeUI。
文中的返回形式明确写成：
text: '以下是最近30天销售趋势：'generativeUI: <SalesChart />
这说明 生成式UI 的核心，不是“模型会写点前端代码”，而是“动作执行完后，直接把结构化业务结果变成界面输出”。
3. 依赖前端组件体系完成渲染
文中示例直接使用 React 组件来承载生成式 UI，并且提到图表实现“需提前安装图表库如 recharts”。
示例里的 SalesChart 是一个 React 组件，内部通过 LineChart、XAxis、YAxis、Line 等图表组件来展示最近 30 天销售趋势。
这说明 生成式UI 的落地前提是：前端运行环境必须支持组件渲染，并且通常与 React 组件体系紧密结合。
换句话说，生成式 UI 并不是任何对话接口天然自带的能力；如果前端只能显示纯字符串，或者没有组件渲染机制，那么 generativeUI 这一类输出就无从展示。
销售数据案例
文中用“查看最近 30 天销售数据”作为典型示例来说明 生成式UI 的工作方式。
用户触发方式
用户不是点击报表系统中的固定菜单，而是直接用自然语言提出分析请求，例如：
- “查看最近 30 天销售数据”
这体现了 Agent 场景的一个重要特征：分析入口是自然语言，而不是预设表单或固定仪表板。
动作定义
对应的动作名为 get_sales_report，其说明是“生成最近30天的销售数据图表”。
在 handler 中，系统先请求 /api/sales/report 接口，再读取返回的数据。
组件生成方式
拿到数据后，示例定义了一个 SalesChart 组件。这个组件使用折线图来展示数据趋势，关键参数包括：
- 图表宽度
width={600}； - 图表高度
height={300}； - 横轴使用
date字段； - 折线使用
amount字段； - 折线类型为
monotone； - 颜色为
#8884d8。
这表明文中的“生成式 UI”并不是抽象说法，而是落实成一个具体的可渲染趋势图。
返回结果结构
动作最终返回的不是一段描述图表的文字，而是：
- 一段文本：
以下是最近30天销售趋势： - 一个组件：
<SalesChart />
于是，聊天界面里出现的不是“建议你查看图表”，而是图表本身。文中将这种效果概括为“对话即分析”。
价值与意义
1. 减少额外手写 UI 代码
文中明确指出，使用 生成式UI 后，开发者无需再为每一种 AI 结果单独写一套外部展示逻辑。
对于销售趋势这种场景，如果只有纯文本回复，开发者往往还要补一层报表页面、卡片组件或弹窗逻辑，把数据再转成图表。生成式 UI 则把这一步并入 Agent 响应本身，降低了从“模型给出结论”到“用户看见结果”的中间开发成本。
2. 让结果直接可视化呈现
销售数据、订单信息、流程引导等内容，往往天然适合结构化展示。
如果只用文字回复，用户需要自行从一大段描述中提炼关键信息；而图表、表格、按钮等组件可以直接承担信息组织与交互入口的作用。
因此，生成式UI 在 Agent 场景中的价值，不只是“更好看”，而是“更直接、更低认知负担”。
3. 让业务动作与对话体验合二为一
文中整体想解决的问题之一，是传统 AI 输出与应用状态割裂，难以实现“边对话边操作”。
生成式UI 与动作机制结合后，用户通过自然语言发起请求，系统调用真实业务接口，随后把结果直接作为界面展示在对话里。
这意味着对话不再只是业务系统的一个说明层，而可以成为业务结果的主入口与承载界面。
组件形式
根据文中描述，生成式UI 可返回的组件形式包括但不限于：
- 图表；
- 表格；
- 按钮。
其中，文中的详细示例使用的是 React 图表组件来实现销售趋势图，但能力范围并不限于图表。
表格适合展示结构化列表数据，按钮适合承接下一步操作或引导流程。因此，这一能力既可用于“展示分析结果”，也可用于“把后续操作嵌入回复”。
细节与边界
1. 它不是对纯文本的替代，而是增强
文中示例保留了 text 字段，说明 生成式UI 并不意味着完全放弃文本。
更常见的做法是：文本负责概述结果、解释当前状态或提示用户如何理解；组件负责承载高密度信息或交互入口。
因此，最佳实践通常不是“只有 UI 没有文字”，而是“文字 + UI”的组合。