DeepSWE高分遭质疑

MaxxBench 把矛头对准了 DeepSWE 的“高分”

截至 2026 年 11 月 7 日，AI 编程 Agent 的评测争议已经从“谁分数更高”转向“这些分数究竟是怎么算出来的”。 MaxxBench 最近发布《Nice DeepSWE score. But is it true?》，公开质疑 DeepSWE 高分能否被当作编程 Agent 真实能力的直接证明。

MaxxBench 是一个强调真实执行环境、可复现过程和严格任务核验的 Agent 评测项目。 它这次的核心态度并不是简单指控 DeepSWE“造假”，而是追问一个更棘手的问题：如果任务是否有效、失败是否应被豁免、Agent 能尝试几次、验证器是否会人工修正，都能显著改变最终通过率，那么排行榜上的一个百分比还有多少可比性？

DeepSWE 是一套面向长周期、原创软件工程任务的 AI 编程 Agent 基准。 与只要求生成函数或修补单个缺陷的代码测试不同，DeepSWE 试图让 Agent 在完整代码仓库中理解需求、定位问题、修改多个文件并通过隐藏测试，其公开论文标题就是“在原创、长周期工程任务上衡量前沿编程 Agent”。

这类基准显然比 HumanEval 式的短代码题更接近工程实践，但“更接近真实”不等于“已经等于真实”。

争议的重点不是一道题，而是整条评分流水线

AI 编程 Agent 的基准分数是任务、模型、Agent 脚手架、运行环境和评分规则共同作用的结果。 同一个底层模型接入不同搜索工具、上下文压缩策略、终端权限和重试机制，最终成绩可能完全不同；把 Agent 分数直接写成模型分数，本身就是一种口径偷换。

Agent 脚手架是包裹在模型外部、负责规划、检索、工具调用、错误恢复和上下文管理的软件系统。 Claude、GPT、Gemini 或其他模型只是其中的推理核心，真正参与测试的通常是一整套系统，而不是一个裸模型。

MaxxBench 的质疑因此值得认真对待。它实际上把 DeepSWE 的高分拆成了几个需要分别回答的问题：

1. 测试任务是否都有效，还是存在破损依赖、错误隐藏测试和需求歧义？
2. 失败任务是否被移出分母，移除发生在运行前还是查看结果后？
3. 每项任务允许多少次 rollout，最终汇报的是单次成功率还是多次尝试后的最好结果？
4. 评分器是否只检查自动化测试，还是允许人工或模型评审推翻原始结果？
5. 参评 Agent 是否使用了相同工具、相同预算和相同执行环境？
6. 任务、补丁或测试是否可能出现在模型训练数据、搜索索引或公开仓库历史中？

这些问题中的任何一项都足以改变排行榜排序。 它们叠加在一起时，最终数字更像一份实验结果，而不是某种固定不变的“编程智商”。

DeepSWE 自己其实也承认：自动评分会犯错

DeepSWE 论文并没有假装验证器绝对可靠，反而专门讨论了评分中的假阳性和假阴性。 论文列出的失败类型包括隐藏测试或测试配置损坏、任务描述存在多种合理解释，以及沙箱、依赖或外部环境错误阻止 Agent 完成任务。

这三种情况分别意味着：

• Agent 可能做对了，但坏掉的测试把它判成失败；
• Agent 可能给出了合理实现，但没有命中出题者唯一接受的解释；
• Agent 可能根本没有获得一次公平执行机会，却仍被记作能力失败。

验证器修正是对自动评分结果进行二次核验并纠正误判的过程。 这种机制有必要，因为真实代码仓库远比数学选择题复杂；但修正流程必须预先定义、保留审计记录，并对所有参评系统一视同仁，否则它也可能成为新的主观偏差来源。

DeepSWE 论文披露了一项针对评分可靠性的抽样审计：研究者从 DeepSWE 和 SWE-Bench Pro 各随机抽取 30 个任务，对 16 种前沿 Agent 配置中的 9 种配置各运行 3 次。按公开描述计算，这一审计设计最多涉及 30 × 2 × 9 × 3 = 1620 条运行轨迹。

1620 条轨迹听起来不少，但它依然只是对两个基准各 30 道题的抽样，而不是对完整榜单的逐项复核。 这个实验可以帮助估计验证器误差，却不能自动证明所有任务、所有配置和所有榜单成绩都具有同等可信度。

“跑三次取最好”与“只跑一次”不是同一种能力

Rollout 是 Agent 针对同一任务进行的一次完整独立尝试。 对带有随机采样、动态规划和工具调用的 Agent 来说，多次 rollout 往往会产生不同补丁，因此评测必须明确究竟统计单次成功率、平均成功率，还是多次尝试中至少一次成功的比例。

假设某个 Agent 单次解决任务的概率为 50%，三次独立尝试中至少成功一次的理论概率是：

1 - (1 - 0.5)³ = 87.5%

