AI 生成代码的多专家对抗性审查系统：从 5 次翻车到机械门控

[xg-gh-25]

AI 生成代码的多专家对抗性审查系统：从 5 次翻车到机械门控

AI 编程 agent 通过了所有测试，置信度 10/10，功能完全无法工作。这是我们如何解决的 —— 5 次失败、7 个专家、以及一个无法绕过的机械门控。

问题：信心 ≠ 正确性

如果你用过 AI 编程 agent，你一定见过这个模式：

Pipeline 置信度: 10/10
测试通过: 57/57
功能状态: 完全不工作

这真实发生在我们身上。我们的自治 pipeline —— 从需求到 PR 的完整生命周期 —— 产出了一个 Voice Conversation Mode 功能，在所有 9 个阶段获得完美评分。每个单元测试都是绿色的。功能完全不能用。

根因： builder agent 在 review 时共享了自己的假设。"我知道这段代码是正确的，因为是我写的" —— 和人类 self-review 的盲区完全一样。

这不是一次性事故。25 天内发生了 5 次。每次都有不同的合理化理由。每次结果都一样。

洞察：Self-Review 是结构性缺陷

当构建代码的同一个上下文也审查它时，特定类别的 bug 变得不可见：

Bug 类别	为什么 Self-Review 抓不到
集成缺口	Builder 假设接线存在，因为他"打算"这么做
状态机漏洞	Builder 追踪 happy path —— 和他编码的路径一样
部署环境不匹配	Builder 的心智模型就是开发环境
API 契约漂移	Builder 从记忆中假设被调用方行为
并发风险	Builder 顺序思考（因为顺序编写代码）

解决方案不是"更仔细地 review"。从你自己的上下文内部发现自己的假设，这在结构上就不可能。 你需要一双全新的眼睛 —— 字面意义上的全新上下文，对 builder 意图零了解。

架构：多专家对抗性审查

我们用一个 Review Army 替换了单 agent self-review —— 多个领域专家并行执行，每个都有隔离的上下文和聚焦的专业知识。

7 个专家

┌─────────────────────────────────────────────────────┐
│                  DELIVER 阶段                         │
│                                                       │
│  1. 完成度审计 (AC → 证据映射)                        │
│  2. AC 验证 (读测试，验证声明)                        │
│                                                       │
│  3. ════════ 对抗性审查门控 ════════                  │
│     ┌─────────────┐  ┌─────────────┐                │
│     │ 正确性专家   │  │  安全专家   │  ← 并行       │
│     └─────────────┘  └─────────────┘                │
│     ┌─────────────┐  ┌──────────────┐               │
│     │ 性能专家    │  │ API 契约专家 │  ← 并行       │
│     └─────────────┘  └──────────────┘               │
│     ┌─────────────┐  ┌─────────────┐                │
│     │ 集成专家    │  │  运维专家   │  ← 并行       │
│     └─────────────┘  └─────────────┘                │
│              ↓ (>200行 或 发现 HIGH)                  │
│     ┌─────────────┐                                  │
│     │  红队专家   │  ← 串行（需要前序结果）          │
│     └─────────────┘                                  │
│                                                       │
│  4. Meta-Review (部署盲区)                           │
│  5. Push-Ready 门控 (二元: yes/no)                   │
└─────────────────────────────────────────────────────┘

每个专家具有：

• 隔离上下文 —— 对 builder 推理过程零了解
• 领域专项清单 —— 聚焦的专业知识，而非稀释的注意力
• 结构化输出 —— 带有严重度、置信度、文件、行号、修复建议的 JSON

为什么多专家优于单一审查者

单一审查者同时检查 Security + Performance + Correctness + API Contract 会遭受注意力稀释。每个领域需要根本不同的思维模式：

• 安全 → 攻击者思维（我怎么入侵？）
• 性能 → 扩展思维（10 倍负载会怎样？）
• 正确性 → 逻辑思维（这符合规格吗？）
• API 契约 → 消费者思维（调用方会崩溃吗？）

并行的专家加上隔离的上下文，产出更深、更高置信度的发现 —— 因为他们不需要在思维模式之间切换。

全新上下文原则

每个 sub-agent 接收：

1. 变更集（变更的文件、diff）
2. 项目 TECH.md 陷阱（这个代码库中已验证的坑）
3. 他们的专家清单
4. 需求（这段代码应该完成什么）

他们不接收：

• Builder 的推理或意图
• 为什么做出某些设计选择
• Builder 的置信度
• 任何中间讨论

这种隔离是关键创新。当正确性专家阅读代码时，他们像陌生人一样阅读它 —— 和生产环境用户遇到功能的方式一样。Builder 的假设（如"我已经验证这个接线能工作"）不会传递。

Profile 感知的分层

不是每个变更都需要全军出动：

Profile	运行什么	理由
full	所有专家 + 红队（条件触发）	新能力 = 最高风险
bugfix	仅正确性 + 安全	窄范围
trivial	跳过	一行修复，测试通过
research/docs	跳过	无代码变更

关键覆盖： 如果 diff 超过 100 行，无论 profile 如何强制使用 full tier。一个 382 行的 "bugfix" 在对抗性审查层面不是 bugfix —— 它是一个跨模块迁移，涉及并发、import 顺序和死代码风险。

置信度门控

不是所有发现都一样重要。我们用置信度评分过滤噪音：

置信度	处理方式
7-10	显示在主要发现中，HIGH 严重度自动修复
5-6	带警告显示 "⚠️ 请验证"
3-4	抑制到附录
1-2	完全抑制

多专家确认（2+ 专家发现同一问题）置信度 +1 并标记为 "MULTI-SPECIALIST CONFIRMED" —— 这些是最高信号的发现。

红队层

红队是一个条件触发、串行执行的专家，只在以下情况触发：

