06 · 模型选择策略4 个高能力模型的分工,reviewer 随机选但不与 developer 重复

模型库

Developer 模型选择

Developer 默认用 deepseek-v4-pro。原因:

• deepseek 在代码生成任务上基准最强
• 成本可控(同档里不是最贵的)
• 响应稳定,工具调用好

PM 在以下情况可临时换 model:

• Developer 卡住 / 重复出错 → 换 GLM 或 MiniMax 试试
• 任务类型特殊(写 UI 重组件)→ 用 GLM(中文 / 美感更好)
• 任务上下文超大(>50K token)→ 用 Kimi(长上下文强)

Reviewer 模型选择(随机 + 不重复)

为什么不从 4 个里选(含 deepseek)?

• Developer 大概率用 deepseek,如果 random 选到 deepseek,概率 1/4 浪费
• 故意排除 deepseek → 强制"换视角 review",避免模型偏见

伪代码

REVIEWER_POOL = ["opencode-go/glm-5.2",
                 "opencode-go/minimax-m3",
                 "opencode-go/kimi-k2.7-code"]

def pick_reviewer(developer_model: str) -> str:
    pool = [m for m in REVIEWER_POOL if m != developer_model]
    return random.choice(pool)

为什么是"不重复"而不是"差异化"?

• 差异化需要"哪个 model 强在哪类任务"的知识,复杂且容易过拟合
• 随机+不重复 = 简单,且平均下来每个 iteration 都会被不同 model review
• 以后想优化再改

Merger 模型选择

Merger 默认用 deepseek-v4-pro(它只跑几个 git 命令,model 能力要求不高,沿用主力即可)。

实际上 merger 的"智能需求"很低(只解释 merge 策略),以后甚至可以用 deepseek-v4-flash 省钱。

模型 fallback 链

如果某个 model 失败(限流、报错),PM 的 fallback 顺序:

deepseek-v4-pro
  → deepseek-v4-flash          (同 provider 的轻量版,省钱)
    → glm-5.2                   (换 provider)
      → minimax-m3              (再换)
        → kimi-k2.7-code        (最后备选)
          → 报用户              (都失败)

模型成本监控

PM 在每次 session 结束时记录:

• 输入 token
• 输出 token
• reasoning token(如果有)
• 估算 cost(按 provider 公开价)

写入 .pm/iterations.json 对应 iteration 的 cost_usd 字段。

每日汇总成一行(写入 ~/agent-workspace/logs/daily-cost.jsonl),PM 在预算快超限时主动告知用户。

模型升级路径(未来)