业务流程分两类：人执行与机器执行，一套引擎如何统一承载

本文以一套开源工作流引擎源码为样本，讨论管理类流程与工业自动化流程的差别与统一承载方案，供做流程系统选型与设计的读者参考。

一、先把「流程」这个词放开一点

「流程」是一个被用得很窄的词。多数人一提流程，想到的是请假、报销、公文——办公室里的事。

但流程的本质定义其实很宽：一件事被拆成有顺序、有判断、有交接、有痕迹的若干步骤。

按这个定义：

• 制造一个零部件，是流程；
• 请假审批，是流程；
• 盖一幢大楼，是流程；
• 维修一架飞机，是流程；
• 开一个连锁店，也是流程。

它们的共同点是「分步骤、有规则、要留痕」，差别只在步骤由谁执行、依据什么前进。

该平台从工程实现的角度，把这些流程粗分为两类：

需要先说明：这个划分不算严谨。 两类之间没有绝对界限，实际项目中经常混合。它更像一个方向性的坐标——帮我们判断「这个流程的重心在哪一边」，而不是给每个流程贴死标签。

二、管理类流程：节点由「人」执行

2.1 特征

管理类流程的每个节点，都对应一个真实的岗位、真实的人。这个人在节点上要做的事，基本是这几件：

• 打开表单
• 确认（审核）
• 数据输入 / 输出
• 决定流程前进、后退、转向，还是终止
• 移交（交给别人办）

一句话：它是人的操作行为。 请假流程、报销审批、公文流转、合同会签，都属于这一类。

2.2 引擎要提供什么

因为执行主体是人，管理类流程对引擎的要求集中在几件事上：

这也是 BPM 引擎最传统的、被讨论最多的部分。

三、工业自动化流程：节点由「设备 / 系统」执行

3.1 特征

工业流程的节点执行者，不再仅仅是一个人、一个角色，而可能是：

• 一台设备
• 一个系统
• 一枚二维码

这个节点做的事，也从「打开表单、填写、点同意」变成了数据的输入输出：

节点接收数据的输入输出，由输入输出的数据参数决定该流程是前进、后退、转向，还是终止。

举个例子：

• 产线上一个工位，扫码后系统返回「这道工序合格」，流程自动走到下一步；
• 传感器读数超过阈值，流程自动触发异常分支；
• 设备信号返回「加工完成」，流程自动流转到检测节点。

判断从「人的意见」变成了「数据的参数」。 这是工业流程与管理流程最本质的区别。

3.2 对引擎的额外要求

因为执行主体不是人，工业流程对引擎提出了管理流程不需要的几件事：

这些需求，决定了工业流程不能直接套用「所有节点都生成待办、都等人办」的模型。

四、该平台怎么落地：一个属性 WhoExeIt

4.1 属性定义

两类流程的差别，在该平台里被收敛成一个节点属性：

csharp // public const string WhoExeIt = "WhoExeIt";

它在节点属性界面上的定义是（NodeExt.cs）：

"@0=操作员执行@1=机器执行@2=混合执行@3=流水线执行@4=过程执行"

前端 whoExeIt.ts 与之后端枚举一一对应：

ts export const WHO_EXE_IT_OPTIONS = [ { value: 0, label: '操作员执行' }, { value: 1, label: '机器执行' }, { value: 2, label: '混合执行' }, { value: 3, label: '流水线执行' }, { value: 4, label: '过程执行' }, ];

五档，前两档正是本文讨论的两类流程：

0 与 1 是一对基础形态，2~4 是面向工业场景的延伸。「分类不严谨、可以混合」这件事，在枚举里就是客观存在的——2=混合执行 这一档，就是对「两类之间没有绝对界限」的直接承认。

4.1.1 一张图：两类流程与 WhoExeIt 的映射

`mermaid flowchart TD A[业务流程] --> B{节点由谁执行 WhoExeIt} B -->|0 操作员执行| C[管理类流程] B -->|1 机器执行| D[工业自动化流程] B -->|2 混合执行| E[两类混合] B -->|3 流水线执行| F[工业流程延伸] B -->|4 过程执行| G[工业流程延伸]

C --> C1[节点是岗位 / 角色 / 人]
C1 --> C2[打开表单 · 审核 · 确认]
C2 --> C3[人决定前进 / 后退 / 终止 / 移交]

D --> D1[节点是设备 / 系统 / 二维码]
D1 --> D2[接收数据输入输出]
D2 --> D3[数据参数决定前进 / 后退 / 转向 / 终止]

C3 -.->|同一套表结构<br/>同一套发送引擎| D3
E -.->|逐节点切换，无需两套引擎| C3

`

