很多开发者用Codex处理复杂Bug时，都会遇到一个很熟悉的场景。

第一次修改没有成功。

于是你告诉AI：

“继续修。”

它重新分析。

又改了一轮。

结果测试还是失败。

你再说：

“继续。”

第三轮、第四轮以后，AI开始改更多文件，重新调整前面的实现，补更多兼容逻辑，甚至开始重构一些相关代码。

最后你打开Diff，最麻烦的已经不是Bug还没修好。

而是：

你已经不知道现在这套代码，到底建立在哪一版假设上。

最开始只是一个小问题。

但连续修了几轮以后，整个任务越来越复杂。

这时候很多人会认为：

“是不是模型能力不够？”

其实不一定。

更常见的情况是：

第一次失败留下的错误状态，没有被真正清理，后面的修改一直建立在它上面。

这就是复杂Agent任务里一个很容易被忽视的问题：

错误会累积，状态也会被污染。

---

一、为什么“继续修”在简单问题里通常有效？

如果任务很简单，“继续修”当然没有问题。

比如：

一个函数报类型错误。

AI第一次改错了一行。

测试失败。

它看到错误信息以后重新调整。

第二次通常就能解决。

因为这个任务的状态很简单。

错误范围有限。

前面的错误修改也很容易被覆盖。

这种情况下，Agent的迭代实际上是在快速收敛。

但复杂项目不一样。

一个真实Bug可能涉及：

业务逻辑、缓存、数据库、异步调用、权限、历史兼容。

AI第一次提出一个错误假设以后，很可能已经据此修改了多个地方。

这时候再说一句“继续修”，它不是回到最初状态重新分析。

而是在：

已经被修改过的系统上继续工作。

这两个过程完全不同。

---

二、复杂任务真正危险的不是“失败一次”，而是失败以后留下了什么

假设你让Codex修复一个订单偶发重复提交的问题。

第一次AI判断：

问题可能来自前端重复请求。

于是它增加防重逻辑。

测试没有解决。

第二次，它发现数据库事务可能有问题，于是继续改事务处理。

还是失败。

第三次，它又怀疑消息队列重复消费，继续加入幂等逻辑。

现在回头看，代码里已经同时存在：

前端防重。

事务调整。

消息幂等。

但是最初真正Root Cause可能只是：

某个状态更新顺序错误。

这时候问题不只是“前面几个方案没成功”。

而是：

这些失败方案已经留在代码状态里。

后面的分析面对的是一个被多次修改过的系统。

于是AI越来越难区分：

哪些行为来自原始问题。

哪些行为来自之前的错误修改。

这就是为什么连续修复几轮以后，经常会出现：

问题越来越难定位。

---

三、背后的工程机制：失败会产生State Contamination

可以把Agent任务理解成一个不断变化的状态系统。

最初：

State 0：原始代码。

第一次AI判断错误，做出修改：

State 1。

测试失败以后，AI继续基于State 1做第二次判断：

State 2。

然后再继续：

State 3、State 4……

问题在于：

如果State 1本身就建立在错误假设上，那么后面的所有状态都可能带着这个偏差。

这可以叫做：

State Contamination——状态污染

也就是：

错误决策不只是失败，而是改变了后续任务所处的环境。

普通聊天答错一次，重新问就行。

但Coding Agent不同。

它答错以后可能已经：

改了文件。

改了测试。

改了配置。

改变了程序行为。

所以“继续”不是重新开始。

而是在被上一轮修改过的世界里继续。

---

四、为什么连续修复还会产生第二个问题：假设堆叠

除了代码状态被污染，还有一个更隐蔽的问题。

就是：

Hypothesis Stacking——假设堆叠。

比如第一次AI认为：

问题来自缓存。

第二次又认为：

缓存和Token刷新共同导致。

第三次又加入：

“可能还和异步时序有关。”

每一次失败以后，它并不一定彻底推翻前面的假设。

更常见的是：

在原假设上继续加新解释。

于是任务逻辑越来越复杂。

最开始：

原因A。

后来：

A+B。

再后来：

A+B+C。

最后：

为了让整个方案自洽，需要越来越多补丁。

这时候即使最终测试通过，也可能只是：

一套非常复杂的补偿机制把问题盖住了。

而不是真正找到了Root Cause。

---

五、为什么AI越强，这个问题反而可能更隐蔽？

因为强模型很擅长“把当前状态解释通”。

它会根据现有代码、测试结果和上下文，找到一个看起来合理的下一步。

于是你看到的每一步都很专业。

第一次：

改缓存，有理由。

第二次：

调事务，有理由。

第三次：

加幂等，也有理由。

问题是：

局部合理，不等于整条修复路径正确。

模型越强，越有能力为一个已经偏离的状态继续找到合理解释。

所以真正危险的不是明显胡乱修改。

而是：

AI在错误方向上持续做出看起来很合理的优化。

这也是为什么复杂Agent任务需要“重置”能力，而不是无限Retry。

---

六、为什么未来这个问题会越来越明显？

因为Codex和Agent承担的任务正在越来越长。

以前：

AI修改几行代码。

失败以后重新来一次，成本不高。

以后：

Agent可能持续几十分钟甚至更久。

期间完成：

分析、修改、测试、重新规划、多轮修复。

任务越长，内部状态越复杂。

一旦前面某一步方向错误，后面的污染范围就越大。

所以未来真正成熟的Agent Workflow不能只有：

Retry。

还需要：

Rollback、Reframe、Restart。

也就是：

什么时候继续。

什么时候撤销。

什么时候重新定义问题。

