SWE-Duel：让编程智能体互出考题、红蓝对决的新基准

2024年8月，OpenAI做了一件事，没怎么声张：官方页面上那个叫SWE-bench Verified的成绩，不再展示了。

当时很少有人大张旗鼓地聊这件事，可懂行的人心里清楚尴尬在哪。这个基准一度被当成衡量AI编程能力的黄金标准，后来被发现，最强的那批模型已经能直接把标准答案"背"出来。不是它们真有多聪明，是这些题目本身早被悄悄塞进了训练数据。

好比一场考试，题库三年没换过。等你发现满分学生越来越多，才反应过来：答案可能早就印在课本某个角落里了。

**这不是个例，而是整个编程基准测试领域正在面临的系统性危机。**

有人会问，换一批新题不就完了？麻烦恰恰在这儿。

测试题会"过期"，但这不是唯一的麻烦

先说说这件事到底有多普遍。

SWE-bench-Live、SWE-rebench这些后来出现的基准，确实想到了"用新鲜题目"这个解法，专门去抓模型训练截止日期之后才出现的GitHub问题。听着挺聪明，可这里头藏着一个更深的坑：题目来自人类开发者的日常issue，而人类开发者日常issue的难度上限，就摆在那儿。

换句话说，题是新的，但题有多难，取决于人类程序员平时随手写出的bug，跟被测试的AI没什么关系。

打个比方。你是体育老师，想测一群运动员的短跑能力。每年换新跑道、换新发令枪，题目确实"新鲜"了。可如果这批运动员的训练强度一年比一年猛，而你设定的距离永远是100米，终有一天所有人都能跑进10秒，测试就失去了区分度。

距离本身，得跟着运动员的能力一起变长。

另一条路，是让模型自己生成测试任务。这个思路本身不新鲜。

**论文SWE-Duel: Towards a Self-Scaling Arena for Coding Agents**（以下简称SWE-Duel）提到两个先行者：BugPilot收集的是AI智能体在添加新功能时意外引入的bug；SwingArena则让两个大模型互相对抗，一个提交补丁，一个写测试去验证。

但这两者都没能彻底解决问题。

BugPilot生成的任务集是提前备好、固定不变的。题库虽然出自AI之手，可还是一次性打包好的，不会随被测模型变强而变难。SwingArena引入了对抗机制，题目素材却依然来自固定的人类GitHub issue池子，只是让AI去写测试用例。题目本身的难度上限，还是绕不开"人类随手写的bug有多难"这道坎。

新加坡管理大学的研究团队由此提出一个直击要害的问题：能不能做一个基准测试，题目和答案都在评测那一刻才被创造出来，而且题目难度由参赛选手自己的水平决定？

这就是SWE-Duel要回答的问题。

红蓝对决：一场没有裁判出题的比赛

SWE-Duel的核心设计，是让两个编程智能体在真实的代码仓库上玩一场"红方蓝方"游戏。

红方每轮对决要完成三项工作。第一步，从真实开源项目中选定一个模块，设计并实现一项新功能，并配上测试用例，证明该功能正确；随后，红方要在刚写好的功能代码中悄悄植入一个不易察觉的bug，并编写一套只有该bug存在时才会失败的“密封测试”。

接下来轮到蓝方登场。蓝方拿到的是一份看起来人畜无害的代码提交（Pull Request，以下简称PR

> **PR**：程序员向代码仓库提交修改请求的常见方式，相当于"我写好了这部分代码，请审核后合并进主干"。

），其中包含新功能和功能测试，但蓝方并不知道里面藏有bug。蓝方需要审查这份代码，发现问题就修复，然后提交自己的修改版本。

胜负如何判定？蓝方提交的修改版本必须同时通过三道关卡：原有仓库的回归测试不得破坏任何已有功能；新功能的测试仍须通过，以证明新功能未被改坏；此外，蓝方完全不知道存在的密封bug测试也必须通过。三关全部通过，蓝方获胜；只要有一关未通过，红方获胜。

蓝方想作弊，其实没门，这个设计把路堵得很死。

偷懒的法子听起来有：把整个PR撤回到最初的版本。可新功能的测试摆在那里，功能都没实现，测试必然过不去。真想赢，只能一句句读代码、定位bug、动手修。

打个比方，公司请来一位审计员，核查刚装修完的办公室验收报告。报告上写着“新增了会议室、新增了茶水间”，审计员不能图省事说“推倒重来”，验收标准里明明白白要求“新增设施必须保留”。他得真的走进那间会议室，摸摸墙角、看看电路，才可能发现那道藏得很巧的接缝——表面上不影响美观，三个月后却会漏水。

