SWE-Duel 让两个 AI 编程 Agent 互出难题，这才是真正动态的编程能力考场

用静态数据集测代码模型已经没意义了，因为题目早就在训练集里被喂过无数遍，分数高可能只是因为模型见过答案。SWE-Duel 换了个思路，让两个 Agent 扮演红蓝方，一个负责在代码库里埋坑，另一个负责填坑，题目在运行时刻实时生成，完全杜绝了数据泄露。

为什么现在的代码 Benchmark 没法信

现在的编程能力测试大多是静态的，比如给一个固定的 Bug 列表让模型修复。这种方式有三个致命伤。首先是数据泄露，一旦测试集公开，这些代码片段很快就会进入下一代模型的训练语料，导致模型在测试时其实是在做记忆检索。其次是饱和度问题，当模型强到一定程度，静态题库里的难题就变成了简单题，无法区分顶尖模型之间的差距。最后是缺乏多样性，现实中的软件工程涉及功能提案、实现和回归测试，而静态测试往往只关注修复。
SWE-Duel 提出的自缩放（Self-Scaling）概念就是为了解决这些痛点。它不再预设题目，而是让参与评估的模型自己来创造题目。这意味着任务的难度是随着参与者的能力同步提升的：模型越强，它能设计的 Bug 就越隐蔽，对对手提出的挑战也就越高。这种机制让评测基准变成了一个动态的天平，而不是一把刻度固定的尺子。

这里的红蓝对抗具体是怎么跑的

SWE-Duel 的核心是一个镜像对战流程，两个编程 Agent 分别担任红方（出题者）和蓝方（解题者），通过多轮角色互换来决定谁更强。
红方的任务是扮演一个狡猾的开发者，它需要在真实的软件仓库中完成一套复杂的“陷阱构建”流程：

• 功能实现： 红方首先得在仓库里提出一个新功能，并实际编写代码将其实现，同时配套相应的功能测试用例。
• 埋设漏洞： 在功能实现之后，红方要在该功能中植入一个隐蔽的 Bug，并编写能够触发该 Bug 的密封测试用例。
• 质量把关： 并不是红方随手写的 PR 都能被采纳。一个合格的“陷阱”必须满足两个硬性条件。第一，该 PR 必须通过所有原有的仓库测试和新功能测试，但唯独在 Bug 测试用例上失败。第二，为了排除那些根本没法修复的死题，系统会启动一个全新的、没有任何上下文记忆的同模型 Session，如果这个新 Session 能在盲测状态下修复这个 Bug，这个任务才被认定为有效。

蓝方的任务则相对纯粹，它面对的是红方提交的这个 PR。蓝方在完全不知道其中包含 Bug 的情况下进行代码审查和修复。如果蓝方的修改能够一次性通过功能测试、原有仓库测试以及那个被密封的 Bug 测试，那么蓝方就在这一回合获胜。
这种设计最精妙的地方在于，它把“代码实现能力”和“代码审查/调试能力”解耦了。红方赢在能写出让对手看不出的 Bug，蓝方赢在能一眼识破陷阱。

15 个仓库和 1500 轮对战揭露的真相

为了验证这套机制，研究人员在 5 种编程语言的 15 个真实仓库上，组织了 11 个模型-框架组合的锦标赛，总共运行了 1500 轮对战。这次测试的结果打破了一些认知，因为最强的“解题者”和最强的“出题者”并不是同一个模型。

• 最强解题能力： GPT-5.5 配合 Codex CLI 拿到了第一名。它展现出了极其恐怖的漏洞修复率，在面对红方设计的各种陷阱时，能够成功修复其中 98.3% 的缺陷。这说明在纯粹的 Bug 扫描和逻辑修复上，GPT-5.5 依然处于领先地位。
• 最强出题能力： Claude Opus 4.8 配合 mini-swe-agent 则在红方角色中表现突出。它的红方胜率达到了 27.3%，这意味着它能制造出更多让对手（包括 GPT-5.5）都感到棘手的复杂漏洞。
• 能力随版本缩放： 研究人员还发现了一个关键现象：在同一个模型家族内部，新版本模型写出的题目比旧版本模型写出的题目更难。具体数据显示，新版本模型设计的任务让参考求解器的失败率高达 42.9%，而旧版本模型设计的任务失败率仅为 4.0%。

这个实验结果直接证明了自缩放机制的有效性。任务的难度不再是由一个人类专家在三年前定义的，而是由当前最强模型的能力边界实时定义的。

这种方案在实际操作中会遇到哪些坑

虽然 SWE-Duel 理论上解决了泄露问题，但在实际搭建这种对战环境时，有几个关键的逻辑死角需要处理。
首先是“不可解任务”的过滤。如果红方模型太强或者太随机，可能会写出逻辑自相矛盾的代码，导致任何模型都无法修复。这就是为什么必须引入那个“新鲜 Session 盲测”步骤。如果连出题者自己（在无记忆状态下）都修不好，这个任务就得被扔掉，否则蓝方会被冤枉。
其次是环境的隔离。红方在埋 Bug 时会产生大量中间状态和临时 Session，如果这些上下文泄露给蓝方，或者蓝方能访问到红方的思考链路，那么测试就变成了简单的内存读取，而不是逻辑推理。因此，三个上下文隔离的 Session 是保证公平性的底线。
最后是计算成本。这种评测方式极其昂贵。传统的静态评测只需要跑一遍推理，而 SWE-Duel 要求红方写功能 → 埋 Bug → 自测修复 → 蓝方修复 → 最终验证。一个回合需要多次调用高昂的 API，且涉及真实的仓库克隆和测试运行。如果要在更大规模的仓库集上跑，token 消耗将是一个天文数字。

对未来编程 Agent 评价体系的启发

SWE-Duel 给我们的最大启示是，编程能力的衡量标准应该从“结果正确”转向“博弈胜率”。
在真实的生产环境中，程序员的工作本质上就是一场红蓝对抗：你写代码（红方），你的同事在 Code Review 中找茬（蓝方），然后你根据反馈再修改。目前的 LLM 评测大多在测“能不能写出正确代码”，而忽略了“能不能发现错误代码”以及“能不能写出让别人难以维护的烂代码（虽然在评测中这是能力，但在工程中是灾难）”。
如果未来的模型评测能全面转向这种动态博弈模式，我们会发现很多在 HumanEval 上刷高分的模型，在面对一个会动态出题的对手时会迅速崩盘。因为刷分模型习惯于寻找模式（Pattern matching），而动态出题强制模型必须进行真实的逻辑推演。
这种模式也为 Agent 的自我进化提供了可能。如果一个模型能同时担任红方和蓝方，它就可以通过不断的自我对战（Self-play）来发现自己的逻辑漏洞并自我修复，而不需要依赖昂贵的人类标注数据。这或许才是通往真正自主编程 Agent 的路径：在不断的自我博弈中，将代码的鲁棒性推向极致。