HITL现在是必需品吗？AI代理时代的Human-in-the-Loop设计原则

HITL是Human-in-the-Loop的缩写，即在AI判断或行动的流程中，加入人可以确认、批准、修改、中止的节点的设计。

当AI仅生成文本时，通常只需纠正错误答案即可。然而，当AI代理发送邮件、批准退款、部署代码、暂停账户时，情况就不同了。因为答案的错误将直接转化为现实世界的行动。

所以，先说结论：HITL并非所有AI任务都必须附加的程序，但对于执行不可逆或影响重大的行动的AI系统来说，它实际上是必不可少的控制装置。重要的是，不是随意地将人置于任何位置，而是精确地将其部署在风险增大的边界上。

表示低风险自动化和高风险审批边界的HITL代表性图片。

轻松理解HITL

让我们回想一下自动驾驶汽车的驾驶辅助功能。汽车保持车道的工作可以自动化，但如果施工区域车道消失或传感器无法确定情况，则必须将控制权移交给驾驶员。

AI代理也是如此。查询商品信息或创建草稿的工作可以自动处理。但是，大额退款或向外部客户发送邮件等工作，需要人工进行最终确认。HITL并非主张不信任AI，而是一个安全带，让人能够控制AI无法承担责任的结果。

在这里，人的作用不仅仅是点击“确认”按钮。人必须理解AI为何提出此行动，审查其依据和影响，并在必要时能够修改、拒绝或中止。

那么，目前的HITL真的必需吗？

答案是：取决于风险。

NIST AI RMF的Human-AI Interaction附录解释说，有些系统，例如改进视频压缩的模型，可能不需要人工监督；而另一些系统则特别需要人工监督。也就是说，即使是权威的风险管理框架，也不要求“所有AI都采用相同的审批程序”。

另一方面，在高风险领域，要求水平明显提高。欧盟AI法案第14条规定，高风险AI系统在使用过程中应设计成能够由自然人有效监督。监督者必须理解系统的能力和局限性，警惕自动化偏见，并能够忽略、重新定义、撤销输出，甚至安全地中止系统。

然而，截至2026年8月，欧盟AI法案正在分阶段实施。欧盟委员会的实施时间表显示，部分条款已进入执行阶段，但附件III高风险系统规则将于2027年12月2日生效，嵌入受监管产品中的高风险系统规则将于2028年8月2日生效。因此，声称“HITL已在全球所有AI中具有法律强制性”是夸大其词。

然而，无论法律适用性如何，操作层面的方向是明确的。OpenAI的代理构建指南也建议，当失败次数超过阈值，或者行为敏感、不可逆且影响重大时，应将任务移交给人工。取消订单、大额退款、支付批准是典型的例子。

因此，当前的实践标准可以总结为一句话：

不是在每个步骤都由人签字，而是根据风险程度、自主性和使用场景，按比例提高人工监督的强度，这才是更接近标准的做法。

HITL、HOTL、完全自动化有何不同？

HITL并非唯一的人工监督方式。根据系统风险程度，可以分为三种操作模式：

