Hermes Agent 合併供應商切換修補，避免 API 金鑰送往舊端點

Hermes Agent 於 10 月 16 日將修補 #139613 合併至 main，處理本機建立工作階段時的供應商路由混用。當請求指定新的 provider、未指定 base_url，系統可能保留設定檔中的舊端點，卻取用新供應商的憑證，將有效金鑰送往另一家服務。這使表面上的驗證失敗，同時涉及憑證傳送邊界。合併紀錄

10 月 15 日的原始回報以 DeepSeek 切換至 Xiaomi 為例：工作階段已選用 Xiaomi 模型，請求卻仍送至 DeepSeek，得到 HTTP 401。討論中也有其他供應商組合的重現。回報指出，錯誤回應還可能使憑證池將有效金鑰標記為耗盡，連帶阻止標題生成等輔助呼叫；因此，更換金鑰未必能解決問題。問題與重現資料

官方文件說明，執行期解析器會統一產生供應商、協定模式、端點與金鑰，供聊天、閘道及排程等路徑使用，並強調憑證應對應各自端點。從工程角度看，這次事件顯示：即使下游共用解析器，上游設定合併若分別更新供應商與網址，仍可能組出互相矛盾的路由。執行期解析文件

新修補會比較解析後的路由身分；真正切換供應商時，先清除舊端點、協定與憑證設定，再套用明確傳入的覆寫值。同一路由的別名則保留設定，避免 vllm 與 custom 等名稱差異誤刪本機端點。審查者以實際閘道與兩個本機模型伺服器觀察請求，確認修補後的金鑰送至預期主機；這是受控測試，不能代表所有部署情境。修補與驗證

部署者接下來應確認發行版是否包含該合併，並分別檢查新建與既有工作階段的實際路由。官方架構文件提供預期行為，並非這次缺陷的獨立驗證；目前公開資料也未證實錯送金鑰遭到濫用。