多模型混用：路由、降级与故障转移
系列入口：如何使用 Agent。M12 第 8 篇。
一、为什么不该只用一个模型
把所有任务都压给单一模型，会同时承担三种风险：成本上，用最贵的模型做简单任务是浪费；能力上，没有任何模型在推理、编码、速度、中文等所有维度都最优；可用性上，任何供应商都会限流、抖动、宕机，单点依赖会让你的自动化随之停摆。
成熟的做法是把"用哪个模型"变成一个可路由、可降级、可替换的决策层：简单任务走便宜快模型、复杂任务升级旗舰、主模型不可用时自动切到备用。这与按任务难度分层省钱（见成本管理）和置信度路由（见Jev 路由）是同一思想的两面。
二、按任务类型与成本路由
建立几档模型（便宜快 / 中等 / 旗舰），让路由器根据任务特征选择：格式化分类等高重复低难任务走小模型，常规实现走中档，复杂推理与难调试才用旗舰。延迟敏感选响应快的，批量非紧急可走廉价批处理。
关键是用评测集验证每档的真实能力边界，而不是凭感觉（见评测集）：在某任务上便宜模型达到质量基线就下沉、达不到才升级。这样路由决策有数据支撑，成本下降而质量不滑坡。
三、用置信度决定升级
静态的"任务类型→模型"规则之外，更精细的是根据运行时置信度动态升级：先用便宜模型尝试，当它对自己的回答没把握（置信度低、证据矛盾、自检发现疑点）时，自动把同一问题升级给更强模型，而不是把低质量结果直接交给用户。
这种"先便宜试探、不行再升级"的级联，通常比一律用旗舰省钱，又比一律用小模型可靠，是成本与质量的动态平衡点（升级判据与 Jev 判别一致）。
四、限流、宕机时的降级与故障转移
模型服务的限流和临时故障是常态。设计上需要韧性：
调用主模型遇到限流/超时/错误时，自动重试（带退避）、仍不可用则故障转移到备用供应商或备用模型；在全面降级期间，可暂时降低非关键功能（如关掉昂贵的多跑、只保留核心路径），保证系统"勉强可用"而非彻底停摆。幂等的任务设计让重试和切换不产生副作用。要注意不同模型输出格式可能有差异，切换时做好兼容，确保下游判定不崩。
五、供应商无关：别让自己被锁死
如果你的提示词、解析逻辑、工具调用格式深度绑定某一家的私有接口，切换成本会高到事实上无法移动。保持供应商无关的关键：在自己的代码里定义统一的模型调用抽象，厂商差异封装在适配层；核心逻辑依赖标准输入输出而非厂商专有特性（确需专有功能时隔离在可替换的模块）；配置中随时可改端点和模型。
这与团队层"工具无关"的约定一致（见共享约定）。保留随时离场的能力，本身就是议价和避险的筹码，也让你能在模型快速迭代时随时换到更优选择。
六、路由本身也要可观测
要让多模型体系可优化，需记录每个任务实际走了哪档、是否发生升级或故障转移、各档成本和质量如何。据此你能发现：路由规则是否合理、哪档被过度使用、故障转移频率多高。让路由决策和降级事件都可追溯、可告警（如主模型频繁不可用应及时暴露）。
七、一次故障转移保住生产的例子
看多模型韧性在真实事件中的价值。
某次大促期间，主用的旗舰模型供应商突然开始大面积限流，依赖它的"客服自动回复"和"PR 审查"两条流水线开始大量超时。因为系统早已配好策略：调用失败先带退避重试两次，仍失败就自动切换到预先验证过的备用模型，输出统一为约定的 JSON 契约，下游无感知。 期间对非关键的"多模型并行择优"临时关闭以省配额，只保留核心路径。
用户几乎没有感知到中断，只是事后发现那段时间回复风格略保守——团队随后对降级期的产出做了补审。对比之下，若当初只接了一家、又把解析写死在它的私有格式上，这次限流会让两个功能同时瘫痪。这个例子说明：故障转移的价值平时看不见，但在供应商抖动的那几十分钟里，它就是"系统可用"与"全线停摆"的区别；而这一切的前提，是统一抽象和标准契约让切换真正可行。
八、为每一档建立"能力画像"
多模型路由要准，前提是清楚每个模型在你任务上的真实强弱，而不是只看跑分。
用评测集分别测各候选模型在几类典型任务上的表现：复杂推理、代码生成、简单分类、响应延迟、中文、成本，给每个模型建一张"能力画像"。路由时直接查画像选最匹配的档；新模型发布、或现有模型升级后，重测画像再决定是否调整路由。
跑分是泛化参考，你自己任务上的评测才是路由依据。 很多时候你会发现，某个便宜模型在你 80% 的高频任务上完全够用，而贵模型只在少数难点上不可替代——这张用数据画出的画像，就是既省钱又保质的决策基础。
九、降级也要让用户和团队"知情"
自动故障转移保证了可用性，但如果悄无声息，可能带来两类问题：用户对"质量略降"无预期，团队也不知道主模型其实挂了。
好的做法是降级对内可见、必要时对外克制告知：内部记录并告警降级事件、标注哪些时段的产出来自备用模型、事后补审；面向用户时只在降级实质影响体验时给出恰当说明。韧性不只是"没断"，还包括"状态透明"。让降级成为一个可观测、可追溯、可善后的动作，而不是系统默默切换、所有人都蒙在鼓里——这样你既拿到了可用性，又不会在不知情中让降级产出影响关键决策。
十、定期重验整个路由体系
模型在持续进化、价格在变、业务也在变，一套路由规则配好后会逐渐过时，需要定期重验。
每隔一段时间：用最新评测重测各模型的能力画像、检查路由规则是否仍最优、复盘近期的故障转移和成本数据、并据此调整。新出现的更便宜模型可能值得纳入一档，曾经的旗舰可能已被后来者超越。多模型体系的优势不是一次建立、而是持续保持"总能选到当前最合适的模型"；定期重验让这层决策始终新鲜，也避免你在模型快速迭代中不知不觉用上了次优、或更贵的选择。
十一、简单与韧性的平衡
多模型体系也有复杂度成本，并非模型接得越多越好，需要在简单与韧性间找平衡。
每多接一家，就要多维护一份适配、评测和监控；过早追求复杂路由，可能带来更多故障点而非收益。务实的路径是：先一主一备覆盖最大风险，验证价值后再按需增加，只为真实痛点（成本、某类能力、可用性）引入新档。用最小必要的复杂度拿到大部分收益，比一开始就搭一个精巧却难维护的体系更可持续——工程上很多过度设计，都来自在没有数据支撑时预先应对想象中的问题。
十二、让团队理解并信任路由
路由体系再合理，如果开发者不理解"为什么我的任务被分给了某模型"，也容易产生疑虑或绕过它。
把路由规则和能力画像对团队透明：让大家知道任务如何被分流、何时会升级、降级时会怎样，并允许在结果不理想时手动请求更强模型。透明带来理解、理解带来配合。 当团队把多模型层视为帮他们省钱又保质的共同设施、而非一个黑箱，它才会被正确使用和持续改进——这与任何平台化工具的推广逻辑一致：先让使用者理解规则、并保留必要的人工介入空间。
十三、为"换模型"保留真实选项
供应商无关不只是技术上的抽象，更要在实践中定期验证切换确实可行，否则它只是纸面能力。
偶尔让部分任务真正跑在备用模型上、确认质量达标、团队也熟悉切换流程，这样在真正需要故障转移时才不会手忙脚乱。一个从未被演练过的"备用方案"，等于没有方案。 把切换演练纳入常规，既是对韧性的真实检验，也向供应商传递了"我可以离开"的信号——多模型的议价和避险价值，只有在切换被证明真实可用时才真正兑现。
十四、常见问题
Q：不同模型风格不一致怎么办？ 用输出契约（如要求 JSON、固定字段）和适配层统一，下游只依赖契约而非具体措辞。
Q：故障转移后质量下降怎么办？ 把"可用但略降级"作为韧性目标并明示，关键路径确保备用模型也达标；事后可对降级期产出补审。
Q：要不要接入很多家？ 起步一主一备即可覆盖多数风险，按成本和可用性逐步增加，避免过度复杂。
Q：开源/本地模型能作为一档吗？ 能，尤其对敏感数据和成本敏感场景，经评测达标后作为降级或专属通道。
八、检查清单
- 已建立多档模型并按任务难度/成本路由。
- 路由与升级判据经评测集验证。
- 有重试、故障转移和服务降级的韧性设计。
- 模型调用有统一抽象，保持供应商无关。
- 已记录路由、升级、故障转移并做监控。
总结
多模型混用的本质，是把"用哪个模型"从写死的选择变成一层可路由、可升级、可故障转移、可替换的决策：按任务难度和成本在便宜/中档/旗舰间路由、用评测集确认每档能力边界，运行时依据置信度把低质量尝试自动升级，遇到限流或宕机就带退避重试、切换备用模型并适度降级以保可用，同时用统一抽象和标准输出契约保持供应商无关、避免被锁定，再把所有路由与降级事件记录可观测；这样你能同时拿到更低成本、更强能力和更高可用性——没有谁永远最优或永不宕机，而一个设计良好的多模型层，让这些风险都不再由你独自承担。