By 黄金金枪鱼 
导语
多 Agent 原型常把同一份上下文传给所有角色，初期运行顺畅，进入并发与恢复阶段却容易出现覆盖、重复执行和旧状态误读。状态边界一旦含糊，再强的模型也只能在不一致的数据上推理。
核心事件
LangGraph 的持久化文档把 graph state 按 thread 与执行阶段保存为 checkpoint，用于恢复、人工介入和历史回放；The New Stack 对 Agent 数据层的报道也把一致视图与状态传递列为生产难点。工程重心因此从“多设几个角色”转向“明确谁拥有状态、谁有写权限、失败后从哪里重放”。这不是框架语法之争，而是分布式系统问题进入 Agent 栈。
技术解析
三种模式的差异，本质上是状态所有权与同步方式不同。
模式一：共享状态。 所有 Agent 读写同一个 typed state，路由节点决定下一步。它适合步骤短、角色少、强一致要求高的流程，调试时也容易还原全局快照。代价是字段耦合：两个 Agent 同时修改计划或任务列表时，必须通过 reducer、版本号或单写者规则解决冲突；否则共享内存会变成隐式通信总线。
模式二：事件消息。 每个 Agent 保留本地状态，只发布不可变事件，其他角色按需订阅并构建自己的投影。优点是审计、重放和水平扩展自然，单个消费者失败不会污染全局对象；代价是接受最终一致性，并处理乱序、重复投递与幂等。它更适合长任务、异步工具和跨服务协作。
模式三：分层状态。 Supervisor 只维护目标、阶段、预算与决策，Worker 的检索过程、工具输出和临时推理留在局部；回传时只提交结构化摘要、产物引用与状态码。它在隔离性和协作效率之间更平衡，但 Supervisor 可能成为瓶颈，因此要把合并规则写成确定性代码，而不是交给模型自由裁决。
关键点
- 先定所有权：全局计划采用单写者，Worker 只能提交候选变更，避免最后写入者覆盖正确结果。
- 状态与消息分开：状态表示当前事实，消息表示发生过什么；两者混用会让重试变成重复执行。
- 为恢复设计：checkpoint 必须绑定 thread、步骤版本和幂等键，恢复时从确定边界继续，而非重新跑完整链路。
- 控制上下文扩散：Worker 默认只接收完成任务所需的最小切片，敏感字段与无关历史不进入其上下文。
- 按冲突率选型：低并发短流程可用共享状态；异步跨服务优先事件消息；角色多但治理集中时采用分层状态。
行业影响
状态层会逐渐从 Agent 框架内部实现，演变为可独立审计的数据基础设施。企业采购编排平台时，评估重点也应从“支持多少角色”转向 checkpoint、版本冲突、重放、权限边界和迁移能力。
结语
多 Agent 并不等于共享全部上下文。最稳妥的起点通常是分层状态：全局只放可验证的任务事实，局部保留执行细节，再用版本化提交完成合并。等异步规模扩大后，再把高吞吐链路迁移到事件消息模型。
参考资料
官方文档
- LangGraph Persistence [200]
开源项目
行业报道
社区讨论
对比基准
- MultiAgentBench 论文 [200]
- MARBLE 基准代码仓库 API [200]
本文由 AI 生成。内容基于公开资料整理，可能存在事实偏差，引用链接请以原始来源为准。