节点执行方式的设计规范：从枚举属性到运行时调度

一个枚举字段如何承载五种执行模型：设计期配置一次、运行期由引擎调度、过程执行页可视化。本文按定义、调度分流、过程可观测、配置要点四部分说明这套设计的取舍。

一、为什么这件事难

企业流程很少是「人填表、人点发送」的直线。真实场景里，同一次流转往往要同时面对：

多数 BPM 产品会拆成「用户任务 / 服务任务 / 脚本任务 / 定时器」多类节点。该 BPM 平台的做法不同：节点形态不变，只改「节点的执行方式」。设计器上仍是同一个节点图形，属性面板上仍是同一个下拉框。低代码人员改枚举，高代码人员改事件，两者共享同一套发送引擎。

这就是面向模式开发的典型切口：能力写在实体属性上，而不是写在另一套节点类型体系里。

二、节点的执行方式是什么

2.1 节点级定义，待办级落地

属性挂在节点表上，字段即「节点的执行方式」。设计器与节点属性页使用同一套系统枚举：

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

发送时，引擎把节点上的值抄到当前待办行：

生成接收人待办时：待办.节点的执行方式 = 到达节点.节点的执行方式

因此「节点的执行方式」不是设计期的装饰字段，而是运行时调度依据。待办查询、定时任务、消息推送、流水线列表、过程连发，读的都是这一列。

2.2 一张图看清调度分流

五种模式共用发送主通道，差异只在何时发、谁来发、给人看什么。

三、五种执行模型

0｜操作员执行（默认）

人处理、人发送。工作进入待办，到达可推送消息，轨迹按人工处理记录。这是 BPM 的基本盘，也是另外四种模式的对照基准。

时间轴上标记为 [人工执行]。

1｜机器执行

节点到达后不进入操作员待办（待办查询显式排除「机器执行」），也不推送到达 / 发送成功消息，避免把系统节点误报成「有人等你批」。

后台服务周期扫描执行方式为「机器执行」或「混合执行」、且尚未通过的待办。到期后以该待办人身份登录并自动发送。同一机制还承载 延期发送：人工点「延期发送」时，把当前待办临时改成机器执行并写入延期时间，到点自动发出；取消或立即发送则原子清回人工态。

特色：自动发送与延期发送共用机器通道，不必再发明一套队列。

2｜混合执行

打开工作页面时，引擎先尝试发送一次。发送成功则用户已经站在下一节点；发送被业务规则挡住（方向条件、接收人、阻塞模式等），则静默失败、保留当前表单，改由人继续处理。

特色：能自动则自动，不能自动则人工，同一节点无需拆成「自动节点 + 人工节点」两条线。

3｜流水线执行

面向工位、扫码、批量过站。待办不混入普通审批箱，而走独立的流水线接口：按节点汇总待办数、按工位列出任务、按当日已处理清单对账，发送可带二维码 / 单据号。开始节点还可按草稿规则先落草稿再进入流水。

特色：流程引擎直接服务产线节拍，而不是把车间操作硬塞进「我的待办」。

4｜过程执行（该 BPM 平台近年重点能力）

连续的系统节点在同一次发送请求内同步连发，不进定时任务（定时扫描明确排除流水线与过程：过程节点由发送时连发）。

引擎逻辑可以概括为：

发送完成后
while 下一节点的执行方式 == 过程执行 且流程未结束 且存在待办:
    切换到该待办处理人
    以系统身份执行发送
    把本次发送前事件 / 过程返回叠加进总消息
切回原操作员

人只点一次「发送」，后面许可申请、并行分发、Kafka、FTP、回写可以一串跑完。某步失败则抛出「系统执行发送」前缀异常，前端过程页展示失败节点与返回。

时间轴上标记为 [过程执行]。

四、看见过程：过程执行页

过程节点如果仍弹一句「发送成功」，集成场景几乎不可用——外部系统可能跑几十秒，人不知道卡在哪一步、返回了什么。

该 BPM 平台用节点属性 发送后转向 接上过程可视化：

交互节奏与引擎连发对齐：

1. 工具栏先打开大窗，状态置为「执行中」，再并发调用发送。
2. 过程执行页每秒轮询轨迹，后端额外下发全流程节点（含节点的执行方式），用于区分过程 / 人工标签。
3. 时间轴展示：节点名、并行分支、处理人、耗时、下达时间、过程返回。
4. 执行中节点实时计时；超过约 1 分钟加强「外部系统处理中」提示。
5. 发送返回里的发送前事件 / 过程明细（JSON、成功报文、许可 / Kafka / FTP 等过程文案）优先贴到「过程执行」的完成项上，并过滤引擎套话（「下一步工作」「已向xxx发送提醒」）。
6. 可切换嵌入式流程图（实时模式），全屏观看整网执行。

人看到的不再是黑盒自动任务，而是 人机混合轨迹：人工节点显示处理人头像，过程节点显示系统返回与等待时长。这是该 BPM 平台把「工作流」做成「可观测过程」的关键一步。

