AI编程的可靠性并不取决于多跑测试

先给出核心判断：在众多AI Coding方案中，验证闭环几乎被默认等同于“让Agent运行测试”。但实际情况远比这复杂得多。

Agent生成补丁后，执行单元测试，读取报错信息，持续修改直至测试通过。这一流程看上去与人类工程师的调试方式高度相似，也容易被当作实现更高自动化等级的必要路径。

然而，论文《To Run or Not to Run》提出了一些不太乐观的结论：对于当前的Coding Agent而言，执行代码带来的收益往往难以覆盖其成本。尤其在自动修复任务中，是否完全开放执行权限，修复成功率的差异并不显著，而Token消耗、时间开销和环境成本却相差悬殊。

这个结论放到企业研发环境中，确实值得深思。大家都在强调补全验证闭环，但如果所谓的验证仅仅是让Agent多跑几轮测试，恐怕还未触及问题的本质。Agent能运行只是第一步。真正棘手的问题是：它是否知道该运行什么、为什么要运行，以及运行结果能说明什么。

generate-run-revise 范式为何成为默认选择

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

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

这一范式完全符合工程师的工作直觉。人在写代码时也不是一次性写完就提交，而是边写边运行、边看错误边修改。到了Coding Agent这里，许多系统便顺理成章地走向类似流程：赋予Shell权限、提供测试命令与日志，让它自己形成闭环。

问题在于，执行并非没有代价。

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

因此，这里的问题不能只从“能力”角度去考量。

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

这篇论文真正测试的是什么

这篇论文的实验设计颇具巧思：它不是笼统地比较哪个Agent更强，而是在同一个Agent框架下，仅调整执行权限。

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

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

结果出乎意料。

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

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

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

测试通过，为何仍可能失败

这篇论文真正值得关注的不仅是算清了执行成本，还有一个更隐蔽的问题：Agent自己跑过的测试通过了，并不代表真实验收就通过了。

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

更棘手的是，许多失败案例并非没有跑过测试。相反，它们曾经通过了Agent自己选择的验证，但最终没有通过SWE-bench官方评测。论文将此归因于Agent所选测试与真实验证之间的差距。

这一点非常贴近企业研发的实际场景。

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

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

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

企业研发中的验证闭环，不能等同于无限执行

将这个结论放到业务研发团队中，论文的提醒会更加现实。

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

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

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

这也正是SDD、PRD、验收点和测试选择需要串联起来的原因。

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

这三类信息连贯起来之后，执行测试才不会变成盲目运行。

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

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

验证闭环中至少要管控三件事

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

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

首先是跑什么。

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

然后是跑几次。

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

最后是跑完以后如何解释。

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

这也是我认为这篇论文对企业研发AI自动化最具启示意义的部分。

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

每次执行，都要回答一个工程问题

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

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

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

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

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

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