去年夏天，我一個月裡開了五家 LLM 服務商的帳號。OpenAI、Anthropic、OpenRouter、Fireworks、Together。到十月份，我已經分不清哪張信用卡在給誰家扣錢了。到十二月，其中一家悄悄改了價格，我三個禮拜後收到帳單才發現。
說白了，2026 年在 LLM 上做事的現實就是：服務商動物園是個長期現象。每個禮拜都有新模型出來，價格隨時會動，免費額度說重排就重排。三月還是最強模型的東西，五月就變成注腳了。如果你的 agent 框架在裝的時候就替你把服務商定死了，那你等於簽了一份每隔幾個月重搭一次的合約。
Hermes Agent 從第一天起就往相反方向押注：服務商是一個 config 值，而不是架構替你做的選擇。三層特性疊在一起，才真正讓這件事跑得通。
中央路由器（v0.2.0）
底層是一個唯一的呼叫入口。v0.2.0 上線時，專案引入了一個集中式服務商路由器——一個 call_llm() / async_call_llm() 函式，agent 裡每一處呼叫 LLM 的地方都從這裡走。視覺、摘要、壓縮、軌跡存檔、主聊天迴圈，全部走同一條程式碼路徑。
聽起來像個重構層面的小細節，直到你在一個沒做過這件事的 agent 裡試著換服務商，你才會明白差別。大多數框架裡，真正呼叫 LLM 的地方散在十一個位置，每處讀憑證的方式都略有不同。你改了一個，忘了另一個，出問題的方式還隱蔽到不容易被察覺。Hermes 的做法是讓所有呼叫只有一個地方，這類問題就從根上消失了。
備援鏈（v0.6.0）
兩週後，v0.6.0 疊上第二層：有序的備援服務商鏈。你在 config.yaml 裡按順序列出服務商，主用的那家一遇到錯誤——429 限速、短暫的 500、連不上的端點——Hermes 會自動切到鏈上的下一家。
重點是：它是有序的，不是輪詢。你自己決定首選和備胎。常見的設法是把 OpenRouter 當作便宜的預設檔，Anthropic 直連當作穩的備援，Nous Portal 的免費額度當作最後的保命檔。鏈頂的那家今天不舒服，你這邊是感覺不到的。v0.6.0 順手修了一個隱蔽的 bug：之前用 hermes model 切服務商時會把 api_mode 寫死成 chat_completions，現在改成在切換時清掉舊值，所以 Anthropic 相容端點在切完之後不會再莫名其妙地回傳 404 了。
憑證池（v0.7.0）
v0.7.0 那一版的主題是韌性，它又疊上了第三層：同一家服務商內部的憑證池。關鍵認知是：「我用的主服務商」和「我在那家服務商下具體用的那把 API key」是兩件不同的事。你可能手裡有三把 Anthropic 的 key——個人的、團隊的，外加另一個帳號上備的一把——你希望 Hermes 永遠用當下最閒的那把。
你透過設定精靈或一個 credential_pool 區塊來宣告它們，Hermes 預設按 least_used 策略挑 key。如果某把 key 回傳 401，池會自動輪到下一把，並把那把死的掛上一段冷卻時間。整套實作是執行緒安全的，意思是你可以同時跑 CLI、一個 Telegram 閘道、一個 cron 任務，它們共用同一個池互不打架。v0.7.0 還確保了池的狀態能扛住備援切換——主用那家遇上 429，不會把池裡「哪把 key 已經累了」的記憶一起抹掉。
為什麼要疊成三層
三層裡每一層單獨拿出來都只解決一個窄問題。它們合起來之所以讓人覺得有力，是因為三層之間完全不重疊：
- •路由器 讓你在一個地方改 用哪家服務商。
- •備援鏈 讓你不用重啟就能處理 服務商層面的失敗。
- •憑證池 讓你在同一家服務商內部處理 key 層面的失敗和負載。
而在命令列裡，hermes model 讓你把以上任何一層都重設一遍，不用手改設定檔。最終效果是：有新模型出來時——不管是誰發的、叫什麼、怎麼定價——你要遷移的成本是「改一行設定」，而不是「把我的助手重寫一遍」。對一個要陪你跨過很多代模型的專案來說，這大概是唯一一個真正重要的架構決策。