GPT-6引爆生成式UI后，下一层缺口是生成式工作流

从生成答案到生成界面

GPT-6 推出的 Intelligent UI 功能，标志着人机交互方式的一次关键转变。过去很长一段时间里，AI 主要生成文本、代码或答案；而现在，它开始为任务本身生成界面——图表、表单、按钮、交互组件，以及围绕用户目标动态拼装的临时工具。

这种转变被社区称为"生成式 UI"（Generative UI）。它让软件不再是预先设计好的固定形态，而是根据用户当下要做的事情即时组装。一个 Reddit 上的讨论精准地指出了这个趋势的意义：AI 不再只是回答问题，而是在为问题创造合适的操作面板。

但正是在这个节点上，一个更深层的问题浮出水面：界面背后发生了什么？

reddit source: GPT-6 just made Generative UI mainstream. We think the next missing layer is Generative Workflow.

界面好生成，系统难生成

生成一个界面相对容易描述，但生成真正"干活"的系统却是另一回事。原文举了一个典型例子：

"分析这家公司的财务数据，找出异常变化，与上季度对比，并生成一份管理层摘要。"

生成式 UI 可以把结果呈现为图表、表格、控件和交互式解释。但在界面之下，系统仍然必须完成一系列硬核工作：

检索正确的数据
对数据进行转换和校验
执行多个分析步骤
在步骤之间维护状态
调用外部工具或 API
产出中间结果
允许用户修改某个特定步骤
再次执行被修改后的流程

这已经不再像一个传统的 UI 系统，而更接近一个工作流编译器 / 运行时（workflow compiler/runtime）。换句话说，界面只是冰山一角，真正决定能力上限的是底层的执行逻辑。

工作流编译器/运行时（workflow compiler/runtime）这一概念源自编译器理论与流程引擎领域的交叉。传统工作流引擎（如 Apache Airflow、Temporal）负责将预定义的有向无环图（DAG）调度执行，管理步骤间的依赖、重试、状态持久化；而"编译器"这一比喻则强调：用自然语言或高层意图描述的需求，需要被"编译"为一套可机械执行的低层操作序列。将两者结合，意味着系统不仅要能执行工作流，还要能从意图动态生成工作流结构本身。这与传统 RPA（机器人流程自动化）的关键区别在于：RPA 流程是人工预先录制或编写的，而生成式工作流中的执行图谱是 AI 实时推断产生的。这种"生成+执行"的双重能力，正是当前大多数 AI 助手缺失的环节——它们能描述怎么做，却没有一个可被检查、修改和重跑的执行载体。

两个必须被区分的层

原文提出了一个很有价值的概念划分，这可能成为下一代智能体系统的重要分野：

生成式 UI（Generative UI）

解决的是用户如何与生成出来的应用交互。它关注呈现层：怎样把结果和操作入口以最合适的形态展示给人。

生成式工作流（Generative Workflow）

解决的是生成出来的应用如何真正完成任务。它关注执行层：数据怎么流动、步骤怎么编排、状态怎么维护、工具怎么调用。

把这两层区分开来之所以重要，是因为它们解决的是完全不同性质的问题。UI 层是"看得见"的交互契约，工作流层是"看不见"的执行引擎。只优化前者，智能体永远停留在"演示很酷、落地很虚"的尴尬处境。

值得注意的是，"生成式 UI"这一概念在业界已有具体的技术实现参照。Vercel 的 AI SDK 中的 streamUI 原语、Vercel v0 以及 Anthropic 推出的 Artifacts 功能，都是生成式 UI 的早期形态——它们让 LLM 能够直接输出可渲染的 React 组件或交互界面，而非纯文本。这些实践验证了"界面可以被实时生成"这一假设，但也同时暴露了文章所指出的问题：这些工具优化的依然是呈现层，生成出来的界面背后通常仍是一次性的、无状态的代码片段，缺乏对应的执行层抽象。因此，当前生成式 UI 的繁荣，恰好为生成式工作流的缺位提供了反衬。

从 prompt→answer 到 intent→execution 的范式

真正令人兴奋的是，这两层最终可能被一起生成。交互范式会从简单的：

prompt → answer

演进为一个带反馈闭环的循环：

intent → UI + workflow → execution → feedback → workflow update → better execution

这个闭环的意义在于，执行过程不再是黑盒。用户表达意图后，系统同时生成界面和背后的工作流；执行之后，用户的反馈可以直接回灌到工作流本身，驱动它更新并产出更好的结果。

这也改变了我们对"智能体技能"（agent skills）的理解。一个技能不必再是一段静态的提示词或指令集，它可以成为一个活的、可执行的工作流——能够被检查、修改、重放，并基于用户反馈不断进化。这是一个相当有想象力的视角：技能从"文本模板"升级为"可运行、可演化的程序资产"。

智能体技能（agent skills）目前在主流框架中通常以"工具调用"（tool calling）或"函数调用"（function calling）的形式存在——本质上是一段静态注册的函数签名加上描述文本，供 LLM 决策时选用。OpenAI、Anthropic 等主流平台的 function calling 机制均属此类。文章提出将技能升级为"可运行、可演化的程序资产"，意味着技能不再是一次性的函数调用，而是拥有内部状态、可被局部修改、支持重放的有状态程序单元。这与 LangGraph、AutoGen 等框架尝试引入的"有状态智能体图"方向一致，但进一步要求技能本身能被用户直接检视和干预，而非对用户保持黑盒。这是从"AI 代劳"向"人机协作编程"演进的关键一步。

FlowX：一次开源的早期探索

原文作者所在团队把这个想法落到了一个名为 FlowX 的开源项目中（GitHub: AIpRoBuilder/FlowX）。该项目当前聚焦两件事：

把自然语言需求转化为可执行的工作流；
允许通过对话更新并重新运行单个工作流节点。

第二点尤其契合前面提到的反馈闭环——用户不需要推倒重来，而是可以精确地修改流程中的某一个节点，再局部重跑。这种"节点级可编辑"的设计，正是把工作流当作一等公民、而非一次性产物的体现。

需要说明的是，FlowX 目前仍处于早期实验阶段，更多是作为验证"生成式工作流"这一抽象是否成立的试验田，而非成熟产品。

一个仍然开放的问题

作者最后抛出的，其实是一个比具体实现更大的问题：

如果生成式 UI 是 AI 软件的新交互层，那执行层应该长什么样？"生成式工作流"是正确的抽象吗？还是说智能体系统最终会收敛到别的形态？

这个问题目前没有标准答案。可以确定的是，当界面可以被动态生成之后，社区的注意力正不可避免地从"AI 说了什么"转向"AI 做了什么、怎么做的、能不能被纠正"。谁能把执行层的抽象做对，谁就可能定义下一代智能体的底座。

对于关注 AI 应用架构的开发者来说，这是一个值得提前思考的方向：别只盯着漂亮的生成式界面，真正的护城河往往藏在界面之下的工作流引擎里。