对吴恩达 workflow 概念产品化的思考！

Datawhale干货

作者：鲁力，Datawhale成员

本文摘要

本文针对当前 workflow 类型产品所存在的问题，思考了产品设计的方法论，主要内容包括：将任务进行形式化表达，提出 workflow 的系统设计可以形式化地表达为 DFA 的构造，以及流程节点设计是给定约束条件下的 DFA 状态数量最小化问题。

1.1 背景

大模型发展到今天，大家基本已经达成了一个共识：复杂的工作任务不可能通过单次 LLM 调用来解决。所以吴恩达、Itamar Friedman、Harrison Chase等人一直在提倡 workflow、flow engineering 之类的概念，意在通过多次、分阶段的 LLM 调用、迭代来实现更好的应用效果。

目前，国内外 coze、百度千帆/灵境/客悦、Dify、FastGPT、flowise、langflow 等诸多平台也推出了自己的 workflow 产品，实现了对执行流程进行可视化的低代码编排，以下我们讨论的 workflow 产品化是指这一类型的产品。

1.2 当前 workflow 类型产品存在的问题

目前业界对于 workflow 形态产品的设计理念并未有明确的共识，或者说正在互相借鉴。从实际效果看，目前市面上的 workflow 产品存在 2 点问题：

（1）能力存在明显边界：现实中还有很多工作任务不能够在 workflow 中被复现。

我们以保险行业的一个AI客服场景业务流程为例，目前市面上所看到的所有 workflow 类产品，都无法复现下述场景应用：

1. AI 客服询问用户的年龄、性别、学历等多项基本信息。
2. 信息确认环节：AI 客服判断用户回答信息是否完整——如果完整，才可以进入下一步骤；如果回答不完整，则继续追问缺失信息，如果回答始终不完整，那么应该始终进行追问。
3. 多轮对话环节：根据用户信息，基于保险产品资料介绍，向用户推荐合适的保险产品，并回答用户的疑问（本质上是基于 RAG 的多轮对话）。
4. 一旦识别到用户购买意愿，发送对应产品的下单链接等后续步骤……

（2）受众群体有限：目前 workflow 类产品相比GPTs 类产品而言有更高的技术门槛，受众群体数量小了若干个数量级。

目前的 workflow 产品的发展处于一种“鸡肋”般的尴尬位置——说灵活吧，又不如全代码灵活，研发人员看不上；说易用吧，相比 GPTs 学习门槛明显提高，不懂技术的人学不会。

笔者认为，GPTs 和 workflow 这两大产品类型的背后，是构建 LLM 应用的两种范式——自然语言和形式逻辑。这里我们稍作展开解释。

形式逻辑为我们提供了一个严格的推理框架，但自然语言却超越了这种单纯的逻辑，发展出了微妙的引申含义。

举个例子，以下 A 和 B 两句陈述在形式逻辑上等价，但在语言理解上，B 的话似乎是在反驳和嘲讽。

• A ：我相信我所看到的东西
• B：原来你看不到你不相信的东西

在某些命题上，逻辑和语言的矛盾难以调和。例如，“极限的投影是投影的极限”与“投影的极限是极限的投影”两个命题，在逻辑上等价，而在几何视角下并不等价——集合的极限不存在时，投影的极限可能存在。

这是因为几何定律的语言陈述方式影响了逻辑的理解。动词“是”在语法上区分了主语和谓语，“A 是 B”可解释为首先断言 A 的存在，而 B 的存在以 A 的存在为前提条件。

GPTs 由于采用了自然语言的便利性，降低了门槛，必然会得到更广泛的使用。但是，欲戴皇冠，必承其重，既然使用了自然语言，所以也必须承受自然语言带来的能力约束——用自然语言描述清楚一项复杂工作是非常困难的，没有人能够光用嘴巴教你怎么样造火箭或者量子物理。

要想进一步拓宽上限，就必须采用形式化的表达。

GPTs 和 workflow 没有谁好谁坏，就是两种范式，二者各有所长但没有高低之分，理论上还可以互相调用、取长补短。

尽管目前来看， workflow 仍然具有较高一些的学习门槛，但长期来看，人群定位应该趋同于 GPTs。

