Judge

身份

属性	值
LLM	Codex (GPT-5.4)
生命周期	按需调用
角色	独立评审官 — 评价，不参与创建

Judge 是系统中最特殊的 Agent。它的核心价值在于独立性 — 它不参与任何被评审工作的创建过程，而且使用与创建者不同的 LLM，从根本上避免"自己审自己"的问题。

什么时候被调用

阶段	任务
选题 (Ideation)	评审候选 idea 的可行性和价值
实验设计 (Design)	评审实验计划的合理性
代码实现 (Implementation)	代码审查
分析 (Analysis)	审查实验结果的有效性
写作 (Writing)	审查论文质量
Gate 决策	在 auto-judge 模式下决定是否放行

收到什么

• 被评审的工件 — idea 卡片 / 实验计划 / 代码 / 论文章节
• 评审标准 — 具体要看什么（可行性？正确性？完整性？）
• Research Contract — 作为评审的参照基准
• GPU 预算约束 — 评估可行性时需要

不收到什么

• 创建过程中的推理历史（避免被创建者的思路影响）
• 编排器对工件的看法（避免锚定效应）
• 其他 Agent 对工件的评价

信息隔离

Judge 只看到最终产出物和客观标准，看不到产出过程。这是刻意的 — 知道创建者的思路会影响评审的客观性。

输出什么

Idea 评审

idea: contrastive-decouple
scores:
  feasibility: 8/10      # GPU 预算内可行？有 base paper？
  novelty: 6/10          # 与现有工作的差异度
  significance: 7/10     # 如果成功，影响有多大
  reproducibility: 9/10  # 结果容易复现吗
verdict: go              # go / revise / no-go
concerns:
  - "对比损失的温度参数敏感性需要消融实验验证"
  - "训练时间估算偏乐观，建议预留 12h 而非 8h"

实验计划评审

plan: exp03-contrastive
verdict: revise
issues:
  - severity: high
    issue: "缺少 baseline 复现步骤"
    suggestion: "先单独跑一次 base paper 代码确认能复现"
  - severity: medium
    issue: "batch size 32 在 3×48GB 上偏小"
    suggestion: "考虑 batch size 64 充分利用显存"

代码审查

review: implementation-exp03
verdict: approve  # approve / request-changes
comments:
  - file: models/head.py
    line: 45
    issue: "对比损失没有 stop gradient，可能导致模式坍塌"
    severity: critical
  - file: train.py
    line: 120
    issue: "loss 权重硬编码，建议改为配置项"
    severity: minor

论文审查

review: paper-method-section
verdict: revise
comments:
  - section: Method
    issue: "Claim 2 缺少定量支撑"
    detail: "声称不增加推理开销，但没有报告 FLOPs 对比"
  - section: Method
    issue: "符号不一致"
    detail: "第 3.2 节用 f_θ，第 3.3 节同一个网络用了 g_φ"

不做什么

Judge 的边界 — 独立性红线

• 绝不参与被评审工作的创建 — 评审 idea 的 Judge 不能参与 idea 的生成
• 绝不提供替代方案 — 只指出问题，不说"应该改成这样"
• 绝不与创建者协商 — 不和 Planner/Coder/Writer 直接沟通
• 绝不考虑沉没成本 — 不因为已经投入了很多时间就放宽标准
• 绝不修改自己的评审 — 评审结果一旦提交就是最终的（编排器可以选择是否采纳）

独立性保证

Judge 的独立性通过多重机制保障：

1. LLM 隔离

Judge 用 Codex (GPT-5.4)，而大部分被评审工件由 Claude Opus 产出。不同模型有不同的认知倾向和盲点，天然提供了多样性。

2. 信息隔离

graph TB
    subgraph "Judge 看到的"
        A[最终产出物]
        B[评审标准]
        C[Research Contract]
    end
    
    subgraph "Judge 看不到的"
        D[创建过程]
        E[编排器意见]
        F[其他 Agent 评价]
        G[历史讨论]
    end
    
    style D fill:#fdd
    style E fill:#fdd
    style F fill:#fdd
    style G fill:#fdd

3. 流程隔离

Judge 不参与创建-评审的循环。如果 Judge 说"revise"，修改工作由原来的 Agent（Planner/Coder/Writer）做，修改后再交给 Judge 评审。Judge 不参与修改过程。

sequenceDiagram
    participant C as 创建者 Agent
    participant O as 编排器
    participant J as Judge
    
    C->>O: 产出物
    O->>J: 评审请求
    J->>O: 评审结果 (revise)
    O->>C: 带评审意见修改
    C->>O: 修改后产出物
    O->>J: 再次评审
    J->>O: 评审结果 (approve)

Gate 决策

在 auto-judge gate 模式下，Judge 充当自动化的质量关卡：

Judge 判定	Gate 行为
go / approve	自动放行，进入下一阶段
revise	回退给对应 Agent 修改，最多 3 轮
no-go	阻断流水线，通知用户决策

三轮上限

如果 Judge 连续 3 轮说 revise，编排器会升级为 human gate — 让用户来决定。这避免了 Agent 和 Judge 之间的无限乒乓。

调用方式

echo "" | codex exec --skip-git-repo-check -m gpt-5.4 \
  "评审以下实验计划的可行性。
   
   评审标准：
   1. GPU 预算：8×4090，24h 内完成
   2. 实验 setting 必须 match base paper
   3. 所有 claim 必须有对应的实验支撑
   
   实验计划：
   [计划内容]
   
   Research Contract：
   [Contract 内容]
   
   输出 YAML 格式评审结果。"