Human-in-the-loop

一句话理解：Human-in-the-loop 不是“多加几个确认弹窗”，而是设计好人在什么时候、以什么方式、基于什么信息介入——事前批准计划、事中确认动作、随时中断接管、事后抽查复盘。

上一课我们给动作定了级，得出结论：有些动作需要人参与。但“需要人参与”只是开始。真正的难题是：

• 让人确认 50 次，第 51 次他还会认真看吗？
• 用户派出任务后去开会了，Agent 在第 3 步需要批准，是停下来干等，还是跳过？
• 审批人只看到“是否允许执行 refund？”，他凭什么做判断？

设计不好的 Human-in-the-loop，既没有提高安全性，又毁掉了自动化的价值。这一课讲清楚几种介入模式，以及让人的判断真正有效的条件。

人介入的五种模式

模式	什么时候介入	适合	例子
计划审批	开始执行前	多步骤任务、方向错了代价大	Coding Agent 先出改造方案，确认后再动代码
动作确认	某个具体动作执行前	对外发送、写入、资金类动作	发给客户的邮件发送前确认
中断	执行过程中任意时刻	用户发现方向不对	看到 Agent 开始批量改价，立刻叫停
接管	Agent 无法或不应该继续时	登录、支付、验证码、需要专业判断	浏览器 Agent 到支付页，交给用户输入
事后复核	执行完成后	低风险但量大的动作	每天抽查 5% 自动关闭的售后工单

按介入时间把五种模式排到一条任务时间线上：

这五种模式不是互斥的。以「订单售后 Agent」处理一个“疑似重复扣款”的工单为例：

让确认真正有效：审批卡片要包含什么

“是否允许执行 refund(order_id=88231, amount=380)？”这样的确认几乎没有意义：审批人既看不懂，也没法判断。一个有效的审批请求至少回答五个问题：

问题	内容	例子
做什么	用业务语言描述动作和关键参数	向客户张某退款 380 元，原路退回
为什么	Agent 的判断与依据	同一订单 9 月 3 日被扣款两次，支付流水号不同
证据	可点开核对的原始数据	两条支付记录、订单详情的链接
影响	执行后会发生什么，影响范围	退款到账 1–3 个工作日，本月该客户首次退款
能否撤回	做错了怎么办	退款发起后无法撤回，只能另行追款

并且提供不止“同意 / 拒绝”两个选项：

• 修改后执行：金额改成 190 元再退；
• 拒绝并说明原因：原因回到 Agent 的上下文，让它调整方案；
• 转交他人：超出权限，转给财务；
• 批量处理：同一类型、同一依据的 20 笔小额退款一次性审批。

界面层面的细节（批量审批、修改后执行、中途接管的交互）在 审批与接管 一课中展开。

审批疲劳：最常见的失败方式

确认次数过多时，人会进入“自动点击同意”的状态，确认就变成了形式。Coding Agent 领域对此有很深的体会：Claude Code 的沙箱文档开篇就说明，沙箱的目的是让大多数命令不再需要逐条确认，而是由用户预先划定可访问的文件和网络范围、由操作系统强制执行。

减少无效确认的几种方法：

1. 把确认换成边界：与其每条命令都问，不如划定“在这个范围内随便做”。
2. 按风险分级确认：只在高风险动作上打断，低风险动作事后可见。
3. 合并确认：把一个计划中的多个相关动作放在一次审批里。
4. 学习用户的选择：用户多次批准同一类动作后，提示是否将其加入允许规则——但这个规则由用户显式设置，不由 Agent 自行决定。
5. 监控批准率与审批时长：如果某类确认 99.9% 被秒批，要么它不该需要确认，要么审批人已经不看了。

异步场景：人不在线怎么办

当 Agent 在云端长时间运行，或者处理的是 7×24 小时的工单队列，人不可能随时在线。这时需要提前设计：

• 暂停并保存状态：到了需要审批的步骤，保存进度并通知审批人，批准后从断点继续。这依赖 任务状态与 Checkpoint。
• 先做不需要审批的部分：退款等审批的时候，可以先起草客户回复、准备工单，不要干等。
• 超时默认拒绝：审批超时后，默认 不执行，而不是默认执行。
• 升级路径：普通审批人超时未处理，自动升级给值班主管。

这几条规则组合起来，是一个“人不在也不出错”的等待流程：

中断与接管要真的能用

“随时可以停下来”必须是可靠的机制，而不是一句承诺：

• 中断按钮要在任何时候可见，并且中断后 正在排队的动作不再执行。
• 中断后给出当前状态：已经做了什么、做到一半的是什么、哪些需要人工收尾。
• 接管时 Agent 真正让出控制权。例如 Claude Code 的计算机操作功能允许用户按 Esc 随时中止，且这个按键会被消耗掉，避免被屏幕上的注入内容利用。
• 敏感输入（密码、支付信息）在接管期间不应被 Agent 记录或截图。

常见误区

• “有人批准过，出了问题就是审批人的责任。” 如果审批请求没有给出足够的信息，责任在产品设计。
• “确认越多越安全。” 确认过多会让所有确认一起失效。
• “人在回路里，所以不需要程序校验。” 人会疲劳、会看漏，校验金额上限、状态合法性这类规则应由程序先做，见 程序校验优先。

产品经理检查清单

• 每个需要人参与的节点，用的是哪种模式：计划审批、动作确认、中断、接管还是事后复核？
• 审批请求是否用业务语言说明了做什么、为什么、证据、影响、能否撤回？
• 审批人除了同意和拒绝，还能修改、转交、批量处理吗？
• 审批超时后默认行为是什么？有没有升级路径？
• 批准率、审批时长、审批后仍出错的比例，是否在持续监控？
• 用户中断后，系统如何呈现“做到一半”的状态？

练习

用 45 分钟为「订单售后 Agent」的退款动作设计一个完整的审批请求：

1. 写出审批卡片上展示的全部信息，按“做什么、为什么、证据、影响、能否撤回”组织。
2. 列出审批人的全部可选操作，以及每个操作后 Agent 的行为。
3. 设计超时策略：多久超时、超时后怎么办、升级给谁。

延伸阅读

• Meta AI：Agents Rule of Two——当 Agent 同时处理不可信输入、访问敏感数据、对外产生影响时，文章建议不要让它自主运行，至少要有人工审批或其他可靠校验。

下一步

人是一道重要防线，但不能是唯一一道。下一课「多层护栏」把视野拉开，看看从输入到输出一共可以设置几层防线。