Wiki Notes

Appearance

安全审批策略案例专题 ​

版本：v1.3

最后更新：2026-07-09

适用对象：正在设计 AI 审批链、做人机协同工作流、管高风险工具与外部动作，以及需要把“什么动作该审、谁来审、审完如何恢复执行”落到真实案例和可执行策略上的产品、平台、安全与业务流程同学

很多团队知道：

  • 高风险动作要审批

但真正落到系统里时，常常会卡在：

  • 什么算高风险
  • 谁来审批
  • 审批触发条件怎么定义
  • 审批通过后如何继续执行
  • 审批拒绝后怎么收口

这篇专题的重点不是重复审批概念，而是把审批策略放进真实案例里看。

1. 为什么审批策略必须案例化 ​

审批不是一句抽象原则，而是必须落到具体动作和具体风险上。

同样叫工具调用，不同动作的风险完全不同：

  • 查询数据
  • 导出数据
  • 向外发送消息
  • 删除记录
  • 修改权限

如果没有案例化规则，系统很容易出现两种极端：

  • 审批过度，效率极低
  • 审批不足，风险过高

所以审批策略真正需要回答的是：

  • 哪类动作在什么条件下必须有人承担最终责任

2. OpenAI 当前官方资料对审批策略的核心启发 ​

根据 OpenAI 当前在 2026-07-08 可访问的：

  • Guardrails and human review
  • Safety in building agents
  • Safety best practices

这些资料共同强调了一点：

  • 自动 guardrails 负责校验和拦截
  • human review 负责高后果动作的批准决策

这说明审批不应该被理解成：

  • 给所有动作加一个“确认按钮”

而应该被理解成：

  • 把高风险动作分级、证据化、可恢复地接进工作流

2.1 更稳的审批，不是“弹个确认框”，而是一次可追责的暂停 ​

OpenAI 当前 Guardrails and human review 明确强调：

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

这背后的关键不是界面上有没有一个“通过”按钮，而是：

  • 系统能不能在高风险节点真正暂停
  • 暂停时能不能保留完整上下文
  • 恢复时能不能从明确节点继续
  • 拒绝时能不能走可解释的降级分支

也就是说，审批更像：

  • 一次带状态、带证据、带责任归属的 workflow interruption

3. 什么动作通常应该进入审批 ​

更常见的高风险动作包括：

  • 对外发送
  • 修改权限
  • 删除和撤销
  • 财务或法律流程动作
  • 高敏感数据导出
  • 生产配置改动
  • 外部系统写操作

这些动作的共同点通常是：

  • 影响真实世界
  • 影响用户权益
  • 影响合规责任
  • 不可逆或回滚代价大

4. 审批策略不只是“批不批”，还包括什么 ​

一套更完整的审批策略，通常至少包含：

  • 动作分类
  • 风险分级
  • 触发条件
  • 审批证据展示
  • 审批后恢复执行方式
  • 审批拒绝后的降级动作
  • 审计记录

如果系统只设计了：

  • 通过 / 拒绝

后面最容易缺的往往是：

  • 为什么批
  • 批完怎么执行
  • 拒绝后怎么收口

4.1 审批策略最好把“建议、审批、执行”拆成三层 ​

很多系统最容易踩坑的一点是把这三件事混在一起：

  1. 模型提出建议
  2. 人类批准动作
  3. 工具真正执行

更稳的设计通常会把它们拆成不同状态：

  • proposed
  • approved
  • executed

这样做的价值非常直接：

  • 模型可以继续负责提出候选动作
  • 人类只对最终责任动作负责
  • 系统可以在批准后再做最后一次执行前校验

如果三者混成一步，后面最常见的问题就是：

  • 审批人其实没看清要执行什么
  • 批准结果和真正执行参数不完全一致

4.2 审批策略真正管的不是“人”，而是“责任边界” ​

审批设计最容易被误解成：

  • 只是多加一个人工环节

但更贴近生产的理解通常是：

  • 把不可完全自动化承担责任的动作，明确交给某个角色签收

所以设计审批策略时，更值得先问的是：

  • 这次动作的责任属于谁
  • 谁对租户、客户、资金或配置结果承担责任
  • 谁拥有看证据、看范围、看影响面的合法权限

