HITL 不是弹窗确认：人在回路，到底在回路什么

HITL 不是弹窗确认：人在回路，到底在回路什么

你有没有遇到过这种情况：AI Agent 突然弹出一个对话框，问「是否执行这个操作」，你点了个「是」，然后它就把数据库删了。

这不是段子，是真实发生过的事。问题出在哪？出在很多人把「人在回路（HITL）」理解成了「弹窗确认」。

今天把这件事掰开讲清楚。

1 三个概念，先分清

HITL 不是孤立的概念，它跟另外两个词经常放在一起比较：

• HITL（人在回路）  动作执行前必须人工审批，不审批无法执行。强管控。
• HOTL（人在环上）  系统自动运行，人只监控，出事故再介入。
• HOOTL（人在环外）  完全自治，全程无人干预。

你现在用的很多 AI 工具，默认是 HOTL——Agent 先干，你看着，干错了你再叫停。而 HITL 是反过来：先问你，你再让 Agent 干。

2 五条通用规则，生产环境必须落地

HITL 不是一句「让人审批就行」这么简单。它需要成体系的规则设计。以下是业界通用的五条规则：

规则 1：风险分级触发

不是所有操作都要人审。按影响范围分级：

• Tier 1 只读查询（查日志、查指标）：无需 HITL，自动执行
• Tier 2 低风险可逆操作（清缓存、创测试资源）：可配置自动执行，事后抽样审计
• Tier 3 中度风险操作（扩容、调配置）：触发 HITL，人工审批后执行
• Tier 4 高危不可逆操作（删数据库、改核心路由）：强制 HITL，禁止放开全自动

规则 2：暂停必须携带完整上下文

Agent 触发 HITL 等待人工审核时，不能只问「是否执行」。必须输出：计划执行的动作、预期影响、风险提示、回滚方案。让人快速判断，而不是猜。

规则 3：人类决策必须留痕审计

所有审批——同意、驳回、修改意见——完整持久化存储。一旦出事，能追溯谁在什么时间批准了哪条操作。

规则 4：审批超时默认拒绝

人不可能是 7×24 在线的。必须预设超时策略：通知到期无人响应，默认拒绝执行，禁止「超时自动放行」。否则无人值守时 Agent 可能自主执行高风险操作。

规则 5：人工反馈回流优化

人对 AI 方案的批准、驳回、修改意见，不能只完成单次流程。需要把人类判断作为反馈数据，持续优化 Agent 的提示词和工具策略，长期减少同类审批。这才是「回路」的真正含义——不只是中途找人审核，还要持续进化。

3 三个常见误区

误区 1：HITL = 所有操作都要人审核

不对。按风险分级，低风险只读操作无需人工，全量审批只会造成人力堵塞。

误区 2：HITL 只是临时方案，等 AI 够强了就可以取消

不对。不存在完全取消 HITL。只要存在不可逆、高损失操作，人类兜底机制就是生产环境永久的安全底线。这是行业共识，也是 SRE、金融、云原生领域的规范。

误区 3：HITL 只是弹窗确认

不对。完整 HITL 包含：流程中断 → 上下文展示 → 人工决策 → 执行/拒绝 → 日志留存 → 反馈迭代。这是一整套闭环，不是弹个窗就完事。

4 两个真实场景

场景 1：AI SRE 运维

Agent 分析出故障，提出「删除异常 Pod、调整限流策略」。删除资源属于高危操作，触发 HITL：等待运维工程师确认，确认之后 Agent 才执行。

场景 2：代码 Agent

AI 计划修改项目核心配置文件，属于高风险变更。框架触发 HITL，展示修改 diff，程序员确认后再写入磁盘。不确认，不写。

5 用一个比喻收尾

HITL 规则就像汽车的刹车锁止机制。车辆（AI Agent）可以自动规划路线、自动巡航。但是遇到急转弯、陡坡、撞击风险（高危操作），系统强制把控制权交还驾驶员，没有驾驶员确认，不能执行危险动作。

这不是刹车坏了，是刹车必须握在人手里。