第48章 Generative UI 与富交互¶
DataAgent 工作台里的“富交互”不能理解成多输出几张图、让模型生成几段 HTML。图表如果没有指标口径，表格如果没有字段权限，按钮如果绕过审批，Artifact 如果覆盖证据链，界面越丰富，事故越难复盘。毛利异常分析这类 ChatBI 原型很快会暴露这个问题。用户问“华东区本月毛利异常来自哪些 SKU”，原型返回一段文字和一张柱状图。试点一周后，业务团队会要求筛选门店和品类，财务要把异常分析保存成月度经营说明，数据治理团队要回放 SQL、指标口径、审批记录和导出动作，安全团队会检查敏感字段是否因为模型“画表格”而泄漏。对话框在这个过程中变成工作台，模型输出也变成可操作界面的一部分。富交互层处理的是另一组约束：图表、表格、表单、Artifact 和审批卡片怎样承接消息流、工具进度和前端协议。工具结果不能只是被推送到前端，还要进入可操作、可审计的界面对象。
很多团队在原型阶段会让模型返回一段 Markdown 表格，或者直接让模型生成 ECharts 配置。演示时这很快，生产时问题也很快：表格字段没有经过权限裁剪，图表轴含义和指标口径没有绑定，用户修改筛选器后没有回写上下文，导出按钮绕过了审批，后续复盘时也不知道用户看到的是哪一版图表。界面越“智能”，平台越要能说明它展示了什么、允许用户做了什么、哪些动作被拒绝、哪些证据进入了报告。
Generative UI 的关键，是让 Agent 在受控协议内选择、填充和编排平台登记过的组件，而不是让模型随手生成界面。模型可以建议“这里适合柱状图”“这里需要审批卡片”“这份报告可以形成 Artifact”，但最终渲染必须经过组件白名单、字段权限、数据引用和服务端策略。否则富交互会从用户体验优势变成新的攻击面和审计盲区。对 DataAgent 来说，富交互还承担“把分析变成工作”的责任。文字回答可以结束一次对话，图表和 Artifact 往往会进入下游流程：业务负责人要保存经营说明，财务要修改措辞并提交审批，区域经理要继续筛选门店，数据团队要回放 SQL 和指标口径。每个动作都要成为事件，进入 trace、审计和评估样本，而非停留在浏览器里的临时状态。本章讨论 Generative UI、可编辑产物、结构化渲染、审批控件、前端契约和 XSS 防护。读者需要把富交互理解成 Agent 平台的一层治理界面：工具调用结果要映射到受控组件，可编辑产物要保留证据链，审批控件要能流转状态，渲染层还要防止脚本注入、越权动作和敏感字段泄漏。从对话 UI 进入 Generative UI 后，界面对象会分化为五类。
表48-1：从对话 UI 到 Generative UI 的能力递进。来源：本书整理。
| 第47章 已具备的能力 | 业界代表 | 第48章 需要补上的富交互能力 | 企业落地边界 |
|---|---|---|---|
| 流式消息和工具进度 | Vercel AI SDK | 将工具结果映射为图表、表格、表单等白名单组件 | JSON 渲染之外，还要绑定字段权限、数据引用和审计 |
| 生产级对话组件 | assistant-ui | 在消息流旁承载可折叠工具卡片、引用面板和操作入口 | 对话组件解决基础交互，不负责业务组件注册、审批和证据链 |
| 应用内 Copilot 与共享状态 | CopilotKit | 让 Agent 读写业务页面状态，并触发表单、筛选器和人在回路卡片 | 组件动作必须和业务系统权限、租户边界、审批策略绑定 |
| Agent 与前端事件协议 | AG-UI | 用事件表达 UI patch、工具渲染、共享状态和 interrupts | 协议只能统一交互语义，企业仍要定义组件白名单、策略和观测字段 |
| 对话旁独立工作区 | Claude Artifacts / OpenAI Apps SDK | 把报告、图表组合、MCP 工具组件做成可编辑、可保存的产物空间 | 需要版本、协作、数据来源、组件安全和访问控制治理 |
表 48-1 指向一个基本判断：Generative UI 的价值不在视觉效果，而在工作界面。它把对话流里的工具过程、业务对象、审批判断和可编辑产物，变成用户能够验证、调整、确认和复用的对象。
表 48-1 保留为能力递进表，是为了把第47章的事件流、消息和工具状态，接到本章的可操作对象上。缺少这个递进关系，团队容易把富交互误解为“把消息渲染得更漂亮”；关系明确后，平台就能逐项检查：组件是否登记，数据是否引用，动作是否鉴权，用户修改是否回写，审计是否能回放。
设计评审时，可以直接把一条工具结果拿来走查：它进入了哪个组件，组件能展示哪些字段，用户能做哪些动作，动作是否需要二次确认，失败后状态如何恢复。只要其中一步回答含糊，富交互就还停留在原型阶段。
48.1 国内企业 Generative UI / DataAgent UI 对比¶
国内企业 Agent 产品也在从“对话生成答案”转向“对话驱动任务界面”。第47章已经讨论了对话入口、应用模式和流式状态，这里更关注工具和组件如何进入可控界面：腾讯元器把 MCP 插件作为可配置能力接入，阿里云百炼 Model Studio 在创建应用时区分 Agent Application 与 Workflow Application，Coze Studio 则把节点输入、变量和试运行表单做成受控配置面。这些界面的共同点不在视觉风格，而在治理方式：模型能力先收敛到工具契约、流程节点、参数表单和运行状态，再进入用户可操作的界面。
腾讯元器的插件广场和 MCP 插件表单，体现的是“外部能力先登记，再进入界面”的路径。DataAgent 的查询、导出、通知和工单动作也应先进入工具注册表，再映射成 UI 卡片，不能让模型在对话中临时拼接任意外部调用。MCP 插件接入只解决协议和发现问题，租户鉴权、动作审批、审计留痕仍属于企业平台边界。阿里云百炼 Model Studio 把 Agent Application 与 Workflow Application 放在创建入口，强调任务容器的差异。自主决策型任务适合在对话中生成组件，流程明确的任务更适合进入工作流工作台和节点状态回放。Coze Studio 的节点试运行表单则说明，表格、图表、表单和审批卡片都应能回到工具输入、输出和日志，而非只在最终消息里展示一个静态结果。
图48-1：腾讯元器接入 MCP 插件的配置表单。来源：产品界面截图。Alt text：表单展示 MCP 服务地址、鉴权方式、工具列表等配置项，体现国产 Agent 平台集成外部工具的典型 UI 交互方式。
把工具能力放进界面之前，平台要先知道这个工具是谁、能做什么、暴露哪些参数。图 48-1 把名称、描述、URL 和高级选项都做成受控字段，正好对应企业 DataAgent 的工具注册要求：模型不能临时拼接任意外部调用，工具注册、Schema 校验、权限和渲染组件要在同一条链路里绑定。
图48-2：阿里云百炼 Model Studio 的应用类型创建界面。来源：产品界面截图。Alt text：界面展示对话助手、工作流助手等应用类型卡片，每类标注适用场景，体现企业 Agent 平台按任务形态提供差异化模板的 UI 设计。
任务形态不同，界面容器也不同。图 48-2 把 Agent Application 和 Workflow Application 的分流放在创建阶段，这个细节对平台设计很有价值：自主决策型任务适合对话内组件，流程明确的任务更适合工作流工作台和节点状态回放。Generative UI 要先判断任务该落在哪种容器里，不能把所有组件都塞进聊天窗口。
图48-3：Coze Studio 单节点试运行表单。来源：产品界面截图。Alt text：表单展示节点名称、输入参数填写区、运行结果展示区，体现低代码平台对工作流节点的调试 UI，输入参数、看输出结果、验证单步逻辑。
调试体验也应围绕契约展开。图 48-3 把输入、变量类型和运行按钮放在同一个单节点试运行表单里，给企业工作台一个很具体的参照：Schema、表单、运行结果和日志要能被同一个工具节点串起来。把工具日志原样塞回对话气泡，只会让调试和审计都变得更难。
48.2 任务化交互界面¶
企业 Agent UI 的演进通常从任务化交互开始，而非从聊天框直接跳到“自动生成完整应用”。用户要完成的是业务任务：分析异常、生成报告、提交审批、导出数据、修正字段映射、确认下一步动作。企业 DataAgent 工作台可以拆成六类任务入口。任务入口要和组件生命周期绑定。异常分析里的图表可能只服务当前会话，也可能被保存进经营报告；参数修正里的表单会影响下一次工具调用；审批确认会改变 Run 状态；协作交接会把上下文带到工单或消息系统。前端如果只把这些对象当作消息附件处理，用户看起来能操作，后台却无法知道哪个动作改变了业务状态。更稳的方式是让每个组件都有 component_id、data_ref、allowed_actions、state 和 trace_id，用户动作都通过 Runtime 或 Policy 回写。
富交互也会改变错误处理方式。普通文本回答出错，前端可以展示重试；图表出错，系统要区分是查询失败、图表配置错误、字段权限不足，还是数据量太大；Artifact 保存失败，用户需要知道草稿是否还在本地、是否已经进入审阅、是否会覆盖旧版本；审批卡片失败，则要明确审批请求有没有送达、是否超时、是否可以转派。Generative UI 越接近业务动作，错误状态越要细。
表48-2：DataAgent 工作台任务入口。来源：本书整理。
| 任务入口 | 用户真实意图 | Generative UI 承载什么 | 下游系统 |
|---|---|---|---|
| 异常分析 | 找出毛利、库存、履约异常的原因 | 图表、表格、口径说明、钻取入口 | 数据仓库、指标平台、告警系统 |
| 经营报告 | 把分析结果整理成月报或周报 | 可编辑 Artifact、图表引用、版本记录 | 报告系统、文档系统 |
| 参数修正 | 修改时间范围、门店、品类、指标口径 | 筛选器、表单、推荐参数 | Semantic Layer、Tool Registry |
| 审批确认 | 执行导出、下发任务、触发补货建议 | 审批卡片、影响范围、证据列表 | Policy、Workflow、审计系统 |
| 数据核验 | 确认字段映射、异常数据、缺失口径 | 表格、字段解释、质量提示 | 数据治理平台 |
| 协作交接 | 转交给财务、运营或区域负责人 | 评论、任务状态、引用上下文 | 工单、消息系统、任务系统 |
表 48-2 的分层把讨论拉回业务任务。企业工作台的每一个控件都可能连接工具、权限、数据和审计。图表背后有 data_ref、指标口径和查询快照；按钮背后有动作权限、审批策略和 trace；Artifact 是可编辑、可复用、可归档的业务产物，不是更大的消息气泡。
在企业语境里，Generative UI 可以定义为：Agent 在受控协议内选择、填充和编排平台已登记的 UI 组件。模型不负责写前端代码；它负责把工具结果以业务对象的形态送进界面。这个定义还隐含一个产品约束：组件必须少而稳。早期平台不需要支持几十种图表、复杂画布和任意自定义控件。它更需要把少数高频组件做扎实：图表能说明口径和数据来源，表格能处理权限和大结果，表单能回写参数，Artifact 能保留版本和证据，审批卡能记录责任。组件数量过多会让模型选择更难，也会让安全审计和回放成本上升。
组件白名单还要配合设计系统。企业工作台里的图表、表格、审批卡和 Artifact 不应由每个业务团队各画一套，否则用户在不同 Agent 之间切换时会重新学习状态含义，安全团队也很难统一审计。平台应给每类组件定义统一的空状态、加载态、错误态、权限拒绝态和审批态。这样富交互不会变成一组漂亮但互不兼容的页面，而是能被复用、测试和监控的平台能力。
48.3 工具调用渲染模式¶
Generative UI 的边界必须在 L1 就讲清楚。企业平台不应让模型直接决定 DOM、脚本、下载链接或业务动作，而应让模型输出结构化意图，再由前端和服务端共同校验后渲染白名单组件。
表48-3：Generative UI 渲染契约与治理边界。来源：本书整理。
| 概念 | 定义 | 与相邻概念的区别 |
|---|---|---|
| Generative UI | LLM 或 Agent 根据任务上下文选择并填充受控 UI 组件 | 不等同于模型生成任意前端代码 |
| 工具调用渲染 | 将 Tool Call 的输入、状态和输出映射为卡片、图表、表格或表单 | 不等同于把工具日志原样展示给用户 |
| Artifact | 对话之外的可编辑、可保存、可复用产物，如报告、分析说明、代码或图表组合 | 不等同于消息附件，它有生命周期和版本 |
| 业务控件 | 与业务动作绑定的筛选器、按钮、表单和审批组件 | 不等同于装饰性 UI，它会触发权限和审计 |
| 组件白名单 | 平台允许 Agent 引用的组件类型、字段、版本和动作集合 | 不等同于前端组件库全集，默认应最小化暴露 |
| 审批卡片 | 在高风险动作前展示影响范围、证据和确认入口 | 不等同于普通确认弹窗，它需要留痕和策略绑定 |
工具结果到 UI 的最小链路应是：工具执行产生结构化结果，Runtime 为结果附加权限和证据，Render Contract 决定可渲染组件，前端根据组件白名单和用户权限渲染，用户动作再回到 Policy 和 Observability。任何一步跳过，都会让界面变成安全薄弱点。Render Contract 还要处理“看得见”和“能操作”的差异。用户可以看到一张聚合图，不代表可以下载明细；可以编辑报告草稿，不代表可以发布到外部；可以看到审批卡，不代表可以批准。组件契约里应把 visible_fields、available_actions、approval_required 和 audit_level 分开。这样前端不会把权限简化成一个布尔值，后端也能在用户点击动作时再次校验。企业渲染对象通常分成五类。
表48-4：工具结果可映射的受控渲染对象。来源：本书整理。
| 渲染对象 | 典型输入 | 用户动作 | 必要控制 |
|---|---|---|---|
| 图表 | 聚合数据、图表规格、指标口径 | 切换维度、钻取、导出图片 | 显示口径、限制维度、保留数据快照 |
| 表格 | 查询结果、字段解释、脱敏状态 | 排序、筛选、复制、下载 | 字段级权限、行数上限、导出审批 |
| 表单 | 工具参数、业务动作参数 | 修改参数、提交任务 | Schema 校验、服务端二次鉴权 |
| Artifact | 报告、方案、代码、长分析 | 编辑、保存、提交审阅、导出 | 版本管理、证据链、协作权限 |
| 审批卡片 | 高风险动作、影响范围、证据列表 | 批准、拒绝、转派、补充意见 | 强制留痕、策略绑定、状态回放 |
表 48-4 划出的边界很直接：模型可以建议组件和数据绑定，但不能绕过组件注册表；模型可以建议动作，但不能直接执行高风险动作；模型可以生成报告草稿，但不能覆盖底层证据。这条边界对安全很关键。模型生成的 Markdown 里可以写“点击这里导出全部客户明细”，但真正的导出按钮必须来自组件注册表和策略引擎；模型可以在报告里建议“下发补货任务”，但补货动作必须进入审批卡和工作流；模型可以解释某张图的异常，但图表数据仍要通过 data_ref 受控读取。把文字建议和业务动作拆开，富交互才不会变成 prompt 注入的放大器。
48.3.1 受控渲染容易被绕开的地方¶
受控渲染最容易在五个位置被绕开。第一，让模型直接生成 HTML/JS，原型很快，但生产环境会引入 XSS、越权动作和审计缺口；模型应只输出组件意图，平台按白名单渲染。第二，用图表数量制造专业感，但没有口径、来源和样本范围的图表会放大错误结论；每张图都要绑定指标口径、数据快照和证据引用。第三，把 Artifact 当成消息附件，报告一旦进入业务流程，就会缺少版本、权限和审批记录；Artifact 必须独立管理生命周期。另外两个问题更偏工程治理。高风险按钮如果只在前端隐藏，用户或脚本仍可能绕过界面直接调用动作，所以所有业务动作都要在服务端二次校验。历史消息回放也不能忽略，组件升级后如果旧消息不可读，审计就无法复现当时用户看到的内容。平台要保留组件版本，必要时把旧组件降级为静态摘要。
48.4 Artifacts 与可编辑产物¶
Generative UI 位于 Tool Registry、Policy、Runtime、Observability 与 Console 的交汇处。后端负责工具执行、权限判断、结果结构化和审计留痕；前端负责按白名单渲染、展示证据链、收集用户确认和反馈。稳定架构不应让模型输出直接进入页面，而应由 Render Gateway 或 Conversation API 把内部事件转换成受控渲染契约。
图48-4：Generative UI 在企业 Agent 平台中的位置。来源：本书自绘。Alt text：分层图中 Generative UI 位于 Agent 与用户之间，向下订阅工具调用结果和状态事件，向上展示富内容并把用户编辑回写给 Agent，标出它比普通对话 UI 多出的渲染与交互职责。
图 48-4 展示了三个边界。Tool Registry 返回的是工具能力和结构化结果，不是前端组件；组件选择要经过 Render Contract，避免工具开发者把内部日志、敏感字段或调试参数直接暴露给用户。Policy 不只管后端工具执行，也要管前端动作；导出、提交审批、转派任务、保存 Artifact、复制明细都属于业务动作，必须和用户、租户、数据范围、风险级别绑定。Observability 还需要记录用户看到的界面状态，平台要知道用户看到了哪张图、展开了哪张表、修改了哪个参数、批准了哪个动作。
48.5 业务控件与数据可视化¶
企业 Generative UI 的组件划分建议保持克制。组件越多，表达力越强，但越难治理。早期可以从 chart、table、form、artifact、approval_card 五类开始。
表48-5：Generative UI 组件职责与失败模式。来源：本书整理。
| 组件 | 职责 | 输入 | 输出 | 失败模式 |
|---|---|---|---|---|
| Render Gateway | 定义工具结果到 UI 组件的映射 | tool name、Schema、result、policy | 渲染契约 | Schema 不匹配、组件缺失 |
| Component Registry | 维护允许 Agent 引用的组件白名单 | component type、版本、权限 | 组件定义 | 版本冲突、越权组件 |
| Chart Renderer | 渲染图表和数据摘要 | 数据集引用、图表规格、口径 | 图表卡片 | 数据过大、图表误导 |
| Table Renderer | 渲染表格、字段说明和脱敏状态 | 行列数据或 data_ref |
表格卡片 | 敏感字段暴露、浏览器卡顿 |
| Artifact Workspace | 编辑和保存长产物 | Artifact 文档、证据引用、版本 | 草稿、审阅件、导出件 | 覆盖证据、冲突编辑 |
| Approval Flow | 高风险动作确认和审批 | 动作、影响范围、证据 | 审批状态 | 审批绕过、状态不一致 |
| UI Telemetry Adapter | 记录前端交互和渲染状态 | trace、组件状态、用户动作 | 指标、日志、回放索引 | trace 断链、隐私字段泄漏 |
示例渲染契约如下。它描述的是后续实现可以采用的接口形态，不代表当前仓库已经实现完整 API。
{
"render_id": "render_margin_chart_001",
"conversation_id": "conv_20260609_001",
"message_id": "msg_042",
"tool_call_id": "call_margin_analysis_01",
"tool_name": "analyze_margin_by_sku",
"component": "chart",
"component_version": "1.0",
"title": "华东区毛利异常 SKU 分布",
"data_ref": "dataset://retail-demo/margin-analysis/20260609/run_001",
"spec": {
"chart_type": "bar",
"x": "sku_name",
"y": "gross_margin_delta",
"color": "category",
"limit": 20
},
"evidence": {
"metric": "gross_margin_delta",
"time_range": "2026-06-01/2026-06-09",
"sql_ref": "sql://trace_abc/query_003"
},
"actions": ["drill_down", "export_png"],
"policy": {
"mask_fields": ["customer_phone"],
"requires_approval": false,
"allowed_roles": ["retail_manager", "finance_analyst"]
},
"trace_id": "trace_abc"
}
工具结果到受控组件的映射如下。
图48-5：工具结果到受控组件的渲染契约。来源：本书自绘。Alt text：工具调用返回 JSON 结构，前端按 type 字段分发到对应渲染组件（表格、图表、代码块、表单），契约约束双方不得越权改写彼此的数据，体现前端与 Agent 的解耦。
这里最容易被低估的是 data_ref。小表格可以直接随消息返回，大结果必须走引用。data_ref 让服务端在用户展开、筛选、导出时重新做权限和脱敏判断，也避免把大量明细塞进消息流和浏览器内存。
48.5.1 Artifact 生命周期与工作区¶
Artifact 的生命周期建议独立于消息生命周期。消息是交流记录，Artifact 是业务产物。一次对话可以生成多个 Artifact，一个 Artifact 可以被后续对话继续引用，也可以进入审批、导出、归档或废弃流程。经营分析 Artifact 至少要记录四类信息。
图48-6：Artifact 生命周期状态机。来源：本书自绘。Alt text：状态机含 generating、generated、editing、committed、archived 等节点，箭头标出用户编辑、提交、归档触发的迁移，体现可编辑产物的完整生命周期管理。
表48-6：经营分析 Artifact 必需记录。来源：本书整理。
| Artifact 信息 | 示例 | 为什么需要 |
|---|---|---|
| 正文块 | 经营说明、异常原因、行动建议 | 支持用户编辑和协作 |
| 证据块 | SQL、图表参数、指标口径、数据快照 | 支持审计和复现 |
| 编辑记录 | 模型生成、用户修改、审批意见 | 区分机器建议与人工判断 |
| 状态记录 | draft、reviewing、approved、exported、archived | 支持工作流和追责 |
可编辑产物不应覆盖原始证据。DataAgent 生成的经营分析报告可以允许用户修改措辞，但 SQL、指标口径、数据快照和图表生成参数必须作为证据链保留。业务可以润色表达，审计时仍能回到当时的事实基础。
48.6 UI 安全与审批流程¶
工具调用渲染比纯文本回答风险更高，因为它会诱导用户点击按钮、提交表单、导出数据或保存结论。高风险 UI 必须由策略引擎约束，而非由模型自由决定。
图48-7：UI 安全与审批时序。来源：本书自绘。Alt text：时序图展示 Agent 产生高风险动作时前端弹出审批控件、用户确认或拒绝、确认后 Runtime 继续执行，拒绝后任务暂停，体现审批在 UI 层的完整交互。
Generative UI 的故障常见于组件授权、契约版本、图表口径、审批绕过和导出权限。表 48-7 将风险放到渲染、审批和导出链路中，便于前端按统一策略处理。这条安全边界的核心原则是：模型可以表达意图，平台决定是否允许；前端可以呈现入口，服务端决定是否执行；用户可以编辑产物，但证据链不能被覆盖。
表48-7：Generative UI 风险点与平台处理方式。来源：本书整理。
| 风险点 | 触发条件 | 平台处理方式 |
|---|---|---|
| 组件越权 | 模型请求渲染未授权组件或动作 | 拒绝渲染，降级为安全摘要 |
| Schema 漂移 | 工具输出字段与组件版本不匹配 | 使用版本化契约，前端展示兼容错误 |
| 图表误导 | 模型选择不合适图表或隐藏分母 | 显示图表规格、指标口径和样本范围 |
| 审批绕过 | 前端直接调用业务动作 | 所有动作服务端二次校验，前端只提交意图 |
| Artifact 污染 | 文档内容中的提示注入被写入报告 | 标记生成来源，高风险段落要求人工确认 |
| 数据泄漏 | 表格导出绕过字段脱敏 | 下载走服务端导出任务，按权限重算数据 |
| 旧版本不可回放 | 组件升级后历史消息渲染失败 | 组件版本保留兼容层，必要时降级为静态摘要 |
图48-8：模型输出与前端渲染之间的安全边界。来源：本书自绘。Alt text：模型输出经过 HTML 转义、CSP 限制、沙箱隔离等安全层才渲染到 DOM，箭头标出每道过滤关卡，防止模型生成的恶意脚本执行。
48.6.1 渲染安全的产品与工程约束¶
模型生成代码与组件白名单¶
生产系统不应让模型直接生成任意 HTML/JS。它表达力强、原型快，但安全边界差，权限审计和漏洞复盘都很困难，只适合隔离沙箱内的实验。企业默认路径应是组件白名单与模型生成配置结合：模型输出受控 JSON，前端只渲染平台允许的图表、表格、表单、报告块和审批卡片；表达力受限的问题，通过持续扩展组件库解决，而非把执行权交给模型生成代码。
对话内卡片与独立 Artifact 工作区¶
对话内卡片适合小图表、短表格和审批提示，因为上下文连续、用户理解成本低；独立 Artifact 工作区适合报告、方案、代码和长分析，因为这些产物需要编辑、审阅、导出、版本和权限；外部系统跳转适合成熟 BI/ERP 操作，但会带来上下文割裂和 trace 拼接成本。DataAgent 工作台应同时支持前两种形态：小结果留在消息流，长报告进入 Artifact，外部系统只在复用已有业务能力时使用。
前端直接渲染数据与数据引用渲染¶
前端可以直接携带小型摘要表，以换取首屏速度；但大结果、敏感字段和可导出数据应使用 data_ref。data_ref 多一次数据获取，却能在渲染时重新计算权限、分页、脱敏和下载审计，适合企业数据分析。静态截图可以用于报告归档和外部分享，但不可交互、难审计，不应替代数据引用。这个边界要写进渲染契约，否则前端很容易为了体验把完整工具结果直接塞进消息 JSON。
前端工具调用与后端工具渲染¶
前端工具调用可以读取页面状态、切换筛选器和完成低风险 UI 动作，但它很容易绕过后端治理。涉及数据查询、导出、写入、审批和外部系统调用时，应由后端工具执行并返回受控渲染对象，前端只负责展示和确认。业务系统内 Copilot 可以采用混合模式：前端提供当前页面状态，后端决定可执行动作并记录审计。这个模式契约更复杂，但能同时保留体验和治理边界。
48.7 富交互产物的版本治理¶
Generative UI 把 Agent 输出从文本扩展为图表、表格、表单、Artifact 和审批卡片，随之而来的问题是版本治理。组件版本、渲染契约、数据引用、用户编辑和审批状态都会影响最终产物。若这些信息没有记录，历史消息在组件升级后可能无法重现，报告也无法说明当时依据的图表配置。富交互链路应从工具结果开始，而非从模型“想渲染什么”开始。工具返回结构化结果和证据引用，Render Gateway 根据 ToolSpec、Policy、组件白名单和用户权限生成渲染契约，前端按契约渲染图表、表格、Artifact 或审批卡片。模型可以建议“这里适合折线图”或“需要审批卡片”，但最终能否渲染、渲染哪些字段、哪些按钮可点击，都由平台决定。这样，UI 组件才和工具契约、权限系统、Trace 保持一致。
异常路径要和正常路径同等重要。组件版本缺失时，前端应降级为只读摘要和证据链接；数据引用过期时，应提示重新计算或请求授权，而非静默显示旧数据；用户权限变化后，历史 Artifact 可以保留文本摘要，但敏感表格和下载按钮必须重新鉴权；审批状态冲突时，前端只能展示当前后端状态，不能根据本地旧状态继续提交动作。Generative UI 一旦能触发业务动作，就必须把这些恢复路径写入渲染契约。
组件白名单要和工具契约一起维护。工具返回什么结构，前端允许渲染什么组件，用户可以触发哪些动作，三者必须匹配。模型不能直接指定任意组件或按钮，Render Gateway 应根据 ToolSpec、Policy 和用户权限生成渲染契约。这样即使模型输出异常，也只能落到安全摘要或兼容错误，而不会直接进入 DOM 或业务动作。Artifact 的编辑记录要区分机器和人工。模型生成草稿、用户修改措辞、审批人调整结论、系统重新生成图表，这些动作都应保留版本。业务报告进入外部会议或归档后，平台要能说明哪些结论来自数据计算，哪些文字经过人工修改，哪些证据在发布后发生过变化。富交互还需要降级策略。组件加载失败、权限变化、历史版本不兼容时，前端应能降级为静态摘要、证据链接或只读报告，而非让整条消息不可读。这个策略会影响审计体验，也会影响长期知识沉淀。Generative UI 的成熟度，不在组件数量，而在产物能否长期可读、可审计、可复用。
从运行角度看，Artifact 还要参与 Trace。一个经营分析报告被生成、编辑、审批、导出后，Trace 中应能串起原始问题、工具调用、图表规格、数据引用、用户编辑、审批意见和导出记录。否则 Artifact 会变成对话之外的孤岛：用户看到的是正式报告，平台看到的却只是一段已经结束的聊天消息。富交互的真正价值，是把 Agent 输出变成可持续维护的业务产物，而非把消息渲染得更漂亮。这能减少误解。
48.8 Artifact 发布边界与长期维护¶
Artifact 一旦离开对话窗口，就进入企业内容治理。经营分析报告可能被发到会议系统，报价草稿可能进入审批流，SQL 草稿可能被保存成指标查询，图表可能被嵌入周报。发布边界要在生成时就设计清楚：哪些产物只能留在会话里，哪些可以保存到个人空间，哪些可以进入团队空间，哪些可以对外导出，哪些必须经过审批。若这些边界只靠用户习惯判断，Generative UI 会把模型生成的临时内容推到正式业务流程里，后续很难追溯责任。
发布前应做两类检查。第一类是证据检查：Artifact 中引用的数据、文档、指标、SQL、图表和人工修改是否仍然可见，是否有版本，是否存在权限变化。第二类是动作检查：发布、导出、发送、归档这些动作是否由后端确认，是否带有审批状态和审计记录。一个报告编辑器可以允许用户改写表达，但不能让用户通过复制粘贴绕过指标口径和数据权限。一个图表可以允许切换展示方式，但不能让用户隐藏分母、样本范围或筛选条件。富交互越接近正式产物，越需要把证据和动作分开治理。
长期维护还要处理“旧产物如何继续可读”。组件库会升级，图表库会替换，数据引用会过期，权限会变化。平台不能因为前端组件升级就让历史报告打不开，也不能因为用户权限降低就继续展示敏感明细。可行做法是同时保存渲染契约和只读摘要：当旧组件仍兼容时按原样渲染；当组件不兼容时展示静态摘要、证据链接和重新生成入口；当权限变化时保留产物元信息，但重新鉴权敏感数据。这样历史产物既不会完全失效，也不会突破新的安全边界。
Artifact 的反馈也要进入平台。用户编辑某段结论、删除某张图、改写一条建议、驳回一次导出，都说明模型或工具链存在可改进之处。平台应把这些反馈与 run id、artifact id、component type、evidence ref 和用户角色关联起来，供评测和产品运营使用。若多数用户都删除某类图表，可能是图表选择策略有问题；若用户频繁改写指标解释，可能是语义层说明不足；若审批人反复退回同类导出，可能是风险文案和权限策略需要调整。Generative UI 的长期价值，来自这些产物维护记录，也来自生成界面本身。
早期平台可以先建立最小 Artifact 发布协议。协议只需要覆盖几件事：产物类型、产物版本、来源 Run、证据引用、可执行动作、审批要求、导出策略和回滚方式。每个富交互产物都按这份协议进入工作区，前端组件和后端治理就有了共同语言。后续无论扩展更多图表、表单、报告块还是审批卡片，都能沿着同一套生命周期管理，而不会让每个业务系统各自定义一套临时交互规则。
48.9 富交互产物的运营复盘¶
Generative UI 上线后的复盘范围要覆盖渲染成功率和产物使用情况。一个图表被生成后，用户是否改了指标、隐藏了某个维度、删除了图表、导出了报告、提交了审批；一个报价草稿生成后，哪些字段被销售修改，哪些折扣被审批人退回，哪些证据链接被打开；一个 SQL 草稿进入 Artifact 后，是否被保存成可复用查询，是否因为权限或口径问题被拒绝。这些行为比一次生成结果更能说明组件契约是否合理。
运营复盘应把反馈落回平台能力。用户频繁删除某类图表，可能说明图表选择规则不合适；用户频繁改写指标解释，可能说明语义层说明不足；审批人反复退回同类导出，可能说明风险提示和审批条件不清；历史 Artifact 经常打不开，说明组件兼容和静态摘要策略不足。复盘材料应包含 run_id、artifact_id、组件版本、数据引用、证据引用、用户编辑和审批结果。这样前端团队、平台团队和业务 owner 才能围绕同一份证据改进。
富交互产物还需要维护责任。组件库升级由前端团队负责，但旧产物是否可读由平台和内容治理共同负责；指标解释来自数据团队，图表呈现来自前端，导出权限来自安全策略，审批状态来自 Runtime。若这些责任没有写清，Artifact 会变成跨团队无人真正维护的产物。早期可以先要求每种 Artifact 类型都有 owner、保留期限、导出策略和兼容策略。这个要求看似简单，却能防止 Generative UI 从漂亮界面退化成不可复盘的临时内容。
48.10 富交互组件的兼容测试与降级策略¶
富交互组件上线前，需要准备兼容测试。图表、表单、报告块、审批卡片、数据表格和可编辑 Artifact 都依赖组件版本、浏览器能力、数据结构、权限状态和后端事件。组件在开发环境能渲染，不代表历史消息、旧报告、移动端、只读模式和权限变化后仍然可用。兼容测试要覆盖旧组件版本、旧数据引用、权限降低、证据失效、导出失败和审批状态变化。
降级策略要写进渲染契约。组件加载失败时，可以展示静态摘要、证据链接和重新生成入口；数据引用过期时，可以提示重新计算或申请权限；审批状态不一致时，应以服务端状态为准；历史版本无法兼容时，应保留只读快照和变更说明。前端不能因为某个组件失败就让整条消息不可读，也不能为了保持界面完整而绕过权限。
兼容测试还要服务长期维护。组件库升级、图表库替换、数据域迁移、报告模板调整，都应先跑一组历史 Artifact 样本。样本中要包含不同租户、不同权限、不同组件类型和不同发布状态。通过这套测试，Generative UI 才能从一次生成体验变成可长期保存的业务产物。
48.11 富交互界面的复核职责¶
Generative UI 生成的控件越多，复核职责越要清楚。图表、筛选器、审批卡片、报告段落、导出按钮和任务状态看起来都在同一个界面里，但它们背后的责任来源不同。数据团队负责指标和数据引用，Runtime 负责状态和审批，前端负责组件渲染和可访问性，安全团队负责导出和敏感信息，业务 owner 负责最终发布。界面如果把这些责任混成一个“AI 生成结果”，用户会误以为所有内容都可以像文本一样自由编辑。
复核职责应通过组件契约表达。可编辑段落允许用户改写；指标卡片允许查看口径和刷新；审批卡片只能由有权限的人提交决策；导出按钮要绑定 artifact、权限和保留策略。组件契约越清楚，用户越容易理解哪里可以修改，哪里只能申请变更，哪里必须回到源系统。Generative UI 的长期可用性，取决于这种责任边界能否在界面里自然呈现。
上线验收可以抽查几类风险操作：用户是否能通过修改文本改变指标事实，是否能绕过审批导出 artifact，是否能在权限变化后继续查看敏感图表，是否能从历史报告中追溯数据来源。若这些问题没有被组件契约覆盖，富交互界面会把治理问题隐藏在漂亮的交互层里。
48.12 富交互产物的权限再校验¶
富交互产物保存后，权限还会变化。用户生成报告时有权限查看某张图表，不代表一个月后仍然可以打开同一份 artifact。部门调整、项目结束、客户权限变化和数据脱敏策略更新，都会影响历史产物的可见范围。Generative UI 如果只在生成时校验权限，历史报告和可编辑产物会变成绕过权限的缓存。
权限再校验需要区分元数据和内容。artifact 的标题、创建时间、版本和审批状态可以保留给审计；图表数据、明细表、敏感字段和外部导出则要按当前权限重新判断。若当前用户失去权限，界面可以显示产物存在，但隐藏敏感视图，并提供重新申请或重新生成入口。这样历史材料仍可管理，敏感内容也不会因为曾经生成过而长期可见。
早期可以在打开 artifact、导出 artifact、发布 artifact 三个动作上做再校验。每次校验记录用户、权限版本、artifact 版本和处理结果。富交互界面越接近正式业务材料，这类再校验越重要。
48.13 Artifact 工作区的运行证据¶
Artifact 工作区需要运行证据，因为用户往往会把它当成正式业务产物。生成的报告、可编辑图表、审批卡片或报价草稿，可能比创建它的对话存活更久。平台应记录产物如何创建、使用了哪些证据、哪些用户编辑改变了内容、哪些审批已经完成、后来导出到哪里。没有这些证据，工作区即使看起来完整，一旦离开聊天界面就很难审计。
运行证据要把产物状态和会话状态分开。会话可以归档，报告仍然处于活跃状态；Run 可以结束，Artifact 继续被编辑；用户可能在产物生成后失去源数据权限。因此 Artifact 需要独立生命周期：草稿、复核中、已批准、已发布、已归档、已撤回或已重新生成。每次状态迁移都要记录操作者、原因、时间、策略版本和受影响的证据引用。
这些记录也能帮助产品团队。用户反复重新生成同一类图表，说明默认图表选择可能有问题；复核人认可报告文字却拒绝导出，说明产物在工作区内可用，但还不适合对外分发；业务用户在多份报告里修改同一段指标解释，说明语义层说明需要改进。这些信号比笼统满意度更有价值，因为它们能指向具体组件、动作或证据链路。
工作区还要降低支持成本。用户询问导出的产物为什么和对话内容不一致时，支持人员应能比较 artifact 版本、数据引用、权限结果、人工编辑和导出策略。若每次都要开发人员临时查多个系统，Generative UI 还没有真正进入生产能力。早期的运行证据可以保持轻量，但结构上要让 Trace、Eval、策略复审和客户支持读到同一份产物历史。
48.14 Artifact 多人协作与冲突处理¶
Generative UI 进入企业工作流后，artifact 往往会被多人编辑和复核。一个销售报价草稿可能由 Agent 生成、销售修改、法务加批注、财务确认折扣，最后由经理批准导出。若平台仍把 artifact 当作单人会话里的临时组件，后续冲突会很难解释：谁改了数字，谁删了证据，谁批准了导出，哪个版本被发给客户。多人协作要求 artifact 拥有独立权限、版本、锁定、评论和发布记录。
冲突处理要按内容类型区分。普通文字段落可以允许多人编辑并保留修订历史；图表配置要绑定数据引用和指标版本，不能只保存可视化参数；审批结论、报价金额、合同条款和导出设置这类高风险字段，应使用明确 owner 或锁定机制。若两个用户同时编辑同一图表，平台应能判断是展示层冲突、数据引用冲突还是审批状态冲突。不同冲突需要不同处理方式：展示冲突可以合并，数据引用冲突要重新复核，审批冲突要回到责任人。
Agent 也可能参与协作。用户让 Agent “根据最新意见重写报告”时，Agent 不能直接覆盖人工复核过的段落。更安全的方式是生成候选修改，标注影响的证据引用和字段，再由 owner 接受或拒绝。对于已经发布或审批中的 artifact，Agent 只能创建新版本或修订建议，不能修改原版本。这样可以保留人工责任链，也能避免模型把已确认材料悄悄改掉。
早期可以把 artifact 协作控制在少量规则内：每个 artifact 有 owner，每次编辑形成版本，每次高风险字段变更要求复核，每次导出绑定版本号和权限结果。多人协作能力不必一开始就做成复杂办公套件，但必须保证关键动作可追踪、可回退、可解释。否则富交互界面越像正式业务工具，潜在责任越模糊。
48.15 Artifact 撤回与通知链路¶
Artifact 一旦被下载、导出、嵌入报告或分享给其他团队，就不再只是工作区里的一个组件。后续发现数据口径错误、权限变化、人工审批撤回、图表解释有误或源证据失效时，平台必须能撤回或标记旧版本。没有撤回机制，富交互产物会像普通文件一样在组织里继续流转，用户看到的界面很现代，治理能力却停留在邮件附件阶段。
撤回不等于删除。已发布 artifact 可能需要继续保留审计证据，同时禁止作为当前结论使用。平台应区分“隐藏内容”“标记过期”“撤销发布”“替换新版本”“通知接收者”几类动作。内部草稿可以直接过期，已审批报告需要保留旧版本和撤回原因，外部导出材料需要记录通知对象和补救方式。对于已经被嵌入其他页面或会议材料的 artifact，平台还要能找到引用位置，避免只撤回原始工作区。
通知链路要按影响范围设计。普通图表样式修正可以只通知编辑者；指标口径错误要通知报告 owner 和复核人；权限泄漏或外部导出错误要通知安全、合规和业务负责人。通知内容应说明受影响版本、原因、建议动作和替代版本，而不是泛泛写“产物已更新”。用户需要知道自己是否要重新下载、重新审批、替换会议材料或停止使用旧链接。
早期可以把撤回能力做得简单但明确：每个 artifact 记录发布范围、引用位置、导出记录和接收者；撤回时生成新状态和通知任务；支持人员能从 artifact id 查到影响范围。这样 Generative UI 产物即使进入正式业务流，也仍然能被追踪和纠正。富交互界面的生产价值，不在于生成得快，还在于出错后能按业务责任把影响收回来。
48.16 交互产物的发布前验收¶
Generative UI 产物发布前，应把验收对象从“页面能渲染”提升到“产物能被业务使用”。验收要检查数据引用是否存在、图表是否绑定指标版本、用户编辑是否留下版本、导出是否重新校验权限、审批状态是否来自后端、撤回和通知是否可执行。只看组件是否显示，会漏掉产物生命周期中的责任问题。
验收还要覆盖降级显示。图表渲染失败时，是否能展示表格或数据摘要；权限不足时，是否能保留元数据并隐藏敏感内容；证据失效时，是否能标记结论过期；多人冲突时，是否能提示用户选择版本。富交互界面如果没有降级路径，任何一个组件失败都可能让用户无法继续任务。
早期可以把发布前验收写成 artifact 样本集。每个样本包含输入证据、组件 schema、权限状态、编辑动作、审批动作和预期导出结果。这样设计师、前端、后端、数据和安全团队可以围绕同一个产物样本讨论，而不是分别检查界面、接口和策略。
48.17 Artifact 权限元数据与导出重检¶
富交互产物的权限不能只绑定在整个文档上。一个报告里可能同时包含公开指标、部门敏感指标、客户明细、人工批注和模型摘要；一个仪表盘里可能有可分享的趋势图，也有只能在原租户内查看的明细表。若平台只给 artifact 一个总权限，导出和分享时就会过度放行或过度拦截。更合理的做法是把权限元数据绑定到组件、字段和证据引用上，再由文档级策略做外层约束。
导出重检要重新计算可见范围。用户生成 artifact 时有权查看某些数据，不代表一周后仍然有权导出，也不代表接收者有权查看。平台应在分享、下载、嵌入、发送外部邮件和生成 PDF 时重新校验权限、证据有效期、数据脱敏状态和审批状态。若只有部分组件不满足条件，系统可以生成降级版本：隐藏敏感表格、保留图表摘要、替换为脱敏字段，或要求审批后再导出。
权限元数据还要支持审计和撤回。一个 artifact 被撤回时，平台要知道是哪个组件、哪个证据引用或哪个导出动作导致风险。若只是整份文档标记异常，后续修复会很粗糙；若能定位到具体组件，就可以局部替换、重新审批或通知特定接收者。这样富交互产物的治理粒度才能跟上它的表达能力。
早期可以为每个组件记录四类信息：数据来源、权限级别、证据引用和导出策略。导出前，后端根据这四类信息生成可下载版本，并把校验结果写入 Trace。前端负责展示状态，不能绕过后端重检。这样 Generative UI 不会因为界面更灵活而削弱原有数据权限边界。
48.18 Artifact 模板的复用与失效¶
Artifact 模板会随着业务流程积累。报告段落、指标卡、审批卡、图表布局、导出表单和证据卡片，都可能从一次生成沉淀为复用模板。复用能降低生成成本，也能让用户看到更稳定的产物形态；但模板失效后，错误会被批量复制。一个旧指标口径、旧审批字段或旧导出说明，如果继续出现在新 artifact 中，会让界面看起来规范，内容却不再适用。
模板复用要绑定适用条件。每个模板应记录适用任务、数据域、指标版本、权限要求、组件 schema、最后复审时间和 owner。Agent 选择模板时，应先检查任务条件是否匹配，而不是只根据自然语言相似度挑选。若模板缺少证据引用、权限元数据或降级渲染，就不适合进入正式工作区。
早期可以把模板状态分为草稿、试点、标准、冻结和退役。草稿模板只在当前任务使用；试点模板用于少量场景；标准模板进入平台组件库；冻结模板等待口径复核；退役模板保留迁移说明。这样 Generative UI 的复用会形成资产管理，而不是把一次成功生成复制到所有场景。
48.19 Artifact 生命周期的前端治理¶
Generative UI进入生产后，平台需要把 artifact 状态、模板版本、数据来源、编辑历史、权限、撤回和发布渠道放进统一证据口径。证据口径会减少事后解释成本，让业务、平台、数据、安全和运营团队能够围绕同一组事实讨论问题。没有这些材料，故障发生后只能凭经验判断；有了这些材料，团队可以知道哪些输入有效、哪些动作已经执行、哪些产物可以继续使用、哪些结果需要撤回。
这类证据应和第36章报告、第38章 Trace 和第52章合规连起来。上游章节提供能力基础，下游章节使用运行结果，本章则负责说明中间环节如何被验证。若某个能力只在本章看起来完整，却无法进入 Trace、Eval、发布记录或合规证据包，生产系统仍然会出现断点。读者在实现时应把章节之间的接口看成工程契约，而不是阅读顺序上的相邻关系。
常见风险包括用户把草稿当成正式结果、模板升级改变历史展示、编辑后证据引用失效。这些问题通常不会在一次成功演示中暴露，因为演示样本往往干净、短小、路径明确。真实业务会带来旧数据、异常输入、权限变化、用户撤回、预算限制和长时间运行状态。平台如果没有把这些情况纳入样本和台账，后续扩展场景时就会重复遇到同类问题。
Artifact 前端应表达草稿、复核、发布和撤回状态，使生成式 UI 能被审计。执行记录至少要说明 owner、版本、样本、影响范围、处置动作和复查时间。记录不需要写成流程报告，但要足够让后来者理解当时的判断。对于高风险能力，还应说明哪些条件满足后才能扩大使用，哪些条件失败时必须降级或撤回。
落地时可以先选择少量代表场景建立这种习惯。实践上，应先把高频、高风险、外部可见的路径做扎实，再把样本、台账和复盘方式复制到其他能力中。这样做能让能力说明落到接入、验证、运营和退出，而不是停留在概念描述。
本章小结¶
Generative UI 的生产路径是受控组件渲染，不是任意代码生成。工具调用结果应先结构化，再映射为图表、表格、表单、Artifact 和审批卡片。Artifact 是业务产物，不是消息附件，因此需要版本、权限、导出和审计生命周期。高风险 UI 动作必须经过服务端二次校验，前端不能成为唯一安全边界。企业平台应沉淀自己的渲染契约、组件白名单、数据引用和 UI 观测模型，并与第23章的工具契约、第30章的人工审批、第36章的表达层、第47章的事件模型、第49章的多模态入口和第50章的安全边界配合使用。
参考文献¶
Vercel. (n.d.). AI SDK documentation.
Model Context Protocol. (n.d.). Specification and documentation.
JSON Schema. (n.d.). Specification.
W3C. (n.d.). Web Content Accessibility Guidelines (WCAG) 2.2.