管理系统的审批流：会签、加签、撤回与智能体代办的四个设计点

一套采购审批，流程图三天就画完了。上线两周，业务群里开始出现另一类问题：「这张单子帮我加个财务总监的签」「已经批过的单子能不能撤回改金额」「王经理离职了，卡在他那里的单子怎么办」「同一张单子两个人同时点了同意，怎么走了两遍」。这些问题没有一个是画图能解决的。

审批流看着是把线连起来，实际是把组织规则写成一套可执行的状态机：谁在什么条件下、以什么身份、对哪条数据、做了什么动作，做完之后数据变成什么状态，能不能回退，回退到哪一步。图画得再漂亮，这五件事没定义，系统上线后就要靠人补。

这篇文章只讲管理系统的审批流设计，不讨论 OA 选型，也不讨论智能体能不能替代审批人。文中引用的标准与法规写明出处；具体节点、金额阈值与审批层级要按客户组织与制度确定，不套用统一模板。

一、先分清四个对象，不要把它们塞进一张表

审批流出问题，很多时候是因为四个对象被混成了一个「流程配置」页面。

表单。这次申请的内容——金额、供应商、合同号、附件。表单字段决定条件分支，也决定审批人怎么解析。金额写的是含税还是不含税、合同号是不是必填，都会影响后面的判断。

流程定义。节点顺序、分支条件、每个节点的审批人规则、会签方式、超时策略。它是模板，不是某一张单子。模板改了，已经发起的单子不应该跟着变。

流程实例。某一张单子发起后生成的那一条运行记录。它必须记住自己用的是哪个版本的流程定义、发起时解析出来的审批人是谁、每一个节点的进入和离开时间。

审批动作。同意、驳回、撤回、转办、加签、催办。每个动作改变的是实例的状态，不是流程定义。把动作做成按钮很容易，把每个动作的语义定清楚很难。

把这四层分开，后面很多问题才有地方放。比如「流程改了，在途单怎么办」是实例与定义的关系；「两个人同时点同意」是动作的并发控制；「离职了审批人是谁」是解析规则与兜底。四层混在一起，开发只能把所有规则写进一段又长又难改的判断里。

二、五个卡点，通常在上线后才暴露

1. 流程定义一改，在途单跟着变

常见的做法是把流程配置存在数据库里，运行时按最新配置走。结果是：采购制度改了一版，昨天发起的单子今天突然多出一个节点，或者原来要过的财务节点消失了。审批人看到的是「怎么和我发起时不一样」，发起人看到的是「怎么又要重新批一遍」。

正确做法是发起时冻结。实例保存流程定义版本号、节点快照和审批人解析结果；在途单按发起时的版本跑完，新单子用新版本。需要强制迁移的，单独做迁移工具，并记录迁移人、迁移时间和影响范围。冻结不是把数据复制一份就完了，还要让旧版本的节点在处理待办时仍能被正确解释。

2. 会签只写了「多人审批」，没写怎么算通过

会签至少有三件事要定：参与人怎么来、通过条件是什么、有人不表态怎么办。参与人可以是固定角色、部门负责人、表单里指定的几个人；通过条件可以是全票、按比例、或者出现一票否决就终止；不表态可以视为弃权、超时提醒，或者到期按规则处理。

如果需求里只写「财务部会签」，开发只能猜：三个人里两个人同意算不算过？财务总监没点算不算？把人加进来又撤掉，算不算已经表态？这些猜法上线后一定会被业务推翻。

3. 撤回、驳回、重提混着用

三个动作在页面上都像「把单子退回去」，语义完全不同。撤回是发起人把还没被处理的单子收回来；驳回是审批人认为内容不成立，退给发起人或者指定的前序节点；重提是修改后再次提交。三者对应的数据变化、通知对象、审批记录保留方式都不一样。