5. 案例一：客服退款审批 ​

场景 ​

  • Agent 识别到用户申请退款

为什么需要审批 ​

因为这类动作往往同时涉及：

  • 资金
  • 客户权益
  • 策略一致性

更稳的策略通常是 ​

  • 小额、低风险可自动建议
  • 超过金额阈值、命中风险标签或证据不足时必须审批

更像生产系统的补充控制 ​

  • 审批前冻结退款对象、金额和依据快照
  • 审批后执行前再次校验订单状态是否变化
  • 对超过时限的审批自动失效，不允许拿旧批准继续执行
  • 对高争议退款保留“建议退款但转人工复核”的降级路径

审批前应展示的证据 ​

  • 用户身份
  • 订单信息
  • 退款原因
  • 风险标签
  • 历史操作记录

审批后恢复执行方式 ​

  • 明确恢复到“执行退款”节点
  • 保留审批记录和执行前快照

6. 案例二：外部消息发送审批 ​

场景 ​

  • Agent 准备向客户发送邮件、短信或 IM 消息

风险点 ​

  • 发错对象
  • 内容不当
  • 泄露内部信息
  • 在不合适的时点对外触达

更常见的审批策略 ​

  • 内部草稿自动生成
  • 外发前必须审批

审批时应重点看 ​

  • 收件人 / 接收方
  • 消息内容
  • 是否包含敏感信息
  • 当前会话上下文是否可信

这类场景最重要的并不是模型能不能写出一段“像样的话”，而是：

  • 最终责任是否有人承担

更像生产系统的补充控制 ​

  • 草稿和最终发送内容必须有稳定版本号
  • 收件人、抄送人、附件和外链要进入证据包
  • 审批后如果正文、对象或附件变化，必须重新审批
  • 高风险外发最好增加域名 / 租户 / 客户 allowlist 校验

7. 案例三：高敏感数据导出审批 ​

场景 ​

  • 用户或 Agent 请求导出报表、客户数据或内部文档集

关键问题 ​

  • 数据敏感级别多高
  • 请求人是否有该权限
  • 导出范围是否过大
  • 是否跨租户或跨部门

更合理的策略通常包括 ​

  • 判断数据敏感级别
  • 判断用户角色和租户边界
  • 判断导出范围
  • 记录审批与导出审计

这类场景通常不适合：

  • 只要登录就能直接导出

更像生产系统的补充控制 ​

  • 审批界面展示导出记录数、字段清单和敏感级别
  • 对超大范围导出增加抽样预览，而不是只看一句“导出客户数据”
  • 导出文件生成后设置时效链接、下载审计和二次分享限制
  • 导出前后都校验 tenant / department scope，避免审批和执行看到的范围不一致

8. 案例四：高风险工具执行审批 ​

场景 ​

  • Agent 通过工具执行外部写操作，例如修改工单、发工单、改权限、删除记录

工程上的核心原则 ​

  • 模型可以提出执行建议
  • 系统在真正执行前仍需要一层控制门

更稳妥的链路通常是 ​

text
Model proposes action
 -> Guardrails validate action
 -> Approval review checks evidence
 -> Tool executes only after approval
 -> Audit records outcome

这类场景里，审批和工具权限必须一起设计，不能拆开看。

8.1 真正危险的通常不是“是否调用工具”，而是“是否拿着批准去做了另一件事” ​

OpenAI 当前 Safety in building agents 和 Computer use 放在一起看，一个特别实用的启发是：

  • 高风险动作要在外部后果发生前暂停

所以更稳的设计通常还会补：

  • 工具参数预览
  • 目标对象校验
  • 执行前 precondition recheck
  • 批准结果和实际执行参数绑定

否则很容易出现：

  • 审批人批准的是 A
  • 系统最后执行的是 A'

9. 案例五：生产配置或模型路由改动审批 ​

场景 ​

  • 调整模型路由、Prompt、guardrails 阈值、审批策略、检索配置

为什么值得审批 ​

因为这类动作虽不直接触达用户数据，但会改变：

  • 整体行为边界
  • 风险分层逻辑
  • 成本结构
  • 可回滚路径

