节点执行方式与 BPMN 任务模型对比：两种调度设计路线的取舍

一篇偏工程视角的对照分析：把节点的执行方式枚举与 BPMN 的任务、作业模型放在同一张表里比较，覆盖建模单元、调度驱动、失败恢复与过程可视化，并说明各自优化的方向与付出的代价。

0. 差异在哪

三家都在解决同一件事：人工等待与系统继续如何在一条流程里共存。分歧不在「有没有自动节点」，而在建模单元和调度哲学。

Flowable / Camunda 这边，作业可靠性、多语言工人、标准互操作更完整。该平台这边，执行策略挂在同一类节点上，过程观测是给业务人员看的，不是给运维控制台看的。选型看场景，不要按「谁更 BPMN」打分。

1. 问题本身：执行者是节点类型，还是节点属性？

企业流程里常见五类诉求，三家都能做，只是落点不同：

1. 必须由指定人批，进待办、可催办、可退回。
2. 到点由系统跑，不要占人的待办箱。
3. 能自动就自动，规则挡住再给人。
4. 产线工位扫码过站，不走审批箱。
5. 连续调外部系统，人要看见卡在哪一步、返回了什么。

Flowable / Camunda 的答案来自 BPMN：换一种图元。用户任务是等待态；服务任务是自动态（同步委托或异步作业）；定时用中间事件；外部系统用 External Task / Job Worker。图上信息量大，语义精确，实施人员要熟悉规范。

该平台的答案来自属性：不换图元，改执行方式。设计器仍是同一个节点，下拉五种方式。发送引擎、待办表、消息、定时任务、过程页读的是同一列。实施人员改枚举，开发人员改事件。

两种设计都自洽。前者优化 规范表达与引擎内核；后者优化 中国审批 + 集成 + 低代码配置的同一套节点生命周期（接收人、方向条件、退回、轨迹仍然在）。

| 对照维度 | Flowable / Camunda | 该 BPM 平台 | | --- | --- | | 建模单元 | User Task / Service Task / External Worker / Timer Event 等不同图元 | 同一类节点 | | 执行者归属 | 由节点类型直接决定 | 由节点上的「执行方式」枚举决定 | | 可枚举的执行者 | 取决于所选图元 | 操作员 / 机器 / 混合 / 流水线 / 过程 |

2. 该平台：五种执行方式如何真正跑起来

属性定义在节点上，发送生成待办时 抄到待办行。运行时调度读待办行，而不是每次再解析流程图。这是设计上的关键：执行方式是运行时状态，延期发送才能把一条人工待办临时改成机器通道，到期再发。

2.1 操作员执行（默认）

人处理、人发送。进待办，可达消息，轨迹按人工记录。对照 BPMN 的 User Task，语义最接近。差异在产品层：该平台的待办与表单、工具栏、审核组件是一体的；Flowable / Camunda 的 TaskService 是引擎 API，页面多由业务或 Tasklist 组装。

2.2 机器执行

• 待办查询排除机器执行，避免系统节点出现在「我的待办」。
• 到达 / 发送成功默认不推消息，避免误报「有人等你批」。
• 后台服务扫描「机器 / 混合、未通过、已启用」的待办，模拟处理人登录后调用与人工相同的发送。

与 Job Executor 的相似处：都是 把继续流转从用户线程里拿出去。 不同处：Camunda / Flowable 的作业有 锁、排他、重试次数、到期时间、失败事故；该平台这条通道更粗——扫待办、发一次、失败记日志。可靠性模型更简单，也更容易和「延期发送」共用：人工把待办改成机器执行并写入延期时间，到点同一扫描任务发出，取消则原子清回人工态。

设计合理性：复用待办行当作业记录，不必再维护一张独立 job 表。代价是作业语义（重试退避、事故工作台、优先级队列）不如 BPMN 引擎成熟。

2.3 混合执行

打开工作页时先尝试发送。成功则人已经站在下一节点；被方向条件、接收人、阻塞等挡住则静默失败，表单留给人。

BPMN 里要对等，通常是：

• 排他网关：条件满足走 Service Task，否则 User Task；或
• User Task 上监听器自动 Complete；或
• 跳过表达式（部分产品）。

图上会变成两个活动。该平台坚持 一个节点两种命运：接收人、表单、退回规则不用配两遍。