要是没有“功能必须保留”这道门槛，蓝方最省事的作弊办法就是把代码打回原形：bug是没了，新功能也跟着没了。这算不上修bug，只是绕开问题。SWE-Duel把bug藏进新功能内部，等于从设计上封死了这条退路。

红方造任务的流程还有一步。论文设置了一道很关键的“自证”关卡：埋完bug之后，红方要换一个全新的、没有记忆的会话，面对自己刚造出来的、只含公开信息的代码——也就是蓝方将来看到的那一版——在盲审状态下试着把bug修好。

> **会话隔离(context-isolated sessions)**：每次新会话都相当于“失忆重启”，智能体不记得此前自己做过什么，只能依据传入的信息重新判断。

红方只有在盲审状态下修好这个bug，任务才会被正式收进“任务库”；修不好，就算生成失败，直接丢掉重来。

这道关卡要防的是“无解的题目”。

可以想象一家出版社收到一份离谱的脑筋急转弯投稿。编辑决定采用之前，会先找一个完全不知道答案、也没参与创作的人试解一遍。连这个人都想不出来，这道题多半是出题人自己都没想清楚的死局，不该收进题库里误导读者。

少了这道自证关卡会怎样？红方为了追求胜率，完全可能埋一个连自己都解释不清、逻辑上根本无解的怪bug。这种任务对蓝方不公平，也会伤到整个评测体系的可信度。

任务库：生成一次，反复使用，但有保质期

任务通过验证后，会被存进一个“任务库”。

有个设计细节值得说说。每个参赛者（论文里叫“参与者”，由一个大模型加一个执行框架组成，比如GPT-5.5配上Codex CLI）在每个代码仓库上，最多能尝试生成固定数量的任务槽位，每个槽位允许连续试五次。五次都没造出合格任务——三道验证关卡，功能验证、bug验证、自证验证，全都没过——这个槽位就记为“空槽”，永远不会再补上。

> **harness(执行框架)**：给大模型提供工具调用、上下文管理、命令执行能力的“外壳程序”，论文里用到了mini-swe-agent、Codex CLI、Claude Code三种。同一个模型换不同框架，相当于换了不同的参赛资格，各自独立计分。

“空槽不补”这条规则看着小气，其实有讲究：能不能造出合格任务，本身就是参赛者编程能力的一部分。要是允许无限重试直到成功，“造题能力”这个指标就被稀释了——尝试次数足够多，理论上谁都能撞出一个合格任务。

任务库一旦生成完毕，整场比赛期间保持不变，所有对手面对的都是同一批题目，公平性由此保证。不过论文也特别说明，这个任务库不能无限期对外公开：公开之后它就不再“新鲜”，未来评测新模型时这批题目就失去了意义。论文因此建议，每次复现研究都重新生成一批任务，被公开过的任务库应当标记为“退休”，不能再用于评测未来发布的模型。

真刀真枪的较量：11个参赛者，1500个回合

研究团队找来了当时最前沿的11组“模型+框架”组合参赛，包括GPT-5.5（分别搭配Codex CLI和mini-swe-agent两种框架）、Claude Opus 4.8（搭配mini-swe-agent和Claude Code两种框架）、Kimi K2.7 Code、DeepSeek V4 Pro、GLM-5.2、Qwen3.7 Max、Nvidia Nemotron 3 Ultra、MiniMax M3，以及Gemini 3.1 Pro。

比赛场地是15个真实开源项目，横跨Python、Java、Go、JavaScript、C/C++五种编程语言，Flask、SQLAlchemy、Express这些你可能听说过的知名项目都在其中。十个初始参赛者两两捉对，打了一场完整的循环赛，凑出45场比赛；之后Gemini 3.1 Pro作为“迟到选手”加入，又打了5场。每场比赛包含30个回合（15个仓库乘以红蓝互换两个方向），总共1500个回合的较量。

输赢怎么判定？论文用了一个叫Bradley-Terry的评分体系

所谓 Bradley-Terry 评分，就是让选手两两交手，再根据胜负结果倒推出各自的“实力值”；这是一种统计方法，竞技排名场景里用得很多，像聊天机器人评测平台 Chatbot Arena，就是靠它给大模型排座次的。

来给所有参赛者算一个综合实力分。

结果挺有意思。

