写测试比例差 82 个点，解决率只差 2.6 个点

「让 agent 写测试来验证自己的改动」几乎是所有 coding agent 的标准配置。Rethinking the Value of Agent-Generated Tests 去量了一下这个动作到底值多少。

结论不太给面子：改变的主要是过程和成本，不是结果。

那组对照

在 SWE-bench Verified（500 个 GitHub issue）上，用 mini-SWE-agent 跑六个模型，写不写测试完全由模型自己决定：

模型	写了新测试的任务占比	解决率
Claude Opus 4.5	83.0%	74.4%
GPT-5.2	0.6%	71.8%

写测试的比例差 82.4 个点，解决率只差 2.6 个点。

然后他们做了干预实验 —— 用提示词强行改变这个行为：

逼 GPT-5.2 写测试还有一笔额外账：输出 token 涨了 19.8%，解决率没动。

最能解释这件事的是他们对反馈信号的拆解。Claude Opus 4.5 平均每个任务写 25.00 个打印语句，5.16 个断言。

打印是「让我看看这里现在是什么值」，断言是「这里必须是这个值」。五比一的比例说明这些测试的实际用途是观察，不是判定。

换句话说，agent 写的「测试」大多是一次性的调试脚手架 —— 它帮模型看清楚现场，然后被扔掉。而调试脚手架的价值不体现在「测试通过率」上，体现在模型有没有找对地方。

这解释了为什么写不写差别不大：GPT-5.2 那 0.6% 不代表它不验证，只代表它用别的方式验证（读代码、跑现有测试、直接推理）。

要非常小心，因为它量的东西和我们做的东西不是一回事。

那篇研究的是 tests-as-means —— agent 为了解决一个 issue，顺手写测试帮自己。测试是过程，交付物是那个补丁。

而「从需求生成测试用例」这类工作是 tests-as-product —— 测试本身就是交付物。用户要的就是那套测试，没有别的产物。

在 tests-as-means 里，「多写测试没提高解决率」是个合理的负面结论。在 tests-as-product 里，这个问题本身不成立 —— 你不能说「少写点测试，反正解决率不变」，因为测试就是你要交的东西。

所以这篇不能拿来论证「用 agent 生成测试没价值」。 它论证的是另一件事：agent 在解题过程中自发写的测试，不该被当成质量提升的证据。

抛开结论，这篇的做法值得抄的地方比结论多。

一、把「过程行为」和「最终结果」分开量。 他们的核心发现是「更多的 agent 写测试不等于更多解决，可靠改变的是过程足迹」。这句话的形状可以直接套到任何 harness 组件上：你加的那个组件，改的是结果还是只是过程？

我自己就吃过这个亏。我给用例生成加过一道「判据够不够具体」的形式检查，跑两轮下来开火十几次，真阳性零次 —— 拦下的全是好判据。它改变了过程（多了一堆日志、拒掉了几条用例），没改变结果（没拦住任何一条真正模糊的判据）。按这篇的框架，它就是一个纯过程足迹的组件。

二、用配对干预，而不是各跑各的。 他们的做法是同一批题、同一个模型，只改提示词里那一句，然后做 McNemar 检验。这比「A 方案跑一批、B 方案跑另一批」严谨得多 —— 题目难度的差异被相减消掉了。

三、成本要单独记账。 他们给出的建议我认为最实用：把写测试的成本单独记录，这样才看得出验证在什么时候停止增值。35.4% 的 API 调用和 49.0% 的输入 token 是实打实省下来的 —— 如果只看解决率，这笔省钱完全看不见。

四、别默认，要有预算意识。 原话是让测试变得有针对性且有预算意识，而不是默认动作。

我准备把「组件改的是结果还是过程」当成一条固定的验收问题。 每加一个 harness 组件，除了问「它有没有用」，还要问「它是改了产出，还是只改了日志的形状」。

我要把成本按组件拆开记。 现在我的预算记账只有一个全局数，答不上来「判据检查这一格花了多少」。而按这篇的做法，一个只改过程不改结果的组件，正是靠成本账才暴露的。

McNemar 那套我已经在用（配对比较那一节讲过为什么必须配对），但用的时候没意识到它同时也是「过程 vs 结果」的判别工具 —— 只看结果的检验，天然看不见那 49% 的 token。

基准是 SWE-bench Verified，任务形态很窄。 一个仓库、一个 issue、有现成的测试套件可以跑。在这种设定下「自己写测试」的边际价值本来就低 —— 因为已经有测试了。换成一个没有任何测试的新项目，结论未必成立。

「解决率」这个指标本身有局限。 SWE-bench 判定成功的方式是跑隐藏测试。一个补丁可能通过隐藏测试但引入了别的问题，也可能修得很好但被隐藏测试的边界卡住。用一个二元指标去量「写测试有没有用」，可能量不到写测试真正影响的东西（比如改动的可维护性）。

六个模型的行为差异极大，平均意义有限。 83% 和 0.6% 之间不是连续分布，是两种完全不同的策略。把它们放一起谈「多写测试没用」，可能掩盖了「对某些模型有用、对某些没用」。

这篇我没有第一手对照。 我没在 SWE-bench 上跑过，上面所有数字都是转述。我能做的是把它的实验条件说清楚，以及说清楚它和我的场景差在哪。

前三篇都默认了一件事：agent 要通过图形界面去操作产品。

最后一篇是反方 —— 有一派主张这个前提本身就错了：让 agent 去看屏幕、点坐标，是在逼它模仿人的感知局限，而它本该发挥的是程序化控制的长处。