AI 工作流人工审批关卡：7 种可落地模式

定义真正的关卡，拒绝“表演式审批”

关卡必须在技术上阻断状态转换

只有存在有效决定，工作流才能取得覆盖动作所需的凭证、授权令牌或状态转换。若模型仍持有可执行工具，仅在提示词中写“等待批准”并不能形成控制。

通知不等于关卡

发送消息、展示面板或索要表态，本身都不会阻止动作。通知送达、审批人确认、结构化决定和执行授权是不同事件，必须分别记录与验证。

人工审阅不天然等于知情审阅

审批人需要看到准确的预期影响、关键证据、不确定性、可选方案和限制。隐藏变更、队列过载或只展示流畅摘要的界面，很容易让人工复核退化为机械点选。

有些动作即使批准也不能执行

审批不能推翻法律、同意范围、数据权利、合同限制、技术权限或组织政策。关卡只能控制原本允许的决策路径，不能把禁止动作变成合法动作。

建立可审计的审批记录

决策对象

保存准确动作、目标、参数、内容、金额、收件人及附件的版本或加密摘要。明确规范化序列化规则，既让等价值产生一致结果，也能发现有意义的变化。

审批人权限

记录审批人身份、认证会话、当前角色、权限范围、委托来源、冲突检查和法定人数位置。不要存储秘密；引用权威身份与策略系统给出的判定。

证据包

展示来源链接、验证结果、风险、可逆性、替代方案、未解决的不确定性、相关政策和预期下游影响。敏感证据应受访问控制，并记录审批人实际看到的版本。

决策生命周期

支持批准、拒绝和要求修改，并记录理由、时间、到期及撤销。要求修改应使旧决策对象失效并返回准备阶段，不能在既有批准之下偷偷修改对象。

执行关联

执行代理在放行前验证对象哈希、权限、有效期和未使用状态，再释放一个准确动作。随后记录操作 ID，并在权威状态核对完成后才把批准标记为已履行。

根据后果选择关卡，而不是根据方便程度

评估影响和不可逆性

数据披露、外部沟通、财务、用工、访问、法律、安全和运营影响都应显式分类。潜在伤害越大、越难撤销，关卡就应越靠前、约束越强。

区分确定性边界与人工判断

金额上限、收件人集合、数据结构、身份、到期和角色冲突应由代码检查；人员只负责政策真正委托给他们的情境判断。不要要求审批人弥补系统本可确定执行的控制。

衡量审批能力与延迟成本

形式完美却无法消化请求量的关卡，会诱发绕过和机械批准。应估算到达率、平均审阅时长、覆盖率、峰值负载和安全到期时间。低风险工作可以采用阈值或仅异常审批。

选择足够且最简单的模式

设计阶段先人工审阅，再采用平台原生审批或确定性工作流，然后才加入受控自动化和智能体辅助证据整理。只有在权限与状态转换仍清晰时，才组合多种模式。

模式 1：执行前审批

适用场景

适用于不可逆、对外、敏感或高影响动作，例如发送受监管通信、改变关键访问权限、承诺资金或作出客户可见决定。授权决定出现前，动作必须不可执行。

前置条件

定义决策对象、审批角色、证据、决定选项、到期、撤销、下游执行代理和失败路径。审批人必须能检查所有关键字段及附件。

技术强制

将可执行凭证或状态转换保留在模型之外。批准后，签发或验证一个绑定对象哈希、请求方、工具、租户和到期时间的一次性授权。

审批体验

先展示拟执行动作和预期影响，再展示风险、证据、不确定性和替代方案；突出准备后发生的任何变化。必须提供安全的拒绝和要求修改选项，而不只是“批准”。

主要失败方式

审批人只批准了摘要，但隐藏载荷、收件人或附件不同，或者工作流在批准后更改了它们。修复方式是绑定哈希，任何实质变化都重新审阅。

停止或升级条件

对象无法规范化、权限来源不可用、证据不完整、风险超出授权范围或执行状态未知时，停止处理并升级给控制负责人。

模式 2：确定性阈值审批

适用场景

适用于政策能用金额、数量、数据级别、地域、受众或风险等级表达的重复动作。边界内可以继续，越界则必须等待有权人员。

前置条件

