用LangGraph搭多Agent协作，状态同步老出问题怎么办？

状态拆开吧，每个Agent维护自己的子状态，用消息队列传结果，别死磕共享State。

建议把共享状态拆成只读上下文和可变结果区，写操作按Agent维度加命名空间隔离。

我踩过这坑，最后是给每个Agent单独维护一份局部状态，只把最终结果merge回主状态才解决。

试试把共享State拆成只读和可写两块，每个Agent单独维护自己的中间结果，别直接往全局塞。

或者干脆给每个Agent建独立状态通道，用消息队列同步，别让它们抢一把锁。

状态拆开吧，每个Agent独立key，别全塞一个共享字典，查重只读自己需要的快照就行。

我踩过这坑，并行写同一份state必然互相覆盖，给每个Agent配独立的子状态再加个只读引用就好了。

把共享状态拆成独立channel吧，每个agent只读写自己那份，全局上下文靠显式传递，别让它们直接碰同一个State。

并行跑的时候共享State确实容易踩坑，我建议你把每个Agent的输入输出拆成独立key，比如用namespace或者前缀隔离，别让它们直接读写同一个字段。另外checkpointer只解决持久化，不解决并发写冲突，你可以试试用langgraph的reduce操作符或者自定义合并逻辑，把摘要更新设计成追加而不是覆盖。我之前做过类似项目，最后是让每个Agent只依赖自己显式声明的上游输出，状态里只留最终结果，中间过程全放临时存储，问题基本就消失了。

这问题我太熟了，之前做类似的多Agent流水线也踩过同一个坑。你单跑没问题是因为每个Agent拿到的都是独立上下文，但并行时StateGraph的共享状态本质上是“最后写入者胜”，查重读旧摘要就是因为生成摘要的节点还没写完，查重已经读取了。我后来换了个思路，不再让所有Agent共用一个全局State，而是给每个Agent分配一个独立的“局部状态槽”，只把必要的结果通过显式的消息传递（比如用字典的key做版本号）同步到共享区，这样覆盖问题基本消失。另外checkpointer只能保证节点间持久化，不能解决并发读写的竞态，你可以在写状态前加个简单的锁或者用LangGraph的通道机制（比如用ReduceAnnotation）来合并结果，而不是直接覆盖。还有一个笨办法但很有效：把三个Agent拆成两个阶段，先跑提取和查重，等它们都完成再跑摘要，牺牲一点并行度换稳定性。你现在的状态结构是不是所有Agent都直接读写同一个顶层字典？如果是的话，建议把状态改成嵌套字典，每个Agent只碰自己那个子模块，这样至少不会互相污染。最后想问下，你并行时是用的多个图实例还是同一个图的多个节点？有时候问题出在SendAPI的分支执行逻辑上，它会复制状态快照，导致后续节点拿到的是旧快照。

你这问题我太熟了，之前搞多Agent的时候也被共享状态坑惨了。建议别把完整上下文扔进State，改成每个Agent只读自己需要的字段，写完再合并，或者用独立的命名空间隔离各Agent的临时变量。另外checkpointer只管持久化，不管并发冲突，并行改同一块数据肯定会被覆盖，可以考虑在SendAPI里显式传不可变快照，而不是让Agent回头去取可能过期的State。

我之前也踩过这个坑，后来发现核心问题不是共享State本身，而是你对每个Agent读写key的粒度控制不够。试试给每个Agent分配独立的命名空间，比如用extract_、check_前缀隔离字段，或者干脆用Annotated类型加个自定义reducer函数，合并逻辑写清楚就不会互相覆盖了。checkpointer只能保证节点级别的状态快照，管不了并发写冲突。另外如果三个Agent确实无强依赖，建议拆成三个独立子图，最后再汇总，比硬凑一个并行流程稳得多。你现在是希望它们并行跑还是顺序跑？这个设计决策很关键。

试试把共享状态按Agent拆分，用独立key存各自输出，别让它们直接读写同一个上下文。

并行写同一份状态肯定打架，搞个中间队列或者版本号，读之前先确认下版本对不对。

试试把共享状态按Agent拆分命名空间，用Reducer显式合并，别让它们直接读写同一份上下文。

并行就别共用一个State了，各维护独立槽位，最后再汇总，能少很多覆盖问题。

