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

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

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

审查循环为什么发散？#

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

  1. AI Agent A 写了一些代码
  2. AI Agent B 审查这些代码，给出修改建议
  3. AI Agent A 根据建议修改
  4. AI Agent B 重新审查
  5. 重复 2-4，直到 B 说「没问题」

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

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

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

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

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

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

Convergo 的三条核心规则#

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

它通过三条规则做到这一点。

规则一：新鲜的审查者决定出口#

这是最关键的一条规则。同一个审查者说「通过」不算数。循环退出只有一个条件：一个全新的、从来没有看过这份代码的审查者，完成一次完整审查，并且报告零阻挡项。

为什么这么重要？因为新鲜的眼睛没有适应过程。上一个审查者可能在第三轮已经适应了代码里的某个奇怪写法，不再觉得它是问题。但一个新的审查者会直接指出来。

在 Convergo 的实现中，这个「新鲜审查者」是一个全新生成的 Agent 会话。它读 plan、读 diff、读 impl notes（实现笔记），但没有任何前几轮的上下文。它的判断是独立的。

如果三轮之内没有新鲜审查者给出干净通过，循环终止，所有未解决的发现直接升级给人。这是一个硬性的上限，不是建议。

规则二：反馈先分类，再修复#

当一个审查发现被传递给写代码的 Agent 时，Convergo 要求它先做一件事：分类。这个发现是哪种类型？

  • 代码 bug：Agent 自己引入的，应该修复。
  • 计划缺口：计划本身遗漏了某个 surface 或 invariant，应该回头修计划，而不是在代码里打补丁。
  • 契约缺口：行为边界没有定义清楚，应该先做决策，再写代码。
  • 系统性设计缺口：多个地方都有类似问题，需要结构化修复，不是局部操作。
  • 过期发现：代码已经改了，这个发现不再适用。
  • 阻塞于缺失决策：需要一个人类来决定某件事，Agent 不应该自己编答案。

这个分类步骤看起来很小，但它是整个系统收敛的关键。它阻止了写代码的 Agent 在遇到计划缺口时「将就一下」，用补丁掩盖设计缺陷。它会停下来，把问题抛回给该处理它的人，而不是在错误的方向上继续前进。

规则三：审查发现必须结构化#

Convergo 的审查者输出的不是自然语言意见，而是结构化的 JSON：每条发现都有严重级别（P0-P3）、置信度锚点、以及关键发现必须有引用代码行作为证据。低置信度的发现会被自动丢弃，除非它是关键性的。P3 级别的风格建议根本不会被输出，因为风格属于工具链的职责，不属于审查循环。

这杜绝了一种常见的反模式：审查者输出一大堆「感觉不太好」「这里可以优化」「考虑一下用另一种写法」。这些模糊意见在下一轮会变成模糊的修改，然后是更多的模糊意见，循环永远兜圈子。

混合循环：Fable 负责品味，Codex 负责执行#

Convergo 有一个特别巧妙的设计叫「混合循环」（Hybrid Loops），目前只在 Claude Code 上可用。它的核心思路是：不同的模型在审查循环中扮演不同的角色，发挥各自的优势。

角色引擎原因
规划者Claude Fable方向设定是品味最高杠杆的地方
计划审查者Codex (gpt-5.5 xhigh)完整性检查是执行工作，跨模型审查还能发现自审查的盲区
代码编写者Codex (gpt-5.5 xhigh)所有迭代消耗都落在这里
代码审查者（第一轮）Codex (gpt-5.5 xhigh)同上
最终出口审查者Claude Fable这决定了是否交付

这里有一个精妙的分工：Codex 的审查者说「通过」并不意味着出口，而是晋升。它触发一个 Fable 审查，只有 Fable 说通过才算真正通过。如果 Fable 发现了阻挡项，代码重新进入修复循环，下一轮从 Codex 审查重新开始。

