第4章：经典论文精读 —— 27 篇文献勾出多 Agent 并发与事务的领域全景

如果你在 2026 年走进多 Agent 并发这个领域，会被 27 篇看似散落各处的论文砸晕：1987 年的 Sagas、2006 年的 TL2、2023 年的 Reflexion、2025 年井喷的 SagaLLM/ALAS/SAFEFLOW/CodeCRDT/Aegean、2026 年开年的 Atomix/AgentSTM/ATCC——同一个”事务”概念被反复挪用，但每篇解决的问题、用的方法、得到的结论都不一样。本章不堆论文综述，做一件事：把 27 篇按 5 大流派按时间线钉在一张坐标系里，每篇给出动机/方法/贡献/局限/对 AgentSTM 启示五要素，再横评研究方法论演进（从”5 个 case study”到”14 任务 + 30 trial Wilcoxon + Cohen’s d”）和 5 个领域开放问题。读完你会拥有一份”打开任何这个领域新论文都能 5 秒定位”的坐标系，不再需要重新翻历史。

1. 论文宇宙地图：演进时间线与 5 大流派

39 年时间线，5 个有清晰边界的流派：

1987 ─── 1995 ── 2005 ── 2006 ── 2013 ── 2021 ── 2023 ── 2024 ──── 2025 ─────── 2026
Sagas   STM     Haskell  TL2    Silo   Polyjuice            ┌──────────────┐  ┌──────┐
                STM       │      │      │           ReAct   │ AutoGen      │  │Atomix│
                Schrr/    │      │      │           Reflex  │ MetaGPT      │  │AgntSTM│
                Scott     │      │      │                   │ ChatDev      │  │ATCC  │
                Guerraoui │      │      │           LATS    │ τ-bench      │  └──────┘
                          │      │      │                   │              │
                          └──────┴──────┴───────────────────┤ SagaLLM      │
                          DB 事务地基                        │ ALAS         │
                                                            │ SAFEFLOW     │
                                                            │ CodeCRDT     │
                                                            │ Aegean       │
                                                            │ GoEX         │
                                                            │ GitContextCtrl│
                                                            │ Temporal     │
                                                            └──────────────┘
                                                            Agent 时代爆发

5 大流派对照：

流派	主张	代表论文	处理冲突的方式
DB 时代地基（7 篇）	OCC / 锁 / Saga 范式给软件层并发奠基	Sagas, STM, TL2, Silo, Polyjuice	重做相同事务
Single-Agent Reasoning（3 篇）	LLM 能从失败中学习改下一次尝试	ReAct, Reflexion, LATS	Verbal 反思 + 重试
Multi-Agent 框架（4 篇）	多 Agent 协同，但不管并发一致性	AutoGen, CrewAI, MetaGPT, ChatDev	不处理（或 SOP 串行）
Agent Transaction（8 篇） ⭐	主战场：把事务概念真正引入 Agent 工具调用	SagaLLM, ALAS, SAFEFLOW, CodeCRDT, Aegean, Atomix, AgentSTM, ATCC	多种范式百花齐放
周边支撑（4 篇）	runtime / 持久化 / context / 评测	GoEX, Git Context Controller, Temporal, τ-bench	不处理但提供基础设施

🌟 结论：Agent 并发与事务的领域是”DB 派系”+“Reasoning 派系” 的合流产物。前者提供”四件套”（版本号、读集、写集、commit-time validation），后者提供”LLM 能 reason about why 失败”——两者结合诞生了第四派系（Agent Transaction）。其中 AgentSTM 第一次把”LLM 推理能力”作为冲突恢复的一等公民。

🍎 直觉比喻：DB 时代是水电煤——没了不能活；Reasoning 时代是新能源车的电池——给老底盘装上新驱动。

2. 派系一：DB 时代地基（7 篇）

为什么 Agent 并发与事务的论文必须读这 7 篇 DB 时代论文？因为所有 Agent Transaction 论文使用的术语（OCC、CAS、commit-time validation、saga、compensation、contention manager、abort retry）都来自这 7 篇。不读它们，看 SagaLLM / Atomix / AgentSTM 都是雾里看花。

2.1 Sagas（García-Molina & Salem, 1987）

论文: García-Molina H., Salem K. “Sagas.” ACM SIGMOD Record 1987.

一句话主张：长事务用一连串”短事务 + 补偿动作”组合替代，单步失败回滚整链。

解决什么问题：1980 年代数据库锁住资源等待长事务（如旅行社订票流水线）会让其他事务全部饿死。Sagas 提议把长事务拆成 T1 → T2 → … → Tn 短事务链，每步配补偿动作 C_i，失败时反向执行 C_{i-1} → … → C_1。

方法：

形式定义”saga”为短事务序列 + 补偿序列
给出 forward recovery（继续完成）和 backward recovery（补偿回滚）两种语义
证明 saga 的正确性等价于”全成功 commit”或”全补偿 abort”

贡献：开创”长事务通过补偿分解”范式。后续 30 年微服务、分布式事务（Choreography Saga / Orchestration Saga）、SagaLLM 都建立在这之上。

局限：

隐式串行化假设：补偿链能正确执行的前提是事务已经按确定顺序完成——并发版 Saga 在工业界几乎没有成功案例
补偿不总是可写：发邮件、扣库存、调外部 API，许多动作没有”自然补偿”
补偿级联：链条越长，单点失败的传播代价越大

对 AgentSTM 的对比关系：SagaLLM 把 Sagas 完整移植到 LLM workflow，但继承了串行化和级联失败的两大弱点——AgentSTM 在 τ-bench 实测中以 3.1× 吞吐压过 SagaLLM，本质上就是因为它用 OCC 替代了 Saga 的串行假设。

2.2 Software Transactional Memory（Shavit & Touitou, 1995）

论文: Shavit N., Touitou D. “Software Transactional Memory.” PODC 1995.

一句话主张：把”原子事务”概念从数据库搬到内存编程，用 lock-free 算法替代锁。

解决什么问题：1990 年代多处理器并发编程的锁污染问题——程序员写锁极易死锁、优先级反转、可组合性差。Shavit & Touitou 借数据库事务概念，让程序员写 atomic { ... } 块，运行时负责冲突检测与重试。

方法：

提出 STM（Software Transactional Memory） 抽象：事务记录 read-set + write-set，commit 时验证
给出 lock-free 实现方案：cooperative termination + helping mechanism
证明 obstruction-freedom 进展保证

贡献：奠基论文。“Transactional Memory” 这个词从此标准化，催生 30 年的 STM 研究浪潮。

局限：

静态事务长度假设：原始算法假设事务的 read/write set 大小预先已知
常数因子大：lock-free 实现的复杂度让性能落后于精心写的锁版本
IO 不友好：事务内调外部副作用（写文件、发网络）几乎没法回滚

对 AgentSTM 的对比关系：AgentSTM 直接继承”事务原语 + commit-time validation”两大概念，但把 IO 不友好这个 STM 30 年痛点反过来当机会——Agent 工具调用本来就是异构 IO，AgentSTM 用 ATVar 抽象统一所有外部资源，把 IO 当作版本化对象第一公民。

2.3 Composable Memory Transactions / Haskell STM（Harris et al., 2005）

论文: Harris T., Marlow S., Peyton Jones S., Herlihy M. “Composable Memory Transactions.” PPoPP 2005.

一句话主张：用 Haskell 的纯函数 + 类型系统让 STM 可组合（compose），解决”两个 atomic 块组合后是不是还原子”的问题。

