Human-in-the-Loop：把人工审批变成可靠工作流

人工介入不是自动化失败

Agent 产品常把“全自动完成率”当作唯一目标，结果要么在不确定时冒险执行，要么在任何异常时把一堆日志甩给用户。Human-in-the-Loop 的正确目标，是把机器擅长的收集、整理和执行，与人擅长的价值判断、责任承担和例外处理接成一条可恢复流程。

人工节点应在设计阶段进入状态机，而不是事故发生后临时加一个确认弹窗。

哪些情况必须让人参与

可以从风险和不确定性两个维度判断。

高风险动作包括付款、删除生产数据、对外发布、发送大批消息和修改权限。即使 Agent 非常确定，也应按政策审批。

高不确定任务包括证据冲突、目标歧义、对象匹配不唯一和关键数据缺失。此时人工提供的是信息或判断，而不是单纯授权。

低风险、低不确定动作可以自动执行；低风险但不确定的任务可以向用户追问；高风险但确定的任务展示精确预览等待批准；高风险且不确定则应停止并解释缺口。

这个矩阵比“模型置信度低于 0.8 就确认”更可靠，因为风险不能由模型自报置信度决定。

审批必须绑定具体参数

一个审批请求需要说明目标、动作、对象、关键参数、证据、预期影响和有效期：

{
  "approvalId": "apr-82",
  "action": "send_campaign",
  "parametersHash": "sha256:...",
  "summary": {
    "audience": "已同意接收通知的华南用户",
    "recipientCount": 842,
    "template": "maintenance-v3"
  },
  "expiresAt": "2026-08-31T12:00:00Z"
}

用户批准后，执行器核对参数哈希。收件人数、模板或对象范围发生变化时，旧批准自动失效。不能让 Agent 获得一个模糊的“允许发送”令牌，再自行改变内容。

审批页面应突出不可逆影响和差异，而不是展示模型的全部推理。批量动作要提供抽样预览、数量和金额上限。

追问要让用户容易回答

Agent 发现信息不足时，应提出最小、具体的问题。与其说“请补充需求”，不如问“报告统计自然周还是最近 7 天？”并说明不同答案会影响什么。

已有事实不要反复询问。追问状态中保存问题 ID、上下文和可接受答案；用户回复后，验证它是否解决阻塞项。若回答改变了目标，应生成新的计划版本，而不是把文字简单附加到旧上下文。

对于专家用户，可以允许直接编辑结构化参数；普通用户则使用清楚选项和默认建议。无论界面如何，默认值不能替用户批准高风险动作。

人工接管需要完整交接包

当 Agent 无法继续时，不能只显示“任务失败”。交接包至少包含：原目标、已完成步骤、关键证据、当前阻塞、已产生的副作用、建议选项和继续所需权限。

用户可以选择修改输入、替换动作、手动完成某一步或终止任务。接管操作作为事件写入运行记录，恢复后 Agent 重新读取最新状态，不能重复已经由人完成的动作。

如果人工在外部系统操作，界面应提供“我已完成”之外的验证。Agent 用只读工具确认真实业务状态，再把步骤标为完成。

等待、过期与提醒

等待人工时任务进入持久状态并释放工作进程。审批有截止时间；时间一到不能继续使用旧授权，因为价格、库存、对象状态或组织政策可能已改变。

提醒策略应克制：首次请求、临近过期和真正阻塞关键路径时通知，不要每次重试都轰炸用户。用户取消后立即传播到队列和正在执行的工具。

团队审批还需要角色与替代人规则。发起者是否可以审批自己的高风险动作、多人是否必须共同批准，都由确定性政策决定，不能让 Agent选择“最方便的人”。

衡量人机协作质量

除了自动完成率，还要看审批等待时间、批准后参数变更率、追问轮次、人工修改比例、错误批准被系统拦截的次数，以及用户拒绝后 Agent 是否正确停止。

人工介入率过高可能说明工具或上下文不足；过低也可能说明系统在该求助时冒险。抽样检查“无需审批”的自动动作，防止模型通过选择另一个工具绕过人工节点。

评测应模拟审批过期、重复点击、拒绝、参数篡改、用户取消和人工在外部完成动作。成功标准是流程状态与真实业务状态一致，而不是界面显示了一个绿色提示。

小结

Human-in-the-Loop 不是在自动化上加一个按钮，而是风险分级、参数绑定授权、持久等待和可恢复交接的组合。让人只在需要价值判断或承担风险时介入，并为其提供足够证据，才能同时提高自动化效率和系统可信度。