エージェントメモリプロバイダー比較：キャプチャポリシーとセルフホスティング

2026年9月更新: MnemosyneとMemoriを追加し、HonchoとHindsightの設定を拡充するとともに、元のインフラストラクチャ表に加え、キャプチャポリシー比較表を追加しました。

モダンなアシスタントは、タブを閉じるとすべてを忘れてしまいます。コンテキストウィンドウを超えるものがある場合を除いてです。**Agent memory providers（エージェントメモリプロバイダー）**とは、セッション間で事実や要約を保持するサービスまたはライブラリです。通常、プラグインとして組み込まれることで、フレームワークはスリムなままメモリを拡張できます。

本ガイドでは、Hermes Agentの外部メモリプラグインとして提供されるメモリバックエンド（Honcho、OpenViking、Mem0、Hindsight、Holographic、RetainDB、ByteRover、Supermemory、Mnemosyne、Memori）を比較し、それらがより広い**AIシステムスタックにどのように組み込まれるかを説明します。これらのベンダーは、コミュニティまたは公式の統合を通じて、OpenClawやその他のエージェントツールでも見られます。AIシステムのメモリハブ**では、この記事がCogneeおよび関連ガイドと共に一覧化されています。

Hermes固有のバウンドされたコアメモリ（MEMORY.mdとUSER.md）、フリーズ動作、トリガーについては、**Hermes Agent Memory System**を参照してください。プロバイダーの配線は、より広いエージェント知識階層の1つのレイヤーにすぎません。アイデンティティファイル、常駐メモリ、スキル、ウィキ、メモリバンクなど、それぞれに独自の注入トリガーがあり、これらは Tiered Context: AIエージェントのための知識階層 でマッピングされています。HermesのネイティブメモリプロバイダーがOpenClawとの採用面での優位性の拡大にどう貢献しているかの文脈（GitHubスター数、OpenRouterトークンランキング、エコシステム規模の比較を含む）については、 OpenClaw vs Hermes Agent: スター数、ダウンロード量、利用状況 2026 を参照してください。

リコール品質と同じくらい重要なもう1つの軸があります。それは **memory governance（メモリガバナンス）**です。プロバイダーによって、自動的にキャプットされる内容、アシスタント生成の結果が永続メモリになり得るか、省察が事実として保存されるか、矛盾がどのように解決されるか、人間が書き込みが将来のコンテキストになる前にレビューできるかなどで大きく異なります。長期稼働エージェントにとって、これらの違いは、リコールベンチマークで数ポイント上がる以上に重要になり得ます — なぜ自動キャプチャが生成された結論を将来の前提に変え得るかの説明は AIエージェントにおける自己強化型メモリループ を、保守的な設定の具体例については Mnemosyne for Hermes Agent: ローカルメモリクイックスタート を参照してください。

Hermes Agentは、永続的なセッション横断知識のために10個の外部メモリプロバイダープラグインをリストしています — 元の8つに加え、MnemosyneとMemoriです。一度に有効化できる外部プロバイダーは1つのみです。組み込みのMEMORY.mdとUSER.mdは、それと並行して読み込まれ続けます — 置き換えではなく、加算的方式です。

外部依存性。 Holographicを除くすべての外部プロバイダーは、少なくとも1つの外部サービス呼び出しを必要とします — メモリ抽出のためのLLM、セマンティック検索用のエンベディングモデル、PostgreSQLのようなデータベースによるストレージなどです。これらの依存性は、プライバシー、コスト、メモリスタックが完全に セルフホスト できるかどうかに対して直接的な影響を与えます。Hindsight、ByteRover、Mnemosyneは最も依存性をバンドルまたは排除しています。一方、Honcho、Mem0、Supermemoryは最も多くの部品を必要とします。プロバイダーがOllamaまたはOpenAI互換のエンドポイントをサポートしている場合、LLMとエンベディングの呼び出しをローカルモデルにルーティングし、データをサードパーティのサーバーから完全に排除できます。

Hermes Agentでの有効化

以下のコマンドラインの手順は、 Hermes Agent CLI チートシート の表と一致します。

hermes memory setup   # インタラクティブピッカーと設定
hermes memory status  # アクティブなものを確認
hermes memory off     # 外部プロバイダーを無効化

