Human-in-the-loop：什么时候必须让人确认
一次让我重新想「确认」这件事的线上事故
去年我负责一个客服 Agent 系统。上线第二周，运营同事跑来找我：Agent 给一个投诉用户自动发了一封退款确认邮件，但退款金额是模型「推理」出来的——500 元，不是用户要求的 50 元。用户已经收到邮件，运营不得不手动再发一封更正说明。
这件事暴露的问题在于我把「自动执行」和「人工确认」的边界画错了。模型可以建议退款金额，但最终按下「发送」按钮的人，不应该是模型。
从那以后我对 HITL（Human-in-the-loop）的理解从「加个确认按钮」变成了一个系统设计问题：哪些动作需要人确认？确认界面要展示什么？超时没确认怎么办？确认后出了问题怎么回溯？ 这篇文章是我在生产环境里踩坑后整理的经验，不一定覆盖所有场景，但核心思路经过了实际检验。
人工确认的三种模式
「人工确认」在学术和工程语境里不是一个单一概念。Redis 的工程博客把 AI 系统中的人工参与分成三个层次，这个分类直接影响你的系统架构选型：
- Human-in-the-loop（HITL）：人做决策，AI 提供建议。系统必须等人输入才能继续。执行模型是同步的——工作流暂停，等人审批，再恢复。
- Human-on-the-loop（HOTL）：AI 自主运行，人通过监控面板观察并保留否决权。执行模型可以是异步的，但依赖监控和覆盖界面。
- Human-out-of-the-loop：系统在预设边界内完全自主运行。人在设计时确定边界，运行时不参与。大多数生产团队对高风险任务回避这个模式。
LangChain 在 LangGraph 中实现的 interrupt() 机制就是典型 HITL：工作流在特定节点暂停，把当前状态（对话历史、工具调用结果、中间产物）序列化保存，等人审批或修改后用 Command(resume=...) 恢复执行。
选择哪种模式，取决于动作的风险等级和可逆性，而非「越自动化越好」。
哪些动作需要确认：一张风险分级表
不是所有 Agent 行为都需要人确认。低风险只读查询（搜索商品、查订单状态）和草稿生成（邮件草稿、报告初稿）可以先自动执行。以下是我在生产系统中总结的分级标准：
| 风险等级 | 动作类型 | 典型例子 | 确认策略 |
|---|---|---|---|
| 低 | 只读查询 | 搜索、查状态、拉取报表 | 自动执行，不阻塞 |
| 中 | 内部写入 | 创建草稿、更新内部备注、打标签 | 自动执行，异步通知 |
| 高 | 对外发送 | 邮件、消息、公告、客户回复 | 同步阻塞，等待审批 |
| 极高 | 不可逆操作 | 删除数据、退款、支付、发布上线 | 强制审批 + 二次确认 + 回滚路径 |
| 特殊 | 低置信度结果 | 模型信息不足、工具返回异常 | 无论风险等级，一律上报人工 |
这个分级不是一成不变的。随着任务稳定、失败样本积累、回滚路径验证通过，可以逐步把某些「高」降级为「中」。但降级必须有数据支撑，不能凭感觉。
工作流全景：从触发到审批到恢复
这个流程图覆盖了四种路径：低风险自动执行、中风险异步通知、高风险同步审批、低置信度强制上报。关键设计点是：每次暂停都有状态持久化，每次审批都有审计日志，每次超时都有降级策略。
审批界面该展示什么
很多团队做 HITL 时只放一个「确认」和「拒绝」按钮。这不够。审批人需要足够的上下文才能做出知情判断。
| 展示项 | 作用 | 缺失后果 |
|---|---|---|
| Agent 准备做什么 | 让审批人理解动作意图 | 审批人不知道在批准什么 |
| 为什么这么做 | 暴露模型推理依据 | 无法发现推理错误 |
| 涉及哪些对象 | 明确影响范围 | 审批人低估影响 |
| 使用了哪些数据 | 追溯数据来源 | 出了问题无法定位 |
| 操作是否可逆 | 影响审批决策的谨慎程度 | 不可逆操作被轻率批准 |
| 超时后会发生什么 | 让审批人知道不操作的后果 | 审批人故意忽略，等超时兜底 |
| 替代方案 | 提供更安全的选项 | 审批人只能批准或拒绝，没有中间路线 |
在 Slack 审批卡片的实践中，我会把模型生成的 SQL、邮件正文、API 请求体都完整展示出来，而不是只展示一个摘要。摘要会丢失关键细节，审批人看到的可能和实际执行的不一样。
四种常见模式的对比
生产系统中 HITL 不只是「加个审批」，不同模式覆盖不同阶段。以下是 Redis 工程博客总结的四种模式和我的实战感受：
| 模式 | 介入时机 | 适用场景 | 基础设施要求 | 我的实战感受 |
|---|---|---|---|---|
| 运行时审批门控 | 执行前暂停 | 不可逆操作、高风险动作 | Checkpoint 持久化、异步恢复 | 最常用，也最容易做对 |
| 置信度路由 | 输出后分流 | 高吞吐量、边界模糊的任务 | 多维度信号聚合、审核队列 | 比单看置信度靠谱得多 |
| 结构化审核队列 | 输出后异步审核 | 内容审核、质量把关 | 审核状态驱动下游自动化 | 人审核变成流水线的一等公民 |
| 主动学习反馈环 | 审核后回流训练数据 | 需要持续改进的模型 | 标注数据管道、定期微调 | 长期收益大，但前期投入不小 |
大多数生产系统会组合多种模式。客服邮件用运行时审批门控，内容审核用置信度路由 + 结构化审核队列，模型改进靠主动学习反馈环。
人工确认的成本与权衡
HITL 不是免费的。加了人工确认，系统延迟会增加，吞吐量会下降，审批人可能被频繁打断。以下是我总结的主要权衡：
| 维度 | 收益 | 成本 |
|---|---|---|
| 安全性 | 拦截不可逆错误操作 | 增加端到端延迟 |
| 合规性 | 满足 EU AI Act 等法规要求 | 审计日志增加存储和查询负担 |
| 信任度 | 用户和运营更信任系统 | 审批疲劳导致人失去判断力 |
| 灵活性 | 可以逐步放开自动执行 | 初期人工成本较高 |
| 可观测性 | 每次审批产生决策数据 | 需要建设和维护审批界面 |
EU AI Act 第 14 条要求高风险 AI 系统必须具备有效的人工监督能力，包括解释输出、覆盖决策和停止运行的能力。第 12 条要求自动记录日志，第 26 条要求部署方保留日志。NIST AI RMF 同样将 HITL 列为常见风险管理策略。这些法规正在把人工监督从「最佳实践」推向「合规要求」。
检查清单：你的 HITL 设计完整吗
以下是我在实际项目中用的检查清单，每次设计或审查 HITL 流程时都会过一遍：
- 是否对所有不可逆操作设置了审批门控
- 审批请求是否展示了完整的操作上下文（不是摘要）
- 是否标注了每个操作的可逆性
- 超时策略是否明确（默认拒绝还是升级）
- 状态持久化是否可靠（暂停后数据不丢失）
- 审计日志是否记录了审批人、时间、输入、输出和执行结果
- 置信度路由是否使用了多维度信号而非单一分数
- 是否考虑了审批疲劳（高风险才打断，低风险自动执行）
- 通知渠道是否匹配风险等级（高风险用 Slack + SMS，低风险用邮件）
- 是否有降级策略（审批人不在时怎么办）
- 回滚路径是否经过实际测试验证（而非仅理论上可回滚）
- 是否定期回顾审批数据，调整风险分级和自动化边界
- 模型改进是否有反馈环（人工审核结果能否回流训练）
写在最后
人工确认是系统可靠性的组成部分，而非 Agent 能力的退步。它让模型负责生成建议，让人负责最终授权。
但 HITL 设计的好坏差异很大。一个只放「确认」按钮的界面和一个展示完整上下文、标注可逆性、提供替代方案的审批卡片，效果完全不同。一个依赖模型自身置信度的路由方案和一个聚合多维度信号的路由方案，拦截错误的能力也完全不同。
我现在的原则是：高风险动作必须同步审批，中风险动作异步通知，低风险动作自动执行。置信度路由用双信号，超时必须有默认策略，每次审批都记录审计日志。这些不是理论推导出来的，是从线上事故和运营反馈里学来的。
如果你的 Agent 系统还没有 HITL，建议从不可逆操作开始加审批门控。如果已经有了，建议回头检查一下：审批人看到的是完整上下文还是摘要？超时策略是否明确？置信度路由是否只依赖单一分数？
参考资料
- Human-in-the-loop - LangChain Docs — LangGraph 中 HITL 的官方实现，涵盖
interrupt()和谓词审批。 - AI Human in the Loop: Production Oversight Patterns - Redis — 四种生产级 HITL 模式，包含置信度路由和状态持久化。
- Human-in-the-Loop Approval Framework - Agentic Patterns — 审批框架模式详解，包括装饰器实现和风险分级。
- Choose a Design Pattern for Your Agentic AI System - Google Cloud — Google Cloud 的 Agent 设计模式指南，涵盖 HITL 模式选择。
- Production AI Playbook: Human Oversight - n8n Blog — 生产 AI 中人工监督的实践手册。
- Making it easier to build human-in-the-loop agents with interrupt - LangChain Blog — LangGraph
interrupt()机制的设计思路和实现细节。 - How to Add Human-in-the-Loop Controls to AI Agents - Agno — 在工具层用
requires_confirmation=True实现轻量审批。 - EU AI Act Article 14 - Artificial Intelligence Act — 高风险 AI 系统的人工监督法规要求。