Agent 最容易出问题的地方，不是"不会回答"，而是"太敢执行"。
查资料可以自动。总结内容可以自动。分类、检索、生成计划也可以自动。
但只要涉及真实影响，比如退款、删除数据、发送正式邮件、修改生产配置、下单付款，就不能让 Agent 直接放飞。
这就是 Human-in-the-Loop，简称 HITL。
1. HITL 到底是什么
HITL 不是简单地"让人看一眼"。
它是一种工程模式：Agent 执行到关键节点时，先暂停，把上下文、参数、风险、建议动作交给人。人做出决定后，系统再恢复执行。
官方资料里，OpenAI Agents SDK 把 HITL 用在敏感工具调用审批上：工具声明需要审批，运行时出现 pending approval，审批后通过 RunState 恢复执行。LangGraph 的 interrupt 机制也能暂停图执行，保存状态，等待外部输入后再继续。
**一句话：**HITL 不是把系统变慢，而是把风险动作变可控。
2. 为什么 Agent 必须有人类参与
传统程序的问题，通常是代码写错。Agent 的问题更复杂。它可能理解错目标，也可能选错工具，还可能把错误参数传给真实系统。
大模型没有业务责任，也没有法律责任。它可以建议，但不能天然拥有最终执行权。
业务风险：退款、赔付、合同、生产变更，错一次就可能造成损失。
安全风险：删除文件、改权限、发邮件、调外部接口，都有现实影响。
合规风险：金融、医疗、法务、隐私数据，不能只靠模型判断。
不确定性：当模型置信度低、用户意图模糊、参数缺失时，应该先问人。
信任问题：用户更愿意接受一个可解释、可干预、可追责的 Agent。
3. 人应该在哪些节点介入
HITL 最大的误区，是每一步都找人。这样系统会慢到不可用。
正确做法是：低风险自动跑，高风险才暂停。人只出现在关键闸门上。
工程上通常把人工介入放在四个位置：
计划审批：多步骤计划准备执行前，先让人确认目标和边界。
工具审批：调用有副作用的工具前，比如退款、删除、发送、修改配置。
异常升级：工具失败、结果冲突、模型低置信度时，交给人判断。
最终确认：对外输出正式结论、重要建议或合规内容前，做人工复核。
4. 源码级理解：HITL 不是一个弹窗，而是一套状态机
很多人以为 HITL 就是前端弹一个"是否确认"。不对。
真正的 HITL 要能暂停、保存、恢复。否则审批人点了同意，Agent 已经忘了自己刚才执行到哪一步。
底层至少要有五个对象：
RunState：当前任务状态，包含对话、计划、上下文、工具调用进度。
ApprovalTask：审批任务，包含工具名、参数、风险原因、等待谁审批。
Decision：人工决定，通常包括 approve、edit、reject、respond。
ResumeCommand：恢复命令，把人工决定重新注入执行流程。
AuditLog：审计日志，记录谁在什么时候对哪个动作做了什么决定。
HITL 的底层运行逻辑
LangChain HITL middleware 的决策类型比较典型：approve 表示照原参数执行，edit 表示修改后执行，reject 表示拒绝并给出原因，respond 表示人直接作为工具返回结果。
5. 案例：生产变更 Agent
假设我们做了一个运维 Agent。用户说："把支付接口超时时间从 3 秒调到 10 秒。"
这不是普通问答。这是生产变更。Agent 可以分析，但不能直接改。
安全流程应该是：
Agent 解析需求，识别目标是修改支付链路配置。
读取当前配置、变更历史、依赖服务和近期告警。
生成变更计划：改什么、影响谁、如何验证、如何回滚。
风险引擎判断：生产环境 + 支付链路 + 真实配置，必须审批。
系统暂停执行，把变更卡片推给负责人。
负责人可批准、修改参数、拒绝或要求补充信息。
审批通过后执行，并自动验证；失败则回滚并记录日志。
这个案例说明：HITL 不是阻止 Agent 做事，而是让 Agent 在真实系统里安全做事。
6. 设计 HITL 时最容易踩的坑
只在前端弹确认，没有保存运行状态，刷新页面后无法恢复。
审批卡片信息太少，人看不到参数、风险、影响面和回滚方案。
所有动作都审批，导致系统变成"人工系统套了个 AI 壳"。
只有同意按钮，没有修改、拒绝、补充信息的选项。
审批通过后不做权限校验，默认人点了就一定能执行。
没有审计日志，事后不知道谁批准、批准了什么、执行结果如何。
7. 总结
HITL 的本质，是把人类判断力放到 Agent 的关键控制点上。
AI 负责跑流程、查数据、生成方案。人负责确认边界、承担责任、处理模糊和高风险决策。
一个能上线的 Agent，不是永远不问人，而是知道什么时候必须问人。