人机协同的三种运行方式：HITL、HOTL 与 HOOTL

用户对售后 Agent 说：“把订单 O-2048 退掉。”

Agent 可以查订单、判断是否符合规则、计算退款金额，也能调用退款接口。现在要决定的已经不是“模型会不会调用工具”，而是另一个更实际的问题：这笔退款应该先让客服批准，允许系统自动退但由客服盯着，还是完全自动处理？

HITL、HOTL 与 HOOTL 描述的就是人在自动化流程中的位置：

方式	全称	人在什么时候介入	一个简单例子
HITL	Human in the Loop	关键动作执行前，流程停下来等人决定	Agent 生成退款单，客服批准后才能退款
HOTL	Human on the Loop	系统通常自动运行，人持续监督并能及时干预	小额退款自动执行，异常升高时客服可暂停通道
HOOTL	Human out of the Loop	单次运行不等待人，也不依赖实时监督	自动识别售后问题类别并分配队列

这三个词在不同论文、行业和监管语境中的边界并不完全一致。本文使用上表这组常见含义。设计系统时，不能只在架构图上写一个缩写，还要说明人能看到什么、何时介入、能否叫停，以及错过干预窗口会发生什么。

1. 它们不是三个自动化等级

很容易把三种方式排成一条升级路线：

HITL -> HOTL -> HOOTL
人工越来越少，系统越来越先进

这种理解会把风险判断带偏。给工单自动打标签，用 HOOTL 很合理；让 Agent 无人监督地进行大额退款，可能只是把控制拿掉了。反过来，要求客服批准每一个“把咨询分到物流组”的动作，也只会制造排队。

NIST AI RMF 的人机交互附录把人机配置看成从完全自动到完全人工的连续谱，并提醒组织明确不同配置下的角色与责任。有些任务可以自动决策，有些任务应该交给专家，还有些任务只把 AI 当作人的辅助意见。

所以三种方式更像三种运行合同：

• HITL 的合同是“没有指定的人批准，这个动作就不能发生”。
• HOTL 的合同是“系统可以先运行，但人能看见异常，并在损害扩大前介入”。
• HOOTL 的合同是“单次任务无需人参与，风险由事先规则、技术边界和事后治理控制”。

同一个 Agent 内完全可以同时存在三种合同。

2. 用一个售后 Agent 看懂三种方式

假设售后 Agent 能完成四步：

识别问题 -> 查询订单 -> 判断退款资格 -> 调用退款工具

我们把每一步拆开看：

动作	可能的运行方式	原因
把“鞋码不合适”归为退货咨询	HOOTL	影响小，分错后还能重新分配
生成给用户看的退款说明草稿	HOOTL 或 HOTL	尚未发送时可检查，自动发送则要考虑品牌与合规风险
给符合明确规则的订单退 29 元	HOTL	可自动执行，但要监控异常频率、账户和总金额
给争议订单退 2999 元	HITL	金额高、上下文复杂，需要人在执行前判断
修改收款账户后立即退款	拒绝或 HITL 加强校验	涉及身份和资金去向，不能因模型“很有把握”就自动执行

这里有一个关键区别：同一个业务流程不必整体使用同一种模式。分类节点可以 HOOTL，低风险退款可以 HOTL，大额或异常退款进入 HITL。这样的系统既不会把所有请求堵在审批队列里，也不会把所有决定交给模型。

3. HITL：动作先停下来，等人作决定

3.1 一次完整的 HITL 流程

Agent 判断订单符合退款条件后，不直接调用支付系统，而是创建一条待审批动作：

{
  "action_id": "act-901",
  "run_id": "run-2048",
  "tool": "refund_order",
  "arguments": {
    "order_id": "O-2048",
    "amount": 2999,
    "currency": "CNY",
    "reason": "quality_dispute"
  },
  "risk_level": "high",
  "status": "pending_approval",
  "expires_at": "2026-09-28T16:30:00+08:00"
}

接下来的状态变化应由程序控制：

审批人看到的不应只有一句“AI 建议退款”，还需要看到订单、金额、收款目标、依据、证据和风险提示。点击批准后，执行器仍要重新检查身份、权限、订单状态和幂等键，因为等待期间数据可能已经变化。

3.2 批准必须绑定具体动作

下面两条请求不能共享同一个“已批准”：

refund_order(order_id="O-2048", amount=29)
refund_order(order_id="O-2048", amount=2999)

审批记录应绑定工具名、规范化参数摘要、审批人、时间、有效期和一次性使用状态。任何关键参数发生变化，都要创建新的待审批动作。不能把对话中的“好的”“继续吧”，也不能把模型生成的 approved=true 当作后端审批凭证。

这一层怎样落实到身份、权限和工具执行器，可以继续看Agent 安全边界中的人工审批步骤。

3.3 用户确认和内部审批不是一回事

