模型接入真正拉开差距的地方，不只是“你用哪一家”，而是主模型、备用模型、认证 profile 和图片模型怎么一起配。OpenClaw 官方的 failover 逻辑非常清楚：先在同一模型内轮换 auth profile；如果还失败，再进入下一层 fallback 模型。 这一层配好了，多渠道机器人和长期运行场景会稳很多。
真正长期跑 OpenClaw，主模型决定上限，fallback 决定稳定性，imageModel 决定多模态体验。三者拆开规划，比“选一个全能模型”更稳。
先理解官方的两级 failover
- 同模型内轮换 auth profile：如果同一个 provider / model 下你配了多个认证资料，OpenClaw 会先尝试在这一层轮换。
- 模型级 fallback：只有当前模型线路不行了，才会继续走到
fallbacks里的下一条模型。
这意味着：一把 key 出问题，不等于一定要立刻切到另一家模型。 如果你已经配了多个 auth profile，系统会先在同型号内部做恢复。
3 个最重要的模型位
primary：主模型，日常优先走它。fallbacks：备用模型链，按顺序接力。imageModel：图片、截图、视觉任务专用，不一定和 primary 相同。
这一点对多模态场景尤其重要。很多人只配了文本主模型，结果截图理解、图片问答效果差，本质上是没有单独规划 imageModel。
最容易踩的 allowlist 坑
如果你配置了 agents.defaults.models，它就会变成允许列表。此时即使你把 primary 或 fallbacks 改了，只要新模型没进 allowlist，系统仍然可能报：
Model is not allowed
这是模型接入里最常见、也最隐蔽的坑之一。很多人以为是 API key 或 provider 坏了，实际上只是 allowlist 没同步。
最实用的 4 种混合思路
中文优先
主模型放一条中国 provider，fallback 放另一条中国 provider 或一条国外强模型。这样飞书、钉钉、企微等中文场景更稳，同时复杂任务还有兜底。
编码优先
主模型放强推理 / 强 coding 路线，fallback 放成本更低或中文更友好的模型。这样日常多数请求有高质量输出，长时间跑又不会太贵。
国际平台优先
Telegram、Discord、Slack 这类机器人可以把国外 provider 做主模型，再补一条中国模型或聚合 provider 做 fallback，兼顾稳定性和成本。
本地优先
本地模型做第一层，远程强模型做第二层，适合隐私优先但又不希望复杂任务完全失手的场景。
什么时候该单独配 imageModel
- 你经常上传截图、界面照片、图表或文档图片。
- 你的主模型偏文字，不一定是最佳视觉模型。
- 你想把图片任务和文本任务分成本管理。
简单说：如果你经常让机器人“看图”，就别把图片能力默认为主模型自然附带。
给中国用户的实战建议
- 先把一条最稳的 provider 放到 primary，不要一开始就搞 5 条随机切换。
- 至少补一条 fallback，最好不是同一家同一把 key。
- 高频图片任务单独规划 imageModel。
- 如果你做多渠道机器人，fallback 比“单次最强模型”更重要。
排障顺序建议
- 先确认 provider auth 是否还有效。
- 再看当前主模型是否在 allowlist 里。
- 确认 fallback 链是否真的被配置，而不是只写了 primary。
- 多模态问题再看 imageModel 有没有单独规划。
和多渠道机器人有什么关系
关系很大。一个机器人也许只是偶尔掉一次，但多渠道同时在线时，一条模型线路波动会被放大成“飞书也卡、Telegram 也卡、Dashboard 也慢”。所以模型 fallback 实际上是多渠道稳定性的底层保障。
如果你已经在跑飞书、钉钉、Telegram 等多个入口，这一页的重要性通常比单独换更强模型还高。