MSEval:多智能体从零写代码,换个组织架构分差竟超30分!

An Empirical Study of Coordination Mode as the First-Class Citizen in From-Scratch Multi-Agent Coding

论文原文 ↗ 论文发布 解读发布 解读:AI前沿分享

在当前大语言模型(LLM)驱动的软件工程浪潮中,“Vibe Coding”正在从单兵作战快速走向多智能体团队协同。行业里普遍存在一种直觉预期:既然单个代码 Agent 已经能在 SWE-bench 等基准上排查故障、提交补丁,那么把前端、后端、测试和项目经理组合成一个虚拟团队,以流水线或讨论组的形式协同,理应能自动化交付完整的全栈系统。然而,现实开发中常常出现沟通冗余、语义漂移、互相覆盖代码、虚假汇报完成等混乱场面,整个团队的产出甚至不如单个模型稳定。

ArXiv URL:https://arxiv.org/abs/2607.27877

这种工程落地与理论预期之间的断层,暴露出现有评测体系的严重滞后。现存的代码基准大多关注单一 Agent 对已知缺陷的修补(如修复单文件函数或已有仓库的 Issue),或者依赖人工预先切分好的精细 API 规格,无法衡量多个 Agent 从一份粗粒度需求文档开始、端到端构建两千行以上代码的全栈工程能力。

针对这一盲区,最新研究提出了多智能体从零代码构建评测基准 MSEval。该基准将“协作拓扑(Coordination Topology)”提升为评测的核心自变量,在统一的项目需求、模型底座与自动化部署测试流水线下,系统性测试了 10 种不同的团队组织模式。这项涵盖上百次完整工程运行的大规模实测给出了一个反直觉的明确结论:在相同的模型和任务条件下,仅仅改变智能体之间的组织协作架构,最终的交付得分波动幅度就能超过 30 分,物理耗时甚至直接翻倍。更出人意料的是,传统软件工程中推崇的“强项目经理管理监督”模式在 Agent 体系中频繁失效,反而让代码陷入严重的质量回退;而边界清晰的流水线与测试先行模式,展现出了压倒性的收敛效率。

MSEval 框架总览与运行流程

从“修补补丁”到“端到端交付”的评测鸿沟

要理解 MSEval 的价值,必须先看清现有评估方案的局限。过去两年,社区从测试纯函数生成的 HumanEval、MBPP,逐步过渡到测试仓库级代码修复的 SWE-bench、RepoBench 等。配合 SWE-agent、Agentless、OpenHands 等运行环境,模型展现出了在现成代码库中检索、调用 Shell 工具、定位并修复 Defect 的能力。然而,这种“在已有大厦上修补裂缝”的场景,天然绕过了架构设计、接口协商、环境配置和跨模块集成等最繁重的工程挑战。

另一方面,此前的多智能体基准(如 AgentsNet 或 MultiAgentBench)往往聚焦在高度抽象的文字沟通游戏或对话仿真上,脱离了真实可执行的软件部署。即便是探索从需求生成仓库的基准(如 CloudDevBench),也往往为每个模块预设了极为细致的 API 签名与设计协议。这种设定实际上是由人类替 Agent 完成了最难的架构分解,本质上依然是“填空题”,无法观察多智能体在模糊需求下如何自分配责任、划分模块边界。

真实的软件交付不仅要求代码静态逻辑正确,更要求它能够在独立的容器网络中被构建、拉起依赖、暴露端口并通过 live 状态的 UI 与 API 探针。这就需要一个能跨越“需求理解—代码分工—并行开发—CI/CD 部署—动态探测—加权反馈”全链路的评测平台。MSEval 正是为此而生,它以大学软件工程课程的团队大作业为蓝本,涵盖即时通讯、在线协作等 10 个业务维度的真实全栈项目,每次从零构建均要求生成通常超过 2000 行的 Python 全栈代码,彻底规避了训练集数据污染对代码补全的投机取巧。

拆解 MSEval:三大支柱重塑评测规范

MSEval 之所以能精准解耦“模型智力缺陷”与“团队协作混乱”,关键在于其围绕三个核心组件构建的设计体系。

首先是可插拔的多智能体执行引擎 LegoGent。在以往的多智能体框架中,团队往往要么陷入完全自由发散的聊天室模式,要么依赖人工预先写死的硬编码依赖图。LegoGent 则引入了一种“激活驱动”与“周期同步循环(Periodic Sync Loop)”相结合的运行时机制。每个 Agent 作为独立的、可恢复的进程在共享工作区中运行,拥有独立的文件编辑与 Shell 工具。智能体之间既不进行漫无边际的无效会话,也不盲目并发,而是由底层的进度采集器定期轮询,广播工作快照。更重要的是,LegoGent 将协作的基本单元定义为“经过验证的构件(Validated Artifacts)”——例如数据库 Schema、路由契约、集成点文档或通过检查的代码状态。框架级验证器会严格守门,检查端口占用、HTTP 连通性与关键产物,只有当所有负责 Agent 均处于空闲状态且必要构件就位时,才允许进入部署与代码移交环节,从系统机制上杜绝了伪造完成状态的侥幸行为。