または ~/.hermes/config.yaml で手動設定:

memory:
  provider: openviking  # または honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory, mnemosyne, memori

プロバイダー比較

キャプチャポリシーとガバナンス

ストレージと依存性は「これで動きますか？」という質問に答えます。以下の表は、長期稼働エージェントにとって同様に重要でありがちな別の質問に答えます。それは、求められていなくても何が書き込まれるのか、そしてそれが永続化する前に人間やポリシーが介入できるのかどうかです。この軸がなぜ重要なのかは AIエージェントにおける自己強化型メモリループ を参照してください。

これらはアーキテクチャ上のリスクカテゴリであり、品質スコアではありません — 丁寧に設定された高度なプロバイダーは、悪く設定されたシンプルなプロバイダーよりも実際により安全になり得ます。

詳細な解説

Honcho

最適対象: マルチエージェントシステム、セッション横断コンテキスト、ユーザーとエージェントの合意。

Honchoは既存のメモリと並行して動作します — USER.mdはそのまま残り、Honchoがコンテキストの追加レイヤーを加えます。それは会話を使用者とエージェントがメッセージを交換するピアとしてモデル化します — 1つのユーザーピアに加え、各Hermesプロファイルごとに1つのAIピア、すべてがワークスペースを共有します。

外部依存性: Honchoには、セッションの要約、ユーザー表現の導出、弁証的推論のためのLLMが必要であり、観察間のセマンティック検索のためのエンベディングモデル、ベクトルストレージのためのpgvector拡張機能付きPostgreSQL、およびキャッシングのためのRedisが必要です。マネージドクラウド api.honcho.dev はこれらすべてを処理してくれます。セルフホストデプロイ（Docker、K3s、またはFly.io）では、独自の認証情報を用意する必要があります。LLMスロットはOllamaやvLLMを含む、すべてのOpenAI互換エンドポイントを受け入れるため、推論をオンプレミスのままにできます。エンベディングスロットは openai/text-embedding-3-small がデフォルトですが、LLM_EMBEDDING_API_KEY と LLM_EMBEDDING_BASE_URL を介した設定可能なプロバイダーをサポートします — OpenAI互換のエンベディングサーバー（BGEモデル付きのvLLMなどのローカルオプションを含む）はすべて機能します。

ツール: honcho_profile (ピアカードの読み取り/更新)、honcho_search (セマンティック検索)、honcho_context (セッションコンテキスト — 要約、表現、カード、メッセージ)、honcho_reasoning (LLMによる統合)、honcho_conclude (結論の作成/削除)。

主要な設定ノブ:

• contextCadence (デフォルト 1): ベースレイヤーの更新間の最小ターン数
• dialecticCadence (デフォルト 2): peer.chat() LLM呼び出し間の最小ターン数 (推奨1-5)
• dialecticDepth (デフォルト 1): 呼び出しあたりの .chat() 実行パス数 (1-3でクランプ)
• recallMode (デフォルト ‘hybrid’): hybrid (自動+ツール)、context (注入のみ)、tools (ツールのみ)
• writeFrequency (デフォルト ‘async’): フラッシュタイミング: async、turn、session、または整数N
• observationMode (デフォルト ‘directional’): directional (すべてオン) または unified (共有プール)

観察モードと自己モデリング。 デフォルトの directional では、ユーザーおよびAIピアはそれぞれ自身と相手を観察できます — よりリッチな弁証的推論が可能ですが、AIが作成したメッセージがAI自身のHoncho上のモデルに貢献することにもなります。unified はより保守的なオプションです: AIはユーザーメッセージからユーザーをモデル化しますが、自身の出力からの対応する自己観察ループを構築しません。生成された結論が将来の推論にフィードバックされることに特に懸念を抱いている方 — AIエージェントにおける自己強化型メモリループ を参照 — には、unified をより安全なデフォルトとして扱うことをお勧めします。

アーキテクチャ: 2レイヤーのコンテキスト注入 — ベースレイヤー (セッション要約 + 表現 + ピアカード) + 弁証的補足 (LLM推論)。コールドスタートとウォームプロンプトを自動選択します。

