智能体面试准备（二十七）：人机协作 HITL——审批流、接管、反馈闭环与可审计

前面讲了多模态 Agent（B25）、成本工程（B26），把 Agent 的"感知"和"算账"都补齐了。但有一个最现实的问题一直悬而未决：当 Agent 要替人做决策、甚至替人执行动作时，人到底放在哪里？这就是本系列第二十七篇——人机协作（Human-in-the-loop, HITL）。本文按"为什么需要人在环 → 三种介入时机（事前审批/事中确认/事后复核）→ 审批流设计 → 接管与回退 → 反馈闭环（人在环如何反哺模型）→ 责任与可审计 → 常见坑"展开，结尾给面试速答和高频追问清单。

一、为什么 Agent 必须有人在环

1.1 三个绕不开的理由

Agent 之所以不能完全自治，源于三个根本约束。第一是可靠性约束：当前模型的失败率虽然低，但非零，而一旦让它自动执行真实动作（发邮件、转账、删库），一次失误的代价极高，人类审批是把"可控失误"挡在门外的最后一道闸。第二是成本与体验约束：不是所有步骤都值得人介入，人的注意力是稀缺资源，HITL 要解决的问题恰恰是"在哪些节点让人看一眼最划算"。第三是责任与合规约束：医疗、金融、法务这类强监管领域，决策必须有可追责的主体，纯自动化的 Agent 在法律上往往站不住脚。

把这三点合起来就是一句话：人在环不是因为模型不行，而是因为"让模型全权负责"在现实中既不安全也不可追责。HITL 是 Agent 从 Demo 走向生产的必经之路。

可以举一个直观的例子来体会这三重约束为什么同时成立。设想一个自动报销 Agent：它要从发票图片里提取金额、匹配审批规则、最后发起打款。可靠性上，OCR 偶尔会把"8"看成"3"，如果没人复核就直接打款，错误信息会直接变成资金损失；成本上，让人工逐张审全部发票不现实，但让人在"金额异常"时看一眼却很便宜；责任上，一旦错付，公司必须知道是系统误判还是审批人疏漏，否则无法追责也无法改进。同一个 Agent，三重约束同时压下来，HITL 不是可选项，而是架构的硬性组成部分。这也是为什么面试里但凡聊到生产级 Agent，HITL 一定是绕不开的一题。

1.2 HITL 与"全自治"的取舍

面试时这道题的本质是考"边界感"：不是"自治好还是人管好"的二选一，而是"按风险等级分层"——低风险步骤放手让模型跑，高风险步骤强制人工确认。B22 长时任务里讲的"幂等与补偿"也可以和 HITL 配合：即使人确认了一步，执行仍要可回退。

二、三种介入时机

2.1 事前审批（Pre-approval）

事前审批指 Agent 在真正执行动作之前，先把"计划"或"待执行操作"交给人确认。最典型的例子是邮件起草后弹窗"确认发送"，或者数据库变更先生成 SQL 让人 review 再执行。它的优点是失误在发生前就被拦下，代价是每次都要人点一下，吞吐受限。

适用场景是那些"执行后不可逆"或"代价高"的动作，例如对外发消息、写数据库、调用付费 API。设计要点是把审批颗粒度控制得当：太粗（一次确认一大坨）人看不过来，太细（每步都确认）人会被烦死。一般做法是按"动作类型"而非"每步"来设审批，比如"任何写操作都要确认"，但"读操作免确认"。

事前审批还有一个常被忽视的价值：它倒逼 Agent 把"计划"显式化。为了让人在确认前看清要做什么，Agent 必须先生成一份可读的执行计划，这反而提升了整个系统的可解释性——人看到的不是黑盒输出，而是一份可审查的方案。很多团队发现，即便最后人几乎都点"通过"，这个"被迫写计划"的过程本身就让 Agent 的行为更可控、更易于调试。所以事前审批不只是安全闸，也是把 Agent 的推理过程"摊开给人看"的契机。

2.2 事中确认（In-process confirmation）

