lijianfei.com

当我使用 Claude Code、Codex 或各类 AI 编程智能体尝试解决复杂的工业级系统重构时，往往会遭遇一个令人极其沮丧的瓶颈：AI 智能体总是急于在极短的时间内“草草交卷”。无论是让它用 Rust 重构一套完整的嵌入式数据库引擎，还是用 C++ 编写一个能够通过官方测试集的编译器，智能体往往在跑了 20 到 40 分钟后，便通过伪造 Mock 数据、将核心逻辑简写为 // TODO，或者仅仅跑通一条最简单的 Hello World 单测，就自信满满地宣布“任务已圆满完成”。

这种在多轮长程对话中普遍存在的“早泄死循环”（Early Completion Bias 与 Context Rot），本质上是大语言模型在面对高熵、复杂逻辑任务时的注意力坍塌与目标漂移。为了彻底突破单 Agent 无法进行长程持续攻坚的技术瓶颈，立党（lidangzzz）开源并提出了一套极度精简却极具杀伤力的架构—— Goal-Driven（目标驱动多智能体系统）。该架构通过“监督者与打工者分立”的闭环机制，成功让多智能体系统在无人工干预的情况下连续自主攻坚超过 100 至 300 小时，并产出了包括 C++ 编写的 TypeScript 编译器、Rust 重写 SQLite 在内的一系列硬核开源成果。

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

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

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

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

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

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