解决什么问题：1995 STM 论文之后 10 年，STM 被发现一个根本短板——锁可以”组合”（A 锁 + B 锁 → 同时持有），但 atomic 块不可组合（atomic { atomic {} }; atomic {} 没有保证整体原子）。

方法：

引入 retry 原语：事务内显式声明”我需要某个条件成立才能继续”
引入 orElse 组合子：让两个 atomic 块可以”或”组合
用 Haskell 的 IO monad / STM monad 隔离副作用——只有纯计算能进 atomic 块

贡献：第一个商业级语言原生 STM（GHC 内置）。证明 STM 在工业界可用——只要语言隔离副作用。

局限：

几乎只能在 Haskell 里跑——其他语言没有 IO monad，副作用隔离做不到
retry / orElse 在生产中使用率远低于预期
Long-running atomic 块依然是性能毒药

对 AgentSTM 的启示：纯函数性是 STM 在传统编程的关键约束——一旦事务里有副作用就崩。AgentSTM 反过来把 Agent 工具调用都建模为”对 ATVar 的 read/write”，把副作用收纳到 ATVar 内部（FileATVar / KVATVar 自己负责持久化与回滚），算是给 Haskell STM 解决不了的”side-effectful transaction”问题给出了 Agent 时代的答案。

2.4 TL2: Transactional Locking II（Dice, Shalev, Shavit, 2006）

论文: Dice D., Shalev O., Shavit N. “Transactional Locking II.” DISC 2006.

一句话主张：全局时间戳 + commit-time validation = STM 的最优实现范式。

解决什么问题：2005 之前的 STM 实现要么在事务过程中做版本检查（侵入开销大），要么有 ABA 问题。TL2 给出第一个简单、正确、高性能的 STM 实现。

方法：

全局原子计数器 clock，每次 commit 时把它读出来作为时间戳
每个变量带版本号 + 锁位
事务执行时：read 用一个 snapshot 时间戳；write 在 commit 时获取写锁、验证 read-set 版本、写入新版本号
证明：TL2 提供 opacity（事务从不见到不一致状态）

贡献：直接成为后续 15 年所有 STM 实现的事实标准。Sun JVM、JikesRVM、各类研究 STM 都用 TL2 范式。

局限：

全局 clock 是争用点（虽然只是 atomic increment，多核扩展性受限）
Long read-only 事务受 clock 偏移影响

对 AgentSTM 的对比关系：AgentSTM 的核心算法就是 TL2 的 Agent 时代版本：每个 ATVar 带 version 号、commit 时 CAS 写入。两者的区别仅在两点——AgentSTM 不用全局时钟（用每变量独立版本号，因为 Agent 事务粒度大、跨机概率低），冲突时用 LLM 重规划而非 identical retry。

2.5 Silo: Speedy Transactions in Multicore In-Memory Databases（Tu et al., 2013）

论文: Tu S., Zheng W., Kohler E., Liskov B., Madden S. “Speedy Transactions in Multicore In-Memory Databases.” SOSP 2013.

一句话主张：把 OCC 推到多核内存数据库的极致——单机可达每秒千万级事务。

解决什么问题：2010 年代内存数据库兴起（Redis、VoltDB），传统 OCC 在多核上扩展性差（共享 commit 序列号成为瓶颈）。Silo 重新设计 OCC：每个 worker thread 用本地 epoch 号代替全局序列号，只在 commit 时与全局 epoch 同步。

方法：

每核心独立的事务执行
Epoch-based 时间戳：32-bit 全局 epoch + 32-bit 本地 sequence
Commit 协议：lock write-set → fence → validate read-set → write
用 fence + epoch 号做 group commit，磁盘日志不阻塞

贡献：证明 OCC 在多核上能撑到 hardware-bound（无锁、cache-friendly）。后续大量在线事务系统（如 Scyllav、Aerospike）借鉴。

局限：

内存数据库假设——磁盘事务难复用
高争用下还是会回退到串行性能

对 AgentSTM 的对比关系：Silo 提供了”epoch-based contention 检测”思路——AgentSTM 论文里 Atomix 的 frontier-gated commit 借鉴了 epoch 概念，但 AgentSTM 自己用的是更细粒度的 per-resource 版本号（论文 RQ4 实验明确证明 epoch-coarse 检测让 targeted replan 失效）。Silo 是 OCC 工程极致的代表，但 AgentSTM 选择了更细粒度路线。

2.6 Polyjuice: High-Performance Transactions via Learned Concurrency Control（Wang et al., 2021）

论文: Wang J., Ding J., Wang H., Shi W., Li Z., Li J. “Polyjuice: High-Performance Transactions via Learned Concurrency Control.” OSDI 2021.

一句话主张：用 RL 学习”什么时候该锁、什么时候该乐观”，自适应不同 workload。

解决什么问题：OCC 在低争用下吞吐高、高争用下惨；2PL 反过来。但真实 workload 在两端之间游走。能不能让系统自动在 OCC / 2PL 之间切换？

方法：

把”操作级并发控制”（每个 operation 独立选 OCC 还是锁）建模为 RL 决策
用 PPO 学习一个策略：状态是 workload 特征 + 当前争用度，动作是 OCC / 锁 / 等待
在 TPC-C / YCSB 上证明比静态选择高 1.5-3×

贡献：第一篇把 ML 用在并发控制核心策略上的论文。开创”learned database internals” 一支。

局限：

训练成本高，离线学习
在 workload 漂移下要重训练
决策粒度仍在 operation 级，不到 plan 级

对 AgentSTM 的对比关系：Polyjuice 是 ATCC（2026）的直接前身——ATCC 把 Polyjuice 思路搬到 Agent 事务层。AgentSTM 与 ATCC 是互补关系：ATCC 优化”什么时候用 OCC vs 锁”（access strategy），AgentSTM 优化”OCC 冲突后做什么”（recovery strategy）。论文里 AgentSTM 明确表态”两者可以叠加”。

2.7 Contention Management 双篇（Scherer/Scott + Guerraoui/Herlihy/Pochon, 2005）

论文 A: Scherer III W. N., Scott M. L. “Advanced Contention Management for Dynamic Software Transactional Memory.” PODC 2005.

论文 B: Guerraoui R., Herlihy M., Pochon B. “Robust Contention Management in Software Transactional Memory.” OOPSLA 2005.

一句话主张：STM 冲突时，谁让谁这件事不是细节——选错策略会导致 livelock（活锁，论文里叫”failure to make progress”）。

解决什么问题：1995 STM 论文证明事务可以并发执行，但没说冲突时哪个事务该被 abort。简单策略（“年长事务赢”）会饿死短事务，“年轻事务赢”会让长事务永远完不成。

方法：

A 篇枚举 8 种 contention manager 策略：Polite / Karma / Eruption / Kindergarten / Polka / Greedy / …
B 篇用博弈论分析”哪种策略能在最坏 workload 下保证 livelock-free”
都给出详尽的 workload 实验

贡献：奠定 contention management 子领域。所有后续 STM / OCC 实现都要选 contention manager。

局限：

策略太多没有”通用最优”
高争用下都退化得难看

对 AgentSTM 的启发：AgentSTM 的 Backoff-with-Escalation 三段式（OCC → LLM 重规划 → 降级悲观锁）就是 contention manager 的 Agent 时代版本。Theorem 1（Bounded-Retry Impossibility）的灵感来自 livelock 分析——论文明确把它表述为”the multi-agent analog of livelock in STM contention management”，并把 Scherer/Scott 和 Guerraoui 论文作为直接引用。

