先说一个尴尬的事。我在 ~/.hermes/config.yaml 里折腾了快一小时，各种改 credential_pool_strategies、填 custom_providers、调 fallback_model，结果发现 WebUI 根本不读这个文件。Hermes 分两套配置：WebUI 模式下 HERMES_HOME 指向的是 AppData\Local\hermes\，CLI 模式下才是 ~/.hermes。如果你只用 WebUI，改 ~ 目录等于白改。这是第一个坑。
凭据池到底干了什么？ 说白了就是让你在一个配置里塞多个 API Key，系统自动按策略轮换——round_robin 轮询、random 随机、fill_first 死磕第一个。操作本身不简单，难在细节。
custom_providers 有两种写法，看你用什么方式配。CLI 手动编配是 dict 格式：
custom_providers:
blazeai:
api_key: xxxx
base_url: https://blazeai.boxu.dev/api/
但 WebUI 或 Pinokio 生成的是 list 格式：
custom_providers:
- name: blazeai
api_key: ${BLAZEAI_API_KEY}
base_url: https://blazeai.boxu.dev/api/
如果你写脚本去读这个字段，dict 可以用 get("blazeai")，list 就得遍历匹配 name。不兼容处理的话，轻则取不到 key，重则直接抛 AttributeError。
更隐蔽的是 base_url 写错。 我排查了半天才发现，WebUI 生成的 blazeai 配置里，base_url 填的是 NVIDIA 的地址——两个字段完全颠倒了。curl 一测，发现请求去了 NVIDIA 服务器却带的是 BlazeAI 的模型名，返回 400 错误。你永远得手动验证一次每个 provider 的接口通不通，别信配置生成器。
API Key 的解析路径也容易想当然。 我写了脚本去测试各 provider 的响应时间，结果死活取不到 NVIDIA 和 OpenRouter 的 key。后来发现 key 可以放在五个地方：config.yaml 里直接写、${VAR_NAME} 形式引用环境变量、.env 文件、系统环境变量、或者 auth.json 的 credential_pool。而且 config 里的 ${...} 包裹不是普通的字符串，得自己解包：去掉 ${}，拿里面的变量名去查环境变量。你以为 api_key: ${NVIDIA_API_KEY} 会自动解析？不会的，yaml 读进来就是原文，得自己处理。
OpenRouter 的模型 ID 也坑。 同样是 Llama-3.1-8B，在 NVIDIA 上写 meta/llama-3.1-8b-instruct 就行，到了 OpenRouter 就得改成 meta-llama/llama-3.1-8b-instruct——多了个 creator 前缀。直接报 400 “not a valid model ID”，排查半天。
折腾完这些，干脆写了个健康探测脚本，每 15 分钟自动测一遍三个 provider 的接口响应速度（发一条 1 token 的请求看返回时间），选最快的自动切换到 model.provider。NVIDIA 稳定在 1 秒出头，BlazeAI 4~5 秒，OpenRouter 2 秒左右。DeepSeek 只做最终的兜底——不是为了省那几毛钱，而是因为 DeepSeek 的闪回模型确实更适合做知识检索而不是日常对话主力。
脚本里最麻烦的部分其实是兼容两套配置格式、处理五种 key 来源、以及正确解包 ${}。核心逻辑反而简单：测延迟、排序、写 config。用 cronjob 的 no_agent=true 模式跑，不消耗 LLM token，输出本地保存。
最后两个提醒：验证 API key 别用 read_file 或 grep，它会给你显示 sk-or-...c889 这样的截断结果，让你以为 key 写错了。用 od -c 看原始字节才踏实。还有，fallback_model 不要自己写 base_url 和 key_env，直接指向 custom_providers 里已经定义好的 provider 名字就行，省事也干净。
这次配完，总算可以不用操心哪个 provider 挂了、哪个响应慢了——机器自己盯着，15 分钟一报，稳了。