用LangGraph搭多Agent协作，状态同步总是乱，求大佬指点

我之前也踩过这个坑，后来发现是节点返回的 state 更新没做 reducer 合并，LangGraph 默认直接覆盖，导致下一轮读到的还是旧值。你可以在每个节点里只 return 增量字段，然后用 Annotated 配 reducer，顺序乱的问题基本就没了。至于 Send API，适合做扇出并行，但你这种串行依赖其实用子图隔离更清晰，每个 Agent 管自己的 state，主图只传必要字段，别全局共享。显式 checkpoint 我试过，太僵硬，不推荐当常规方案用。

我之前也踩过这个坑，后来发现根子不在状态同步，而是节点执行顺序没有严格按依赖走，LangGraph默认是并行调度能跑就跑。建议试试把检索和总结之间加一条显式边，再用Send API把代码生成拆成独立子图，上下文用子图自己的state传，别全塞全局。全局state看着方便，但三个Agent写同一份数据，谁先谁后根本控不住。你要动态调度的话，checkpoint只能兜底，不能当同步机制用。

我也踩过这坑，后来用Send API拆子图才理顺，全局state共享太容易读到脏数据了。

状态串味八成是节点里直接改了同一个state，试试用Send把子任务拆成独立通道，别共享全局变量。

我之前也这样，后来改成每个节点只读自己需要的字段，别全量塞state，就顺了。

子图隔离更稳，别用全局state。Send API重构图虽然麻烦，但状态不会串。

我之前也踩过这个坑，说白了大概率是你把三个Agent塞进同一个全局state里互相读写，谁先谁后全靠LangGraph的调度碰运气。它默认的边触发是并行的，你看到“上一轮结果”其实就是节点执行顺序和state合并时机错位了。我后来改成子图隔离，每个Agent只暴露输入输出schema，中间过程不污染主state，检索结果用显式的channel传，问题基本就没了。Send API适合做map-reduce式的扇出，比如一次检索多个query再汇总，但你这三个Agent是流水线依赖，硬套Send反而更绕。节点函数里手动checkpoint我不太推荐，那等于自己重写调度器，LangGraph的interrupt和Command原语更适合做条件等待。另外检查一下你的reducer是不是默认覆盖，如果是并发写同一个key，用operator.add或者自定义合并函数，不然状态被静默冲掉你都看不出来。

我遇到过几乎一样的问题，后来发现根子往往不在LangGraph本身，而是节点函数里悄悄改了共享state的引用。Python的dict/list传引用，你检索Agent写进去的结果如果是个可变对象，下游拿到手时可能已经被后续节点改掉了，看起来就像“拿到上一轮的”。建议先排查一下每个节点是不是返回了全新的state片段，而不是原地修改。

显式checkpoint我觉得治标不治本，你加等待本质上是在用命令式的方式补丁一个声明式的图。Send API确实更适合你这种动态扇出的场景，特别是检索结果数量不固定的时候，用Send把每个检索结果分发到独立的总结分支，天然就隔离了时序问题，不用手动等。

全局state还是子图隔离，我倾向于混合：检索和总结之间用子图包一层，内部状态私有，只把最终摘要暴露到父图；代码生成那边单独读父图里已经定稿的字段。这样既不会让全局state变成一锅粥，也保留了跨Agent的必要信息流。另外可以给state加个版本号或者轮次标记，节点入口断言一下版本，过期就直接短路，比加等待干净多了。