上海交大提出CoAgent:LLM自修复并发控制,多智能体提速1.4倍
CoAgent: Concurrency Control for Multi-Agent Systems

当我们在生产环境中同时运行多个大型语言模型(LLM)智能体时,一个经典但致命的计算机科学问题正在以全新的形态复活:并发控制。无论是修复代码库、管理 Kubernetes 集群,还是协作编辑长文档,一旦多个智能体开始读取和修改同一个共享状态,它们的执行轨迹就会交织在一起。
ArXiv URL:https://arxiv.org/abs/2606.15376v1
传统的数据库系统通过两阶段锁(2PL)或乐观并发控制(OCC)来解决这类冲突,但在大模型智能体的场景下,这些经典机制遭遇了彻底的失效。智能体的一次“事务”通常伴随着长达数分钟的推理时间,且它们对外部世界(如部署集群配置)的操作往往是即时生效、无法简单撤销的。这就导致,如果系统强行加锁,会导致其他智能体陷入漫长的等待;如果采用发现冲突就回滚重试的机制,则会白白丢弃消耗了大量 Token 和时间的推理成果。
为了解决这一难题,上海交通大学的研究团队提出了 CoAgent 框架。这是一种专为多智能体系统设计的并发控制中间件,其核心创新在于摒弃了传统系统中“强制阻断或回滚”的生硬做法,转而利用大模型自身强大的语义理解能力来实现“自修复”。研究结果表明,在高冲突工作负载下,CoAgent 能够实现 1.4 倍的执行提速,将 Token 成本控制在接近串行执行的水平,并在零散工具库测试中将任务通过率从 45/71 大幅提升至 63/71,同时还降低了整体运行时间和成本。
为什么经典并发控制机制在 LLM 面前束手无策
要理解 CoAgent 的突破,首先必须看清传统并发控制在多智能体环境中的水土不服。在多智能体架构中,最核心的正确性标准被称为“可串行化(Serializability)”,即多个并发运行的智能体,其最终产生的结果应该等同于它们以某种特定顺序逐个串行执行的结果。然而,现实中的系统往往会因为读取和写入的交叉而产生异常。
论文中给出了一个发生在真实 Kubernetes 集群上的“金丝雀发布异常”案例。假设智能体 A 正在处理一个故障修复任务,需要扫描集群并修复所有使用了错误容器镜像的部署;与此同时,智能体 B 正在为一个特定服务准备金丝雀发布,它需要读取该服务当前的镜像并创建一个新的金丝雀部署。如果在并发执行中,智能体 A 在金丝雀部署创建之前就完成了扫描,那么它的修复动作就会漏掉尚未创建的金丝雀节点;而如果智能体 B 在智能体 A 修复完成之前就读取了镜像,它就会基于错误的镜像构建出金丝雀节点。最终,两个智能体都毫无错误地完成了各自的推理和行动,但集群中却留下了一个基于已知错误镜像运行的金丝雀节点,随时可能引发线上事故。
现有的解决方案大多非常笨重。要么一次只运行一个智能体,完全放弃并发带来的效率红利;要么在执行前静态划分好各自负责的区域,但这对于执行过程中动态生成计划的 LLM 来说根本不现实;又或者采用分支与合并(Fork-and-merge)策略,给每个智能体分配独立的副本,最后再进行合并。但在真实的业务环境中,活跃的生产数据库或运行中的 Kubernetes 集群是根本无法被随意复制和合并的。
更深层的原因在于经典并发控制协议面临的两大不可逾越的鸿沟:功能性鸿沟与性能鸿沟。
从性能角度看,数据库的事务通常在毫秒级内完成,而智能体的推理需要几秒甚至几十分钟。如果在这么长的时间窗口内使用两阶段锁(2PL),意味着一个智能体会长期霸占资源,导致严重的死锁和阻塞。如果换用乐观并发控制(OCC),虽然执行期间不加锁,但在最终提交时一旦发现数据冲突就会触发整体重试。对于数据库来说,重试只是几毫秒的运算开销;但对于大模型而言,一次重试就意味着前面消耗的数以万计的 Token 和长达数分钟的推理时间全部付诸东流。在研究团队的测试中,OCC 在并发压力下的重试成本高达 1.83 倍,整体速度甚至比单智能体串行还要慢。
从功能角度看,外部物理世界的状态操作是不允许简单“暂存”或“一键抹除”的。传统数据库可以通过将写入操作放在私有缓冲区来避免脏写,或者在发现死锁时直接丢弃未提交的事务。但智能体的动作(例如执行一条 kubectl apply 命令)一旦发出,就会立刻在真实世界产生后果。框架层本身并不具备撤销这些外部影响的能力,导致无论是需要安装缓冲区的 OCC,还是需要回滚机制的 2PL,都无法在智能体控制物理或逻辑状态的场景中直接生效。
利用 LLM 的语义理解实现“咨询式”并发控制
面对这些困境,CoAgent 引入了一个极其精妙的洞察:经典并发控制之所以必须采取生硬的强制手段,是因为传统的事务代码是极其死板的。一段普通的应用程序既无法判断数据冲突是否真的影响业务逻辑,也无法对已经执行的操作进行精准的局部修复,系统除了让它等待或全部推倒重来之外别无他法。
然而,由大型语言模型驱动的智能体,拥有着传统程序所缺乏的“自愈”能力。CoAgent 敏锐地抓住了大模型的三个独特优势,彻底改变了并发控制的范式。
大模型能够准确评估冲突的真实影响。智能体在执行任务时往往会读取大量的上下文信息,当并发的另一个智能体修改了其中的某部分状态时,经典机制会盲目地判定为冲突并触发回滚。但 LLM 可以结合当前任务目标,判断这种修改是否真的颠覆了它之前的行动前提。比如,另一个智能体只是在日志文件末尾追加了一行记录,这完全不影响当前智能体部署特定 Pod 的逻辑,大模型完全可以忽略这种无害的干扰,继续推进任务。
大模型具备局部精准修复的能力。在真正发生冲突,导致之前的某些判断失效时,LLM 并不需要像传统事务那样从头开始重做所有步骤。它可以回顾自己的读写历史,精准定位出哪些操作是建立在过期数据之上的,然后仅仅重新执行受影响的少数几个操作。如果发现金丝雀部署的镜像读错了,大模型只需要生成一个重新设置镜像的操作即可,而不需要将整个部署流程推倒重来。
基于这两种能力,CoAgent 提出并发控制不再应该是“强制性(Mandatory)”的,而应该转变为“咨询式(Advisory)”的。框架不再负责粗暴地阻断或终止智能体,而是仅仅充当一个“通知者”的角色。当监测到可能破坏隔离性的并发写入时,框架会将变更情况作为一条通知消息发送给受影响的智能体,由智能体自行判断是否需要调整计划并实施局部修复。
与此同时,为了应对外部操作立刻生效且难以撤销的问题,CoAgent 引入了长事务领域经典的 Saga 补偿模式,即要求每个工具调用在定义时提供反向撤销逻辑。例如,扩大副本数的逆操作就是将副本数缩减回原值,应用新配置文件的逆操作就是重新应用被覆盖的旧配置文件。通过在工具层面注册这些逆操作,框架本身就可以在不依赖大模型重新推理的情况下,机械地撤回那些由于时序错乱而提前生效的外部写入操作。
MTPO 协议:确保操作单调有序的通知机制
为了将上述设计理念转化为一个严谨、可证明的系统,研究团队在 CoAgent 中设计并实现了一种名为 MTPO(Monotonic Trajectory Pre-Order)的通信与控制协议。该协议在系统启动时为并发的智能体分配一个确定的串行执行顺序,并通过过滤和通知机制来维持整个系统的最终状态一致性。

