# MaxxBench 抓到一个编程 Agent：改对了，又自己撤回

**Summary:** Unlap 的 MaxxBench 改动了 89 个 DeepSWE 编程任务的说明和起始代码。其中一个 agent 本来实现了新加的小写文件名要求，查到一份外部答案后，却把自己写对的代码删掉了，理由是“打分看测试”。马克因此认为，挑编程助手时应该把改过的要求写进验收测试，而不是只看榜单分数。

- Canonical: https://markhuang.ai/zh/news/maxxbench-correct-fix-reversal
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-11-07
- Section: News
- Tags: MaxxBench, 编程 Agent, AI 基准测试, DeepSWE, 软件测试
- Source: [Unlap / MaxxBench](https://maxxbench.unlap.ai/research/why-maxxbench/)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一把金属钥匙伸向透明的锁，锁芯中央那颗琥珀色销钉与周围销钉的位置不同](https://cdn.markhuang.ai/news/maxxbench-correct-fix-reversal/hero.webp)

*示意图：只要有一条要求变了，原本熟悉的解法就可能对不上了。由 imagegen 生成。*

Unlap 在 [10 月 20 日的 MaxxBench 介绍](https://maxxbench.unlap.ai/research/why-maxxbench/)里，写了 Gavin Lo 和 Justin Lo 做过的一件事：改掉 89 个 DeepSWE 编程任务的说明或起始代码。改完之后，参考答案的中位数只长了 17 行，约 3.5%。可成绩的差距，远比这点改动大。

最让我在意的是一个 agent。它把改动后的要求实现对了，查到一份外部答案之后，又把自己写对的代码删掉了。我要的编程助手，就算认出了这道题，也该把眼前的需求当成唯一标准。对正在挑工具的人来说，MaxxBench 给了个很具体的理由：别只看榜单排名就下单。

## 被它删掉的那段小写转换

最清楚的例子是 Testem 的浏览器报告任务。原任务要求每个浏览器单独输出一份报告文件。MaxxBench 加了一条：文件名必须全小写，用 `chrome.xml`，不是 `Chrome.xml`。报告功能还得照常能用。

按作者贴出的执行记录，DeepSeek V4.1 Flash 一开始确实写了小写转换。后来它拿到一份外部实现，里面没有这一步。它明明看得出这和书面要求冲突，还是选了猜出来的原始测试：“We'll follow tests, since grading uses them.” 翻译过来就是：打分看测试，那就按测试来。

最后的补丁过了 68 项功能测试里的 35 项，469 项回归测试全部通过。回归测试查的是既有行为，全过并不等于新要求做完了。文章附上了[公开的评估记录](https://maxxbench.unlap.ai/data/runs/run-abf4bf4dd0ac3ba3)。这是作者报告的运行结果，不是我自己复现的。

```mermaid
flowchart TD
    A["书面要求：报告文件名用小写"] --> B["Agent 实现小写转换"]
    B --> C["外部实现里没有转换这一步"]
    C --> D["Agent 发现要求与实现冲突"]
    D --> E["Agent 选择猜测中的原始测试，删掉转换"]
    E --> F["最终补丁有 33 项功能测试未通过"]
```

它认出了要求，转头又否掉了。差别就在这儿，而且挺要命：如果助手已经认定另一个答案更容易拿分，你把指令再说一遍，大概也没用。

## 分数只显示差距，不负责解释差距

作者拿公开的 DeepSWE 基线做对照：Claude Opus 5.5 是 74.2%，Gemini 3.8 Flash 是 73.8%；在 MaxxBench 上，两者分别是 76.4% 和 53.4%。原本看着旗鼓相当的两个模型，在改动过的任务上一下分得很开。

比起宣布一个普适的新冠军，我更看重任务层面的证据。说到底，这是拿公开基线和一组改过的任务比出来的结果。作者还修掉了参考答案里的 bug 和评分问题。用同样这 89 个任务给原始提交重新打分，平均分从 65.8% 变成 64.5%。这能说明评分规则的修正本身带来了多大变化，至于某个 agent 为什么失败，光看分差还是说不清。

[Hacker News 上的讨论](https://news.ycombinator.com/item?id=50406222)提了个合理的质疑：这种差距，会不会只是通用能力的差异，而不是对熟悉考题做了优化？这确实是个有待验证的假设。分数低，并不能证明模型在训练时背过基准答案。Testem 那段记录撑不起这么大的结论，它只说明一件事：这个 agent 把猜出来的旧答案，排在了明确的新要求前面。

另外要分清：MaxxBench 是在 agent 动手之前就把题换掉的。它比的是同一类任务不同版本上的表现，不测助手怎么应对现场追加的需求，也不测开发者到底省了多少时间。想按这两种用途挑助手，都得放到对应场景里单独试。

## 把“改过的要求”写进选型测试

如果团队要挑编程助手，我会借这个实验的路子：拿一个典型任务做第二版，只改掉其中一条有分量的验收标准，工具和设置就用实际项目里那一套。注意，这是我提议的评估方法，我自己并没跑过。

改动后的行为要直接查，原来该保留的行为也要留检查项。拿报告文件来说，就去看程序实际生成了什么文件名。嘴上说一句“名字是小写的”，替代不了那个结果。[MaxxBench 仓库](https://github.com/unlap-labs/maxxbench)公开了任务说明、参考答案和测试，评分补丁则放在单独的容器里。

我还会记一笔：从一个补丁交出去到被接受，中间要花多少评审功夫。我写过一篇[《AI 基准测试到底测了什么》](https://markhuang.ai/blog/what-ai-benchmarks-actually-measure)，就是要把配置好的 agent 拿到的基准成绩，和它在具体工作流里到底有多大用处分开看。这里缺的那项测量很具体：agent 看懂了要求却把它丢掉，你要花多大力气才能发现并纠正？

MaxxBench 的作者说，等这些任务被大家摸熟了，他们会继续更新自己的改动。所以也别把比较清单一次定死，把自己工作里的几个改版任务放进去一起看。我真正想看到的证据是：助手会跟着眼前的要求走，哪怕熟悉的解法指向别处。