一个带人工批准的 AI 工作流应在高影响动作前停下，展示精确目标、范围、变更、权限和后果，并通过可信通道接收决定。系统必须把批准绑定到审阅者、提案版本、允许动作和有效期。任何实质变化都会使批准失效，并需要重新决策。

Microsoft 的 Work Trend Index 把有效 Agent 使用与人类判断和主动权联系起来。［1］真正的审批门禁会把原则变成技术边界：它不是让人给黑箱结果盖章，而是提供足够的已核验信息，让人接受或拒绝一个具体动作。

关键要点

先按后果分级动作，再确定审批点。

分离提案生成与高权限执行。

展示完整、可读、可核验的审批包。

把批准绑定到身份、版本、范围和过期时间。

输入、权限或效果变化时必须重新批准。

测试伪造对话框、过期批准与间接提示注入。

先用重复任务自动化流程选择并原型化有边界的任务。本文从提案可能造成外部副作用的位置开始。

哪些动作需要带人工批准的 AI 工作流？

按动作可能造成的后果分类，而不是按系统调用它有多容易。要考虑保密性、金钱、法律权利、安全、对外沟通、数据完整性、账户访问、可逆性、受影响人数和恢复时间。

一个简单的分级模型如下：

等级	典型后果	默认控制
读取	查看获准数据，不改变任何内容	记录日志、最小权限访问
起草	生成内容，不向外发送	使用前人工审阅
可逆写入	修改有可靠回退的有界记录	批准或范围狭窄的预授权
外部或高权限动作	发送、发布、付款、授权、删除或部署	对精确动作的显式批准
不可逆或高影响	安全、权利、重大财务、大范围删除	独立控制或排除在外

同一个工具调用可能属于不同等级。起草邮件不等于发送邮件；生成访问规则提案不等于安装规则；展示 diff 不等于部署。把风险等级写进工作流定义，让模型无法通过改写动作描述来降低其等级。

OWASP 的 Excessive Agency 指南建议限制功能、权限和自主程度，并对高影响动作要求用户批准。［2］审批只是其中一层，不能替代最小权限、校验、限流或回退。

步骤 1：分离提案和执行

在无法执行高影响动作的环境中生成提案。提案阶段可以读取获准输入、生成结构化候选、校验候选并制作预览，但不应持有执行凭据。

执行服务只应接受已校验的提案 ID 加上可信的批准凭证。它必须重新读取规范（canonical）提案，再次检查政策和权限，并只执行其中编码的操作。批准之后，不要让模型另行发送任意工具参数。

这种分离带来清晰的责任划分：

模型提出提案；
确定性代码负责校验和打包；
经过身份认证的人作出决定；
可信执行器中介每一个副作用；
审计存储记录决定和结果。

如果执行器由生成的代码实现，请按AI 代码审阅清单检查。权限执行、序列化、重试和故障恢复，都需要与其他安全敏感代码同等的审阅。

步骤 2：为 AI 审批工作流制作完整审批包

审批界面应直接回答“到底会发生什么”，而不要求审阅者从聊天记录里重建提案。应包含：

目的：为何请求这个动作，由谁负责；
目标：精确的账户、记录、收件人、环境或资源；
范围：包含和排除的项目、数量、时间范围和目的地；
变更：可读的 diff 或前后对照；
证据：支撑提案的已校验输入和政策检查；
权限：执行器将使用哪项能力和哪个凭据；
效果：对外消息、写入、费用、访问变更或下游任务；
风险与可逆性：可能的失败方式和回退限制；
版本和有效期：不可变的提案身份和决定期限；
替代选项：拒绝、编辑后重新生成、缩小范围或升级处理。

可以逐层展开细节，但绝不能把重大后果藏在折叠的摘要里。突出显示不确定和缺失的信息。如果提案涉及大量记录，要同时展示汇总和可供审阅的样本；当集合超出已批准边界时，要求更严格的审阅。

不要只展示模型生成的文字。关键字段应从规范的结构化数据和确定性政策检查中生成。审阅者应能分辨哪些陈述已经核验，哪些只是模型的解释。

步骤 3：把批准绑定到身份、版本、范围和有效期

批准凭证应标明已认证的审阅者、角色或权限、提案 ID、内容版本、允许的动作、精确范围、目的地、有效期、决定和决定时间。使用适合你系统的身份与完整性控制来保护它。

