让 Agent 多跑几轮，代码就更可靠？这篇论文说不一定

你在 PR 里看到 coding agent 改了一版、又改一版、再改一版。直觉告诉你：多修了几轮，应该更稳了吧。

一篇刚挂在 arXiv 上的论文，专门盯着这个直觉打了一枪。

标题就叫「Looping Is Not Reliability」，循环不等于可靠。三位作者 Gao、Yang、Yang 用 30 个 HumanEval 题目做了 900 条三轮修订轨迹，结果很直接：一轮修改后的正确率是 0.820，强制再改一轮之后，正确率掉到了 0.673。虽然"曾经正确过"（ever-correct）的累计比例升到 0.847，但那只是说明中间一度修对过，不代表最终交出去的版本是对的。

Agent 在 loop 里可能已经踩到了正确答案，但又自己改走了。

这种现象论文里给了个名字叫 stale traces——过时痕迹。一个修复在某一轮通过了验证，但 agent 没有把它锁定下来，继续迭代之后反而丢了正确状态。在一个预设的 14B 复制实验中，用过时轨迹（stale traces）重启的正确起点有 34/135 被损坏，而使用当前轨迹的只有 4/135，差了 22.2 个百分点，统计显著（Holm p=0.0337）。

对团队来说，后果很清楚：信任 agent 多跑几轮，结果它把已经修好的 bug 又改回去了，而开发者根本不知道。因为只看最后提交的那一版，看不到中间哪一步其实是正确的。

论文进一步做了 24 个仓库 bug 和 4 个 coder stack 的实验，暴露了两个问题。一个是 floor effect——有些 bug 本身就很难，多跑也没用；另一个是 component heterogeneity——不同模块表现差异很大，同一个策略在这个仓库好用，换一个就垮了。

作者没有停留在批评 loop，他们提出了一套「typed revision contracts」——类型化修订契约。思路是把验证器的证据绑定到精确的代码状态上：哪个版本通过了测试、证据是什么、谁签发的，全部记录下来，而不是让 agent 在黑箱里瞎绕。他们还做了一个参考实现，能保留已验证的检查点、发出可审计的验收收据。

这个实现论文自己也说了：它是一个可执行的规范，不代表能提高修 bug 的能力，也不代表验证器本身的可靠性被校准了。它只是让人知道——哪一次修改是真的可验证的，哪一次只是又绕了一圈。

对于每天都在用 Cursor、Copilot、Devin 或者自己搭 coding agent 工作流的开发者来说，这个结论不算意外，但被论文用数据钉死了。多轮 loop 不是银弹，没有 checkpoint 和证据绑定的迭代，修得越多不一定交得越好。

如果 agent 每轮都在改，但不留证据、不锁正确状态，那最后拿到的不过是它最后一次碰运气的结果。论文的参考实现已经放在 arXiv 上了，不一定直接拿来用，但它指的那个问题——所有跑 coding agent 的人都应该想一想。