🧠 DB 派系小结：7 篇论文给出 4 个核心概念：Saga（长事务补偿）、STM（事务原语 + 副作用隔离）、TL2（commit-time validation 范式）、Contention Management（谁让谁）。Agent Transaction 派系的所有论文都建立在这 4 个概念之上——读不懂这 7 篇，等于没法判断 SagaLLM 的局限、Atomix 的合理性、AgentSTM 的”escape via intent preservation”在 contention management 谱系中处于什么位置。

3. 派系二：Single-Agent Reasoning（3 篇）

这一派不解决并发——它解决”单 Agent 任务难度”。但它是 AgentSTM 的关键对照组：Reflexion 类的 verbal reinforcement 是”plan rigid retry”在 NLP 化包装下的延续。本节 3 篇是理解 AgentSTM “intent preservation” 创新点的镜面。

3.1 ReAct: Synergizing Reasoning and Acting in Language Models（Yao et al., 2023）

论文: Yao S., Zhao J., Yu D., et al. “ReAct: Synergizing Reasoning and Acting in Language Models.” ICLR 2023.

一句话主张：LLM 同时输出”思考（Thought）“和”行动（Action）“，交错进行。

解决什么问题：CoT（Chain-of-Thought）让 LLM 推理，但只在”自己脑内”——不能调工具。Tool-using LLM 调工具但缺中间推理。ReAct 把两者合一：每步先输出思考，再输出动作。

方法：

Prompt 模板：Thought: ... Action: ... Observation: ... 循环
在 HotpotQA、ALFWorld、WebShop 上验证
证明 Thought 显著降低工具调用错误率

贡献：奠定 LLM Agent 的标准 prompt 范式。AutoGen / CrewAI 等所有现代 Agent 框架的”loop”骨架都是 ReAct 形态。

局限：

单 Agent，不涉及并发
长任务下 reasoning 步骤过多导致漂移
失败时只能重头再来，没有显式反思机制（Reflexion 补这块）

对 AgentSTM 的关系：ReAct 提供”Agent loop”骨架，AgentSTM 在这个骨架外面包了一层事务上下文（每个 ReAct loop 在一个 AgentTransaction 里跑）。ReAct 是 Agent，AgentSTM 给 Agent 加并发安全——两者是装配关系不是替代关系。

3.2 Reflexion: Language Agents with Verbal Reinforcement Learning（Shinn et al., 2023）

论文: Shinn N., Cassano F., Gopinath A., Narasimhan K., Yao S. “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023.

一句话主张：Agent 失败后在记忆中存一段”我哪里错了”的反思，下次执行时把反思塞进 prompt。

解决什么问题：单 Agent 任务失败时，传统重试就是”再跑一次同样代码”。Reflexion 让 LLM 自己生成反思文本，作为下一次的 episodic memory。

方法：

三组件：Actor（执行 task）、Evaluator（判定成败）、Self-Reflection 模块（生成反思）
反思文本存入”memory”，下次执行时拼接到 prompt 前
在 HumanEval、AlfWorld、WebShop 上跑出 SOTA

贡献：第一篇把”verbal RL”概念落地的工作。证明 LLM 能从失败中学习。

局限：

Single-Agent 假设——记忆和反思都是单 Agent 内部循环
Reflection 是文字层的，executed plan 不变——这是 AgentSTM 论文 §4.4 拿来对比的关键点
Long-horizon 任务下 memory 膨胀

对 AgentSTM 的关系（论文里的核心对照组）：AgentSTM 论文 RQ2 设计了 “same-plan verbal-retry control” 实验直接对标 Reflexion——让 LLM 在文本上反思但 executed plan 保持原样，结果 Jaccard token 保持率 0.115（与 Structured+Full 的 0.143 几乎可比），但 conflict 次数没下降（4.4±0.5 vs 4.0±0.0，95% CI 不重叠）。

🧠 结论的转译：Verbal 反思 ≠ Plan 改写。Reflexion 的反思在多 Agent 并发下解决不了 race，因为 race 不是”task 难”，是”两个 agent 抢同一个资源”——你 verbal 反思一万遍也没用，必须真改 plan。

3.3 LATS: Language Agent Tree Search（Zhou et al., 2024）

论文: Zhou A., Yan K., Shlapentokh-Rothman M., Wang H., Wang Y. “LATS: Language Agent Tree Search Unifies Reasoning Acting and Planning in Language Models.” ICML 2024.

一句话主张：用 MCTS（蒙特卡洛树搜索）让 LLM Agent 探索多条 reasoning 路径，回退低分分支。

解决什么问题：Reflexion 是线性反思——失败后只产生一个新 prompt。LATS 让 Agent 在每步保留多个候选 thoughts，用价值函数评分，选最优分支。

方法：

把 LLM Agent 的执行建模为 MCTS 树：Action 是 tool call，State 是 prompt 状态
每个节点有 visit count + value estimate
用 LLM 自己作为 value function

贡献：把”探索 vs 利用”经典 RL 张力引入 LLM Agent。在 HotpotQA / Programming 上比 ReAct/Reflexion 高 5-10%。

局限：

树搜索代价高（每步多路调 LLM）
仍是单 Agent
需要好的 value function（LLM-as-judge 在长任务下不稳）

对 AgentSTM 的关系：LATS 解决”任务空间太大该怎么搜”，与 AgentSTM 解决的”多 Agent 共享 state 怎么不冲突”不在同一维度。但LATS 的”分支 + 回退”思想给 AgentSTM 第 6 章 Replan 设计提供启发——重规划可以输出多个候选 plan，让 Agent 验证哪个不冲突再选。论文未来工作章节明确点名”LATS-style 分支重规划”是后续方向。

🧠 Single-Agent 派系小结：3 篇论文证明 LLM 能 reason about why 失败。但它们都假设单 Agent 在隔离环境——Agent 对手是”task 难度”不是”另一个 Agent 的并发写”。当场景变成多 Agent，这一派的方法都不够：Reflexion 的反思救不了 race，LATS 的树搜索不会主动避让其他 Agent。AgentSTM 把这一派”LLM 推理失败”的能力扩展到”多 Agent 冲突恢复”，是这两派的合流。

4. 派系三：Multi-Agent 框架（4 篇）

这一派造了”多个 Agent”的舞台，但没有装并发安全栏杆。本节 4 篇是 AgentSTM 实测对比的工业基线（无保护场景下 79% 损坏率的来源）。

4.1 AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation（Wu et al., 2023）

论文: Wu Q., Bansal G., Zhang J., et al. “AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation.” arXiv 2308.08155.

一句话主张：多个 Agent 通过自然语言对话协同，每个 Agent 有自己的角色和工具集。

解决什么问题：单 Agent 工具调用对复杂任务（多角色协作如代码 review、辩论）力不从心。AutoGen 提供 GroupChat / SequentialChat / NestedChat 三种对话拓扑。

方法：

AssistantAgent + UserProxyAgent 抽象
用 LLM 做”该谁说话”的调度
工具调用作为消息类型嵌入对话

贡献：成为最流行的多 Agent 编排框架之一。GitHub 30k+ stars（截至 2026-05）。

局限：

真并发但无并发保护：GroupChat 模式下多 Agent 可同时调工具改共享 state，框架不检测冲突
调度依赖 LLM 自己判断，长链路下不稳
没有事务概念

对 AgentSTM 的关系（无保护对照组）：AgentSTM 论文实测在 AutoGen-style 并发设置下，14 个 ground-truth task 只有 3 个能通过校验（21%）。AgentSTM 提供了一个 AutoGen Adapter（src/agent_stm/autogen_adapter.py），可以 drop-in 替换 AutoGen 的 GroupChat 提供 STM 保护——这是 AgentSTM 走向落地的关键工程贡献。