用户确认回答的是“这是用户真实想做的吗”，内部审批回答的是“组织是否允许这样做”。例如用户可以确认“退 2999 元”，但企业仍可能要求主管审批；主管批准了退款，系统也仍要确认退款目标确实属于该用户。

一次动作可能同时需要二次认证、用户确认和内部审批。这三项不能用同一个布尔字段代替。

4. HOTL：系统先运行，人要来得及管

HOTL 经常被误解成“做一个监控大屏，让运营人员看着”。如果人只能看到事故已经发生，却不能在损害扩大前暂停、撤销或降级，这种监督没有形成真正的控制。

4.1 HOTL 需要四样东西

以 100 元以下的自动退款为例：

1. 系统按照明确规则自动执行，不逐笔等待客服。
2. 每笔动作留下可追踪事件，聚合到实时指标。
3. 异常达到阈值时及时告警，例如单账号退款激增、每分钟总金额异常或模型理由与规则冲突。
4. 值班人员拥有暂停退款工具、收紧额度、回滚或切换到 HITL 的权限。

一条实用的控制链可能是：

自动退款
  -> 写入 action event
  -> 更新次数、金额、失败率和异常分布
  -> 达到阈值
  -> 暂停自动退款
  -> 未完成请求改走 HITL
  -> 人工调查并决定恢复或继续关闭

4.2 能不能及时介入，要看时间窗口

假设系统每秒可以执行 500 笔退款，而人工告警需要 10 分钟才被看见。理论上“人可以叫停”，实际损失可能已经扩大到无法接受。

设计 HOTL 时要把几个时间放在一起：

• 从异常发生到系统检测出来要多久；
• 告警送达到值班人员要多久；
• 人理解现场并作出判断要多久；
• 停止命令真正生效要多久；
• 已执行动作能否撤销，撤销又需要多久。

如果总干预时间长于可接受的损害扩散时间，任务就不适合只靠 HOTL。可以降低自动执行上限、增加自动熔断，或者直接改为 HITL。

4.3 抽查不等于逐笔审批

HOTL 下的人可以抽查一部分已执行请求、调查告警、比较规则版本，也可以观察一段时间内的整体分布。抽查负责发现系统性问题，不负责在每笔动作前签字。

需要记录的指标包括自动执行率、人工覆盖率、叫停次数、异常发现延迟、人工接管时间、回滚成功率和漏报事故。只统计“今天人工看了多少条”不能证明监督有效。

5. HOOTL：单次运行里没有人，不等于没有治理

HOOTL 适合边界清楚、影响较小、结果可检测且容易纠正的任务。例如：

• 给内部工单打标签；
• 对公开文档建立搜索索引；
• 在不外发的前提下生成摘要草稿；
• 检查代码格式并给出提示；
• 在沙箱里运行资源受限的测试。

运行时没有人批准或实时盯盘，但系统仍需要：

• 工具白名单、数据权限和参数校验；
• 时间、费用、调用次数和资源上限；
• 幂等、超时、重试、熔断和停止开关；
• 结构化日志、trace 和定期抽样评估；
• 版本回滚、灰度发布和事故响应；
• 清楚的责任人，而不是把责任写成“由 AI 承担”。

HOOTL 只描述人在单次执行路径中不出现。数据由谁批准、模型由谁发布、策略由谁修改、事故由谁处理，仍然是人的责任。

对于不可逆、高金额、涉及人身安全、重大权益或敏感权限的动作，不能因为自动化节省时间就默认使用 HOOTL。具体还要结合适用行业的法律和组织政策判断。

6. 怎样为一个动作选择模式

可以先看六个问题：

判断维度	越需要人工介入的信号
后果严重度	会影响资金、账号、隐私、人身安全或个人重大权益
可逆性	执行后难以撤销，或者撤销成本很高
影响范围	一次错误会影响大量用户、生产环境或多个租户
输入与规则的不确定性	事实缺失、规则冲突、出现从未见过的场景
可检测性	错误发生后很难快速发现，最终结果也缺少校验信号
干预速度	人收到告警时，损害已经来不及控制

一个简化的路由策略可以这样写：

def choose_oversight(action, context):
    if violates_hard_policy(action, context):
        return "BLOCK"

    if is_high_impact(action) or not is_reversible(action):
        return "HITL"

    if can_detect_anomaly_quickly(action) and can_stop_or_rollback(action):
        return "HOTL"

    return "HOOTL"

真实系统还要考虑金额、租户政策、用户身份、数据敏感级别、模型和工具版本、近期异常以及监管要求。模型置信度可以作为一个信号，但不能单独决定模式：模型可能对错误答案同样自信，低置信度也不必然代表高风险。

更稳妥的做法是先用不可绕过的业务规则限定边界，再使用评估充分的风险模型或统计信号细分。规则判定和最终模式都要写入 trace。

