用LangGraph搭的多Agent协作，任务一多就互相死等，怎么排查？

大概率是图结构里循环边没配interrupt或条件出口，导致节点永远在等对方状态更新，先检查状态快照和节点触发条件。

之前也踩过这坑，后来给关键边加了显式超时和死锁检测，或者把共享状态改成显式传递才解决。

遇到过，而且比你更惨，我是三个子agent互相等，最后发现是共享state里有个字段被两个节点同时写了，但LangGraph的supervisor模式不会主动做锁，导致一个节点以为写完了，另一个节点读到的还是旧值，整个图就卡在条件判断那了。你现在这个情况，我建议先别急着怀疑框架，把你那个“主管”节点的输出日志打全，看它最后发出去的message到底带没带路由信息，很多时候是A节点其实已经返回了，但B节点订阅的channel没对上，消息就丢了。排查死等有个笨办法，就是给每个节点加超时和强制跳转，比如在config里设置recursion_limit，或者用interrupt_before/after在关键节点前插桩，这样至少能知道卡在哪两个节点之间。另外你提到“互相等待”，我猜你是不是在子图里用了send语法去主动触发其他节点？LangGraph的send是fire-and-forget的，如果你在send之后还等着那个节点把结果写回同一个state key，那大概率会死锁，因为那个key的写入时机根本不受你控制。我后来改成把所有子agent的中间结果都塞进一个list字段，用append而不是覆盖，然后在主管节点里做聚合，才勉强绕过去。不过说实话，如果业务流复杂到A和B确实需要环状依赖，不如直接拆成两个独立的图，用消息队列做异步通信，比在LangGraph里硬凑循环依赖要省心得多。你现在是每个agent都有自己的内部状态吗？还是说所有状态都放在顶层共享？这个区别挺大的，前者容易漏同步，后者容易写冲突。

遇到过类似的，多半不是LangGraph的锅，而是你图里对共享状态的读写时机没控制好。建议先给每个子Agent的输入输出加个版本号或时间戳，卡住时看最后更新的节点是谁，就能快速锁定是哪个边没触发。另外检查一下条件边的判断逻辑，是不是某个字段永远满足不了，导致A一直等B的新状态但B实际早返回了。我之前是改用显式的消息队列（比如Redis Stream）做节点间通信，绕开LangGraph内部的状态同步，排查起来直观很多。

之前跑过一个类似的，最后发现是子Agent共享state里某个字段被重复覆盖，导致条件边判断永远走不到触发分支。建议你先给每个节点加个超时和显式的状态dump，看卡住时各个key的实际值，比print直观多了。另外LangGraph对循环依赖其实支持还行，但业务流里真别设计成A等B、B等A这种强耦合，尽量把共享状态拆成独立模块或者加个中间协调节点。

这种情况我在生产环境也踩过，多半不是LangGraph的循环依赖问题，而是你的图里某个节点的条件边没设超时或者重试机制，导致状态一直挂在那个节点上。我一般会先给每个节点加个简单的日志输出当前状态和输入输出hash，然后看卡住时最后一条日志是哪个节点，基本就能定位是调度问题还是状态没更新。另外你检查下是不是用了共享内存状态，A和B同时写同一个key会互相覆盖，这种死等其实是数据竞争。建议把关键路径上的状态改成显式传递，别全塞在顶层state里，会好查很多。

我上周也踩过类似的坑，后来发现不是LangGraph的问题，是我在子Agent的state里塞了个共享的list，结果两个节点都在等对方往里面写东西。建议你先在图的每个节点入口打一行日志，把当前state的key和值hash打出来，能很快看出来是哪个节点没被触发还是卡在某个await上。另外检查下有没有不小心把同一个node实例用了两次，LangGraph对节点ID重复有时候会静默跳过。

我之前也踩过类似的坑，后来发现多半是图结构里对共享状态的读写时机没控制好，尤其多个分支同时依赖某个字段时容易卡死。建议你先把所有节点改成显式声明输入输出，再用LangGraph的debug模式看每个节点的执行状态，比print高效很多。另外，如果确实有循环依赖，考虑用while循环或者把共享状态拆成独立子图，别让A和B直接互相引用。你可以试试在关键节点加超时和重试逻辑，这样至少能定位到是哪个环节在等。

碰到过类似的，最后排查下来大部分不是LangGraph的循环依赖问题，而是子Agent之间共享的state里某个字段被覆盖了，导致下游节点拿到的是旧值或者空值，看起来就像死等。建议你先在关键节点加个hook或者中间日志，把每次state的变更都打出来，对比一下卡住前后状态差异，比print高效很多。另外如果子Agent之间有相互确认的逻辑，可以试试把确认超时设成显式的tool call，而不是靠图结构隐式触发，这样能快速定位是调度没触发还是状态没更新。

我之前也踩过这个坑，后来把图拆成更细的节点，每个子Agent只负责单一动作，状态传递全走显式字段，死等问题就少多了。你那个主管Agent是不是也参与了状态读写？有时候主管节点没正确返回，子Agent会一直等它的响应，这个容易忽略。

