目录

一、什么是 LLM workflow？?

1.1 前言

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

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

1.2 对于 workflow 类型产品定位的思考

我们把 workflow 定位为人类和 AI 协作的一个框架，人类和 AI 共同影响和控制 workflow 的执行流程。基于这个框架，可以实现各种任务类型的应用搭建。

一个 workflow 流程示例

在这个框架中，根据大模型自主规划能力强弱，AI 参与任务规划的比例也会不一样:如果 LLM 的自主规划能力很弱，那么框架中任务执行流程控制的逻辑主要由人类主导；如果 LLM 的自主规划能力很强，那么框架中任务执行的逻辑主要由 LLM 主导。

举个例子：

• 比如文本生成 bot 是最简单的人机协作，执行逻辑已经完全由人类指定，即把人类指令作为 prompt 调用一次大模型获得文本生成内容；

• 相比文本生成 bot，会调用工具的 bot 就具备了一定的任务规划能力，可以自主决定调用哪些工具，遵从人类命令独立完成一些复杂工作任务中的简单子任务；

• 更高级的 bot （类比贾维斯、MOSS 等形象）可以完全由 AI 来进行任务规划，端到端地完成复杂任务，内部执行流程逻辑完全对人类屏蔽，无需人类关注其中细节。

1.3 对于 workflow 与 bot 关系的理解

我们先从 coze 的产品设计开始讨论，在 coze 中如果要搭建一个智能体 agent，核心主体是使用 system prompt 定义的 bot，workflow 是等待被 bot 调用的工具， bot 通过 function call 能力决定是否调用 workflow。所以在 coze 的产品设计中，基于自然语言构建的 bot，和通过拖拉拽节点形式化表达的 workflow，这二者的关系不是对等，bot 是上位者，workflow 是下位者。

coze 单 agent 编排

我们认为构建大模型应用存在两种范式——自然语言和形式逻辑（ 最顶级的形式逻辑是全代码）。

通过自然语言编排的GPTs 简单、便捷，适合普通人快速完成一些不太复杂的工作， 通过形式化表达的workflow 适合具有一定深度的业务场景，能稳定地完成一些复杂工作任务。

二者各有所长，但没有上位者和下位者的分别，甚至可以互相调用、取长补短，所以我们认为应该将二者放在同一平等的层面进行产品设计。

1.4 毕昇 workflow 与市场上同类产品的差异

在明确 workflow 的定位和与 GPTs 类型bot 的关系后，很自然地让我们在设计 workflow 产品的时候与市场上的 workflow 类产品产生了一些差异，这是大家对于 workflow 理解上的不同导致的。具体而言，毕昇 workflow 和 Dify/coze 等产品存在以下不同：

（1）毕昇 workflow 是一个可以实现通用任务的框架 ?

Dify 存在Chatflow 和 Workflow 两种类型的划分：Chatflow 面向对话类情景，Workflow 面向自动化和批处理情景。

Dify 对于 Chatflow 和 Workflow 概念的区分

首先，我们认为大模型应用落地过程中这两个情景未必能完全切分隔离，一个复杂的业务场景可能夹杂着对话和自动化处理。

然后我们希望用一个通用框架来实现各类业务场景下应用的搭建，这样就不会存在 Chatflow 和 Workflow 两种划分——无论是人机多轮对话，还是根据人类修改意见不断迭代信贷尽调报告，抑或是一个 AI 保险销售去向客户推销保险产品，都应该能放在一个通用框架下去实现。

以多轮对话为例，毕昇与市场上的产品存在这样的区别：
在 coze/Dify 等产品中，如果需要用 workflow 来实现多轮聊天对话功能，实现方式是多次重复调用该Workflow，每一次调用视为一轮对话。
在毕昇中，多轮对话始终处于一个工作流调用过程内，通过【用户输入节点】和【输出节点】的交替运行来实现多轮对话，这样做的好处是更好的泛化性，在多轮对话前后可以进行其他任务处理。

用 workflow 实现多轮对话

以保险行业为例，毕昇与市场上的产品存在这样的区别：
毕昇 workflow 能实现这样的AI客服场景流程
1.保险客服询问用户的年龄、性别、学历等多项基本信息。
2.AI 客服判断用户回答信息是否完整：如果完整，才可以进入下一步骤；如果回答不完整，则继续追问缺失信息，如果回答始终不完整，那么应该始终进行追问。
3.多轮对话环节：根据用户信息，基于保险产品资料介绍，向用户推荐合适的保险产品，并回答用户的疑问（本质上是基于 RAG 的多轮对话）。
4.识别到用户购买意愿后，发送对应产品的下单链接。
5.后续其他步骤……而由于类似上一个多轮对话例子中提到的问题，在Dify/coze中，整个Workflow是不允许用户在中间参与交互的，只能一次性从头执行到尾，所以无法在一个Workflow中先通过多轮交互收集用户信息，然后又有多次交互来给用户推荐产品。只能通过Agent去调度两个Workflow来实现，这样会存在效果不可控的问题。

保险客服 workflow

（2）毕昇 workflow  允许复杂的人机交互 ?

