Agent并发干活像“三个和尚没水喝”？CoAgent新框架：让它们学会看懂冲突再动手

CoAgent团队 投稿 
量子位 | 公众号 QbitAI

谁不想要一队agent帮手？让多个agent并发组队干活，可能是2026年落地到用户手上最有趣的agent玩法。

例如，Claude Code最近推出的ultracode模式，一条命令下去，拉起几十个agent。看它们忙忙碌碌几个小时，颇有一种当老板的乐趣。

但上海交通大学IPADS实验室的团队发现，在尝试把并发agent接入生产环境时，会出现奇怪的现象：两个（或者多个）agent明明按照要求做了，最后的结果却是错的。

其核心问题在于，多个agent并发干活的时候，遇到了传统操作系统中的Race Condition的问题，但是这个问题却无法用经典操作系统方法高效地解决。

针对这个问题，该团队的新工作《CoAgent: Concurrency Control for Multi-Agent Systems》，专门解决并发agent的一致性问题，把并发agent的任务成功率提高了7.2倍；相比串行执行多个任务，平均加速1.43倍。

事故复盘

某一时刻，一个工程师发现某个K8s业务容器的版本配错了，命令agent去修复。agent先把产线上的容器和版本扫了一遍。

与此同时，隔壁工位刚开发完新功能，派agent克隆一组生产容器搞灰度发布。这个agent也先把产线扫了一遍。

就在这交错的一瞬间，错误的种子悄悄埋下：

• 灰度agent读到的容器版本是错的，克隆出来的自然也是错的；
• 修复agent压根没看到灰度容器，也就不会想到去修它。

于是，当灰度部署晋升为主部署时，一个明明已经修过的版本配置错误，如幽灵般回到了生产系统。

传统并发控制方法，为什么不行？

不难看出，这是一个典型的并发一致性问题，人们已经研究了几十年。但实践表明，传统并发控制方法搬到agent领域异常低效。例如，最经典的方案有两种：

• 悲观加锁。
  读写前先上锁，跑完再释放。在传统系统（如数据库）里，一笔事务几毫秒就结束，锁的代价可以忍受；可agent的任务动辄几分钟到几小时，后来者只能看着自己的agent任务一直卡住。
• 乐观并发。
  先放手执行，最后检查，冲突就整体重做。这套做法有个要求：写操作得先放进某种局部缓冲区，等commit之后才对其他参与者可见。传统系统的数据结构简单，中间结果容易暂存；但如今的agent可能接入各种数字系统（比如一个K8s集群），这些系统难以托管进任何暂存区。

雪上加霜的是，读放大导致上述系统更加低效。agent干活前习惯把环境先读个遍：修一个bug，先grep整个仓库。读得越多，锁系统阻塞得越多，乐观并发遇到的冲突和重做也越频繁。

团队在K8s修复任务上实测（2倍并发，对照组为所有任务排队串行执行）：加锁方案的加速比只剩1.04倍，平均每轮死锁0.81次；乐观并发方案更是只有0.93倍，比串行还慢，token反而多烧了83%。

CoAgent：把冲突语义传递给agent

传统并发控制有一个隐含假设：参与者不知道冲突的语义，所以系统只能保守地上锁，或者整体推倒重做。

但agent不一样，它背后的LLM是能分析冲突语义的。

这一点其实和人与人的协作很像：同事改了共用的文档，你瞄一眼，多数时候和你手头的段落无关；真有关系，也只需改自己受牵连的那几句，犯不着把整篇重写。

CoAgent把这个思路搬进了agent系统：框架发现冲突时，通知当事agent，让它自己判断是不是真冲突、思考代价最小的修正方式。

作为一个并发控制算法，首先得明确一致性模型。CoAgent采用了最严格的可串行化一致性：并发运行的结果，必须等价于这些agent按某个串行顺序依次执行的结果。

围绕这个目标，为了确保agent能正确完成任务，CoAgent把上述设计思想展开为如下算法：

• 预定序。
  为了让agent以最小化的代价知道该如何修正，就需要让它知道自己在“可串行化”顺序中的逻辑位置，例如，如果一个靠后的agent看到了一个逻辑上靠前的agent的冲突操作，则它无需修复。为此，我们提前给不同agent一个序号。
• 读后写->冲突通知。
  CoAgent追踪每次工具调用的读写集。序靠后的agent读过的内容，如果之后被序靠前的agent修改，CoAgent会提醒靠后的agent检查是否需要对应修复，并自主设计最小化修正方案，无需上锁或重试。
• 写后读->读过滤。
  反过来，序靠前的agent如果读到了序靠后agent的写入产物，也会破坏并发一致性。为此，CoAgent记录系统内对象的历史状态，过滤掉后序agent的影响，把前序agent本应读到的结果还原出来交给它。若无法还原结果（如对K8s集群的操作已经生效），则进入步骤4。
• 写后写->撤销重做。
  当某个对象上出现逆序的写后写冲突，或上述读过滤在技术上无法实现时，CoAgent会先撤销顺序错误的现有写操作，还原出正确的原始状态（例如回滚K8s集群的操作），再让前序agent完成其意图中的读写动作，最后通知被撤销的agent重做。

落地成系统时，CoAgent引入了一个服务agent：它负责实时构造worker所需的工具，确保每一次工具调用都有明确的读写集合标记。而且为了保证“能撤销”，所有带写操作的工具调用，执行前都要先跑一段准备逻辑（用快照或日志兜底）。这段准备逻辑和对应的撤销逻辑，同样由服务agent编写。

实验结果：提速1.4倍，正确率损失5%以内

评测覆盖10个高竞争的多agent场景，包含真实K8s集群上的部署实验250次。

CoAgent的正确率比串行执行低不到5%（用的还是较便宜的模型），比无保护并发提高了7.2倍。审计运行记录表明协议行为符合预期，只是模型判断冲突真假时偶尔误判。

CoAgent的速度接近不加任何保护的裸并发，处理冲突只额外花费7%的时间；token开销也只比串行多15%。

作为对照，在同一批场景里，加锁和重做这两套老办法的速度与串行相当，还在死锁和反复重做中额外烧掉了大量token。

写在最后：agent协作的未来

如今，人类工程师一起维护云系统时，协作靠的是各种协调群，甚至是办公室里的吆喝。

然而，具体的活儿正越来越多地交给agent，人正一步一步退到指挥的位置上。因此，协作的责任，不可避免地要逐步下放到agent层。

当工作流变成一位真人工程师，给手下几个agent分派如“维护整个系统健康运转”、“每天自己构思新功能，开发上线”等任务，到那时，agent和agent之间必须自己学会协作：发现彼此的冲突、看懂冲突的语义、用最小的代价互相礼让。

CoAgent，也许就是朝着这个未来迈出的一步。

团队简介

CoAgent来自上海交通大学并行与分布式系统研究所（IPADS）。论文共同一作吕泓涛、张鼎言均为IPADS博士生；指导老师为吴明瑜、魏星达、陈海波。

IPADS是国内系统软件方向的代表性实验室：SOSP、OSDI、EuroSys等系统顶会的常客，近年接连拿下SOSP 2023、EuroSys 2024、SOSP 2025最佳论文；团队所著教材《现代操作系统：原理与实现》已被近200所高校采用。

论文标题：CoAgent: Concurrency Control for Multi-Agent Systems
论文地址：https://arxiv.org/abs/2606.15376