双模型协同：让便宜的模型做规划，贵的模型只负责执行

前八篇写下来，你可能已经发现了：Reasonix 最核心的省钱武器，是前缀缓存。
>
但如果你同时用两个模型——一个便宜的做规划，一个贵的做执行——各自的缓存还能独立保持高命中率吗？
>
答案是能。而且这是 Reasonix 独有的能力。

一、直觉上，双模型应该更贵

先说实话：同时用两个模型，听起来像在烧钱。

一个任务，叫两个 AI 来干 → 两倍的钱

但 Reasonix 的设计正好反过来——双模型协同反而更省钱。原因有三个：

原因一：各司其职，不浪费

模型做什么成本调用频率
规划器（planner）读代码、分析架构、出方案便宜（如 deepseek-flash）低（只在任务开始时）
执行器（executor）写代码、跑命令、落地贵（如 deepseek-pro）高（全程干活）
如果不分角色，让贵的模型自己边想边干，它会在"想"的阶段也花贵的钱。

原因二：缓存独立，互不干扰

这是最巧妙的部分。两个模型各自在独立的会话中运行：

  • 规划器的对话 → 缓存规划器的提示词 → 缓存命中率高
  • 执行器的对话 → 缓存执行器的提示词 → 缓存命中率也高
如果把两个模型塞进同一个会话，切换模型会导致前缀变化、缓存全部失效。分开跑，双方都保持 90%+ 的缓存命中率。

原因三：规划器只读，不消耗执行额度

规划器只能使用只读工具（读文件、搜索代码），不能写文件、不能跑命令。这意味着：

  • 规划器不需要大量的输出 token
  • 规划器的上下文不会膨胀太快
  • 规划器的成本几乎可以忽略不计

二、配置方法：只需加一行

默认配置下，Reasonix 只用执行器。开启双模型协同只需要一行配置：

[agent]
planner_model = "deepseek-flash"   # 用 flash 做规划
planner_max_steps = 12             # 规划器最多 12 步只读操作

完整配置示例

default_model = "deepseek-pro"     # 执行器用 pro

[agent]
planner_model = "deepseek-flash"   # 规划器用 flash
planner_max_steps = 12             # 规划器最多 12 步
max_steps = 0                      # 执行器不限步数

[[providers]]
name        = "deepseek-flash"
kind        = "openai"
base_url    = "https://api.deepseek.com"
model       = "deepseek-v4-flash"
api_key_env = "DEEPSEEK_API_KEY"
context_window = 1000000

[[providers]]
name        = "deepseek-pro"
kind        = "openai"
base_url    = "https://api.deepseek.com"
model       = "deepseek-v4-pro"
api_key_env = "DEEPSEEK_API_KEY"
context_window = 1000000

注意事项

  • planner_model 必须指向一个不同的 provider
  • 如果两个模型来自同一个 vendor（如都是 DeepSeek），只要 name 不同就行
  • planner_max_steps 建议设为 8-15，太高了规划器会过度分析
  • max_steps 控制执行器，跟规划器无关

三、双模型协同的完整工作流

第一步：规划器登场

你提出一个复杂任务。规划器开始只读分析：

你：帮我把这个项目的日志系统从 logrus 迁移到 slog

[规划器 deepseek-flash 启动]
  → read_file go.mod
  → grep "logrus" internal/**/*.go
  → read_file internal/logger/logger.go
  → ls internal/
  → grep "log\." internal/handler/*.go
  ……

规划器会持续探查代码，直到它认为信息足够。

第二步：规划器输出计划

📋 迁移计划

当前状况：
- logrus 在 23 个文件中被引用
- 有自定义格式化器 internal/logger/logger.go
- 在 cmd/main.go 中初始化

建议执行方案：
1. 创建 slog 封装层（保持接口兼容）
2. 逐文件替换，每 5 个文件跑一次测试
3. 清理 go.mod 依赖

风险提示：
- handler/ 和 service/ 有交叉引用，建议同步替换

第三步：你审核

你：计划可以，先替换 handler 目录

第四步：执行器开始干活

[执行器 deepseek-pro 启动]
  拿到规划器的计划，开始执行
    
  [1/6] → edit_file internal/handler/user.go
  [2/6] → edit_file internal/handler/order.go
  ……
  → go test ./internal/handler/... ✓

执行器拿到计划后，按步骤执行。每一步都会跑测试确认没搞坏。

四、实际成本对比

我用一个中等复杂度的任务做了实测：

"重构用户模块，加上 Redis 缓存层"

模式规划阶段执行阶段总成本
只用 pro—23 步，¥0.087¥0.087
只用 flash—23 步，¥0.012¥0.012（但质量一般）
flash 规划 + pro 执行8 步，¥0.00318 步，¥0.068¥0.071
关键发现：

指标只用 proflash 规划 + pro 执行
总成本¥0.087¥0.071（省 18%）
执行步数23 步18 步（少 22%）
代码质量还好更好（有规划，少走弯路）
审查负担需要全程盯着只看计划就行，执行更放心
为什么双模型反而更省？ 1. 规划阶段花的是 flash 的钱（便宜 90%） 2. 有了规划，执行阶段少走了弯路（步数减少 22%） 3. 两个模型缓存独立，各自保持高命中率

五、什么时候该用双模型？

推荐使用双模型的场景

场景理由
复杂重构需要先理解架构再动手，规划器最适合
不熟悉的代码库规划器可以先花时间读代码，不浪费执行器的钱
多人协作项目需要方案评审，规划器出的计划可以分享给团队
自动化任务reasonix run 时自动走规划→执行流程

不需要双模型的场景

场景理由
简单 bug 修复直接让执行器干就行
文件格式化不需要规划
快速原型需要快速试错，规划反而拖慢节奏

六、微调规划器的行为

限制规划器的深度

[agent]
planner_model = "deepseek-flash"
planner_max_steps = 8     # 规划器最多 8 步，浅尝辄止

如果任务比较明确，可以减少规划步数，让规划器快速出方案。

限制执行器的范围

[agent]
max_steps = 30            # 执行器最多 30 步

防止执行器陷入死循环。

Subagent 也可以指定模型

不只是规划器/执行器，连内置的 review、research 等 subagent 也可以单独指定模型：

[agent]
subagent_model = "deepseek-flash"                  # 所有 subagent 默认用 flash
subagent_models = { review = "deepseek-pro" }      # 但 review 用 pro

这样，日常的 explore 和 research 用便宜的 flash，遇到代码审查这种需要深度的任务才用 pro。

写在最后

双模型协同是 Reasonix 性价比最高的用法：

规划器（flash）：   ¥0.003  →  出一份完整方案
执行器（pro）：     ¥0.068  →  按方案精准执行
────────────────────────────────
总计：             ¥0.071  →  比只用 pro 省 18%，质量还更好

不是你请不起 pro，而是让 flash 先探路更聪明。

🔜 下一篇预告：Desktop 桌面端完全指南

如果你不喜欢终端界面，Reasonix 还有一个 Wails 桌面客户端——图形界面管理会话、配置、MCP 插件，还能看对话历史树。而且它跟 CLI 共享同一个内核，配置互通。
>
关注我，带你用最少的钱，薅最狠的 AI 羊毛。

📌 互动话题：你会怎么搭配两个模型？flash + pro 还是 flash + mimo？评论区聊聊你的方案。