不是所有 Agent 都需要人类审批，但所有会产生真实后果的 Agent，都应该先回答一个问题：
$$ 这一步如果错了，代价谁来承担？ $$
一旦答案涉及金钱、权限、合规、数据写入或客户承诺，Human-in-the-Loop 往往就不再是“体验优化”，而是系统底线。
建议先看 AI Agent 安全与权限控制、Function Calling 工程实战、AI Agent 状态机设计指南 和 多 Agent 协作架构。
一、什么时候必须引入人工审批
下面四类场景，优先默认“先审后执”：
| 场景 | 风险 | 建议做法 |
|---|---|---|
| 写操作 | 重复下单、重复退款、误删数据 | 必须审批或幂等双保险 |
| 高敏感权限 | 越权访问、批量导出 | 先做人工确认 |
| 高金额决策 | 预算超限、成本失控 | 设金额阈值 |
| 对外承诺 | 错误报价、错误 SLA | 审批后才能发送 |
如果你的 Agent 只做检索和总结，审批可以轻一些；如果它会改变真实世界状态，审批就应该成为设计第一项。
二、典型失败案例：自动退款触发了重复副作用
某个售后 Agent 根据工单文本判断“可以直接退款”，然后自动调用退款工具。
一次接口超时后，系统误判第一次调用失败，第二次又重试了一次。最终用户收到了两笔退款。
问题不只在幂等，而在于系统默认了“模型判断通过 = 可以执行”。
更稳的做法应该是：
- 模型只输出退款 proposal
- policy 层判断金额与历史记录是否超阈值
- 满足风险条件时进入审批队列
- 审批通过后再生成真正的执行请求
Human-in-the-Loop 的价值就在这里：把“模型建议”和“业务执行”隔开。
三、审批流不要做成聊天确认
很多团队会简单做一个“是否确认执行？”，然后让操作员点按钮。
这种方式的问题是：
- 审批人看不到证据
- 审批没有结构化字段
- 审批通过后无法回放为什么放行
更好的审批单至少要有：
| 字段 | 含义 |
|---|---|
proposal_summary | Agent 建议做什么 |
evidence | 证据来源和摘要 |
risk_flags | 风险标签 |
estimated_impact | 金额、用户范围、影响面 |
fallback_plan | 如果失败怎么回滚 |
这样审批不是“相信模型”，而是“基于证据做决策”。
四、触发审批的规则怎么定
最常见的 4 类触发条件：
- 金额阈值：超过金额必须人工审批
- 权限阈值：涉及管理员、财务、隐私字段必须审批
- 不确定性阈值：模型置信度低、证据不足必须审批
- 异常阈值：超预算、重试次数过多、工具返回冲突必须审批
不要把所有任务都拉进审批，否则系统会退化成手工工单系统。
五、审批流也需要指标
至少看下面 5 个：
approval_rateapproval_latency_msmanual_override_ratepost_approval_failure_ratefalse_positive_approval_rate
这些指标能帮助你判断：审批到底是在降低风险，还是只是在制造流程摩擦。
六、Human-in-the-Loop 上线清单
- 所有高风险写操作都先输出 proposal
- 审批单包含证据、风险、影响面和回滚方案
- 审批通过前不能直接进入执行态
- 审批记录支持回放与审计
- 审批阈值按金额、权限、不确定性分层设置