更麻烦的是「已经有人批过还能不能撤回」。有的企业允许，有的不允许；允许时是原单继续跑，还是作废后新开一张。这个规则不在需求阶段定死，开发只能按自己的理解写，最后变成每个项目一套，运维也说不清。

4. 审批人写成了具体的人

流程配置里直接选「张三」，当时能跑，三个月后张三调岗，单子就卡住。审批人应该写规则：发起人的部门负责人、申请金额对应级别的总经理、表单里选定的项目负责人、某个角色下的全部或指定一人。规则要能回答「解析不到人怎么办」，而不是等到上线后由管理员手工改单。

5. 代理、离职、超时没有兜底

审批人请假、离职、长期出差，是流程运维的日常。代理要有时效和范围，不能永久接管；离职要触发待办转移；超时要能提醒、升级，必要时转给兜底人。自动通过要谨慎，只适合金额小、风险低、规则明确的节点，并且要留下「为什么自动通过」的记录。

这些规则听起来琐碎，但它们决定了流程在真实组织里能不能跑满一年。演示环境里审批人永远在线，生产环境里审批人会休假、会调岗、会忘记点。

三、四个设计点：会签加签、撤回重提、审批人解析、版本冻结

1. 会签与加签：通过条件要能写成测试用例

会签不是「多个人审批」这么一句话。落地时要拆成四个字段：参与人集合、通过条件、否决条件、超时处理。参与人集合可以来自角色、部门、表单字段或者指定人；通过条件要明确是全票、过半、按人数比例，还是按权重；否决条件要明确是一票否决还是达到某个比例才终止；超时处理要明确是提醒、升级、转办还是自动弃权。

加签分前加签和后加签：前加签是在当前审批人之前插入一个节点，后加签是在当前节点之后、下一节点之前插入。加签会改变后续的审批顺序，因此要记录加签人、被加签人、加签位置和原因。加签不是转办，原审批人仍然保留在记录里；转办则是把当前待办交给另一个人，原审批人退出当前节点。

这些规则写成文字容易含糊，写成测试用例就清楚了：三个人会签，两人同意一人未表态，实例应该停在哪个状态；加签后原审批人还能不能看到待办；一票否决后其他审批人的待办是否自动关闭。用例跑不通，说明规则还没定完。

2. 撤回与重提：先定「已经批过」的边界

撤回的边界要写进需求：只允许撤回自己发起、且还没有任何审批人处理的单子；只要有人处理过，就只能走「终止并新开」或者「退回发起人修改后重提」，不能悄悄把已审批记录抹掉。终止要保留原单和全部审批记录，新开的单子关联原单号，方便对账。

重提也要区分两种情况：原单继续跑，还是生成新版本。原单继续跑适合只改附件、不改金额的场景；生成新版本适合金额、供应商、合同条款发生变化的场景。两种做法在审计上的含义不同，不能由开发临时决定。

下面这张表把五个常用动作的语义放在一起，需求评审时可以直接对照。表格里「是否可逆」一列经常被忽略，但它决定了要不要保留历史版本。

3. 审批人解析：把「找谁」做成一个可替换的解析器

审批人不要直接存人名，要存解析规则。常见的五类规则是：指定人、角色、部门负责人、发起人上级、表单字段指定人。每一类都要有明确的解析时机——是发起时解析一次，还是每个节点进入时再解析。发起时解析适合固定审批人，节点进入时解析适合按当前组织实时取负责人。

解析失败要有兜底链：先按规则逐级上溯，比如部门负责人找不到就找上级部门负责人；仍然找不到，转给配置的兜底人或者流程管理员；兜底也为空，流程不能静默卡住，要生成一条待处理的异常任务，并通知发起人。解析过程要留痕，记录用了哪条规则、命中了谁、为什么落到兜底。

这块做成统一的解析器，后面加「按项目组」「按区域」「按金额区间」都只是新增一类规则，不用改流程引擎。反过来，如果每个节点都写一段取人代码，组织一调整就要改很多地方。

