FDE W4D4 学习手册 · HITL 与中断恢复

W4 Day4 · A 级（必须掌握，面试核心）· 4h · 学会用 LangGraph 把"人有最终否决权"落到可恢复、可重试、可审计的工程系统里

一、HITL 的本质：为什么 Agent 需要"人兜底"

Human-in-the-Loop（人在回路）指在 Agent 自主执行流程中，把部分高风险决策节点交回给人确认/修改/驳回，人拥有最终否决权。它和"纯人工流程""纯自动流程"都不同：Agent 跑大部分步骤，只在关键闸门等人。

1.1 为什么必须 HITL

• 高风险动作不可逆：特药理赔一旦放款，追回成本极高；用药建议错误可能危害生命健康。
• 模型不确定性：LLM 有幻觉、边界模糊，对"是否合规"这类判断需要人类专家拍板。
• 合规与审计：医保/保险监管要求"谁决策、谁负责"，必须有可审计的人工节点。
• 异常处理兜底：低置信度、规则冲突、知识库缺失时转人工，而非硬猜。

1.2 HITL 的三种形态

二、LangGraph Checkpointer：状态持久化基础

LangGraph 的图是有状态的（StateGraph），每执行一个节点都会产生状态变更。Checkpointer 就是把这个状态快照持久化到外部存储（如 PostgreSQL）的机制，让图可以"暂停、断线、再恢复"。

2.1 核心概念

• Thread：一次对话/任务的唯一标识（thread_id），所有状态快照按它组织。
• Checkpoint：某一时刻的完整状态快照（包含 messages、自定义 state 字段、待执行节点等）。
• Checkpointer 后端：MemorySaver（内存，开发用）、PostgresSaver（生产用）、SqliteSaver 等。
• pending writes：中断时"已决定要做、但尚未提交"的写操作，恢复时重放。

2.2 为什么 HITL 必须依赖 Checkpointer

没有 Checkpointer，进程一停状态就没了，无法恢复；有了它，中断只是"不继续执行下个节点"，状态已安全落库。

三、Interrupt：精确暂停与恢复

LangGraph 提供 interrupt()（配合 @node 使用）让节点在执行到某行时主动暂停并把控制权交还调用方，同时保存上下文。恢复时从断点继续，不会重跑已完成的节点。

3.1 工作机制

from langgraph.types import interrupt, Command

def approval_node(state):
    # ... 模型已生成建议赔付金额 ...
    decision = interrupt({
        "type": "human_approval",
        "payload": {"claim_id": state["claim_id"],
                    "amount": state["suggested_amount"],
                    "reason": state["reason"]}
    })
    # 恢复后，decision 就是人返回的结果（通过/驳回/修改）
    state["approval"] = decision
    return state

3.2 暂停 vs 恢复

3.3 与"普通异常"的区别

• interrupt：受控暂停，状态已保存，可恢复，是设计内的流程控制。
• 异常/崩溃：未受控，状态可能不一致，需靠重试/幂等恢复。

四、人工审批触发：什么时机、什么条件下停下

触发人工审批是 HITL 的"闸门设计"，目标是只在必要且高价值处拦截，而非无差别拦截。

4.1 触发策略（按风险分层）

4.2 触发信号来源

• 模型自评置信度：logits/概率或显式 confidence 字段。
• 规则引擎：命中"黑名单药品""超额赔付"等业务规则直接拦截。
• 知识库缺失：RAG 检索无高相关结果，无法支撑结论。
• 工具调用风险等级：调用"放款""外发"类工具前必拦截。

五、审批通过与驳回：状态如何回流

人给出决定后，通过 Command(resume=...) 把结果送回图，断点节点拿到决定继续。

5.1 通过的回流

• 审批字段写入 state：approval = "approved"、审批人、时间戳。
• 流程继续到"执行动作"节点（如调用赔付接口、生成通知书）。
• 下游节点读取审批结果，确保只在 approved 时产生副作用。

5.2 驳回的处理

• 审批结果 approval = "rejected" + 驳回原因。
• 不走"执行动作"节点，转入驳回分支：通知用户、记录原因、可选转人工坐席。
• 不得重复触发同一审批（用幂等键/状态标记防重）。

5.3 代码结构示意

def execute_node(state):
    if state["approval"]["decision"] != "approved":
        return {"status": "rejected", "reason": state["approval"]["reason"]}
    # 仅在 approved 且幂等键未消费时执行副作用
    if not ledger.mark_consumed(state["claim_id"], state["idempotency_key"]):
        return {"status": "already_done"}
    payout.call(claim_id=state["claim_id"], amount=state["amount"])
    return {"status": "paid"}