• 总变更超过 200 行，或
• 任何专家产出了 HIGH 严重度发现

与其他专家不同，红队接收所有专家的合并结果 —— 它寻找他们集体遗漏的问题。它的工作是系统级对抗：不是"代码正确吗？"而是"考虑到专家已经检查的一切，这个系统在生产中可能如何失败？"

Meta-Review：Pipeline 结构性看不到的

专家通过后，一个 Meta-Review sub-agent 寻找代码审查无法捕获的部署上下文 bug：

你不是在审查代码 bug。对抗性审查者已经做了这件事。
你在审查 PIPELINE 可能遗漏的东西 —— 代码审查在结构上无法捕获的
运维、扩展和部署上下文问题。

它分析 5 个维度：

1. 部署上下文 —— daemon vs CLI vs cron 的行为差异
2. 运维扩展 —— 空操作成本、随数据量的增长
3. 跨边界格式 —— JSON 空格、编码、序列化假设
4. 首次运行 vs 稳态 —— 首次部署时积压数据的副作用
5. 架构完整性 —— 这个 fix 是否增加了净复杂度？是否在正确的层级修复？是否重新实现了系统已有的能力？（"No-Patch Gate"）

这一层存在是因为我们的 pipeline 持续捕获代码正确性问题，但遗漏环境特定 bug：PyInstaller 二进制中的 sys.executable、daemon 中未设置的 $HOME、per-session hook 中的 O(n) 扫描。

机械门控：为什么文字规则失败了

不舒服的事实：我们构建了这个系统，详细记录了文档，然后跳过了 5 次：

#	日期	合理化理由	结果
C011	4月25日	"测试通过，置信度 10/10"	功能 100% 损坏
C021	5月9日	"Validator schema 很严格，强制通过"	用户发现 bug
C025	5月15日	"我了解这段代码，很简单"	用户发现跳过了 pipeline
C026	5月19日	"追加代码，已经 review 过"	发现门控绕过路径
C029	5月20日	"压缩输出，跳过 DELIVER"	2 个 MEDIUM bug 发布

基于文本的执行（"你必须运行对抗性审查"）每一次都失败了。Agent 用听起来完美的理由合理化绕过。

修复方式：物理上无法绕过的机械门控。

# 在 artifact_cli.py validator 中
if profile in ("full", "bugfix"):
    if adversarial_review.get("profile_tier") in ("skipped", "lite", None):
        raise ValidationError(
            "Pipeline 完成被阻断：adversarial review 对于 "
            f"{profile} profile 是必须的。Tier: {adversarial_review.get('profile_tier')}"
        )

Pipeline 字面上无法完成 —— 除非有证据表明对抗性审查以正确的 tier 运行过。这不是提醒 —— 这是一个代码路径，拒绝写入 status: completed。

反合理化门控

在 deliver 阶段的顶部（在"跳过"决定发生之前），放置对质检查点：

🚨 关键: 对抗性审查不可协商

停下来。在你越过第 2 步之前确认：你会在第 3 步启动对抗性
sub-agents 吗？如果答案不是"是，正在启动" —— 你在合理化。

| 你在想什么               | 为什么这是错的                        |
|--------------------------|--------------------------------------|
| "测试通过，不需要 review" | C011: 57 测试绿色 → 100% 损坏        |
| "代码简单，我已经看过了"  | C025: "简单" → 用户发现了            |
| "我快速自己看一下就行"    | 自己看发现 0。对抗性发现 5（2 HIGH）。 |

为什么位置重要： 放在文件末尾的反合理化表格永远不会被读到。跳过的决定发生在第 ~16 行。反驳在第 ~750 行。通过将门控放在第 2 步和第 3 步之间，agent 字面上无法跳过它而不阅读它。

结果

每次对抗性审查运行，都发现了 bug：

• C011（Voice Mode）：57 测试绿色后发现 5 个 bug
• run_bc707066：2 个 MEDIUM（阈值顺序 + 13 秒阻塞调用）
• run_bd42b58f：Self-review 发现 0。对抗性发现 5（2 HIGH）。
• 多次 pipeline 运行：高置信度后捕获 12+ 关键发现

每次跳过对抗性审查，bug 都发布到了生产。

模式是明确的。对抗性审查门控是 pipeline 中最有效的质量机制 —— 比单元测试、集成测试或 self-review 的组合都更有效。

关键设计原则

1. 全新上下文不可协商 —— 审查者必须是代码的陌生人
2. 领域隔离优于通才审查 —— 每个专家发现其他人遗漏的
3. 机械门控 > 文字执行 —— 如果能被跳过，就会被跳过
4. 检查点位置很重要 —— 执行在决定之前，而非之后
5. 置信度门控减少噪音 —— 不是所有发现都相等
6. 已验证的反驳 —— 反合理化使用真实失败数据，非假设
7. 二元 push-ready —— 无数字评分（10/10 + 功能损坏证明了分数无意义）

适用性

这个模式适用于任何 AI 编程 pipeline，当：

• Builder agent 也审查自己的输出
• Pipeline 置信度与实际质量不相关
• 特定 bug 类别对 builder 结构性不可见
• 基于文本的流程要求被合理化绕过

核心洞察可以泛化：任何生产者也评判质量的系统，都会系统性地遗漏生产者假设 bug。 修复方式是结构性分离 —— 不是更好的 prompt，不是更多规则，而是物理上独立的评估上下文。

---

构建于 SwarmAI —— 一个 AI 指挥中心，一个 builder + AI 以团队规模运作。对抗性审查系统每周处理约 15 次 pipeline 运行，平均每次捕获 3.2 个所有其他质量门控遗漏的发现。

欢迎讨论： 在你的 AI 编程工作流中，你如何处理"测试通过但功能损坏"的问题？