マルチピアマッピング: ワークスペースは、プロファイル横断の共有環境です。ユーザーピア (peerName) はグローバルな人間のアイデンティティです。AIピア (aiPeer) は、Hermesプロファイルごとに1つ (hermes がデフォルト、他は hermes.<profile>) です。

セットアップ:

hermes memory setup  # "honcho" を選択
# またはレガシー: hermes honcho setup

設定: $HERMES_HOME/honcho.json (プロファイルローカル) または ~/.honcho/config.json (グローバル)。

プロファイル管理:

hermes profile create coder --clone  # 共有ワークスペース付きの hermes.coder を作成
hermes honcho sync                   # 既存プロファイルのAIピアをバックフィル

OpenViking

最適対象: 構造化ブラウジングによるセルフホスト型知識管理。

OpenVikingは、ティアードローディングを持つファイルシステム階層を提供します。無料、 セルフホスト、そしてメモリストレージに対する完全なコントロールを与えてくれます。

外部依存性: OpenVikingは、セマンティック処理とメモリ抽出のためのVLM（ビジョン言語モデル）と、ベクトル検索のためのエンベディングモデルを必要とします — 両方とも必須です。サポートされるVLMプロバイダーにはOpenAI、Anthropic、DeepSeek、Gemini、Moonshot、vLLM（ローカルデプロイ向け）が含まれます。エンベディングについては、サポートされるプロバイダーにはOpenAI、Volcengine (Doubao)、Jina、Voyage、およびOllama経由のローカル提供エンベディングモデルが含まれます。openviking-server init インタラクティブウィザードは、利用可能なRAMを検出し、適切なOllamaモデルを推奨し（例: エンベディング用にQwen3-Embedding 8B、VLM用にGemma 4 27B）、ゼロAPIキーの完全にローカルな設定をすべて自動的に構成します。外部データベースは不要で、OpenVikingはメモリをファイルシステムに保存します。

ツール: viking_search、viking_read (ティアード)、viking_browse、viking_remember、viking_add_resource。

ユーザーメモリとエージェントメモリ。 OpenVikingのアイデンティティモデルは、ユーザーのメモリネームスペースとオプションのアシスタントピアを分離できます。この分離はメモリ衛生にとって重要です: ユーザーに関する事実とエージェントが生成した経験は、同じ保持ポリシーを共有する必要はなく、アシスタント作成の状態とユーザー作成の状態を分離したい場合に有用な特性です。

セットアップ:

pip install openviking
openviking-server init   # インタラクティブウィザード (ローカル設定用にOllamaモデルを推奨)
openviking-server
hermes memory setup  # "openviking" を選択
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

最適対象: 自動抽出によるハンズフリーメモリ管理。

Mem0は、すべての add 操作でLLM呼び出しを介してサーバーサイドでメモリ抽出を処理します — 会話を読み取り、離散的な事実を抽出し、重複を除去し、保存します。マネージドクラウドAPIがすべてのインフラストラクチャを処理します。オープンソースライブラリとセルフホストサーバーが完全なコントロールを与えてくれます。

外部依存性: Mem0は、メモリ抽出のためのLLM（デフォルト: OpenAI gpt-4.1-nano; Ollama、vLLM、LM Studioなどを含む20のプロバイダーをサポート）と、検索のためのエンベディングモデル（デフォルト: OpenAI text-embedding-3-small; OllamaとHuggingFaceなどを含む10のプロバイダーをサポート）を必要とします。ストレージには、ライブラリモードでは /tmp/qdrant のQdrant、セルフホストサーバーモードではpgvector付きPostgreSQLが使用されます — 両方ともローカルで実行できます。完全にローカルで、クラウドゼロのMem0スタックは実現可能です: LLM用にOllama、エンベディング用にOllama、ローカルQdrantインスタンス、すべてを Memory.from_config 経由で設定します。

Mem0は本質的に抽出システムです: LLMが会話素材を離散的なメモリに変換し、重複除去と更新ロジックを実行します。それは便利ですが、抽出の出所が重要であることを意味します — キャプチャパスが抽出実行前にフィルタリングしない限り、生成されたアシスタントの結論は、ユーザーが述べた事実と構造的に区別がつかなくなりがちです。

ツール: mem0_profile、mem0_search、mem0_conclude。

