Agent 如何设计 Human-in-the-Loop 审批、中断与可恢复执行？

面试时怎么答

把 Human-in-the-Loop 讲成可持久化状态机，会比“弹窗让人确认”更完整。高风险节点保存检查点并生成带权限、有效期和操作摘要的审批请求；恢复时用幂等令牌，并重新校验外部状态。追问拒绝、超时或进程重启时，要给出明确分支，不能让任务一直阻塞。

可以这样答：

Human-in-the-Loop 应当建模为任务状态，而不是让进程同步等待。Agent 到达高风险节点后保存检查点，生成包含操作对象、参数、权限范围和有效期的审批请求；批准后用幂等令牌恢复，拒绝或超时进入明确终态。恢复前还要重新校验账户、金额等外部状态，防止审批期间条件已经变化。

核心回答

Human-in-the-Loop 不是在对话里简单询问“是否继续”，而是把审批建模为可持久化状态：Agent 在高风险节点生成审批请求，保存检查点并中断；人可以批准、拒绝或修改参数；执行器用同一个任务标识从检查点恢复，并记录最终决策。审批应尽量放在副作用发生前，尤其是付款、删除、权限变更、外部发送和生产写入。

可恢复执行的关键是把“模型决定做什么”和“副作用是否已经提交”分开。恢复时中断节点之前的代码可能重新运行，因此外部操作需要幂等键、操作状态查询或事务性 Outbox，不能仅依赖进程内布尔值防重复。

展开说明

审批对象应包含可理解的动作、目标资源、关键参数、风险、数据去向和过期时间。用户批准的是这份确定的请求；如果恢复前参数、工具版本或目标已变化，应使旧审批失效并重新确认，不能把“批准发送 10 元”复用于“发送 1000 元”。

不同风险采用不同交互：低风险可记录后自动执行；中风险单人确认；高风险需要双人审批、强认证或只生成草稿。拒绝也应是正常状态转换，Agent 可以选择安全替代方案，但不得通过改写同一动作来规避审批规则。

中断可能持续数小时或数天，所以状态必须存储在持久化 Checkpointer，而不是绑定某个 Worker 内存。恢复入口要验证审批者身份和任务租户，并处理超时、撤销、重复点击及并发审批。

工程实践

使用稳定 Task/Thread ID 保存状态，审批请求带内容哈希和版本。副作用工具接受幂等键，并提供按操作 ID 查询结果的接口；执行前再次核对授权和资源当前状态。审计日志关联提议者、审批者、模型版本、工具参数、检查点和执行结果。测试进程崩溃、批准后重试、拒绝、超时、参数修改和两个审批者竞态。

常见追问

为什么审批最好发生在工具调用前？ 调用后再询问无法撤销已经发生的外部副作用，只能用于告知或补救。
恢复为什么可能重复执行代码？ 持久化工作流通常从某个节点或检查点重放，节点内非幂等副作用若无保护就会再次发生。
批准后参数改变怎么办？ 用内容哈希或版本让原审批失效，对变化后的动作重新展示并确认。
所有工具都需要人工审批吗？ 不需要，应按数据敏感性、可逆性和影响范围分级，避免过度审批让用户机械点击。

一句话复习

Human-in-the-Loop 要把审批变成带版本的持久化状态，并用幂等副作用和审计链保证中断恢复既安全又不重复执行。

参考资料

LangGraph：Interrupts