SWE-Duel：让编程智能体在实战中互相出题与验收

导语

传统软件工程基准通常在发布时固定任务、代码和测试。随着公开数据进入训练集，模型可能记住解法；当能力继续提升，原本有区分度的任务也会逐渐饱和。来自新加坡管理大学的研究团队提出SWE-Duel，试图把代码智能体评测从“做一套固定试卷”变成“在现场互相出题、互相验收”的竞技过程。

核心机制：Red出题，Blue排错

SWE-Duel让两个智能体在真实代码仓库中轮流扮演Red和Blue。Red先在隔离的会话中理解项目、实现一个新功能，并编写功能测试；随后，它要在该功能中埋入一个隐蔽缺陷，同时准备不会公开的触发测试。一个任务只有在通过新功能测试和仓库原有测试、但恰好无法通过缺陷测试时才会被接纳。

研究还增加了一道重要筛选：由同一个智能体开启全新会话，在不知道缺陷位置的情况下尝试修复。如果它无法完成，任务就会被排除。这一步旨在避免把“出题者自己也解决不了”的异常任务误当成高难度挑战。

接着，Blue收到代码变更或拉取请求，但不会被告知其中存在缺陷。它需要审查、修改并提交结果；只有同时通过功能测试、原有测试和隐藏缺陷测试，才算获胜。双方随后交换角色。这样的设计不仅考察生成代码的能力，也考察测试理解、代码审查和定位隐蔽错误的能力。

实验结果与观察

研究者让11组模型与工具组合在15个仓库、5种编程语言中完成1500个回合。结果显示，不同参与者的优势并不相同：GPT-5.5配合Codex CLI在缺陷修复上排名第一，修复其审查任务中98.3%的缺陷；Claude Opus 4.8配合mini-swe-agent则是更强的任务作者，Red方胜率达到27.3%。

同一模型家族的对比还提供了“难度随能力增长”的初步证据：最新版本生成的任务击败固定参考求解器的比例为42.9%，旧版本任务则为4.0%。这意味着任务作者越强，越可能构造出能够区分更强求解器的挑战，而不是简单重复既有基准模式。

意义与局限

SWE-Duel的价值在于重新思考代码评测的生命周期：任务、测试预言机和难度不必在发布日一次性确定，而可以伴随参与者实时产生。它还把“写代码”和“发现问题”放进同一套对抗框架，有望更贴近真实软件协作中的审查流程。

不过，现有结果仍是初步证据。实验规模、仓库覆盖和参与者数量有限，任务质量也依赖出题智能体能否稳定制造细微且可判定的缺陷。未来还需要更长周期、更广泛语言与项目类型的验证，并研究如何防止智能体利用评测流程本身。无论如何，SWE-Duel展示了一条值得关注的方向：编程基准不只是测试集，也可以成为一个持续自我升级的竞技场。

来源：Hugging Face Daily Papers