阈值应来自正式政策且带版本、适用范围和负责人。明确聚合窗口、币种、单位、边界等号、缺失值和冲突规则。

技术强制

在可信执行层计算阈值，不让模型自行声明其动作“低于上限”。输入不足、政策冲突或计算失败时采用安全阻断，而不是默认放行。

审批体验

说明触发的确切规则、观察值、阈值、计算窗口和来源。审批人需要判断是否批准例外，而不是重新做本可自动完成的算术。

主要失败方式

团队只检查单次金额，却忽略累计支出、关联对象或短时间拆分动作。修复方式是加入聚合维度和反规避规则。

停止或升级条件

政策版本不明、单位无法比较、请求刻意拆分、关联对象不可解析或风险分类发生变化时，阻断并交给政策负责人。

模式 3：仅异常审批

适用场景

适用于经过验证、边界明确且正常路径高度重复的流程。只有结构校验失败、置信不足、策略冲突、新类别或结果偏离时才进入人工队列。

前置条件

建立可解释的正常范围、异常触发器、基线样本、监测指标和回退路径。异常检测自身也需要版本、测试和误报复核。

技术强制

所有触发器在执行前由确定性检查器或受控检测服务评估。任何检查缺失、超时或返回未知，都按异常处理而非跳过。

审批体验

首先呈现“为什么异常”，再给出正常基线、差异、证据和可选处理。让审批人能批准一次、修改规则候选、退回或升级，但不要让一次批准永久重写政策。

主要失败方式

团队只采集模型置信分数，把高置信误判当成正常。修复方式是组合业务规则、数据完整性、权限、漂移和结果核对信号。

停止或升级条件

异常率突然上升、基线失效、分类器或工具版本改变、队列容量耗尽或未知状态累积时，暂停自动路径并重新验证。

模式 4：双人审批

适用场景

适用于单人错误或滥用后果严重的高影响动作。两名独立且合格的审批人必须对同一个对象分别作出决定。

前置条件

定义所需角色组合、独立性、顺序或并行方式、否决权、替补、到期及一人要求修改后的状态。两个槽位都必须引用同一对象版本。

技术强制

执行代理验证两个不同的有效身份、角色资格、冲突规则、对象哈希和未撤销决定。第二个决定不能悄悄覆盖第一个人看到的对象。

审批体验

每名审批人都应看到完整证据和另一决定的可见范围。为避免从众，可在适当场景隐藏第一人结论，直到第二人提交独立判断。

主要失败方式

共享账户、同一委托身份或同一控制人占据两个槽位，形成表面上的双人复核。修复方式是比较有效控制关系，而非只比较用户名。

停止或升级条件

独立性无法证明、两人意见冲突、任一决定到期或撤销、对象发生变化、法定人数不足时保持阻断，并交给指定裁决者。

模式 5：职责分离审批

适用场景

适用于请求、准备、审批与执行不能由同一有效控制者完成的流程，例如访问变更、付款、敏感数据导出和关键配置发布。重点不是人数，而是相互制约的职责。

前置条件

建立角色矩阵，明确谁能发起、准备证据、批准、执行和核对结果。把委托、临时角色、服务账户、团队归属及利益冲突纳入有效身份模型。

技术强制

策略引擎在决定和执行时比较请求方、对象准备者、审批人和执行身份。发现禁止组合时直接拒绝，不能依赖人员自行声明“没有冲突”。

审批体验

界面应说明审批人为何具备资格、哪些参与者受到隔离，以及是否存在委托或替补。冲突提示必须可操作，同时避免暴露不必要的身份数据。

主要失败方式

系统只比较账号 ID，忽略同一人控制多个账号或通过委托填满两个角色。AG096 的 D23 正是这种否决失败，因此整次演练不能获准启用。

停止或升级条件

有效控制关系不清、目录同步过期、委托链循环、紧急权限未经复核或冲突策略无法求值时，阻断动作并由身份与控制负责人处理。

模式 6：限时与限条件审批

适用场景

适用于只在短时间、特定环境、固定上限或某个来源状态下有效的动作，例如维护窗口、一次性数据访问、限量发布和临时例外。

前置条件

定义开始与截止时间、时区、允许条件、最大次数、状态版本、撤销触发器和到期后的安全状态。时钟与条件来源必须可信且可审计。

技术强制

