立场：多智能体系统应优先考虑并发控制

# 观点：多智能体系统应优先处理并发控制
来源：https://arxiv.org/html/2608.18092

###### 摘要
基于大型语言模型的多智能体系统有望实现可扩展的协作，然而增加智能体数量往往*降低*可靠性。本文观点认为，许多多智能体系统的故障本质上是并发控制问题：智能体并发读写共享状态，而长时间的LLM推理窗口放大了过时读取、更新丢失和结果不一致的风险。通常归因于“协调”或“通信”故障的失败模式，可以直接映射到经典的并发异常上。我们认为，多智能体系统框架应通过显式的并发控制机制来处理这些故障：冲突检测、隔离保证以及对共享资源的结构化访问。并发控制应成为一等设计关注点，而非事后补救。
机器学习，ICML

## 1引言
大型语言模型已展现出日益强大的语言理解、推理和生成能力，其应用领域已从文本生成扩展到复杂决策。工具调用和与环境交互的整合，进一步将LLM转变为能够通过迭代推理和行动执行现实世界任务的自主智能体。以ReAct框架为例的这一范式转变，使模型能够超越纯粹的对话，通过观察、推理和行动循环来完成实际任务。最近，为解决日益复杂任务的追求推动了多智能体系统的发展，其中多个智能体并发运行，通过通信和协作实现比单智能体方法更大规模和更高成功率的目标。然而，实证证据揭示了一个严峻的现实：扩展智能体数量并不能可靠地提升性能。研究表明，多智能体系统在流行基准测试中的故障率介于41%至86.7%之间，其中协调失败和智能体间错位占据了这些故障的很大一部分。最近的系统和基准测试提供了具体证据，表明并发机制会影响多智能体系统的成果。

请参阅图注
图1：多智能体编码中的过时读取风险。智能体A读取utils.py并进入长时间的推理阶段以实现main.py。同时，智能体B重构了utils.py，将f_A重命名为func_A。两个智能体单独执行时都是正确的，但操作的交错导致了导入错误——这是一个经典的并发异常，被长时间的LLM推理窗口所放大。

在本观点论文中，我们主张，多智能体系统中许多通信和协调故障本质上是并发控制问题，应被视为构建高效、可扩展多智能体系统的优先瓶颈。我们的主张针对的是那些在长时间推理窗口期间读取或修改共享可变状态的多智能体系统，包括共享代码库、黑板记忆、消息缓冲区和实体化的世界状态。具有不相交输入的系统面临的并发风险较低，其瓶颈可能在于推理、规划或沟通质量。这一范围与梳理工作流、基础设施和协作模式的多智能体系统综述相补充；我们的贡献在于提供了并发控制的视角，将独立开发的协调机制联系起来。

表1：近期证据表明并发机制影响多智能体系统成果。
| 来源 | 并发信号 | 报告效应 |
| --- | --- | --- |
| CAID | 工作树隔离，合并验证 | 隔离环境63.3% vs. 非隔离55.5%；单智能体57.2% |
| CodeR | 依赖调度 | 移除任务图后解决率22% vs. 10% |
| Silo-Bench | 屏障，状态冲突 | 67.1%的故障率；RCC在高竞争下达到100% |
| MegaAgent | 并行调度 | 800秒 vs. 无并行组执行4505秒 |
| SagaLLM | saga事务 | 在基线LLM规划器失败时实现正确的反应式规划 |

表2：可归因于并发的故障占很大比例。
| 故障模式 | 来源 | 比例 | 并发根因 |
| --- | --- | --- | --- |
| 过早提交 | Silo-Bench | 37.2% | 缺少同步屏障 |
| 共识失败 | Silo-Bench | 29.9% | 并发冲突状态 |
| 智能体间错位 | MAST | 36.9% | 过时读取，状态不一致 |
| 协调开销 | Silo-Bench RCC | ≤100% | 并发扩展惩罚 |

为了具体说明这一观点，考虑一个涉及两个编码智能体在共享文件系统上协作开发软件的示例。智能体A读取一个现有的工具模块utils.py，随后在main.py中实现了一个新功能，该功能导入并调用工具模块中的函数f_A。与此同时，智能体B正在重构utils.py，将f_A重命名为func_A。不幸的是，在智能体A读取工具模块到完成其代码实现之间的时间窗口内，智能体B写入了重构后的版本。结果：两个智能体各自从自己的角度看都正确完成了任务，但系统进入了不一致状态——main.py包含了损坏的导入。这个失败表面上看是协调或通信问题。然而，通过并发系统的视角审视，它揭示了一个经典的并发风险：导致状态不一致的*过时读取*。

使得这类风险在多智能体系统中尤为普遍的根本原因是*时间不对称性*：LLM推理时间（例如，“思考”阶段的持续时间）通常比工具操作的执行时间长数个数量级，这极大地扩展了交错操作可能产生冲突的时间窗口。当一个智能体推理数秒甚至数分钟时，其他智能体可能已经多次修改了共享环境，使第一个智能体决策所依据的假设失效。

本文余下部分组织如下：首先，我们论证常见的多智能体系统故障模式可以系统地理解为并发风险，揭示了多样的“协调问题”共享着基于并发访问共享状态的共同结构。然后，我们提出针对多智能体系统设计中并发控制的建议，涉及目标、系统级机制以及正确性、效率和可扩展性之间的权衡。最后，我们讨论开放性挑战，并向机器学习与系统导向的社区发出跨学科合作的行动号召。