更稳妥的做法 ​

  • 变更单审批
  • 评测结果附证据
  • 灰度计划附说明
  • 回滚条件提前写清楚

这类审批更偏“发布治理审批”，但同样属于安全审批体系的一部分。

9.1 这类审批最好把“发布证据包”做成固定模板 ​

更稳的模板通常包括：

  • 变更对象
    • 模型 / prompt / route / guardrail / approval policy
  • 评测证据
  • 风险说明
  • 影子 / 灰度计划
  • rollback owner
  • rollback trigger

这样发布审批才不至于沦为：

  • 靠口头解释说“应该没事”

10. 审批策略应该按哪些维度建模 ​

更实用的设计维度通常包括：

  • 动作类型
  • 风险等级
  • 用户角色
  • 数据敏感级别
  • 金额或影响范围
  • 是否可逆
  • 是否对外
  • 是否命中异常信号

也就是说，审批通常不是一个简单布尔值，而是一组条件判断。

10.1 更稳的做法通常会把这些维度组合成 approval profile ​

例如：

  • refund.low_amount
  • export.high_sensitive
  • message.external.customer
  • tool.write.production
  • config.route_change.high_impact

这样做的好处是：

  • 审批策略不再散落在一堆 if/else 里
  • 每类 profile 都能绑定自己的证据模板、审批人、SLA 和回滚动作

10.2 审批人选择本身也应该被建模 ​

更实际的设计维度通常还包括：

  • 租户边界
  • 部门边界
  • 金额或影响级别阈值
  • 值班 / on-call 状态
  • 是否需要“双人批准”

因为很多事故并不是没有审批，而是：

  • 批准人本身不对
  • 批准人没有该租户或该数据范围的责任权限

10.3 审批结果最好带有效期和适用范围 ​

审批最容易被忽略的一件事是：

  • 一次批准到底对什么生效，生效多久

更稳的结果对象通常至少带：

  • approved_scope
  • approved_action
  • approved_args_hash
  • expires_at
  • approved_by

否则系统很容易把一份旧批准：

  • 用到新的对象上
  • 用到更大的范围上
  • 用到已经变化的上下文上

11. 审批证据应该怎么展示才够用 ​

审批人最怕的不是审批动作本身，而是：

  • 信息不够，无法判断

建议审批界面至少展示：

  • 谁发起
  • 触发什么动作
  • 作用对象是谁
  • 为什么要做
  • 系统判断的风险等级
  • 相关上下文证据
  • 可选的降级动作

如果审批人只能看到一个“通过 / 拒绝”按钮，系统通常很难长期运转好。

11.1 一份更像生产系统的审批证据包，通常至少包含这些字段 ​

  • request_id / trace_id
  • 发起人、租户、角色
  • 动作类型
  • 目标对象
  • 风险等级
  • 系统建议动作
  • 证据摘要
  • 关键原文 / 原始引用
  • 工具参数预览
  • 可逆性说明
  • 推荐降级动作

如果是发布治理审批，还建议再补：

  • 评测结果摘要
  • 影子 / 灰度差异
  • 回滚方案

11.2 证据越复杂，越应该先摘要再展开 ​

审批界面常见另一个问题是：

  • 信息太少无法判断
  • 或信息太多根本没人看

更稳的展示方式通常是：

  • 默认展示摘要卡
  • 支持展开看证据原文、历史操作、trace 和工具参数

这样审批既不会沦为空点按钮，也不会变成阅读灾难。

12. 审批通过后流程如何恢复，往往和审批本身一样重要 ​

很多系统忽略了这件事：

  • 审批通过以后，工作流如何继续

更稳妥的系统通常会：

  • 保留状态机
  • 保留审批记录
  • 保留执行前快照
  • 从明确节点恢复

这样后续才能：

  • 继续执行
  • 追责
  • 审计
  • 事故时快速排查

12.1 恢复执行前最好做一次 recheck ​

审批通过不代表现在立刻就能安全执行。

恢复前更稳的系统通常还会重新检查：

  • 目标对象状态是否变化
  • 权限是否变化
  • tenant scope 是否变化
  • 风险标签是否变化
  • 工具参数哈希是否和审批时一致

