别等 Hermes 任务跑崩才补救：3 层模型兜底配置，额度用完也能续上

很多人刚开始用 Hermes，最关心的是模型够不够强。跑久了以后，你会发现另一个更烦的问题：模型能不能稳定接住任务。

比如你让 Hermes 跑一个长任务：整理资料、跟踪网页、执行 Cron、写一套脚本、分析一批文件。前面 20 分钟都很顺，快结束时突然来一句：

HTTP 429
rate limit exceeded
quota exhausted
usage limit reached
provider overloaded

任务已经跑了一半，上下文也堆起来了，工具调用也执行过了，偏偏模型额度没了、接口限流了、服务商抽风了。你再手动换模型，经常要重新解释一遍前因后果。

Hermes 这类工具真正要跑稳，不能只配一个模型、一把 Key、一个入口。更稳的做法是提前准备 3 层兜底：

  1. 同服务商多 Key 轮换
  2. 主模型失败后自动切备用模型
  3. 图片、网页提取、压缩这些辅助任务也单独兜底

今天就把这套讲清楚。

一、为什么长任务最怕半路断掉

短对话里，模型挂一下问题不大。你问一句，失败了，换个模型再问一遍就行。

但 Hermes 的长任务不一样。它可能已经读过文件、开过网页、跑过命令、生成过中间结果，还可能在 Cron 里无人值守地执行。这个时候断掉，损失的不只是一条回复，还包括前面已经消耗的时间、Token 和上下文整理成本。

最常见的崩点有 5 类：

状态码 含义
429 限流，短时间请求太多
402 余额、账单、额度问题
500 / 502 / 503 服务商服务器异常
401 / 403 Key 失效，权限不对
404 / invalid response 模型名、接口或返回格式异常

这类问题靠“换一个更聪明的模型”解决不了。你要做的是给 Hermes 提前铺好备用路线。

打个比方，主模型像主路。平时走主路最快，但一旦堵车，你不能坐在原地等。你要提前准备辅路、备用车、备用司机。Hermes 里的 3 层兜底，就是这个思路。

二、第一层：同一个服务商，多准备几把 Key

第一层最简单，也最容易被忽略：Credential Pools（凭据池）。

它解决的是同一个 provider 里的 Key 用完、限流、失效问题。比如你主要用 DeepSeek，主模型是 deepseek-v4-pro。如果只有一把 DeepSeek API Key，一旦这把 Key 限流或额度用完，Hermes 就只能报错。

如果你在同一个 provider 里放了多把 Key，Hermes 遇到这类问题时，可以换下一把健康的 Key 继续跑。

先看看当前凭据：

hermes auth list

给 DeepSeek 加第二把 Key：

hermes auth add deepseek --api-key sk-your-second-deepseek-key

如果你还用 OpenRouter，也可以加第二把 OpenRouter Key：

hermes auth add openrouter --api-key sk-or-v1-your-second-key

这一步的价值很实在：

  • 主模型不变
  • 服务商不变
  • 模型风格不变
  • 只是在同服务商下换一把可用 Key

建议：长期跑任务的人，至少给主 provider 准备两把 Key。尤其是你用 Hermes Cron 跑日报、监控、资料整理时，这一步很值。

三、Key 怎么轮换：别让一把 Key 被薅到见底

多把 Key 放进去以后，还要考虑怎么用。Hermes 支持给不同 provider 设置轮换策略。可以理解成：到底先把第一把 Key 用到不能用，还是几把 Key 轮着用。

配置示例：

credential_pool_strategies:
  deepseek: round_robin
  openrouter: least_used

常见策略：

策略 含义
fill_first 先用第一把，用到不行再换
round_robin 几把 Key 轮流用
least_used 优先用目前用得少的那把
random 随机选一把
  • 如果你只有两把备用 Key，想要平时尽量平均一点，就用 round_robin。
  • 如果你有几把不同额度的 Key，希望尽量别让某一把过早见底，可以试 least_used。

这里有个小坑要提前说：Key 一换，prompt cache（提示词缓存）可能失效。新 Key 没有前面那段上下文缓存，下一次请求可能要重新读完整上下文，多花一点输入 Token。

所以凭据池的本质不是“免费省钱”，更像是**“任务续命”**。长任务最怕断，必要时多花一点，也比整轮任务报废强。

四、第二层：主模型挂了，自动切备用模型

第一层解决的是同服务商里的 Key 问题。第二层要解决更大的问题：整个 provider 或主模型不稳定。

比如你主力用 deepseek-v4-pro。某一段时间 DeepSeek 接口拥堵，或者你这边额度打满了。这个时候只换 DeepSeek 的另一把 Key 也许没用，因为问题出在服务侧或账户总额度上。

这时候就需要 fallback providers。

你可以直接用交互式配置：

hermes fallback

也可以手动改 ~/.hermes/config.yaml。下面给一个偏实战的例子：

model:
  provider: deepseek
  default: deepseek-v4-pro

fallback_providers:
  - provider: zai
    model: glm-5.2
  - provider: kimi-coding
    model: kimi-k2.7-code

这套的意思是：

  1. 平时先用 deepseek-v4-pro
  2. DeepSeek 出问题，切到 GLM 5.2
  3. GLM 5.2 也接不住，再切到 Kimi K2.7

模型名要按你实际接入渠道调整。最稳的方法是：以你在 hermes model、provider 控制台或模型列表里看到的 ID 为准。

这套配置适合长任务：整理一批资料、后台跑 30 分钟任务、代码库分析。主模型临时抽风时，它能继续往下走，而不用你半路手动接盘。

五、第三层：辅助模型也要兜底，别只盯聊天模型