## 2伪装的并发风险
表3：多智能体系统并发控制的设计空间。权衡评估基于：任务成功率(S)、兼容性(C)、效率(E)、推理成本(I)。箭头：↑表示提升，↓表示降低。
| 层级 | 决策选项（权衡） |
| --- | --- |
| **系统设计** | |
| 隔离级别 | 弱/读已提交（E↑，S↓：更多并行性，有异常风险）↔ 强/可串行化（S↑，E↓） |
| 控制策略 | 悲观/锁（S↑，E↓：长时间推理期间阻塞） vs. 乐观/验证（E↑，I↓：因中止浪费计算） |
| 版本管理 | 单版本（简单） vs. MVCC（E↑：读者永不阻塞写者；C↓：增加复杂性） |
| 事务粒度 | 细粒度/单操作（E↑，I↓：更短冲突，更高开销） vs. 粗粒度/子任务（I↑，S↓：昂贵回滚） |
| 事务边界 | 显式BEGIN/COMMIT（C↑，I↓：灵活，需要模型理解） vs. 隐式/系统推断（I↑，C↓） |
| 锁/资源粒度 | 粗粒度/文件（I↑，E↓） vs. 细粒度/函数（E↑，I↓：更多并行性，更多元数据） |
| **基础设施** | |
| 后端系统 | 定制（C↑：定制语义） vs. 现有数据库/Git/文件系统（S↑，C↑：成熟保证，可能不适合智能体语义） |
| 版本控制集成 | 每子任务一个分支（S↑：隔离；E↓：合并开销） vs. 合并时验证（E↑，S↓：延迟冲突检测） |
| 推理优化 | 标准 vs. 优化的批处理/推测/量化（E↑，S↑：更短事务减少冲突窗口） |
| 检查点 | 无（简单） vs. KV缓存检查点（I↑：无需完全重算即可高效回滚；C↓：需要引擎支持） |
| **模型** | |
| 并发训练 | 无 vs. 针对冲突场景的SFT/RL（S↑：更好预测/解决；I↓：需要数据和计算） |
| 提示干预 | 通用 vs. 并发感知提示（I↑：低成本；S±：有限、脆弱的保证） |
| **任务设计** | |
| 任务分解 | 资源重叠（E↑，S↓） vs. 不相交分区（S↑，C↓：需要前期设计工作） |
| 失败反馈 | 不透明的“重试”（I↑：简单） vs. 语义冲突细节（S↑，I↓：支持适应，需要模型能力） |

多智能体系统中的许多失败，常被描述为协调或沟通问题，但可以理解为经典的并发风险。我们展示了具有代表性的失败案例，并将其映射到已建立的并发控制概念上，表明这些挑战反映了系统和数据库研究中长期探讨的问题。这一视角激励我们将并发控制作为多智能体系统的核心设计原则，并将协调启发式方法建立在明确的并发语义基础之上。

### 2.1故障案例
我们展示了四个多智能体系统中的代表性故障场景，这些场景通常归因于协调或沟通不畅，但更精确地说是对共享状态的经典并发风险。

**过时读取。** 在协作编码多智能体系统中，智能体A读取一个配置文件config.yaml，并根据观察到的端点实现一个客户端模块。与此同时，智能体B更新了配置以反映新的基础设施。当智能体A稍后写入其代码时，它依赖于过时的假设，导致系统状态不一致，尽管两个智能体单独执行时都是正确的。这是一个标准的过时读取异常。

**更新丢失。** 两个智能体独立修改共享文件utils.py的不同部分。智能体A优化了一个函数，而智能体B修复了另一个函数的错误。由于两者都读取相同的初始版本并独立写回，后一个写操作覆盖了前一个，悄然丢弃了一个智能体的贡献。这种更新丢失发生时，任一智能体都未检测到冲突。

**过时修正。** 在基于消息的多智能体系统中，智能体A广播了一个计划，智能体B发送了修正，但智能体C在接收更新之前就开始执行原始计划。尽管修正已发送，但它并未对所有智能体原子地应用，导致基于过时信息执行了不正确的操作。

**动作-消息不同步。** 在像基于Minecraft的基准测试这样的实体环境中，智能体通过消息和改变世界状态的动作进行协调。一个智能体可能基于描述预期状态的消息采取行动，而该状态已被另一个智能体的并发操作无效化。因此，即使通信在逻辑上是一致的，智能体的信念与真实环境状态也会出现分歧。

**现有系统中的隐含假设。** 这些风险存在于当前的多智能体系统架构中。像MAGIS这样的系统通过结构化编排和基于Git的事后合并提高了可靠性，但隐含地假设在并发推理期间是良性交错。冲突仅在智能体已经基于不兼容的假设执行了昂贵的推理之后才被检测到。这反映了依赖于编排但并发语义定义不足的多智能体框架中的更广泛模式。

最近的系统从另一个角度展示了相同的模式。CAID使用隔离的工作树和合并时验证，CodeR使用任务图来排序依赖工作，SagaLLM使用saga风格的补偿，MegaAgent强调并行调度。这些机制对应于乐观隔离、依赖调度、事务性恢复和并发调度，即使引入时未使用明确的并发控制术语。

### 2.2统一框架
上述故障案例虽产生于不同的应用背景，但共享着一个共同的结构。我们现在建立一个统一的框架，借鉴经典的并发控制理论，将这些故障揭示为对基本并发属性的违反。

**多智能体系统形式化。** 我们将一个多智能体系统建模为n个智能体的集合，每个智能体具有各自的内部状态。