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

遇到过类似的坑，子图里改状态真的很容易把外层dict给冲掉，后来我干脆把子Agent的输入输出都隔离成独立key，不直接往顶层塞。Reducer合并list重复的话，试试用operator.add配合set去重，或者干脆别用list，改用dict按id存结果，覆盖就覆盖了。Checkpoint我个人觉得更多是恢复用的，不能解决状态覆盖逻辑本身，建议先画清楚每个节点到底读写哪些key。有个叫langgraph-examples的仓库里有研究助手的参考，你可以翻翻看，那个架构挺干净。

遇到过类似的坑，子图覆盖父图状态是LangGraph的经典问题，建议把共享数据单独放在一个不会被子图改写的key上，比如用Annotated来标记。自定义Reducer合并list时，记得先检查item是否已存在再extend，或者直接用set去重。Checkpoint确实能解决一部分同步问题，但别完全依赖它，核心还是得把图设计成无状态节点，数据流清晰了会好很多。

我之前也踩过这个坑，子图里手动改state基本必出竞态，后来干脆把子图当纯函数用，只让它返回结果，状态合并全部交给父图统一处理。Reducer合并list去重可以试试用operator.add配个set逻辑，或者直接上Annotated加自定义去重函数。Checkpoint不是拿来替代状态传递的，它是做持久化和恢复的，方向别搞反了。话说你这个“规划-检索-写作”其实可以考虑把检索做成工具调用而不是独立子图，能省掉不少同步麻烦。

子图状态覆盖这个坑我也踩过，大概率是你把父图和子图的状态key混用了，子图return后直接覆盖了父图里的检索结果。建议每个子图用独立的状态schema，父节点只拿子图输出的最终字段，别整个dict往上传。Reducer合并list重复的问题，试试用operator.add配合去重逻辑，或者干脆存dict按id做key。另外Checkpoint是持久化用的，治不了状态覆盖，别指望它。

子图覆盖状态我也踩过，你试试给每个节点单独命名空间，别让子图直接改父图状态。

子图里覆盖状态这个问题我也踩过，本质是你把子Agent当黑盒了，它内部的state key和外层撞了。LangGraph的Reducer合并list重复，八成是你没做去重，用operator.add直接拼肯定重复，得自己写个按id去重的。Checkpoint解决的是持久化和恢复，跟状态同步乱是两码事，别指望它。建议你把三个子Agent的state schema显式分开，子图返回时只透传需要的字段，别整个state往外丢。

这个状态覆盖的问题我太熟了，LangGraph里子图默认是独立作用域，父图节点调子图时如果没显式指定输出映射，子图的最终状态确实会直接冲掉父图对应key，你写作节点读到旧检索结果大概率就是子图return时把整个state回写了。Reducer那块合并list重复，常见坑是用了operator.add但没去重，或者并行分支各自append后没做归一化，可以试试用Annotated配合自定义函数，在里面按id或hash去重再拼接，别直接add。Send API做并行时每个分支拿到的state其实是快照，分支间不会自动同步，想共享得靠父图统一收口，或者干脆让并行节点只读不写、结果统一交给一个汇总节点处理。Checkpoint和手动传状态不冲突，它解决的是持久化和恢复，不是实时同步语义，你现在这情况更像是图结构设计问题，建议把检索和写作解耦成显式依赖，别让子图内部再嵌套太深。参考项目可以看看LangGraph官方那个multi-agent collaboration示例，还有open-deep-research里对状态分层的处理，思路值得抄。

状态被覆盖八成是子图没隔离好，试试给检索结果单独走一个channel，别跟写作共用一个key。

子图覆盖父图状态这个坑我也踩过，后来发现是节点里直接改了共享的dict，LangGraph的状态是不可变的，得返回新值才行。你那个list重复的问题，Reducer里用operator.add或者自己写去重逻辑都行，但关键是要确认每个节点返回的是增量而不是全量。Checkpoint机制主要是做持久化和恢复的，解决不了你现在的状态污染，建议先把图拆简单点，子Agent别嵌套太深。

子图覆盖状态这坑我也踩过，建议先查checkpoint作用域，Reducer合并list用operator.add试试。