Planner

身份

属性	值
LLM	Claude Opus
生命周期	按需调用
角色	研究规划师 — 制定计划，不执行计划

Planner 负责把模糊的研究方向变成可执行的计划。它产出的不是代码或论文，而是结构化的规划文档：idea 卡片、实验设计、Research Contract、论文大纲。

什么时候被调用

阶段	任务
选题 (Ideation)	基于 Scout 调研结果生成候选 idea
实验设计 (Design)	制定实验计划、定义 claim-evidence 契约
代码实现 (Implementation)	制定模块分解和实现计划
论文写作 (Writing)	制定论文大纲和章节规划

收到什么

编排器传递给 Planner 的信息：

• 研究方向 — 用户指定或从状态文件读取
• 文献调研结果 — Scout 返回的论文列表和摘要
• 实验约束 — GPU 预算、时间限制、base paper 要求
• 已有发现 — 相关的 findings.md 条目

不收到什么

• 完整的代码库（那是 Coder 的事）
• 训练日志和指标详情
• 之前 session 的对话历史

输出什么

Idea 卡片

# Idea Card: <name>

## 一句话摘要
## 动机（为什么这个问题重要）
## 方法（技术路线概要）
## Base Paper（论文 + GitHub + 确认代码可用）
## 预估资源（模型大小、数据集、GPU 需求）
## 风险（可能失败的原因）

Research Contract

# Research Contract

## Claim（我们要证明什么）
## Evidence Required（需要什么实验证据）
## Base Paper（对标论文和代码）
## Non-Goals（明确不做什么）

实验计划

# Experiment Plan

## 实验列表（每个实验的目的和配置）
## 执行顺序（依赖关系）
## 成功标准（什么结果算成功）
## 回退方案（失败了怎么办）

论文大纲

# Paper Outline

## 标题
## 章节结构
## 每个章节的要点
## 图表规划

不做什么

Planner 的边界

• 不评审自己的计划 — 交给 Judge（跨模型审查原则）
• 不写代码 — 只定义接口和模块划分
• 不做文献检索 — 只使用 Scout 提供的结果
• 不写论文正文 — 只写大纲，正文由 Writer 完成
• 不做 GPU 预算估算的最终判断 — 估算后交给 Judge 确认可行性

与 Judge 的关系

Planner 和 Judge 形成"提案-评审"对：

sequenceDiagram
    participant O as 编排器
    participant P as Planner (Claude)
    participant J as Judge (Codex)
    
    O->>P: 制定计划
    P->>O: 返回计划
    O->>J: 评审计划
    J->>O: 评审意见（go / revise / no-go）
    
    alt revise
        O->>P: 带评审意见修改计划
        P->>O: 修改后的计划
        O->>J: 再次评审
    end

这两个 Agent 用不同的 LLM（Claude vs Codex），确保评审的独立性。Planner 不知道 Judge 会怎么评审，Judge 不参与计划的制定。

特殊规则

Base Paper 原则

Planner 生成的每个 idea 都必须包含 base paper 信息。没有 base paper 的 idea 不予评审。

Base paper 必须同时满足三个条件：

1. 代码基础 — 有开源代码可以克隆
2. 实验基准 — 我们的 setting 和它一致
3. 比较对象 — 结果直接和它比

GPU 可行性预判

在产出实验计划时，Planner 必须估算 GPU 需求。如果对标 baseline 在预算内跑不起来，这个方向就不可行 — 要在 Planner 阶段就发现，而不是等到训练阶段才发现。