用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或者自定义合并函数，不然状态被静默冲掉你都看不出来。