这张图想说明两件事：五档枚举里，0 与 1 是两类流程的基本形态，2~4 覆盖混合与工业细分；而管理类与工业类共用同一套发送引擎——分叉只在「谁来执行」，汇合在「同一条流程」。这也正是 WhoExeIt=2（混合执行）能存在的结构基础。

4.2 WhoExeIt = 1（机器执行）时，引擎行为有什么不同

这是最关键的部分。看代码，WhoExeIt 不只是个标记，它真的改变了引擎的运行行为：

（1）待办列表里被排除

Dev2Interface.cs 查待办时的 SQL 里有一句：

sql AND C.WhoExeIt != 1

意思是：机器执行的节点，不会出现在人的待办列表里。它不需要人去点。

（2）不再推送到达消息

ExecEvent.cs 里，节点到达事件的处理开头就有：

csharp // 机器执行节点在流程发送时不处理消息推送. if (doType.Equals(EventListNode.WorkArrive) == true && wn.HisNode.WhoExeIt == 1) return msg;

机器执行的节点，不发「您有新工作」这类消息——因为那不是给人办的。

（3）发送成功通知也跳过

WorkNode.cs 的 SendMsgToThem：

csharp if (this.town != null && this.town.HisNode.WhoExeIt == 1) return;

（4）工作者列表里仍记录 WhoExeIt

生成待办记录时（WorkNode.cs）：

csharp gwl.WhoExeIt = nd.WhoExeIt;

也就是说，机器节点的执行痕迹照样进 WF_GenerWorkerList。这一点很重要：虽然不推给人，但流程轨迹与责任链仍然完整——审计需要。

4.3 为什么用「一个属性」而不是「两套引擎」

这是该平台这套实现里最值得琢磨的设计选择。

管理流程与工业流程，可以做成两套产品、两个引擎。但该平台把它们统一在同一个节点模型上，只用一个 WhoExeIt 区分。好处是：

这正好回应了「两类流程没有绝对界限」： 界限不清晰时，最忌讳的就是用两套模型去切——切不干净，接缝处必然出问题。用一个属性、逐节点配置，反而是对「界限模糊」这一现实的正确建模。

五、两类流程的对照

六、结论

回到「业务流程的分类」这个问题：

1. 流程是一个宽泛概念，制造零件、维修飞机、开连锁店、请假审批，都是流程；
2. 管理类流程的节点由人执行，是人的操作行为（打开表单、审核、决定前进后退）；
3. 工业自动化流程的节点由设备/系统/二维码执行，由数据参数决定流转方向；
4. 两类之间没有绝对界限，可以混合——这一点最重要；
5. 该平台用节点属性 WhoExeIt 承载这个分类：0=操作员执行、1=机器执行，再加 2/3/4 覆盖混合与流水线等场景。

对工程实现来说，第 4 点决定了第 5 点的选择：既然界限模糊，就用「一个属性、逐节点配置」，而不是「两套引擎、强行切分」。 WhoExeIt=1 的节点在待办查询里被过滤、在消息推送里被跳过，但执行痕迹仍完整记录——该自动的自动，该留痕的留痕，这大概是把两类流程装进同一套引擎时最需要拿捏的一层。

延伸阅读

本文讨论的是分类视角——业务流程该怎么分、WhoExeIt 如何承载这个分类。如果你更关心 WhoExeIt 五档各自的调度机制，可对照阅读：

• 《一个属性，五种执行者：CCBPM 节点的执行方式》（ BPM 平台-节点执行方式的设计规范.md）

那篇的重点在产品能力与运行时细节：机器执行的定时扫描通道、延期发送如何复用机器通道、混合执行的「能过则过」、流水线执行的独立待办接口、过程执行的连发循环，以及过程执行页（发送后转向 6/7、时间轴与流程图）如何让连发过程可观测。

一句话区分两篇：本文回答「流程分几类」，那篇回答「五种执行者各自怎么跑」。