如何在 Agent 系统中设计 Human-in-the-loop 人工介入能力？
未标记
考查重点：暂停状态与人工决策恢复。缺信息、重要冲突或高影响动作前暂停，持久化待确认状态，人核具体对象后回写决策并恢复，权限与审计独立
本题目录
参考答案
核心回答
HITL 是在 Agent 的任务流程里设置可暂停、可审查、可恢复的人工决策点。我会先确定哪些情况需要人参与：缺少关键业务信息、方案需要用户选择、结果存在重要冲突，或者即将执行需要明确确认的操作。
触发后，后端保存任务状态和待处理请求，向界面展示要补充的信息、待审方案或具体操作；用户可以补充、修改、批准、拒绝或取消。服务端验证回复者和请求版本，把结果写回对应任务，再从合法的下一步继续，不能只把“同意”当成一条普通聊天消息。
例如生成研究报告，先让用户确认或修改大纲，再开始资料收集；若是发送报告，则应展示收件人和内容，并把确认绑定到这次发送。等待期间可以释放执行资源，断线后仍能查到待处理状态，重复提交也不能导致重复发送。
展开说明
1. 按业务需要触发，避免每一步都打断
需要区分三类介入：补充信息、审阅内容和授权动作。缺失收件人应补问，报告大纲可编辑，发送或其他需要确认的动作则按策略审查。模型可以识别不确定性并提出请求，明确的权限与业务规则应由服务端实施。
触发条件要考虑影响范围、可恢复性、现有授权和证据是否充分。低风险且已授权的稳定步骤可以直接执行；不能靠模型自报一个置信度，就决定全部高风险操作是否放行。Spec 提前明确需求可以减少反复补问，但不会消除运行期间的数据变化和必要确认。
2. 把等待人处理作为明确状态
一种简单流转是：执行中 → 等待人工 → 已收到有效决定 → 继续执行；拒绝、超时和取消各有自己的分支。“等待人工”应有任务 ID、请求 ID、状态版本、介入原因、所需输入或待执行参数，以及允许的响应类型。
界面收到等待事件后展示表单或方案，提交时携带对应请求标识。后端状态才是事实来源：刷新页面或重新连接后重新查询待处理项，不能因为一次推送丢失就让任务永久卡住，也不必让原连接一直阻塞。等待期间，依赖这项决定的步骤暂停；独立且允许继续的工作可以另行安排。
3. 回复必须对应仍有效的动作
服务端验证真实用户、租户、审核权限、请求是否仍在等待，以及参数和版本是否与展示内容一致。修改了收件人、金额或数据范围后，应重新检查业务规则；重要条件变化时，旧确认不能继续授权新方案。
同一请求的重复回复应返回已处理结果，两个并发决定只能有一个合法地推进状态。请求被取消、过期或被新方案替代后，迟到回复应明确告知失效。审核通过也不能绕过业务系统的资源权限，最终执行时仍要检查当前状态。
4. 在 LangGraph 中怎样实现？
可以在审核节点调用 interrupt(...)，把可序列化的待审内容返回图外；配置 checkpointer 和稳定的 thread_id 保存状态。收到有效人工输入后，用同一个线程上的 Command(resume=...) 恢复，节点把结果写回状态并进入相应分支。需要跨进程、重启后继续等待时，应选择持久化存储，InMemorySaver 适合进程内示例。
动态中断恢复时，包含 interrupt 的节点会从函数开头重新执行，不能理解为程序指针直接跳到暂停的下一行。审核节点宜只做可重复的准备工作，真实外部操作放到批准之后的独立节点；执行节点本身仍需幂等或结果核对，防止恢复和重试重复产生副作用。
LangChain 的 HITL 中间件适合按工具策略审查调用。它支持批准、编辑、拒绝等决定；人工直接回答提问与批准真实工具执行含义不同，不能把拒绝包装成工具已执行成功。
5. 记录决定与实际执行结果
保留触发原因、展示方案、审核主体、决定、修改内容、状态版本及后续业务回执，才能解释是谁批准了什么、最后是否真的执行。人工输入应校验格式与业务约束，关键修改使旧计算失效时，应重算相关步骤。
衡量效果可以看必要介入是否被触发、无效打断次数、等待时长、恢复成功率和重复执行情况。人工介入率低未必更好，还要看任务质量与错误影响；长时间无人回复时，应按业务规则提醒、结束或转人工队列，不能默认批准。
常见追问
前端有一个确认弹窗就够了吗？
不够。弹窗只是交互入口，还需要持久化待处理项、回复鉴权、请求与版本匹配，以及可恢复的后端状态。刷新、断线、重复点击和执行失败都要有确定结果。
用户改了大纲，旧搜索结果还能用吗？
可复用仍与新问题、范围和版本一致的证据；失去依据的分析或结论应标记失效并重新执行相关步骤。人工修改不是简单覆盖一个字段后继续使用所有旧产物。
人工拒绝后，Agent 能不能换个工具执行？
应先理解拒绝范围。若拒绝的是这个业务动作，换工具不能绕过它；若只是参数不合适，可以按反馈形成新方案。拒绝内容和适用范围要进入任务状态，避免循环申请同一个已被拒绝的操作。
RagentJava Agent
基于 RagentRagent 把人工确认接在 AgentScope 的工具执行环节：模型提出调用，运行时判断是否需要确认；需要时保存待执行状态，用户决定后再继续同一会话。 知识检索与业务操作由 ReAct 循环选择，写操作不靠提示词里的“请先询问用户”来约束。
怎样暂停和继续
工具目录结合管理端配置与 MCP 的 readOnlyHint 决定确认要求：显式配置确认，或工具没有明确声明只读，都会要求确认。框架将调用标记为 ASKING，页面展示工具及参数，服务端保存待确认消息；Agent 状态通过 PostgreSQL 保存。
用户提交 conversationId、messageId 和同意或拒绝。后端核对用户、会话及待确认状态，再从 Agent 状态取回原始工具调用，构造 ConfirmResult 续跑；前端不能在确认请求里替换工具参数。已经处理或失效的卡片会被拒绝。这里支持同意、拒绝，修改方案需要重新形成调用，不等于任意编辑参数后直接执行。确认与续跑实现。
确认之后仍要检查什么
以仓库中的比特严选 apply_after_sale 为例，用户确认订单、商品、售后类型和原因；执行时工具仍按当前用户查询订单，校验签收状态和受理时间窗，检查同一订单同一商品是否已有未结售后单，并借助唯一约束拦截并发重复申请。成功回执只表示售后单已提交、待人工审核，不能说已经退款或完成换货。售后申请工具。
人工确认也不自动解决外部写操作的幂等：远程调用超时后，仍需根据业务回执核对结果，不能盲目重新生成一次售后申请。这个边界决定了确认负责表达意愿，业务服务负责最终校验与执行。
对应教程
- LangGraph 高级特性：人工介入章节说明 checkpoint、
interrupt与Command(resume=...)如何配合，并解释节点重执行与副作用处理；界面、审核权限和请求生命周期需要在应用层补齐。
参考资料
- 国内：JavaGuide：AI 可观测性：借鉴等待审批、恢复关联与回执记录的组织，说明正文中人工介入需要保存任务、请求版本和后续执行证据。
- 国内：zero2Agent：HITL 交互链路：参考大纲编辑的暂停、展示、提交和恢复链路，组织正文中人工输入与后台任务状态的衔接。
- 国内：WeThinkIn：权限与人工审批：解释审核主体、动作参数、版本和有效期的绑定，说明人工确认与业务权限的配合。
- 国外：LangGraph：Interrupts：说明状态保存、相同线程恢复及节点重执行规则，是处理中断与副作用的依据。
- 国外：LangChain：HITL 中间件：依据按工具策略发起审查及批准、编辑、拒绝的语义，说明正文中 HITL 中间件的适用范围和人工回答与真实执行的区别。
- 国内：Ragent：固定版本工具确认与业务执行：项目答法据此说明待确认状态校验、从服务端取原始调用，以及同意或拒绝后的续跑；工具目录与比特严选售后工具分别支持确认触发条件和执行期业务校验。
DifyPython
基于 Dify核心回答
在 Dify 中，可以用人工输入节点把工作流分成“准备内容、等待人处理、根据决定继续执行”三段。节点展示上游草稿和待填字段，后端保存表单与运行现场；用户提交有效输入后，服务端记录选择和修改内容，再投递恢复任务，让后续节点读取这些结果并走对应分支。
这里需要区分表单已提交、工作流已恢复、业务动作已完成。表单状态检查能阻止重复提交，暂停记录能限制重复恢复，但都不直接保证下游接口只执行一次。
介入点怎样设置，输入输出是什么
适合介入的位置包括缺少必要字段、需要审阅模型草稿，以及执行外部写入之前。以一个工作流配置示例说明：模型生成草稿后进入人工输入节点，展示草稿并允许修改，提供“确认”和“退回”两个动作；确认后将修改内容交给下一节点，退回则进入另一条处理分支。
Dify 的人工输入回调会用变量池渲染表单内容、解析默认值，并把表单关联到节点及本次运行。尚未提交时返回 PauseRequested；恢复后读取保存的提交值，构造节点输出，并以所选动作的标识作为 selected_handle。因此后续分支消费的是明确的字段和动作，而非从一句聊天中的“同意”猜测意图。表单创建与恢复输出。
等待期间保存什么
当前 Python 后端通过 Flask 提供接口，由 Graphon 执行图。收到暂停事件时，WorkflowRunAgg 将运行参数、序列化的 RuntimeState、累计耗时和响应流过滤状态组织成 WorkflowResumptionContext，保存未完成节点及运行状态；暂停上下文写入配置的存储，数据库中的 WorkflowPause 记录其存储键及暂停原因。暂停现场保存、暂停记录持久化。
这样人工处理可以与原来那次请求分开，恢复时按运行记录找回现场，无需让用户重新提交原始任务。它也不是在服务进程中一直阻塞等待一个输入框。
提交以后怎样继续
服务端先检查表单是否仍可提交、有无过期，再校验动作和输入字段。mark_submitted() 在事务内锁住表单行，只允许从 WAITING 变为 SUBMITTED，同时保存动作、输入、提交者及时间；并发或重复提交会收到已处理错误。提交校验与调度、表单状态原子更新。
对于运行中的人工输入表单，服务随后按 workflow_run_id 投递 Celery 恢复任务。消费者读取暂停上下文，用 RuntimeState.from_snapshot() 重建运行现场；在带行锁的恢复事务中检查运行仍为 PAUSED、未请求停止、暂停记录匹配且尚未恢复，再标记为运行中，调用对应的工作流或对话流恢复入口。恢复任务、恢复状态转换。
取舍与重复执行边界
人工输入节点让等待、表单和分支成为明确流程，代价是要处理过期、恢复失败和业务结果跟踪。当前提交表单与投递恢复任务之间存在失败窗口：enqueue_resume() 捕获入队异常后只记录日志，表单可能已经提交而工作流还没继续，不能仅凭提交接口成功就显示业务办理完成。
若接入发邮件、创建订单等写入工具，可在业务侧增加动作标识、幂等处理和回执核对，并为已提交但未继续的运行设计补偿入口。这些需要结合具体业务实现；已有的表单防重与恢复状态转换，不能代替业务动作的防重复执行。
参考资料
- 国内：JavaGuide：AI 可观测性：参考长时间等待可以分成多段执行、用运行标识关联暂停与恢复的解释。
- 国内：zero2Agent：HITL 交互链路：参考暂停后展示草稿、提交修改、继续处理的交互组织；具体恢复机制按本文的
Dify实现展开。 - 国内：WeThinkIn：工具权限、沙箱和人工审批如何协同：参考人工确认绑定具体动作、最终结果仍需业务回执验证的区别。
- 国内：Spring AI Alibaba：人类反馈：参考预设介入点、回写人工输入、再按反馈分支的设计；其框架接口不用于
Dify。 - 国外：LangGraph：Interrupts：参考持久化运行现场与恢复输入的职责划分；
Dify使用自己的表单、暂停记录与恢复入口。 - 国外：LangChain：Human-in-the-loop：参考批准、编辑、拒绝和直接回答的语义差异，帮助区分人工输入与真正执行工具。
相关面经
6 篇
小红书
Agent 开发工程师工具调用里的用户确认，也就是 human-in-the-loop 是怎么做的？
理想汽车
IT全栈交付培养生你说 ai-pipeline 这个流程中人只需要在关键节点做决策, 那你这个关键节点怎么定义? 它会给你发消息? 还是停下来? 还是怎么样? 这里是怎么设计的. (ai-pipeline 流程: analyze (analyze_code, analyze_doc) --> inject --> generate --> lint --> review_loop (含fix) --> final_report)
药明康德
AI 数据HITL人工介入，中断之后如何恢复？
袋鼠云
前端开发工程师讲讲你项目里Human in loop人工干预机制。
公司未注明
Agent 岗位Human in the loop是怎么设计的
展开剩余 1 篇面经
字节跳动
后端开发工程师设计题：如果要支持人工介入（human in the loop）能力，你会怎么设计？