4. 版本冻结：新单用新版，老单跑完

流程定义的每次发布都要有版本号，实例发起时记录版本号并冻结节点、审批人规则和表单校验规则。修改流程只影响新发起的实例；在途实例继续按冻结的快照执行。需要升级在途实例时，走单独的迁移流程：先列出受影响的实例、当前节点、迁移后的节点，再由流程管理员确认，迁移记录进入审计日志。

这套做法会增加一点存储和查询成本，但能避免「改一次流程，所有在途单重新审批」这种事故。对于审批周期长的场景，比如合同、用印、付款，这个成本是值得的。

四、技术实现：状态机、快照、幂等与审计

状态机与审批解耦。单据状态由业务状态机管理：草稿、审批中、已通过、已驳回、已撤回、已作废。审批节点只是状态迁移的守卫，不直接改业务状态。这样同一张单子可以先走审批、再走付款、再走归档，审批流换了，业务状态仍然清楚。

实例快照。发起时保存流程版本、节点列表、审批人解析结果、表单关键字段。快照不是日志，它是运行时的依据；日志是事后回放的证据，两者都要有。

并发与幂等。同一节点多个审批人同时操作，或者用户连续点击两次提交，都会导致重复推进。做法是给实例加版本号，审批动作携带版本号做乐观锁；同时给每个动作生成幂等键，键由实例、节点、审批人、动作和客户端请求号组成。重复请求返回次结果，不重复推进，也不重复写审计。

通知与超时。提醒、升级、自动转办由服务端定时任务驱动，不靠前端计时，也不把「消息已发送」当成「审批已处理」。通知失败要重试并记录，超时规则要能按节点配置，而不是全局一个值。

审计留痕。每次动作记录：谁（本人、代理人还是智能体）、以什么身份、什么时间、从哪个入口、对哪条数据、做了什么、变更前后的值。代理要标明代，智能体要标来源。审计表按追加写，不提供修改和删除接口。

电子签名的边界。系统里的「同意」按钮是内部审批记录，不等同于法律意义上的电子签名。需要法律效力的合同、授权书，要按《电子签名法》第十三条、第十四条评估是否满足可靠电子签名条件，接入合规的电子签平台，并把签署结果回写到审批记录。内部审批与对外签署是两条链，不要用一条链代替。

五、智能体代办：能做什么，不能做什么

智能体接进审批流，价值不在「替人点同意」，而在把发起和催办这两头的重复动作接过去。边界划清楚，反而更容易落地。

可以做的三件事。一是起草：按模板填单、带出历史同类单据、检查附件和必填字段，生成一张待人工确认的草稿。二是查询：查制度、查额度、查同类单的处理结果，回答「这张单现在卡在谁那里」。三是催办与摘要：按待办列表提醒审批人，汇总卡点，给出「还差哪几个节点」的说明。

不建议做的三件事。代替审批人点同意或驳回；修改已经产生的审批记录；绕过会签、加签或超时规则。审批是有责任的判断，责任在人，智能体可以准备材料、给出建议，但不能替人承担签字后果。

接入方式。起草时以发起人身份调用，权限不超过发起人本人；需要跨系统查询时，用单独登记的服务账号，只授予必要的只读范围，不与人的账号混用；工具集只暴露读取接口和「创建草稿」，不暴露审批接口。智能体生成的草稿、建议和调用记录要单独标记，人工确认后再进入审批流。

审计要能回答三个问题。这条建议是谁在什么时间、基于哪些数据生成的；它调用了哪些接口、返回了什么；人工最终改了什么、为什么改。三个问题答不上来，智能体在审批场景里就只能停在演示。

六、交付物与验收

审批流项目结束时，交付的不应该只是一套能点的页面。下面六份材料决定了上线后能不能维护：流程清单与状态机图；审批矩阵（节点、审批人解析规则、会签条件、超时与兜底）；流程版本与迁移方案；异常与越权用例集；审计日志字段说明；运维手册（代理、离职、超时、流程变更）。