4.2 CrewAI: Framework for Orchestrating Role-Playing Autonomous AI Agents（Moura, 2024）

论文/项目: Moura J. “CrewAI.” GitHub 2024.

一句话主张：用”团队（Crew）+ 角色（Role）+ 任务（Task）“三个抽象模拟真实团队工作流。

解决什么问题：AutoGen 的 GroupChat 太自由（Agent 自己决定该谁说话），CrewAI 强行结构化为”manager → worker”层级。

方法：

Role 定义 Agent 的 persona、tools、goal
Task 定义工作单元，可指派给 Role
Crew 把 Role 和 Task 编排成 sequential / hierarchical workflow

贡献：模板化多 Agent 协作。文档友好，开箱即用。

局限：

与 AutoGen 同病：多 Agent 并发执行时不管共享 state 一致性
角色定义太死，复杂任务下角色边界模糊

对 AgentSTM 的关系：和 AutoGen 同档——属于”高层编排正确，低层并发裸跑”。

4.3 MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework（Hong et al., 2024）

论文: Hong S., Zhuge M., Chen J., et al. “MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework.” ICLR 2024.

一句话主张：用 SOP（Standard Operating Procedure）把多 Agent 工作流硬性规定为线性流水线，强制串行。

解决什么问题：观察到自由对话型多 Agent（AutoGen 早期）容易跑偏。MetaGPT 借鉴软件公司 SOP——产品 → 架构 → 编码 → QA 严格串行，每个 Agent 输出标准化文档（PRD、Design、Code、Test）。

方法：

5 个固定角色：ProductManager、Architect、Engineer、QA、ProjectManager
角色间通过结构化文档（schema 化）传递
产出物保存到内存/磁盘

贡献：Demo 效果惊艳——给一句话能跑出完整代码库。引领”SOP 化多 Agent”路线。

局限：

强行串行化放弃了并发吞吐——每个 task 一次只一个 Agent 在跑
SOP 死板，复杂任务里 Agent 角色界限不清
串行不代表无并发问题：两个独立 task 跑两个 SOP 时还是会撞

对 AgentSTM 的对比关系：MetaGPT 是”避免并发问题”的代表——用串行换正确。AgentSTM 是”拥抱并发”的代表——用乐观执行 + LLM 重规划换吞吐。两者的 throughput 差距在论文 RQ3 里被量化（AgentSTM 在 τ-bench airline workload 上 205 vs SagaLLM 的 66 tasks/s，3.1×）。

4.4 ChatDev: Communicative Agents for Software Development（Qian et al., 2024）

论文: Qian C., Liu W., Liu H., et al. “ChatDev: Communicative Agents for Software Development.” ACL 2024.

一句话主张：模仿瀑布模型软件开发流程的多 Agent 协作框架，专攻代码生成。

解决什么问题：MetaGPT 偏通用，ChatDev 专做软件开发，把 SOP 进一步细化为软件工程瀑布——Designing / Coding / Testing / Documenting 四阶段，每阶段两个 Agent 对话生成产出。

方法：

双 Agent 对话生成（CEO + CTO 讨论需求；Programmer + Reviewer 写代码）
“Communicative Dehallucination” 减少幻觉
产出 GitHub-ready 代码库

贡献：在自动化软件开发上跑出完整可运行的代码库 demo，证明 LLM 能产出有用代码。

局限：

与 MetaGPT 同病：SOP 串行
单一应用场景（软件开发），通用性弱
无并发保护——若让两个 Programmer Agent 同时改代码会冲突

对 AgentSTM 的关系：ChatDev 与 MetaGPT 同属”SOP 串行”派。AgentSTM 在论文里把它们打包描述为”forfeit concurrency to gain safety”——这一派的核心问题是并发吞吐被完全放弃。

🧠 Multi-Agent 框架派系小结：4 篇论文呈现一个明显的”二元”光谱——AutoGen / CrewAI 站在”真并发但无保护”端，MetaGPT / ChatDev 站在”SOP 串行换正确”端。AgentSTM 是这两端之间的中间道路——保留真并发，但用 STM + LLM 重规划提供保护。

5. 派系四：Agent Transaction 主战场（8 篇）

这是本模块的主战场。8 篇论文都明确把”事务（transaction）“概念引入多 Agent，但路线分化。按时间和方法分两组：Saga 派（SagaLLM、ALAS、SAFEFLOW）和 OCC/CRDT/Consensus 派（CodeCRDT、Aegean、Atomix、AgentSTM、ATCC）。

5.1 SagaLLM: Context Management, Validation, and Transaction Guarantees（Chang & Geng, VLDB 2025）

论文: Chang E. Y., Geng L. “SagaLLM: Context Management, Validation, and Transaction Guarantees for Multi-Agent LLM Planning.” VLDB 2025.

一句话主张：把 Sagas（1987）完整移植到 LLM workflow，每步配补偿动作链。

解决什么问题：第一篇明确提出”LLM workflow 需要事务保证”的论文。观察到 Agent 跑长流程时部分步骤失败需要回滚，而当时没有任何系统提供。

方法：

把 LLM Agent workflow 建模为 saga：T1 → T2 → … → Tn
每个 Ti 配 Ci 补偿（用 LLM 自己生成补偿动作描述）
失败时 backward recovery 回滚已完成步骤

贡献：开创 Agent Transaction 子领域。VLDB 2025 是这领域第一篇主流数据库会议论文。

局限：

串行化代价：补偿链假设事务串行，并发 saga 没有解决方案——τ-bench airline workload 实测 SagaLLM 66 tasks/s vs AgentSTM 205（3.1× 差距）
Compensation cascade：30% fault injection 下 SagaLLM 完成率崩塌到 10%（5/50 tasks），因为单点失败触发全 chain 补偿
补偿动作正确性：让 LLM 自己生成补偿可能错（如”删除”补偿”插入”，但 LLM 可能漏掉级联依赖）

对 AgentSTM 的对比关系：SagaLLM 与 AgentSTM 是 Agent Transaction 派系内部的两条主线——前者继承 1987 Saga 范式，后者继承 1995 STM 范式。AgentSTM 论文 RQ3 把 SagaLLM 设为头号 baseline，量化两者在并发吞吐和故障鲁棒性上的差距，得到的结论是STM 派系在多 Agent 真并发场景下显著优于 Saga 派系。

5.2 ALAS: Transactional and Dynamic Multi-Agent LLM Planning（Geng & Chang, 2025）

论文: Geng L., Chang E. Y. “ALAS: Transactional and Dynamic Multi-Agent LLM Planning.” arXiv 2511.03094, 2025.

一句话主张：SagaLLM 的扩展——加上 local repair（局部修复）和 idempotency keys（幂等键），减少补偿级联。

解决什么问题：SagaLLM 的 compensation cascade 太严重。ALAS 引入两件武器：

Local repair：单步失败不一定全 chain 回滚，先尝试在本地修复（如重新生成内容）
Idempotency key：每个动作带唯一 ID，重复执行无副作用——避免”已经发了的邮件再发一次”

方法：

在 SagaLLM 框架基础上增加 LocalRepairAgent
每个 tool call 自动加 idempotency token
失败时先 local repair，3 次失败再回退到 saga 补偿

贡献：SagaLLM 路线的重要补丁。把 fault tolerance 从 10% 提到约 30%（论文自报数据）。

局限：

