LangGraph 中状态管理 StateGraph 循环死循环的排查与解决技巧

写 LangGraph 的状态机最怕的就是节点在两个状态之间反复横跳，直接把 Token 烧光。这种死循环通常不是因为逻辑写错了，而是因为 State 里的某个关键字段没有在更新时被正确覆盖，导致条件边（Conditional Edge）判断时始终触发同一个跳转分支。

我最近在做一个多步推理的 Agent，实测发现 Claude 3.5 Sonnet 在处理复杂状态跳转时比 GPT-4o 稳很多，但即便如此，如果 State 定义不严谨，依然会陷入死循环。

排查死循环的几个实测痛点：

1. 状态累加导致的判定失效
很多人习惯用 Annotated[list, operator.add] 来记录对话历史。但如果你在条件边里用 state["history"][-1] 来判断是否需要跳转，而某个节点在出错后只是简单地把错误信息 add 进列表，那么判定逻辑可能会因为没能正确识别“重试次数”而陷入死循环。

2. 节点更新没覆盖旧值
如果你定义状态时没用 operator.add，而是默认覆盖，但节点返回的字典里漏掉了某个关键标志位，条件边读到的就是旧状态，导致它认为任务还没完成。

解决技巧和实测方案：

方案一：引入计数器（Counter）强行截断
这是最粗暴但最有效的办法。在 State 中定义一个 retry_count，每次进入可能死循环的节点就 +1，超过 3 次直接强制跳转到 END。

from typing import TypedDict, Annotated
import operator

class AgentState(TypedDict):
    messages: Annotated[list, operator.add]
    retry_count: int  # 关键：用来记录循环次数

def check_loop(state: AgentState):
    if state["retry_count"] > 3:
        return "fallback"
    return "continue"

方案二：使用特定的“状态快照”进行比对
在节点执行前后记录一个 last_action。如果连续两次执行的 last_action 完全一致，说明模型陷入了复读机模式，此时应该触发提示词强制干预，而不是再次调用模型。

模型能力对比实测：

Claude 3.5 Sonnet：在处理 LangGraph 的条件路由时，对 State 变化捕捉极其敏锐，能够通过 Prompt 意识到自己已经在循环，自我纠偏能力强。
GPT-4o：逻辑能力顶尖，但在长链路的状态机中，容易忽略之前状态的细微变化，更容易在两个节点之间打转，必须依赖强硬的 retry_count 逻辑来兜底。
DeepSeek-V2：性价比极高，但在复杂状态跳转的指令遵循上偶尔会掉链子，建议在条件边写死判定逻辑，不要交给模型决定跳转方向。

总结避坑指南：

不要在条件边里写复杂的逻辑判断，尽量把判断结果在节点内计算好，存入 State 里的一个布尔值字段，条件边只做简单的 if state["is_finished"]: return END。这样排查时只需要打印 State 就能一眼看出哪里卡住了。