执行时重新验证时间、条件、对象版本、授权状态和使用次数，不能只相信批准时的快照。过期或条件改变后，授权令牌应无法使用。

审批体验

清晰展示授权何时开始、何时结束、可以做什么、最多几次以及哪些变化会立即失效。不要把无限期例外伪装成“临时批准”。

主要失败方式

审批在来源状态改变后仍被使用，或时区处理不一致导致窗口意外延长。AG096 的 D36 使用旧审批执行实质变化载荷，是第二项否决失败。

停止或升级条件

时钟不同步、条件来源不可用、版本不匹配、使用次数未知、撤销未传播或请求落在边界之外时，拒绝执行并要求新审批。

模式 7：用于有界可逆工作的事后复核

适用场景

只适用于低风险、有上限、可观测且可靠可逆的动作。它不是执行前许可，而是快速发现偏差、暂停后续自动化并触发恢复的监督模式。

前置条件

定义小批量上限、明确的允许范围、完整日志、权威结果检查、撤销方法、自动暂停阈值和复核时限。无法真正恢复的动作不适合此模式。

技术强制

每个动作仍需满足确定性策略并记录操作身份。系统按数量、时间或风险触发复核；超时、异常或撤销失败时自动暂停剩余工作。

审批体验

复核人应看到实际结果而非预测摘要，包括差异、已影响对象、恢复状态和下一批范围。他们可以接受、纠正、回滚、缩小范围或停止自动化。

主要失败方式

团队把“可以以后看看”当成事后关卡，却没有审阅时限、自动暂停或可靠恢复。修复方式是将复核结论绑定到下一批放行，而不是放任连续执行。

停止或升级条件

出现不可逆影响、撤销失败、异常率超过上限、权威结果不可读、审阅积压或风险分类上升时，立即停止并切换为执行前审批。

完整虚构审批关卡演练：AG096

组织与演练边界

Meridian Workshop Group 的 Harbor Gate 团队用完全虚构的环境评估七种审批模式。演练不连接客户、支付、生产身份或真实外部系统，所有可能副作用均由记录模拟。

冻结的演练配置。

配置锁定为 A11、GP06、ID08、DO04、AS03、EB05、K04、X01–X07 和 RG03。任何规则、身份、对象模式或工具变化都会形成新版本，不能沿用本次结论。

决策对象与事件范围。

数据集包含 D01–D42 共 42 个决策对象，每种模式恰好 6 个；另含 63 条生命周期事件和 42 次人工复核。分母在运行前冻结，失败对象不会从计算中删除。

结果分布。

42 个对象中 34 个通过、8 个失败。失败覆盖载荷绑定、权限、到期、职责冲突、单次执行、证据和恢复问题，而不是只挑选容易成功的样例。

两项否决失败

D23 允许同一委托身份占据两个需要分离的角色；D36 则用旧批准执行了实质变化后的载荷。两项都违反强制边界，因此即使其他百分比较高，也不能启用。

明确的最终结论。

AG096 的结论为 NOT_ENABLED，外部副作用为 0。它是教学用测试夹具，不是客户结果、产品基准、认证或 OpenMax 性能声明。

下载工作表与证据包

• 下载中文审批关卡工作表
• 下载中文 AG096 演练证据包

复算 AG096 的全部七项指标

载荷绑定完整率：38/42 = 90.48%

分子是执行前审阅对象与执行对象准确一致的 38 项，分母是全部 42 个决策对象。失败包含隐藏字段变化与陈旧对象复用，不能因动作未完成而移出分母。

权限验证通过率：37/42 = 88.10%

37 项在决定时通过当前身份、角色、范围、委托和冲突验证。其余 5 项保留为失败，用来暴露只在队列打开时检查权限的缺陷。

到期约束执行率：9/10 = 90.00%

此指标只针对预先标记为到期或条件边界测试的 10 项，其中 9 项被正确阻断或要求重批。分母不是全部对象，避免制造虚高或虚低比例。

职责冲突阻止率：7/8 = 87.50%

8 个预设冲突场景中 7 个被阻止；D23 漏掉同一委托身份，因此失败。由于这是核心控制否决项，87.50% 不能解释为“基本可用”。

单次执行保障率：11/12 = 91.67%

