我为 Claude Code、Codex 和 Gemini 构建了一个本地 CLI，利用现有的认证机制来互相审查彼此的 GitHub PR

我一直在尝试联合使用多个编码智能体（coding agents），但始终面临一个令人头疼的采用障碍：仅为了让一个智能体审查另一个智能体的 PR，就需要处理 API 密钥、CI 密钥以及额外的按 Token 计费。因此，我构建了一个名为 `coding-review-agent-loop` 的开源本地 CLI 工具。它会调用已在本地完成身份验证的 CLI 工具（如 Claude Code、Codex CLI、Gemini CLI 和 `gh`），从而复用你现有的授权和订阅，而无需配置单独的大模型 API 密钥。 示例： ```bash $ agent-loop task "Fix the flaky auth test" \ --repo OWNER/REPO \ --coder codex \ --reviewer claude \ --reviewer gemini ``` 该循环的大致流程如下： 1. 编码智能体（Coder agent）创建或更新一个 GitHub PR。 2. 审查智能体（Reviewer agents）对该 PR 进行审查。 3. 如果审查者发现阻塞性问题，编码智能体会进行修复。 4. 循环重复执行，直到所有审查者均通过。 5. 可选的后续操作可以被总结、提交为 Issue，或返回同一 PR 中进行修复。 这并非旨在取代人类的架构判断。其主要价值在于为代码实现审查提供低成本的本地自动化：包括遗漏的测试、回归问题、代码清理、明显的 Bug，以及强制第二个模型对第一个模型的代码进行批判性审查。 我目前最感兴趣的是“本地优先智能体工作流”这一方向：直接使用人们已经付费使用的 CLI 工具，而无需设置另一套 API/计费通道。 我也在这个仓库本身上进行了“内部测试”（dogfooding）：最近的大部分 Issue 和 PR 都是通过该循环创建、审查或迭代完成的。我还在其他一些个人项目中使用了相同的工作流，这也是许多关于后续处理、脏工作树以及 Gemini 输出处理的边缘情况被发现并得到解决的原因。 我希望听到正在使用 Claude Code / Codex / Gemini CLI 的用户的反馈： - 对于小型 PR，你会信任智能体之间的互审吗？ - 哪些审查模式对你有用？安全审查、架构审查、测试审查？ - 复用本地 CLI 授权对你来说重要吗？还是你更倾向于基于 CI/API 的智能体？