Codex 修复 Codex：一个共识循环
我构建了一个代理循环 (agent loop)，它不仅仅是建议代码，还会编写代码、进行审查并合并自己的 pull request。
为了测试它，我将该循环指向了 codex CLI 的一个 fork。我让代理们尝试自行修复软件。这纯粹是一个实验。该 fork 没有用户，也没有 star。这关乎机制，而非产品。
以下是该循环的工作原理：
- 输入 (Intake)：上游的一个 bug 变成了 fork 中的一个 issue。该循环只挑选它能够完成的小型、机械性 bug。
- 解决者争论 (Solvers Argue)：多个代理提出不同的修复方案。一个解决者希望改动最小；另一个希望结构清晰；第三个则希望删除代码而不是添加代码。他们意见不一。
- 裁判仲裁 (Judge Arbitrates)：裁判阅读辩论内容。如果解决者们意见不一，裁判会将他们送回进行更多轮次的讨论。裁判还会记录拒绝某些想法的原因。
- 实现与合并 (Implement and Merge)：一旦达成共识，循环就会编写补丁、运行测试并开启一个 PR。如果测试通过，它会自动合并。
你可以在 issue #34 中看到实际运行情况。代理们就一个并发 bug 展开了辩论。在达成决定之前，他们经历了三轮仲裁。该循环生成了一个真实的修复方案和一个回归测试，而人类甚至没有输入一行代码。
PR #16 中出现了一个有趣的结果。该循环无法复现报告的 bug。它没有编造一个虚假的修复方案，而是简单地添加了一个测试来锁定该行为，然后停止了。一个懂得何时不该进行修复的循环，比一个只会盲目产生 diff 的循环更有用。
到目前为止，该循环已合并了大约 16 个 PR。它处理小型任务，如 UTF-8 处理和命令修复。它并不维护整个代码库，但它能从头到尾地解决小型、边界明确的 bug。
人类仍然制定规则并审查工作。我们仍然会检查每一个 PR。代码是自动化的，但关注点是人类的。
你可以在 GitHub 上查看整个过程。查看 issue #34 和 PR #37 来了解辩论过程。
Optional learning community: https://t.me/GyaanSetuAi