Agent Memory Provider比較：キャプチャポリシーとセルフホスティング

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

現代の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 を参照してください。

検索品質と同じくらい重要なもう一つの軸があります。それは メモリガバナンス です。プロバイダーによって、自動的に何がキャプチャされるか、アシスタントが生成した出力が永続メモリとなってもよいか、リフレクション（内省）が事実として保存されるか、矛盾はどのように解決されるか、人間のレビューなしに書き込みが未来のコンテキストとなってもよいかといった点で大きく異なります。長期的に動作するエージェントにとって、これらの違いはリコールベンチマークで数ポイント向上することよりも重要になる可能性があります。自動キャプチャが生成された結論を将来の前提に変えることについては、AI エージェントにおける自己強化的メモリループ を、慎重な設定の実例については、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

プロバイダー比較

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

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

これらはアーキテクチャ的なリスクのカテゴリーであり、品質スコアではありません。慎重に設定された高度なプロバイダーは、粗雑に設定されたシンプルなプロバイダーよりも、実際には安全である可能性があります。

詳細な解説

Honcho

適しているケース: マルチエージェントシステム、セッション間のコンテキスト、ユーザーとエージェントの整合性。

Honcho は既存のメモリと並行して動作します — USER.md はそのまま保持され、Honcho がコンテキストの追加レイヤーを付加します。Honcho は会話をメッセージをやり取りするピア（対等者）としてモデル化します — 各 Hermes プロファイルにつき1つのユーザーピアと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 を通じてプロバイダーを設定可能で、BGE モデルを使用する vLLM などのローカルオプションを含む、任意の OpenAI 互換エンベディングサーバーが動作します。

ツール: 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が作成したメッセージが Honcho の AI 自身に対するモデルに貢献することも意味します。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 (Vision-Language Model)、ベクトル検索にはエンベディングモデルを必要とし、どちらも必須です。サポートされている 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 は、メモリ抽出をサーバーサイドの LLM 呼び出しによって add 操作ごとに処理します — 会話を読み取り、個々の事実を抽出し、重複を排除して保存します。マネージドクラウド 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、グラフ走査、時間的）を並列で実行し、その後、相互順位融合 (Reciprocal Rank Fusion) を使用して結果をマージし、順序を再調整します。

外部依存関係: Hindsight は、retain 呼び出しでの事実とエンティティの抽出、および reflect 呼び出しでの統合には LLM を必要とします（デフォルト: OpenAI; サポートされるプロバイダーには Anthropic、Gemini、Groq、Ollama、LM Studio、および任意の OpenAI 互換エンドポイントが含まれます）。エンベディングモデルとクロスエンコーダーのリランキングモデルは Hindsight 自体にバンドルされており、hindsight-all パッケージ内でローカルに動作し、外部 API を必要としません。PostgreSQL も、管理される pg0 データディレクトリを通じて埋め込み Python インストールにバンドルされています。代替として、Hindsight を外部 PostgreSQL インスタンスにポイントさせることもできます。完全ローカル、クラウドゼロの設定では、HINDSIGHT_API_LLM_PROVIDER=ollama を設定し、ローカル Ollama モデルにポイントします — retain と recall は完全に動作しますが、reflect にはツール呼び出し対応モデル（例: qwen3:8b）が必要です。

ツール: hindsight_retain、hindsight_recall、hindsight_reflect (独自のメモリ横断統合)。

セットアップ:

hermes memory setup  # "hindsight" を選択
echo "HINDSIGHT_API_KEY=your-key" >> ~/.hermes/.env

hindsight-client (クラウド) または hindsight-all (ローカル) を自動インストールします。0.4.22 以上が必要です。

設定: $HERMES_HOME/hindsight/config.json

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

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

保守的なメモリ衛生のために、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 です。システムはまた、ワーキングメモリ、エピソード記憶、構造化事実、時間的3項、正典事実、統合も維持します。

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: Local Memory Quickstart を参照してください。

Memori

適しているケース: 会話履歴と同じくらい実行履歴が重要なエージェント。

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

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

セットアップ:

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

ByteRover

適しているケース: 人間が読みやすく、監査可能なストレージを持つローカルファーストのメモリ。

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

外部依存関係: ByteRover は、メモリのキュレーションと検索には LLM を必要とします (18のプロバイダーをサポート、Anthropic、OpenAI、Google、Ollama、および openai-compatible プロバイダースロット経由の任意の OpenAI 互換エンドポイントを含む)。エンベディングモデルやデータベースは不要です — コンテキストツリーはプレーンな Markdown ファイルのローカルディレクトリです。クラウド同期は任意であり、チームコラボレーションのためだけに使用されます; デフォルトではすべて完全オフラインで動作します。完全自己完結型のローカルセットアップでは、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 — ナレッジグラフ plus reflect
• ピアまたはユーザーモデリング: Honcho — 弁証法的推論、保守的なセルフモデリングのための unified モード
• ファイルシステムスタイルの知識: OpenViking — 階層的な viking:// 階層
• お手軽な自動抽出: Mem0 — ゼロ設定の LLM ベース事実抽出
• 操作的/ツール認識メモリ: Memori — ターンと実行トレースのキャプチャ
• 人間が読みやすく、監査可能、エンベディングパイプラインなし: ByteRover — プレーン Markdown コンテキストツリー
• エンタープライズコンテキストフェンシング: Supermemory — セッショングラフ取り込み、Cloudflare ホスト
• 高頻度更新、セルフホスト不要: RetainDB — デルタ圧縮、弁証法的セルフモデル

プロファイルごとのプロバイダー設定と実際のワークフローパターンについては、Hermes Agent 本番セットアップ を参照してください。

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

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

• Scope Recall は、SQLite を永続的な真実として扱い、生会話キャプチャを別にスコープして保持し、保守的なターン後レビューのための任意の turn-closure-audit 同伴機能を持っています — 捕捉された各ターンを即座に同等の長期知識として扱うのではなく、生ジャーナル証拠を永続的なセマンティックメモリから分離します。
• Cognee は、Hermes 対話メモリプラグインではなく、ナレッジグラフ / ECL 取り込みパイプラインです。構造化されたプロジェクトまたは組織記憶では優れていますが、明示的事実ストアよりも自動的です; ドロップイン Hermes プロバイダーとして扱うのではなく、セルフホスト Cognee クイックスタート と Cognee に最適な LLM の選択) を参照してください。
• AgentMemory は、ソースイベント、監査可能性、削除セマンティクスを強調します — 上記で Mnemosyne について議論された孤立した派生レコードの問題後に相关します。
• XMemo は保守的なデフォルト値を提供します: 自動タイムラインキャプチャはオフのままにでき、削除は制約されます。採用はまだ初期段階であり、完全なセクションを必要とするほどではありません。

関連ガイド

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