我们不应该将workflow 定位于 LLM技术爱好者群体，定位于技术爱好者群体将会让 workflow 产品的发展之路越走越窄，虽然目前还没有办法大幅降低门槛，但如何提高易用性仍然是产品经理需要思考的问题。

1.3 本文主要工作

本文针对目前 workflow 产品能力存在明显边界的问题（我们认为主要原因是缺少产品设计方法论）进行讨论。为了解决这个问题，笔者认为需要厘清以下 3 点：

（1）明确 workflow 产品的设计目标

理论上，整个 workflow 在系统设计时应该是能够处理通用任务的，也就是说它是一个通用图灵机，可以执行任意一个特定的工作任务——无论是人机多轮对话，还是根据人类修改意见不断迭代信贷尽调报告，抑或是一个 AI 保险销售去向客户推销保险产品，都应该能放在一个通用框架下去实现。

现在市面上有些产品细分出了工作流和聊天流等多个类型，笔者认为没有必要。现实世界的真实任务本不存在工作流、聊天流如此泾渭分明的划分，硬生生地强行分类并不合理，也提高了用户学习和使用门槛。

（2）明确“你的”workflow 产品”要解决哪些业务场景下的工作任务。

尽管 workflow 体系在设计时能够处理任意特定任务，是个通用图灵机，但在具体产品落地的时候，workflow 应该包含哪些流程节点，取决于“你的”workflow 产品”要复现哪些现实世界的工作任务（以下简称“任务”）。

以下两种产品设计思路的方向是截然相反的，我们认为应该采取第一种：

1. 现有任务的集合，再决定设计出哪些节点（node）。
2. 先设计出节点（node），再思考我设计出的节点能够完成哪些现实世界的任务。

（3）对“任务”进行形式化定义

每一个设计 workflow 产品的产品经理，或多或少应该都会遇到这样的思索——现实世界中的任务千变万化、数量繁多，到底应该有哪些流程节点（node）？这些节点应该发挥哪些功能？

歌诗合为事而作，设计流程节点固然要先明确整个产品要解决哪些任务。但是这还不够，我们还需要对任务进行形式化的表达。

当我们能够对任务进行形式化表达的时候，就能够思考对各种任务的中间过程状态的拆解以及合并归类的方法和策略，进而设计出合理的流程节点。

如果没有方法和策略作为指引，产品经理很容易自然而然地从技术实现角度出发，去思考目前能够做出哪些流程节点。

经过思考，我们得出了两点结论，这两点结论指引我们对于 workflow 产品的设计：

1. workflow 的系统设计可以形式化地表达为 DFA 的构造。
2. workflow 的流程节点设计是给定约束条件下的 DFA 状态数量最小化问题。

2 正文

2.1 现实世界的任务天然具有状态属性

我们先给出一些基本定义，然后结合具体例子来解释这些定义：

1. 现实世界的任何一个任务，都天然具有状态属性。
2. 任何一个任务至少包含 2 个以上的状态：初始状态和结束状态，此外还可以拥有中间若干过程状态。
3. 当任务处于结束状态时，我们认为任务已完成。

假设我们面对一个“把大象放进冰箱”的任务，对于一般人而言，完成这个任务需要经历以下 5 个状态：

• 初始状态：任务初始状态
• 中间状态 1：冰箱门被打开
• 中间状态 2：大象被在冰箱里
• 中间状态 3：冰箱门被关闭
• 结束状态：任务已完成（当然，我们也可以把 中间状态 3 和 结束状态 合并为一个状态）

我们继续以之前的 AI 保险销售任务为例，一般而言，可能会被划分为以下中间状态：

• 状态 1：AI 已发送开场白
• 状态 2：用户已发送文字
• 状态 3：判断用户输入内容是否包括全部所需要信息（年龄、性别、学历……）
• 状态 4：追问用户缺失信息
• 状态 5：结合保险知识库向用户推荐相关保险产品
• 状态 6：用户已发送文字
• 状态 7：判断用户是否表达购买意愿
• 状态 8：……

2.2 工作流编排的本质是驱动状态的有序流转