仍是 Saga 派——并发问题没解决
Local repair 的”重新生成”对 nondeterministic 工具调用语义模糊
Idempotency key 设计假设外部服务支持——大量真实 API 不支持

对 AgentSTM 的关系：ALAS 把 SagaLLM 的补偿级联问题打了补丁，但没有改变”串行 saga”这一根本约束——AgentSTM 论文里把 ALAS 与 SagaLLM 一起归为”compensation-style”派系，认为它们和真并发是结构性不兼容。

5.3 SAFEFLOW: A Principled Protocol for Trustworthy and Transactional Autonomous Agent Systems（Li et al., 2025）

论文: Li P., Wang Y., Zhang H., et al. “SAFEFLOW: A Principled Protocol for Trustworthy and Transactional Autonomous Agent Systems.” arXiv 2506.07564, 2025.

一句话主张：从协议层面规定多 Agent 必须遵守 4 个属性（Safety / Atomicity / Fault tolerance / Explainability），用形式化方法证明。

解决什么问题：SagaLLM / ALAS 是工程方案。SAFEFLOW 走形式化路线——给出一套定义明确、可形式化的 transactional protocol。

方法：

形式定义 4 属性
给出协议规范（如 commit 需要 quorum 同意、abort 需要 audit log）
证明协议在某种攻击模型下满足 4 属性

贡献：把 Agent Transaction 推向形式化方向。给出可被 model checking 验证的协议。

局限：

形式化代价：协议复杂、实现成本高
性能数据弱（论文里实测吞吐显著低于 SagaLLM）
假设强（如”Agent 不会撒谎”——和 Byzantine 假设抵触）

对 AgentSTM 的关系：SAFEFLOW 是 Agent Transaction 派系里形式化派的代表。AgentSTM 是工程派，方法论上互补——AgentSTM 可以借 SAFEFLOW 的形式定义来强化自己的 Theorem 1/2 表述（论文里 Theorem 是半形式的，给读者直观理解为主）。两派系不是对抗，是抽象层级不同。

5.4 CodeCRDT: Observation-Driven Coordination for Multi-Agent LLM Code Generation（Pugachev, 2025）

论文: Pugachev S. “CodeCRDT: Observation-Driven Coordination for Multi-Agent LLM Code Generation.” arXiv 2510.18893, 2025.

一句话主张：用 CRDT（Conflict-free Replicated Data Types）让多 Agent 协同编辑代码——每个 Agent 自己编辑，最后用 CRDT merge 算法合并。

解决什么问题：多 Agent 改同一份代码（如同时给一个 module 加 5 个函数），lock 太强、Saga 不合适、OCC 容易冲突。CRDT 是分布式系统里”无锁最终一致”的标准答案——CodeCRDT 把它搬到代码生成场景。

方法：

把代码 AST 建模为 CRDT（每个 AST 节点带 unique ID + causal vector clock）
多 Agent 各自生成 AST 修改
用 RGA（Replicated Growable Array）算法 merge

贡献：Agent 协同编辑的另一条路线。无需协调，最终一致。

局限：

5-10% 残余语义冲突：CRDT 保证 syntactic merge，但 semantic 可能不对（两个 Agent 各加了一个函数都名为 helper()）
这 5-10% 需要人工介入或额外验证步骤
不适合需要事务原子性的场景（订单 / 支付 / 状态机转换）

对 AgentSTM 的对比关系：CodeCRDT 选的是”放弃强一致换无协调”——这与 AgentSTM 的”乐观 + 验证 + 重规划”是不同哲学。两者目标场景不同：CodeCRDT 适合代码协同编辑这种”merge 主导”任务；AgentSTM 适合订单/booking 这种”原子状态转移”任务。生产部署可同时用——代码用 CodeCRDT，business state 用 AgentSTM。

5.5 Aegean: Reaching Agreement Among Reasoning LLM Agents（Ruan et al., 2025）

论文: Ruan C., Wang Y., Shi Z., Li J. “Reaching Agreement Among Reasoning LLM Agents.” arXiv 2512.20184, 2025.

一句话主张：把分布式共识协议（Paxos/Raft 类）适配到 LLM Agent，让多个 Agent 对决策达成一致。

解决什么问题：多 Agent 投票决定一个事（如”要不要批准这个交易”），单纯多数投票不够鲁棒（一个 Agent 故障会卡住）。Aegean 引入分布式共识协议保证：

多数活着 → 能达成一致
决策不可撤销
网络分区下安全

方法：

把 Paxos 改造：proposer 提案是自然语言描述
Acceptor 投票时不只是 yes/no，还能给出 LLM 评分
Leader election 用 LLM 判断”哪个 Agent 当下最合适做 leader”

贡献：把分布式共识带入 LLM Agent。在 Byzantine Agent 假设下提供安全保证。

局限：

目标是 decision agreement，不是 state consistency——Aegean 解决”多个 Agent 投票投同一个结果”，AgentSTM 解决”多个 Agent 共享 state 不被并发写坏”。两者不是替代关系
通信复杂度高（Paxos 经典 N² 消息）
LLM 推理嵌入投票协议增加了不确定性

对 AgentSTM 的关系：Aegean 与 AgentSTM 在领域里被同时提到，但关注层不同——决策 vs 状态。AgentSTM 论文 §4 “Related Work” 明确写：“Aegean adapts distributed consensus protocols for multi-agent agreement but targets decision-making, not shared-state consistency.”

5.6 Atomix: Timely, Transactional Tool Use for Reliable Agentic Workflows（Mohammadi et al., 2026）

论文: Mohammadi B., Potamitis N., Klein L., Arora A., Bindschaedler L. “Atomix: Timely, Transactional Tool Use for Reliable Agentic Workflows.” arXiv 2602.14849, 2026 (ICML 2026 投稿).

一句话主张：用 frontier-gated commit——副作用先 buffer，等”进度 predicate”确认安全后才真正提交。

解决什么问题：Agent 调外部工具（发邮件、扣钱）时，一旦提交就不可撤销。Atomix 让所有副作用先 stage，由”frontier”决定何时安全提交：

Frontier 是个 predicate，描述”workflow 已经走到了一个安全 checkpoint”
只有 frontier 推进过某个事务的 stage 点，事务才真正 commit

方法：

每个工具调用包装为 “stage → validate → commit” 三段
引入 epoch 时钟跟踪 progress
失败时整个 epoch 回滚（rigid retry）

贡献：第一个把”延迟提交 + progress gate”概念引入 LLM Agent。在外部副作用敏感场景（fintech、医疗）很合适。

局限：

冲突恢复仍是 plan-rigid retry：Atomix 检测到冲突就丢弃 epoch 重做，没有重规划机制
粗粒度检测：epoch 级冲突信号”something in this epoch conflicted”，无法定位到具体资源——AgentSTM 论文 RQ4 实验直接证明：在 Atomix-style epoch 检测下，targeted replan 完全失效（abort 50.6% → 50.9%，几乎无变化）
推迟 commit 会增加端到端延迟

对 AgentSTM 的对比关系：Atomix 是 AgentSTM 论文 RQ4 实验的核心对照组。AgentSTM 论文里”orthogonality experiment”明确证明：fine-grained 冲突检测 + targeted replan = 必须搭配，缺一不可。Atomix 只做粗检测+重做，AgentSTM 做细检测+重规划，两者的差距是”5.3% abort vs 50.9% abort”（同 workload 同 contention 设置）——这是 AgentSTM 区别于所有 epoch-based 方案的核心数据。

5.7 AgentSTM ⭐（Anonymous, ARR/EMNLP 2026）

