一句话：多智能体写代码，不能只看「任务做没做对」
arXiv:2609.32662 提出 AsynCodeBench，它要做的事很朴素却长期被忽视：给异步多智能体软件工程单独立一把「协作尺」。今天的代码基准大多沿用单智能体的老办法——看最终补丁有没有通过测试，于是多智能体系统里每个智能体各自编码能力的强弱，被悄悄混进了「协作好不好」的结论里。AsynCodeBench 的核心主张是：协作是一项独立能力，必须被单独量出来，而不是从任务分数里顺手推断。它来自 Kaituo Zhang 等多位高校研究者组成的团队，整套基准与两个新指标都已开源。
为什么值得看：协作是被长期误读的那一维
多智能体编码最近两年明显升温，ChatDev、MetaGPT、RTADev、CAID、CodeTeam 等系统把规划、实现、测试与协调拆给不同专长的智能体。可评价方式几乎没跟上：仓库级基准如 SWE-bench 用可执行测试判最终实现，多智能体系统则往往拿同一套端到端指标去比单智能体基线。问题就出在这里——一个任务最终通过，可能只是因为某个智能体单兵能力够强，并不说明几个智能体之间真的协调好了。当任务被拆成多块、分给彼此独立推进的代理，跨代理的依赖能不能被满足，才是协作的真问题。AsynCodeBench 想把这个被掩盖的维度摊开在桌面上。
机制拆解：用依赖图把协作显式化
它的做法是一句话——把每个任务表示成显式依赖图，再配上一组可执行的依赖检查器。传统评测只关心「最终对不对」，AsynCodeBench 则把任务里 52 条有向依赖当成独立的评分单元：一条依赖代表「代理 A 的产出，是代理 B 工作的前置条件」。基于这种依赖追踪，论文提出两个互补指标。其一是 ADPR（异步依赖通过率），量的是最终有多少条跨代理依赖被真正满足；其二是 DRS（依赖解决步数），量的是每条依赖在执行轨迹里于第几步被满足。前者看结果，后者看过程节奏，合起来才勾勒出协作的真实形态。基准本身由 19 个来自真实仓库的任务构成，把 52 条有向依赖暴露成可评测的单位。
实验读数：编码涨了，协作未必跟着涨
跨模型家族、规模与代际的实验，给出了一个清醒的结论：编码能力的提升，并不必然翻译成更强的协作。任务级指标有时会和依赖级的协作指标明显背离——一个任务分数很好看，依赖达成率却未必同步走高。这恰恰说明，过去用任务分数替协作打分，可能一直在误读系统的真实水平。更耐人寻味的是依赖轨迹分析揭示的一种模式：成功的协调往往不是渐进发生的，而是在执行轨迹的某一段里集中爆发——许多依赖在很短的窗口内被一起解决，论文把这种现象称为 hopping window。这个观察对如何安排多智能体的沟通节奏，是有增量价值的提示。
优势与局限：范式清晰，但仍是起点
优势在问题定义到位：它把「协作」从「任务结果」里剥离出来，给出可复现的依赖级度量，并指出编码与协作可能脱钩。局限也清楚：其一，19 个任务、52 条依赖的样本规模仍偏小，结论的外推需要更多仓库验证；其二，依赖图与检查器由人工或模型构建，其覆盖度会影响指标可信度；其三，异步协作之外的同步、回滚、冲突解决等更难的场景，尚未纳入。关于指标是否该区分「依赖被满足」与「被满足且被正确消费」，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。它真正的价值，是给多智能体编码研究递了一把此前缺位的尺。
结语
AsynCodeBench 提醒我们：当智能体从单兵作战走向分布式协作，评价系统也必须升级。任务做对了，不代表几个代理真的配合好了；把依赖当成一等公民来量，我们才能看清多智能体编码到底进步在哪、卡在哪。它未必是终局基准，但确实是把协作从黑箱里拉出来的关键一步。