50% 和 87.5% 可以同时来自同一个 Agent，只是统计问题不同。 前者更接近开发者把任务交给 Agent 一次后直接验收的体验，后者更接近投入三倍推理成本、并由外部机制从多个结果中挑选成功方案的体验。

问题还不止于此。实际系统往往无法事先知道哪份补丁是正确的，因此“取最好结果”还需要一个选择器：它可能是隐藏测试、额外模型、人工评审或更强的验证 Agent。如果排行榜使用了只有评测方才能访问的隐藏测试来挑选最佳 rollout，用户在真实工作中未必能够复制这一流程。

任何没有同时披露尝试次数和选择机制的 Agent 高分，都缺少关键上下文。 这也是 MaxxBench 这轮质疑最有价值的地方：它迫使行业把分数背后的计算预算摆到桌面上。

分母一变，排行榜就可能重排

无效任务处理方式是 Agent 基准中最容易被忽略、也最容易放大成绩的环节。 假设一个基准共有 100 道任务，Agent 通过 60 道，原始通过率就是 60%；如果评测方随后认定 10 道失败任务存在歧义并全部移出分母，成绩会变成 60 ÷ 90 = 66.7%，在 Agent 没多解决一道题的情况下增加 6.7 个百分点。

任务清理本身没有错，错误在于清理规则不透明或只对特定系统有利。更稳妥的做法是同时公布：

• 原始任务数与原始通过率；
• 预注册的无效任务判定标准；
• 被移除任务的编号、原因和证据；
• 移除前后的分数变化；
• 其他 Agent 在这些任务上的结果；
• 负责裁决的人或模型是否知道参评系统身份。

查看结果后再决定哪些失败“不算”，会产生典型的后验选择偏差。 即使研究团队没有主观操纵排名，只要判定者知道某条轨迹来自哪个系统，也可能无意识地对不同结果采用不同宽严尺度。

这并不意味着 DeepSWE 一定存在不当处理。更准确的判断是：MaxxBench 提出的是足以影响结论的方法学风险，而公开资料是否已经完整排除这些风险，仍需要可下载轨迹、版本化任务清单和独立复跑来回答。

几个常见分数，名字相似但不能横向比较

AI 编程榜单最大的问题之一，是不同统计口径经常被压缩成同一个“通过率”。 开发者看到两个百分比时，往往会本能地比较大小，但它们可能分别测量单次解题、多次搜索、人工筛选和修正后的不同结果。

| 指标口径 | 实际含义 | 优点 | 主要风险 | |---|---|---|---| | 单次通过率 | 每题只运行一次，统计成功比例 | 最接近一次性交付 | 随机波动较大 | | 多次平均通过率 | 每题运行多次，对成功率取平均 | 能估计稳定性 | 成本高，仍需披露采样参数 | | pass@k | k 次尝试中至少一次成功 | 衡量搜索上限 | k 越大分数越高，未体现如何选答案 | | Best-of-N | 生成 N 个方案，再由选择器挑一个 | 接近带验证器的生产系统 | 选择器能力和额外成本容易被隐藏 | | 修正后通过率 | 人工或评审模型纠正验证器误判 | 能减少坏测试造成的误差 | 容易引入主观性和后验偏差 | | 有效任务通过率 | 移除无效任务后重新计算 | 避免坏题污染结论 | 分母变化可能抬高成绩 |

排行榜只有在口径一致时才有可比性。 如果 DeepSWE 的一个成绩经过多次尝试、验证器复核和无效任务剔除，而另一个 SWE-bench 成绩是单次运行的原始结果，即便两者都写成百分比，也不应直接得出前者 Agent 更强的结论。

DeepSWE 比旧基准更难，但“原创”也不是万能药

原创任务是没有直接复用历史公开 issue、现成补丁和已知测试答案的新工程任务。 DeepSWE 强调原创与长周期，主要是为了降低数据污染，并避免 Agent 通过记忆公开仓库中的历史修复直接命中答案。

这个方向是对的。SWE-bench 一类基准建立在真实开源仓库和历史 issue 上，真实性很高，但也天然面临训练数据污染：模型可能见过问题描述、提交记录、补丁讨论，甚至完整答案。随着基准在 GitHub、论文和模型评测报告中反复传播，污染风险只会继续增加。

原创并不能自动消除泄漏和过拟合。 如果任务开发过程、参考补丁、测试代码或相关分支曾经进入公开环境，搜索型 Agent 仍可能检索到线索；如果团队反复在固定测试集上调节提示词、工具策略和停止条件，Agent 也可能对基准形成系统级过拟合，而不是模型参数级记忆。

更关键的是，原创任务由评测团队设计，它们是否代表真实软件团队的需求分布仍需验证。一套任务可能特别偏爱修 bug，另一套可能强调功能开发；一套仓库以 Python 为主，另一套包含复杂构建系统。所谓“更难”，通常只在具体任务分布中成立，不能自动外推到所有工程场景。

真正需要比较的，是能力、可靠性、成本和时间

