真实系统里模型调用一定会失败。可能是429 rate limit 认证过期 provider 超时 模型临时不可用 上下文太大 网络波动 工具结果过长OpenClaw 要解决的不是“永不失败”而是“失败后知道该不该重试、换 key、换模型还是直接告诉用户”。先说结论Retry 和 Failover 不是一回事可以这样区分Retry 同一个请求短暂失败后再试一次 Auth profile rotation 同一个 provider换另一个 key / OAuth profile Model failover 当前模型或 provider 不可用时换 fallback model User-visible error 不应该自动绕过时把结构化失败告诉用户不要把所有失败都暴力重试。Retry按请求重试不按整条流程重跑官方 retry policy 的目标包括按 HTTP request 重试 保持顺序 避免重复非幂等操作默认配置包括attempts: 3 maxDelayMs: 30000 jitter: 0.1这意味着 OpenClaw 不会随便重放已经完成的复合流程。否则可能出现重复发消息、重复上传、重复执行命令。Provider SDK 和长 Retry-After对 OpenAI、Anthropic 这类 SDKOpenClaw 允许 SDK 处理普通短重试。但如果 retry-after 很长OpenClaw 会让 SDK 快速暴露错误这样 model failover 可以接管换 auth profile 或 fallback model。这避免了用户等几分钟却没有任何进展。Auth profile rotation先换同 provider 的身份OpenClaw 使用 auth profiles 管理 API key 和 OAuth token。当某个 profile 遇到 rate limit、auth 或类似 cooldown 错误时可以尝试同 provider 下的下一个 profile。例如openai-codex:userexample.com ↓ 使用量限制 openai:api-key-backup这仍然可能保持同一个模型或 runtime只是换了认证来源。Model failover再换模型候选官方 model failover 文档说明OpenClaw 先在当前 provider 内进行 auth profile rotation再根据agents.defaults.model.fallbacks尝试下一个模型候选。运行时会解析 session 当前模型状态 构建 candidate chain 尝试当前 provider 和 auth profiles 遇到可 failover 错误时进入下一个模型 把 auto fallback override 写入 session 失败时窄范围回滚 全部失败时抛出 FallbackSummaryError用户还会看到 fallback notice例如从 primary 切到 fallback或 primary 恢复后清除 fallback。哪些选择不应该自动 fallback如果用户显式/model选择了某个模型这通常是 user session override。官方文档说明用户显式选择是严格选择。如果失败OpenClaw 应报告失败而不是悄悄用另一个模型回答。原因很简单用户明确要求用 A 系统不应该无声换成 B常见误解误解一失败就应该一直重试不对。非幂等流程不能随便重放。误解二Fallback 等于换更差模型不一定。Fallback 只是下一个候选可以是更快、更便宜、更稳也可以是备用强模型。误解三用户指定模型也应该自动降级不一定。显式用户选择通常应该严格执行。最后总结可靠性来自分层处理失败。一句话总结短暂错误用 retry身份问题用 profile rotation模型不可用用 fallback不该绕过的错误要透明报告。本节作业设计一个 primary two fallbacks 的模型链。解释 retry 和 model failover 的区别。思考哪些工具调用不能自动重试。找一次 429 或 timeout判断它应该 retry、rotate 还是 fallback。下一节预告下一节进入工具系统、Browser、Shell 与 Canvas我们会把 OpenClaw 如何真正“动手做事”讲透。参考资料OpenClaw DocsModel failoverOpenClaw DocsRetry policyOpenClaw DocsModel providersOpenClaw DocsModels CLIOpenClaw DocsFAQ: models and auth原文链接模型降级、重试和错误处理策略 | Harries Blog™