验收指标按周可记录，不用「流程顺畅」这类无法验证的说法。可以看六项：审批用例通过率；流程改版后在途实例不受影响的比例；审批人解析成功率（含兜底命中）；重复提交不重复推进的验证结果；审批记录能否回放到具体单据；各节点平均处理时长。指标用来发现卡点，不作为对客户的承诺。

七、边界与成本

不是所有审批都值得上系统。低频、单人、没有留痕要求的确认，用邮件或一张登记表就够；流程越复杂，配置、培训和运维成本越高。建议先跑三到五条主流程，比如采购、付款、合同、用印、请假，跑顺了再扩。

组织治理是前提。组织架构天天变、岗位职责说不清、代理人随意指定，再好的流程引擎也只能把混乱固化下来。上线前至少要把审批人规则、代理规则和离职交接规则定下来，否则系统只是把线下的等待搬到了线上。

涉及个人信息、财务数据与合同文本的审批，还要按《个人信息保护法》的最小必要原则和安全措施要求处理；具体合规义务由客户法务确认，本文不构成法律意见。

八、常见问题

能不能完全照现在的纸质流程做？

可以照着做，但要先区分「必须保留的控制点」和「历史习惯」。纸质流程里常有重复签字、并行补签、先办后补的动作，直接搬进系统会把等待时间放大。建议先把控制点列出来，再决定哪些合并、哪些保留。

流程改了，在途的单子怎么办？

默认按发起时的版本跑完，新单用新版本。需要统一升级的，走迁移工具，列出受影响实例并由管理员确认。不要用「运行时读最新配置」的做法，否则在途单会在审批人不知情的情况下变节点。

审批人离职或长期出差怎么办？

代理要有有效期和授权范围，离职触发待办转移，超时按节点规则升级或转兜底人。代理期间产生的审批记录要标明代，事后能查清是谁以谁的身份做的。

智能体能不能直接审批？

不建议。智能体可以做起草、查询、催办和摘要，审批动作留给有责任的人。确需自动处理的，只放在低风险、规则明确、可回滚的节点，并保留人工复核入口。

能不能设置超时自动通过？

只适合金额小、风险低、制度明确允许的节点，并且要记录自动通过的依据、时间和规则版本。合同、付款、用印这类节点不建议自动通过，超时应该升级给上级或兜底人，而不是默认放行。

附：口径与来源

· OMG《Business Process Model and Notation (BPMN) 2.0》，规范编号 formal/2011-01-03，2011 年发布；2013 年成为 ISO/IEC 19510:2013。本文只用它说明流程建模与执行语义的分层，具体引擎实现按选型确定。

· W. M. P. van der Aalst 等《Workflow Patterns》，Distributed and Parallel Databases 14(1):5–51，2003 年。会签、并行分支、同步汇合等控制结构的讨论，参考了这套模式分类。

· OWASP Top 10:2025，A01「失效的访问控制」、A09「安全日志和告警失效」。审批接口的越权与审计缺口，按这两类的检查思路设计用例。

· OWASP Application Security Verification Standard（ASVS）5.0，2025 年 5 月发布，共 17 章、约 350 条要求。访问控制与日志要求在服务端实现，前端隐藏不作为权限依据。

· NIST SP 800-53 Rev.5，AC-2 账户管理、AC-3 访问执行、AC-6 最小权限。用于说明审批账号、代理账号与服务账号的权限边界。

· 《中华人民共和国电子签名法》（2019 年修正）第十三条、第十四条：可靠的电子签名需满足专有、可控、改动可发现等条件，并与手写签名或盖章具有同等法律效力。内部审批点击不等同于可靠电子签名。

· 《中华人民共和国个人信息保护法》第六条、第五十一条：处理个人信息应具有明确、合理的目的，限于实现处理目的的最小范围，并采取相应的安全措施。审批数据涉及个人信息时按此评估。