如上图所示,MTPO 协议定义了三个核心动作,这三个动作相互配合,既保证了执行的乐观性和高效性,又兜底了状态的严谨性。
在读取数据时,MTPO 采用“过滤读取”的策略。框架会根据预先分配的串行顺序,拦截并隐藏排在当前智能体之后的其他并发者所产生的写入。智能体只会读取到在它的视角下合法的、由排在前面的智能体所确认的状态。由于它无法预知排在前面的智能体后续是否还会修改这个数据,智能体会乐观地将当前读到的数据作为前提,直接继续执行任务,绝不陷入死锁等待。
在发生并发更新时,MTPO 采用“订阅通知与局部修复”机制。当排在前面的智能体修改了排在后面的智能体已经读取过的某个状态时,框架会立刻向后面的智能体发送通知消息。接收到消息的智能体会被唤醒并重新评估当前的局势,利用大模型的推理能力判断这个新变化是否推翻了现有的执行计划。如果确实影响了核心逻辑,智能体会针对性地撤销并修正与之相关的后续操作;如果不影响,则继续原有进度。
而在处理写入操作时,为了解决乱序生效的问题,MTPO 依靠工具层面注册的逆操作来实现纠偏。如果一个排在后面的智能体由于进度较快,已经把结果写入了真实世界,而此时排在前面的智能体才姗姗来迟地尝试写入同一个资源,框架不会报错。它会利用逆操作先撤销后面智能体已经打乱顺序的修改,让状态回退,然后再依次应用正确顺序的写入。这样一来,任何时刻物理世界中的最终状态,都能严格对应于预设的串行顺序。
实验结果与多智能体系统的效率跃升
为了验证 CoAgent 及其底层 MTPO 协议的真实有效性,研究团队不仅在数学模型上对其可串行化能力进行了形式化推演,还在多种不同复杂度和冲突强度的实际工作负载中进行了详尽的测试。实验结果呈现出压倒性的优势。
在十个高并发冲突场景中,采用未协调并发执行的基线系统最终正确率仅为 13%,这意味着不受管理的并发必然会导致系统陷入混沌状态。而在部署了 CoAgent 之后,系统不仅保证了仅低于纯串行执行 5% 的极高正确率,更是在执行效率上实现了 1.4 倍的显著提速。由于 CoAgent 大量减少了无效的推倒重来,其消耗的 Token 成本仅仅是纯串行执行的 1.15 倍。
对比之下,被传统数据库奉为圭臬的并发方案在这些测试中暴露出了巨大的缺陷。使用 2PL 方案由于频繁陷入死锁互相等待,不仅几乎没有任何速度提升(仅 1.04 倍),反而因为锁机制带来的逻辑复杂度增加了额外的运行风险。而使用 OCC 方案更是灾难,平均每次运行都会触发 0.95 次全局重试,导致整体耗时甚至比一个接一个单独运行更慢(0.93 倍速度),Token 成本也飙升至 1.83 倍。
除了应对高冲突场景,CoAgent 还展示出了极强的通用性和扩展性。在一项仅提供基础 Bash 终端而未预置复杂工具表的外部系统测试中,CoAgent 框架能够在运行过程中动态实现在线生长,构建出包含 25 种工具的操作库。在总计 71 项复杂修复与部署任务中,CoAgent 将任务通过率从基准的 45 个成功跃升至 63 个,同时整体耗时减少了 20%,Token 消耗降低了 14%。
这种“既要速度,又要正确,还要省钱”的结果表明,多智能体并发问题不能生搬硬套传统软件工程的底层约束。传统的系统设计总是预设底层组件是愚笨的,因此必须用严格的锁和检查点去约束它们。而 CoAgent 向我们展示了一种全新的工程哲学:当系统中的基本运作单元已经升级为具备强大理解与反思能力的大语言模型时,系统架构的职责不再是强制阻断错误,而是及时同步信息,将修复与容错的权利下放给智能体自身。在这条道路上,大语言模型不仅仅是任务的执行者,更成为了维护分布式系统稳定性的核心枢纽。