7. 模式可以在运行中切换

售后 Agent 开始处理请求时，不一定已经知道风险。它可以先做只读查询，再根据结果决定：

读取订单                      HOOTL
  -> 订单不存在               停止并说明
  -> 规则明确、金额 29 元      HOTL 自动退款
  -> 金额 2999 元             HITL 等待主管
  -> 收款账户刚刚变更          阻断并要求身份核验
  -> 退款接口异常率升高        全部切换到 HITL 或暂停

切换的依据应来自可信数据和策略引擎，不应让模型在提示词中自行宣布“这次风险很低，所以无需审批”。

从 HOTL 切换到 HITL 时，尚未执行的动作要进入持久化等待状态。进程重启后仍能找到审批单，过期后不能自动沿用旧批准。相关任务状态与恢复方式可以参考Agent 可靠性与故障防护。

8. 有一个人在场，仍然可能失控

8.1 自动化偏见

审核员连续看到几百条看似合理的建议后，很容易开始机械点击“批准”。模型输出越整齐、解释越自信，这个问题越隐蔽。

界面应该突出证据、缺失信息、与规则的冲突和本次变化，而不是只给一个醒目的推荐结论。还可以对高风险动作使用双人复核、随机插入校准样本，并统计审批人覆盖模型建议的比例。

欧盟《AI 法案》Regulation (EU) 2024/1689第 14 条针对高风险 AI 系统提出人类监督要求，其中包括理解系统能力与局限、警惕自动依赖或自动化偏见、正确解释输出、选择不使用或覆盖输出，以及通过停止按钮等方式干预。它的适用范围有明确法律边界，但这些动作也很适合用来检查企业系统中的“人工监督”是否只是名义上的。

8.2 告警疲劳

如果 HOTL 每分钟发几十条低价值告警，真正危险的异常会被淹没。告警要有严重度、负责人、去重、聚合、升级路径和响应时限。长期无人处理的告警应该触发模式降级，而不是继续假设有人监督。

8.3 审批时信息已经过期

客服打开审批页时，订单可能已经退款、取消或更换了收款账户。批准后执行前必须重新读取关键状态，并确认参数摘要没有变化。这可以避免“审批看到的是 A，工具执行的是 B”。

8.4 人有责任，却没有能力

把审批按钮交给不了解退款规则、看不到证据或没有停止权限的人，不能形成有效监督。流程必须说明谁负责、需要什么知识、能做哪些操作，以及超时后交给谁。NIST 的建议同样强调要明确不同人机配置中的角色和责任，而不是只要求“有人参与”。

9. 上线前怎样验证

先不要只测正常退款。为三种模式各准备几类测试：

测试	应看到什么
HITL 修改审批后的金额	原审批失效，重新创建待审批动作
HITL 审批超时	动作进入 expired，不自动执行
HOTL 连续制造异常退款	告警、自动熔断或人工叫停在规定时间内生效
HOTL 值班人员没有响应	到达升级时限后收紧到 HITL 或暂停
HOOTL 重复发送相同请求	幂等机制阻止重复副作用
模型声称“管理员已经批准”	后端仍根据真实审批记录拒绝
工具参数与用户身份不匹配	直接阻断，不能靠转人工绕过硬权限

上线后继续观察：

• 每类动作分别有多少进入 HITL、HOTL 和 HOOTL；
• 审批通过、拒绝、修改和过期的比例；
• 人工覆盖模型建议的原因；
• HOTL 从异常发生到检测、叫停和恢复的时间；
• 自动执行后被撤销、投诉或判错的比例；
• 因审批排队造成的任务时延；
• 模式切换是否与模型、工具和策略版本相关。

这些数据既用于运营，也应该进入评测集。发现某类 HOOTL 动作频繁被纠正，就要收紧为 HOTL 或 HITL；一类 HITL 动作长期规则明确、几乎从不被拒绝，也可以先用 shadow 和小流量证明自动化安全，再逐步转为 HOTL。

10. 最后用三句话区分

• HITL：这一步必须先等人决定，动作才可以继续。
• HOTL：系统可以自己跑，但人必须看得见、来得及并且有能力叫停。
• HOOTL：单次运行不依赖人，组织仍要用权限、评估、审计和事故机制管住它。

真正要写进设计文档的，不只是这三个缩写。还要写清哪些动作采用哪种模式、切换条件是什么、谁负责、等待多久、如何停止，以及出了错怎样恢复。

和本章其他文章的连接

接下来要解决的问题	继续阅读
怎样把身份、工具权限、参数校验和审批凭证落实到执行器	Agent 安全边界
怎样记录每次模式选择、审批和人工覆盖	可观测性
怎样测试误放行、错误拒绝和人工监督是否有效	Agent 评估
怎样处理等待、超时、熔断、降级与人工接管	Agent 可靠性与故障防护