执行时，把批准凭证与规范提案对照。出现以下情况时拒绝执行：

提案哈希或版本已变化；
动作类型、目标、目的地或记录集合已变化；
请求的权限更宽；
批准已过期或被撤销；
审阅者已不再拥有相应权限；
政策或相关状态已变化；
要求一次性使用的凭证已被使用过。

批准“发送每周摘要”，并不等于批准发送之后修改的草稿、增加收件人、添加附件或更换账户。以往的一般偏好可以指导低风险起草，但不应被解读为对高影响动作的永久授权。

批准有效期应短到与底层状态的变化速度相匹配。如果库存、账户访问、收件人、价格或部署目标可能很快变化，就要在执行前立即重新校验；实际效果有实质差异时，要求重新批准。

步骤 4：定义拒绝、超时、编辑与重试行为

拒绝是正常结果，不是需要绕过的错误。在有用时记录理由，停止该提案，并防止同一动作被自动重新提交。修订后的提案需要新的身份和新的批准。

超时应 fail closed（默认拒绝）。不要把沉默当作同意。按政策通知负责人，或把请求标为已过期。如果确需紧急处理，应走另行治理的升级路径，而不是降低门禁。

在审批界面内直接编辑可能很危险，因为展示的变更和实际执行的变更可能不一致。优先采用“拒绝并重新生成”，或根据编辑结果创建新的规范提案，再展示新版本供批准。

重试必须保留动作身份。遇到超时或网络响应不明确时，先查询目标系统，确认动作是否已经发生。盲目重放付款、消息、权限变更或部署，可能导致效果重复。下游系统支持时使用幂等机制，不支持时设计明确的恢复流程。

步骤 5：批准后仍要中介每个动作

OWASP 要求对 Agent 工具调用进行完整中介，而不是信任模型的计划。［2］执行器应独立检查所请求的操作、参数、目标、授权、批准绑定、限流和当前政策。

使用范围狭窄的操作允许清单。不能因为审批包显示了一段安全摘要，执行器就接受 shell 命令或自由形式的 API 调用。把已批准的提案转换成字段有界的类型化内部命令。

执行最小权限：

分离读取、提案和执行身份；
只授予目标资源和目标操作的访问权；
避免把长期凭据放进模型上下文；
限制动作量和受影响记录数；
批准后禁止更改目的地；
既记录执行，也记录拒绝；
让紧急停止开关留在模型控制之外。

当审批包含敏感来源数据时，请参考AI 隐私风险。展示足以作出决定的证据，但不要把无关的个人或机密信息复制到界面或日志中。

步骤 6：保护人机协同 AI 控制免受操纵

OWASP 的 AI Agent 安全指南把提示注入、工具滥用、记忆污染、过度自主和人类监督不足视为相互关联的风险。［3］外部内容绝不能创建、伪装或提交一个可信的批准。

Lies-in-the-Loop 攻击描述了伪造或误导性的人机交互，用来诱骗用户批准某个动作。［4］凡是由不可信网页内容、邮件、文档或模型输出渲染出的对话框，都应视为不可信。真正的审批界面应有明确的来源、已认证的会话、稳定的提案身份和已核验的动作详情。

防御措施包括：

把不可信内容渲染在清晰分隔的数据区域；
绝不执行其中包含的链接、表单或指令；
把批准和拒绝控件放在可信的应用界面框架中；
在最终决定点再次显示目标和 diff；
较高风险等级要求重新认证；
防止模型把自己的提案标记为已批准；
对异常敏感的动作发送独立通知；
在网页界面中检测框架嵌套、覆盖层或来源混淆。

不要依赖“此动作是安全的”这类措辞。决定必须建立在独立得出的字段和政策结果之上。

步骤 7：测试批准、审计执行并准备回退

先测试正常流程，再尝试破坏批准绑定。测试应包括：

批准后修改提案；
更改收件人、环境或目的地；
扩大记录集合或权限；
使用过期、已撤销、重复或已用过的批准；
由已认证但无相应权限的角色批准；
声称已批准的伪造界面或内容；
检索材料中的间接提示注入；
下游超时且执行结果未知；
部分执行且回退失败；
审计存储或通知故障。