五、设计器里改一改就能用

流程设计器把「节点的执行方式」做成一等公民：

• 节点右键菜单直接改「节点的执行方式」，五种选项带当前勾选态，保存即写回节点。
• 非开始节点只要不是默认的操作员执行，节点底色变为橙黄，设计图上一眼能看出哪些是机器 / 过程 / 流水线。
• 节点属性用系统枚举下拉暴露同一字段，并挂帮助文档，配置人员不必读源码。

低代码侧：改枚举、配接收人、配发送后转向 6/7。 高代码侧：在节点 发送前事件 或 过程 里调外部系统。 两边对接的契约就是节点的执行方式，而不是再发明一种节点类型。

六、面向模式：属性即能力

「节点的执行方式」能从「一个整数」长成整套产品能力，靠的是该 BPM 平台的实体映射框架，而不是散落的 if-else 配置文件。

实体映射把该字段登记为：

• 数据类型：整数
• 字段类型：枚举
• 控件：下拉框
• 绑定键：节点的执行方式，配置值写在枚举项里

前后端实体镜像：同一张节点表。属性面板、设计器右键、运行时读取的是同一元数据。

定时自动执行则复用可管理的自动任务，与逾期、消息、同步等任务并列。配置、存储、调度、界面同源——这是面向模式开发相对「表单 + 脚本」通用低代码的门槛所在。

七、和待办、消息、事件如何配合

同一属性在多个子系统上保持语义一致，避免「自动节点还在待办里催办」这类产品级漏洞。

过程节点不是「跳过引擎」的脚本钩子，而是 仍受接收人、方向条件、阻塞、事件约束的系统执行者。外部 API 失败可以按节点停下，而不是整条流程无声丢失。

八、典型场景

跨系统编排（过程执行） 一次人工发送后，连续节点分别申请许可、向并行系统分发、写 Kafka、回写 FTP。过程执行页时间轴按节点展示耗时与 JSON 返回，失败停在具体过程节点。

夜间批量过账（机器执行） 归档、生成凭证、同步主数据放在机器节点，由服务扫描发送，白天待办箱保持干净。

能过则过（混合执行） 表单完整且规则满足时打开即走；缺附件或条件不成立时停留给操作员。一个节点覆盖两种命运。

工位扫码（流水线执行） 同一工位处理同一节点的多件任务，按二维码发送，按日统计已过站数量。

定时再发（延期发送） 人先填完，约定小时后再发。待办临时变为机器态，到期自动进入后续人工或过程节点。

这些场景不需要五套引擎，只需要五种节点的执行方式。

九、该 BPM 平台特色归纳

1. 一个枚举贯通设计期与运行期 节点属性 → 待办行 → 定时任务 / 发送循环 / 流水线接口 / 前端标签，语义不漂移。
2. 人机协同是一等模型，不是插件 操作员、机器、混合、流水线、过程并列，而不是在用户任务旁边外挂「自动步骤」。
3. 过程可观测 连发不是后台黑盒。发送后转向 6/7 + 过程执行页把执行中、停留、失败、耗时、API 返回摊在时间轴和流程图上。
4. 自动通道可复用 机器执行同时服务「节点自动发送」和「延期发送」，调度、身份、原子清标记都在同一条链上。
5. 面向模式，而不是面向节点类型爆炸 枚举属性 + 同一套发送。扩展新执行者主要是加枚举值与一条调度策略，而不是复制一套节点运行时。
6. 低代码可配、高代码可嵌 设计器右键改节点的执行方式；事件与过程承接外部系统。集成复杂度留在过程节点里，主流程图形仍然可读。

十、配置要点（给实施与二次开发）

• 连续系统步骤请设 过程执行（4），不要设成机器执行（1）：后者进定时扫描，前者在当次发送内连发，时延与事务边界不同。
• 需要人盯进度时，上一人工节点的 发送后转向 选 6 或 7。
• 过程节点仍要配置接收人：连发会按待办人切换身份，便于权限与审计。
• 外部调用放在节点发送事件 / 过程，返回信息会出现在过程页「结果」区。
• 机器节点默认不进待办、不发到达消息；若业务必须通知人，请用独立消息策略，不要依赖默认到达推送。
• 流水线节点走专用待办接口，不要期望出现在普通「我的待办」里。

结语

节点的执行方式，表面是节点上的一个下拉框，背后是该 BPM 平台对「工作到底由谁做完」这个问题的产品化回答：

人可以批，机器可以跑，打开可以试，工位可以扫，过程可以连发——并且人能看见。

把五种执行者收进同一属性、同一发送引擎、同一套实体映射，再配上过程时间轴，这是该 BPM 平台区别于「只会画人工审批链」的工作流工具的关键能力。实施时改的是枚举，运行时调度的是引擎，用户看到的是过程。属性即能力，模式即产品。