先把一个模型跑稳，再谈调度
最容易犯的错不是“模型太弱”，而是还没把单模型跑稳，就先把 fallback、路由、预算和多条链路一起上了。
单模型什么时候就够用
单模型通常已经足够的场景包括：
- 你还在跑第一条渠道闭环
- 技能数量不多
- 任务类型比较单一
- 你现在最怕的是排障，而不是模型极限
这时候单模型的最大优势不是“简单”，而是：
- 更容易判断问题在哪
- 更容易估算成本
- 更容易看清上下文和工具调用的关系
什么时候该先加 fallback
先加 fallback，而不是直接做复杂路由，通常适合这些情况：
- 主模型偶尔不稳定
- 你不希望某次故障把整条任务链打断
- 你想给关键动作准备一个较弱但可用的兜底
fallback 的本质不是“更聪明”，而是“更稳”。
什么时候才值得上多模型路由
多模型路由更适合下面这些情况：
- 任务已经明显分层
- 你知道哪些任务值得上高质量模型
- 你知道哪些任务只需要低成本模型
- 你已经能接受配置、日志和排障复杂度上升
如果你现在还说不清楚“哪些任务该去哪一个模型”，那通常还不该做路由。
一个更稳的升级顺序
蓝皮书里最有价值的一点不是具体模型名，而是升级顺序：
- 先单模型
- 再双模型分层
- 再补 fallback 链
- 最后才是任务专项路由
如果你反过来做，复杂度几乎一定先于理解。
双模型什么时候最值
双模型最适合下面这种状态：
- 你已经知道“简单任务”和“复杂任务”的区别
- 你不想所有任务都去最强模型
- 你愿意接受一点点配置复杂度，换明显成本下降
更常见的分法通常是：
- 轻量模型：查询、翻译、格式化、短摘要
- 主力模型：复杂写作、长链路任务、需要更稳妥判断的场景
fallback 链真正解决什么
fallback 的工作不是“让系统更聪明”，而是：
- 主模型出错时不断档
- 遇到限流时不至于整条任务链停住
- 让你在生产环境里有最低可用兜底
所以更应该先定义的是：
- 哪些情况才触发 fallback
- 最多重试几次
- 触发后是否报警
任务专项路由，只有这类人该先碰
任务专项路由更适合已经能明确区分下面这几类任务的人：
- 中文写作
- 长文档处理
- 复杂推理
- 图像分析
- 批量处理
如果你现在只是“觉得不同模型各有优缺点”，还不够。
只有当你能把任务类型说清楚，专项路由才值得上。
最容易出问题的两种误配
误配 1：把所有任务都送去最强模型
短期看最省事，长期通常最贵。
而且很多基础任务，比如结构整理、固定格式输出、轻量摘要，并不需要最高规格模型。
误配 2：刚装好就做复杂多模型链
一旦消息链、技能、工具权限和模型路由同时出问题，你几乎没法判断是哪里坏了。
一份够用的判断清单
在你决定上 fallback 或路由前，先过一遍这张表：
路由思考 checklist
1. 当前单模型是否已经稳定跑通
2. 我能否清楚说出 fallback 的触发条件
3. 我能否说出哪些任务值得去更强模型
4. 我是否已经能看懂成本和日志
5. 如果路由配置错了，我知道怎么快速回滚
如果这 5 条里有 2 条还答不上来，先别做复杂路由。
一个足够保守的配置思路
第一次做模型分层时，更保守的方式通常是：
{
"strategy": "single-model-first",
"primary": "你当前最稳定的一条模型路线",
"fallback": "只在主模型失败时启用",
"routing": "先按任务价值分层，不按想象分层"
}
这不是可直接粘贴的正式配置，而是一种思路模板：
先有主模型，再有兜底，最后才考虑主动路由。
先不要做的两件事
- 不要一开始就配 4 到 5 层 fallback
- 不要把“中文写作、图像分析、复杂推理、批处理”全都一次配完
前者会让你排障很痛苦，后者会让你根本不知道哪条路真正产生了价值。
继续往下看什么
- 想把预算控制一起想清楚，去看 模型成本控制
- 想把这些思路写成实际配置，去看 配置模板中心
- 主要在中文环境里跑，去看 国产模型路线 / Coding Plan 入口
- 查看官方路由配置文档 → OpenClaw 文档
- 遇到路由问题 → GitHub Issues