> 你让一个 coding agent 修 Bug。它写出补丁，跑测试，测试过了。你说”再修一轮看看”。第二轮它改了点别的，测试还是过。你查最终代码，发现原本修好的 Bug 又回来了。 > > 你以为它在进步。其实它在原地打转，每转一圈还丢一点东西。
这不是假设，是 2026 年 7 月 arXiv 上一篇叫《Looping Is Not Reliability》的论文实测出来的事实。作者团队来自阿里云 + 香港科技大学（杨强），他们做了一次密封五种子、900 条三轮修订轨迹的受控实验，专门测一件事：coding agent 反复修 Bug，到底是在积累正确，还是在流失正确？
答案既反直觉又精确：反复修订下，”曾经修对过”的比率从 82.0% 涨到 85.3%，但”当前仍然正确”的比率从 82.0% 掉到 67.3%。Agent 曾经修对过，但后来又修回去了。
一、核心实验：900 条轨迹的密封研究
实验设计非常严谨。30 个 HumanEval 编程题，5 个随机种子，每题让一个 7B 的 coding agent 做三轮强制修订（forced revision），总共 900 条”三轮修订轨迹”。每一轮都让 agent 看到测试结果，让它继续改。
关键区分两个指标：
– current correctness（当前正确率）：最终这版代码是否通过测试 – ever-correct（曾经正确率）：任何一轮曾经通过测试
两个指标的差距，就是”曾经修对过但后来又修坏”的比例。
二、判决结果：正确性不是”吸收态”
RQ1：正确性不是吸收态
在强制修订下，current correctness 的轨迹是：
| 修订轮次 | current correctness | ever-correct |
|---|---|---|
| 第 1 轮 | 82.0% | 82.0% |
| 第 2 轮 | 67.3% | 84.7% |
| 第 3 轮 | 69.3% | 85.3% |
第 3 轮时，16.0% 的轨迹曾经产出过正确补丁，但随后又丢失了。用上”当前二元证据”（只告诉 agent 当前是否通过）后，流失率降到 8.0%，但仍然不是零。
这个数据直接反驳了一个默认假设：“只要 agent 修对过一次，这个正确性就会被保持”。不会。正确性在 Agent 系统里不是”吸收态”——不是一旦进入就永远留下。它是一个可逆状态，下一轮修订可以把它打回去。
RQ2：证据能帮修订，但会伤保留
第二个研究问题把”证据”（agent 看到的测试反馈）拆成三种：
– current traces：当前这版代码的测试输出 – stale traces：之前某版代码的测试输出（没更新） – unavailable evidence：不给测试输出
在 7B 模型上，current traces 修复 113/135 错误起点（83.7%），stale traces 修复 105/135（77.8%），不给证据修复 97/135（71.9%）。证据确实帮修订——但代价在另一头。
RQ3：陈旧证据让已修好的 Bug 复活
这是最狠的一刀。在 14B 模型的复制实验里，从已经修对的起点出发：
– 用 current traces：只有 4/135 把修好的 Bug 又改坏（3.0%） – 用 stale traces：34/135 把修好的 Bug 又改坏（25.2%）
差距 22.2 个百分点，95% CI [8.9, 37.0]，Holm 校正 p=0.0337——统计学显著。
陈旧证据让已修好的 Bug 复活。Agent 看着旧版测试输出，以为某个 Bug 还在，于是去”修”它，结果把已经修好的代码改回去了。
这个发现的杀伤力在于：很多生产系统的”记忆”机制就是把历史测试输出存下来给 agent 看。如果这些输出不随代码更新而更新，它们就是定时炸弹。
RQ4：验证器质量 ≠ 独立性
第四个研究问题更微妙。社区里有个共识：“验证器越强，loop 越可靠”。这篇论文说：不对。
作者用三个不同家族的验证器（Qwen 7B、Qwen 14B、DeepSeek 6.7B）做交叉验证，发现跨家族的多样性不等于验证器质量。一个强验证器在独立测试集上表现好，不等于它在 loop 里能提供独立的判断信号——它可能和 coder 模型有同源的盲点。
“验证器质量”和”验证器独立性”是两个不同的属性，不能互相替代。
三、解决方案：Evidence-Bound Typed Loop Contract
论文不只是诊断，还给了一个工程化的解决方案：StateSeal——一个”证据绑定类型化循环契约”的参考实现。五个核心设计：
1. State-bound evidence（状态绑定证据）：每条测试证据必须绑定到具体的代码状态 hash，陈旧证据自动失效 2. Typed revision actions（类型化修订动作）：修订不是”改一改”，而是有类型的动作（修测试、修实现、修接口等），不同类型有不同的准入和保留规则 3. Last-known-good checkpoint（最后已知正确检查点）：一旦产出过正确版本，自动保存为检查点，后续修订失败时可回退 4. Risk- and dependence-aware stopping（风险和依赖感知的停止规则）：不是”修到测试过就停”，而是评估”继续修的风险 vs 收益”再决定 5. Bundled admission（打包准入）：修订的准入不只看”这次测试过没过”，还看它对保留、对其他组件的影响
StateSeal 不是另一个 Agent 框架，它是一套可机械执行的契约——任何现有 coding agent 都可以接入。
四、这为什么重要：三个层面的冲击
对 Agent 评测的冲击
过去 coding agent 的评测几乎都在测”最终正确率”——SWE-bench、HumanEval 这些基准都只看最后一版代码过没过测试。这篇论文指出这个评测方式有一个致命盲区：它看不到中间过程中曾经修对又被改坏的代码。
ever-correct 85.3% vs current correctness 69.3% 的差距，就是评测盲区定律的又一次复现——测什么就优化什么，不测的就是问题藏身处。如果评测只看最终版本，agent 就会为了”最终版本过测试”牺牲中间版本的稳定性。
对 Agent 架构的冲击
更深层的是对架构的冲击。过去两年主流 coding agent（SWE-agent、OpenHands、CodeAct 等）都默认”generate-test-revise”循环是可靠的——只要循环足够多轮，agent 就会收敛到正确答案。
这篇论文说：循环本身不提供可靠性保证。循环次数增加，transition kernel（状态转移核）决定方向——它可能向上收敛，也可能向下发散。没有保留机制和停止规则的循环，和随机游走没区别。
对”颗粒度同构”原理的呼应
这篇论文和之前概念谱系里的 Heddle、CodeRescue 形成呼应：Agent 系统的优化颗粒度必须从”单次调用”升级到”轨迹”级别。
– 单次调用层面的”测试过了”不等于轨迹层面的”修对了” – 单次调用层面的”验证器强”不等于轨迹层面的”验证器独立” – 单次调用层面的”证据有用”不等于轨迹层面的”证据不害人”
优化颗粒度应该和被优化对象的颗粒度一致——这是 Agent 系统设计的普遍原则，这篇论文用 900 条轨迹把它钉死了。
五、诚实评价
论文的局限也明显：
– 30 个 HumanEval 题 是入门级编程题，生产环境的 SWE-bench 任务复杂度远高于此 – 强制修订协议（forced revision）是人工触发的，真实 agent 会自己决定何时停。论文在 5.6 节也承认这一点，并做了 prospective 540-rollout policy 的自适应实验——结果消除了 correct-start harm，但 wrong-start repair 也下降了，没通过联合准则 – Repository 实验（24 个真实 bug、4 个 coder 栈）出现了 floor effect——bug 太难，所有 agent 都修不好，看不出修订轨迹的差异 – StateSeal 是参考实现，不是生产级系统。论文没给 StateSeal 在大规模生产环境的数据
但作为一个”把整个领域的默认假设戳穿”的论文，它做到了。900 条轨迹、5 个种子、p=0.0337 的 Holm 校正显著性——这是受控实验的标杆，不是 case study。
六、一点延伸思考
这篇论文让我想起一个更广的问题：Agent 系统里”曾经达到”和”当前保持”是两个不同的属性。
人类工程师修 Bug 也会改回去了——但我们有 git，可以 diff，可以回退。Agent 系统的”记忆”机制如果只存”最新版本”，就等于一个没有 git 的工程师：改坏了也回不去。
StateSeal 的 last-known-good checkpoint 本质上就是给 agent 装了一个 git。生产级 coding agent 的最低门槛，可能不是更强的模型，而是更基本的工程卫生——状态绑定、类型化动作、检查点、停止规则。这些不是花哨的 AI 技术，是软件工程 101。
但正因为它是软件工程 101，才更值得说：Agent 时代的可靠性问题，不是 AI 问题，是工程问题。
> 论文链接：arXiv:2607.24604 > 代码：论文提及 StateSeal 参考实现，暂未在 arXiv 页面公开链接 > 一句话总结：Agent 修 Bug 越修越多——曾经修对的 16% 在第二轮又改回去了，陈旧证据让已修好的 Bug 复活率从 3.0% 飙到 25.2%。