系统设计 / 审批流 · 把签字流程做成引擎 / 并行会签的归并策略 待审核 2 / 3
countersign · 并行会签

并行会签的归并策略

串行是排队，并行是同一张单同时摆到几个人面前。随之而来的问题是几票算过，这由归并策略（quorum）回答：把多个子结果归并成一个父结果。常用的三种是 any（一票通过）、all（全票通过）与 N-of-M（够 NN 票通过）。

图 0-1 · 财务、法务、HR 三位审批人逐个投票时三种归并策略的判定时点。可切换策略并逐票投出，观察何时定局，以及定局后其余人的待办如何结束。

1 · 三种归并策略

策略 通过条件 否决条件 典型场景
any 或签 通过票 ≥ 1 全部驳回 任一值班经理批了即可放行
all 会签 全部通过 驳回票 ≥ 1 财务、法务、HR 都点头才能签合同
N-of-M 阈值 通过票 ≥ NN 驳回票 > M−NM - N 5 位委员里 3 人同意即过

N-of-M 的否决条件值得单独推一遍。设已有 RR 票驳回，则剩余可用的赞成票最多 M−RM - R 张；只要 M−R<NM - R < N，即 R>M−NR > M - N，通过就已不可能。前两种策略是它的端点：N=1N = 1 时否决条件退化为 R>M−1R > M - 1，即全部驳回，正是 any；N=MN = M 时退化为 R>0R > 0，即一票驳回即否决，正是 all。

建议 · 定局即结束（short-circuit）。any 里只要有人先批，其余人的待办立即失去意义；all 里只要有人先拒，其余人也不必再看。流程引擎须主动撤销这些 pending 任务，否则它们会沉淀成永远处理不掉的僵尸待办。上面推出的阈值边界正是引擎判断「可以撤销了」的时点，不必等所有人投完。

注 · 会签人写死是简化。真实场景常是「所有部门经理会签」，人数运行时才定，节点需要动态展开成 nn 个并行子任务，再按同一套策略归并，即多实例（multi-instance）。归并逻辑本身完全复用，动态部分只在于展开这一步。