To Run or Not to Run：AI Coding 不是多跑测试就更可靠

在很多 AI Coding 方案里，验证闭环几乎被默认等同于“让 Agent 跑测试”。

Agent 生成补丁后，执行单测，读取报错，继续修改，直到测试通过。这个流程很像人类工程师的调试过程，也很容易被当成更高自动化等级的必要路径。

但《To Run or Not to Run》给了一个有些刺耳的提醒：对当前 Coding Agent 来说，执行代码带来的收益并不总是覆盖它的成本。尤其是在自动修复任务里，完全开放执行权限和限制执行权限之间，修复成功率差距并不显著，token、时间和环境成本却差得很明显。

这个结论放到企业研发里很值得琢磨。我们一直在补验证闭环，但如果验证只是让 Agent 多跑几轮测试，可能并没有触到问题核心。Agent 能跑起来，只是第一步。更麻烦的问题是：它知不知道该跑什么，为什么要跑，跑完以后结果能说明什么。

在自动修复 bug 的任务里，让 Agent 执行代码是一个很自然的设计。

它可以先根据 issue 和源码生成补丁，再运行测试或脚本，观察报错、日志、堆栈和测试结果，然后继续修改。这就是论文里提到的 generate-run-revise 范式：生成、执行、修正。执行结果被当成反馈信号，帮助 Agent 复现问题、定位缺陷、验证候选补丁。

这个范式符合工程师的工作直觉。人写代码也不是一次写完就合入，而是边写边跑，边看错误，边修。到了 Coding Agent 这里，很多系统也自然走向类似流程：给它 shell，给它测试命令，给它日志，再让它自己闭环。

问题在于，执行并不是免费的。

一次执行会消耗时间。完整测试套件可能跑几分钟，也可能更久。一次执行也会消耗 token。Agent 要生成命令、读取输出、解析日志，大量报错和测试结果还会挤占上下文。更隐蔽的是环境成本：每个仓库、每个版本、每组依赖，都可能需要一套可运行环境。论文也特别提到，在工业部署里，为目标仓库和版本维护可用的 Docker 镜像，本身就是持续成本。

所以这里的问题不能只从“能力”角度看。

Agent 能执行，不代表每次都值得执行。每一次执行，都应该带来足够的信息增益。

这篇论文有一个比较好的实验设计：它不是泛泛比较哪个 Agent 更强，而是在同一个 Agent scaffold 下，只调整执行权限。

作者先分析了 SWE-bench leaderboard 上的 7700 多条公开 Agent traces，观察不同 Agent 和模型在真实 benchmark 任务中如何执行测试。随后又在 200 个 SWE-bench 实例上，使用 Claude Code、Codex 和开源 OpenCode，进行了约 3000 次端到端 repair attempts。执行策略被分成几类：完全禁止执行、有限次数执行、带成本提醒的执行，以及完全开放执行。

这个设计让它可以单独追问一个问题：在同样的 Agent 工作流下，执行代码这件事本身，到底贡献了多少？

结果不太符合直觉。

从公开 traces 看，代码执行非常普遍。Agent 平均每个任务执行 8.8 次测试，不同系统之间差异很大，频率大约从每个任务 2 次到 19 次不等。后期执行的成功率通常高于早期执行，说明 Agent 在理解任务后，确实会更有针对性地运行测试。

但在受控实验里，执行权限放开并没有显著提高商业 Agent 的修复成功率。论文报告称，在 Claude Code、Codex 这类商业 Agent 上，Prohibited 和 Unrestricted 的 resolve rate 平均只差约 1.25 个百分点，统计上不显著。与此同时，以 Claude Code 为例，不开放执行权限相比完全开放，可以节省 56–62% token，以及 48–54% wall-clock time。

这个结果不能简单理解成“执行没用”。更准确的说法是：执行收益并不是均匀分布在所有任务上的。它对部分任务有价值，但当前 Agent 经常无差别地执行，在很多实例上付出了成本，却没有换来足够的修复收益。

这篇论文真正有意思的地方，不只在于它算清了执行成本，还有另一个更隐蔽的问题：Agent 自己跑过的测试通过了，并不代表真实验收就通过了。

我们通常会认为，只要 Agent 能复现问题、看到报错，就更容易定位 bug。但实验里，复现执行对定位的帮助并没有想象中稳定。以 Claude Code 为例，成功案例中有 55% 使用了 reproduction execution，但只有 48.8% 的复现执行产生了 actionable feedback。很多执行结果并没有真正帮助 Agent 缩小问题范围，或者只提供了环境错误、泛泛失败、超时等低价值反馈。

