Wiki Notes

Appearance

多阶段审批链专题 ​

版本：v1.5

最后更新：2026-07-09

适用对象：正在做高风险 Agent、企业审批助手、对外发送型工作流、批量数据处理和需要把自动化动作接入人工审核的产品、平台和安全治理同学

很多 AI 工作流一开始只有一个简单审批节点，但随着风险上升，团队很快会发现：

  • 一个审批人看不住所有风险
  • 一个审批动作无法覆盖业务、合规和技术视角

这时就会进入多阶段审批链设计。

这篇专题真正想解决的不是“怎么多加几个审批节点”，而是：

  • 如何按风险把审批拆成多关
  • 每一关该看什么
  • 如何把机器预审、人审、状态机和执行审计接成闭环

根据 2026-07-09 可访问的 OpenAI Guardrails and human review、Safety in building agents、Safety best practices、Anthropic 关于 human confirmation 的文档，以及 NIST AI RMF Playbook 中关于角色、监督与流程治理的资料，一个很值得先建立的共识是：

审批链不是为了增加流程层级，而是为了把不同类型的风险交给最适合判断的人或控制点。

1. 什么是多阶段审批链 ​

更实用的理解通常是：

  • 把高风险任务拆成多个审批关口
  • 每一关只处理自己最擅长判断的风险

它不是为了增加流程层级，而是为了减少错误放行。

1.1 为什么单点审批经常不够 ​

因为现实里的高风险任务往往同时涉及：

  • 业务正确性
  • 权限边界
  • 数据合规
  • 外部动作执行
  • 品牌与舆情风险

如果只依赖一个审批节点，经常会出现：

  • 看懂业务的人不懂系统风险
  • 看懂系统的人不了解业务影响
  • 能判断合规的人没看到完整上下文

2. 适合做多阶段审批的场景 ​

尤其这些任务更适合多阶段审批链：

  • 对外发送高价值内容
  • 访问敏感企业知识
  • 批量操作客户数据
  • 调用高风险外部工具
  • 触发财务或合同相关动作
  • 变更生产系统状态

这类场景里，审批链本身就是产品的一部分，而不是上线后的临时补丁。

3. 一个常见的审批链分层方式 ​

可以按关口拆成：

3.1 机器预审 ​

  • 规则过滤
  • 敏感词与策略检查
  • 风险分级
  • 明显异常先拦住

3.2 业务审批 ​

  • 判断业务目标是否合理
  • 判断内容是否能发
  • 判断这件事是否值得做

3.3 安全或合规审批 ​

  • 判断是否越权
  • 判断是否触碰敏感边界
  • 判断是否需要升级权限或人工豁免

3.4 最终执行确认 ​

  • 在真正执行前做最后一次确认
  • 确认实际动作和审批对象一致
  • 确认执行环境和目标范围没有漂移

OpenAI 当前 Guardrails and human review 文档的核心边界也很明确：

  • guardrails 负责自动校验
  • human review 负责批准或拒绝敏感动作

4. 为什么“机器预审”和“人工审批”要分开看 ​

很多团队会把规则命中误当成“已经完成审批”。

这通常会带来两个问题：

  • 机器能拦一部分明显风险，但拦不住业务和语境风险
  • 人工审批如果看不到规则结果，也不知道系统为什么把它送来

更稳的做法通常是：

  • 机器预审负责筛、标、分级
  • 人工审批负责判断是否放行、退回或升级

5. 审批链设计时最容易遗漏什么 ​

很多团队只画“谁来批”，却没有设计：

  • 每一阶段的输入是什么
  • 产出是什么
  • 超时怎么办
  • 驳回后回到哪一步
  • 跳过审批是否允许

这些如果不明确，流程一长就会失控。

5.1 每一关最好至少回答四件事 ​

  1. 看什么材料
  2. 做什么判断
  3. 输出什么结果
  4. 失败或超时后谁接

6. 为什么状态机和审批链通常要绑在一起 ​

只要审批链超过一个节点，系统就必须知道：

  • 当前卡在哪一关
  • 上一关是谁批的
  • 下一关何时触发
  • 驳回后如何回退
  • 当前审批对象是否已被修改

