审批流程

在实践中

审批流程远早于工作流软件——采购申请、变更评审委员会、授信委员会、药物试验放行，编码的都是同一个模式。有三个性质把真正的审批流程与「看起来像审批的通知」区分开来。变更必须在请求待决期间真的被挡住，而不是一封邮件躺在收件箱里没人读、事情照样往前走。决定必须可归属到一个在做决定的那一刻确实持有该权限的人，而不是归属到一个共享邮箱。以及路由必须对着组织解析，而不是对着人名——绑死在具体人身上的审批链，会在下一次组织调整时悄悄断掉，然后路由给一个已经离职的人。三条一条都不满足的，是一个带延迟的通知。

在 ObjectStack 里，审批不是一个独立系统，而是流程里的一个持久节点：运行到达审批节点，开出一个请求，挂起，等一条决定被记录下来之后，再沿它的 approve 或 reject 出边恢复。审批人可以声明为某个用户、某个角色、某个团队，或申请人的上级链，并在请求发起时对着实时身份解析——一个岗位会展开成当前持有它的人。每一步设定自己的行为，于是一个节点可以是「首个响应即生效」，下一个是「必须全票」；lockRecord 让记录在待决期间保持不动，没人能越过审阅者去改；maxRevisions 给退回修改的循环设上界，一个请求不会在「请修改」里永远打转；onEmptyApprovers 决定审批人名单解析为空时怎么办，默认交给管理员接管，而不是悄悄把记录放行。决定会在运行继续之前先写进审计账本，于是不存在任何一条「没有记录决定就越过审批」的路径。这也是 AI 提出的结构性变更所进入的同一个队列——那份 diff 本身就是请求——正是这一点，让 Agent 写出来的软件变成一个人可以签字的东西，而不是事后才发现的东西。

对任何审批引擎都值得追问的是：它的截止时间住在哪里？在这里，诚实的答案是范围很窄。流程里的 wait 节点完全没有超时：曾经有两个键声称有，两个都被退役了，而不是留着当一句运行时并不兑现的承诺。升级只存在于审批节点上，而且是逐节点的 SLA，不是一个全局定时服务。设置 timeoutHours，一次扫描会找出自创建起超过该小时数仍处于待决的请求并逐个升级，每个请求一生只升级一次，执行配置的 action——notify、reassign、auto_approve 或 auto_reject——escalateTo 指向一个用户或一个会展开成当前持有者的岗位，而升级的审计行先写，于是崩溃或重跑的扫描不会重复触发。由此得到的设计结论值得直说：如果某一步必须有时限，就把它建模成一个带 SLA 的审批，或者从流程外部驱动那个截止时间。一个光秃秃的 wait 会耐心地、正确地、永远等下去。