セットアップ:

pip install mem0ai
hermes memory setup  # "mem0" を選択
echo "MEM0_API_KEY=your-key" >> ~/.hermes/.env

設定: $HERMES_HOME/mem0.json (user_id: hermes-user、agent_id: hermes)。

Hindsight

最適対象: エンティティ関係を持つナレッジグラフベースのリコール。

Hindsightは、メモリのナレッジグラフを構築し、エンティティと関係を抽出します。そのユニークな reflect ツールは、メモリ横断の統合を実行します — 複数のメモリを新しいインサイトに変えます。リコールは4つの検索戦略（セマンティック、キーワード/BM25、グラフトラバース、時間的）を並列で実行し、その後、相互ランク融合を用いて結果をマージし並べ替えします。

外部依存性: Hindsightは、retain 呼び出し時の事実とエンティティ抽出、および reflect 呼び出し時の統合のためのLLMを必要とします（デフォルト: OpenAI; Anthropic、Gemini、Groq、Ollama、LM Studio、およびOpenAI互換エンドポイントをすべてサポート）。エンベディングとリランキングはデフォルトで、プロセス内のローカルモデル（SentenceTransformers; 太Docker/hindsight-all イメージはBGE + MiniLMをバンドル）ですが、他のローカルモデルや外部のOpenAI互換 / TEIエンドポイントに交換できます — 例: CPU上のQwen3-Embedding-0.6BとBGE-reranker-v2-m3。PostgreSQLは、マネージド pg0 データディレクトリ経由でバンドルされており、外部PostgreSQLインスタンスにHindsightを向けることもできます。完全にローカルな生成パスについては、HINDSIGHT_API_LLM_PROVIDER をOpenAI互換ローカルサーバー（Ollamaまたはllama.cpp）に設定してください; retain と recall は完全に機能し、reflect はツール呼び出し対応のモデルを必要とします。

ツール: hindsight_retain、hindsight_recall、hindsight_reflect (ユニークなメモリ横断統合)。

セットアップ:

hermes plugins install hindsight
hermes memory setup hindsight   # 個別のHindsight APIに対して local_external を選択

クラウドモードでは、まだ ~/.hermes/.env でAPIキーを受け入れます。セルフホストインストールは、埋め込みまたは既存のPostgreSQLに対するDocker Composeを使用します — 以下のウォークスルーを参照してください。最新 のHindsightクライアント/APIペアが必要です（プラグインドキュメントでは >= 0.4.22 と記載）。

設定: $HERMES_HOME/hindsight/config.json

• mode: cloud、local、または local_external
• recall_budget: low / mid / high
• memory_mode: hybrid / context / tools
• auto_retain / auto_recall: true (デフォルト)

ローカルUI: hindsight-embed -p hermes ui start

セルフホスト完全ウォークスルー — Docker Compose、ローカルエンベディングとリランキング、書き込み経路のコントロール (auto_retain)、およびHermes local_external 配線 — については、 Hindsight for Hermes Agent: ローカルLLMによるセルフホストメモリ を参照してください。OpenCode、Cursor CLI、その他のコーディングハーネスは、リポジトリごとにバンクを持つ別のパッケージを使用します: Hindsight Memory for OpenCode, Cursor, and Other Coding Agents。

保守的なメモリ衛生のために、auto_retain=false に設定しつつ auto_recall=true を残すことは考慮する価値があります — セマンティックリコールは利用可能のままですが、完了したターンはもはや自動的に長期メモリに入らなくなります。 reflect の出力は、メモリから統合された導出的知識として扱うべきであり、それが構築されたメモリと同じ証拠的権重を持つ独立した観察ではありません。

Holographic

最適対象: ローカルストレージのみのプライバシー重視セットアップ。

Holographicは、メモリエンコーディングのためにHRR（Holographic Reduced Representation）代数を使用し、メモリの信頼性のために信頼スコアリングを行います。クラウド依存性なし — すべてが独自のハードウェア上でローカルに実行されます。