这问题我太熟了，之前做类似并行节点的时候也被覆盖过。核心原因大概率是共享State里直接塞了可变对象，LangGraph的Reducer没配好，导致写操作互相踩踏。建议把每个Agent的输出拆成独立字段，比如summary_v1、summary_v2，或者用Annotated[T, operator.add]这种带归约逻辑的类型，让不同Agent写不同key。另外checkpointer只管恢复快照，不管并发冲突，真要根治得自己搞个锁或者版本号机制。你那三个Agent既然有依赖关系，其实可以考虑把查重和摘要改成串行，或者用子图隔离状态，别硬塞进一个顶层State里。

我最近也在折腾这个，后来发现核心问题不是checkpointer，而是State结构设计得太粗了。你得让每个Agent只读自己关心的key，写的时候用独立命名空间，比如把shared_context拆成extract_result、dup_result、summary_result三个子字段，这样并行写互不干扰。另外SendAPI适合fan-out场景，但如果Agent之间强依赖顺序，不如老老实实串行，或者用map-reduce模式，让每个子Agent先返回局部结果，最后统一合并进主State，比共享一个可变字典靠谱多了。

说实话你这问题我太有共鸣了，之前做类似的多agent协作也踩过这个坑。我后来是把共享State拆成了每个agent独立的子状态，再单独建一个只读的全局上下文，写操作全走消息队列，这样基本没再出现过覆盖。另外你那三个agent其实有依赖关系，查重和摘要都依赖提取结果，不如干脆串行跑，并行反而把简单问题搞复杂了。你checkpointer加的是哪个节点？有时候只在末端存状态，中间过程的读写冲突照样会漏。

状态拆分试试，每个agent维护独立子状态，用显式消息传递替代共享上下文，查重和摘要之间加个同步节点。

我之前也踩过这个坑，后来发现核心问题不在LangGraph本身，而是你把“共享State”理解成了“全局可变变量”。每个Agent的输入输出应该严格隔离，比如让查重Agent只读它依赖的那个字段，而不是整个State对象。你可以试试把状态拆成不同子模块，每个Agent只声明自己读写的key，这样就算并行，覆盖也只发生在各自的命名空间里。另外，checkpointer管的是持久化，不是并发一致性，别指望它解决竞态。我之前是把“提取要点”的结果先落库，再触发后续两个Agent，用任务队列代替直接状态传递，反而更稳。

建议把共享State按Agent拆成独立命名空间，只暴露必要字段，别让查重直接读摘要生成前的中间态。

试试把状态改成只读快照加版本号，每个Agent写自己那份，用消息队列同步，别让checkpointer背锅。

多Agent并行时共享State确实容易踩这个坑，我之前做类似流程时发现核心问题在于“读-改-写”的时序冲突，LangGraph的state reducer如果没针对每个agent定义独立的key，覆盖几乎是必然的。建议试试把每个agent的输入输出拆成独立的子状态节点，再通过显式的合并节点做同步，或者干脆用消息队列传递增量数据。另外checkpointer只解决恢复问题，不保证并发一致性，你查重Agent读旧摘要很可能是因为它拿的是父状态快照，可以看看是不是需要强制让下游依赖上游的输出节点而非全局state。

状态别整一个大而全的，按Agent拆成独立channel再加个版本号，查重读旧摘要大概率是没做写入校验。

跟你情况挺像的，我之前做客服工单分类加知识库检索那套流程，也是三个节点抢一个state，后来发现根子不在LangGraph本身，在于我把“共享状态”理解成了“全局变量”。你试过把每个Agent的输入输出拆成独立命名空间吗？比如用字典套娃，或者干脆让每个Agent只读自己需要的字段，写完再显式合并，别让它们直接碰同一个顶层key。另外你说加了checkpointer，但有没有确认并行节点之间是不是真的隔离了写操作？我踩过的坑是checkpointer只负责恢复，不解决并发写冲突，你得像处理数据库事务一样，给关键状态加版本号或者让每个Agent返回增量补丁而不是全量覆盖。还有个笨办法，把并行改成串行，用中间队列缓存结果，虽然慢点但绝对不乱，文档审阅这种场景延迟几秒应该能忍。你要是非要用并行，建议去翻一下LangGraph的分布式状态模式，我记得官方文档里提过用子图隔离状态，父图只做汇总——我当时是被这个坑逼得直接换成了多进程加Redis锁，反而更稳。