当我们有了对任务状态属性的明确定义以后，可以发现，对于任务的工作流编排，本质上是通过使用一些工具（流程节点 node），使得任务有序地抵达若干特定中间状态，最终达到结束状态。

完成一个任务应该需要经历多少个中间状态，取决于两点：

• 流程编排者对于 任务执行过程 的理解
• 系统拥有哪些工具（流程节点）

也就是说不同的人对于任务的理解，以及他所能使用的工具，决定了他可能会将任务的执行划分为哪几个步骤。

以“把大象放进冰箱”任务为例，当我们手里有【机械臂】和【起重机】 2 种工具时，我们可能会划分出以下三个中间状态：

• 用【机械臂】打开冰箱门
• 用【起重机】把大象放进冰箱
• 用【机械臂】关上冰箱门

而当我们拥有【机械臂】、【起重机】和【威震天】一共 3 种工具时，我们可能只使用威震天这一个工具，直接向威震天发送命令“帮我把大象放进冰箱”，而不需要关心威震天的具体执行细节。

最极端的理想情况下，假设我们有一个【万能助手】工具，可以端到端地完成用户交代所有任务，那么整个系统不需要存在中间状态，只有初始状态和结束状态。

2.3 workflow 系统是一个确定有限自动机

给定现实世界的若干类型的任务集合（），如果 workflow 系统能够完成这些任务，那么意味着存在若干流程节点的有序序列，使得任务集合 里的所有任务抵达结束状态。

整个工作流产品可以用五元组来表示：

• 有限状态集合 ：给定任务集合 （包括初始状态、中间状态、结束状态）所包含状态的有限集合。
• 有限流程节点集合 ：workflow 产品所提供的流程节点的集合。
• 状态迁移函数δ ： ，状态迁移函数的值是状态集合 的子集。迁移函数定义了在经过流程节点的处理后，workflow 如何从一个状态迁移到另一个状态。
• 初始状态 ：workflow 的初始状态，
• 结束状态集合 ：任务的结束状态集合，

在自动机理论中，这样的五元组表达是一个自动机。更进一步，如果我们认为一个流程节点在内部配置不同时，可以被当做不同的流程节点，那么这是一个确定有限自动机（DFA）。

2.4 流程节点设计是给定约束条件下的最优化问题

workflow 产品的核心设计内容是流程节点的设计以及相关交互，从产品角度，在能够完成任务集合 的前提下，流程节点设计追求的目标应该是「尽可能简单的流程编排步骤」——对于一个需要完成的任务，编排者能够比较快速地使用系统提供的流程节点进行搭建。

极端理想情况下，每类任务都能用一个流程节点（相当于万能 agent）搞定，这样对于用户的学习和使用成本是最低的。

如果我们用形式化的表达方式，这个问题应该等价于：在给定任务集合 的情况下，通过设计流程节点集合 ，使得 DFA 中的状态集合 的状态数量 最小。

很幸运，自动机理论已经给我们提供了标准的区分表算法 (Myhill-Nerode 定理)来进行 DFA 状态数最小化：通过定义状态的不可区分（indistinguishable）概念，来将不可区分的状态合并为一个状态，达到减小状态数量的目的。

算法 区分表最小化 DFA
输入：DFA (Q, Σ, δ, q0, F)
输出：最小化的 DFA

1. 初始化区分表 T 为 |Q| x |Q| 的布尔矩阵，所有条目初始为 false
2. 对于每个状态对 (p, q)：
    如果 p ∈ F 且 q ∉ F 或 p ∉ F 且 q ∈ F：
        将 T[p, q] 设为 true  // 标记 (p, q) 为可区分

3. 重复直到没有更多条目被标记：
    对于每个未标记的状态对 (p, q) 和每个符号 c ∈ Σ：
        令 δ(p, c) = p' 和 δ(q, c) = q'
        如果 T[p', q'] 被标记：
            将 T[p, q] 设为 true  // 标记 (p, q) 为可区分

4. 构建最小化 DFA 的状态集合 Q'：
    初始化 Q' 为 ∅
    使用未标记的状态对构建等价类，每个等价类选择一个代表状态