外部依存性: なし。HolographicにはLLM、エンベディングモデル、データベース、ネットワーク接続のいずれも不要です。メモリエンコーディングは、プロセス内で実行されるHRR代数を通じて完全に完了します。これは本比較のプロバイダーすべての中でユニークであり、ゼロの外部呼び出しで動作する唯一のプロバイダーです。トレードオフは、エンベディングベースのセマンティック検索よりもリコール品質が低いこと、そしてHindsightの reflect のようなメモリ横断統合が存在しないことです。プライバシーとゼロ依存性動作が譲歩不可能なユーザーにとって、Holographicはそのことを無条件に実現する唯一の選択肢です。

auto_extract はデフォルトで false であるため、Holographicは自律的なトランスクリプトからメモリへのパイプラインとしてではなく、信頼スコアを持つ小さな明示的事実データベースとして主に動作できます。ゼロ依存性と組み合わせることで、それは自動キャプチャを意図的に望まない読者にとって、Mnemosyneと並ぶ2つの最もシンプルな選択肢の1つになります。

ツール: HRR代数によるメモリ操作のための2つのツール。

セットアップ:

hermes memory setup  # "holographic" を選択

RetainDB

最適対象: デルタ圧縮による高頻度更新。

RetainDBは、メモリ更新を効率的にストレージするためにデルタ圧縮を使用し、関連コンテキストを表面化するためにハイブリッド検索（ベクトル + BM25 + リランキング）を使用します。$20/月のコストを持つクラウドベースであり、すべてのメモリ処理がサーバーサイドで処理されます。

外部依存性: RetainDBのLLM呼び出し、エンベディングパイプライン、リランキングはすべてRetainDB自身のクラウドインフラストラクチャで実行されます — 提供するのは RETAINDB_KEY のみです。メモリ抽出はサーバーサイドでClaude Sonnetを使用します。セルフホスティングオプションは存在せず、ローカルモードもありません。すべての会話データは処理とストレージのためにRetainDBサーバーに送信されます。データ主権性やオフライン動作があなたのユースケースにおいて重要であれば、このプロバイダーは適していません。

ツール: retaindb_profile (ユーザープロファイル)、retaindb_search (セマンティック検索)、retaindb_context (タスク関連コンテキスト)、retaindb_remember (タイプ+重要性を付けてストレージ)、retaindb_forget (メモリの削除)。

RetainDBのHermes統合は、リモートメモリデータベースを超えて成長しました — いまや弁証的統合とエージェント自己モデルを含んでおり、アーキテクチャ的には単純なベクトルストアよりもHonchoに近い位置にあります。それは連続性のために有用ですが、ソース事実と生成された解釈を分離することの重要性も高めます — Honchoの directional モードに適用的な同じ懸念です。

セットアップ:

hermes memory setup  # "retaindb" を選択

Mnemosyne

最適対象: 細粒度な保持コントロール、検査可能なSQLiteストレージ、構造化事実、時間的メモリ、設定可能な統合を持つローカルファーストメモリ。

MnemosyneはHermesの元バンドルメモリプロバイダーの1つではありません — 個別のHermesプロバイダープラグインとして出荷されますが、同じ MemoryProvider インターフェースを介して統合されます。その主な利点はコントロールです: 会話のオートセーブはロールで制限するか sync_roles: [] で完全に無効化でき、ツール結果のロギングはデフォルトでオフ、明示的なremember/recall/forget操作は常に利用可能、新しいバージョンではコンテキスト圧縮境界周りのオプションな自己エコー抑制を含みます。

外部依存性: core インストールでは不要; embeddings エクストラはローカルベクトル検索を追加します。ストレージは、FTS5とオプションのベクトル検索付きのローカルSQLiteです。システムはまた、ワーキングメモリ、エピソードメモリ、構造化事実、時間的トリプル、正準事実、統合を維持します。

Mnemosyneはまた、Hermes memory.write_approval に対するプロバイダー固有の段階的書き込みを実装していますが、Hermes全体での外部プロバイダー承認はまだ標準化されていないため、このパスはデプロイされる正確なバージョンに対してテストする必要があります。追加の洗練にはコストがあります: 導出的メモリは、検査とクリーンアップすべきライフサイクル状態をより多く作成します。最近のMnemosyneリリースは、競合検証、削除動作、自己エコー処理を特に引き締めています — 競合検証変更の動機となった本番監査については AIエージェントにおける自己強化型メモリループ を参照してください。