这样可以避免一种很危险的情况：

  • 审批时合法
  • 恢复执行时上下文已经变了

12.2 最好把审批恢复做成显式 resume token ​

如果系统支持长工作流或异步工作流，一个更实用的做法通常是：

  • 审批通过后返回稳定的 resume token
  • token 绑定状态快照、动作范围、审批人和有效期

这会让后续流程更容易做到：

  • 精确恢复
  • 审计追踪
  • 过期失效
  • 重放排查

13. 审批被拒绝后怎么收口 ​

同样重要的问题是：

  • 审批拒绝以后系统做什么

更合理的做法通常包括：

  • 生成只读建议而不执行
  • 转人工继续处理
  • 反馈受控说明给用户
  • 记录拒绝原因进审计链

如果拒绝后流程悬空，系统很快就会变成新的运营问题来源。

13.1 拒绝原因最好结构化，而不是只写自由文本 ​

更稳的拒绝分类通常包括：

  • 证据不足
  • 风险过高
  • 角色权限不足
  • 目标范围异常
  • 需升级审批
  • 建议改走人工流程

结构化拒绝原因的价值在于：

  • 更容易做失败分桶
  • 更容易做策略复盘
  • 更容易指导下一步降级或人工接续

13.2 有些拒绝不该直接结束，而该“升级” ​

真实系统里常见的并不是简单的：

  • 通过
  • 拒绝

而是：

  • 升级到更高层审批
  • 转专业人工角色继续处理
  • 先补证据后重新发起

如果系统没有这条中间路径，就会把很多本该继续的流程：

  • 粗暴打回
  • 或粗暴放行

14. 审批策略如何和权限模型、租户隔离保持一致 ​

很多审批策略失败，不是审批本身设计错了，而是和权限模型脱节。

例如：

  • 能审批的人没有对应租户权限
  • 能发起动作的人本来就不应看到那份数据
  • 审批人看到的证据比执行系统看到的证据还少

所以审批策略必须和下面这些一起设计：

  • 角色权限模型
  • 多租户隔离
  • 工具白名单
  • 数据敏感级别

14.1 审批看到的证据范围，不能大于它合法能看的范围 ​

很多系统在“为了方便审批”时，会无意中让审批人成为新的越权面。

更稳的原则通常是：

  • 审批人只看完成判断所必需的最小证据
  • 证据视图受租户和角色限制
  • 原始敏感数据必要时脱敏或摘要化

也就是说，审批机制本身不能为了治理别的风险，又引入新的数据暴露风险。

14.2 同一个动作的发起权、审批权和执行权最好分离 ​

尤其在高风险场景下，更稳的做法通常是：

  • 发起人不等于审批人
  • 审批人不等于执行系统 owner

这样更容易避免：

  • 自批自过
  • 单点误判
  • 缺少复核制衡

在高后果流程里，还可以进一步考虑：

  • 双人批准
  • 不同职能批准
  • 值班与业务双签

15. 最常见的反模式 ​

  • 只知道“要审批”，不知道触发条件
  • 所有动作都审批，导致系统效率极低
  • 审批记录不进 trace / audit
  • 审批界面证据不足
  • 通过后没有明确恢复节点
  • 拒绝后没有降级路径
  • 审批策略和权限模型割裂
  • 批准结果没有有效期和适用范围
  • 审批通过后不做执行前 recheck
  • 审批看的是一个参数版本，执行走的是另一个参数版本
  • 审批人没有该租户 / 该数据范围的真实责任权限
  • 把升级审批和直接拒绝混成一类结果

16. 建议的建设顺序 ​

第一阶段：先梳理动作分类和风险等级 ​

先搞清楚什么动作值得审批。

第二阶段：为最关键案例建立证据模板 ​

优先覆盖：

  • 对外发送
  • 敏感数据导出
  • 写操作工具
  • 财务 / 权限 / 删除

第三阶段：把审批纳入状态机和审计链 ​

让审批不再只是按钮，而是系统流程的一部分。

第四阶段：把审批策略接进回归和发布门禁 ​

确保策略变化本身也被验证。

17. 推荐搭配阅读 ​

18. 重点官方资源 ​

以下资源已按 2026-07-09 复核可访问：