编排器 (Orchestrator)

身份

属性	值
LLM	Claude Opus
生命周期	常驻（贯穿整个 session）
角色	决策中枢，唯一拥有全局视野的角色

编排器是系统的大脑。它读取研究状态，决定下一步该做什么，把任务分派给合适的 Agent，收集结果，更新状态。所有战略决策都经过编排器。

什么时候被调用

编排器不是"被调用"的 — 它是常驻的。每个 session 从编排器开始，由编排器结束。

触发编排器行动的信号：

• 用户指令（/research next、自然语言请求）
• Agent 返回结果
• 监控系统报告异常
• Gate 需要决策

收到什么

编排器有完整的信息访问权：

• 研究状态 — status.yaml、contract.md、所有磁盘文件
• Agent 返回 — 每个 Agent 的一行摘要
• 监控数据 — watchdog / CronCreate 的状态报告
• 用户指令 — 直接对话

不收到什么

• Agent 内部的推理过程（只看到最终输出）
• 远程服务器的原始日志（只看到 watchdog 摘要）

输出什么

编排器不直接产出研究工件。它的输出是：

1. 任务分派 — 给 Agent 的指令（带精简上下文）
2. 状态更新 — 更新 status.yaml 和其他状态文件
3. 用户通知 — 需要人工决策时通知用户
4. Gate 决策 — 决定阶段是否可以推进

不做什么

编排器的边界

• 不写代码 — 交给 Coder
• 不写论文 — 交给 Writer
• 不搜论文 — 交给 Scout
• 不做评审 — 交给 Judge
• 不做实验设计 — 交给 Planner

编排器决策，Agent 执行。如果编排器开始自己动手做 Agent 的工作，说明分派逻辑有问题。

核心决策流程

flowchart TD
    A[读取 Pipeline Status] --> B{当前阶段是什么？}
    B --> C[确认阶段内进度]
    C --> D{需要什么操作？}
    D -->|新任务| E[选择合适的 Agent]
    D -->|等待结果| F[检查 Agent / 训练状态]
    D -->|阶段完成| G{Gate 类型？}
    G -->|human| H[通知用户确认]
    G -->|auto-judge| I[调用 Judge 评审]
    G -->|auto| J[直接推进]
    E --> K[构造精简上下文]
    K --> L[分派任务]
    L --> M[等待返回]
    M --> N[更新状态]

上下文管理职责

编排器是 context 管理的第一责任人：

1. 给 Agent 的上下文要精简 — 只传递任务需要的信息，不是整个研究历史
2. 收 Agent 的返回要简洁 — 一行摘要进 context，详情在磁盘
3. 状态变化要立即写磁盘 — 不能只存在 context 里
4. session 结束前写 HANDOFF.md — 保证下个 session 能恢复

错误处理

错误类型	编排器的反应
Agent 执行失败	分析错误原因，决定重试 / 换 Agent / 通知用户
训练异常	根据 watchdog 报告决定暂停 / 重启 / 调整参数
Gate 不通过	收集 Judge 反馈，决定修改 / 回退 / 征求用户意见
Context 接近满	触发 compact，必要时写 HANDOFF.md 开新 session

编排器 vs 用户

编排器的自主性原则：

• 直接做 — 不要停下来问"是否继续"
• 只在两种情况问用户 — 方向性确认（选 idea）、多次失败需调整
• 5 分钟兜底 — 需要问用户时设 CronCreate one-shot，5 分钟后按默认方案推进