Hermes反复提示“切换到备用模型”？原因和永久解决方案在这里

如果你使用Hermes Agent时，每次发送消息都看到“⚠️ Rate limited — switching to fallback provider... 🔄 Primary model failed — switching to fallback: sg claude opus 4.7 via custom”，这不是系统出了Bug，而是设计如此——但重复出现确实让人抓狂。

这条提示到底在说什么

Hermes内置了一套自动备用（fallback）机制。当主模型提供商遇到限流、服务器过载、认证失败或连接中断时，系统会自动切换到备用的“provider:model”组合，且不会丢失当前对话上下文。

但关键在于：这种切换只在当前这一轮对话生效。到了下一轮（你发送新消息时），Hermes会重新尝试连接主模型。如果此时主模型仍然处于限流状态，切换就会再次触发，于是你又看到了这条提示。

这就是它“反复出现”的直接原因。

为什么主模型一直处于限流状态

要从根本上解决，必须找到主模型持续触发限流的真正原因：

• 上游提供商限额用尽：如果你使用的是Anthropic、OpenAI等商业API，可能已经用完了当天的请求配额或令牌配额。
• 长上下文请求加剧限流：OpenClaw文档明确指出，当提示词/上下文过大时，上游可能返回“HTTP 429: rate_limit_error: Extra usage is required for long context requests”，即长上下文请求需要额外用量，更容易触及限额。
• 网关级限流：如果你通过OpenClaw Gateway或自定义网关使用模型，限流可能发生在网关层面，而非模型提供商本身。

值得高度怀疑的一点

提示中出现了“sg claude opus 4.7 via custom”，说明备用模型是通过自定义端点（custom endpoint）配置的。

如果主模型和备用模型共用同一个上游网关或密钥池，那么当主模型因限额用尽而失败时，备用模型很可能也因同样的网关/池子被限而“名义上切换了，实际仍不可用”，进而让下一轮尝试主模型时继续失败——形成循环。

虽然没有足够证据断言两者一定共用同一个池，但这是排查时应该首先验证的高概率场景。

排查步骤

1. 查看当前配置

打开 ~/.hermes/config.yaml，确认：

• 当前主模型（model 字段）指向什么
• 备用链（fallback_providers 列表）中包含哪些项目，特别是

  sg-claude-opus-4.7 via custom

  这条的具体配置

如果备用条目中的 provider 字段显示为 custom，说明它走的是自定义端点。

2. 检查主模型与备用模型是否共用上游

查看自定义端点的真实后端地址。如果主模型和备用模型都指向同一个网关、同一个API密钥或同一个服务商的后端，那么其中一个被限流，另一个也大概率不可用。

3. 运行网关诊断

如果你使用OpenClaw Gateway，运行：

openclaw gateway probe

检查输出中的 Reachable 和 Capability 字段，确认网关是否可达以及认证状态。

同时运行

openclaw gateway status --deep

openclaw doctor --deep

4. 检查长上下文请求限制

如果你的对话历史较长，或单次请求的提示词很大，可以尝试：

• 缩短上下文（开始新会话或用 /clear 清理）
• 观察在短上下文下是否仍然出现限流

如果短上下文正常、长上下文才限流，说明问题在于上游对长上下文请求的额外限制。

5. 验证密钥和网关环境

确保API密钥正确配置在网关运行的主机上（通常放在 ~/.openclaw/.env 中）。修改密钥或配置后，务必重启Gateway进程使其生效。

推荐的处理方案

场景	解决方案
主模型超额用尽	等待配额重置，或升级API套餐
主备用共用同一池	将备用改为其他独立提供商（如OpenRouter），避免单点限制
长上下文触发限流	缩短会话长度，或使用支持长上下文的替代模型
网关配置问题	修复密钥、重启Gateway、检查客户端进程
需要快速恢复	用 hermes model 临时切换到另一个确实可用的模型

总结

Hermes反复提示“切换备用模型”不是因为备用机制坏了，
而是因为主模型持续被限，系统忠实地每轮执行“先试主→失败→切备用”的流程[8]。
要彻底停止这种提示，必须解决上游限流的根本原因[2][3][8]。

如果你的配置中主备用恰好共用同一个受限的上游，那么即使切换了，感觉也像“一直在出错”。排查时应优先确认这一点。