大厂 Agent 面试｜什么是 Human-in-the-Loop？用一个订票例子彻底讲明白

Human-in-the-Loop，简称 HITL，通常译为“人在回路”或“人机协同闭环”。

这个名字听起来有些抽象，其实它解决的是一个很实际的问题：

AI 可以自己完成很多步骤，但遇到信息缺失、需要专业判断或必须由人做决定的地方，应该怎样把人接进来，并根据人的反馈继续工作？

本文用一个出差订票助手的例子，从零讲清 HITL 的含义、参与方式、运行过程、适用场景，以及它和普通聊天、人工审批、模型训练的区别。

一、先别背定义：想象你有一个会办事的小助理

你对一个出差助手说：

帮我安排下周二从上海去北京的行程，上午出发，预算 1500 元以内。

它可以自己完成不少事情：理解日期、查询交通方案、比较价格、整理行程。

但查到一半，它发现了几个问题：

• 你说的“上午出发”，能不能接受早上 6 点？

• 一班航班价格合适，但到达机场离会议地点很远，你是否接受？

• 如果没有符合预算的方案，是提高预算，还是改坐高铁？

• 最终准备下单时，是否已经获得了针对这次购买的有效授权？

如果它不问，全部自己猜，就可能订出一个“规则上似乎符合，实际上你不想要”的行程。

如果每点一下搜索按钮都要你批准，你又会觉得：

那我还不如自己订。

HITL 要解决的，就是怎样在自动执行的过程中，把真正需要人的环节交给人，并让人的决定有效地影响接下来的工作。

可以先这样理解：AI 负责推进任务，人在人有必要参与的节点补信息、做判断、改方案或授权。

二、Human、Loop，到底分别指什么？

1. Human：参与者不一定是提出任务的用户

订票时，参与的人可能就是你。

但在企业系统里，参与者还可能是客服、运维工程师、财务人员、业务主管或领域专家。

不同问题应该交给能够回答、并且有资格作出相应决定的人。

所以，HITL 里的“人”是一个工作角色，不只是聊天窗口另一端的那个人。

2. Loop：不是死循环，而是反馈会回到任务里

这里的“回路”，可以理解成一个反馈闭环。

以订票为例：

人的回答没有停留在聊天记录里，而是改变了后面的筛选行为。

这就是“进入回路”的关键。

它不要求人参与每一步，也不要求必须反复问很多轮。一次有效的人类输入，也可以构成任务中的一个 HITL 环节。

三、HITL 不只有“同意”和“拒绝”

很多人第一次接触 HITL，看到的是发送邮件前的确认弹窗，于是把它理解成“让用户点个批准”。

批准确实是一种常见形式，但人还可以以其他方式参与。

下面按订票助手的需求，整理五种容易理解的参与方式。这是方便理解的业务分类，并非某个框架的固定枚举。

LangChain 的工具调用 HITL 中间件提供批准、编辑、拒绝和直接回应等决策方式，可以支持其中一些具体交互；更完整的业务参与流程仍需要应用自己设计。

HITL 的共同点，是人的输入会影响任务如何继续；具体输入不一定是一个批准按钮。

四、一个完整例子：订票助手怎样让人参与？

下面假设我们正在设计一个出差订票助手。票价、时间和页面内容均为教学示例。

第一步：Agent 先完成能够自主完成的工作

用户要求：

下周二从上海去北京，上午出发，预算 1500 元以内。

Agent 可以先查询方案，并整理出：

这些步骤不必因为使用了 HITL，就全部交给用户逐项指挥。

第二步：在会影响选择的位置，提出有价值的问题

Agent 可以问：

你更看重尽早到达，还是减少出行费用？如果有必须到达的时间，也可以告诉我。

用户回答：

下午 3 点前到会议地点就行，我更希望路上能办公。

这个回答提供了两个不同层面的信息：

• “下午 3 点前到会议地点”是需要满足的时间条件。

• “希望路上能办公”是方案排序时需要考虑的偏好。

Agent 接下来应结合车站到会议地点的交通时间，判断高铁方案是否满足要求，而不是看到“办公”两个字就直接选高铁。

第三步：把人的表达转成可以执行的任务条件

用户说了一句话，后台还需要把它变成后续步骤能使用的状态。

例如，系统可以保存：

这里有一个很重要的区别：

“我喜欢这个方案”不一定等于“请立即付款”。

偏好、选择和执行授权应根据上下文分别识别。信息不明确时，系统需要把待确认的事情说清楚。

第四步：在确实需要人的决定时暂停

假设系统选中了符合条件的车次，并且这次购买尚未得到有效授权。

它展示：

已选中方案 C：周二 08:30 出发，票价 660 元，二等座。预计到会议地点的时间满足要求。是否按当前乘车人、车次、席别和价格提交购票？

此时，受这项决定约束的购票动作应处于等待状态。

不是一边问用户，一边已经提交了付款请求。

第五步：根据反馈，进入不同分支

如果用户回复时票价已经变化，系统需要根据原授权范围判断是否还能继续。不能把针对旧方案的决定，随意解释成对任何新方案都有效。

你会发现，这个完整过程里，人参与了补充需求、表达偏好和确认购买三个环节，其他步骤仍然由 Agent 推进。

五、“问了一句话”，就算实现 HITL 了吗？

从广义的人机交互来看，人工澄清可以成为 HITL 的一部分。但在一个需要可靠运行的 Agent 系统里，只在回答中写一句“请确认”，还不够。

可以检查三个方面。

1. 真的在等这个决定吗？

如果页面写着“等待确认”，工具却已经执行完，人的决定就失去了作用。

需要等待的是受该决定约束的步骤。

与之无关、已经获准的其他工作，可以按系统设计继续进行，不一定要冻结整个任务。