5. 设定最小化 DFA 的初始状态 q0' 为 q0 所在等价类的代表状态
6. 设定最小化 DFA 的接受状态集合 F' 为所有包含至少一个接受状态的等价类的代表状态

7. 定义最小化 DFA 的状态转移函数 δ'：
    对于每个等价类的代表状态 r 和每个符号 c ∈ Σ：
        令 s := δ(r, c)
        令 r' 为 r 所在等价类的代表状态
        令 s' 为 s 所在等价类的代表状态
        设定 δ'(r', c) = s'

8. 返回最小化的 DFA (Q', Σ, δ', q0', F')

当然实际情况可能会更复杂，不可能完全按照算法策略进行优化，因为给定任务集合并不是可以完全枚举的，但 Myhill-Nerode 定理仍然可以给产品设计带来一些启发。

比如在给定业务场景下，假如我们发现，知识检索节点处理完成的状态，和 LLM 节点处理完成的状态，是不可区分的，那么它们可以合并成一个 RAG 节点，通过对基础的组件进一步抽象，达到降低使用门槛的目的。

3 结论与展望

3.1 结论

综上所述，本文从目前市面上 workflow 产品的局限问题出发，重新思考了任务的形式化表达，以及对于 workflow 产品的设计方法论，并得出了两条思考结果：

（1）workflow 的系统设计可以形式化地表达为 DFA 的构造。

（2）workflow 的流程节点设计是给定约束条件下的 DFA 状态数量最小化问题。

同时，借助自动机理论中的 DFA 状态数最小化算法，我们也给出了优化节点的策略参考。

3.2 展望

展望未来，我们认为 workflow 的以下方向仍然有提升和改进空间：

（1）降低 workflow 学习和使用成本

包括两方面：

• 一方面，支持通过自然语言描述的方式先创建一个工作流的雏形（类比于当下 GPTs 产品自动生成 prompt），然后允许用户在其基础上二次编辑修改。
• 另一方面，支持通过自然语言描述的方式，创建自定义流程节点，其效果约等于多智能体的工作流编排。

（2）关于成环

一个很有意思的现象是，目前市面上的产品，可能是出于担心死循环或者其他原因，在工作流的编排设计上不支持成环。

我们认为允许成环是有必要的，并且利大于弊的，对于一个 DFA 而言如果不允许其成环，那么它的能力一定是大打折扣的，而且有很多现实场景就是需要循环迭代的（e.g.让 LLM 生成正确的代码），做好相应的兜底措施就好。

（3）人类在工作流中的参与和干预

当前 LLM 的 planning 能力还不够强，所以一部分的 planning 工作仍然需要开发人员/业务专家来承担，允许人类在适当的时候参与进来，指出 LLM 的错误或者下一步应该采取的行动。

举个例子：当工作流执行到某一中间状态时，只要人类专家表达对上一状态 LLM 的生成结果不满意，可以携带专家的修改意见，返回到上一状态让 LLM 对之前的输出进行修正。

（4）多模态 & 动态交互

我们上述讨论的一些场景，以及大模型实际在企业内落地的一些复杂任务，都会要求比较复杂的交互，比如报告生成任务，可能涉及到版本的回退、某一特定章节的修改等等场景。

显然，目前对话的交互形式已经无法承载复杂的工作任务，我们需要继续探索与 AI 的最佳交互方式。

4 致谢

本文灵感来源于 2017 Fall 台湾清华大学资讯工程学系何宗易教授《Formal Language》课程，这并不是门常见的课，在大陆往往会放在编译原理课程的前半部分，介绍形式语言与自动机相关内容。事实上我当时并不知道这门课是干什么的，听起来像是学正则表达式的水课就稀里糊涂去学了。

老实说涉及的理论有点枯燥，感谢何教授的个人魅力，让我在若干年后思考 workflow 产品设计时，依然能想起那些在炎炎夏日里画状态机的日子。

昆明湖畔，蝉声如织，时而高亢，时而低沉，将夏日的繁华与落寞交织在一起。壬戌亭下，绿荫婆娑，月影摇曳，仿佛在低语着青春的故事。