所以多阶段审批链几乎都需要配合状态机。

6.1 没有状态机时常见的问题 ​

  • 审批人不知道现在到第几步了
  • 驳回后回退逻辑混乱
  • 一旦超时就没人知道该怎么办
  • 执行和审批记录对不上

7. 多阶段审批链怎么兼顾效率 ​

审批链多并不一定代表慢。

更稳妥的优化方式通常是：

  • 低风险任务走快速通道
  • 高风险任务才进入完整链路
  • 机器预审先过滤明显问题
  • 对重复性稳定任务做策略豁免

重点不是“阶段越多越安全”，而是：

  • 不同风险走不同链路

7.1 更实用的三类路径 ​

  1. 可自动放行
  2. 需补充信息后重审
  3. 需更高权限人工确认

如果系统只有“通过 / 不通过”两种结果，审批链通常会越来越僵硬。

7.2 串行审批、并行审批和会签不要混着用 ​

很多团队说“多阶段审批”，但实际上没有把审批拓扑设计清楚，最后常见情况是：

  • 所有节点都串行，整体时延过长
  • 本来该会签的风险，被一个人单独放过
  • 本来只需要业务确认的场景，却被安全、法务、平台全部串起来

更稳的设计通常至少区分三类：

  1. serial approval 前一关通过后，下一关才出现。
  2. parallel approval 多个角色同时审批，汇总后再继续。
  3. quorum / co-sign 不是所有人都必须批，但必须满足最低会签条件。

这三种模式更适合解决的是不同问题：

  • 串行更适合强依赖前置判断的链路
  • 并行更适合独立视角同时审阅
  • 会签更适合高价值高风险动作

如果不把它们拆开，审批链就很容易：

  • 要么太慢
  • 要么太松

8. 审批链和权限模型要联动，而不是各管各的 ​

很多问题不是审批人没批，而是：

  • 根本没有权限批
  • 批了也没有执行权限
  • 批准和执行对象不是同一个范围

所以审批链设计最好和下面这些一起看：

  • 角色权限矩阵
  • 多租户边界
  • 高风险工具动作
  • 审计记录

否则很容易出现：

  • 流程看起来严谨，落地却仍然越权

9. 审批链最容易卡住的地方 ​

最常见的卡点包括：

  • 审批上下文不完整
  • 驳回理由不结构化
  • 上下游没有统一 trace / request id
  • 超时后没人接手
  • 最终执行和审批记录断开

这些问题一旦出现，复盘就很难回答：

  • 到底是谁批的
  • 批的时候看到了什么
  • 为什么最终还是出了问题

10. 一个更可执行的多阶段审批链视角 ​

很多真实系统会同时存在三层材料：

10.1 事实层 ​

  • 输入内容
  • 检索证据
  • 工具参数
  • 目标对象范围

10.2 解释层 ​

  • 模型建议
  • 风险标签
  • 规则命中结果
  • 历史相似案例

10.3 动作层 ​

  • 审批结论
  • 执行动作
  • 回滚入口
  • 审计记录

审批链如果只给人看“最后结论”，不给事实层和解释层，审批质量通常会很差。

11. 审批结果为什么要结构化 ​

很多团队让审批人只点：

  • 通过
  • 驳回

但这对复盘和后续流程不够。

更好的做法通常是让审批结果至少带上：

  • 结果类型
  • 驳回或通过理由
  • 风险分类
  • 是否需要补材料
  • 是否升级到更高权限

这样后续才能做：

  • 统计
  • 复盘
  • 案例回放
  • 规则优化

11.1 结构化审批结果最好显式区分“放行理由”和“风险接受理由” ​

很多审批结果里，大家只会写一句：

  • 已批准

这对事故复盘远远不够。

更稳的结构化对象通常最好把两件事拆开：

  • approval rationale
  • risk acceptance rationale

前者更偏：

  • 这件事为什么满足业务和流程要求

后者更偏：

  • 哪些风险被接受了
  • 为什么接受
  • 是谁承担接受责任

