OpenAI、Anthropic、OpenRouter、xAIなどのAPIキーがHermes Agentに増えたら、Bitwarden Secrets Managerを検討してもよいですが、すぐにローカル~/.hermes/.envをカバーさせないようにしましょう。 v0.15.0以降、HermesはBitwardenから単一のBWS_ACCESS_TOKENで複数の認証情報を取得することをサポートし、長期使用やチームメンテナンスに適しています。
いつ引っ越す価値があるのでしょうか?
OpenRouterキーが1つしかない場合は、ローカルの.envも使えます。 複数のプロバイダーや複数のマシンを持ち、頻繁にキーを変えるなら、Bitwardenの方が明らかに安心です。 その核心的な価値は「かっこいい」ことではなく、キーローテーション後に各サーバーのファイルを手動で変更する必要がないことです。
推奨移動順序
- まず現在の
~/.hermes/.envをバックアップし、少なくとも1つはオフラインのコピーを残してください。 - Bitwardenで対応する秘密を作成し、Hermesが読み取った変数の名前に合わせます。
- まず
BWS_ACCESS_TOKENを注入し、その後ヘルメスを起動して医師の確認や出力の認証情報の出所を設定する。 - 新しいソースが利用可能であることを確認したら、同じ名前のローカル変数をBitwardenに上書きさせるかどうかを判断します。
公式ドキュメントによると、Bitwardenはデフォルトで真実のソースに近いもので、同じ名前の値がローカル環境を上書きする可能性があるとされています。 この行動は中央管理には適していますが、同時に調整しようとする初心者には向いていません。 まず上書きをオフにして、すべてが正常であることを確認してから切り替えることができます。
最も陥りやすい落とし穴
まず、トークン権限が大きすぎて、すべての環境が同じブートストラップトークンに露出してしまうこと。 次に、古いローカルキーがあるため、間違って入力するとヘルメスが実際にどのキーを使っていたのか分からなくなります。 三つ目は、チームメンバーがBitwardenに切り替え、オンラインサービスが再起動した後に突然認証情報が変更されたことです。 解決策はシンプルです:異なる環境ごとにトークンを分割し、認証情報の出所を記録し、キーを変更する前に影響を受けたゲートウェイやスケジュールされたタスクに通知します。
