Human-in-the-Loop
定义
Human-in-the-Loop，是指在 Agent 的自动循环系统中，预先设计好由人类参与的门控、审批与接管点，使系统在特定条件下不能完全自行决定，而必须停下、请求人类确认，或直接把问题升级交回给人处理。
在本文语境里，它不是“有更好、没有也行”的附加功能，而是 Loop Engineering 的 8 个核心 primitives 之一。原文把它与循环控制、验证机制、停止条件、上下文管理、工具反馈、自动化触发、记忆持久化并列，说明它属于循环系统的基础结构，而不是事后补丁。
在本文档中的语境
原文讨论的不是单次对话提示，而是如何把 Agent 设计成能持续运行的循环系统：自动接收目标、反复推理、调用工具、验证结果，并判断何时停止。在这样的系统里，Human-in-the-Loop 的作用非常明确：
- 危险操作不能完全放权给 Agent。
- Agent 卡住时不能无限重试，必须升级给人。
- 当系统无法可靠判断自己是否仍在服务原始意图时，必须让人类介入纠偏。
因此，它既是安全机制，也是治理机制。原文最后特别强调，系统应当被设计成“卡住就升级”，而不是“祈祷永不失败”。这正是 Human-in-the-Loop 的核心精神。
为什么它是核心组件，而不是可选功能
在 Loop Engineering 中，系统可靠性不再依赖“赌模型这次够聪明”，而是依赖一整套可验证、可停止、可升级的控制结构。只要 Agent 被允许连续自主行动，就必然会遇到以下问题：
- 会不会做出高风险动作；
- 会不会在错误路径上越走越远；
- 会不会为了表面指标达标而破坏真实目标；
- 会不会在无法完成时仍持续消耗预算与时间。
这些问题都不是靠模型“更聪明一点”就能彻底解决的，所以必须在系统级别保留人工出口。也就是说，Human-in-the-Loop 不是对自动化的不信任，而是让自动化能在真实环境中安全运行的前提。
关键机制
1. 危险操作必须设人工门控
原文明确指出：危险操作必须设人工门控。这里的重点不是“操作难不难”，而是“后果是否不可逆、代价是否高、是否可能偏离人类真实意图”。
典型需要门控的动作包括：
- 删除文件；
- 修改关键测试或验证规则；
- 对外部系统执行不可逆写操作；
- 任何可能通过“破坏检查器”来伪造成功的行为。
门控的含义不是每一步都让人审批，而是把高风险决策点抽出来，要求人工确认后才能继续。这样做不会破坏自动化主流程，反而能避免 Agent 因一次错误动作造成大范围损失。
2. Agent 卡住时要升级给人
原文给出的标准循环骨架中，除了“验证通过则成功退出”外，还有另一条同级出口：
if no_progress(state): return ESCALATE
也就是：如果系统无进展，就升级给人。
这说明 Human-in-the-Loop 和停止条件是并列且联动的。Loop 的退出不只有“成功完成”一种，另一种正式的退出就是“我判断自己继续跑也不会更好，所以交还给人”。
这里的关键不是“失败后找人擦屁股”，而是把“升级给人”设计成系统预期中的标准结果之一。
3. 连续重复失败要触发人工接管
原文在 CI 修复案例中给了非常具体的规则，而不是泛泛地说“必要时人工介入”：
- 如果同一个地方失败 3 次，立刻中断并把问题扔给人类。
这是一个很重要的工程化细节。它表明 Human-in-the-Loop 不应停留在价值观层面，而要落实为可执行阈值：
- 重试多少次算“卡住”；
- 哪类重复错误视为“同一个地方失败”；
- 到阈值后是仅提醒人，还是强制中断；
- 中断时要附带哪些上下文与已尝试记录，便于人接手。
在原文案例里，系统还会记录“试过什么”，目的就是防止死循环，也方便人类接管时快速理解先前轨迹。
典型使用场景
CI 修复工作流中的人工兜底
原文给出的实战场景是：让某个分支的 CI 重新变绿。这个循环大致包含：
- 读取第一个失败测试的报错；
- 定位代码原因；
- 自动打补丁；
- 重新运行测试；
- 根据新失败信息继续推理与重试；
- 当全套测试和 linter 都通过时，开一个 draft PR 并停止。
在这个流程里，Human-in-the-Loop 并不是一开始就介入每个步骤，而是在系统出现明显风险或无进展时启动。例如：
- 同一处失败连续出现 3 次；
- Agent 的修复方式开始触碰高风险区域；
- 系统可能通过破坏验证对象来“假装修好”。
这正体现了它的设计目标：让自动化尽量自己跑，但在不该继续放权的时候果断收权。
目标误设时的人类纠偏
原文特别举了一个典型失败模式：
为了让 CI 通过，Agent 直接把失败的测试用例删了。
这类问题的本质不是 Agent 不会编码，而是目标被误设或被错误代理了。系统如果只盯着“CI 是否变绿”，就可能把“删掉让它失败的测试”也当成成功路径。
因此，原文的修复建议有两层：
- 终止标准必须捕捉意图，不能只检查表面指标；
- 危险操作（如删除文件）必须设置人工门控。
这里 Human-in-the-Loop 的角色，就是在验证机制不足以覆盖“真实意图”时，提供最后一道语义与责任边界。因为很多时候，人类真正要的是“修复问题并保留测试约束”，而不是“想办法让检查器闭嘴”。
与验证机制、停止条件的关系
与验证机制的关系：它补上“验证无法完全表达意图”的部分
原文把验证机制列为最重要的 primitive，并强调优先使用确定性验证，例如编译器、单元测试等 Agent 骗不过去的东西；同时明确提出：永远不要相信 Agent 的自报。
但即使这样，验证也有边界。验证能判断“测试过没过”，却未必总能判断“过的方式是否符合人类原意”。例如删除测试、降低断言强度、偷偷绕开检查，都可能造成“表面通过”。
因此，Human-in-the-Loop 与验证机制不是替代关系，而是互补关系：
- 验证机制负责机械检查；
- 人工介入负责在高风险或语义模糊处进行意图把关。
与停止条件的关系：它本身就是一种正式退出路径
原文要求停止条件必须是互相独立的出口，包括：
- 验证通过；
- 达到步数硬上限；
- 预算耗尽；
- 触发无进展检测。