这一步在高风险 AI 工作流里特别重要，因为很多问题不是“审批人没看”，而是：

  • 风险明明看到了，但没有被显式记录是谁接受了它

11.2 一票否决字段最好显式建模，不要让它埋在自由文本里 ​

有些审批条件本质上不是“给个综合意见”，而是：

  • 只要命中就必须拦住

例如：

  • 越权访问
  • 对外高风险写操作
  • 资金或合同变更对象不一致
  • 审批对象快照失配

这类条件更稳的做法通常是直接做成结构化布尔或枚举字段，而不是让审批人在备注里写：

  • “这里看起来有点风险”

因为一旦进到自动执行或复盘查询阶段，自由文本几乎无法稳定消费。

12. 为什么超时和升级机制是审批链的一部分 ​

审批链只设计“正常通过”，通常是不够的。

真实系统里更常见的问题是：

  • 审批人不在线
  • 审批材料不充分
  • 高风险任务在夜间触发
  • 需要更高一级角色介入

所以更稳的设计通常要明确：

  • 超时多久升级
  • 升级到谁
  • 夜间和节假日谁兜底
  • 是否允许人工转派

12.1 超时策略最好区分“可自动过期”和“必须阻塞” ​

很多审批链超时后只有一种处理：

  • 一律卡住

这在真实系统里通常不够。

更稳的设计通常会先按风险把动作分成两类：

  1. 超时可自动过期
    例如时效性很强但风险可控的任务，超时后直接作废，不继续排队。
  2. 超时必须阻塞
    例如高风险写操作、对外发送、资金或权限变更，超时后必须升级，不能默认通过。

如果这两类不分，结果通常会是：

  • 低风险任务被高风险流程拖死
  • 高风险任务因为赶时效被不合理放行

13. 为什么最终执行确认不能省 ​

前面都批完了，很多团队就直接执行。

但真实风险往往发生在最后一跳：

  • 审批时看的对象和执行时的对象变了
  • 参数被中途改写了
  • 目标范围扩大了
  • 上下文已经过期了

所以在高风险动作里，最后一次执行确认很有价值。

14. 审批链如何接入 observability 和复盘 ​

OpenAI 当前 Guardrails and human review、Safety in building agents 与相关安全资料都在说明：

  • 高风险动作不能只看最后有没有执行
  • 还要能回放审批链上的上下文和决策过程

推荐至少保留：

  • request id / trace id
  • 审批阶段
  • 审批人
  • 审批时间
  • 驳回或批准理由
  • 最终执行动作
  • 对应风险标签

这样后续才能做：

  • 审计
  • 复盘
  • 回归测试

14.1 审批链最好单独保留“阶段轨迹”，而不只是最终审批结果 ​

很多系统最后只留：

  • 这条任务通过了
  • 这条任务驳回了

但对多阶段审批链来说，这远远不够。

更值得保留的通常是：

  • 进入每一关的时间
  • 每一关看到的快照版本
  • 每一关的等待时长
  • 每一关的审批结论
  • 升级、转派、撤回和补材料轨迹

这样你后面才能真正回答：

  • 哪一关最容易卡住
  • 哪一关最容易误放
  • 哪一关的上下文最不完整

而不是只得到一个模糊结论：

  • “审批链总体有点慢”

15. 审批链如何和发布门禁联动 ​

多阶段审批链不是只在业务动作里使用。

它也很适合用于：

  • 高风险 Prompt 发布
  • 模型切换
  • 工具开放
  • 知识库大版本切换
  • 生产权限放开

这时审批链本质上就是：

  • 发布治理链

16. 哪些指标值得单独跟踪 ​

建议至少跟踪：

  • 各阶段通过率
  • 各阶段驳回率
  • 平均审批时长
  • 超时升级率
  • 审批后执行撤回率
  • 审批后事故关联率

这些指标能帮助你判断：

  • 审批链是真的有效，还是只是把问题变慢了

17. 常见反模式 ​

  • 所有任务都走同一条长链
  • 审批人只看到结论，看不到上下文
  • 审批超时后没有升级机制
  • 驳回理由不结构化，无法复盘
  • 批准和实际执行之间没有审计关联
  • 把机器规则命中误当成“已经完成审批”

