HITL 人工介入的并发难题：两个人同时审批一张证书怎么办

先看官方 Demo 的 HITL 长什么样

LangGraph 的 HITL 机制本身很优雅：interrupt 暂停图执行，状态交给 Checkpointer 持久化。人工决定通过 Command 注入后恢复：

from langgraph.types import interrupt,Command
async def hitl_checkpoint -> dict:
"""Node ：人工最终确认 + 组装结果。"""
if settings.hitl_enabled:
decision = interrupt({
"prompt": f"证书审核人工确认","fields": state.get,"verifications": state.get,"suggestion": state.get。})
...
# 管理员提交决定后恢复执行
state_out = await CERT_REVIEW_GRAPH.ainvoke(
Command,config={"configurable": {"thread_id": thread_id}},)

User Pain Point: 失踪——导致使用者等待无端延迟甚至丢单。

Pitfall 1：MemorySaver 存 HITL 状态。等于把审核单写在便利贴上

这是最容易被轻视的坑，因为它在开发环境永远不会暴露。

• MemeorySaver 把图状态存在进程内存里。
• MemeorySaver 对多副本不友好：
• 1. 滚动更新： 管理员 A 点了"通过"，请求落在副本 X；此时发布新版本，副本 X 被杀。管理员 B 刷新页面——审核单消失，因为状态随进程一起蒸发。
  2. 多副本状态分裂： AI 审核发起的 interrupt 状态存在副本 X，管理员的 resume 请求被负载均衡打到副本 Y ——副本 Y 的 MemorySaver 根本没有这个 thread 的状态。

User Pain Point: 多实例部署下同一条审核单可能被不同实例截取，导致“冲突”或“丢失”。不过，这会让业务负责人担心数据一致性与程序可靠性。

方法 – RedisSaver 与 TTL 延长策略

User Pain Point: 想要让每个线程持久化到共享存储。但又怕 TTL 过期导致长时间未操作就被清除，从而导致使用者 点击失效。其实，需要一种既能保证高可用，又能防止过期误删的方法。

配置示例 – Redis Saver + DB 灾备包装

def build_checkpointer:
"""建立顺序：Redis → RedisD娱乐heckpointer 包装 → MemorySaver 回退。每层都有 fail-open 降级，最终保证返回一个可用 Checkpointer。"""
if settings.checkpointer_backend == "redis":
try这方面，from langgraph.checkpoint.redis import AsyncRedisSaver
ttl = {
"default_ttl": settings.checkpoint_ttl_minutes,# 单位是「分钟」
"refresh_on_read": True。# 读取时续期
}
saver = AsyncRedisSaver
# DB 灾备包装：防止 Redis TTL 过期导致会话中断
if settings.checkpoint_db_fallback:
saver = RedisD娱乐heckpointer
return saver
except Exception as exc:
logger.warning
from langgraph.checkpoint.memory import MemorySaver
return MemorySaver

• `refresh_on_read=True`： 活跃会话每次读取都续期，只清“真的死了”的线程；确保即使使用者长时间不操作，也能保留上下文直到真正放弃。
• `fallback`： Checkpointer 故障不能拖垮整个 AI 服务——宁可退化为单副本可用，而不是全局失败。

Pitfall 2：TTL 不够长导致超时冲突

使用者痛点的观点是，

• A 审核完成后离线一天却因为默认 TTL 已过期而无法继续恢复；B 在同一天重新打开并做决定，程序认为是新线程。 两人其实是在同一条记录上操作却产生冲突。 老实说，

Pitfall 3：谁说了算？竞争条件与乐观锁

使用者痛点的观点是。

• B 点击通过前 A 已经手动更新了一些字段，两人的修改互相覆盖；程序如何判定优先级与合并策略？缺乏统一的决策规则会导致业务数据错误或重复审计记录。

S一句话这方面。HITL 并发冲突的根源在于状态管理的不一致——无论是存储位置、生命周期还是决策者身份，都需要统一且可 地设计，以免出现“谁说了算”的灰区和“数据漂移”问题。实现高可用、低延迟且易维护的 HITL 必须从持久化方案、TTL 策略和冲突解决规则三方面共同考虑。