更麻烦的是，很多失败案例并不是没有跑过测试。相反，它们曾经通过过 Agent 自己选择的 validation，但最终没有通过 SWE-bench 官方评测。论文把这个问题归因于 agent-chosen tests 和 ground-truth validation 之间的 gap。

这点很贴近企业研发现场。

Agent 可能不是不会跑测试，而是不知道该跑哪个测试。它可能不是不会读日志，而是不知道日志和真实验收点之间的关系。它也可能得到了“通过”的信号，但这个信号覆盖不了真正的上线风险。

所以，“测试通过”只是一个事实，还不是一个可以直接用于合入判断的结论。

它还需要回答：覆盖了哪个需求点，验证了哪个风险，还有哪些边界没有覆盖。

放到业务研发团队，这篇论文的提醒会更现实。

很多 H5、PC、小程序需求，并不是难在改哪几行代码。真正麻烦的是变更影响很散。一个看似普通的页面调整，可能同时牵涉接口字段、表单校验、跳转来源、埋点、实验开关、灰度条件和下游页面展示。

Agent 如果只跑了一个局部测试，很容易得到一个“通过”的信号。但这个信号未必覆盖真正的上线风险。

如果把验证闭环简单理解成“让 Agent 跑 E2E”，也会很快遇到问题。简单页面改动不值得完整跑链路，高风险流程又不能只靠局部测试。E2E 很重要，但 E2E 不是万能答案。它的价值取决于是否覆盖真实验收点，是否能表达业务风险，是否能帮助定位问题。

这也是为什么 SDD、PRD、验收点和测试选择要连起来。

SDD 不是为了制造文档负担。短期看，也没必要为每个页面、每个组件长期维护一份厚重 SPEC。更现实的做法，是在 AI Coding 试点 PR 里补齐三类信息：本次变更意图、影响范围、验证证据。

这三类信息连起来以后，执行测试才不是盲跑。

比如一个简单样式调整，可能只需要静态检查、截图对比或人工确认。一个列表字段展示，可能需要补充接口字段、空态、异常态和权限可见性说明。一个涉及准入、权益、配置类流程的需求，就需要明确状态流转、关键分支、回滚策略和对应测试路径。

Agent 可以执行，但它不应该在缺少任务意图和风险说明的情况下随意执行。否则，执行次数越多，只是把成本摊得更大，并不会自动提高可信度。

如果一定要给这个问题起个名字，我会叫它“验证治理”。

它要管的不是 Agent 有没有 shell 权限，而是每次执行之前、执行之中、执行之后，是否能形成可解释的工程证据。

先是跑什么。

文案、样式、配置展示、字段透出，不一定需要完整 E2E。涉及金额、权益、权限、准入、状态流转、跨端兼容的需求，只跑局部测试又明显不够。不同需求类型，应该对应不同验证策略。

然后是跑几次。

Agent 不能因为一次报错就无限修改，也不能在没有说明收益的情况下反复跑全量测试。对低风险任务，可以限制执行次数；对中等任务，可以先跑局部验证；对高风险任务，再开放更完整的构建、单测和 E2E。

最后是跑完以后怎么解释。

测试通过以后，Agent 需要说明这次验证覆盖了哪些验收点，还有哪些风险没有覆盖。如果只输出“测试已通过”，对 Reviewer 的帮助很有限。Reviewer 真正需要的是：这个通过结果是否足以支撑合入。

这也是我觉得这篇论文对企业研发 AI 自动化最有价值的地方。

它没有否定执行，也没有否定测试。它只是提醒我们，执行能力不能被当成免费的默认能力。Agent 每跑一次测试，都应该说清楚它在验证什么。

这篇论文不应该被误读成“测试不重要”。它研究的是 SWE-bench 风格的仓库级 program repair，结论也有边界。对于性能优化、安全漏洞、复杂动态行为、端到端业务流程，执行仍然可能非常关键。

但它确实提醒我们：让 Agent 有能力跑测试，不等于拥有可靠的验证闭环。

在企业研发场景里，验证闭环不能靠工具权限堆出来。它需要任务意图、影响范围、测试选择、执行预算和结果解释一起工作。

Agent 可以跑测试，但每次执行都应该回答一个工程问题：

这次执行，到底帮我们确认了什么？

如果回答不了这个问题，测试跑得再多，也只是更多日志。对 AI Coding 来说，下一步要补的也不只是更强的执行工具，还包括更清楚的验证策略、更可解释的证据链，以及更适合企业研发流程的门禁设计。