18. 审批对象最好冻结，否则批的是 A，执行的是 B ​

很多审批事故不是“审批人判断错了”，而是：

  • 审批时看的对象和执行时的对象已经不是同一份内容
  • Prompt、参数、收件人、附件或目标范围在中途被改了
  • 人工看到的是摘要，最终执行的是另一版 payload

这在 AI 工作流里尤其常见，因为模型、工具、审批和执行往往不是一次同步完成。

更稳妥的做法通常是：

  1. 为审批对象生成不可混淆的快照 ID。
  2. 把关键参数、目标范围和风险标签固化进审批材料。
  3. 执行前校验“将执行对象”与“已批准对象”是否一致。
  4. 对高风险动作追加最终执行确认，而不是默认沿用旧审批结果。

18.1 哪些字段更值得冻结 ​

  • 收件人或外发目标
  • 写操作对象 ID
  • Prompt / policy / template 版本
  • 工具参数快照
  • 审批时引用的证据与附件

如果这些字段不冻结，审批链很容易看起来完整，实际却在最后一跳漂移。

18.2 审批快照最好支持重放，而不只是留档 ​

很多团队会保存审批快照，但只是为了审计留档。

更成熟的做法通常还会要求：

  • 这份快照能不能被拿来重放
  • 新策略能不能在旧快照上重跑
  • 新 guardrail 能不能在历史审批对象上做 replay

这件事很重要，因为审批策略经常会升级：

  • 新增规则
  • 调整风险标签
  • 改审批材料模板
  • 调整人审路径

如果历史快照不能重放，你就很难回答：

  • 新策略是真的更好
  • 还是只是让流程看起来更复杂

19. 审批链的 SLA、超时升级和人工容量要提前设计 ​

审批链真正上线后，最容易把系统拖慢的不是“审批多了一步”，而是：

  • 没人知道每一关最多该等多久
  • 夜间 / 节假日没人接
  • 高峰期审批积压，但没有升级和分流策略

Google SRE 的 on-call 与 incident response 实践对这里有个非常实用的启发：

  • 任何关键人工环节，如果没有时间边界和升级规则，最终都会变成隐性故障点

更稳妥的做法通常是为每一关明确：

  • 目标响应时长
  • 超时后升级到谁
  • 是否允许转派
  • 是否允许降级到“只读建议”或“暂停执行”

19.1 更值得单独跟踪的审批容量信号 ​

  • 各阶段积压量
  • 超时升级率
  • 夜间触发比例
  • 审批后人工返工率
  • 因审批拥塞导致的业务放弃率

这些指标能帮助你判断：

  • 审批链是在兜风险
  • 还是已经开始吞噬交付能力

19.2 审批容量最好和风险分桶一起算，不要只看总队列长度 ​

很多团队会盯一个总指标：

  • 当前审批队列有多少条

但这通常不够，因为真正危险的问题往往是：

  • 高风险桶只有几十条，但已经没人能在承诺时间内处理
  • 低风险桶几百条，却并不影响关键业务

更稳的容量观察通常至少按这些维度拆开：

  • risk tier
  • action type
  • tenant tier
  • approver group
  • working hours / after hours

这样你才能更准确地判断：

  • 该扩哪一组审批人
  • 该收哪一类高风险入口
  • 哪条链路已经在接近 SLA 红线

20. 推荐搭配阅读 ​

21. 重点官方资源 ​

以下资源已按 2026-07-09 复核到当前正式入口；其中少数站点对脚本探测可能受限，但浏览器入口仍可正常打开：

22. 落地检查清单 ​

  • 是否区分了机器预审、业务审批、合规审批和最终执行确认
  • 是否给每个审批阶段定义了输入、输出、超时和升级逻辑
  • 是否把审批链和角色权限、执行权限、审计链路打通
  • 是否为高风险动作保留了结构化审批结果和 trace 关联
  • 是否能在事故后回放“谁在什么上下文下批准了什么”