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

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

タブを閉じるとすべての記憶を失う現代のAIアシスタントに対し、コンテキストウィンドウを超えて永続化する何かが必要になります。エージェントメモリプロバイダーとは、セッション間で事実や要約を保持するサービスやライブラリであり、フレームワークをスリムに保ちつつメモリをスケーリングするために、多くの場合プラグインとして組み込まれます。

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

Hermesに固有のバウンデッドコアメモリ（MEMORY.mdとUSER.md）、フリーズ動作、トリガーについては、**Hermes Agent メモリシステム**を参照してください。HermesのネイティブメモリプロバイダーがOpenClawに対する採用優位性の拡大（GitHubスター数、OpenRouterトークンランキング、エコシステム規模の比較など）にどのように貢献しているかという背景については、OpenClaw vs Hermes Agent: Stars, Downloads & Usage 2026を参照してください。

検索品質と同様に、もう一つの重要な軸があります。それはメモリガバナンスです。プロバイダーは、何が自動的にキャプチャされるか、アシスタント生成出力が永続メモリになり得るか、レフレクション（省察）が事実として保存されるか、矛盾がどのように解決されるか、人間の介入なしに書き込みが将来のコンテキストになる前にレビューできるかという点で、劇的な違いがあります。長期的に稼働するエージェントにとって、これらの違いは、リコールベンチマークでの数ポイントの差よりも重要になり得ます — 自動キャプチャが生成された結論を将来の前提に変える危険性については Self-Reinforcing Memory Loops in AI Agents を参照し、保守的な設定の具体例については Mnemosyne for Hermes Agent: Local Memory Quickstart を参照してください。

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

プロバイダー比較

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

ストレージと依存関係は「これを走らせることができるか？」という答えになります。以下の表は、長期的に稼働するエージェントにとって同じくらい重要であり、求められることなく何が書き込まれ、それが永続化される前に人間またはポリシーが介入できるか、という異なる質問に答えます。この軸がなぜ重要なのかについては Self-Reinforcing Memory Loops in AI Agents を参照してください。

これらは品質スコアではなく、アーキテクチャ的なリスクカテゴリです — 慎重に設定された洗練されたプロバイダーは、悪く設定されたシンプルなプロバイダーよりも実際には安全な場合があります。

詳細な解説

Honcho

最適な用途: マルチエージェントシステム、セッション横断コンテキスト、ユーザー-エージェントのアラインメント。

Honchoは既存のメモリと並行して動作します — USER.mdはそのまま維持され、Honchoがコンテキストの追加レイヤーを加えます。対話をメッセージを交換するピア（同格）としてモデル化します — 1つのユーザーピアと1つのAIピア（Hermesプロファイルごと）がすべてワークスペースを共有します。

外部依存関係: 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 経由で設定可能なプロバイダーをサポートし、vLLMとBGEモデルのようなローカルオプションを含むOpenAI互換エンベディングサーバーが動作します。

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

主な設定項目:

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

観察モードとセルフモデリング。 directional は新規設定のデフォルトで、ユーザーとAIの両方のピアが自分自身と互いを観察できるようにします — より豊かな弁証法的推論ですが、AIが作成したメッセージがHonchoのAI自身へのモデルに貢献することも意味します。unified はより保守的なオプションです: AIは、自分の出力から対応する自己観察ループを構築せずに、ユーザーメッセージからユーザーをモデル化します。生成された結論が将来の推論にフィードバックされることを特に懸念する方（Self-Reinforcing Memory Loops in AI Agents を参照）は、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呼び出しを通じてサーバーサイドでメモリ抽出を処理します — 会話を-read し、離散的な事実を抽出し、重複を排除し、保存します。マネージドクラウド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: Self-Hosted Memory with Local LLMs を参照してください。

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

Holographic

最適な用途: ローカルストレージのみによるプライバシー重視のセットアップ。

Holographicは、メモリエンコードにHRR（ホログラフィック・レデュード・表現）代数を使用し、メモリ信頼性のために信頼スコアリングを行います。クラウド依存関係なし — すべての処理はあなたの独自のハードウェア上でローカルで実行されます。

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

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

ツール: 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リリースは、競合検証、削除動作、自己エコー処理を特に引き締めました — 競合検証の変更を動機付けた生産環境監査については Self-Reinforcing Memory Loops in AI Agents を参照してください。

セットアップ:

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

完全なインストールと保守的な設定の手順については、Mnemosyne for Hermes Agent: Local Memory Quickstart を参照してください。

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" を選択

選び方

グローバルな勝者を選ぶのではなく、プロバイダーをタスクに一致させます:

• 最もシンプルなローカル明示メモリ: 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インジェストパイプラインです。構造化プロジェクトまたは機関メモリに優れていますが、明示的事実ストアよりも自動的であるため、Self-Hosting Cognee quickstart と Choosing the right LLM for Cognee を参照し、それをドロップインHermesプロバイダーとして扱うべきではありません。
• AgentMemory は、ソースイベント、監査可能性、削除セマンティクスを強調します — 上記でMnemosyneについて議論された孤児導出レコードの問題の後に関連します。
• XMemo は保守的なデフォルトを提供します: 自動タイムラインキャプチャはオフのままにでき、削除は制限できます。採用はまだ早期で、完全なセクションを正当化するほどではありません。

関連ガイド

• AI Systems Memory hub — このサブクラスターのスコープとCogneeガイドへのリンク
• Self-Reinforcing Memory Loops in AI Agents — キャプチャポリシーとアプローバルゲートがなぜ重要か、深く
• Mnemosyne for Hermes Agent: Local Memory Quickstart — 上記でカバーしたMnemosyneプロバイダーの完全なインストールと保守的な設定
• Hermes Agent Memory System — プラグイン前のコア2ファイルメモリ
• Hermes Agent production setup — 実際のプロバイダーのプロファイルワイヤーリング