论文: Anonymous. “Beyond Blind Retry: LLM-Guided Conflict Resolution for Multi-Agent Systems.” ARR May 2026 / EMNLP 2026 投稿.

一句话主张：把 STM 移植到 Agent 工具调用层，冲突时用 LLM 重规划替代 identical retry——这一步是 STM 30 年第一次根本性范式改变。

解决什么问题：前面 6 篇论文都没解决”高并发下 Agent 怎么不冲突”——SagaLLM 串行慢、CodeCRDT 留 5-10% 语义冲突、Atomix 粗检测不会重规划。AgentSTM 给出第一个”真并发 + 100% ground-truth task 正确”的方案。

方法：

ATVar：版本化资源 wrapper（File / KV / DB 统一接口）
AgentTransaction：read-set / write-set 跟踪
ConflictDetector：commit-time 版本验证
LLM Replan Engine：冲突时把结构化 conflict metadata 注入 prompt，让 LLM 生成不同 plan
Backoff-with-Escalation：3 次重规划失败 → 降级悲观锁

关键贡献（按论文宣称）：

Theorem 1 (Bounded-Retry Impossibility)：plan-rigid retry 在 n>k 下必然有人永久失败
Theorem 2 (Intent-Preserving Escape)：随机资源选择下，重规划失败概率 ≤ ((n-1)/(|R|-1))^k，指数级趋零
Same-plan verbal-retry control 实验：分离”verbal 反思”与”plan 改写”的效果（Reflexion-style 对照组得分 0.115 vs intent-preserving 0.143，但 conflict 没下降）
14-task ground-truth benchmark：unprotected 21% vs AgentSTM 100%

局限（论文 Limitations 章自承）：

单 LLM 评测（doubao-code-preview），未跨多模型完整对比
LLM contention scan 仅单次运行（API cost），未做 30-trial Wilcoxon
Jaccard token retention 是 surface-level metric，不是 semantic similarity
单机原型，分布式部署未实测
Cooperative agent 假设，Byzantine 不处理

对其他论文的整合：AgentSTM 论文 §4 Related Work 中明确把自己定位为：

与 SagaLLM：取代关系（OCC vs Saga 范式的胜出）
与 Atomix：互补但优于（细 vs 粗检测、重规划 vs 重做）
与 ATCC：互补（ATCC 选 access strategy，AgentSTM 选 recovery strategy）
与 Reflexion：对照组（verbal vs plan-level 反思的差别）
与 STM 经典：直接继承（TL2 范式 + Scherer/Scott 的 contention manager 思想）

🌟 结论：AgentSTM 是当前（2026-05）多 Agent 并发与事务领域 最完整的理论 + 系统 + 评测三位一体的工作——理论层有 2 个定理、系统层有 800 行可跑 prototype、评测层有 14-task ground-truth + Wilcoxon + Cohen’s d 统计学严谨度。

5.8 ATCC: Adaptive Concurrency Control for Unforeseen Agentic Transactions（Zhou et al., 2026）

论文: Zhou W., Wang Z., Peng Z., Chen H., Zhang Y., Yu G. “ATCC: Adaptive Concurrency Control for Unforeseen Agentic Transactions.” arXiv 2603.13906, 2026.

一句话主张：用 RL 自适应地在 OCC 和悲观锁之间切换——根据 workload 特征动态选最优。

解决什么问题：OCC 在低争用快、高争用差，悲观锁反过来。ATCC 把 Polyjuice (2021) 的 RL learned concurrency control 思路搬到 Agent 事务层。

方法：

状态：当前 contention 度、Agent 数、resource 数、最近 abort 历史
动作：每个事务用 OCC / 悲观锁 / 等待
用 PPO 训练 + DB-layer 模拟器
在 LLM Agent workload 上比固定策略高 20-40%

贡献：把”learned concurrency control”扩展到 Agent 事务层。给 ATVar 类系统提供智能策略选择。

局限：

训练成本——需要构造 representative agent workload
workload 漂移要重训
决策粒度仍是 access strategy，不到 plan 改写

对 AgentSTM 的关系：互补。AgentSTM 论文里把它表述为：“ATCC optimizes the access strategy (when to lock); AgentSTM optimizes the recovery strategy (what to do after conflict). The approaches are complementary.” 实际生产可以双层用——ATCC 选 OCC vs 悲观，OCC 路径冲突后用 AgentSTM 重规划。

🧠 Agent Transaction 派系小结：8 篇论文呈现 3 条主线 +1 条形式化线 +1 条共识线：

工程主线：
  Saga 派 (SagaLLM, ALAS) ── 串行补偿 ── 慢但简单
  STM 派 (AgentSTM)        ── 乐观重规划 ── 高并发 + LLM 推理
  CRDT 派 (CodeCRDT)        ── 无协调 merge ── 适合代码场景但有 5-10% 语义残留

辅助线：
  形式化派 (SAFEFLOW)       ── 协议正确性证明
  共识派 (Aegean)           ── 决策一致而非状态一致

进度门 派：
  Atomix                     ── frontier-gated commit ── 副作用敏感场景
  ATCC                       ── 学习选 OCC/锁 ── 与上述任何派系互补

AgentSTM 处于 STM 派的旗手位置，与其他派系大多是互补、对比、或对照关系，仅与 SagaLLM 在”是否串行化”上是对抗关系。

6. 派系五：周边支撑（4 篇）

这一派不直接做事务，但提供基础设施——runtime、context、persistence、benchmark。

6.1 GoEX: Perspectives and Designs Towards a Runtime for Autonomous LLM Applications（Patil et al., 2024）

论文: Patil S. G., Zhang T., Xie S., Chen Z., Gonzalez J. E., Stoica I. “GoEX: Perspectives and Designs Towards a Runtime for Autonomous LLM Applications.” arXiv 2404.06921, 2024.

一句话主张：LLM Agent 需要一个”runtime”层——管理工具调用、状态、安全、可撤销。

解决什么问题：早期 Agent 系统直接调 LLM API + 调工具，没有 runtime 抽象。GoEX 提议把 Agent 视作”OS process”，runtime 提供调度、隔离、回滚。

方法：

提出 “Post-Facto Validation” 概念：动作执行后用 LLM-as-judge 验证
“Undo Actions”：动作执行时记录回滚步骤
沙盒化 + 速率限制

贡献：为 Agent runtime 子领域奠基。AutoGen 后期版本、Temporal 都借鉴 GoEX 概念。

局限：

偏概念论文（perspectives & designs），实现层薄
没有事务概念（commit / abort / isolation）

对 AgentSTM 的关系：GoEX 是 AgentSTM 的前置概念——AgentSTM 可以视作 “GoEX 的事务层”。两者抽象层不同，可叠加。

6.2 Git Context Controller: Manage the Context of LLM-based Agents like Git（Wu et al., 2025）

论文: Wu J., Hu M., Zhang Y., Chen K. “Git Context Controller: Manage the Context of LLM-based Agents like Git.” arXiv 2508.00031, 2025.

一句话主张：把 LLM Agent 的 context 管理建模为 git——版本、分支、merge、cherry-pick。

解决什么问题：长任务 Agent 的 context 膨胀、丢失、污染。GCC 把 context 抽象为可版本化对象，Agent 可以 fork、merge、回滚 context。

方法：

Context as DAG of commits
Branching：探索性任务可以 branch 后失败 merge
Diff / merge：基于 LLM 的语义 merge

贡献：把 git 思想搬到 context 层。Agent 可以”试错而不污染 main context”。

局限：

与状态一致性正交——只解决 context，不解决共享 state
LLM-based merge 有错误率