其次是自动化评估器 TAgent。在传统的基准测试中,评估通常依赖于静态单元测试;但在“从零构建”任务中,不同 Agent 团队设计出的 URL 路径、数据库字段和前端组件层级千差万别,预设的单元测试根本无法挂载。TAgent 扮演了类似“自动化助教”的角色。它首先将非结构化的高层需求文档解析为带有确定性权重的多级评分量规(Rubric),然后利用大模型结合动态爬虫与自动化测试工具,自主探测被测项目刚刚暴露出的 API 接口、代码文件结构以及前端 UI 界面。通过并行收集接口返回、页面 DOM 元素和后端日志,TAgent 将这些证据综合融合成满分为 100 分的“功能完成度得分(Functional Completion Score)”,并生成结构化、带权重的缺陷反馈报告。

最后是多轮迭代与全维度资源度量。软件从来不是一次性写成的,MSEval 为每个 Agent 团队提供最多 3 轮(R1、R2、R3)的修正机会。上一轮被 TAgent 动态探测出的缺陷报告会被裁剪、定责后注入下一轮的上下文,以此测试团队利用反馈进行调试收敛的能力。与此同时,评测不仅仅记录最终得分,还将物理时钟耗时(Wall-clock Latency)、基于前缀缓存(Prefix-cached)的 Token 消耗量以及云端折算美元成本作为一等指标。这使得评估摆脱了孤立的排行榜思维,转而能够清晰绘制出一条“质量—耗时—成本”的三维 Pareto 前沿面。

组织架构的威力:同模型下分差竟达 30 分

当项目、需求文档、部署环境和评分量规被完全固化,仅将智能体协作模式作为唯一自变量时,实验揭示了极其惊人的数据差异。

研究人员在 LegoGent 中实现了 10 种典型的协作拓扑:特性小队(Feature Squads)、分层专员(Layer Specialists)、流水线交接(Pipeline Handoff)、集群协同(Swarming)、轮岗协作(Rotation)、项目经理监督(PM Oversight)、测试先行(QA-first)、PR式代码审查(PR-style Review)、对抗测试(Adversarial Testing)以及竞争团队(Competitive Teams)。

在横跨多个大模型的数百次端到端评测中,组织拓扑对最终表现的塑造力展现得淋漓尽致。以综合能力居中的代表性模型 DeepSeek v4 Pro 在即时通讯项目上的表现为例:当采用“流水线交接(Pipeline Handoff)”模式时,智能体团队分工严谨、按架构层顺序交付,最终斩获了 89.9 分的高分;然而在相同的需求与算力下,一旦将拓扑切换为模拟开源社区的“PR式代码审查(PR-style Review)”,模型得分断崖式下跌至 43.0 分,落差接近 47 分。在全项目的综合均分统计中,QA-first 和 Rotation 模式均以 83.3 分并列榜首,而开源审查模式的均分仅有 73.5 分。

这种巨大差异背后的机理非常值得深思。在“测试先行(QA-first)”拓扑中,测试 Agent 会在编写业务代码之前,先将高层需求转化为可落地的验收目标与契约规范,这相当于在系统状态、API 和前端发散前钉牢了边界;后续编码人员无论如何扩展,目标都不会偏离。相反,在偏后期的审查机制(如 PR Review)中,由于缺乏前期契约锚定,不同智能体各自并发写出了一套自洽但互不兼容的代码,审查环节不得不在大量已经出现语义漂移的代码中艰难权衡。此时智能体之间的沟通不再是信息增益,而演变成冗长的撕扯与妥协,不仅严重消耗 Token,还常常在强行合并时破坏原有的正常功能。

更具讽刺意味的是“强项目经理监督(PM Oversight)”模式。在很多工程设想中,配置一个统筹全局的 PM Agent 来指挥各成员应该能提升协调度。但实验数据表明,重度管理往往成为系统性能的绊脚石。PM Agent 不仅自身需要消耗大量上下文去读取全员状态,容易形成通讯瓶颈,而且由于 LLM 在长文本推理下对局部细节代码的掌控力衰退,PM 给出的指令往往浮于表面。在 DeepSeek v4 Pro 的即时通讯任务第三轮迭代中,PM 试图指挥团队修复用户资料编辑与 API 文档,结果团队修好了文档,却把此前已经运转良好的用户搜索、好友申请、消息发送、未读计数和群聊等核心流程全部改挂,导致得分从第二轮的 80.9 分暴跌至 66.0 分。过度干预和责任模糊,直接诱发了灾难性的“功能回退(Regression)”。

模型的性格画像与“成本—质量”权衡

除了组织拓扑的巨大影响,MSEval 还通过多维度的资源消耗曲线勾勒出了不同前沿模型的行为画像。

在即时通讯等复杂项目的测试中,Claude Opus 4.8 展现出了极高的工程上限,最终轮次能够打出 97 分的顶尖成绩。然而,这种高分是用极其昂贵的代价换来的:整个协作交付过程耗时达 110 分钟,Token 账单高达约 654 美元。相比之下,GPT-5.5 展现出了极强的工程性价比,交付质量高达 96 分,但耗时仅需 74 分钟,花费仅约 138 美元,性价比显著拉开差距。

