在线 -
搜索
← 返回题目列表

Agent 为什么需要 Human-in-the-loop？

高频 中等 第 13 / 26 题 更新于 2026/09/17
AI AgentHuman-in-the-loop审批风险控制

简化版

Human-in-the-loop（HITL）是在 Agent 无法独立承担风险或不确定性时，把澄清、审核、授权或接管交给人。它最适合不可逆、高金额、权限敏感、证据不足和模型低置信场景；关键不是给流程随便加一个“确认”按钮，而是定义何时暂停、向人展示哪些证据、批准后从哪个检查点继续，以及超时或拒绝后如何安全结束。

详细版

HITL 常见有四种介入方式：执行前审批，例如付款、发信、删库；信息不足时澄清，例如收件人同名；结果审核，例如医疗摘要和合同条款；异常时接管，例如工具连续失败。触发条件应由风险规则、权限、金额、置信区间和异常状态共同决定，不能只听模型说“我不确定”。

Agent 计划 -> 风险判定
              ├─ 低风险 -> 自动执行 -> 验证
              └─ 高风险 -> 冻结计划 -> 人工审核
                                      ├─ 批准/修改 -> 恢复执行
                                      └─ 拒绝/超时 -> 取消或转人工

审批载荷必须展示目标对象、动作参数、数据来源、预计影响和不可逆部分；批准令牌要绑定任务版本、审批人和有效期，防止计划在等待期间变化后复用旧批准。执行层仍需权限校验、限额和幂等，人工批准不能替代系统安全控制。

完整版教学

一、人不是失败兜底，而是系统角色

Agent 的输出具有概率性，现实动作却可能不可逆。让人介入的目的，是在机器缺少信息、授权或责任能力时建立明确决策点。审核员不是替 Agent 重做所有工作，而是处理需要人类判断或责任确认的部分。

若每一步都人工确认，自动化价值会消失；若从不确认，小概率错误会在大规模调用中持续发生。因此 HITL 的核心问题是“哪一步、什么风险、由谁、基于什么证据做决定”。

记忆钩子：HITL 不是弹窗，而是一份暂停—审阅—决策—恢复协议。

二、四类介入点解决不同问题

澄清补足缺失意图，例如用户说“把报告发给张伟”，但通讯录有三位同名。审核判断开放式结果是否合格，例如品牌文案。授权允许有副作用的动作，例如转账。接管则在系统失去继续能力时把完整状态交给人。

类型人提供什么Agent 后续动作
澄清缺失参数或歧义选择更新状态后重规划
审核接受、修改或退回意见使用审核版本继续
授权对具体动作承担许可仅执行获批动作
接管人工完成或改变目标停止自动循环

四者不能混用。用户补充一个邮箱地址，不代表他授权发送；编辑修改文案，也不等于批准公开发布。

三、触发条件要由系统计算

只让模型自行决定“是否需要人”并不可靠，因为模型可能过度自信。触发器应包含确定性条件：动作是否不可逆、金额是否超阈值、是否跨权限域、证据是否缺失、验证是否失败，以及该任务的风险等级。

可以使用风险分层：低风险自动执行，中风险抽样或事后审核，高风险逐次事前审批。例如退款小于 50 元且规则验证通过可自动处理；50～500 元进入抽样；超过 500 元或涉及异常账户必须逐笔审批。具体阈值应来自业务损失和历史错误，而不是拍脑袋。

模型置信度只能作为一个信号。生成概率未必经过校准，开放式任务也很难得到可信单值；更稳的是把检索覆盖、规则冲突、异常类型和输出验证结果一起使用。

四、审批页面必须支持真正判断

糟糕的确认框只写“Agent 将执行操作，是否继续”，用户无法看出风险。有效审批要展示动作对象、关键参数、证据来源、影响范围、可否撤销、模型做过哪些假设，以及批准后会发生什么。

例如邮件审批至少展示真实收件人地址、主题、正文、附件、是否群发。付款审批还要展示币种、金额、账户、手续费和幂等业务号。敏感信息应按审批人权限脱敏，不能为了透明把全部秘密暴露出来。

确认页面还要突出变化。如果人修改过金额或收件人，应重新运行相关验证；不能在旧预览上批准一个已经变化的新计划。

