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

我之前搞交易信号聚合也栽这上面过，LangGraph的state默认是浅拷贝，多个节点并行写同一字段时真会串。后来我干脆把检索结果和总结各自塞到独立子图里，只在最后汇聚点用Send批量拉结果，反而省心。你那个“拿上一轮结果”的毛病，八成是节点里改了共享list但没触发新key的版本更新，试试在节点返回时显式声明受影响的字段名。全局state在Agent少的时候凑合，一旦超过三个，建议还是子图隔离加显式超时机制，不然排查顺序依赖能熬死人。

说实话你这问题我太有共鸣了，之前搞过类似的代码评审流水线，三个Agent串起来后也是各种读脏数据。我后来发现核心不是等不等的问题，而是LangGraph的state更新本质上是节点返回后整体覆盖，你得把每个Agent的输出字段设计成带版本号的独立channel，比如retrieval_result带个时间戳，下游节点读取时校验版本，而不是靠执行顺序去猜。另外你说的Send API，我建议别急着上，那玩意儿适合并行fan-out场景，你这种强依赖的链式结构用了反而更乱。关于全局state还是子图隔离，我的经验是子图隔离适合每个Agent内部有复杂逻辑但对外交互简单的情况，但你这种需要高频传递上下文的研究助手，全局state加显式字段命名反而更容易追踪，关键是别在节点函数里手动做checkpoint，那会跟LangGraph的reducer机制打架。我最后的解法是每个节点函数开头先打印当前state的key列表，跑几轮日志看哪个字段被意外覆盖，基本能定位到是共享state的覆盖顺序问题还是节点内部异步操作没await完。另外你可以试试在节点返回时用Annotated类型加个自定义reducer做合并，比如让检索结果和总结结果用不同的key前缀，这样哪怕执行顺序乱，数据也不会互相踩。要是还不行，就把检索和总结拆成两个子图，用主图调度子图的输入输出，虽然代码多点但至少状态隔离得干净。

同感，我之前也是被这坑过，后来把共享状态拆细了，只让节点读自己关心的key，别一把梭全塞全局。

你真想动态调度就别硬等，给每个Agent配个独立子图，用Send异步触发，最后汇总再合并，乱序基本就没了。

我之前搞多Agent也踩过这个坑，LangGraph的全局state在并行节点上确实容易读到旧值。建议试试把检索结果按轮次打上版本号，在总结节点里校验一下，或者干脆用子图隔离，每个Agent维护自己的状态，只在需要交互时显式传递。Send API更适合动态任务分发，如果三个Agent的依赖关系基本固定，还是子图更可控，别为了动态而动态。

遇到过一模一样的坑，尤其是多轮对话场景下，LangGraph的默认state共享机制在并行分支里特别容易串数据。我后来是给每个Agent单独建了子图，子图内部用局部state，只在子图的输入输出接口做显式映射到全局state，这样至少能保证每个Agent读到的输入是快照级的，不会因为兄弟节点更新而污染。但说实话，这种方式牺牲了实时共享，如果你需要Agent间动态协商，子图隔离就不太够用。

关于你提到的Send API，我之前试过动态分发，但发现它更适合fan-out/fan-in的批处理，如果你的协作依赖是链式的，比如总结必须等检索结果，代码生成又依赖总结，那直接改图结构反而更清晰。我现在的做法是在节点函数里手动加版本号字段，每次写入state时带上时间戳或者轮次标记，读取时校验版本，不匹配就重试或跳过，虽然丑但能解决问题。

全局state和子图隔离我建议混合用：公共的、所有Agent都要读的元数据放全局，比如任务ID、用户意图；但每个Agent的私有中间结果，尤其像检索的原始文档、总结的暂存文本，一定要隔离在子图里。另外，试试在节点之间加显式的“屏障”节点，用条件边判断数据是否就绪，而不是靠状态等待，这样图的动态性还在，只是多了个检查动作。我目前跑了两个月没出过顺序问题，代价是调试时看图逻辑复杂了些，但比玄学状态乱序强。

子图隔离更省心，全局state共享一多必乱，checkpoint不如把中间结果显式传给下游节点。

同踩过坑，建议每个Agent返回时把关键字段快照进局部state，别老指望全局顺序。

全局state图省事但坑多，建议子图隔离+节点内显式checkpoint，Send API适合动态分支但你这问题核心是数据版本控制。

遇到过，别硬等，把检索结果按轮次打上版本号塞state里，读的时候带条件路由就行。全局state够用，子图隔离反而更难排查。

子图隔离更靠谱，全局state一旦多agent并发读写必乱，我上次就是靠拆分状态机解决的。