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

建议子图隔离+显式checkpoint，全局state在这种场景下就是坑，顺序依赖用Send传数据比硬等靠谱。

说实话你这个情况我上周刚踩完坑，LangGraph的StateGraph默认是节点执行完才整体更新state，所以你那个“检索结果拿上一轮”的问题大概率是节点并发时共享了同一个state字典，没有做深拷贝。我最后是直接在节点函数里用config["configurable"]传一个独立的临时状态，等节点返回时再手动合并，虽然丑但至少顺序可控。Send API我也试过，它更适合那种真正需要动态分支的场景，比如根据检索结果决定要不要额外查一次，但你这种固定三阶段的流水线其实用不上，硬上反而把图拆得稀碎。关于全局state还是子图，我强烈建议你换成子图隔离，因为你三个Agent的中间产物根本不需要互相可见，全局state看着方便，但一旦某个节点忘了清理旧key，污染起来查错能查到怀疑人生。我现在的做法是每个子图内部用自己的state，只暴露最终结果给父图，这样就算顺序乱了也只会影响单个子图的重跑。另外你那个“显式状态等待”写死的问题，可以试试给每条边加condition，用检索结果的元信息（比如时间戳或内容hash）判断要不要跳过等待，这样比死等灵活。最后提醒一下，LangGraph的checkpointer不是用来解决顺序的，它是给断点续跑用的，别混了。

我之前也踩过这个坑，问题多半出在共享state的写时序上，LangGraph默认是异步节点并发更新，你那个“拿到上一轮结果”八成是节点读取时依赖的字段还没被写入。建议别在节点里自己搞checkpoint，太容易把逻辑搞乱，直接给每个Agent单独定义自己的state字段，然后通过显式的路由边（比如用Send或条件边）来控制数据流动，而不是靠全局大state硬扛。子图隔离我试过，虽然能减少冲突，但跨图传数据反而更繁琐，你这种场景不如把检索结果直接作为消息体传给总结节点，而不是写在全局state里。另外，你可以试试在每次节点返回时用“覆盖写”而非“追加”，配合图编译时的recursion_limit，这样至少能保证顺序稳定。

之前也踩过这坑，后来是把检索结果写成单独的子图状态，只把必要引用传给总结节点，顺多了。全局state确实容易串味儿。

我之前也被这个坑过，后来直接在节点里用显式checkpoint控制版本号，比改图结构省事得多。

我之前用LangGraph也踩过这坑，后来发现主要是共享state里写入了太多中间变量，导致节点读到的不是最新快照。我的做法是把检索结果单独放进一个子图或专门的state字段，每次节点开头强制取当前值，别依赖隐式顺序。另外Send API适合真正并行的分支，如果三个Agent本身有依赖，建议保留线性图但把checkpoint逻辑封装成装饰器，这样比全局state直观很多。你试试把总结和代码生成各自的输入输出隔离成独立key，可能比改图结构省事。

试过把关键状态存redis做版本号，节点读之前先比对，乱序问题基本绝了，全局state够用别急着拆。

给子图隔离吧，全局state在这种多轮迭代下迟早把你逼疯，checkpoint治标不治本。

我之前也踩过这个坑，LangGraph的state默认是浅拷贝，节点并行跑起来很容易读到旧值。建议别死磕全局state，把检索和总结拆成子图，用Send API显式传数据，至少能保证每轮输入是干净的。另外你可以试试在节点里返回时用Annotated的add_messages或者自定义reducer，强制覆盖而不是追加，比手动checkpoint省心。还有个笨办法，给每个Agent的输出加个时间戳，在下一个节点开头校验下seq，乱序就重跑，虽然粗暴但排查问题好使。

我之前踩过类似的坑，最后发现问题是出在节点返回的state覆盖逻辑上，LangGraph默认是整体替换，你得在节点里显式声明要更新的字段，不然老数据就把新结果冲掉了。另外别用全局state塞太多东西，建议把检索和总结拆成子图，各自维护内部状态，只把必要的结果通过SendAPI传出去，这样时序问题会好很多。你现在三个agent是线性串行还是并行跑的？如果是串行，可以试试把总结节点改成条件分支，等检索结果真正落地再触发。

