模型降级不是兜底，是生产系统的稳定策略

为什么需要模型降级

在 AI 工作流里，模型并不是永远可用的。接口会限流，本地推理会占满显存，长上下文会让延迟突然升高，某个模型也可能在工具调用或结构化输出上表现不稳定。如果系统只绑定一个主模型，故障就会直接传导到任务执行。

模型降级的目标不是追求便宜，也不是简单换一个小模型，而是让任务在不同压力下仍然能完成。主模型负责复杂推理和最终把关，备用模型负责摘要、分类、检索整理、格式转换等低风险步骤。这样即使主模型不可用，队列也不会完全停住。

降级要按任务风险分层

最适合降级的是可验证任务，比如提取标题、生成摘要、整理日志、检查链接、改写短文。这类任务可以通过规则、测试或人工抽查发现错误。

不适合直接降级的是生产发布、数据库写入、财务判断、安全策略和复杂代码合并。这些任务即使用了备用模型，也应该经过更高等级模型或人工 gate 复核。

一个实用配置

生产系统可以保留三层模型：第一层是主力模型，处理规划、复杂编码、长上下文和最终审查；第二层是吞吐模型，处理批量文本和中等复杂度任务；第三层是保底模型，只处理简单结构化任务。

调度器需要记录每次切换原因，包括限流、超时、上下文过长、工具不支持或质量不达标。没有记录的降级，后面就无法判断是偶发故障还是架构问题。

OpenClaw里的落地方式

在 OpenClaw 里，模型降级应该和任务拆分一起设计。一个大任务先拆成资料收集、草稿生成、验证、发布四段，不同阶段选择不同模型。最终发布前，再由稳定模型做一次页面、日志和数据回读。

这比简单写一个 fallback 配置更可靠。真正的稳定性来自任务边界、证据回读和明确的回滚路径，而不是模型名字本身。