现实场景中，一个复杂的工作任务可能需要复杂的人机交互，任务执行过程中间可能需要多样化的输入，也可能出现多样化的输出，通过复杂的人机交互可以实现更好的人类与 AI 协作效果。

例如在撰写论文的过程中，人类可以在大模型输出草稿的基础上，直接进行修改，或者提出二次修改意见。

bisheng workflow 的输入、输出节点提供多样化的交互形式来满足复杂的人机交互需求：

同时，【模板报告生成】、【文档审核】等涉及到文件作为输入输出的毕昇经典特色场景，也同样会在毕昇 workflow 中继续支持。

（3）支持成环 ?

这里成环与 Dify/coze 中的循环不是一个概念（Dify/coze 中的循环节点是对某一数组变量的迭代处理） 目前市面上的产品，可能是出于担心无限循环或者其他原因，在 workflow 编排设计上不支持成环。

我们认为允许成环是有必要的，并且利大于弊的，有很多现实场景就是需要循环反复执行的，就是需要 LLM 自我修正迭代的（e.g.让 LLM 生成正确的代码）。

毕昇 workflow 支持成环，通过设定节点的最大运行次数来防止无限循环。

二、毕昇 workflow 的设计方法论

2.1 明确要解决的业务任务集合

尽管 workflow 在设计理念上应该是一个能够处理任意特定任务的框架，但在具体产品落地的时候，workflow 应该包含哪些流程节点，取决于我们要解决哪些现实世界的工作任务（以下简称“任务”）。所以我们需要先划定要解决的业务需求范围的集合，然后决定设计出哪些节点（node）。

根据我们之前的大模型在企业场景中落地的实践经验，我们认为毕昇 workflow 至少要实现以下场景：

• 大模型多轮对话 ?️

• 多知识库问答 ?

• 双路径问答：先检索 QA 知识库，有结果则直接返回，无则借助大模型能力 ?

• 客服辅助助手 ?

• 具备自主工具调用能力的 copilot ?

• 文档审核：e.g.上传一份合同，根据预置问题逐项进行审核 ?

• 报告生成：e.g. 尽调报告，反洗钱报告  ?

• ……

2.2 对任务状态进行拆解

每一个设计 workflow 产品的产品经理，都应该都会遇到这样的苦恼——到底应该有哪些流程节点（node）？这些节点应该发挥哪些功能？

我们需要对任务进行形式化表达，对各种任务的中间过程状态进行拆解，然后合并归类，进而设计出合理的流程节点。

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

1. 现实世界的任何一个任务，都天然具有状态属性。

2. 任何一个任务至少包含 2 个以上的状态：初始状态和结束状态，此外还可以拥有中间若干过程状态。

3. 当任务处于结束状态时，我们认为任务已完成。

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

• 初始状态：任务初始状态

• 中间状态 1：冰箱门被打开

• 中间状态 2：大象被在冰箱里

• 中间状态 3：冰箱门被关闭

• 结束状态：任务已完成（有些时候，我们也可以把 中间状态 3 和 结束状态 合并为一个状态）

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

• 状态 1：AI 已发送开场白

• 状态 2：用户已发送文字

• 状态 3：判断用户输入内容是否包括全部所需要信息（年龄、性别、学历……）

• 状态 4：追问用户缺失信息

• 状态 5：结合保险知识库向用户推荐相关保险产品

• 状态 6：用户已发送文字

• 状态 7：判断用户是否表达购买意愿

• ……

2.3 workflow 编排的本质是驱动任务状态的有序流转

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

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

• workflow 编排者对于 任务执行过程 的理解

• 系统拥有哪些工具（流程节点）

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

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

• 用【机械臂】打开冰箱门

• 用【起重机】把大象放进冰箱

• 用【机械臂】关上冰箱门

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

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

2.4 workflow 可视化产品是一个 DFA

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

所以我们认为 workflow 可视化产品可以等价为一个确定有限自动机（DFA），用五元组来表示：

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

当然实际情况可能会更复杂，不可能完全按照上述算法进行产品设计，因为给定任务集合  的并不是可以完全枚举的，但 Myhill-Nerode 定理可以给我们的产品设计带来一些启发。现在很多 workflow 产品提供的流程节点，还是从技术视角出发，而不是从业务视角出发，导致做出来像 LLM 版的 scratch 少儿编程。所以在前人经验的之上，我们的设计将更进一步贴近业务逻辑，从业务视角定义“不可分”的节点。

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

所以在 毕昇 workflow 与市面上的其他产品的一个不同点是不存在单独的文档知识库检索节点。

三、workflow 类型产品展望

展望未来，我们认为 workflow 的以下发展方向值得关注：

3.1 降低 workflow 学习和使用成本

包括两方面：

一方面，支持通过自然语言描述的方式先创建一个工作流的雏形（类比于当下 GPTs 产品自动生成 prompt），然后允许用户在其基础上二次编辑修改

另一方面，支持通过自然语言描述的方式，创建自定义流程节点，其效果可以约等于多智能体的工作流编排。

3.2 人类在工作流中的参与和干预

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

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

3.3 多模态&动态即时交互

对话的交互形式已经无法承载复杂的工作流任务，比如报告生成，可能涉及到版本的回退、某一特定章节的修改等等场景，这些都是当前对话形态的交互无法承载。