多 Agent 代码审查：协作不是多开几个模型

问题：并行输出不等于可靠协作

让多个 Reviewer 并行分析代码，确实能够扩大检视覆盖面，但也会带来重复发现、严重度漂移和缺少证据的问题。系统需要的不只是更多输出，而是一条可以追踪和复核的执行链。

项目的六阶段主线是：上下文快照、预扫描与路由、并行审查及对抗复核、调用链辅助深度检视、事实综合与完整性校验、受控输出与反馈。深度检视是可选的工作区分析路径，对抗复核用于挑战候选缺陷的成立条件。

Reviewer 按检视维度分析候选缺陷；Adversary 主动挑战缺陷成立条件；Synthesizer 负责事实验证、去重和严重度校准。三类角色不是人格设定，而是工程上的职责边界。

为了避免结果与执行者脱节，链路使用 assignment ID、sender handle、task ID 与 revision 绑定任务身份，同时对文件范围、行号、规则 ID 和置信度执行准入校验。

提示词决定单次推理的方向，门控机制决定系统允许什么结果进入最终输出。Defect Proof、零发现二次审查和 SHA-256 完整性校验，让审查结果能够被复核，而不是只依赖模型自信。

当前展示的是实习交付后的个人整理／重构版。离线测试检查角色回执、精确定位与准入规则等契约，不能据此推导真实多 Agent 端到端效果或线上缺陷检出率。

从技术笔记回到完整案例