AI 编程代理的审查循环为什么不收敛？Convergo 给出了答案

Wed, 08 Jul 2026 10:00:00 +0800

如果你最近在用 AI 编程代理做稍微复杂一点的工作，你大概经历过这样一个场景：你让 AI 审查另一个 AI 写的代码。第一个审查者发现了三个问题。你让 AI 修复，然后让同一个审查者再看一遍，通过了。但你不放心，又找了一个新的审查者看，结果它发现了三个完全不同的问题。

你深吸一口气，修复，再来。第五轮的时候，代码没变好多少，但 docs/impl-notes.md 已经长到了 500 行。

这就是 AI 编程代理的审查循环问题。它不是 AI 不够聪明，而是审查循环本身有结构性缺陷：每一轮都在发散，而不是收敛。

审查循环为什么发散？

先定义一下概念。当我说「审查循环」，我指的是这样一个流程：

这个流程看起来没毛病。但实际上，它经常不收敛，而且失败的方式很隐蔽：

问题一：审查者只看到症状，看不到根因。 一个缺失的不变量在八个不同的地方产生了影响，审查者可能把这些当成八个独立的问题，一个接一个地发现，一轮接一轮地修复。本该一次修补计划就能解决的事，变成了八轮局部打补丁。

问题二：写代码的 AI 在修补丁，而不是修结构。 当审查者说「这里有个 bug」，写代码的 AI 倾向于在出问题的地方打个补丁。但如果这个 bug 的根源是一个不完整的设计决策，贴补丁只会让代码库越来越复杂，而问题依然存在。

问题三：每一轮都在增加内容，而不是减少不确定性。 审查发现一个问题，写代码的 AI 加一段文字解释。下一轮发现另一个问题，再加一段文字。经过几轮之后，artifacts 越来越长，越来越模糊，伪代码越来越多，这些伪代码又成为新一类审查发现的来源。这是一个正向反馈循环，方向是错的。

问题四：同一审查者的「通过」不可信。 同一个 AI 审查者在看完第六轮修改后说「通过」，可能是因为它已经适应了代码的风格，或者它已经「累了」。它的通过不是真正的无疵，而是认知惯性的产物。

这四个问题叠加起来，就形成了一个典型的发散螺旋：越改越大，越改越模糊，越改越不确定什么时候算「改好了」。

Convergo 是 Miles 在七月初发布的一个开源插件，同时支持 Claude Code 和 Codex。它源自 Compound Engineering 的设计理念，但加了一个关键的改进：边界。Convergo 的目标不是让审查更彻底，而是让审查循环必然终止。