单 Agent 的状态管理已有成熟方案------Pregel 的 super-step 快照、pending writes 的容错设计、DeltaChannel 的增量压缩。但那些都是单 Agent 的问题。
现在把场景升级一下：Planner Agent 把任务拆成五个子任务，分发给 Coder、Reviewer、Tester 三个 Agent 并行执行。三个 Agent 共享一个代码仓库，同时读写同一个 State。
Planner 刚把"优先修复认证模块"写进共享状态，Coder 在另一个分支上读到的是五分钟前的旧状态（它的 git checkout 拉下来的还是包含已知漏洞的版本）。Coder 花二十分钟写了一套基于这个漏洞版本的补丁方案，PR 提交到 Reviewer 手里时，Reviewer 发现这整个方向都错了------因为就在 Coder 埋头写补丁的这段时间里，Tester 已经确认认证模块是安全的，真正的风险点在别处。
状态不一致不只是性能问题，可能引发逻辑层面的连锁错误。一个 Agent 基于过期信息做出的决策，会顺着任务依赖链往下传播，污染所有下游 Agent 的推理。
Gartner 的数据显示，多 Agent 系统的咨询量从 2024 年 Q1 到 2025 年 Q2 增长了 1,445%。UC Berkeley 的 MAST 研究分析了七个开源框架的 1,600 多条执行轨迹：多 Agent 系统的失败率从 41% 到 86.7% 不等，其中约 79% 源于规格说明模糊和 Agent 间协调失效，而不是代码 bug（arXiv:2503.13657）。
也就是说，工程界在狂热地搭建多 Agent 系统，但基础的状态一致性问题还没有被认真对待。从"只有一个 Agent"到"有 N 个 Agent"，状态共享这件事会以四种不同的方式出问题------以及每一种方式的解法。
串行执行：安全到有点浪费
大多数 Agent 框架的起点都是串行。CrewAI 的默认模式是 Process.sequential，任务按照定义顺序一个接一个执行，上一个任务的输出作为下一个任务的上下文。LangGraph 在没有显式声明并行分支时，所有节点串行推进。
好处很明显：不存在状态竞争，因为根本没有并发。但代价也很直接：你加了三个 Agent 不是为了跑得更快，只是为了让每个环节的推理质量更高。Planner 生成计划、Coder 写代码、Reviewer 审查，但吞吐量完全没变。
后来出现了一种折中方案：fork-and-merge。给每个 Agent 一份独立的状态副本，各自在自己的副本上干活，最后合并结果。这类似于数据库的 READ COMMITTED 隔离级别------Agent 读到的是快照时刻的一致视图，但不保证它做的事在你合并时还有意义。
CoAgent 论文（arXiv:2606.15376）对这种方式有一个准确的判断：fork-and-merge 只提供弱隔离，Agent 在孤立副本上做出的决策，回到全局状态时可能已经失效。
事件溯源：不可篡改的真相
串行太慢，fork-and-merge 太脆弱。一个更根本的思路是：既然并发写入会导致状态冲突，那就不要让人写入同一个状态。每个 Agent 的所有行为都变成一条不可变事件（AgentDecision、ToolCalled、ResultEmitted），追加到一个 append-only 的事件日志里。当前状态不再是直接写入的目标，而是事件日志的投影（projection）。
这意味着三件事：
1没有 Agent 会覆盖另一个 Agent 的写入（大家都在追加，各写各的）2出了任何问题都可以从头重放事件日志，精确重建任意时刻的系统状态，堪称调试天堂3事件日志本身就是审计追踪，整个运行过程天然就是一份日志
LangGraph 1.0 的 Pregel/BSP 模型本质上就是这么工作的：每个 super-step 结束后的状态更新，就是一条事件。AutoGen v0.4 重构为 actor 模型后，Agent 之间通过类型化消息（typed messages）通信，消息本身就是事件。
行业层面，Confluent 在 2025 年发布的四套事件驱动多 Agent 模式（Orchestrator-Worker、Hierarchical Agent、Blackboard、Market-Based），底层依赖的全是 Apache Kafka 的不可变事件流。
AgentMarketCap 在 2026 年 4 月的分析文章里把这件事概括得很清楚：
任何两个 Agent 不需要共享可变状态------它们只共享不可变的、只追加的事件流。
换个角度看，事件溯源就是分布式系统中的"写时复制"（Copy-on-Write）搬到 Agent 领域：你不修改别人的数据，你只是往公共日志里追加新事实。
但事件溯源不是免费的。Agent 看到的状态是"事件日志的当前投影"，而这个投影在并发场景下始终存在延迟------Agent A 追加了一个事件，Agent B 要等日志消费到这一条才能看到。本质上是最终一致性（eventual consistency），而不是强一致性。
Agent B 可能基于稍旧的状态做出决策，等它发现实际情况跟自己的假设不符时，已经跑完的推理链条就浪费了。对于容忍少量不一致的场景（比如代码审查 Agent 读到几分钟前的代码评审意见），这不是大问题；但对于实时决策场景（比如 Tester Agent 发现严重 bug、Planner Agent 需要立即重新调度），延迟会导致管道里已经产出的推理全部作废。
CRDT：无锁收敛
事件溯源解决的是"谁写到了哪里"的问题，但追加式日志意味着每次读状态都要重放事件------token 开销和延迟都在上升。
CRDT（Conflict-Free Replicated Data Type，无冲突复制数据类型）换了一个角度：它不是靠"避免冲突"来保证一致性，而是靠"数学上可证明的收敛"。Shapiro 等人 2011 年给出的定义大意是：任意两个接收了相同更新集合的副本，无论更新以什么顺序到达，最终都会收敛到完全相同的状态。
CRDT 的核心是三个代数性质：
1交换律：a + b = b + a2结合律：(a + b) + c = a + (b + c)3幂等律：a + a = a
只要合并操作满足这三个性质，不管你以什么顺序、在多少个副本上执行，最终结果一定一致。没有中心化协调，没有锁，没有两阶段提交。这三个性质之所以能在 Agent 系统中成立，是因为 Agent 天然就是自主、并发、部分知情、最终同步的计算单元------恰好是 CRDT 设计时假设的运行环境。
对于多 Agent 系统，这意味着每个 Agent 可以独立修改自己的本地状态副本，然后随时和其他 Agent 合并------结果自动收敛，不需要人工解决冲突。四种 CRDT 类型刚好能映射到 Agent 系统的四种状态模式：
1G-Set（仅增长集合 ）：已完成的任务 ID、已发现的事实------只增不减，合并就是取并集2PN-Counter（正负计数器 ）：token 预算追踪、资源分配------P 和 N 两个计数器分别递增，合并时对应相加3OR-Set（观察移除集合 ）：共享任务队列------并发添加和删除都能正确收敛，"add wins"语义保证不会丢任务4LWW-Register（最后写入胜出寄存器）：任务状态、资源归属------保留时间戳最新的写入
用 CRDT 做 Agent 状态共享有一篇很有参考价值的论文：CodeCRDT（arXiv:2510.18893）。它用 Yjs 的 CRDT 实现让多个 LLM Agent 并行编辑同一份代码，结果达到了 100% 的字符级收敛（零合并失败），但依然有 5% 到 10% 的语义冲突------代码结构上完美合并，逻辑上却是矛盾的。
并行 Agent 还比串行多产出了 82% 到 189% 的冗余代码，这些多余的 token 开销正是并行化没有兑现加速的原因之一。
这个数字揭示了 CRDT 的边界：CRDT 保证的是数据收敛，不是语义正确。两个 Agent 可以分别往 G-Set 里添加"数据库连接池大小设为 10"和"数据库连接池大小设为 50"------合并后两个事实都在集合里，但它们是矛盾的。CRDT 只会告诉你"这两个值都存在"，不会告诉你"你应该用哪个"。
这就自然地把 BDI（Belief-Desire-Intention，信念-愿望-意图，Rao & Georgeff, 1991）模型拉了进来。在 BDI 架构里，Agent 的状态由三部分组成：
1信念（belief）：它知道的事实2愿望（desire）：它想达成的目标3意图（intention）：它已经承诺的行动计划
CRDT 正好一一对应：
1G-Set 承载信念（累积的知识）2PN-Counter 承载愿望（资源博弈）3OR-Set 承载意图（承诺的任务队列）
而 BDI 的审慎循环（deliberation cycle，即 Agent 不断检查信念是否改变、是否需要重新规划）本质上就是在做 CRDT 合并不了的"语义仲裁"。
把 CRDT 代码落地到 Agent 系统里，一个最简洁的基元是 G-Set：
python
class GSet:
"""Grow-only set --- CRDT for append-only agent knowledge"""
def __init__(self):
self.elements = set()
def add(self, element):
self.elements.add(element)
def merge(self, other: "GSet") -> "GSet":
# Commutative + Associative + Idempotent = always converges
result = GSet()
result.elements = self.elements | other.elements
return result
# Agent A 完成了登录模块的实现
completed_tasks_a = GSet()
completed_tasks_a.add("implement_login")
# Agent B 在另一个线程里完成了限流模块
completed_tasks_b = GSet()
completed_tasks_b.add("add_rate_limiting")
# 合并------两个事实都存活，没有冲突
merged = completed_tasks_a.merge(completed_tasks_b)
# merged.elements == {"implement_login", "add_rate_limiting"}工程实现层，Automerge 2.0 用 Rust 重写后提供了完整的 JSON CRDT 和分支/历史模型，cr-sqlite 直接把 CRDT 同步能力嵌进了 SQLite。每个 Agent 各自写入本地的 SQLite 数据库，底层自动通过 CRDT 合并到一致状态------不需要额外的同步服务，不需要修改 Agent 的代码逻辑，数据库层面就完成了收敛。
CoAgent MTPO：让 LLM 判断冲突
CRDT 解决不了语义冲突。能解决语义冲突的，是 LLM 本身。
上海交大的 CoAgent 论文提出了 MTPO（Monotonic Trajectory Pre-Order，单调轨迹预排序）协议，核心思路很直接：传统的并发控制（两阶段锁、乐观并发控制）对 Agent 不适用------锁住 Agent 几小时的推理不让别人动数据不现实，而乐观并发控制在检测到冲突后直接丢弃几十分钟的推理结果也太浪费。
MTPO 的做法是反过来：固定所有 Agent 的序列化顺序，让 LLM 自己判断冲突是否真的影响了自己的计划 。启动时给每个 Agent 分配一个全局顺序号 σ，低序号 Agent 的写入对高序号 Agent 可见，反之不可见。
当低序号 Agent 写入了高序号 Agent 已经读过的数据时，框架会发一条通知，高序号 Agent 用 LLM 判断：这个变更有没有让我的计划失效？如果没有，继续；如果有，只修复受影响的操作，不从头重跑。
结果很直接：1.4 倍加速，串行正确性的 5% 以内，token 开销接近串行。
这意味着 CoAgent 把并发控制的本质从"强制中止"变成了"通知式修复"------不是锁住你、不是回滚你，而是说"有件事变了，你看看要不要改"。这种策略之所以行得通，是因为判断一个变更是否真的构成语义冲突，需要的不是形式化的读写集合分析，而是理解和推理。后者恰好是 LLM 的能力所在。
BDI 视角：为什么这些机制有效
把前面四种机制串起来看，会发现它们各自对应了认知科学理论在 Agent 时代的一次计算化重演。
共享心智模型（Shared Mental Models）理论认为，高效团队靠的不是每个成员掌握全部信息，而是每个成员对任务状态、队友能力、当前进度保持一致的认知------这种一致性通过持续的低成本交互维持，而不是一次性对齐。
多 Agent 系统中的状态共享机制，本质上是将这套理论计算化：事件溯源提供了"团队发生了什么"的不可变记录，CRDT 提供了"每个成员怎么独立更新自己的理解"的数学收敛保证，MTPO 提供了"当理解出现分歧时谁来仲裁"的决策机制。
从分布式态势感知（Distributed Situation Awareness）的角度看，没有一个 Agent 掌握系统的全部状态。"系统到底进展到哪里了"这个知识，是从所有 Agent 的交互历史和共享状态中涌现出来的，不存在于任何一个单独的 Agent 内部。
这个视角解释了为什么多 Agent 系统中的状态一致性问题比单 Agent 场景复杂一个数量级：你不是在管理一个状态容器，你是在管理一群彼此只能看到局部视图的认知单元如何形成对全局的准确判断。
四种机制对比
| 机制 | 一致性保证 | 吞吐提升 | Token 开销 | 适合场景 |
|---|---|---|---|---|
| 串行执行 | 强串行 | 无 | 低 | 简单流程、质量优先 |
| Fork-and-Merge | 弱隔离 | 中 | 中 | 独立子任务、低交互 |
| 事件溯源 | 最终一致 | 中高 | 中高 | 审计要求、可回溯 |
| CRDT | 强最终一致 | 高 | 低 | 协作编辑、高并发 |
| MTPO | 接近串行 | 中高 | 近串行 | 复杂计划、语义仲裁 |
没有一种机制是普适的。框架支持也不同：LangGraph 和 CrewAI 都支持事件溯源式 checkpoint，AutoGen v0.4 的 actor 模型天然适配消息驱动的事件流，CRDT 依赖 Yjs/Automerge 这类专用库接入，而 MTPO 目前还停留在 CoAgent 的研究实现阶段。
五个实践原则
1从串行开始，只在吞吐成为瓶颈时才引入并发 。 Anthropic 在 2025 年 6 月的工程博客里给出过一组数据：多 Agent 系统用 Claude Opus 4 做协调者、Sonnet 4 做子 Agent，在内部评估上比单 Agent 提升了 90.2%。但同一篇博客也强调了多 Agent 系统在生产中的可靠性问题------加了三个 Agent 不代表就有三倍的可靠，串行调通了再想并发。2给每条状态记录打上版本号 。 静默的最后写入胜出（Last-Write-Wins）会在没有证据的情况下破坏数据。向量时钟或 HLC（混合逻辑时钟）比物理时间戳可靠得多。3追加式事件日志的存储开销比修复一致性 bug 的人力开销便宜 。 事件溯源的前期实现成本，大概率低于事后追查"为什么 Agent B 基于过期的数据推了一个错误的 Kubernetes 配置到生产集群"。4CRDT 保证数据收敛，但不保证语义正确 。在 CRDT 合并之后加一层语义验证，哪怕只是一个简单的规则检查（"同一配置项不允许出现两个不同值"），也比盲目信任 CRDT 的收敛结果好得多。自动合并只是把问题推迟了，不一定能消除它。5即使在多 Agent 系统中，依然要在 super-step 边界做 checkpoint。 单 Agent 的 checkpoint 机制是多 Agent 状态管理的地基------没有它，前面的四种机制都没法在故障恢复时正常工作。
三个常见的坑
丢失更新 ：两个 Agent 同时读到同一个状态值，各自基于它做出决策后写回。后写入的覆盖先写入的，先写入的那个 Agent 不知道自己辛苦推理出来的结果已经被人静默抹掉了。解法是在写入时带上 expected_version，版本不匹配则拒绝写入并强制 Agent 重新读取最新状态后再决策。
级联污染：一个坏的状态值向下游传播。在多 Agent 依赖链中，一个错误状态造成的破坏会沿着依赖链逐级放大------不像单 Agent 场景下错误只影响自己的输出，多 Agent 场景下错误会变成下游 Agent 的"已知事实"，被当作正确的上下文嵌进后续推理。
时钟偏斜导致的静默数据丢失：如果两个 Agent 用物理时间戳做"最后写入胜出"，时钟快的那台机器永远赢------而且这种错误在测试环境几乎不可能复现，因为测试机器的时钟通常是同步的，到了生产环境的跨数据中心部署才会暴露。解法是用确定性 reducer 或向量时钟替代墙上时间。
结尾
回到开头那个场景：Planner、Coder、Reviewer 共享一个代码仓库。看完这四种机制不难发现，问题其实不在"共享"本身，而在共享的方式------是串行排队（安全但慢），是独立副本最后合并（快但容易炸），是不可变事件流（可回溯但有延迟），是数学可证明的收敛（能自动合并但不懂语义），还是让 LLM 自己决定"这个冲突跟我的计划有没有关系"。
演变轨迹很清楚：从施加强制秩序（串行、锁）到拥抱并发（CRDT、事件流），再到利用智能本身来处理不一致（CoAgent）。每一步都在降低对中心化协调者的依赖，每一步也都在增加对 Agent 自身判断力的信任。
串行阶段信任的是"顺序"，事件溯源阶段信任的是"不可篡改"，CRDT 阶段信任的是"数学"，MTPO 阶段信任的是"LLM 的判断"。信任的对象在升级，但信任的风险也在升级：数学的边界是已知的，LLM 的边界还是一个巨大的问号。
而分布式系统在 Agent 数量超过某个阈值后给人的答案，很可能不是"选哪一种机制"，而是"这几种机制在什么条件下组合用"。
还有一个开环问题：MCP（Model Context Protocol，模型上下文协议）和 Google 的 A2A 协议正在快速成为 Agent 间通信和记忆共享的标准栈，但一致性语义在协议层还完全没有定义。
两个 Agent 通过 MCP 共享一段记忆时，没有机制保证它们看到的是同一个版本的同一个事实。Agent A 写入了一条新的任务状态，Agent B 在 MCP 的另一端读到的是一个中间版本------这些协议定义了"怎么传"，没有定义"传的是什么版本"。这是标准化阶段绕不过去的工程问题。
参考来源：
- Gartner: "Multiagent Systems" (2025): www.gartner.com/en/articles...
- MAST 论文: arXiv:2503.13657 --- Cemri et al., "Why Do Multi-Agent LLM Systems Fail?"（NeurIPS 2025）
- CoAgent 论文: arXiv:2606.15376 --- Lyu et al., "CoAgent: Concurrency Control for Multi-Agent Systems" (2026)
- CodeCRDT 论文: arXiv:2510.18893 --- Pugachev, "Observation-Driven Coordination for Multi-Agent LLM Code Generation" (2025)
- Anthropic Engineering Blog: "How we built our multi-agent research system" (Jun 2025)
- Zylos Research: "AI Agent Memory Architectures for Multi-Agent Systems" (2026.03); "CRDTs and Distributed State Synchronization for Multi-Agent AI Systems" (2026.03)
- AgentMarketCap: "Concurrent Multi-Agent State Management" (2026.04): agentmarketcap.ai/blog/2026/0...
- Confluent: "Event-Driven Multi-Agent Systems" (2025): www.confluent.io/blog/event-...
- Automerge 2.0: automerge.org/blog/autome...
- cr-sqlite: github.com/vlcn-io/cr-...