遇到过类似的，多半不是LangGraph本身的问题，而是图结构里隐式循环依赖没被正确建模。建议先给每个节点加超时和状态快照，再用LangGraph自带的debug模式看node执行顺序，能直接看出卡在哪个step。另外检查下共享state里是不是有字段被多个agent同时读写，这种竞态最容易造成逻辑上互相等但日志无报错。我上次就是靠把state改成显式事件队列解决的，比单纯print高效得多。

我跑LangGraph也踩过这坑，后来发现多半不是循环依赖的问题，而是节点间共享的state里某个字段没更新，导致下游节点一直拿到旧值在那等。你可以试试在关键节点前后打印一下完整的state快照，对比输入输出，比单纯print日志直观很多。另外检查下supervisor的decide逻辑，是不是某个分支条件没匹配上，节点压根没被调度到。我上次就是有个tool调用返回格式不对，主管节点一直没触发下一步。

这题我熟，先把每个子Agent的输入输出都打上时间戳，看看卡在谁那儿，八成是状态里的key没对上。

我上次也遇到过，后来发现是共享state里字段被覆盖了，建议检查下子Agent的返回值是不是都塞进了同一个槽位。

我碰过类似的坑，后来发现多半不是LangGraph的循环依赖问题，而是子Agent的tool调用超时设置太保守，导致它们各自在等对方的外部API响应。你可以试试给每个节点加个显式的超时和重试机制，同时把状态快照打出来看看具体卡在哪个step。另外建议用LangSmith或者自定义一个全局trace，比print高效多了，能直接看到每个节点的输入输出时间戳。我之前还遇到过A和B共享同一个状态key但写入顺序冲突的情况，这个在单测里根本暴露不出来。

我倒是觉得你可能把图设计成完全双向依赖了，实际业务里很多“等待”是可以拆成异步或者用条件边绕开的。建议把A等B、B等A这种环状关系画出来，看能不能改成A先发部分结果，B处理完再回调A的链式结构。排查死等最笨但有效的方法，是在每个节点入口打印个带时间戳的日志，然后看是哪个节点一直没打印。如果所有节点都打印了但后续没动静，那大概率是状态管理里某个字段被覆盖了，而不是调度问题。

之前我被这个坑折磨了两周，最后发现是LangGraph的checkpointer在并发写同一个thread时锁住了，节点都在等锁释放。你可以先确认下是不是用的默认内存存储，如果是，换成SQLite或者Redis后端试试。排查上别

查死等先看状态里有没有环回依赖，用tracing插件看节点实际触发顺序，别靠print。

遇到过类似的，多半是图里隐式环了，建议把共享状态改成显式消息传递试试。

我之前也踩过类似的坑，最后发现多半不是LangGraph本身对循环依赖支持不行，而是图的设计里埋了“隐式环”。你提到A等B、B等A，这种在业务流里特别容易变成“逻辑上需要对方先确认，但状态节点没把依赖关系显式画出来”，LangGraph的调度器是按节点依赖走的，如果两个节点都订阅了同一个共享状态字段，很容易就卡在版本号等待上。我排查时习惯先看每个节点的输入输出是否真的只依赖前驱节点，而不是“觉得”它依赖——用print看日志确实费劲，建议直接给每个节点加个回调，把进入和退出时的状态快照打出来，对比一下谁没触发。另外，你把共享状态拆细一点试试，比如A和B各自维护自己的独立字段，别都用一个大字典，这样能减少很多无谓的锁等待。我遇到最坑的一次是某个节点返回了None，但下游节点还在等它的输出字段，也不报错，就静默卡着——所以检查一下节点返回结构是否稳定也很重要。如果还不行，可以试试把LangGraph版本升到最新，之前有几个版本对条件边的触发时机确实有bug。

这题我熟，之前用LangGraph跑多Agent也栽过这坑。你查查是不是子Agent之间共享的state里用了可变对象，或者某个节点在等一个永远不满足的条件，比如传感器轮询那种。我后来是给每个节点加了超时和重试，再用LangSmith的trace看每个节点的输入输出，比print高效多了。另外你试试把图改成并行分支再汇总，别让两个Agent直接互相引用，死等往往就是循环依赖的拓扑没设计好。

我之前也踩过类似的坑，最后发现多半不是LangGraph的循环依赖问题，而是子Agent内部把某个中间状态覆盖了，导致下游节点拿到的还是旧值。建议你先在关键节点前后打日志看state的hash或者关键字段变化，比print整个对象快很多。另外可以试试给每个边加个超时或者显式的next路由，强制让A先返回再触发B，能直接暴露是调度没触发还是状态没更新。实在不行就拆成两个子图跑，用外部存储传结果，虽然丑但排查起来一目了然。

八成是图里循环边没配好终止条件，LangGraph对这种隐式环默认会hang住，给每个子Agent加个超时或显式路由试试。