审批规则引擎：条件审批、会签、或签、顺序审批、并行审批

说实话，规则引擎这东西，我刚开始接触时觉得就是个if-else的复杂版。后来在双人审批系统里踩过几次坑，才真正理解为什么需要专门的引擎来做这件事。

简单说，审批规则引擎就是一套可配置的决策逻辑。它决定了：
谁审批？几个人批？按什么顺序批？满足什么条件才能过？

本章我把常见的五种模式拆开讲。每种我都会给个真实场景，再说说坑在哪儿。

1. 条件审批

条件审批，说白了就是根据业务数据走不同的审批链。比如报销单：金额≤1000走直线主管，1000～5000加财务经理，超5000再加CFO。

我在一个合同审批项目里遇到过这种情况：起初把所有条件写死在代码里，后来业务方隔三岔五改金额阈值，改一次发一次版。后来换成了规则引擎，把条件暴露成配置，字段来源、比较符、阈值全都可配。嗯，这个世界清静了。

2. 会签

会签就是“所有人签了才能过”。典型的场景：合同需要法务、财务、业务三方全部同意，缺一不可。

属性	说明
参与人	预定义列表，或角色组（比如部门经理全部为会签人）
通过规则	100% 同意；有人拒绝则整个流程拒绝
超时处理	可设超时自动跳过（需记录）或转为转审
并行/串行	通常会签建议并行发送，节省时间

你想想看，如果三个人会签，A批了，B驳回了，这时候C还没看到。系统应该怎样？我的经验是：一旦出现驳回，立即终止其余待办并进入驳回分支。别让C白干。

3. 或签

或签就是“只要有一人同意就过”。常用于紧急审批、轮值审批、随机指定审批人。

举个例子：运维变更审批。三个值班SRE任意一人同意就能执行变更。没必要所有人都同意，浪费时间。

注意：或签不是“优先抢单”，而是“任意一人即可”。实现时我建议把待办同时推送给所有人，谁先处理就采纳谁的结果。后处理的直接忽略，但需要告知“此单据已被xxx审批完毕”，避免混淆。

4. 顺序审批

顺序审批就是一条链，一个一个来，前一个人批完才能到下一个。这其实是传统OA最经典的模式。

• 典型场景：请假审批：直属领导 → 部门总监 → HR
• 特点：审批人有严格的先后关系，不可跳过
• 实现注意：当前环节审批人如果离职或被占用，需要有“转审”或“加签”机制

我在一个金融系统里见过更复杂的顺序审批：中间某个人可以“加签”一个协办人，协办人必须先审，然后原审批人再审。这种串中嵌套的顺序就很考验引擎的节点管理能力。我个人建议在设计数据模型时，用链表结构存审批步骤，每个节点指向下一节点，方便动态插入。

5. 并行审批

并行审批是把单据同时发送给多个审批人，他们各自独立决定。最终结果根据配置决定：是“全部通过才过”还是“任一通过就过”。

注意：并行审批和会签其实很相似，但核心区别在于——并行审批允许不同的审批人有不同的意见，且最终结果可以通过加权计数来决定（比如3人中有2人同意即通过）。而会签必须是100%通过。

特性	并行审批	会签
通过条件	可配（全部/多数/任一）	必须全部通过
审批人独立性	完全独立，结果可不同	独立，但失败即终止
典型场景	预算分摊审批（各部门独立确认费用）	合同合规审查（法务+财务必过）

嗯，这里要注意：并行审批如果走“多数通过”策略，必须明确“多数”的定义——超过50%？还是超过2/3？边界情况（偶数平票）怎么处理？我在一个项目里就发生过平票，最后系统卡住了。后来加了“由发起人最终决策”的兜底规则才解决。

组合使用是常态

其实大多数生产系统不会只用一种模式。比如：

1. 第一步：条件审批（根据金额选链）
2. 第二步：并行审批（多部门同时审批）
3. 第三步：会签（法务+财务最后双签）

引擎必须支持节点嵌套和模式切换。我个人习惯把整个流程定义为一个有向图，每个节点标记自身模式（条件/会签/或签/顺序/并行），这样扩展性最好。