在实践中，Fable 通常每个循环只运行一到两次，刚好在便宜引擎认为工作完成的时候。这既控制了成本（Fable 的配额稀缺），又保证了质量（最终判断由最强的判断力做出）。

同时，Codex 的审查者每次都是全新的会话，Fable 的出口审查也是全新的。没有记忆，没有惯性，只有当前的 plan、diff 和代码库。

什么时候该用 Convergo？什么时候不该用？#

Convergo 不是万能药。它的 README 里坦诚地列出了适用和不适用场景。

适合用的场景：

  • 正确性关键的工作，比如 API 设计、认证逻辑、数据处理管线
  • 需要多轮审查的复杂变更
  • 你关心代码质量的长期可维护性
  • 团队中 AI Agent 在互相审查对方的工作

不适合用的场景：

  • 快速原型和 spike（浪费审查时间）
  • 一次性脚本和实验
  • 快速 UI 迭代（视觉反馈比代码审查快得多）
  • 「随便搞搞」的小改动

还有一个重要的经济考量：一个完整的 build-loop 大约消耗 10 倍于「直接让 AI 写」的 token。这是独立审查的代价，也是为什么 Convergo 把循环上限设为三轮，不是因为它认为三轮之后代码就完美了，而是因为它认为三轮之后，剩下的边际收益不值得继续消耗 token。

几个让我印象深刻的设计细节#

读完 Convergo 的 README 和技能定义后，有几个设计选择让我停下来想了一会儿。

第一，审查的临时文件放在 /tmp 而不是 repo 里。 这听起来是小事，但实际上很关键。如果审查记录留在 repo 里，下一轮的新鲜审查者可能会读到前几轮的发现，那它就不再是「新鲜」的了。Convergo 把每轮的 review.json 放在 /tmp/convergo/ 下，用完即弃。

第二，实现笔记（impl notes）是一个故意的例外。 写代码的 Agent 会把它的决定、偏离、假设记录在 impl notes 里，和 diff 一起交给审查者。但这些笔记只包含决策，不包含审查溯源，没有轮次编号，没有发现 ID，没有修复状态。这样新鲜审查者能继承决策记录，但不会被前一个审查者的「搜索地图」影响。

第三，单 repo 循环，多 repo 拆分。 Convergo 的一次 build-loop 只覆盖一个 repo。如果计划涉及多个 repo，orchestrator 会在开始时就声明 repo 拆分，每个 repo 独立运行一个循环，任何未覆盖的 repo 都会被标记为阻挡性已知缺口。永远不会出现「单 repo 通过即计划完成」的情况。

收敛是一种纪律，不是一个特性#

写这篇文章的时候我一直在想一个问题：为什么 AI 编程代理的审查循环天然倾向于发散？

答案可能藏在人类审查的工作方式里。一个有经验的工程师审查代码时，他看到的不是一个孤立的 diff，而是一个心智模型：他理解代码库的结构，理解设计决策的背景，理解哪些是局部问题，哪些是系统性缺口。当他看到一个 bug，他不只会指出这行代码的问题，他会追溯到这个 bug 的根源。

AI 审查者暂时做不到这一点。它不是不理解代码，而是不理解变化的意义。所以它会一个症状一个症状地发现，一轮一轮地反馈，把发散当成深入。

Convergo 的价值在于，它没有试图让 AI 变得更像人类审查者。它承认了 AI 的局限性，然后通过结构化的规则，把审查循环的边界牢牢框住：三轮回合、新鲜出口、先分类再修复。收敛不是自然涌现的，是被设计出来的。

这让我想起 Kernighan 的名言：「调试的难度是写代码的两倍。因此，如果你在写代码时尽可能聪明，那你将无法调试它。」换到 AI Agent 的时代，也许可以改成：「让审查循环收敛的难度是写代码的两倍。因此，如果你不设计收敛机制，你的 Agent 将永远在兜圈子。」

参考来源：