事中确认发生在 Agent 推理过程中，当模型自身"不确定"或命中某类敏感操作时暂停问人。它与事前审批的区别在于：事前审批是固定流程（不管模型多确定都要确认），事中确认是条件触发（模型自信且低风险就跳过）。

实现上通常结合不确定性估计（呼应 A26 的语义熵）和规则引擎：当某步涉及敏感工具，或模型的置信度低于阈值，就插入一个"人类决策点"。这比原来"每步都问"体验好得多，因为大部分常规路径是静默通过的，只有异常情况才打扰人。

事中确认在工程上比事前审批更考验"该不该打扰人"的判断力。如果触发条件太松（比如只要调用任何工具就问），就退化成每步审批；太紧（只有模型极度不确定才问），又会漏掉那些"模型很自信但其实错了"的情况。一个实用的经验是双条件触发：要么命中"敏感工具白名单"（如支付、删除），要么不确定性估计超过阈值，二者满足其一就暂停。这样既覆盖了"已知危险"，也覆盖了"模型自己都没底"的盲区，比单一规则稳得多。

2.3 事后复核（Post-hoc review）

事后复核不阻断执行，而是让人在动作发生后抽检或全检。适合"失误可逆、影响有限"的场景，比如内容生成后由编辑把关、批量处理任务跑完后再人工抽样。它的优势是几乎不牺牲吞吐，缺陷是失误已经发生了，只能止损不能预防。

工程上常把三种时机组合使用：高频低风险走事后复核，中风险走事中确认，高风险走事前审批。这样一个 Agent 既能保持高吞吐，又把致命失误挡在事前。

三、审批流设计

3.1 审批状态机

审批流本质上是一个状态机，把每个待确认操作从"待审"推到"通过"或"拒绝"。一个最小实现如下：

from enum import Enum class ApprovalState(Enum): PENDING = "pending" # 待人工确认 APPROVED = "approved" # 已通过，可执行 REJECTED = "rejected" # 已拒绝 EXPIRED = "expired" # 超时未处理 def decide(action, risk_level, human_ok): if risk_level == "high" and not human_ok: return ApprovalState.REJECTED # 高风险无确认直接拒 if human_ok: return ApprovalState.APPROVED return ApprovalState.PENDING

这个状态机的价值在于把"人是否确认"变成显式的、可持久化的状态，而不是散落在代码各处的 if-else。结合 B22 的持久化和检查点，即使 Agent 中途崩溃，审批状态也不丢，重启后能继续等人工决策。

这里要特别注意 EXPIRED（超时）状态的设计。现实中人工审批可能几小时甚至几天才处理，而 Agent 不能无限等待。超时策略要根据动作性质定：可逆的读操作超时可直接放行或重试；不可逆的写操作超时则应默认拒绝而非默认通过——因为"没人看"不等于"可以执行"。很多生产事故源于把超时默认设成"放行"，等于在没有人确认的情况下自动执行了高风险动作，HITL 形同虚设。所以状态机里每个转换的默认方向，都是安全性设计的一部分，值得在架构评审时逐条确认。

3.2 审批信息要"让人能决策"

一个常见的失败是：把"是否批准？[是/否]"丢给用户，但用户根本不知道 Agent 要干什么、后果是什么。好的审批界面必须给出足够上下文：要执行的动作、影响范围、预估后果、可撤销性。否则人只能盲点"通过"，HITL 退化成形式主义。

这就要求 Agent 在请求审批时，不能只抛一句"请确认发送邮件"，而要带上"收件人、主题、正文摘要、是否可撤回"等关键信息。换句话说，HITL 的体验好坏，取决于 Agent 的"自我解释"能力——它能把下一步动作讲清楚，人才有能力判断。

四、接管与回退

4.1 什么是接管（Takeover）

接管指当 Agent 陷入困境或执行危险操作时，人类能随时从 Agent 手里夺回控制权。它和审批的区别是：审批是 Agent 主动停下来问，接管是人主动插手（Agent 可能还没停）。接管要求系统支持"热切换"——人类输入的指令优先级高于 Agent 的自动决策。

