外部メモリプロバイダ

Hermes Agent 向けのサードパーティメモリプロバイダをインストール、設定、および検証します。「インストール済み」と「Hermes 上でアクティブ」は別々の受け入れ基準として扱います。

原則

現在の公式ドキュメントから始める。 hermes-agent スキルを読み込み、プロバイダのインストールページとその完全な Hermes 統合ページの両方を取得します。文書化された推奨パスに従い、実際の互換性制約が必要な場合にのみ文書化されたフォールバックを使用します。
依存関係は Hermes の管理 venv の外に保持する。 Hermes の更新によりその venv が再構築される可能性があります。pipx または専用の永続 venv を優先します。
ブリッジ境界で Python ABI を一致させる。 pipx 環境は Hermes よりも新しい Python を使用する可能性があります。ネイティブホイールが関係する場合、その site-packages を Hermes の sys.path に追加するのは安全ではありません。ラッパーがインポートをインプロセスで実行する場合は、Hermes の Python で作成された専用 venv を使用します。
設定には Hermes CLI を使用する。 config.yaml を手動編集せず、hermes config set で設定を適用します。
共有メモリツールセットを無効にしない。 レガシーファイルメモリを置き換える場合、プロバイダ用に文書化されている組み込みのファイル/プロファイルフラグのみを無効にします。包括的な hermes tools disable memory はプロバイダツールも隠してしまう可能性があります。
プロンプトキャッシングを考慮する。 プロバイダ/ツールの変更は新しく初期化されたセッションに適用されます。既存の会話のシステムプロンプトやツールスキーマを変更せず、ゲートウェイを再起動し、実行中の TUI セッションは置き換える必要があることを明確に伝えます。

インストールワークフロー

1. 状態変更前に監査する

以下を記録します：

hermes --version および Hermes の Python バージョン/パス
プロバイダパッケージのバージョンとインストール環境
プロバイダのインストーラ/ステータス出力
hermes plugins list --plain --no-bundled
hermes config get memory.provider
hermes memory status
ゲートウェイのステータス

ベースパッケージのバージョンから [all] や同等のエクストラを推測しないでください。プロバイダのドキュメントで名前指定されているすべての機能依存関係をインポートまたは検査します。

2. 分離トポロジを選択する

プロバイダがプロセス外で通信する場合、または Hermes が安全なパッケージエントリポイントを発見する場合は、pipx を使用します。
Hermes がプロバイダコードをインプロセスでインポートし、パッケージにネイティブ拡張が含まれる場合は、Hermes の Python から構築された専用 venv を使用します。
importlib.util.find_spec() を互換性の証明として決して扱わないでください。これはネイティブコードをロードせずにモジュールを特定します。プロバイダを実行するインタプリタで実際のインポートを実行します。

3. プロバイダとブリッジをインストールする

要求された完全な機能プロファイルとその Hermes ラッパーをインストールします。ラッパーにインストーラ/ステータスコマンドが同梱されている場合は、それを使用して $HERMES_HOME/plugins/ 下に永続的なプラグインブリッジを作成し、そのインポートを確認します。

Hermes がユーザープラグインをオプトインとしてリストしている場合は、明示的に有効にします：

hermes plugins enable <manifest-name>

プロバイダの選択と一般プラグインの有効化は別々のメカニズムである可能性があります。両方を確認します。

4. 重複なく設定する

外部プロバイダを設定し、プロバイダのドキュメントで指示されている場合は、メモリツールセットを保持したままレガシーファイルメモリを無効にします：

hermes config set memory.provider <provider>
hermes config set memory.memory_enabled false
hermes config set memory.user_profile_enabled false

これらが普遍的なものであると想定せず、プロバイダの現在の文書化されたキーを使用します。

5. 再起動して検証する

インストール、有効化、および設定が完了した後にのみゲートウェイを再起動します。その後、以下を確認します：

ゲートウェイがアクティブであること。
プラグインブリッジ/ステータスがインストール済みかつインポート可能と表示されること。
フック/ツールがそれに依存する場合、一般プラグインリストが有効と表示されること。
hermes memory status が選択したプロバイダがインストール済み、利用可能、かつアクティブと表示すること。
プロバイダ診断に実際のエラー/障害レコードがないこと。カウンタ、測定値、スキップされたチェック、または未設定のオプションのオーバーライドを障害として誤って解釈しないでください。

6. Hermes エージェントパスを実行する

スタンドアロンの SDK スモークテストは必要ですが十分ではありません。Hermes 自身のメモリプロバイダローダーを通じてプロバイダをロードするか、新しい Hermes エージェントを開始し、以下を確認します：

プロバイダの構築と初期化；
プロバイダのシステムプロンプトブロックがアクティブであること；
プロバイダのツールスキーマが公開されていること；
一意のタグが付けられたテストメモリを書き込む；
その正確なタグを呼び戻す；
テストメモリを削除する；
プロバイダの DB/パスが意図した Hermes ストアであることを確認する。

アサーションを使用し、いずれかのステップが失敗した場合は検証コマンドを失敗させます。もっともらしい期待ではなく、観測された正確なバージョン/ステータスを報告します。

よくある落とし穴

別個の pipx venv はインプロセスインポートのための「共存」ではありません。 コアとラッパーはそれぞれ単独で動作しても、Hermes が両方を安全にインポートできない場合があります。
プラグインが検出されたからといって、有効化されたわけではありません。 プロバイダの検出は成功しても、フック/ツールの登録はオプトインのままである場合があります。
CLI コマンドがないことはプロバイダの障害を証明しません。 Hermes はプロバイダをロードできても、インストーラが argparse 検出に使用する兄弟の cli.py を省略している場合があります。プロバイダと CLI パスを個別に診断し、テスト済みのブリッジでのみ修復します。
ゲートウェイの再起動は現在の会話を遡及的に変更しません。 新しいゲートウェイと CLI セッションはプロバイダを使用しますが、古い TUI プロセスは凍結されたプロンプト/ツールサーフェスを保持します。
インストールコマンドの成功は完了ではありません。 読み戻し設定、アクティブプロバイダステータス、および実際の書き込み/呼び戻し/クリーンアップサイクルが必要です。

プロバイダリファレンス

Mnemosyne + Hermes 統合、Python ABI 処理、CLI ブリッジ、および決定論的スモークテスト：references/mnemosyne-hermes.md

Apartment38/Agent-Skills

Agent-Skills とは？

お気に入りのAIに質問する

ドキュメント