多数 BPM 会把执行方式拆成用户任务 / 服务任务 / 脚本任务等多类节点。这套引擎的做法是节点形态不变，只改「节点的执行方式」。本文拆解这个设计为什么成立，以及定时任务、待办、消息、延期发送如何与它对齐。
一、为什么这件事难
企业流程很少是「人填表、人点发送」的直线。真实场景里，同一次流转往往要同时面对：
| 环节 | 典型诉求 |
|---|---|
| 审批、会签、退回 | 必须由指定人处理，进待办、发消息 |
| 校验、归档、写回业务系统 | 到点就跑，不要占人待办 |
| 打开表单就能过、过不了再给人 | 能自动则自动，不能则人工兜底 |
| 产线扫码、工位流转 | 不走传统待办，按工位批量处理 |
| 连续调用外部 API（许可、Kafka、FTP…） | 到达即连发，人要看见进度与返回 |
多数 BPM 产品会拆成「用户任务 / 服务任务 / 脚本任务 / 定时器」多类节点。CCBPM 的做法不同：节点形态不变，只改「节点的执行方式」。设计器上仍是同一个节点图形，属性面板上仍是同一个下拉框。低代码人员改枚举，高代码人员改事件，两者共享同一套发送引擎。
这就是面向模式开发的典型切口：能力写在实体属性上，而不是写在另一套节点类型体系里。
二、节点的执行方式是什么
2.1 节点级定义，待办级落地
属性挂在节点表上，字段即「节点的执行方式」。设计器与节点属性页使用同一套系统枚举：
@0=操作员执行 @1=机器执行 @2=混合执行 @3=流水线执行 @4=过程执行
发送时，引擎把节点上的值抄到当前待办行：
生成接收人待办时：待办.节点的执行方式 = 到达节点.节点的执行方式
因此「节点的执行方式」不是设计期的装饰字段，而是运行时调度依据。待办查询、定时任务、消息推送、流水线列表、过程连发，读的都是这一列。
2.2 一张图看清调度分流
| 节点的执行方式 | 工作到达后的调度动作 |
|---|---|
| 0 操作员执行 | 进入人工待办，可推送到达消息，人工处理并发送 |
| 1 机器执行 | 不进普通待办、不推送到达消息；由后台定时任务按执行方式自动发送 |
| 2 混合执行 | 打开表单时先尝试自动发送；成功直接走下一节点，失败则保留为人工待办 |
| 3 流水线执行 | 进入独立工位待办，按扫码 / 单据号发送，不与普通审批箱混在一起 |
| 4 过程执行 | 在当次发送请求内同步连发，以系统身份执行；由过程执行页的时间轴 / 流程图展示过程返回 |
五种模式共用发送主通道，差异只在何时发、谁来发、给人看什么。
三、五种执行模型
0｜操作员执行（默认）
人处理、人发送。工作进入待办，到达可推送消息，轨迹按人工处理记录。这是 BPM 的基本盘，也是另外四种模式的对照基准。
时间轴上标记为 [人工执行]。
1｜机器执行
节点到达后不进入操作员待办（待办查询显式排除「机器执行」），也不推送到达 / 发送成功消息，避免把系统节点误报成「有人等你批」。
后台服务周期扫描执行方式为「机器执行」或「混合执行」、且尚未通过的待办。到期后以该待办人身份登录并自动发送。同一机制还承载 延期发送：人工点「延期发送」时，把当前待办临时改成机器执行并写入延期时间，到点自动发出；取消或立即发送则原子清回人工态。
特色：自动发送与延期发送共用机器通道，不必再发明一套队列。
2｜混合执行
打开工作页面时，引擎先尝试发送一次。发送成功则用户已经站在下一节点；发送被业务规则挡住（方向条件、接收人、阻塞模式等），则静默失败、保留当前表单，改由人继续处理。
特色：能自动则自动，不能自动则人工，同一节点无需拆成「自动节点 + 人工节点」两条线。
3｜流水线执行
面向工位、扫码、批量过站。待办不混入普通审批箱，而走独立的流水线接口：按节点汇总待办数、按工位列出任务、按当日已处理清单对账，发送可带二维码 / 单据号。开始节点还可按草稿规则先落草稿再进入流水。
特色：流程引擎直接服务产线节拍，而不是把车间操作硬塞进「我的待办」。
4｜过程执行（CCBPM 近年重点能力）
连续的系统节点在同一次发送请求内同步连发，不进定时任务（定时扫描明确排除流水线与过程：过程节点由发送时连发）。
引擎逻辑可以概括为：
发送完成后
while 下一节点的执行方式 == 过程执行 且流程未结束 且存在待办:
切换到该待办处理人
以系统身份执行发送
把本次发送前事件 / 过程返回叠加进总消息
切回原操作员
人只点一次「发送」，后面许可申请、并行分发、Kafka、FTP、回写可以一串跑完。某步失败则抛出「系统执行发送」前缀异常，前端过程页展示失败节点与返回。
时间轴上标记为 [过程执行]。
四、看见过程：过程执行页
过程节点如果仍弹一句「发送成功」，集成场景几乎不可用——外部系统可能跑几十秒，人不知道卡在哪一步、返回了什么。
CCBPM 用节点属性 发送后转向 接上过程可视化：
| 发送后转向 | 行为 |
|---|---|
| 6 | 发送后弹出过程执行大窗，默认 时间轴 |
| 7 | 同一大窗，默认 流程图 |
交互节奏与引擎连发对齐：
- 工具栏先打开大窗，状态置为「执行中」，再并发调用发送。
- 过程执行页每秒轮询轨迹，后端额外下发全流程节点（含节点的执行方式），用于区分过程 / 人工标签。
- 时间轴展示：节点名、并行分支、处理人、耗时、下达时间、过程返回。
- 执行中节点实时计时；超过约 1 分钟加强「外部系统处理中」提示。
- 发送返回里的发送前事件 / 过程明细（JSON、成功报文、许可 / Kafka / FTP 等过程文案）优先贴到「过程执行」的完成项上，并过滤引擎套话（「下一步工作」「已向xxx发送提醒」）。
- 可切换嵌入式流程图（实时模式），全屏观看整网执行。
人看到的不再是黑盒自动任务，而是 人机混合轨迹：人工节点显示处理人头像，过程节点显示系统返回与等待时长。这是 CCBPM 把「工作流」做成「可观测过程」的关键一步。
五、设计器里改一改就能用
流程设计器把「节点的执行方式」做成一等公民：
- 节点右键菜单直接改「节点的执行方式」，五种选项带当前勾选态，保存即写回节点。
- 非开始节点只要不是默认的操作员执行，节点底色变为橙黄，设计图上一眼能看出哪些是机器 / 过程 / 流水线。
- 节点属性用系统枚举下拉暴露同一字段，并挂帮助文档，配置人员不必读源码。
低代码侧：改枚举、配接收人、配发送后转向 6/7。
高代码侧：在节点 发送前事件 或 过程 里调外部系统。
两边对接的契约就是节点的执行方式，而不是再发明一种节点类型。
六、面向模式：属性即能力
「节点的执行方式」能从「一个整数」长成整套产品能力，靠的是 CCBPM 的实体映射框架，而不是散落的 if-else 配置文件。
实体映射把该字段登记为：
- 数据类型：整数
- 字段类型：枚举
- 控件：下拉框
- 绑定键：节点的执行方式，配置值写在枚举项里
前后端实体镜像：同一张节点表。属性面板、设计器右键、运行时读取的是同一元数据。
定时自动执行则复用可管理的自动任务，与逾期、消息、同步等任务并列。配置、存储、调度、界面同源——这是面向模式开发相对「表单 + 脚本」通用低代码的门槛所在。
七、和待办、消息、事件如何配合
同一属性在多个子系统上保持语义一致，避免「自动节点还在待办里催办」这类产品级漏洞。
| 子系统 | 对节点的执行方式的处理 |
|---|---|
| 待办列表 | 排除机器执行，人不被系统节点打扰 |
| 消息推送 | 到达节点为机器执行时，跳过工作到达 / 发送成功推送 |
| 轨迹 / 时间轴 | 过程节点标 [过程执行]，人工节点标 [人工执行] |
| 节点事件 | 过程连发仍走完整发送，发送前事件、方向条件、接收人规则全部生效 |
| 延期发送 | 复用机器通道 + 延期时间，到点由同一定时任务发出 |
| 身份切换 | 过程连发按待办人登录，结束后切回原操作员，审计主体清晰 |
过程节点不是「跳过引擎」的脚本钩子，而是 仍受接收人、方向条件、阻塞、事件约束的系统执行者。外部 API 失败可以按节点停下，而不是整条流程无声丢失。
八、典型场景
跨系统编排（过程执行）
一次人工发送后，连续节点分别申请许可、向并行系统分发、写 Kafka、回写 FTP。过程执行页时间轴按节点展示耗时与 JSON 返回，失败停在具体过程节点。
夜间批量过账（机器执行）
归档、生成凭证、同步主数据放在机器节点，由服务扫描发送，白天待办箱保持干净。
能过则过（混合执行）
表单完整且规则满足时打开即走；缺附件或条件不成立时停留给操作员。一个节点覆盖两种命运。
工位扫码（流水线执行）
同一工位处理同一节点的多件任务，按二维码发送，按日统计已过站数量。
定时再发（延期发送）
人先填完，约定小时后再发。待办临时变为机器态，到期自动进入后续人工或过程节点。
这些场景不需要五套引擎，只需要五种节点的执行方式。
九、CCBPM 特色归纳
-
一个枚举贯通设计期与运行期
节点属性 → 待办行 → 定时任务 / 发送循环 / 流水线接口 / 前端标签，语义不漂移。 -
人机协同是一等模型，不是插件
操作员、机器、混合、流水线、过程并列，而不是在用户任务旁边外挂「自动步骤」。 -
过程可观测
连发不是后台黑盒。发送后转向 6/7 + 过程执行页把执行中、停留、失败、耗时、API 返回摊在时间轴和流程图上。 -
自动通道可复用
机器执行同时服务「节点自动发送」和「延期发送」，调度、身份、原子清标记都在同一条链上。 -
面向模式，而不是面向节点类型爆炸
枚举属性 + 同一套发送。扩展新执行者主要是加枚举值与一条调度策略，而不是复制一套节点运行时。 -
低代码可配、高代码可嵌
设计器右键改节点的执行方式；事件与过程承接外部系统。集成复杂度留在过程节点里，主流程图形仍然可读。
十、配置要点（给实施与二次开发）
- 连续系统步骤请设 过程执行（4），不要设成机器执行（1）：后者进定时扫描，前者在当次发送内连发，时延与事务边界不同。
- 需要人盯进度时，上一人工节点的 发送后转向 选 6 或 7。
- 过程节点仍要配置接收人：连发会按待办人切换身份，便于权限与审计。
- 外部调用放在节点发送事件 / 过程，返回信息会出现在过程页「结果」区。
- 机器节点默认不进待办、不发到达消息；若业务必须通知人，请用独立消息策略，不要依赖默认到达推送。
- 流水线节点走专用待办接口，不要期望出现在普通「我的待办」里。
结语
节点的执行方式，表面是节点上的一个下拉框，背后是 CCBPM 对「工作到底由谁做完」这个问题的产品化回答：
人可以批，机器可以跑，打开可以试，工位可以扫，过程可以连发——并且人能看见。
把五种执行者收进同一属性、同一发送引擎、同一套实体映射，再配上过程时间轴，这是驰骋 BPM 区别于「只会画人工审批链」的工作流工具的关键能力。实施时改的是枚举，运行时调度的是引擎，用户看到的是过程。属性即能力，模式即产品。