安全的结果是可见的停止，而不是猜测的成功。确认动作没有发生、尝试已被记录且未泄露密钥，并且获授权的操作人员能理解原因。

NIST 的生成式 AI 配置文件强调在 AI 全生命周期中进行治理、记录、测量和管理。［5］把测试证据与工作流版本一起保存；模型、提示词、schema、政策、身份系统、工具或用户界面变化后，重新运行测试。

审计执行并让回退真正可用

记录提案 ID、工作流版本、审阅者身份、决定、批准范围、时间戳、校验结果、执行器身份、下游请求身份、结果和回退状态。尽量减少日志中的敏感内容，并防止日志被未经授权地修改。

审计记录必须区分：

已提出但从未获批；
已拒绝或已过期；
已批准但未执行；
执行成功；
执行结果未知；
部分执行；
已回退或已修正。

用接近真实的权限和依赖测试回退。如果下游消息无法撤回，或外部用户已经据此采取行动，一个标着“撤销”的按钮并不构成恢复计划。对于不可逆效果，要加强执行前审阅，或把该动作移出工作流。

为停机和有争议的批准保留人工操作流程。SOP 冷运行审阅可以在事故发生前暴露负责人、凭据或恢复步骤方面的缺口。

怎样衡量人机协同 AI 审批门？

不要只看批准率。按风险等级追踪提案、审阅时间、拒绝与重新生成的原因、试图改变范围的次数、过期批准、执行器拒绝、关键错误、回退成功率和审阅者分歧。很高的批准率可能说明提案质量出色，也可能说明审阅者疲劳或审批包信息不足。

抽样检查已批准的动作，把展示的审批包与规范提案和实际副作用对比。访谈审阅者：他们实际用了哪些字段、哪些内容无法核实、何时感到被催促。在提升清晰度的同时，不要删去重要细节。

通用 AI 使用指南为有边界的任务和核验提供了更广的框架；审批门只是这个更大系统中的一项专门控制。

常见问题

点击“批准”就足以构成人类监督吗？

不够。审阅者需要一份可信、完整的审批包，以及真正拒绝的权力。系统必须把决定绑定到一个精确提案，并独立中介执行。

哪些动作一定需要批准？

答案取决于你的风险政策，但对外沟通、资金转移、访问权限变更、删除、发布、部署和高影响决定，通常都需要显式控制。其中一些应完全排除在 AI 执行之外。

一次批准可以覆盖一个批次吗？

只有当批次成员、范围、目的地、上限和效果都可见且固定时才可以。任何新增项目或改变的目标，都应使批准失效，或进入另行授权的规则。

批准后提案变化了怎么办？

拒绝已过时的批准，并创建新的提案版本。不要原地修补已获批的内容，也不要假设审阅者会接受类似的变更。

批准应该有效多久？

按相关状态和风险变化的速度设定有效期。执行前立即重新校验；效果有实质差异时，要求重新作出决定。

AI 可以解释为什么某个动作是安全的吗？

它可以提供清楚标注的解释，但关键字段和政策结果应来自规范数据和确定性检查。模型的自信不是批准证据。

怎样防止伪造的审批对话框？

使用可信的应用来源、已认证会话、稳定的提案身份、分隔开的不可信内容、已核验的目标详情和受保护的控件。测试覆盖层、嵌入内容和间接提示注入。

执行超时时应该怎样处理？

在检查目标系统之前，把结果视为未知。不要自动重放高影响动作。使用幂等机制或明确的对账流程。

延伸阅读

免责声明：本文提供一般安全与工作流信息。审批要求取决于系统、风险、法律与政策。高影响部署应由合格的安全、隐私、法律和运营人员审阅。

来源：

Microsoft WorkLab — Work Trend Index: Agents, human agency, and the opportunity for every organization — https://www.microsoft.com/en-us/worklab/work-trend-index/agents-human-agency-and-the-opportunity-for-every-organization
OWASP GenAI Security Project — LLM06:2025 Excessive Agency — https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
OWASP Cheat Sheet Series — AI Agent Security Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html
OWASP — Lies-in-the-Loop — https://owasp.org/www-community/attacks/Lies_in_the_Loop
NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 8 月 24 日。

如何构建带人工批准的 AI 工作流：提案与执行分离，批准绑定精确版本