在全网格长期基准测试中,国产模型也表现出了鲜明的性格特征。GLM-5.2 在全网格平均分上名列前茅,在面对复杂架构时具备极强的代码韧性,但其最大短板在于推理与生成速度极慢。其物理运行耗时达到了 DeepSeek v4 Pro 的 2.6 倍左右,美元成本约为后者的 8 倍,在许多第一轮任务中由于触碰了 90 分钟的硬性时间预算上限,只能提交未写完的路由,不得不将得分希望寄托在后序轮次的拉升上。而 DeepSeek v4 Pro 则表现为一个非常稳定的“中坚基线”,在平衡耗时、成本与工程实现完整度上展现出均衡的工业落地潜质。

对比之下,偏向轻量快速推理的模型(如 Qwen3.6-Flash)则遭遇了滑铁卢。该模型在所有 10 种模式下均无法建立起哪怕最基础的可跑通系统,全线停留在 0 分(最终轮耗时 39 至 270 分钟不等)。深入分析其日志发现,轻量级模型在面对零起点的复杂工程时,极易生成结构破碎的初版草稿,且缺乏遵循 CI/CD 环境报错与端口协议进行自愈的能力,这也反向证明了 MSEval 对代码真实工程能力的检验极为严苛,绝非靠“套路式生成”即可蒙混过关。

缺陷归因:系统为什么拿不到满分?

在所有 300 次全网格测试运行产生的 600 次相邻轮次迭代中,有 82.0% 的转换实现了得分提升,94.7% 的项目在经历三轮 TAgent 反馈后最终得分高于第一轮(R1)。这证明 TAgent 生成的量规缺陷报告确实具备高度的可操作性,能够驱动智能体团队进行有效自愈。

但随之而来的问题是:为什么绝大多数 Agent 团队即便经历了三轮优化,得分依然很难达到 100 分的完美状态?

研究人员对被测智能体触发的 1,440 处未通过项进行了人工与自动化结合的根本原因归因分析。统计发现,在所有未通过的检查中,有 86% 的项智能体依然获得了部分分数,只有 14% 彻底得零分。这说明当前的 Frontier Agent 团队在工程上已经几乎不会产出完全无法启动的“崩溃软件”,绝大多数情况下他们交付的是一个“核心链路可运行、但边缘功能与交互细节残缺”的半成品。

更有深度的发现隐藏在基础设施层面。在未能拿到的满分项目中,有相当一部分被固定扣除项所锁定。例如与部署层集成相关的网络安全和传输规范(如必须通过内部部署网关 XDeploy 提供的 TLS 加密、HTTPS 重定向以及安全 WebSocket 连接),在近 80% 的运行中均有失分(占所有失败项的 8.5%)。Agent 往往在本地代码逻辑中实现了功能,却忽视了真实网络环境下严苛的证书链与反向代理约束。反观代码本身的静态缺陷、文档缺损(3.9%)或 UI 接线失灵(2.6%),所占比例反而极小。这意味着,当前代码智能体最大的能力瓶颈,早已不是写出能跑的 Python 函数,而是在复杂的跨组件契约、环境集成协议以及全栈网络链路上保持无缝闭环的能力

总结与启示

MSEval 通过 100 组真实项目与协作模式的严谨评测,将多智能体软件开发的研究视角从单一的模型代码生成能力,强行拉到了分布式系统协同设计与组织架构的高度。它用扎实的实验数据打破了“只要底座模型够聪明,随便搭个 Multi-Agent 架构都能起飞”的盲目乐观。

实验给未来多智能体落地提供了两点极具操作性的启发:

其一,协同拓扑不是一次性写在 Prompt 里的装饰品,而是决定全流程产出效能的“一等控制面(First-Class Control Surface)”。在实际工程落地中,盲目引入复杂的角色扮演和多重管理层往往只会增加系统的熵值与通讯负担。明确职责所有权(Accountability)、利用“测试先行”固化验收边界、采用结构化流水线(Pipeline)降低上下文交叉污染,是让 Agent 团队发挥稳定效能的最优解。

其二,未来的 Agent 运行时必须具备动态调整组织形态与主动熔断(Early Stopping)的能力。静态不变的组织架构无法通吃所有工程阶段。一个成熟的 Agent 系统应当学会:在架构设计初期收紧控制、串行敲定接口契约;在功能填充期利用并行小队快速放量;在集成调试期及时阻断无休止的协商仲裁,防止无序的并发修改破坏整体代码的一致性。

当 AI 从编写单点代码片段走向独立交付庞大软件,如何组织这些数字员工,正在变得比挑选模型本身更加重要。MSEval 的开源不仅为学术界提供了一面高标准的镜子,也为所有尝试构建多智能体工程平台的开发者敲响了警钟:决定代码质量上限的,永远是清晰的契约、严格的边界与高效的组织。