什么时候从干净状态重新开始。

---

七、可以用“连续修复深度”判断任务是否已经失控

这里可以建立一个自测指标：

连续修复深度

它不是看AI失败多少次。

而是看：

同一个任务，在没有重新建立干净状态的情况下，连续进行了多少轮修复。

例如：

第一次失败。

第二轮根据测试信息修正。

成功。

连续修复深度 = 2。

这种通常没有太大问题。

另一种情况：

失败。

继续。

再失败。

再继续。

第五轮开始重新修改第一轮代码。

第七轮又补新的兼容逻辑。

第八轮已经没人说得清当前方案。

这时候连续修复深度已经很高。

还可以观察三个信号。

第一，AI是否开始反复修改同一批文件？

第二，每一轮修复是不是新增更多假设，而不是减少假设？

第三，你是否已经无法用一句话解释“当前认为Root Cause是什么”？

如果三个信号同时出现，就不应该继续Retry。

应该重置。

---

八、什么时候应该停止“继续修”，重新开始？

第一个信号是：

Root Cause越来越模糊。

如果每轮以后原因解释更多，而不是更清晰，说明任务没有收敛。

第二个信号是：

修改范围持续扩大。

原来改2个文件，现在10个、15个。

说明Agent正在用更多变化补偿前面的失败。

第三个信号是：

测试从验证工具变成了追逐目标。

如果AI开始不断修改代码，只为了让当前测试变绿，而不是验证原始问题是否消失，需要警惕。

第四个信号是：

你已经不知道哪些修改仍然必要。

这时候最好的动作通常不是：

“继续。”

而是：

停下来。

---

九、正确做法：先把状态恢复干净，再重新建立问题模型

复杂任务失败多轮以后，可以做四步。

第一，保存当前Diff，但不要继续在上面堆修改。

把它当成：

失败实验记录。

第二，回到一个已知稳定状态。

例如原始分支或上一个可靠Commit。

这样重新获得干净的Baseline。

第三，让AI重新总结：

已经确认的事实是什么？

哪些只是猜测？

哪些方案已经被证明无效？

这一步非常重要。

要把“证据”和“假设”分开。

第四，重新制定下一轮最小实验。

不要再说：

“重新修好它。”

而是：

“只验证缓存假设，不修改其他模块。”

这样每一次尝试都能产生新证据，而不是继续污染状态。

---

十、真正高效的Debug，不是修改得快，而是假设收敛得快

很多人衡量AI Debug效率，会看：

改了多少轮。

修得多快。

但复杂问题真正应该看的，是：

假设空间有没有缩小。

比如开始时有5种可能原因。

第一轮排除2种。

第二轮确认1种。

第三轮找到Root Cause。

这才是健康的Debug过程。

相反，如果每一轮以后：

可能原因从3个变成5个，再变成8个。

即使AI一直在工作，任务实际上没有在收敛。

所以Agent Debug真正成熟的目标不是：

持续行动。

而是：

每一次行动都让未知变少。

---

十一、连续修复深度低：Plus通常已经够用

如果你的日常任务主要是：

简单Bug。

小范围功能修改。

AI第一次或第二次调整通常就能解决。

失败以后也很容易回滚。

说明任务状态比较简单。

这种情况下，Plus通常已经能覆盖大量真实开发。

你的核心需求还是：

提高单次任务效率。

---

十二、连续修复深度高，也不要先想到Pro

如果你大量任务都出现：

修5轮、8轮、10轮。

代码越来越复杂。

状态越来越乱。

第一反应不应该是：

“需要更多AI容量。”

因为更多容量可能只是让Agent在污染状态上继续跑更久。

应该先解决的是：

Baseline。

Rollback。

假设管理。

最小实验。

重新规划。

只有当你的复杂Debug Workflow已经能够稳定收敛，而且仍然每天有大量高价值长任务需要运行，AI侧能力才真正可能成为瓶颈。

---

十三、什么时候Pro才真正匹配？

更接近Pro的状态是：

你已经建立成熟的复杂任务Debug流程。

失败可以快速回滚。

假设和证据分开管理。

连续修复深度被控制。

任务不会无限Retry。

但工作里仍然持续存在：

大型Repository。

复杂故障调查。

长时间Agent执行。

大量真实工程任务。

这时候更高强度AI能力才会真正转化成生产力。

判断逻辑不是：

“AI修不出来，所以我要Pro。”

而是：

“我的Workflow已经能稳定让复杂任务收敛，现在AI侧能力才成为限制。”

---

最后：复杂Agent失败以后，最危险的一句话可能就是“继续修”

“继续”很方便。

尤其看到AI已经工作了很久，人会产生一种心理：

既然已经做到这里，再让它试一次。

但复杂Debug里，已经投入很多时间并不意味着当前路径值得继续。

真正成熟的AI Coding方式，需要知道：

什么时候继续。

什么时候回滚。

什么时候重新定义问题。

因为Agent失败最危险的地方，不只是：

这一次没修好。

而是：

它可能把一个错误假设写进代码，然后让后面所有判断都建立在这个错误状态上。

如果任务简单、连续修复深度低：

Plus通常够用。

如果复杂Workflow已经成熟，并且大量高价值Agent任务仍然需要持续运行：

Pro才开始真正匹配。

未来AI Debug真正拉开差距的，不是谁最敢让Agent一直试。

而是谁知道：

什么时候应该让AI继续，什么时候应该把它拉回一个干净的起点重新开始。

持续更新Codex、大模型开发相关技术内容。
长期使用各类代码大模型，整理了稳定的AI会员订阅渠道，有需要可自取！