12 个重复提交、重放或使用次数场景中 11 个保持单次效果。剩余失败表明审批令牌与工具调用的操作身份还没有完全绑定。

决策证据完整率：35/42 = 83.33%

35 个记录含对象版本、审批身份、理由、证据版本、决定时间、执行关联和最终状态。缺少任一关键链路的对象都不计入分子。

事后恢复成功率：5/6 = 83.33%

6 个有界可逆案例中 5 个在规定时间内完成检测、暂停、撤销和权威核对。一个恢复失败足以证明事后模式还不能扩大范围。

把审批关卡实施成受控项目

第一步：列出动作与后果

盘点智能体可能读取、生成、提交、发送、修改或删除的动作，并按外部影响、敏感性、范围、可逆性和错误代价分类。不要从界面按钮开始设计。

第二步：定义权威策略与身份

为每类动作指定允许者、审批者、额度、职责冲突、证据、到期和禁止条件。确认哪个身份目录、策略系统和业务系统拥有最终权威。

第三步：规范化决策对象

把目标、参数、内容、附件、来源状态和预期效果转成稳定结构。规定哪些变化属于实质变化，并通过版本或摘要强制触发新审阅。

第四步：将执行能力置于关卡之后

模型不应绕过关卡直接持有高影响凭证。由执行代理验证决定、对象、权限、时间、次数和租户后，释放一次受限动作。

第五步：在隔离环境演练

先运行正常、拒绝、要求修改、超时、权限变化、载荷变化、重复提交、下游未知和恢复场景。记录所有分母，而不是只展示成功路径。

第六步：小范围启用并监测。

从低数量、低范围和明确负责人开始，持续观察队列负载、机械批准、超时、变更、重放、结果偏差与恢复。触发停止阈值时自动收窄或关闭。

第七步：变更后重新验证。

模型、提示词、工具、对象结构、策略、身份、审批界面、数据源或执行方发生重要变化后，都应重新演练。旧分数不自动适用于新系统。

人工复核与运营治理

指定三类责任人

业务负责人决定哪些结果可以接受；控制负责人维护策略、权限和否决项；技术负责人保证关卡无法被模型、集成或人工捷径绕过。三者的签字不能互相替代。

复核失败对象而不只看平均值

每次审阅都应检查全部失败、否决项、未知状态和分母定义。单个严重越权可能比平均通过率更重要，不能被总分掩盖。

观察审批人的真实行为

监测等待时间、拒绝率、修改请求、连续快速批准、相似决定和队列积压，但不要把速度当成质量。结合抽样复核判断是否发生机械点选或绕过。

保护证据与审计数据。

审批记录可能包含敏感业务和个人信息。使用最小权限、保留期限、访问日志和脱敏，避免为了审计而无限复制载荷或凭证。

规划中断与紧急路径。

身份、策略、消息或下游系统不可用时，应进入预定义安全状态。紧急越权需有狭窄范围、明确到期、独立复核和事后调查，不能成为常规后门。

OpenMax 如何支持审批工作流

适合承担的角色

在经过配置且权限允许的范围内，OpenMax 可帮助组织有界工作流暂停、整理准许证据、路由审批任务并记录决定。实际能力应以当前租户配置和官方资料为准。

仍由外部权威系统决定的事项

身份目录、组织政策、法律授权、业务账本及最终执行系统仍是权威来源。OpenMax 不会因为生成了摘要或工作项，就自动拥有这些系统的批准权。

建议的最小试点。

选择一个低量、可逆、负责人明确的流程，只开放只读证据准备和受控暂停。验证对象绑定、拒绝、过期、权限变化和核对后，再考虑扩大动作范围。

不适合的情况

若团队无法定义权威审批人、无法冻结对象、无法阻断凭证、无法读取最终结果或无法安全恢复，就应先修复基础控制，而不是增加智能体审批界面。

人工审批关卡的限制

人会犯错也会疲劳

审批人可能误解证据、受到时间压力或逐渐形成机械批准。关卡不能代替清晰政策、训练、容量管理、抽样复核和可用的拒绝路径。

审批不会修复不安全的工具调用

即使决定有效，工具仍可能超时、返回未知状态、重复提交或部分完成。操作身份、幂等语义、对账和恢复必须单独设计。

摘要可能遗漏关键事实