操作模式	人的位置	适用任务	示例
—	—	—	—
Human-in-the-Loop	在重要行动前，人进行批准·修改·拒绝	高风险、不可逆、例外多的任务	大额退款、运营部署、账户暂停
Human-on-the-Loop	人监控自动执行并在必要时介入	中等风险、可逆的任务	内容分类、有限的自动恢复
Human-out-of-the-Loop	在既定安全范围内自动执行	低风险、重复性、易于恢复的任务	格式转换、内部草稿、视频压缩根据风险程度从自动执行到人工批准的四个阶段 随着风险增大而提高监督和批准强度的操作模式。基于NIST AI RMF和欧盟AI法案的风险比例原则重新构建。来源：NIST AI RMF Core, EU AI Act 第14条 核心不是最大化自动化率，而是在可接受的风险范围内最大化自动化范围。如果低风险任务每次都需要批准，就会积累审查疲劳，人们最终会不看内容就点击批准按钮。这更像是“人工盖章”而非HITL。 必须呼叫人工的五个信号1. 结果难以逆转支付、汇款、数据删除、外部发送、运营部署等执行后恢复成本高的行为需要事先批准。即使是同一个代理，最好将草稿生成（自动）与实际发送（批准后执行）分开。 2. 失败影响重大如果一次错误可能对人的权利或组织的信任产生重大影响，例如在健康、安全、招聘、信用、法律、安全、个人信息等领域，则应保留人的判断权。 3. 模型不确定或反复失败低置信度、相互冲突的依据、工具调用失败、重试次数超限都是移交信号。不应让系统继续执行“失败三次，但第四次可能会成功”，而应在设定的失败阈值处停止。 4. 遇到政策例外政策中没有的情况、相互冲突的规则、客户的特殊请求，都不是模型可以随意创建新政策的问题。负责人应进行判断，该决定应随后反映在政策和评估数据中。 5. 试图越过权限边界只读代理请求写入权限、内部系统试图向外部系统发送数据、或试图访问敏感信息的时刻是明确的批准点。批准界面不应只显示“允许”，还应同时显示目标、范围、期限和预期影响。 好的HITL如何运作？好的设计不会将AI的所有思考都推给人类。策略引擎首先自动处理低风险行为，只将超出设定条件的请求发送到审查队列。 AI代理的提议经过策略检查、人工批准、最小权限执行和审计日志的控制流程 提议·策略检查·人工批准·最小权限执行·观察与评估的HITL控制循环。基于NIST AI RMF Core和OpenAI代理构建指南重新构建。 在此流程中，以下七个步骤至关重要： 1. 分离提议和执行。 代理首先创建行动计划和预期影响。 2. 通过代码检查策略。 使用确定性规则确认金额、数据等级、目标系统和权限范围。 3. 分类风险。 低风险自动执行，中风险进行监控，高风险移交给人工。 4. 显示审查所需的上下文。 在一个屏幕上提供原始请求、AI的提议、依据、变更点、预期影响以及如何回滚。 5. 赋予人实际的选择权。 不仅要能批准，还要能修改、拒绝、暂停和安全中止。 6. 以最小权限执行。 只在批准的范围和时间内调用工具。 7. 记录和评估所有决策。 记录谁查看了什么以及做出了什么决定，用于故障分析和模型改进。 NIST AI RMF Core也建议制定区分人与AI角色和责任的政策（GOVERN 3.2），并定义、评估和记录人工监督程序（MAP 3.5）。HITL不是一个按钮，而是一个策略、界面、权限、日志和评估协同工作的系统。 为什么加入人工仍不安全？仅仅因为人最后看一眼，系统并不会自动变得安全。 首先，存在自动化偏见。如果AI反复提供看似合理的解释，审查者很容易相信机器的判断比自己更准确，并直接批准。这就是欧盟AI法案第14条明确规定监督者必须能够识别过度依赖自动化输出倾向的原因。 其次，存在审查疲劳。如果每天收到数百个相同的批准请求，人就会成为瓶颈，判断质量也会下降。低风险请求应通过基于规则的自动化处理，只筛选出真正需要人工判断的例外情况。 第三，存在信息不足。如果批准界面只显示AI的结论，而没有依据、变更点和影响，人就只能承担责任而无法做出判断。如果是代码变更，应显示差异和测试结果；如果是支付，应显示金额和收款人；如果是数据传输，应显示字段和目的地。 第四，存在无权限监督者问题。如果审查者发现错误但没有权限停止系统或推翻决定，监督就形同虚设。任务必须由具备能力、培训、时间和权限的人员承担。 客户退款代理的实际案例假设客户服务AI处理退款。 – 准确符合条款、金额小且同一账户无异常迹象的请求将自动处理。 – 符合条款但金额大或近期退款次数多的请求，在处理前会发送给人工审查。 – 如果条款冲突或客户提出特殊情况，由负责人判断政策例外。 – 如果支付系统错误反复发生，则中止重试并移交给操作员。 – 所有自动和手动决策都将记录，包括请求、依据、批准人、执行结果和可恢复性。 这种设计并非“AI或人”的二选一。机器负责重复性判断和信息整理，人负责责任、例外和价值判断。这是一种将两者的优势部署在不同节点的方式。 实施前需确认的清单				—	—		问题	未准备好可能产生的问题					—	—		哪些行为是敏感的、不可逆的、高影响的？	审批点随意决定		自动执行的风险限度是多少？	过度自动化或审批瓶颈		在何种失败·不确定性下移交？	无限重试和静默失败		审查者是否能看到依据·差异·影响？	沦为橡皮图章式审批		批准·修改·拒绝·中止是否都可能？	人的控制权形式化		执行权限是否限制在批准范围内？	一次批准导致权限过度扩大		所有决策和结果是否可观察？	无法追溯事故原因和责任		是否评估批准质量和移交标准？	系统长期不改进	结论：HITL是设计“可控性”，而非仅仅加入人类HITL现在是设计AI代理系统时不可或缺的基本问题。然而，在每次点击前都弹出审批窗口并非答案。 低风险且易于回滚的任务应自动化，中风险任务通过观察和事后干预管理，高风险、不可逆或不确定的行为应设置人工审批点，让人能够实际停止和更改。并且，这些决策必须被记录，以改进未来的政策和评估。 最终，衡量良好HITL的标准不是“过程中是否有人参与”。而是：人是否在适当的时机，以真实的权限，看到了足够的信息，从而控制了AI的行为？ 官方参考资料 – 欧盟AI法案第14条 — 人工监督 – 欧盟委员会 — AI法案执行时间表 – NIST AI RMF核心 – NIST AI RMF附录C — 人机交互 – OpenAI — 构建AI代理的实用指南