セットアップ:

python -m pip install "mnemosyne-memory[embeddings]" mnemosyne-hermes
mnemosyne-hermes install
hermes config set memory.provider mnemosyne

完全なインストールと保守的な設定ウォークスルーについては、 Mnemosyne for Hermes Agent: ローカルメモリクイックスタート を参照してください。

Memori

最適対象: 会話履歴と同様に実行履歴が重要なエージェント。

Memoriは、ツール認識型構造化メモリに焦点を当てた新しいHermes統合です。それは、完了したターンと一緒に、利用可能な実行コンテキスト（ツール使用、ワークフローステップ、決定、結果、制約）をキャプチャします — 運用作業の記憶には非常に優れていますが、アクション、モデル決定、ツール結果がいずれも永続的な構造化メモリになり得るため、より大きなフィードバック面も作成します。

ほとんどのプロバイダーが各ターン前に大きなメモリブロックを注入するのとは異なり、Memoriは明示的なリコールとリコール要約ツールを公開し、エージェントが実際に必要なときに運用コンテキストを取得できるようにします（全プロンプトでではなく）。それはプロンプト汚染を軽減しますが、それだけで書き込み側のフィードバックリスクを除去するわけではありません — 完了したターンと実行トレースはバックグラウンドで自動的にキャプチャされ続けるため、Memoriはエージェントが以前の作業から学ぶことを望むユーザーに適していますが、厳密な明示的専用保持を要求するインストールには適していません。

セットアップ:

pip install hermes-memori
hermes memory setup  # "memori" を選択

ByteRover

最適対象: 人間が読め、監査可能なストレージを持つローカルファーストメモリ。

ByteRoverは、エンベディングベクトルやデータベースではなく、構造化されたマークダウンコンテキストツリー（ドメイン、トピック、サブトピックファイルの階層）としてメモリをストレージします。LLMがソースコンテンツを読み取り、それについて推論し、抽出された知識を階層内の正しい場所に配置します。検索は、MiniSearch全文検索とLLM駆動検索へのティアードフォールバックであり、ベクトルデータベースは不要です。

