多智能体代码审查工作流：两名审查者，一名最终编写者
我使用多个 AI 编码会话时，总会遇到同一个限制。根据我的经验，并行会话能够发现不同的代码路径，但它们之间的分歧会被困在各自独立的线程中。我成了消息总线：把一份审查结果复制到另一个会话，再判断哪个模型真正理解了这个文件。
更好的设计是采用一个由三个不同角色组成的多智能体代码审查工作流。两个 AI 会话独立检查同一文件版本。它们交换发现，并相互质疑对方的证据。第三个会话接收决策记录，编写一个补丁并运行检查。
在审查期间，将文件视为共享且不可变的输入。审查达成一致后，再授予一个会话写入权限。
这不同于我目前使用的混合 AI 代码审查循环→：一个模型编写代码，第二个模型审查每次修复。那个循环已经为审查者提供了有用的独立性。下一步实验会延后写入：前两个会话先进行审查，第三个会话只有在它们的分歧形成决策记录后才开始编码。
这种模式已经接近当前智能体工具所支持的能力。OpenAI 的 Codex 子智能体文档建议使用并行智能体进行以读取为主的探索、测试、分流和审查，同时警告并行的高写入工作流会产生冲突和协调开销。缺少的部分，是位于审查者与编写者之间的一等讨论和综合层。
为什么多智能体代码审查工作流需要一名编写者？
并行分析可以提供不同的故障假设，而不会产生多个相互竞争的补丁。
一名审查者可以追踪行为和不变量。另一名可以寻找安全问题、竞态条件、缺失测试或 API 契约破坏。它们从同一个提交 SHA 和任务开始，但会收到不同的审查简报。这种分离降低了两个会话都沿着同一个最初想法推进的可能性。
Anthropic 在构建高效智能体中描述了一种相关的生产模式：多个模型调用可以从不同角度审查代码，而编排者—工作者工作流则负责分派工作并综合结果。Anthropic 还建议团队只在能够改善可测量结果时增加智能体复杂性。三个会话比一个会话消耗更多 token 和时间，因此工作流必须有存在的理由。
并发修改很少是这个理由。如果两个智能体编辑同一个工作副本，系统就必须解决过时上下文、重叠代码块以及部分应用的假设。Git 已经提供了更安全的原语：链接工作树允许不同会话使用隔离的 `HEAD` 和索引状态，同时共享相同的仓库历史。
审查者可以使用工作树进行实验，但只有集成者应该拥有候选补丁。
每个 AI 会话负责什么？
| 会话 | 访问权限 | 必须输出 | 不得执行 |
|---|---|---|---|
| --- | --- | --- | --- |
| 审查者 A | 只读快照 | 行为风险、被破坏的不变量、行号引用、建议测试 | 编辑最终分支 |
| 审查者 B | 只读快照 | 安全性、并发性、边界情况、反例 | 在没有证据的情况下照搬审查者 A 的结论 |
| 集成者 | 独占写入权限 | 已接受的补丁、附理由的被拒发现、测试结果、最终差异 | 超出约定范围进行重写 |
第三个智能体并不会自动变得更聪明。它的优势来自所有权。它接收有边界的证据，明确处理冲突，并生成一个可审计的差异。
我还会让审查者在第一次审查时彼此保持盲审。一项关于多智能体辩论的受控研究发现，多数压力可能会压制独立纠正。过早的交叉交流可能把两个审查者变成一个重复的观点。应先获得独立发现；双方提交初始证据后再开始讨论。
审查者应该如何讨论一个文件？
自由形式的聊天对人类很有用，但编码工作流需要一份紧凑的发现台账。每个主张都应携带足够的证据，使集成者无需重放私有思维链即可验证它。
{ "id": "F-03", "revision": "8a31f2c", "file": "src/auth/session.ts", "lines": "84-103", "claim": "A refresh failure can leave the previous session active", "evidence": "The error branch returns before clearSession()", "risk": "stale authorization state", "proposed_test": "refresh 401 clears the active session", "confidence": "high", "status": "disputed" }
第二名审查者可以接受该发现，也可以用可达代码论证反驳它，或缩小其范围。台账会保留双方立场。达成一致本身并不能证明正确性，一段自信的文字也不应胜过一个可复现的测试。
智能体协议正在朝这个方向发展。Google 的 Agent2Agent 协议通过任务、消息、状态和工件来建模协作。本地编码系统不需要完整协议，也可以借用其中的契约：使用类型化消息、稳定 ID、明确状态和持久化工件，而不是无结构的聊天记录。
我的 AI 同行审查桥接器→已经会为第二个模型打包差异、重点问题和结构化结论。三会话工作流需要下一层：两份审查包可以在编写者接收它们之前引用、质疑并解决相同的发现 ID。
编写者在编辑前必须收到什么？
集成者不应接收两段冗长的聊天历史。它需要一个小型交接包：
随后，编写者会重新读取当前文件，并将其版本与交接内容进行比较。版本不匹配就停止写入。这项检查可以防止对昨天文件的有效审查，最终变成针对今天代码的损坏补丁。
这也是权限应当变得确定的地方。我曾主张采用确定性的 AI 智能体权限→，因为“只能编辑这个文件”这样的提示词，不如一项让其他路径全部只读的工具策略可靠。在这个工作流中，权限模型应强制执行角色分工：审查者不能写入，集成者未经新决策也不能扩大范围。
讨论会改善软件补丁吗？
证据支持这一方向，但并不能证明每个团队都应该严格使用两名审查者和一名编写者。
通过多智能体辩论改善语言模型的事实性与推理能力表明，多个模型实例可以在多轮中提出、批评和完善答案，从而改善论文所测试的推理和事实性任务。这些实验没有测试 Git 冲突或生产环境中的拉取请求。
一个更接近编码的例子出现在 2025 年的预印本 SWE-Debate中。其智能体会围绕相互竞争的故障定位轨迹展开辩论，整合修复计划，再将计划交给独立的补丁生成智能体。论文报告称，在 SWE-bench Verified 上，500 个任务中解决了 207 个，即 41.4%；而其列出的最强基线为 38.8%。该基准和架构与我提出的工作流不同，但这种分离很有启发性：先进行多样化分析，再进入单一修改阶段。
诚实的下一步，是在真实拉取请求上进行小规模受控评估。针对 10 到 20 个缺陷，将单一编码智能体与三会话工作流进行比较。衡量有效发现、误报、合并冲突、达到可接受补丁所需的时间，以及初稿之后发现的回归问题。更多智能体消息不是成功指标。
编写者如何生成一个可审计的补丁？
集成者应遵循一个狭窄的循环：
最后一次审查应检查补丁，而不是重新开始设计辩论。每名审查者回答两个问题：编写者是否实现了已接受的决策？补丁是否引入了新的风险？
OpenAI 当前的 Codex 应用已经使用独立线程和工作树，使智能体能够并行运行而不触碰同一本地 Git 状态，并允许开发者检查和评论每个差异。Codex 应用公告表明，隔离层已经存在。共享的发现台账和明确的集成者角色，可以将并行任务转变为协调一致的审查室。
还会有哪些失败？
一名编写者可以消除编辑竞态，但无法消除模型错误。
两名审查者可能共享同一个盲点，尤其是在使用相同模型、提示词和上下文时。集成者可能选择更有说服力的论点，而不是正确的论点。仓库注释可能包含不可信的指令。测试套件通过，也可能遗漏用户所依赖的行为。
工作流需要以下防护措施：
我在21.54 billion code-agent activity tokens→之后得出的早期结论仍然适用：模型周围的系统决定了更多智能最终会变成有用的工作，还是更快的清理工作。
什么时候值得使用三会话工作流？
当错误补丁代价高昂，或代码存在不止一种合理解释时，可以使用它：身份验证、权限、支付、迁移、并发、公共 API 和事故修复。对于通常会请两名专家分别审查不同风险领域的高级工程师来说，它也可能很有帮助。
格式调整、生成文件、简单重命名以及拥有明显测试预言机的修改，则可以跳过它。Anthropic 的多智能体团队发现，协调复杂性会快速增长，而其生产研究系统依赖清晰的任务分派，以及负责综合专业结果的主智能体。编码也需要同样的纪律，只是对含糊写入的容忍度更低。
我希望编码智能体在其中一个获得光标之前，先围绕证据展开辩论。两个会话应检查同一个文件，公开表达分歧，并留下一个决策记录。第三个会话应编写候选补丁，并根据仓库证明它的正确性。
候选补丁仍然需要测试、差异审查和人工发布决策。三个 AI 会话可以改善通往补丁的路径，但它们不会让补丁自动成为真理。
常见问题
两个 AI 智能体可以同时编辑同一个文件吗？
可以，但共享写入会造成上下文过时和编辑冲突。让两个智能体以只读模式分析同一版本，或在独立工作树中隔离实验，然后为最终分支提供一个拥有独占写入权限的集成者。
两名审查者应该使用相同的模型吗？
可以，但不同的提示词、角色或模型系列能够减少相关盲点。多样性并不能保证正确性，因此工作流仍然需要证据和测试。
审查者意见不一致时会发生什么？
在发现台账中记录双方立场。集成者应重现该主张、运行建议测试，或将问题标记为未解决并交给人工处理。多数投票是对可验证证据的薄弱替代。
第三个 AI 会话会取代人工代码审查吗？
不会。第三个会话负责综合和编写候选补丁。人类仍然需要判断补丁是否符合更广泛的系统、产品意图和发布风险。
这个工作流能处理跨多个文件的修改吗？
可以。将每个已审查文件固定到同一个仓库版本，分配清晰的所有权，并保留一个集成分支。审查者可以在隔离的工作树中工作，而集成者仍然是唯一负责组装最终补丁的会话。