【随笔】AI Agent怎样等待人工确认：从任务暂停到可靠恢复

上一篇讨论了Agent如何管理记忆避免把过期记录直接当成当前事实。接下来沿着任务流程往前走一步当Agent已经准备好一个操作但需要人确认时这段任务应该停在哪里用户过了半小时回来系统又该从哪里继续Human-in-the-loopHITL常被理解成一个“确认”按钮。真正落到后端按钮只是入口后面还连着待审核内容、任务状态、审批记录与执行结果。把这些关系理清Agent才能既说明自己在等待什么也能在收到答复后继续做对的事。本文围绕Agent工作流的人工介入机制展开参考2026年9月26日核对的LangGraph官方文档。后面的完整教学示例使用Python 3.11及以上标准库不依赖模型服务也不代表完整生产审批系统。一、先把待确认的动作说清楚假设Agent为一个开发工具准备了配置变更。面向用户的确认页面至少应展示目标环境、变更内容、影响范围和本次请求编号。只展示“是否继续”用户很难判断自己究竟同意了哪一步。在后端可以先生成一个提案{request_id:review-001,action_id:change-001,revision:1,target:demo-service,change:{log_level:INFO},status:waiting}这里的服务名和变更只是演示数据。request_id定位一次审核action_id定位一次待执行动作revision标识本次内容版本。三个字段承担不同职责不必挤进一个含糊的“任务ID”。如果用户修改了配置后端应生成新版本或明确记录修改后的提案再让执行环节读取对应版本。审批的是哪份内容需要在数据上说得清。二、暂停流程时保存什么图中学习猫递交提案导师猫核对内容和版本。被确认的卡片才进入后面的执行步骤仍在修改的内容应继续留在审核阶段。可以把流程拆成五个职责清晰的环节环节保存或处理的内容作用准备提案动作参数、版本、说明确定待确认对象进入等待当前状态、请求编号让任务可以暂停接收决定审核人、选择、对应版本绑定答复与提案执行动作业务校验、执行标识落实已允许的操作记录结果成功、失败或待核查为重试和后续查询提供依据等待期间不需要一直占着一个请求连接。前端可以展示“等待确认”后端持久化任务记录。收到答复后再发起一次恢复请求。这种方式也便于处理浏览器关闭、服务重启或用户延迟回复。三、LangGraph提供了怎样的暂停入口LangGraph的interrupt用于向调用方提出外部输入需求恢复时传入Command(resume…)。需要配置checkpointer并使用稳定的thread_id定位同一条执行记录。官方特别说明恢复时会从包含interrupt的节点起点重新执行因此interrupt之前的代码可能再次运行。官方Interrupts文档下面只是接口关系片段省略了State类型、图的构建和checkpointer配置不能单独运行fromlanggraph.typesimportCommand,interruptdefreview_node(state):decisioninterrupt({proposal:state[proposal]})return{decision:decision}config{configurable:{thread_id:demo-review-001}}# graph已构建并已编译配置checkpointerfirst_resultgraph.invoke(initial_state,configconfig)resumed_resultgraph.invoke(Command(resume{approved:True,revision:1}),configconfig,)工作流框架负责暂停与恢复的机制谁有权批准、答复是否过期、动作参数是否已经变动仍需要应用自己的校验。thread_id也只是定位状态的标识不应被当成访问权限凭证。四、恢复时最容易忽略的是重复执行如果一次恢复请求超时前端可能重发工作进程中断后后台也可能重试。此时要区分两个问题任务能否继续以及业务动作会不会多执行一次。一个实用做法是给动作分配稳定的幂等键并在业务执行端核对已有结果。重复请求可以返回已记录的结果不再重复产生副作用。图中的执行记录表达这种去重职责。但“先检查记录、执行远程操作、再写成功记录”仍存在间隙远程操作完成后本地进程可能还没来得及保存结果。对于真实系统需要结合下游幂等接口、数据库唯一约束、事务或消息方案处理这类间隙。一个内存set无法替代这些保证。五、完整示例校验版本并拦住重复确认下面用一个内存状态机模拟配置审核。它没有调用真实服务所谓执行只是在本进程中追加一条演示记录。重点是观察过期确认、正常确认和重复确认如何走向不同结果。fromdataclassesimportdataclass,fielddataclassclassReviewTask:action_id:strrevision:intstatus:strwaitingapplied:list[str]field(default_factorylist)defresume(task:ReviewTask,approved:bool,revision:int)-str:ifrevision!task.revision:return内容版本已变化请重新确认iftask.statusdone:return已处理返回已有结果iftask.status!waiting:return任务已结束不再执行ifnotapproved:task.statusrejectedreturn已拒绝未执行# 仅模拟本进程中的动作记录不调用真实业务服务。task.applied.append(task.action_id)task.statusdonereturn确认通过完成模拟动作taskReviewTask(action_idchange-001,revision2)print(resume(task,approvedTrue,revision1))print(resume(task,approvedTrue,revision2))print(resume(task,approvedTrue,revision2))print(f模拟动作次数{len(task.applied)})rejectedReviewTask(action_idchange-002,revision1)print(resume(rejected,approvedFalse,revision1))保存为review_demo.py后执行python review_demo.py输出内容版本已变化请重新确认 确认通过完成模拟动作 已处理返回已有结果 模拟动作次数1 已拒绝未执行这个例子按顺序执行没有数据库、并发请求、鉴权、崩溃恢复或外部副作用。它帮助说明状态转移的基本关系不能据此宣称实现了分布式“恰好执行一次”。迁移到服务端时可将waiting到executing的转换做成带版本条件的数据库更新并明确只有拿到转换结果的执行者可以继续。随后再结合业务执行端的幂等能力和结果核查处理跨进程与跨系统的问题。六、哪些地方适合放人工介入内容已经足够具体时。Agent先把提案整理到可审核的程度再请求确认。让用户面对一份清楚的变更比反复确认抽象意图更有效。动作即将越过业务边界时。例如从生成配置建议进入应用配置从整理草稿进入对外发送。是否需要审核取决于产品规则和已有授权避免所有读取动作都弹一次确认框。关键信息不足时。当目标环境、参数含义或内容版本不明确可以先暂停收集信息再重新生成提案。不要把缺失信息偷偷补成默认值后执行。恢复请求需要再次校验时。批准发生在过去执行发生在现在。权限、资源状态和提案有效期可能已经变化后端应按当前业务条件检查。七、 思维导图Agent人工介入明确提案动作与参数版本与请求编号暂停与恢复interruptcheckpoint与thread_idCommand resume业务校验权限与有效期确认对应版本可靠执行节点可能重跑幂等与结果记录异常后核查八、总结总结要点人工介入需要绑定具体内容。用户应看到自己确认的目标、参数和版本后端也应保存对应关系让答复能够被准确解释。状态恢复让任务可以跨请求继续。应用仍需校验权限和业务条件并考虑恢复过程中节点再次执行的情况。幂等与核查关系到实际执行结果。教学状态机能解释基本过程面对远程调用与故障重试还需要持久化记录、原子状态转换和下游配合。后续预告下一篇新兴技术随笔聊聊Agent如何使用沙箱让工具执行拥有清楚的工作目录、资源限制与结果回收路径。如果你觉得这篇文章对你有所帮助欢迎点赞、收藏、分享