Agent 的生产力不是通过率一个数字，而是质量、成本、延迟和人工介入的联合函数。 一个系统用 20 次尝试、数小时运行和高额推理预算获得 80% 通过率，未必比一个单次运行、10 分钟内达到 70% 的系统更有商业价值。

| 评测维度 | 应披露的数据 | 对实际使用的意义 | |---|---|---| | 任务成功率 | 单次、平均值、pass@k 分开报告 | 判断能力上限与稳定性 | | Token 与推理成本 | 每题均值、中位数、P95 | 判断规模化部署价格 | | 运行时间 | 墙钟时间中位数与长尾 | 判断能否进入开发工作流 | | 重试次数 | 每题最大值与实际均值 | 识别算力换分现象 | | 人工介入 | 提示、选择、修正次数 | 判断是否真正自治 | | 环境失败率 | 沙箱、依赖、网络故障占比 | 区分系统能力与基础设施问题 | | 补丁质量 | 测试通过、代码审查、回归风险 | 避免只为隐藏测试投机 | | 结果方差 | 不同随机种子和批次波动 | 判断成绩是否可复现 |

成本必须成为 Agent 榜单的一等指标。 红杉中国推出的 xbench 同样强调技术—市场契合度，核心理由就是投入更多推理算力通常能换来更高效果，但现实应用必须在花费、延迟和成功率之间取得平衡。

这也是 Agent 时代与静态模型时代最大的差异。传统问答基准通常只有一次前向推理，而编程 Agent 会搜索仓库、阅读文件、执行命令、修改代码、运行测试、发现失败后继续迭代。多走十轮不只是“想得更久”，还意味着更高费用、更长等待和更多环境故障机会。

一个可信的编程 Agent 榜单至少应公开什么

下一代编程 Agent 基准必须从“公布一个分数”升级为“公布一份可审计实验”。 最低限度应包括以下六类材料：

1. 版本化任务集：每个任务都有固定提交哈希、依赖锁文件、测试版本和变更记录。
2. 完整运行轨迹：保留模型输出、工具调用、命令执行、文件修改和错误信息。
3. 统一预算约束：限制最大 Token、运行时间、工具调用次数和 rollout 数量。
4. 预注册评分协议：在看到参评结果前写清无效任务、环境失败和歧义任务如何处理。
5. 盲化人工审计：裁决者不知道结果来自哪个模型或 Agent，减少品牌偏见。
6. 独立复跑结果：由与基准作者、模型厂商无利益关系的第三方在隔离环境复现。

排行榜还应同时给出置信区间，而不是把小数点后一位包装成精确能力差距。 如果测试集只有几十或一百多道任务，两个系统相差 1 至 3 个百分点，很可能只是随机种子、任务抽样或基础设施波动，并不意味着存在稳定代差。

这场争议不会让 Benchmark 失去意义

MaxxBench 对 DeepSWE 的质疑并不意味着所有 AI 编程基准都不可信。 Benchmark 仍然是比较系统进步最快、成本最低的办法，只是开发者不能再把榜单首位直接等同于生产环境首选。

DeepSWE 的价值也没有因此消失。它对原创任务、长周期工程、验证器误差和轨迹审计的关注，本身就是对传统 SWE-bench 模式的重要推进；MaxxBench 的价值则在于提醒行业，设计更复杂的任务并不够，评分过程也必须接受同样严格的审计。

目前最合理的结论不是“DeepSWE 高分为假”，而是“现有证据不足以让任何单一高分自动升级为真实工程能力证明”。 在完整任务版本、原始轨迹、修正规则、运行预算和第三方复跑全部对齐之前，这些成绩更适合被理解为特定实验设置下的能力估计。

开发者选择编程 Agent 时应该优先做内部任务集复测。 最有价值的测试集通常不是公开榜单中的一百道题，而是团队过去三个月真实出现过的缺陷、依赖升级、跨文件重构和测试补全任务；同时记录一次成功率、平均成本、P95 时间、人工接管率和回归缺陷数，得到的结论远比“榜单高 2 分”更接近生产力。

AI 编程 Agent 正在快速变强，但衡量它们的尺子还没有稳定下来。MaxxBench 与 DeepSWE 这场争论真正揭示的，是 Agent 行业已经进入下一阶段：大家不再只需要更高的分数，也需要知道每一分从哪里来。

参考来源

受参考链接域名范围限制，以下保留可用于查找公开复现、数据与社区讨论的国内可访问入口；MaxxBench 原文与 DeepSWE 论文的非白名单域名不在文末直接列出。

• GitHub：检索 DeepSWE 公开仓库与复现材料——用于查找任务实现、评测脚本、运行轨迹及第三方复现项目。
• Hugging Face：检索 DeepSWE 相关模型与数据条目——用于核对可能公开的数据集、模型卡和评测说明。
• Reddit：检索 DeepSWE 社区讨论——用于追踪开发者对评测口径、复现结果与排行榜可信度的公开讨论。