夜雨聆风你精心配好的 Agent，正跑着关键任务，结果主力模型一个 503 掉线。那一刻你才明白：单吊一个模型，等于把业务押在别人的心跳上。
一图速览
OpenClaw 的模型配置支持多 provider，不绑死某一家。 failover（故障转移）让你在主模型不可用时自动切到备用模型。 本地模型服务可跑在你自己机器上，兼顾隐私与离线可用。 故障转移不是"随便切"，涉及质量、成本、延迟的权衡。 配置思路：主模型 + 兜底模型 + 本地模型，三级梯队。 不同 provider 在价格、速度、能力、合规上各有取舍。 自托管让"模型选谁"完全由你决定，不被平台绑架。 据官方文档，failover 与本地模型服务是模型配置层的标准能力。
一、为什么不能只用一个模型
先说一个朴素的道理：任何一家模型服务都可能挂。限流、维护、区域故障、账单异常、API 变更——只要你用的是别人的接口，就有失控的那一刻。如果你的 Agent 只认一个模型，那它挂了，你的自动化就停了。
更现实的场景不是"彻底挂掉"，而是"时好时坏"：高峰期延迟飙高、偶发 429 限流、长输出被截断。单模型方案面对这些，表现是脆弱的。OpenClaw 作为自托管网关，把"选哪个模型"的权力完全交给你，同时提供 failover 这种机制，让你的 Agent 在扰动中还能接着干活。
对做个人效率工具的人，failover 可能是"偶尔慢一点"；对做企业内部流程的人，failover 是"半夜别叫我起来重启"的保障。无论如何，多模型冗余是成熟部署的基本功。
有人会问：我把同一个任务多接几个模型，会不会变慢？答案是看你怎么设计。failover 是"失败时才切"，正常情况下只走主模型，所以日常延迟几乎不受影响；它增加的只是"判断失败 + 切换"的极小开销，以及备用模型的待命成本。真正影响体验的，是切换瞬间的那一次重试——如果阈值设得太敏感，会频繁切走又切回。所以"冗余"和"迟钝"是两回事：好的 failover 你平时感觉不到它存在，只有在主模型真出事时，才发现自己被悄悄救了。这种"无感的保护"，正是它该有的样子。
二、failover 是怎么工作的
failover 的字面意思是"故障转移"。在 OpenClaw 的模型配置里，你可以为一个 agent 或一类任务指定多个 provider / 模型，并定义优先级和触发条件。大致逻辑如下（具体字段以官方文档为准）：
主模型优先：正常情况下走你配置的主力模型（比如你最看重的那个，质量最高或最便宜）。 触发切换：当主模型出现可识别的失败——超时、限流、返回错误、健康检查不过——网关按配置切到下一个候选。 兜底模型：链尾通常放一个"永远能跑"的模型，保证至少任务不中断。可以是另一个云模型，也可以是本地模型。 状态恢复：主模型恢复后，后续请求可切回，避免一直用更贵的备用。
这里有两个工程细节。一是怎么算"失败"：是任一错误就切，还是连续失败 N 次才切，需要你定阈值，否则会"抖动切换"——刚切走主模型就好了，又切回来又挂，来回抽风。二是切走之后的语义一致性：不同模型输出风格、格式可能不同，你的下游解析如果不能容忍差异，failover 反而引入新 bug。所以 failover 通常配合"输出格式约束"（比如强制 JSON schema）来用。
据官方文档，OpenClaw 的模型配置层把这些作为标准能力提供，目的就是让自托管用户不用自己造轮子。
补充一个工程视角：failover 的"候选顺序"不是越贵越好，而是要和任务匹配。比如写代码的任务，主力用强编码模型，备用也该选编码不弱的，不能为了省钱切到一个完全不会写代码的模型，那等于"救活了但干砸了"。反过来，像"把这段长文缩成三句话"这种容错高的任务，备用用便宜模型完全没问题。所以成熟的配置往往是"按任务分组"的：不同 agent、不同 channel、甚至不同类型请求，走不同的 failover 链。OpenClaw 把模型配置做成可组合的，正是为了方便你做这种细分，而不是全网一套配置打到死。
三、本地模型服务：把"最后一道保险"放在自己机器上
failover 链尾放什么，是最值得琢磨的。很多人的选择是本地模型服务：在你自己的机器或内网服务器上跑一个开源模型（如通过本地推理服务），作为兜底。
本地模型的好处很直接：
离线可用：云挂了、网断了，本地模型还在，基础任务不中断。 隐私闭环：敏感数据不出本机，适合处理内部文档、个人信息。 零边际成本：不用按 token 付费，跑多少都不加账单。 不被限流：本地不跟你玩 429，稳定可控。
代价也同样真实：本地模型的质量和速度通常不如顶级云模型，尤其是需要强推理、长上下文、多模态的任务。所以本地模型更适合"兜底"和"隐私敏感"场景，而不是当主力。OpenClaw 把本地模型服务作为可配置项，让你把"主云 + 备云 + 本地"组成梯队，是比较务实的架构。
补充一个选型直觉：本地模型不是"便宜的劣质云模型"，而是"另一种取舍"。它慢、可能不够聪明，但它永远在线、零边际成本、数据不出本机。对于"哪怕格式丑一点也要先有结果"的场景（比如离线环境下的草稿生成、内部数据的初步整理），本地模型的"稳定可得"比"聪明"更值钱。把本地模型当成"保底生产力"而非"主力竞争力"，心态就对了。OpenClaw 让你同时握着云的能力和本地的兜底，这种组合在不同网络环境、不同合规要求下，灵活度远高于只信一边。
四、一张表：怎么选 provider
不同 provider 在不同维度上各有长短。下面这张表是通用视角的对比框架，具体数字请以各 provider 官方定价和文档为准，我不替你编精确报价：
怎么用这张表：把"质量最看重的任务"给顶级云模型当主力；把"量大、容错高"的任务给性价比模型；把"不能停、不能出域"的任务留给本地模型兜底。OpenClaw 的 failover 让你把这些角色串成一条链，而不是二选一。
五、成本权衡：冗余是要花钱的
多模型不是免费午餐。每多一个备用 provider，就多一份配置成本、可能的账单、以及调试复杂度。几个权衡点：
备而不用的成本：很多 failover 备用平时不调用，但配置、密钥、监控都要维护。这是"买保险"的成本。 切到贵模型的账单冲击：主模型限流时，流量可能全涌向更贵的备用，月底账单吓人。建议给备用也设预算上限或降级策略。 本地模型的硬件投入：要跑得动，得有显卡或足够内存。对个人是一次性投入，对企业是运维项。 质量的隐性成本：failover 到弱模型，输出质量下降，可能你需要人工返工。这种"省了 API 钱、赔了人力"的账也要算。
所以 failover 配置的成熟度，不在于"接了多少家"，而在于你知道每次切换在发生什么成本。OpenClaw 作为自托管网关，把这些开关都暴露给你，但也意味着你要自己负起"配比"的责任。
还有一个常被忽略的隐性成本：切换带来的"状态不一致"。比如主模型正生成一个很长的文件，中途挂了切到备用，备用是从头生成还是续上？如果续不上，你拿到的是半截输出，比直接报错还难处理。所以选型时也要看模型服务对"断点续传"类能力的支持，或者在 failover 时让 Gateway 主动做"重置上下文 + 重新请求"，宁可偶尔重跑，也不要给下游留半成品。这类细节文档不会替你全想好，得结合你自己的任务形态去调。冗余不是接上就完事，是把"切换那一刻"也设计进去。
六、实践建议：三级梯队怎么搭
给想动手的你一个落地模板（命令与字段以官方文档为准）：
主力层：选你最信任、质量/成本最平衡的云模型，处理日常 80% 任务。 备用层：再选一家不同供应商的云模型，专治主力限流或区域故障。两家最好"不同云"，避免同机房一起挂。 本地层：本机跑一个开源模型，作为最后兜底和隐私任务专用。断网、超预算、敏感数据，都走它。 健康检查：给每个 provider 配超时与失败阈值，避免抖动切换。 格式约束：关键任务强制结构化输出，降低切换带来的解析风险。 可观测：记录每次 failover 的原因和去向，定期回看，优化配比。
这样搭完，你的 Agent 基本能做到：主力稳时用主力，主力抽风秒切备用，全网都不行还有本地兜底。这种"不把鸡蛋放一个篮子"的思路，是 OpenClaw 自托管哲学的自然延伸。
最后一句实在话：failover 配置完不是一劳永逸。模型商的可用性、价格、能力都在变，你几个月前配的"主力 + 备用 + 本地"可能早就不最优了。建议每个季度花十分钟回看一次 failover 日志，看看真实切换都发生在什么场景、备用模型的质量你能不能接受、本地模型还跑得动新任务吗。自动化配比，和车一样需要定期保养。把它当成"持续调优"而不是"一次设置"，你的 Agent 才会在各种意外里始终稳得住。
七、自托管给的底层自由
说到底，failover 和本地模型服务之所以重要，是因为 OpenClaw 把"模型选择权"彻底还给了你。在封闭平台里，你只能用它给的模型；在自托管网关里，云模型、本地模型、开源模型，都是你的可插拔组件。你可以按任务、按成本、按合规自由组合。
这种自由是有重量的：你要学着配比、看账单、管密钥、做监控。但它换来的是"不被任何一家绑死"。对长期做 Agent 系统的人，这种自主权，比短期的省事值钱得多。
把视角拉到 2026 年这个时点看，模型市场的格局本身就鼓励"多模型"策略。据公开资料，OpenClaw 基金会的生态里已有 Red Hat、腾讯等三十多家组织共建，微软 Scout 也基于其开源技术——一个基金会驱动、社区共建的网关，天然倾向于"不站队任何一家模型商"。对使用者来说，这意味着你今天选的架构，不会明天因为某家政策变动而失效。自托管 + 多模型 + failover，本质上是一种"抗绑定"的韧性设计。它不一定让你当下最快，但能让你长期最稳。在模型迭代越来越快的年代，"能随时换"本身就是一种竞争力。
写在最后
单吊一个模型，是把业务押在别人的心跳上。OpenClaw 的 failover 加本地模型服务，给你的是"主云 + 备云 + 本地"的三级梯队。冗余是要花成本的，但不冗余的代价，往往是半夜被叫醒。
今日金句
成熟的 Agent 不赌某个模型永远在线，它给自己留了后路。
今日互动
如果只能保留一个"兜底"模型，你会选：另一家云模型（快但出域），还是本地开源模型（慢但私密）？说说你的取舍理由。
往期回顾
自托管 Agent 网关：数据不出域的另一种可能 上下文工程实战：把窗口用在对的地方 Agent 记忆设计怎么玩：让长期任务不再"转头就忘"