模型生成的说明可以辅助阅读，但不能成为唯一证据。审批人应能访问规范化对象和权威来源，并看到摘要与原始字段之间的差异。

复杂关卡会产生新的运营风险。

过多角色、条件和例外会增加等待、误路由、过期和绕过。定期删除无效规则，保留能解释、测试和监测的最小控制集合。

常见审批失败与修复

批准的是摘要而不是动作

失败：摘要看似正确，但隐藏收件人、附件或工具参数不同。修复：展示并绑定规范对象，实质变化后使批准失效。

过早验证审批人

失败：打开队列时权限有效，决定时角色已经变化。修复：在决定时检查当前身份、角色、范围和冲突，并按执行策略再次验证。

跨重试或新意图复用批准

失败：一个决定被用于重复效果或变化后的操作。修复：执行前定义使用次数、操作身份、到期和对账规则。

同一有效身份占据多个角色

失败：委托、共享账号或服务会话绕过独立性。修复：跨身份和会话建模实际控制关系，强制执行冲突政策。

把无人回应当成同意

失败：等待超时后工作流自行继续。修复：到期后进入安全阻断、替补或事件状态，不能因为队列缓慢就扩大权限。

实施检查清单与下一步

启用关卡之前

确认决策对象模式、规范化、审批角色、冲突、决定选项、到期、撤销、执行代理、权威结果和失败路径。在强制机制验证前，保持受控工具不可用。

扩大自主范围之前

运行全部 AG096 类案例，检查两项否决失败，并测试实质变化、错误角色、陈旧批准、重放和事后恢复。由具名负责人接受剩余风险。

运行期间

持续监测队列负载、决定耗时、拒绝、变更、权限失败、过期、载荷不匹配、重放、下游偏差、撤销和伤害。发生实质变化后重新演练。

常见问题

每个 AI 动作都需要人工审批吗？

不需要。应按后果、可逆性、范围和已验证控制分类。高影响动作采用执行前关卡；有界低风险工作可采用确定性、抽样或事后控制。

一次批准可以覆盖一批动作吗？

只有当成员、上限、允许操作、来源状态和变更规则都可见且绑定时才可以。新增成员或实质变化必须形成新决定。

哪些变化会使批准失效？

载荷、目标、收件人、金额、附件、来源事实、权限、政策、风险、身份、使用次数或有效条件变化，都可能按关卡合同使批准失效。

事后复核算真正的关卡吗？

它是监督与恢复模式，不是执行前提。只应在有上限、可观测、可逆的低风险工作中使用，并必须具备自动暂停。

审批能让不安全的重试变安全吗？

不能。审批只确立对某个决策对象的人工权限；重试安全仍取决于操作身份、服务方语义、幂等、提交状态和对账。

演练分数高就能授权上线吗？

不能。否决失败、具名复核、真实系统证据、安全审查和负责人的批准都需单独满足。AG096 的状态仍是 NOT_ENABLED。

OpenMax 在哪里发挥作用？

在配置允许时，OpenMax 可支持有界暂停、许可范围内的证据准备、审批路由和决定记录；身份、政策和业务执行仍由外部权威系统控制。

来源与编辑方法

OpenMax 产品背景

• OpenMax：AI 工作流自动化合规解决方案——受控工作流、复核和合规场景背景。
• OpenMax：AI 智能体平台——角色、工具、权限、日志、复核和运营背景。

治理、访问与安全来源

• NIST：生成式 AI 风险管理框架简介——治理、人工监督、隐私、安全与内容完整性风险背景。
• NIST SP 800-53 Rev. 5：AC-5 职责分离——职责划分控制背景。
• NIST SP 800-53 Rev. 5：AC-6 最小权限——限制授权访问的控制背景。
• OWASP：LLM06:2025 过度代理能力——最小功能、最小权限、用户上下文执行和高影响人工审批。
• OWASP：LLM01:2025 提示词注入——不可信外部内容与间接注入边界。

编辑方法

OpenMax 编辑人员于 2026 年 9 月 5 日核查上述官方或第一方来源，并将有来源支持的控制及产品背景与原创运营分析明确分开。AG096 完全虚构；其对象、事件、复核及百分比不是基准、认证、客户结果或 OpenMax 性能测量。发布前仍需合格人员与实际租户复核。