设计合理性：贴近「填完就能过、过不了再改」的办公习惯。边界也清楚——试发发生在打开页面，不是到达瞬间；不适合代替真正的异步作业。

2.4 流水线执行

待办不进普通审批箱，走独立工位接口：按节点汇总、按工位列出、按日对账，发送可带二维码 / 单据号。

BPMN 没有工位图元。落地一般是 User Task + 自研扫码页 + taskService.complete。引擎不管「这个任务该出现在工位屏还是审批箱」。

设计合理性：执行方式直接决定 任务出现在哪条交互通道，而不仅是「谁 complete」。这是产品化，不是规范新增。MES / 车间过站值得用；普通审批不要滥用。

2.5 过程执行

连续系统节点在 同一次发送请求内同步连发，明确不进定时扫描：

发送完成后
while 下一节点的执行方式 == 过程执行 且流程未结束 且存在待办:
    切换到该待办处理人
    以系统身份走完整发送（方向条件、接收人、发送前事件仍生效）
    叠加本次过程返回
切回原操作员

上一人工节点若配置「发送后转向」为过程执行页，则先打开大窗再并发发送。页面每秒拉轨迹：过程 / 人工标签、耗时、外部返回、并行分支；超过约一分钟提示外部系统仍在处理。

对照 BPMN：一串 Service Task 令牌也会自动往前走。差别在 事务与观测：

• 若 Camunda 7 用同步 JavaDelegate，同样可能在一次事务里跑完一串自动活动——官方反而建议 asyncBefore / asyncAfter，避免长事务与锁。
• 若用异步作业或 Camunda 8 Job Worker，每步独立提交，崩溃可从作业恢复，事故在 Operate 里可见。
• 该平台过程执行选择 同步连发 + 业务时间轴，优化的是「人点一次发送、盯着集成跑完」；HTTP 超时、中途宕机、逐步重试不是这条路径的强项。长耗时、需重试的外部调用，更适合机器执行（定时再发）或自建工人，而不是无限拉长当次请求。

设计合理性：过程节点仍是节点——有接收人、有事件、失败停在具体节点——不是跳过引擎的脚本钩子。身份切到待办人再切回，审计主体仍是人。这与 BPMN 服务任务「引擎账号执行、活动上常无办理人」不同，更符合国内审批留痕习惯。

3. Flowable / Camunda：任务类型与作业模型（对等叙述）

3.1 元素分工

Camunda 8 把「引擎内 JavaDelegate」基本拿掉，自动步骤默认是工人模型：扩展性、隔离性更好，运维模型也更重。该平台仍把自动步骤留在同一套发送里，部署形态更接近传统单体 BPM。

3.2 作业执行器在解决什么

Flowable / Camunda 7 的异步延续，核心不是「自动」，而是 把一次令牌推进切成可恢复的作业：

• 获取作业并加锁，防止多节点重复执行。
• 失败写重试与事故，人工在 Cockpit 处理。
• exclusive 避免同一实例并发把数据写乱。

该平台机器执行用待办扫描近似「有活就发」，没有同等的作业锁协议。集群下要靠服务部署约定，而不是引擎级 job lock。这一点对比必须写明：在高并发自动节点与失败恢复上，BPMN 作业模型更完整。

3.3 外部工人在解决什么

External Task 的类比是：服务任务也是一种「待办」，领取者不是人而是程序。fetchAndLock → 做事 → complete / failure。工人可多语言、可水平扩展，引擎不持有长调用。

该平台过程执行是引擎（或应用进程）在发送循环里直接调外部 API。耦合高、配置简单、过程页容易把返回贴回节点。工人模式要运维一套消费者；事件模式要守住超时与重试。

跨语言、长耗时、要独立扩缩的集成，用工人模型更合适。配置人员改节点就能串内部系统调用时，用该平台过程执行更合适。两条路的运维成本和失败恢复不一样，不要混着用同一套预期去验收。

4. 技术细节对照

4.1 运行时数据落在哪

该平台让 待办表身兼「人工任务」与「自动作业」（靠执行方式区分）。表更少，语义要靠枚举约束。BPMN 把任务与作业分表，查询清晰，模型更重。

延期发送能成立，正因为待办行可变：执行方式从操作员改为机器，参数里带延期时间。BPMN 更标准的做法是图上放 Timer，或把作业 due date 设到未来——图与作业表都看得见，待办不一定还在。

4.2 消息与待办为什么要跟着执行方式走