很多朋友配置兜底时，只盯着主聊天模型。但 Hermes 做事的时候，旁边还有很多“辅助任务”。比如：

  • 图片分析
  • 网页提取
  • 上下文压缩
  • 会话标题生成
  • Skill 搜索
  • MCP 辅助操作
  • 命令审批判断

如果这些辅助模型没有兜底，也可能拖垮整轮任务。你可以给某些辅助任务单独配置：

auxiliary:
  compression:
    provider: zai
    model: glm-5.2
    fallback_chain:
      - provider: kimi-coding
        model: kimi-k2.7-code
      - provider: deepseek
        model: deepseek-v4-pro

  web_extract:
    provider: kimi-coding
    model: kimi-k2.7-code
    fallback_chain:
      - provider: zai
        model: glm-5.2

这段配置的意思是：

  • 上下文压缩先用 GLM 5.2，不行再换 Kimi K2.7，最后回到 DeepSeek
  • 网页提取先用 Kimi K2.7，不行再换 GLM 5.2

辅助任务讲究稳定、便宜、速度合适。你可以把最强模型留给主任务，把便宜快速的模型给网页提取、压缩和标题生成。但如果你的任务很关键，比如合同分析、代码库长上下文整理、客户资料归纳，那给辅助任务也安排一层兜底，就很有必要。

六、想快点切备用模型，可以调重试次数

Hermes 默认会先重试几次，再触发 fallback。这个设计很合理：有些 429 或网络错误只是短暂抖动，等几秒就好了。直接切模型，可能会增加成本，也可能改变回答风格。

但如果你经常遇到某个 provider 长时间不稳定，想让 Hermes 更快切到备用模型，可以调这个参数：

agent:
  api_max_retries: 1

更激进一点：

agent:
  api_max_retries: 0

建议：

  • 日常聊天：保持默认
  • 长任务：可以改成 1
  • 无人值守 Cron：可以考虑 0 或 1
  • 成本敏感任务：不要太激进，因为每次切 provider 都可能让缓存失效

这个参数不是越小越好。更稳的做法是：对重要长任务降低重试次数；对普通任务保留默认。

七、一套适合长任务的兜底方案

给一个经常跑 Hermes 长任务的环境，可以这样设计：

  • 主模型：deepseek-v4-pro，主打长上下文和综合能力
  • 第一备用：glm-5.2，适合长任务、代码、推理和复杂工作流
  • 第二备用：kimi-k2.7-code，放在需要继续写代码、理解项目、处理长材料时兜底

示例配置：

model:
  provider: deepseek
  default: deepseek-v4-pro

fallback_providers:
  - provider: zai
    model: glm-5.2
  - provider: kimi-coding
    model: kimi-k2.7-code

credential_pool_strategies:
  deepseek: round_robin
  zai: fill_first
  kimi-coding: fill_first

agent:
  api_max_retries: 1

auxiliary:
  compression:
    provider: zai
    model: glm-5.2
    fallback_chain:
      - provider: kimi-coding
        model: kimi-k2.7-code
      - provider: deepseek
        model: deepseek-v4-pro

  web_extract:
    provider: kimi-coding
    model: kimi-k2.7-code
    fallback_chain:
      - provider: zai
        model: glm-5.2

  title_generation:
    provider: deepseek
    model: deepseek-v4-pro

保存以后，重启 Gateway：

hermes gateway restart

再检查一下配置：

hermes config check

如果你不想手写 YAML，可以先走交互式：

hermes model
hermes fallback
hermes auth list

建议：刚接触的朋友先别一次性把所有模型都配上。可以分三步来：

  1. 先加第二把主 provider Key
  2. 再加一个 fallback provider
  3. 最后再给 compression 和 web_extract 配辅助兜底

这样更容易排查问题。

八、哪些任务最该配这 3 层兜底

并非所有任务都需要这么复杂。如果你只是问几句普通问题，完全没必要搞三层兜底。但下面这些场景，建议尽早配：

  • Hermes Cron 定时任务
  • 资料整理类长任务
  • 代码库分析任务
  • 多网页搜索和提取
  • 长上下文压缩频繁的任务
  • 客户项目相关任务
  • 无人值守的后台流程

最典型的是 Cron。比如你让 Hermes 每天早上整理 AI 新闻，或者每小时检查一个网站变化。它执行的时候你不在电脑旁边，如果模型额度刚好用完，任务就会失败。配置了凭据池和 fallback，至少能多一条路。

还有代码库分析。Hermes 读完一堆文件，已经构建出项目上下文。此时模型挂掉，重新来一遍会很浪费。fallback 能让它在当前上下文里继续走下去。

干货提炼

这篇可以记住一句话：Hermes 跑长任务，模型兜底要提前配，别等崩了再救。

最实用的 3 层是：

  1. Credential Pools：同一个 provider 准备多把 Key，遇到限流或额度问题自动轮换。
  2. Fallback Providers：主模型失败后，自动切到备用 provider 和备用模型。
  3. Auxiliary Fallback：网页提取、图片分析、上下文压缩等辅助任务，也给它准备备用路线。

一个比较稳的模型组合可以是：

  • 主模型：deepseek-v4-pro
  • 第一备用：glm-5.2
  • 第二备用：kimi-k2.7-code

关键命令：

hermes auth list
hermes auth add deepseek --api-key sk-your-second-deepseek-key
hermes fallback
hermes config check
hermes gateway restart

最后提醒：fallback 的目标是让任务不断，代价可能是缓存失效、成本上升、回答风格略有变化。所以它适合重要长任务、定时任务、无人值守任务。普通聊天不用折腾太多；真要让 Hermes 干活，就别只靠一个模型硬扛。