排名第一的是GPT-5.5搭配Codex CLI，实力分+2.82。它的强项不在出题，而在解题：复审别人埋的bug时，98.3%的情况下都能把问题修好。

排在第二位的是Claude Opus 4.8加mini-swe-agent，实力分+2.46。可它的长处跟第一名正好反过来：轮到它当红方出题，胜率达到27.3%，全场没人比它更高。作为对照，排名第一的GPT-5.5在两种框架下分别只有11.3%和10.4%，被它甩开一倍还不止。换句话说，它埋下的bug更难被揪出来。

同一个榜单的冠亚军，依赖的竟是两套完全不同的本事。一个极擅长“找茬”，一个极擅长“藏雷”。这个现象本身就有意思：放到软件工程里，能解题和能造出有价值的难题，居然是两种彼此相对独立的能力。

垫底的是MiniMax M3和刚进来的Gemini 3.1 Pro。它们解题能力偏弱，更要命的是连出题都没做好，常常连一个合格任务都产不出来，综合得分因此被直接拉低。

新面孔怎么挤进一场已经开打的比赛

这是SWE-Duel设计里相当实用的一处安排。

按常规循环赛的算法，N个参赛者的情况下，新人想跟所有人过一遍招，就得打N场。人越多，新人进场的代价越大。不少竞技型评测体系都卡在这：入场门槛越抬越高。

SWE-Duel把这套思路换成了Chatbot Arena的“主动采样”：新人只需打大约log₂N+1场（10个老选手时约5场），对手由算法挑出来，不必挨个碰一遍。

打个比方，一个辩论新手想加入已打了半个赛季的联赛。照常理，他得跟联赛里每支队伍都打一场友谊赛才能定级。但组织者有个更省事的法子：翻历史战绩，挑出五个“信息量最大”的对手——比如一个中上游、一个中下游，再加几个实力接近的——五场打完，这新人大概排第几就能推算出来，其余几十支队伍不用陪他跑一遍。

Gemini 3.1 Pro走的就是这条路，只打了5场，最终排在第11位，也就是垫底；置信区间显示，它的排名大概率落在第9到第11名之间。更关键的一点：把它加进来之后，原先45场比赛排出的顺序一点没动——用Kendall's τ系数衡量，相关性是满分1.0。这说明“少量精选对手”的入场机制站得住，不会因为抽样不够而搅乱原有秩序。

论文还算了笔账：精选对手的入场方式花费约243美元；若照老办法跟全部十个老选手各打一场，预计要花380美元上下。算下来省了大约三分之一的评测成本。

出题者变强，任务难度真会跟着涨吗

整篇论文里，我认为最有说服力的是这个实验。

前面提过，SWE-Duel的设计初衷是“任务难度由参赛者自己的水平决定”。可光讲道理不够，得拿数据说话。研究团队为此设计了一个对照实验：解题的裁判固定为DeepSeek-V4-Pro加mini-swe-agent，出题方则换成同一模型家族里三个不同世代的版本——GLM-5.1、GLM-5.2、GLM-5.3，版本号越大越新，理论上也越强。

三个版本在同样的15个代码仓库上各自生成任务，再统一交给那个固定的裁判去解。

结果：GLM-5.1出的题，裁判有8.3%解不出来；GLM-5.2出的题，裁判0%解不出来，全部搞定；最新的GLM-5.3出的题，裁判有42.9%解不出来。

这个跳跃幅度不小。新版本出的题，裁判失败率比老版本高出十倍以上。论文还做了统计检验（单边精确条件Cochran-Armitage趋势检验），p值为0.015，说明这一上升趋势并非随机波动。

研究团队接着又让三个版本互相出题、互相解题，打了一场内部小型循环赛。结果是：GLM-5.3出的题让GLM-5.1输掉一半回合（7/14），让GLM-5.2输掉接近三成回合（4/14）；而两个老版本出的题几乎难不倒GLM-5.3，各自只赢了一次。

这些数据合起来指向一件事：任务难度确实随出题者能力水涨船高，而且这种关系在统计上显著。

这正是论文想验证的核心假设——一个能自我进化的评测场地，题目难度不该是固定的天花板，而该是一面随时映出参赛者当前水平的镜子。镜中影像变了，是因为站在镜前的人变了，不是镜子被人为调高了分辨率。

缺了这套自我进化机制，评测体系早晚会重蹈前面提到的SWE-bench Verified的覆辙：模型越来越强，题目原地不动，最后大家一起“背答案”，测试本身也就失去意义。