外部依存性: ByteRoverは、メモリキュレーションと検索のためのLLMを必要とします（Anthropic、OpenAI、Google、Ollama、および openai-compatible プロバイダースロット経由のOpenAI互換エンドポイントなどを含む18のプロバイダーをサポート）。エンベディングモデルもデータベースも不要です — コンテキストツリーはプレーンマークダウンファイルのローカルディレクトリです。クラウド同期はオプションであり、チームコラボレーションのためだけに使用されます; デフォルトでは完全にオフラインで動作します。完全に自己完結的なローカルセットアップについては、Ollamaをプロバイダーとして接続し (brv providers connect openai-compatible --base-url http://localhost:11434/v1)、データがあなたのマシンを離れないようにします。

Hermesは auto_extract: false を公開して自動キュレーションフックを無効化できるため、ByteRoverは、自動キャプチャがデフォルトではなくオプトインであるプロバイダーのグループ（HolographicとMnemosyne）に近くなります。

ツール: メモリ操作のための3つのツール。

セットアップ:

hermes memory setup  # "byterover" を選択

Supermemory

最適対象: コンテキストフェンシングとセッショングラフ取り込みによるエンタープライズワークフロー。

Supermemoryは、コンテキストフェンシング（コンテキストによるメモリ分離）とセッショングラフ取り込み（会話履歴全体のインポート）を提供します。自動的にメモリを抽出し、ユーザープロファイルを構築し、セマンティック検索とキーワード検索を組み合わせたハイブリッド検索を実行します。マネージドクラウドAPIがプライマリデプロイターゲットです。

外部依存性: Supermemoryのクラウドサービスは、すべてのLLM推論とエンベディングをサーバーサイドで処理します — 提供するのはSupermemory APIキーのみです。セルフホスティングは、エンタープライズプランのアドンとしてのみ利用可能で、Cloudflare Workersにデプロイします; pgvector拡張機能付きPostgreSQL（ベクトルストレージ用）とOpenAI APIキー（必須、AnthropicとGeminiはオプションの追加）を提供する必要があります。Dockerベースやローカルセルフホスティングパスはありません — アーキテクチャはCloudflare Workersエッジコンピューティングに密接に結合しています。エンタープライズ契約なしで完全なデータ主権性を必要とするユーザーにとって、このプロバイダーは適切な選択ではありません。

現在のHermes統合は、Supermemoryの会話エンドポイントを通じて完全なセッションを単位として書き込み、会話をバッファリングし、セッション終了、リセット、または圧縮時に取り込みます。それは、孤立した事実書き込みよりも豊かなエンティティとプロファイルコンテキストを生み出しますが、それと同時に、生成されたアシスタントテキストはユーザー発言だけでなく、メモリ抽出パイプラインに提示される素材の一部を形成することを意味します。

ツール: メモリ操作のための4つのツール。

セットアップ:

hermes memory setup  # "supermemory" を選択

選び方

1つのグローバルな勝利者を選ぶのではなく、プロバイダーをタスクに合わせます:

• 最もシンプルなローカル明示メモリ: Holographic — ゼロ依存性、auto_extract がデフォルトでオフ
• よりリッチなライフサイクルコントロールを持つローカルメモリ: Mnemosyne — SQLite、細粒度な保持、自己エコー抑制
• グラフ重量型統合: Hindsight — ナレッジグラフに reflect を加える
• ピアまたはユーザーモデリング: Honcho — 弁証的推論、保守的自己モデリングのための unified モード
• ファイルシステム様知識: OpenViking — ティアード viking:// 階層
• ハンズフリー自動抽出: Mem0 — ゼロ設定LLMベース事実抽出
• 運用/ツール認識メモリ: Memori — ターンと実行トレースキャプチャ
• 人間が読め、監査可能、エンベディングパイプラインなし: ByteRover — プレーンマークダウンコンテキストツリー
• エンタープライズコンテキストフェンシング: Supermemory — セッショングラフ取り込み、Cloudflareホスト
• 高頻度更新、セルフホスティング不要: RetainDB — デルタ圧縮、弁証的自己モデル

プロファイルごとのプロバイダー設定と実世界のワークフローパターンについては、 Hermes Agent production setup を参照してください。

より広いサードパーティHermesメモリエコシステム

Hermesは、外部メモリプロバイダーのためのパッケージ/プラグインインターフェース（ユーザーインストールディレクトリとPythonエントリポイントを含む）を文書化しているため、エコシステムは上記で完全なセクションを持つプロバイダーを超えて拡張されています。完全なセクションを追加せずに知っておく価値があるものがいくつかあります:

• Scope Recall は、生の会話キャプチャを個別のスコープに保ちつつ、SQLiteを永続的な真理として扱います — 保守的なターン後レビューのためのオプションの turn-closure-audit 同伴プログラムがあり、キャプチャされた各ターンをすぐに等価な長期知識として扱うのではなく、生のジャーナル証拠と永続的なセマンティックメモリを分離します。
• Cognee は、Hermes会話メモリプラグインではなく、ナレッジグラフ / ECL取り込みパイプラインです。構造化されたプロジェクトまたは機関メモリに優れていますが、明示的事実ストアよりも自動的です; Hermesプロバイダーとしてドロップインで扱うのではなく、 Self-Hosting Cognee quickstart と Cognee用の適切なLLMの選択 を参照してください。
• AgentMemory は、ソースイベント、監査可能性、削除セマンティクスを強調します — 上記でMnemosyneについて議論された孤立導出的記録の問題の後に関連があります。
• XMemo は、保守的なデフォルトを提供します: 自動タイムラインキャプチャはオフのままにでき、削除は制約可能です。採用はまだ早期段階であり、完全なセクションはまだ不要です。

関連ガイド

• AIシステムのメモリハブ — このサブクラスターのスコープとCogneeガイドへのリンク
• AIエージェントにおける自己強化型メモリループ — キャプチャポリシーと承認ゲートがなぜ重要かを詳しく
• Mnemosyne for Hermes Agent: ローカルメモリクイックスタート — 上記でカバーされたMnemosyneプロバイダーの完全なインストールと保守的な設定
• Hermes Agent Memory System — プラグイン前のコア2ファイルメモリ
• Hermes Agent production setup — 実務でのプロバイダーのプロファイル配線