在长时任务（B22）里，接管尤其重要：一个跑了半小时的 Agent 如果走到错误分支，人应该能中途纠正而不必从头重跑。这需要在架构上把"人类输入通道"作为最高优先级的事件源，任何自动循环在收到人工指令时立即让出控制权。

接管能成立的前提是 Agent 的执行是"可中断"的。如果模型正在一个不可打断的同步调用里（比如一次性提交了十个写操作的事务），人即使想夺权也插不进去。所以支持接管反过来要求 Agent 的每一步动作都足够原子化、可暂停——这又和 B22 的"把长任务拆成可检查点的小步"呼应。可以说，一个好的长时任务架构天然就支持接管，而一个"一把梭"的脚本式 Agent 几乎无法让人中途介入。这也是为什么 HITL 经常和任务拆解、状态机这些工程实践绑定出现，它们本质上是同一套"可控执行"思想的不同的面。

4.2 回退（Rollback）与补偿

即便有人确认，执行仍可能出错，所以必须配套回退机制。回退有两种思路：真回退（如数据库事务回滚、文件版本恢复）和补偿（执行一个反向操作抵消影响，如"已发的邮件撤回"或"已扣的款退回"）。B22 讲的幂等和补偿事务在这里直接复用：每个可变操作都要设计对应的撤销路径。

面试时能把"审批 + 接管 + 回退"串成一条"事前可拦、事中可夺、事后可撤"的链路，会显得你对生产级 Agent 的可靠性有完整认知，而不是只停留在"加个确认按钮"。

五、反馈闭环：人在环如何反哺模型

5.1 人工决策是最贵的标注

人在环产生的每一个"通过/拒绝/修改"，本质都是一条高质量标注：人拒绝了 Agent 的某个动作，等于告诉系统"这一步不该这么做"；人修改了 Agent 的草稿，等于给了一份更好的示范。这些信号如果只用于当次拦截就太浪费了，应该回流进训练与评测。

常见的回流路径有三条。其一进入 SFT 数据：人类修改后的最终版本作为（状态, 好动作）对，用来微调策略。其二进入偏好数据：被拒的动作和被采纳的动作构成 rejected/chosen 对，用于 DPO（呼应 A16、A28）。其三进入评测集：人类拒绝的案例沉淀为回归测试，防止模型下次再犯。

5.2 闭环的飞轮效应

用户反馈(拒/改) -> 沉淀为偏好/SFT 数据 -> 微调策略模型 ^ | | v 评测回归(防止回退) <- 新版本上线 <- 模型变强、误拒下降

这个飞轮是 HITL 最被低估的价值：它不只是"兜底安全"，更是"持续让模型变好"的数据引擎。很多团队一开始上 HITL 是为了防错，跑半年后发现最大的收获是攒出了一堆别处买不到的高质量反馈数据。这也和 A23 数据飞轮、A27 蒸馏数据工程一脉相承——人在环是最高质量的"数据生产线"。

需要提醒一个常见误区：反馈回流不是"把人工修改直接当标签灌进去"就完事。人工修改可能本身有错，也可能只适用于某个特定客户场景，直接全量微调会过拟合到个别案例。稳妥的做法是先把这些反馈沉淀为"候选数据"，经过抽样质检、去重、和分布校验后再进入训练，并且每次用回归测试确认新模型在旧案例上没退步。换句话说，反馈闭环的工程难点不在于"收集"，而在于"清洗与治理"——这和 A23 数据工程讲的是同一件事，只是数据来源从爬虫变成了人在环。

六、责任与可审计

6.1 为什么可审计是合规底线

当 Agent 参与医疗诊断建议、信贷审批、合同审核时，出了问题必须能说清"是谁、基于什么信息、做出了什么决策"。可审计要求系统记录每一步的关键信息：输入上下文、模型输出的中间推理、调用了哪些工具、人工在哪个节点确认了什么。这些日志既是追责依据，也是模型改进的输入。