六、人工状态修改与回写

HITL 不只是"同意/拒绝"，人常需修改中间结果（如把模型算的赔付额从 8 万改成 5 万，并补充材料）。这要求状态可被安全地"回写后继续"。

6.1 修改的两种路径

6.2 回写后的继续

• 修改写回 Checkpoint 后，再 invoke 即可从当前状态继续。
• 下游节点应读取最新 state，而非缓存旧值。
• 每次修改都应记录"谁、何时、改了什么"，形成审计轨迹。

七、异常重试与恢复一致性

恢复执行时可能发生网络超时、工具失败、模型报错。需要分层重试策略，且每次重试都基于已落库的状态，避免状态漂移。

7.1 重试分层

7.2 一致性要点

• 重试必须在同一 thread_id 下，复用同一快照。
• 所有重试要记 Trace（次数、原因），用于成本归因。
• 重试不能放大副作用——靠幂等键保证"重试 N 次也只生效一次"。

八、幂等键：保证副作用"只发生一次"

幂等（Idempotency）指同一操作执行一次和多次效果相同。在 HITL 恢复里，放款、外发、写库这类副作用必须幂等，否则"重试/重复恢复"会导致二次放款。

8.1 幂等键设计

# 每次"提交审批结果 + 执行动作"用全局唯一 idempotency_key
key = f"{claim_id}:{approval_id}"   # 或由客户端/审批系统生成
if ledger.mark_consumed(claim_id, key):
    payout.call(claim_id, amount)   # 首次：执行
else:
    return {"status": "already_done"}  # 重复：直接返回成功，不重复执行

8.2 关键点

• 键的粒度：到"一次具体动作"（如某次审批对应的放款），而非整个任务，避免误吞合法二次操作。
• 存储：幂等表用唯一索引（claim_id, key），并发抢注，只一个成功。
• 有效期：键可设 TTL，过期允许重新发起（但需谨慎，避免绕过审批）。

九、最大执行时间：防止挂起与失控

Agent 可能因循环、等待人工过久、工具卡死而"永远跑不完"。最大执行时间（超时/步数上限）是兜底安全网。

9.1 多个时间维度

9.2 超时的处理

• 单步超时 → 退避重试或降级。
• 步数超限 → 判定异常，转人工/告警，记录原因。
• 审批超时 → 自动驳回或升级到更高权限/值班人。

十、特药理赔 Agent 的 HITL 落地示例

10.1 流程图（关键节点）

接收申请 → 材料抽取(LLM) → 知识库校验(用药合规/医保目录)
   → 规则引擎(金额/黑名单) → [高风险?] --是--> interrupt(人工审批)
                                      --否--> 自动通过
   人工审批: 通过/驳回/修改金额
   → 执行放款(幂等键保护) → 生成通知书 → 结束

10.2 一次完整 HITL 会话

1. thread_id=claim_10086 首次 invoke，跑到"人工审批"节点 interrupt，返回待审信息（金额 8 万、用药合规、置信度 0.92）。
2. 状态快照落 PostgreSQL，释放计算资源。
3. 理赔专家在后台看到待审，把金额改为 5 万（超出目录限额部分不赔）并点"通过"。
4. 系统用 Command(resume={"decision":"approved","amount":50000}) + 同 thread_id 恢复。
5. 执行节点校验幂等键 claim_10086:approval_77 未消费 → 放款 5 万 → 标记已消费。
6. 若此时因网络重试了一次恢复调用，幂等键已消费，直接返回"已处理"，不会二次放款。

十一、可靠性保证四件套总结

十二、面试达标线①：HITL 在 LangGraph 里怎么用 Checkpointer + Interrupt 实现

十三、面试达标线②：中断恢复 / 幂等键 / 最大执行时间如何保证可靠性

1. 中断恢复：Checkpointer 把状态快照落库，interrupt 在断点暂停；恢复时读快照从断点续跑，不重跑已完成节点，省 token 且避免重复副作用。
2. 幂等键：每次"审批+执行"用唯一键，落幂等表唯一索引抢注；只有首次执行放款，重复恢复/重试直接返回已处理，杜绝二次放款。
3. 最大执行时间：分层超时（单步 LLM/工具、总步数上限、审批超时），把"失控"转为"可控失败（转人工/告警/升级）"，防循环与挂起。
4. 三者配合：Checkpointer 给状态锚点，Interrupt 给流程控制，幂等键给副作用安全，超时给兜底，共同构成医疗级可靠 Agent。

十四、W4D4 自测清单

十五、高频面试题速记卡