OpenAI Intelligent UI 与 OpenUI：企业应用如何落地生成式 UI

OpenAI 于 2026 年 10 月 7 日发布了 ChatGPT 的 Intelligent UI，将文本与交互式回答结合起来。其实现采用可流式传输的组件和编译器。OpenAI 发布公告

与此同时，在 10 月 8 日核查时，Thesys OpenUI 仓库显示约 10,000 个 GitHub 星标。这说明开发者对它感兴趣，但星标数量无法证明有多少业务流程已经在生产环境中成功运行。

对于产品团队，更有价值的问题是：当用户想根据回答采取行动时，会发生什么？能够解释审批事项的采购助手很有帮助；如果它还能展示对应申请，让用户核查详情，并正确记录审批结果，就有可能省去一次完整的流程交接。

资料核查日期为 2026 年 10 月 8 日。下文中的工作流和评估标准是 Wavect 提出的工程方案，不是 OpenUI 客户部署报告，也不是性能实测结果。

Intelligent UI 和 OpenUI 有什么区别？

Intelligent UI 是 ChatGPT 的一项能力；OpenUI 是可以集成到应用中的框架。OpenAI 的 Intelligent UI 帮助页面介绍了布局和交互方式随问题调整的回答。

Thesys 将 OpenUI Lang定义为一种声明式语言，用于组合应用已注册的组件。模型生成描述，应用负责渲染。本文所说的生成式 UI（Generative UI），指的是在运行时围绕用户任务选择并组织界面。

这与让编码智能体生成一个页面，再由开发者审查并发布的交付方式也不同。运行时生成意味着用户使用产品的同时，系统正在创建新的呈现方式。因此，稳定的交互、故障恢复和组件约束都必须成为产品设计的一部分。

能否通过 API 把 OpenAI Intelligent UI 接入自己的应用？

本次核查的发布公告没有宣布可嵌入应用的 Intelligent UI 渲染器。它介绍的是 ChatGPT 的产品体验。模型 API 与完整的交互式产品界面属于不同的集成契约，不应仅凭功能公告推断存在某个 SDK，再据此规划实现。

如果希望在 ChatGPT 内部提供由开发者控制的界面，OpenAI 另有文档介绍采用 MCP Apps 标准的 MCP 服务器，以及可选的 iframe UI。请参阅其当前 Plugins 文档中的 MCP 服务器与 UI 快速入门。

先决定用户从哪里进入工作流。如果用户已经在客户门户中工作，就在门户里制作交互原型；如果预期入口是 ChatGPT，就评估该宿主的集成方式。企业最终可以同时支持两者，但第一个有价值的实验只需要一个入口。

开发者应该评估哪一个 OpenUI 项目？

本文讨论的是由 Thesys 维护的 thesysdev/openui。仓库列出了 React、Vue、Svelte 和 Angular 运行时，并提供额外的现成 React 界面组件。其开源项目采用 MIT 许可证。托管服务费用与模型推理费用仍需分别考虑。

名称相似的其他项目包括用于生成和预览 UI 代码的 Weights & Biases OpenUI，以及可自行托管的 AI 界面 Open WebUI。比较软件包、示例或部署说明时，应同时核对仓库所有者。

对于现有应用，建议从一个刻意保持精简的组件目录开始。只注册工作流确实需要的摘要、表格、筛选器和确认视图。OpenUI 的组件文档通过数据结构定义和渲染器来定义组件。

我们的建议是：对会产生重要后果的组件，明确其业务语义。由应用控制的 PurchaseApproval 组件可以一致地展示申请、金额、币种和批准的实际含义。如果只是一个文案由模型生成的通用按钮，产品就更难强制保持这种一致性。组件验证之外，仍然需要单独的业务验证。

OpenUI 每次点击都需要调用 LLM 吗？

不需要。OpenUI 可以只生成一次界面，再通过运行时执行受支持的交互。其架构文档将生成与执行分开，并通过 toolProvider 连接工具。

例如，更改日期筛选条件可以更新现有视图并获取最新数据；要求重新设计该视图，则可以再次调用模型。这两类操作适合走不同路径，因为前者是已知交互，后者需要重新组合界面。

查询与修改文档通过 Query 表示读取，通过 Mutation 表示写入。修改操作由 @Run 触发后执行。这为执行流程提供了实用的连接机制，但某项具体操作是否获准，仍必须由服务端决定。

保持工具接口的能力范围足够小。提供“批准现有采购申请”这样的具名操作，并验证参数。不要向生成的界面开放可以执行任意 SQL、访问任意 URL 或运行任意命令的通用端点。读取路径也需要访问检查：看起来无害的表格仍然可能包含其他客户的记录。

尽可能将布局生成与数据获取分开。让获准使用的工具返回当前数值，再由普通代码计算总额。这样可以减少经过模型的业务数据，并避免过期的生成文本看起来像权威信息源。它能否降低成本，取决于实际请求、工具调用和界面重新生成的工作量。

生成式 UI 示例：为采购审批保留稳定的操作边界

设想一个内部请求：“列出等待我审批的采购申请，对比交付日期，让我核查其中一项。”用户应当可以自由浏览列表，但批准某一项采购，必须始终是一项明确且可验证的操作。