五、批准令牌要绑定具体版本

审批可能等待十分钟或一天，其间库存、价格、计划甚至权限都可能变化。批准不能只是数据库里的布尔值 approved=true，而应绑定任务 ID、动作哈希、关键参数、审批人、时间和有效期。

approval = sign(task_id, action_hash, approver, expires_at)

若动作参数从“退款 100 元”改成“退款 1000 元”，哈希变化，旧令牌自动失效，需要重新审批。执行服务必须验证令牌，而不是让 Agent 在 Prompt 中声称“用户已同意”。

假设批准有效期 30 分钟，排队 35 分钟后才执行，就应重新检查或申请审批；这能防止人基于过期状态做出的许可被滥用。

六、暂停与恢复需要检查点

Agent 等人期间不能一直占用进程和模型上下文。系统应把目标、计划版本、已完成步骤、工具结果、待审批动作和副作用日志持久化，进入 WAITING_APPROVAL 状态；收到决定后从检查点恢复。

RUNNING -> WAITING_APPROVAL -> APPROVED -> RUNNING -> SUCCEEDED
                         \-> REJECTED  -> CANCELLED
                         \-> EXPIRED   -> SAFE_STOP

恢复前再次验证外部状态。如果机票价格变化、文件已被删除或用户权限被收回，应使批准失效。检查点还要保证写操作幂等，避免恢复消息重复投递导致动作执行两次。

七、控制“确认疲劳”和排队成本

过多确认会让用户形成机械点击习惯，使 HITL 失去安全价值。应合并同一风险边界内的动作、自动通过已被可靠规则覆盖的低风险情况，并把真正关键的差异突出显示。

若每天有 10 万次动作，5% 进入审核，即 5000 单；审核员平均每单 90 秒，需要约 125 人时/天。将误触发率从 5% 降到 2%，可减少 75 人时，但若因此漏过高风险动作又得不偿失，所以要分别评估审核精确率和风险召回率。

SLA 也必须设计：超时后是取消、转更高权限人员还是继续等待。高风险动作绝不能因为“审批超时”而默认通过。

八、评估 HITL 要看端到端风险

离线测试应覆盖正确触发、漏触发、误触发、审批信息完整性、参数变化后令牌失效、拒绝与超时流程。线上则观察自动完成率、人工介入率、平均等待时间、审核修改率、机械批准率和漏拦截事故。

如果 99% 的请求都被人工批准，但审核修改率接近零，可能是触发太宽，也可能是界面无法发现问题。反过来，人工介入率很低却频繁发生不可逆事故，说明规则漏拦截。指标必须和损失事件一起解释。

审计链应能回答：谁在什么时间看到了什么内容，批准了哪个版本，执行服务校验了什么令牌，最终产生了什么副作用。

九、常见误区与追问

  • 误区：所有 Agent 都必须每一步人工确认。 HITL 应放在风险、歧义和责任边界上，否则只会制造确认疲劳。
  • 误区：模型说低置信才需要人工。 触发器还要使用动作类型、权限、金额、证据和验证结果。
  • 误区：人工批准后可以跳过权限检查。 人的决定不能替代执行服务的最小权限和业务规则。
  • 误区：一个 approved 字段足够表示授权。 批准必须绑定动作参数、版本、审批人和有效期。
  • 误区：审批超时可以默认通过以免阻塞。 高风险动作应安全停止或升级，不能用可用性换掉授权。
  • 追问：怎样降低确认疲劳？ 收窄触发条件、批量展示同类低风险项，并突出参数变化与不可逆影响。
  • 追问：用户修改审批内容后怎么办？ 生成新动作版本，重新验证；若风险边界变化则重新审批。
  • 追问：等待审批时 Agent 如何保存状态？ 持久化检查点并释放运行资源，收到事件后校验状态再恢复。

十、加强记忆

HITL 记住“四种人类输入”：澄清补信息、审核看质量、授权担许可、接管处理异常。系统先用确定性风险规则决定何时暂停，再把对象、参数、证据和影响展示给正确的人；批准令牌绑定动作版本与有效期，恢复前重新检查外部状态。最后用最小权限、幂等和审计守住执行层，因为人的一次点击只能表达决定，不能替代整个安全系统。