可审计和 B20 可观测性高度重合：Trace 不仅用于排查故障，也用于还原决策链路。区别在于 HITL 场景下的日志还要额外记录"人类决策点"——谁确认的、何时确认的、确认时看到了什么信息，这是纯技术 Trace 不一定覆盖的。

6.2 责任归属的设计

责任归属要在设计阶段就定清楚，而不是出事后再扯皮。一般原则是：模型自主决策导致的失误，责任在系统提供方；人类在审批节点明确确认的动作，责任在确认人；但如果一个高风险动作根本没走审批（系统 bug），责任仍归提供方。所以"强制高风险动作审批"不仅是安全需要，也是责任隔离需要。

落地时还有一个细节：责任归属要写进产品文案和合同，而不能只停留在内部设计文档。用户需要知道"这个决策是 AI 做出的还是人工确认的"，监管方需要能调取对应的确认记录。把责任设计从"代码逻辑"提升到"业务契约"层面，是 HITL 在金融、医疗这类强监管行业能否真正落地的分水岭。面试官如果问"你怎么做合规"，能答到"责任归属 + 可审计日志 + 业务契约"三层，会比只谈技术实现成熟得多。

七、常见坑与面试陷阱

7.1 把 HITL 做成"每步都问"

最常见的反模式是让 Agent 每走一步都弹确认，结果人成了模型的"人肉回车键"，既没省事又制造疲劳，还会因为疲劳导致"无脑点通过"。正确做法按风险分级，只对真正高代价、不可逆的动作设硬确认。

7.2 审批界面没有上下文

第二个坑是确认弹窗只给"是否批准"，不给人决策所需的信息。这会导致盲确认，HITL 名存实亡。Agent 在请求审批时必须附带动作的影响范围与可撤销性，让人有能力判断。

7.3 反馈只用于当次，不回流

第三个坑是把人工反馈当成一次性拦截，不沉淀进数据与评测。这样模型永远长不大，HITL 退化成纯成本。必须建立反馈回流管道，让每一次人工决策都成为训练与回归的资产。

7.4 忽视回退，确认了也救不回来

第四个坑是只有审批、没有回退：高风险动作确认后一旦出错无法撤销，损失照样发生。确认降低的是"未经审视就执行"的概率，但执行本身的失败仍需回退与补偿来兜底。

八、面试速答 + 高频追问清单

面试速答（60 秒版）

人机协作（HITL）解决的是"Agent 不能完全自治"的可靠性、成本与责任问题。介入时机分三种：事前审批（执行前确认，适合不可逆高风险）、事中确认（模型不确定或命中敏感操作时暂停，条件触发）、事后复核（执行后抽检，适合可逆低频）。审批流用状态机建模（待审/通过/拒绝/超时），关键是给审批人足够上下文让他能决策。接管让人随时夺回控制权，回退与补偿（呼应 B22 幂等）保证出错可救。人在环产生的人工决策是最贵标注，应回流进 SFT/DPO 数据与评测集，形成数据飞轮。可审计记录每一步与人工确认点，是强监管领域的合规底线，也关乎责任归属。核心认知：HITL 不是模型不行的妥协，而是 Agent 上生产的必经架构。

高频追问清单

1. 事前审批、事中确认、事后复核分别适合什么场景？怎么选？
2. 怎么设计审批颗粒度，既不让人疲劳又能控风险？
3. 审批界面应该给 human 哪些信息，他才能有效决策？
4. 接管（takeover）和审批（approval）本质区别是什么？架构上怎么支持热切换？
5. 回退和补偿有什么区别？各举一个适合的例子。
6. 人工反馈怎么回流进模型训练？除了 SFT 还能进哪？
7. HITL 产生的人工修改，为什么是"最贵标注"？飞轮怎么转？
8. 强监管场景下，责任归属怎么设计？审批能免除提供方责任吗？
9. 可审计日志要记哪些字段？和 B20 可观测性的 Trace 有什么不同？
10. 怎么避免"每步都问"导致的盲确认疲劳？分级策略怎么定？