自动步骤若仍发「请审批」类到达消息，产品就是错的。该平台在消息模块对机器执行短路。Flowable / Camunda 通常根本不会给 Service Task 建 Task，自然也不会进 Tasklist；若在监听器里发业务消息，要实施自己区分。

两边都合理。该平台必须显式短路，因为机器节点 仍然生成待办行（只是查询排除）；BPMN 服务任务 往往不生成 User Task。这是「同一套节点生命周期」带来的额外正确性义务，不是缺陷，但实现上必须守住。

4.3 失败停在哪里

过程页把集成报文展示给业务人员，这是该平台有意做的产品层。Cockpit 面向运维。两者不互相替代。

4.4 并行该平台时间轴能解析「并行执行：」类节点名，过程页展示并行分支。引擎并行仍靠分流 / 合流运行模式，与执行方式正交。

BPMN 用并行网关 + 多令牌，服务任务可在分支上各自异步。并行作业调度、合流同步是 BPMN 引擎的传统强项。

不要把「过程连发」理解成分流：连发是 同一路径上的同步序列；并行是 多令牌。配置错了会把长耗时外部调用塞进一次 HTTP。

5. 设计合理性：各自优化什么，各自付出什么

5.1 为何该平台坚持「改属性、不改图元」

1. 生命周期复用：接收人、方向条件、退回、撤销、轨迹、表单权限都挂在节点上。自动步骤若换成另一种活动类型，这些能力要再实现一遍，或承认自动步骤是「瘦活动」。该平台选择自动步骤仍是「胖节点」。
2. 低代码配置面：一个下拉框比在工具箱里认七八种 BPMN 任务更适合业务实施。
3. 通道产品化：待办箱、流水线箱、过程大窗是交互通道，执行方式是通道开关。BPMN 把通道留给应用。

代价：不是国际标准；工具链、人才、流程文件互换弱；作业协议简单；过程同步连发有超时上限。

5.2 为何 Flowable / Camunda 坚持「换图元、作业可恢复」

1. 规范：BPMN 2.0 令牌语义、导入导出、培训材料统一。
2. 失败域：异步作业把外部 IO 移出引擎事务，这是十年踩坑后的默认建议。
3. 工人模型：自动步骤与引擎进程解耦，适合微服务与多语言。

代价：中国式审批（退回、加签、抄送、审核意见）要在 User Task 上大量扩展；「能过则过」要拆图；工位、过程时间轴要自建；对实施人员的规范门槛高。

5.3 不宜互相抄的部分

• 不要要求该平台用 BPMN 任务类型重做一遍节点工具箱，那会拆掉「胖节点」生命周期。
• 不要要求 Camunda 用一个枚举取代 User / Service Task，那会拆掉标准与作业模型。
• 过程执行不要当成 Camunda 8 Worker 的替代；Worker 不要当成过程页的替代。前者是同步编排 UX，后者是异步可靠性。

6. 场景怎么选（可执行的对照）

混合使用也常见：核心审批用该平台，超长集成用独立工人回写后「发送」推进。那是架构组合，不是某引擎的失败。

7. 容易说满的三处

1. 「五种策略共享发送、待办、事件与轨迹」是对的，但共享生命周期就要自己处理待办过滤和消息短路。作业锁、重试次数、事故台，BPMN 那边更完整，这点不要略过。
2. 过程执行页让业务人员能看见人机混合轨迹。看见的是当次请求里的同步连发，不是分布式工人编排。
3. Flowable / Camunda 的图元和作业模型，自动步骤可恢复。跟该平台比的是引擎内核；待办箱、退回加签、工位通道在他们那边多半要产品层自己补。

8. 收束

节点执行方式不是 BPMN 任务类型的对照表，问题切法就不一样：

• Flowable / Camunda 问的是：活动是什么类型，令牌和作业怎么往前走。
• 该平台问的是：这个节点由谁、按什么节奏执行，同一节点进哪条通道。

复杂性放的位置不同。前者在规范和作业协议上，恢复力和生态更好；后者在一个枚举和发送循环上，配置面和过程页更直接。

实现上可以记成：同一节点、五种执行方式、同一套发送。机器靠待办扫描，过程靠当次连发，混合靠打开试发，流水线走工位接口。执行方式同时管待办过滤、消息和轨迹标签。

三家都会自动。差别是自动步骤还算不算原来那个节点，以及失败之后谁看见、谁重试。