1. 加载用户有权查看的内容。后端从已认证会话中确定用户身份和所属组织，返回该用户有权访问的记录、记录当前版本，以及允许执行的动作。
2. 生成有用的呈现方式。模型组合已注册的表格、对比和解释组件。供应商、金额、币种等关键审批详情来自应用中经核查的记录。
3. 由应用控制确认环节。确认组件准确展示即将发生的变更。只有所需数据齐全且验证完成后，组件才可操作；其他内容继续流式传输时，用户输入也应保留。
4. 执行时重新检查。后端验证当前权限、记录版本和允许的状态转换，并通过防重复机制提交操作。
5. 展示已记录的结果。UI 显示后端回执或当前状态。超时意味着结果尚不确定，需要核对；它不能成为编造成功结果或盲目重新提交审批的理由。

应用请求可以包含以下字段。这是针对自有端点的示例契约，不是 OpenUI SDK 语法：

{
  "request_id": "PR-2048",
  "expected_version": 7,
  "operation_id": "8b47e18a-2986-4eb4-94a4-c6466bc12476"
}

服务端从会话中确定操作主体，将操作 ID 绑定到该主体、组织和动作载荷，拒绝冲突的重复使用，并在写入时以原子方式检查记录版本。如果审批详情发生变化，用户必须核查更新后的申请，再次确认。

这一设计遵循在执行前立即检查授权的原则，相关说明见 OWASP 交易授权指南。上面的具体请求字段和工作流则是我们建议的实现选择。

由此带来的设计要求是：进入同一业务操作的所有路径，都必须执行相同的检查。生成的控件、普通页面和智能体工具不能演变成三套不同的权限系统。外围的执行架构选择可参阅我们的 AI 智能体设计模式指南。

OpenUI 状态和业务记录应该保存在哪里？

应主动设计交互状态与业务状态的保存方式，并为它们分配不同的管理责任。OpenUI 的交互指南介绍了通过 onStateUpdate 和 initialState 提供的持久化钩子。存储与重新加载行为由应用负责实现。

保存的界面必须限定到相应用户和组织。重新打开仪表盘时，应获取当前有权访问的数据。已保存的“已批准”标签只是呈现内容，绝不能被当成权威业务系统中确实存在审批记录的证据。

还有一项集成细节需要核对：onAction 处理对话和 URL 动作，而 @Run 等运行时操作由内部机制处理。应在真正执行操作的工具或后端路径中实施业务权限检查，不要假设一个 UI 回调就能拦截所有操作。

OpenUI、A2UI、AG-UI 与 MCP Apps：你需要哪一层？

这些名称对应不同的系统边界。选择依赖之前，先比较自己需要哪项职责。

第一个功能可以复用现有后端，只增加少量渲染器集成。只有遇到实际的连接需求时，才引入另一项协议。判断生成视图是否能帮助用户，并不需要先采用全部协议。

生产环境中的生成式 UI 测试究竟应该验证什么？

OpenUI 自己的可靠性指南也说明了未知组件、不受支持的值、无法解析的引用和生成不完整等问题。页面即使成功显示，也可能缺少完成任务所需的控件或信息。

采购工作流可以采用以下建议验收场景。应使用实际组件库、模型配置和应用后端进行测试。

还要检查键盘操作和屏幕阅读器体验。W3C 说明了为什么焦点顺序必须维持有意义的操作顺序，以及为什么状态消息必须能被辅助技术获取。流式界面尤其需要这些测试：新组件不应打断用户当前的操作位置，写入失败也应得到清晰播报。

什么时候生成式 UI 值得投入？

从改变呈现方式能够减少反复理解或页面跳转的场景开始。适合试点的任务包括探索不熟悉的数据集、比较多个供应商方案，或跨记录调查异常。对于经常执行、流程稳定且熟练用户已经能快速完成的任务，固定表单仍然是很好的基线。

针对同一个任务比较三个版本：当前页面、使用固定回答组件的助手，以及受约束的生成式界面。生成版本只有在充分改善任务完成情况、足以抵偿额外实现和运行成本时，才值得采用。

我们建议衡量首个可用控件的等待时间：从请求发出，到第一个与任务相关的控件具备所需数据、通过验证且能够操作所经过的时间。报告其中位数和 p95。占位内容、标题或尚未完成的按钮都不算。这是我们建议的产品指标，不是行业基准。

同时衡量正确完成率、用户纠正次数、不完整页面、重试次数，以及每个已完成工作流的总成本。OpenUI 发布了自己的生成式 UI 基准测试，但仅比较不同格式的 token 用量，无法确定整个应用的经济性。

每个已完成工作流的成本 = 模型、修复、工具和托管总成本 / 正确完成的工作流数量

在人力方面，还应同步测量人工核查时间。即使后续点击无需推理，也必须计算创建和重新生成 UI 所用的模型调用。更完整的核算方法可参考我们的 AI 智能体单次动作成本指南。

我们的判断是，生成式 UI 正在成为智能体技术栈中一项切实可用的选择。但产品发布和开发者关注度，并不能证明每个企业应用都应该生成每一个页面。更合适的实现可能是一个稳定的产品，只在用户确实受益的地方加入少量可适应任务的视图。

确定试点范围时，请准备一个工作流、一段记录用户目前如何完成它的操作视频，以及有代表性的业务记录。Wavect 的 AI 开发服务可以帮助定义组件目录、集成方式和验收标准。我们的 TwinSoft AI 交付案例展示的是另一项独立产品合作，并非 OpenUI 参考实现。

关于更广泛的技术选型与维护责任决策，请参阅 MVP 技术栈选择指南，或与 Wavect 讨论一个具体的生成式 UI 工作流。