对 AgentSTM 的关系：完全互补。GCC 管 context（每个 Agent 自己的 working memory），AgentSTM 管 shared state（多 Agent 共同读写的资源）。两层独立，可同时用。

6.3 Temporal: Building AI Agents That Overcome the Complexity Cliff（Temporal, 2025）

资料: Temporal Technologies Inc. “Building AI Agents That Overcome the Complexity Cliff.” Temporal Blog, 2025.

一句话主张：用 durable execution（持久执行）让 Agent workflow 在崩溃后从 checkpoint 续跑。

解决什么问题：Agent 长流程跑到一半崩溃（API 超时、容器重启）后，要么从头重跑（贵），要么状态丢失。Temporal 把 workflow 步骤记录到持久日志，崩溃后重新执行 = 从日志重放到当前进度。

方法：

Workflow 函数声明为 durable
每步调用记录到日志（DB 或对象存储）
失败重启时从日志重放
提供 retry / timeout / saga 内建模板

贡献：成熟工业级的 durable execution 平台。AWS Step Functions、Cadence 类似思路。

局限：

不感知 Agent 语义——把 Agent 视作通用 workflow，没有事务隔离
处理”工作流崩溃”，不处理”工作流内部 race”
日志开销

对 AgentSTM 的关系：完全互补。Temporal 管 workflow 持久化（崩溃恢复），AgentSTM 管 workflow 内部并发（agent 间 race）。生产部署可以同时用——Temporal 包外层，AgentSTM 在内层提供事务保护。

6.4 τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains（Yao et al., 2024）

论文: Yao S., Narasimhan K., Yue X. “ $\tau$ -bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains.” arXiv 2406.12045, 2024.

一句话主张：第一个针对 Agent 工具调用的 benchmark——airline 和 retail 两个 domain，每个 100+ task + ground-truth。

解决什么问题：之前 Agent 评测要么靠 GAIA (general assistant benchmark) 偏 QA，要么靠合成 task 不真实。τ-bench 提供：

真实 schema 模拟（航空、零售的 booking system）
User simulator（用 LLM 模拟用户复杂交互）
Ground-truth checker

方法：

用 LLM-as-user 提供动态对话
用 ground-truth state 对比判定成败
pass^k metric：k 次重跑全部成功的概率

贡献：成为 LLM Agent 评测的事实标准。AgentSTM、Atomix 等都以 τ-bench airline 为对照 workload。

局限：

单 Agent 评测——本身不测多 Agent 并发
LLM-as-user 引入额外不确定性
仅 2 个 domain

对 AgentSTM 的关系：AgentSTM 论文 §3.3 RQ3 用了 τ-bench-inspired 的 airline workload（不是 τ-bench 原版，是适配多 agent 并发场景的改造），明确在 Limitations 里强调”this is a custom workload modelled on τ-bench’s airline domain, not the official τ-bench evaluation harness”。τ-bench 是评测工具，AgentSTM 是被评的方法——两者关系是 benchmark 与系统。

🧠 周边支撑派系小结：4 篇论文给出 Agent 系统的 4 个非事务但必要的层——runtime / context / persistence / benchmark。它们都不与 AgentSTM 竞争，反而互补可叠加：生产部署可以是 GoEX 做 runtime + Temporal 做 durable execution + Git Context Controller 管 context + AgentSTM 做事务 + τ-bench 评测，五层各管一摊。

7. 研究方法论的演进

读完 27 篇，会发现”评测 Agent 事务系统的方法论”自身在演进——而且演进得很快。本节梳理 4 个明显的演进维度。

7.1 Benchmark 演进：从 5 个 case study 到 14-task ground-truth

2023 (ReAct/Reflexion): 5-10 个手工 task，pass/fail 二值
       ↓
2024 (τ-bench):           100+ task，ground-truth state checker
       ↓
2025 (SagaLLM):           ~5-10 个多 agent task，部分 ground-truth
       ↓
2026 (AgentSTM):          14 个 ground-truth multi-agent task，每个 10 trial
                          + τ-bench-inspired airline 5 trial

关键转变：

2023→2024：单 Agent benchmark 标准化（τ-bench）
2024→2025：第一批 multi-agent benchmark 出现（SagaLLM、AgentSTM 都贡献了自家的）
2026：multi-agent ground-truth + 多 trial 成为底线

🌟 结论：没有 ground-truth checker + 多 trial 的 benchmark 已经发不出主流会议。AgentSTM 论文 RQ1 的 14-task × 10-trial 是当前主流会议的”准入门槛”。

7.2 Fault Injection 的标准化

2024 之前：           不做或随机
2025 (SagaLLM):       随机 fault, 30% rate
2026 (AgentSTM):      30% tool-call failure injection（可复现 seed）

演进的核心：从”随机扰动”到”可复现的 fault profile”。AgentSTM 在 fault injection 实验里明确写”30% tool-call failure injection (single run per system)“——单次运行还是因为 LLM 调用 cost，不是技术不够。未来 1-2 年标准会演进到”多 trial 多 seed 的 fault injection”。

7.3 统计严谨度的分水岭：30 trials + Wilcoxon + Cohen’s d

2024 之前：           "我们更好"，无 p-value
2025 (SagaLLM):       报均值±std，无显著性检验
2026 (AgentSTM):      30-trial Wilcoxon signed-rank, p<0.001
                      Cohen's d_z=2.57（large effect）
                      Bonferroni correction (5 metrics)
                      IQR outlier removal

这是 2026 年 multi-agent 系统论文要进顶会的”卡 bar 项”。AgentSTM 在 throughput 比较上做了完整的：

Wilcoxon signed-rank test（非参数检验，对非正态分布鲁棒）
Cohen’s d_z（effect size，回答”差多少”而不只是”是否显著”）
Bonferroni correction（多重比较修正）
IQR-based outlier removal（避免单次崩溃 trial 主导均值）

7.4 评测指标演进：从 completion rate 到 semantic correctness

2023:  completion rate (任务跑完没崩) ── 太宽松
       ↓
2024:  conflict count (冲突次数) ── 不直接反映正确性
       ↓
2025:  ground-truth task success ── 真正测对错
       ↓
2026:  + Jaccard token retention   ── 测 plan 改写质量
       + repeat-conflict rate       ── 测重规划是否真的避让
       + semantic correctness       ── 业务一致性

最大进步：从”系统层指标”（throughput / latency）扩展到”语义层指标”（task 是否完成对了、plan 是否真正改写了）。AgentSTM 论文 RQ2 的 Jaccard token retention + repeat-conflict 双指标，正是这一演进的代表——它能区分”verbal 反思（reply 像但 plan 没变）“和”真重规划（reply 像 + plan 真改）”。

🧠 方法论小结：2026 年开始，论文发表标准 = 14+ ground-truth task × 多 trial × 多统计检验 × 双层评测指标。AgentSTM 论文是当前这个标准的代表。任何想在这领域发主流会议的工作都要照着做。

8. 五个领域开放问题

读完 27 篇论文，真正悬而未决的问题有 5 个。每个都至少够 2-3 篇博士论文。

8.1 跨机分布式 Agent Transaction

问题：现有方案（AgentSTM 含）都假设单机。生产部署多 Agent 可能跑在不同节点，cross-machine ATVar 怎么做？

为什么难：分布式 OCC 在数据库领域已经成熟（Spanner / CockroachDB），但 Agent 工具调用粒度大、跨网络代价高，传统 2PC 的”prepare-commit”开销可能让收益完全消失。

方向：

