lijianfei.com

在 AI 编码工具（Claude Code、Codex、Cursor、Antigravity 等）全面接管研发日常的今天，代码产出速度暴涨了十倍，但研发效能的真正堵点却顺延到了下游：代码评审（Pull Request Review）。

为了分担人类工程师的审阅负担，不少团队尝试引入 AI 进行自动代码审查。然而，早期的尝试往往迅速沦为两场灾难：要么是单个智能体“自审自查”，陷入 自证清白的严重幻觉 与虚假绿灯；要么是拉入多个智能体互审互改，演变成 “无休止的乒乓补丁战” ——A 提修改，B 反对并改回，C 又引入无端抽象，甚至连改 10 轮依然无法收敛。

近期在开源社区备受瞩目的 Code Jury（agentsdance/codejury），以一种极富创见的“英美法系法庭质辩”架构，彻底打破了这一僵局。它将多智能体分工重构为 “只看不动的陪审团（Jury）” 与 “唯一动刀的主审法官（Judge）”，并推行极其严苛的 机械证据门禁（Mechanical Gate）。

本文将深入剖析 Code Jury 的核心架构、博弈收敛机制以及在生产级复杂并发系统中的真实质辩案例。

当前的多智能体（Multi-Agent）技术生态，正经历着严重的“框架虚胖症”。

打开任意主流 Agent 开源项目，映入眼帘的往往是动辄数十层的抽象封装：各类魔改的 Node、Edge、StateGraph、AgentExecutor、回调函数与黑盒管道。当开发者尝试将官方 Demo 推向生产环境时，一旦遭遇上下文超限、工具调用幻觉、发言人死循环或 API 400 校验拒绝，便会陷入厚重的源码堆栈中茫然失措。很多工程师甚至分不清一个确定的任务到底该用 DAG 工作流，还是该用多智能体群聊。