2. 回复能准确回到原来的任务吗？

用户可能同时有两个订票任务，一个去北京，一个去深圳。

他点击北京行程的“确认”，系统应该知道这次反馈对应哪一个任务、哪一版方案、哪一个待处理问题。

否则“同意”只是一个没有明确对象的词。

3. 人的输入真的改变了后续行为吗？

用户明确选择高铁，Agent 后续却仍然按照飞机方案执行，就没有正确落实反馈。

因此，一个实用的判断标准是：

该等时能等住，反馈能找到对应任务，后续执行受反馈约束。

六、后台发生了什么？用“游戏存档”理解

用户可能一分钟后回复，也可能第二天才回来。

系统不能把“等人回复”理解成让模型一直生成内容，或者让某个网络请求一直卡在那里。

可以把它想成游戏存档：

• 当前关卡：任务进行到哪一步。

• 已有道具：已经查到哪些资料、形成了什么方案。

• 待选剧情：需要人回答什么问题。

• 玩家选择：人最后给了什么反馈。

通常，应用会把这些内容保存下来，将任务标记为等待人工输入。

用户提交反馈后，应用找到对应任务，验证反馈并更新状态，再安排后续执行。

LangGraph 的中断机制就是一种实现方式：通过检查点保存执行状态，再通过恢复输入继续运行。

这里保存的是应用的任务状态，不是要求把模型“大脑里的所有想法”存下来。

继续执行，是否意味着从暂停的那一行接着跑？

不一定，要看框架的运行语义。

例如，LangGraph 文档说明，恢复后包含中断的节点会从节点开头重新执行；中断前的部分代码可能再次运行。

因此，游戏存档只是帮助理解“保存进度”的类比，不等于所有代码都自动拥有精确到某一行的暂停恢复能力。

在系统设计层面，可以把“准备方案”“请求人工输入”“执行动作”分成职责明确的步骤，让人工决定与实际动作之间的关系更清楚。

七、它和普通聊天、人工审批、模型训练有什么区别？

1. HITL 与普通多轮对话

多轮对话描述的是交互形式：你说一句，系统说一句，可以有很多轮。

HITL 描述的是人对流程的作用：人的输入是不是某个处理环节需要的反馈，并影响后续工作。

多轮对话是“怎么交流”，HITL 关心“交流如何参与决策和执行”。

2. HITL 与人工审批

人工审批重点解决“这件事是否获准执行”。

HITL 还可以解决：

• 信息不够怎么办？

• 哪个方案更符合偏好？

• 结果需要怎样修改？

• 当前问题是否应该由人工接管？

因此，在 Agent 运行过程中，人工审批是 HITL 的一种常见实现。

另外，HITL 也可以用于固定工作流。

例如，系统自动提取发票字段，财务人员修正后再入账。它不一定需要一个会自主规划的 Agent。

3. 运行时 HITL 与模型训练

用户告诉订票助手“以后优先考虑高铁”，并不意味着模型参数当场发生了更新。

当前系统可能只是更新了任务约束，或者在用户允许的情况下保存了一项偏好。

HITL 也可以出现在数据标注、主动学习等机器学习环节。本文讨论的重点，是 Agent 运行时的人类参与。

有人的反馈，不等于已经进行了模型训练；RLHF 也不能直接当作运行时 HITL 的同义词。

八、加上 HITL，Agent 就不够智能了吗？

可以从工作分工的角度看这个问题。

一个靠谱的助理，会自己完成查询、整理和比较；遇到只能由你决定的事情，也会把选项和影响整理好再来问。

他不会因为“没有替你决定个人偏好”就显得不专业。

Agent 同样如此。让人参与，不一定是模型能力不足，也可能是因为：

• 必要信息只有人知道。

• 多种方案都合理，需要人的偏好。

• 决定涉及特定人员的职责与权限。

• 问题超出了当前自动化流程能妥善处理的范围。

真正影响体验的是参与方式。

设计得好的 HITL，会减少人必须亲自做的工作，同时保留人需要作出的决定。

九、什么时候值得引入 HITL？

可以先问三个问题：

并不是每个任务都值得设置人工节点。

例如，格式转换规则已经明确、操作可逆且已获授权，再反复让人确认，可能只会增加等待。

对于必须即时响应的流程，也应明确哪些动作可以按预设规则自动完成，哪些情况需要升级给人处理。

不能假设人随时在线、马上回复。

十、HITL 能带来什么，又解决不了什么？

HITL 可以帮助补全信息、校准偏好、引入专业判断，以及建立执行前的人类控制环节。

但它的有效性取决于设计。

如果用户只看到一句“建议同意”，看不到方案内容；如果审批消息太多，大家习惯性点击；如果人已经拒绝，系统却继续执行，那么“流程里有人”并不能保证效果。

可以从几个实际问题评估这套机制：

“问了多少次人”本身不能说明好坏。

更重要的是：问得是否有必要，问题是否容易回答，回答是否被正确落实。

十一、面试精简总结：一分钟讲清 HITL

Human-in-the-Loop 是把人的输入、判断或授权接入自动化流程的一种方式。在 Agent 场景下，系统先自主完成能够确定的步骤，遇到缺失信息、需要人工判断或授权的节点，再请求人参与，并根据反馈继续执行、修改方案、停止任务或转人工处理。

它不只是审批弹窗，还包括澄清需求、选择方案、修正结果和处理例外。工程上，需要保存任务状态，让反馈关联到正确的任务和待处理事项，并确保人的决定真正影响后续执行。

HITL 可以通过聊天，也可以通过审核页面完成；它也不等于模型训练。设计目标是在必要的地方引入人的判断，让自动化效率和人的控制能力相互配合。

一句话记忆：Agent 先推进任务，在需要人的节点接入反馈，再带着这个反馈继续工作。