建议去读下LangGraph的持久化layer，节点里显式等上一轮state真不如用subgraph隔离，我踩过这坑。

我之前也踩过这个坑，尤其是多轮对话场景下，状态覆盖问题特别隐蔽。建议别在节点里手动checkpoint，那个太容易漏，试试用子图隔离每个Agent的私有状态，只让公共信息走全局state，这样能避免串味。另外Send API适合那种真需要动态分支的，你这个其实更可能是数据流时序问题，可以在总结Agent入口加个显式的version字段，用检索结果的哈希值对比，能快速定位是不是拿到旧数据。全局state不是不能用，但记得用TypedDict定义清楚，别图省事全塞一起。

试试把检索结果按时间戳打标，节点里强制读最新版本，别依赖图默认顺序，全局state够用但得自己管版本号。

我之前也被这个坑过，LangGraph的state更新顺序本质上是节点返回的dict直接覆盖，不是增量合并。你试下把每个节点的输出字段名错开，比如检索结果放retrieval_result，总结放summary_result，最后再统一合并，这样至少不会互相踩。另外子图隔离会好很多，全局state一旦复杂起来根本没法调试，我后来是拆成三个子图，主图只负责调度，数据传递在子图内部消化。Send API适合真正需要动态分支的场景，你这三个Agent顺序相对固定，不如显式把依赖关系画清楚，别为了动态而动态。

子图隔离吧，全局state在这种多轮协作里就是个坑，我之前也是被这玩意坑惨了。

显式checkpoint治标不治本，建议把检索结果缓存到子图外部，用Send触发时带上版本号。

这问题我上个月刚踩过一遍，最后发现根子不在LangGraph，而在你对“状态即共享内存”的预期上。三个Agent共用一个大state，本质就是所有节点都在读写同一个全局变量表，顺序一乱就全乱套。我后来改成每个Agent维护自己的内部状态，只在节点边界显式声明要传递的字段，比如检索Agent结束后只把top5文档ID和摘要塞给总结Agent，这样就算某轮检索慢了一拍，总结那边拿到的还是它真正需要的快照，而不是整个state的脏拷贝。你说的显式状态等待其实不是把图写死，而是用条件边去检查某个字段是否达到预期版本号，我加了个简单的版本计数器，每个节点写入时自增，下游节点读到版本号不匹配就自动重试，比硬等灵活多了。全局state适合proto类型简单、字段少的场景，像你这种要传长文本和代码块的，强烈建议子图隔离，每个子图内部状态独立，父图只传递精简的summary和引用指针，否则state里塞满历史中间结果，不仅顺序乱，内存也扛不住。至于Send API，我试过但觉得它更适合并行fan-out，你这种强依赖链路的场景反而增加心智负担，不如先把state切分做好。最后说个坑：别在节点函数里做checkpoint，那是给持久化用的，不是给逻辑用的，不然你会在调试时被一堆中间快照淹没。

试试把检索结果按时间戳缓存到子图里，总结节点只读最新快照，我之前这么搞就没乱过。

建议把检索结果按轮次存成带时间戳的子状态，节点只读自己那轮的数据，全局state只放调度标识。另外Send API适合动态并行，但你这顺序依赖强，还是子图隔离更稳。

遇到过类似的坑，后来发现核心问题不是状态等待，而是你每个节点读state的时机——LangGraph默认是共享可变state，得在节点函数里显式声明依赖哪些字段，不然容易读到旧值。建议试试把检索结果存成带时间戳的dict，总结节点直接按key取最新，比加等待靠谱。子图隔离确实能减少混乱，但跨子图传参又得维护一套映射，小项目反而更麻烦。Send API适合动态分支，你这个固定三节点用全局state加版本号就够了，重点是把checkpoint逻辑写清楚。

我之前也踩过这个坑，后来发现关键是别把状态全塞全局，每个Agent自己维护一份私有上下文，只在节点返回时显式声明需要同步的字段，这样能避免拿错轮次的数据。另外，Send API不是必须的，你可以在节点函数里用条件边+状态版本号来控制读取，比写死等待灵活得多。还有个土办法，给检索结果打个时间戳，总结Agent读的时候校验一下，过期就强制重跑，虽然丑但很管用。子图隔离我试过，调试起来反而更费劲，不如全局state加清晰命名。