借鉴 Calvin（OLAP 确定性事务）的”先排序后并行”
或者 epoch-based 的 cross-machine 一致性快照（类似 Silo 的扩展）

8.2 Plan 改写质量的 semantic 度量

问题：AgentSTM 用 Jaccard token retention 度量 replan 质量，但 Jaccard 是 surface-level，看不出 paraphrase。

为什么难：什么叫”plan A 和 plan B 等价但路径不同”？需要：

一个 plan 的 canonical form
或一个学到的 plan-to-goal 嵌入
或一个”reference replan”集合做监督学习

方向：

LLM-as-judge 评 plan 等价性（成本高、可重复性差）
用 plan 对应的 trace（执行序列）embedding
AgentSTM 论文 Limitations 明确把这点列为未来工作

8.3 LLM Replan 的 cost-quality 权衡

问题：LLM 重规划好但贵。AgentSTM 实测 LLM-replan 比 heuristic redirect 慢 ~10×（分钟级 vs 秒级）。生产部署该如何决策？

为什么难：

简单冲突可能 heuristic 就够（如”换个未占用的 resource”）
复杂冲突需要 LLM（如”重排操作顺序”）
但”判断该用 heuristic 还是 LLM”本身是个 meta-decision

方向：

ATCC 的 RL 路线 + replan 决策
分级 replan：先 heuristic 试，失败再升级 LLM
用小模型做 first-pass replan，大模型做 fallback

8.4 Byzantine Agent 与 Trustworthy 多 Agent 系统

问题：现有所有方案（含 AgentSTM）假设 cooperative agent。如果某个 Agent 是 Byzantine（恶意写冲突值、不响应、伪造 conflict info），整个系统会崩。

为什么难：

LLM Agent 可被 prompt injection 攻击成 Byzantine
多方协作场景里 Agent 来自不同租户，trust 假设不成立
Aegean 是这方向的开端但只解决 decision agreement

方向：

把 Aegean 的 BFT 协议扩到 state consistency
Zero-knowledge proof 验证 Agent 行为
LLM-based “audit Agent”做 runtime 行为校验

8.5 Multi-Step Plan 与 Causal Dependency

问题：现有方案的 plan 大多是”单步”或”短链”。真实工作流的 plan 是 DAG，步骤间有 causal 依赖（步骤 5 用步骤 3 的结果）。

为什么难：

中间某步冲突时，下游已经基于错误中间值跑了一段
重规划要识别”哪些下游受影响”——这是数据库 cascading aborts 的 LLM 版
AgentSTM 当前实现把 plan 当原子（重规划整个 plan），没有部分重规划

方向：

引入 plan dependency graph
部分重规划（只改受影响子图）
借鉴 Atomix 的 frontier 概念但扩展到 plan 节点级

🌟 这 5 个开放问题给整个领域至少 3-5 年的研究空间。AgentSTM 论文的 Future Work 章节直接点名其中 3 个（multi-step plan、resource contention 扩展、distributed deployment），剩余 2 个（semantic plan metric、Byzantine）是社区共识的硬骨头。

🧠 领域全景的最后一句话：多 Agent 并发与事务在 2026 年还远没有成熟。8 篇 Agent Transaction 论文勾出了路线图，但每条路线都有结构性弱点。AgentSTM 是当下完整度最高的工作之一，但它本身也在 5 个开放问题上有大量未尽之处——这也是为什么本模块剩余 4 章会继续展开（第 5 章框架对比、第 6 章 Replan 设计、第 7 章评测、第 8 章实战），每章都是这 5 个开放问题某个切片的工程下沉。

STM 入门：Software Transactional Memory —— 维基百科
OCC vs 2PL 对比：Optimistic concurrency control —— 维基百科
Saga pattern 入门：Saga pattern —— microservices.io
CRDT 入门：Conflict-free replicated data type —— 维基百科

关键论文（按本章流派分组）

DB 时代地基（7 篇）

Sagas（García-Molina & Salem, 1987）：ACM SIGMOD Record 1987 —— 长事务补偿的祖师爷
Software Transactional Memory（Shavit & Touitou, 1995）：PODC 1995 —— STM 概念奠基
Composable Memory Transactions（Harris et al., 2005）：PPoPP 2005 —— Haskell STM，副作用隔离
Advanced Contention Management for Dynamic STM（Scherer III & Scott, 2005）：PODC 2005 —— STM contention 管理策略族
Robust Contention Management（Guerraoui, Herlihy, Pochon, 2005）：OOPSLA 2005 —— STM livelock 博弈论分析
Transactional Locking II / TL2（Dice, Shalev, Shavit, 2006）：DISC 2006 —— AgentSTM 算法直接祖先
Speedy Transactions in Multicore / Silo（Tu et al., 2013）：SOSP 2013 —— OCC 工程极致
Polyjuice: Learned Concurrency Control（Wang et al., 2021）：OSDI 2021 —— ATCC 直接前身

Single-Agent Reasoning（3 篇）

ReAct（Yao et al., 2023）：ICLR 2023 —— Agent loop 标准范式
Reflexion（Shinn et al., 2023）：NeurIPS 2023, arXiv 2303.11366 —— AgentSTM 论文核心对照组
LATS（Zhou et al., 2024）：ICML 2024 —— 树搜索式 Agent

Multi-Agent 框架（4 篇）

AutoGen（Wu et al., 2023）：arXiv 2308.08155 —— AgentSTM 实测无保护对照组
CrewAI（Moura, 2024）：GitHub —— 角色驱动协作
MetaGPT（Hong et al., 2024）：ICLR 2024 —— SOP 串行流水线
ChatDev（Qian et al., 2024）：ACL 2024 —— 软件开发瀑布

Agent Transaction 主战场（8 篇）⭐

SagaLLM（Chang & Geng, VLDB 2025） —— AgentSTM 头号对照基线
ALAS（Geng & Chang, 2025）：arXiv 2511.03094 —— SagaLLM 的局部修复扩展
SAFEFLOW（Li et al., 2025）：arXiv 2506.07564 —— 形式化 transactional protocol
CodeCRDT（Pugachev, 2025）：arXiv 2510.18893 —— CRDT 用于多 Agent 代码协同
Aegean（Ruan et al., 2025）：arXiv 2512.20184 —— 分布式共识 for LLM agreement
Atomix（Mohammadi et al., 2026）：arXiv 2602.14849 —— frontier-gated commit
AgentSTM（Anonymous, ARR/EMNLP 2026） ⭐ —— 本模块主线：OCC + LLM replan
ATCC（Zhou et al., 2026）：arXiv 2603.13906 —— RL 自适应并发控制

周边支撑（4 篇）

GoEX（Patil et al., 2024）：arXiv 2404.06921 —— Agent runtime 概念
Git Context Controller（Wu et al., 2025）：arXiv 2508.00031 —— Context as Git
Temporal（Temporal Technologies Inc., 2025）：Temporal blog —— Durable execution
τ-bench（Yao et al., 2024）：arXiv 2406.12045 —— Agent 工具调用 benchmark

行业讨论

AutoGen GitHub issues 中的并发问题 —— 搜索 “race condition” / “concurrent state” 关键词
Temporal vs AWS Step Functions vs Cadence 对比 —— Temporal 官方博客系列
CRDT 在协同编辑工业实践 —— Yjs, Automerge 项目文档

框架文档

AutoGen 官方文档：microsoft.github.io/autogen
CrewAI 官方文档：docs.crewai.com
MetaGPT 官方文档：docs.deepwisdom.ai
Temporal 官方文档：docs.temporal.io
τ-bench GitHub：github.com/sierra-research/tau-bench