Hermes Agent、プロバイダー切り替え時に旧エンドポイントへ送信される問題を修正

Hermes Agent は10月16日、修正 #139613 を main にマージし、ローカルでセッションを作成する際にプロバイダーのルーティング設定が混在する問題に対処した。リクエストで新しい provider を指定し、base_url を指定しない場合、設定ファイル内の古いエンドポイントが残る一方、新しいプロバイダーの認証情報が使われ、使えるAPIキーが別のサービスに送られる可能性があった。これは表面上は認証失敗として現れるが、認証情報の送信先境界にも関わる問題だ。マージ記録

10月15日の最初の報告では、DeepSeek から Xiaomi に切り替えるケースが示された。セッションでは Xiaomi のモデルが選択されていたにもかかわらず、リクエストは DeepSeek に送られ、HTTP 401 が返された。議論では、ほかのプロバイダーの組み合わせでも再現したとの報告があった。また、エラー応答を受けて認証情報プールが有効なキーを枯渇扱いにし、タイトル生成などの補助呼び出しまで妨げる可能性も指摘された。そのため、キーを交換しても問題が解決するとは限らない。問題と再現情報

公式ドキュメントによると、ランタイムリゾルバーはプロバイダー、プロトコルモード、エンドポイント、キーを一元的に決定し、チャット、ゲートウェイ、スケジュール実行などの経路に提供する。また、認証情報はそれぞれ対応するエンドポイントに紐付けるべきだとしている。エンジニアリング上、今回の事例は、下流でリゾルバーを共通化していても、上流の設定マージ処理でプロバイダーとURLを別々に更新すると、整合しないルーティング設定ができることを示している。ランタイムプロバイダーの解決に関するドキュメント

新しい修正では、解決後のルーティングIDを比較する。実際にプロバイダーを切り替える場合は、古いエンドポイント、プロトコル、認証情報の設定をいったん消去してから、明示的に渡された上書き値を適用する。同じルートを指す別名の場合は設定を維持し、vllm と custom のような名称の違いだけでローカルエンドポイントが誤って削除されないようにする。レビュー担当者は実際のゲートウェイと2つのローカルモデルサーバーでリクエストを観察し、修正後にキーが想定したホストへ送られることを確認した。このテストは管理された環境での検証であり、すべてのデプロイ環境を網羅するものではない。修正と検証

デプロイ担当者は、利用するリリース版にこのマージが含まれているか確認し、新規セッションと既存セッションのそれぞれで実際のルーティングを検証する必要がある。公式のアーキテクチャドキュメントは期待される動作を説明するもので、今回の不具合を独立に検証したものではない。また、公開情報からは、誤送信されたキーが悪用されたとは確認されていない。