细节上的较真：这套体系靠不靠谱

论文还花了不少篇幅验证评测机制本身是否可靠。这种自我审视的态度并不多见。

比如，红方埋下的bug是否真靠得住？会不会出现蓝方明明修对了、却因为测试写得太刁钻而被判错？研究团队安排两位作者人工检查了50个蓝方失败的案例，发现只有约6%属于“假阴性”，即蓝方其实修对了，只因密封测试要求过于具体而被误判。这个比例不算高，整体评判机制还算公道。

红方那道“自证”关卡本身靠不靠谱？模型推理带点随机性，同一个任务反复测，结果未必每次都一样。研究团队从已收录任务里挑了44个，每个再跑三次，91.7%的情况下任务能被稳定解出；只有一个任务三次全败。可见“侥幸过关”确实存在，但很罕见。

研究团队还把“硬件框架”这个变量单独拎出来做了对照实验：同一个模型分别套上mini-swe-agent、Codex CLI、Claude Code三种框架，三者之间的实力差距在统计上并不显著，置信区间全部重叠。至少在这个实验规模下，选哪个执行框架对最终战绩的影响，比不上模型本身的差异来得明显。

代价：这套评测体系要花多少钱

整场1500回合的比赛跑完，API调用费用总共2109美元，平均每场约26美元。

其中，红方出题环节花了670美元（含所有失败重试），盲审自证环节158美元，蓝方解题评测则占了1281美元。蓝方解题这一块占了六成多开销，这也不难理解，因为每个参赛者都要当一次蓝方去解其他所有人出的题，计算量自然最大。

写在后面

读完这篇论文，我印象最深的其实不是那张排名榜，而是那个“自证关卡”的设计。

不少评测体系琢磨的是“题目怎么才能更难”，SWE-Duel却用不少篇幅去回答一个更靠前的问题：“这道题确实有解，怎么证明”。这个路子不常见。多数竞赛设计者把出题人当成权威，默认题目天然成立；SWE-Duel反过来要求出题人先过一道关——在盲审状态下证明自己出的题不是胡来。说白了，这种“出题人自证清白”的做法，是把信任押在可核查的行为上，而非出题人的身份权威上。

还有个细节我反复看过：GPT-5.5和Claude Opus 4.8在这份榜单上像分裂成了两个人。一个擅长修bug，一个擅长埋bug，可两边都没能同时占住。老话在这里又被验证了一遍——发现问题与造出有价值的难题，走的是两条认知路径：前者靠收敛式分析，后者靠发散式设计。会修车的师傅，未必能设计出一辆让同行师傅都头疼的故障车；两件事看着挨得近，中间那道门槛其实不低。

论文里那个GLM版本阶梯实验给出的数据（8.3%到0%再到42.9%）算初步证据，可样本只有十几个任务，置信区间也不窄。严格讲，这个结论还停在“初步证据”，离“已经证实”有距离，论文自己也承认了。我好奇的是，把阶梯实验扩到几十个任务、再多覆盖几个模型家族，趋势还站得住吗？或者过了某个阈值会不会饱和？毕竟没有哪条增长曲线能一直线性向上。

论文留了一道没写完的题：参赛者之间解题能力的差距越缩越小，他们出题能力的差距会不会跟着收窄？真到那天，这个擂台又该往哪走？

Q&A

Q1：SWE-Duel是什么？

A：SWE-Duel是一套让编程AI智能体互相出题、互相解题的自我进化评测体系：红方在真实代码仓库里实现新功能并暗藏bug，蓝方在盲审条件下修复，任务难度由参赛者自身水平决定，从根上避免了题目提前泄露进训练数据的问题。

Q2：SWE-Duel和SWE-bench这类传统编程基准测试有什么区别？

A：传统基准测试的题目提前固定、公开发布，时间一长模型容易“背答案”，难度上限也被人类开发者日常写的bug难度卡住。SWE-Duel不一样，题目和标准答案都由参赛AI在评测当下现场生成，没有提前泄露的可能，难度还会随着参赛者水平提升自动变难。

Q3：SWE-Duel的比赛结果显示了什么有趣现象？

A：排名第一的GPT-5.5（配Codex CLI）是最强的解题者，审查bug修复成功率达98.3%；排名第二的Claude Opus 4.8（配mini-swe-agent）却是最强的出题者，埋藏的bug让对手失手的概率高达27.3%，两项能力并不重合在同一个模型上。