記憶プロバイダー

Hermes Agent には、外部の記憶プロバイダーのプラグインが 2 つ（RetainDB と ByteRover）同梱されています。内蔵の MEMORY.md と USER.md を超えて、セッションをまたいで残る知識をエージェントに持たせるものです。Honcho、Hindsight、Supermemory、Holographic などほかのものは、プラグインカタログから入れられます。外部プロバイダーは一度に1 つしか動かせません。内蔵の記憶は、それと並んで常に動いています。

すぐに使い始める

hermes memory setup      # interactive picker + configuration
hermes memory status     # check what's active
hermes memory off        # disable external provider

動かす記憶プロバイダーは、hermes plugins → Provider Plugins → Memory Provider からも選べます。

あるいは ~/.hermes/config.yaml に手で設定します。

memory:
  provider: retaindb  # or byterover,
                      # or honcho / hindsight / supermemory / mem0 / openviking / holographic
                      # (plugin catalog — run `hermes plugins install <name>` first)

しくみ

記憶プロバイダーが動いているとき、Hermes は自動で次のことを行います。

1. プロバイダーの文脈をシステムプロンプトへ差し込む（そのプロバイダーが知っていること）
2. 関係のありそうな記憶を各ターンの前に先読みする（裏側で、処理を止めずに）
3. 会話のターンをプロバイダーへ同期する（応答のたびに）
4. セッションの終了時に記憶を抽出する（対応しているプロバイダーの場合）
5. 内蔵の記憶への書き込みを外部プロバイダーにも写す
6. プロバイダーごとのツールを追加する（エージェントが記憶を検索・保存・管理できるように）

内蔵の記憶（MEMORY.md と USER.md）は、これまでとまったく同じように動き続けます。外部プロバイダーは足し算です。

Hermes がプロバイダーに渡すもの（ターン、ツールの出力を含む会話の記録、呼び出しの検索語、セッション終了時と圧縮前の会話の記録、写された記憶の書き込み、委任の結果、そしてプロバイダー自身のツールの引数）はすべて、チャットのプラットフォームや cron への配信と同じ秘密情報の除去を先に通ります。そのため、ツールの出力に表示されてしまったキーは、プロバイダーが保存する前に伏せられます。配信時の除去と同じく、security.redact_secrets: false のときでも働きます。決まった形を持たない認証情報（任意のパスワードや、key=value や Bearer の文脈の外にある不透明なトークン）は検出されません。手元の会話の記録には元の文章がそのまま残ります。

使えるプロバイダー

Honcho

AI に向いた、セッションをまたぐ利用者のモデリング。対話的な推論、セッション範囲の文脈の差し込み、意味検索、そして残り続ける結論を備えます。基本の文脈には、利用者の像とピアのカードに加えて、セッションの要約も含まれるようになったので、エージェントはすでに話した内容を把握できます。

ツール（5 つ）: honcho_profile（ピアのカードの読み書き）、honcho_search（意味検索）、honcho_context（セッションの文脈 — 要約、像、カード、メッセージ）、honcho_reasoning（LLM がまとめたもの）、honcho_conclude（結論の作成と削除）

構成: 文脈の差し込みは 2 層です。基本の層（セッションの要約、像、ピアのカード。contextCadence の間隔で更新）と、対話的な補足（LLM の推論。dialecticCadence の間隔で更新）です。対話的な補足は、基本の文脈があるかどうかで、冷えた状態向けの指示文（利用者に関する一般的な事実）と、温まった状態向けの指示文（セッション範囲の文脈）を自動で選び分けます。

互いに独立した 3 つの設定つまみが、費用と深さを別々に制御します。

• contextCadence — 基本の層が更新される間隔（API の呼び出し頻度）
• dialecticCadence — 対話用の LLM が走る間隔（LLM の呼び出し頻度）
• dialecticDepth — 対話 1 回あたりの .chat() の回数（1〜3。推論の深さ）

自動で差し込まれる対話的な補足は、問い合わせの長さに応じて推論の強さも変えます（長い問い合わせほど深く、上限は reasoningLevelCap）。問い合わせに応じた推論の強さを参照してください。

設定の案内:

hermes plugins install honcho   # from the plugin catalog
hermes memory setup             # select "honcho" — runs the Honcho-specific post-setup

以前からある hermes honcho setup コマンドも動きます（いまは hermes memory setup へ回されます）。ただし、Honcho を記憶プロバイダーとして選んだあとにしか登録されません。

画面の無い端末やリモートの端末では: ブラウザーの無い環境（SSH、リモートの仮想マシン）でクラウドの認証を行うには、案内の認証方法の質問で device を選んでください。CLI が短いコードと確認用のリンクを表示するので、別の端末のブラウザーでそのリンクを開いて承認すれば設定が終わります。API キーをコピーして貼る必要はありません。使えるブラウザーが手元に見つからない場合、案内は自動でこの選択肢を既定にします。

設定ファイル: $HERMES_HOME/honcho.json（プロファイル内）または ~/.honcho/config.json（全体）。解決の順番は $HERMES_HOME/honcho.json > ~/.hermes/honcho.json > ~/.honcho/config.json です。プラグインの READMEと Honcho の連携ガイドを参照してください。

<details> <summary>設定の早見表（全項目）</summary>

</details>

<details> <summary>最小の honcho.json（クラウド）</summary>

{
  "apiKey": "your-key-from-app.honcho.dev",
  "hosts": {
    "hermes": {
      "enabled": true,
      "aiPeer": "hermes",
      "peerName": "your-name",
      "workspace": "hermes"
    }
  }
}

</details>

<details> <summary>最小の honcho.json（自己ホスト）</summary>

{
  "baseUrl": "http://localhost:8000",
  "hosts": {
    "hermes": {
      "enabled": true,
      "aiPeer": "hermes",
      "peerName": "your-name",
      "workspace": "hermes"
    }
  }
}

</details>

複数ピアの設定:

Honcho は会話を「メッセージをやり取りするピア」としてモデル化します。Hermes のプロファイルごとに、利用者側のピアが 1 つと AI 側のピアが 1 つあり、すべてが 1 つの作業空間を共有します。作業空間は共有の環境です。利用者側のピアはプロファイルをまたいで共通で、AI 側のピアはそれぞれ別の人格です。AI 側のピアはそれぞれ自分の観測から独立した像とカードを組み立てるので、同じ利用者に対しても coder のプロファイルはコード寄りのまま、writer のプロファイルは編集寄りのままでいられます。

対応づけは次のとおりです。

新しいプロファイルと、新しい Honcho のピア

hermes profile create coder --clone

--clone は honcho.json に hermes.coder のホストの区画を作り、aiPeer: "coder"、共有の workspace、引き継いだ peerName、recallMode、writeFrequency、observation などを設定します。AI 側のピアは先に Honcho 上で作られるので、最初のメッセージの前から存在します。

すでにあるプロファイルに、Honcho のピアを埋める

hermes honcho sync

すべての Hermes のプロファイルを走査し、ホストの区画が無いものには作り、既定の hermes の区画から設定を引き継ぎ、新しい AI 側のピアを先に作ります。何度実行しても結果は同じで、すでにホストの区画があるプロファイルは飛ばします。

プロファイルごとの観測

ホストの区画はそれぞれ独立に観測の設定を上書きできます。例として、AI 側のピアが利用者を観測するが自分自身はモデル化しない、コード寄りのプロファイルを挙げます。

"hermes.coder": {
  "aiPeer": "coder",
  "observation": {
    "user": { "observeMe": true, "observeOthers": true },
    "ai":   { "observeMe": false, "observeOthers": true }
  }
}

観測の切り替え（ピアごとに 1 組）:

observationMode で選べる組み合わせです。

• "directional"（既定） — 4 つの旗すべてが有効です。互いに完全に観測し合い、ピアをまたぐ対話が働きます。
• "unified" — 利用者側は observeMe: true、AI 側は observeOthers: true、残りは無効です。観測者を 1 人にまとめる形で、AI は利用者をモデル化しますが自分自身はモデル化せず、利用者側のピアは自分だけをモデル化します。

Honcho のダッシュボードでサーバー側に設定した切り替えは、手元の既定より優先されます。セッションの開始時に手元へ同期されます。

観測についての全項目は Honcho のページを参照してください。

ゲートウェイでの人格の対応づけ

上のピアの考え方は、CLI、TUI、デスクトップのセッションに当てはまり、どの会話も peerName に解決されます。ゲートウェイではもう 1 つの軸が加わります。利用者はそれぞれの基盤の実行時 ID（Telegram の UID、Discord の snowflake、Slack の利用者）で現れ、3 つのキーが、その ID をどのピアに解決するかを決めます。

ゲートウェイの外では、これらのキーは何もしません。hermes memory setup は、つながっているゲートウェイの基盤を見つけたときだけ、これらを尋ねます。解決の順序と設定の流れについては Honcho のページを参照してください。

<details> <summary>honcho.json の全項目の例（複数プロファイル）</summary>

{
  "apiKey": "your-key",
  "workspace": "hermes",
  "peerName": "eri",
  "hosts": {
    "hermes": {
      "enabled": true,
      "aiPeer": "hermes",
      "workspace": "hermes",
      "peerName": "eri",
      "recallMode": "hybrid",
      "writeFrequency": "async",
      "sessionStrategy": "per-directory",
      "observation": {
        "user": { "observeMe": true, "observeOthers": true },
        "ai": { "observeMe": true, "observeOthers": true }
      },
      "dialecticReasoningLevel": "low",
      "dialecticDynamic": true,
      "dialecticCadence": 2,
      "dialecticDepth": 1,
      "dialecticMaxChars": 600,
      "contextCadence": 1,
      "messageMaxChars": 25000,
      "saveMessages": true
    },
    "hermes.coder": {
      "enabled": true,
      "aiPeer": "coder",
      "workspace": "hermes",
      "peerName": "eri",
      "recallMode": "tools",
      "observation": {
        "user": { "observeMe": true, "observeOthers": false },
        "ai": { "observeMe": true, "observeOthers": true }
      }
    },
    "hermes.writer": {
      "enabled": true,
      "aiPeer": "writer",
      "workspace": "hermes",
      "peerName": "eri"
    }
  },
  "sessions": {
    "/home/user/myproject": "myproject-main"
  }
}

</details>

プラグインの READMEと Honcho の連携ガイドを参照してください。

同梱されていた Honcho からの移行

以前の Hermes では、Honcho が本体に入っていました。プロファイルにまだ memory.provider: honcho が残っていれば、次に起動したときか hermes update を実行したときに、Hermes がカタログのプラグインを自動で入れます。~/.honcho/config.json（または $HERMES_HOME/honcho.json）、ホストのブロック、ピア、セッションの対応づけはこれまでどおりに読まれるので、記憶が失われることはありません。手で入れたいとき、または起動時にネットワークにつながらない端末では、hermes plugins install honcho を実行してください。

OpenViking

Volcengine（ByteDance）による文脈のデータベースです。ファイルシステム風の知識の階層、段階的な取り出し、6 分類への自動的な記憶の抽出を備えます。

ツール（6 つ）: viking_search（意味検索）、viking_read（段階的に: 要旨・概観・全文）、viking_browse（ファイルシステム風の移動）、viking_remember（事実の保存）、viking_forget（viking:// の URI をそのまま指定して記憶のファイルを削除）、viking_add_resource（URL や文書の取り込み）

設定:

# Prepare OpenViking first
openviking-server init
openviking-server doctor
openviking-server

# Then install and configure the Hermes plugin
hermes plugins install openviking
hermes memory setup    # select "openviking"
# Or manually:
hermes config set memory.provider openviking

hermes memory setup は、 ~/.openviking/ovcli.conf にある接続の値をそのまま使うか、複製できます。手で設定する場合は、動いているプロファイルの .env ファイルを使います。 既定のプロファイルなら ~/.hermes/.env、名前付きのプロファイルなら ~/.hermes/profiles/<profile>/.env です。

OPENVIKING_ENDPOINT=http://127.0.0.1:1933
# OPENVIKING_API_KEY=...
# OPENVIKING_ACCOUNT=default
# OPENVIKING_USER=default

OpenViking のサーバー側の設定は ov.conf にあります（--config、 OPENVIKING_CONFIG_FILE、または ~/.openviking/ov.conf）。クライアント側の接続の値は ovcli.conf にあります（OPENVIKING_CLI_CONFIG_FILE または ~/.openviking/ovcli.conf）。

エンドポイントがローカルで、何も待ち受けていない場合、プラグインが openviking-server を裏で起動します。カタログに載っている版では、このサーバーは Hermes のプロセスの環境変数を（PYTHONPATH を除いて）すべて受け継ぎます。そこに設定された ボット、ゲートウェイ、中継のトークンも含まれます。これを避けたい場合は、Hermes より先に openviking-server を自分で起動しておけば、プラグインがサーバーを立ち上げることはありません。 この修正は上流の volcengine/OpenViking#5553 で追跡されています。

主な特徴:

• 段階的な文脈の読み込み: L0（約 100 トークン）→ L1（約 2k）→ L2（全文）
• セッションの確定時に記憶を自動抽出（人物像、好み、実体、出来事、事例、型）
• 階層をたどって知識を見て回るための viking:// の URI 形式

OPENVIKING_ACCOUNT と OPENVIKING_USER は、手元や信頼できる環境で使います。 ピアの人格は任意です。既定では、Hermes はピアの ID を送らず、明示的な記憶を viking://user/<user>/memories/... に書きます。設定の案内でピアの ID を 尋ねることはありません。アシスタント用の文脈を分けたい場合は、config.yaml に memory.openviking.agent: work-assistant を設定してください。

すでに空でないピアの設定がある場合は、ピア範囲での書き込みと呼び出しが保たれます。 これには OPENVIKING_AGENT や、連携する OpenViking の設定にある actor_peer_id、 以前からの agent_id が含まれます。既存の記憶が移動したり消えたりすることはありません。 ピアの ID が無い場合、既定の検索は利用者の記憶と、同じ OpenViking の利用者の下にある 既存のピアの記憶を対象にします。古いピアの記憶も、いまのパスのまま検索できます。 どの記憶が返るかは、順位付けと件数の上限で決まります。 以前のピア範囲での書き込みに戻したい場合は memory.openviking.agent: hermes を設定してください。 この変更より前に利用者の範囲で書かれた記憶はそこに残り、検索もできます。 この設定が変えるのは今後の書き込みで、既存の記憶の場所ではありません。

Hermes は OpenViking への要求に User-Agent: openviking-memory-hermes/<version> を 付けます。これは標準的な実行環境の識別子で、利用者ごとの識別子は含みませんし、 要求が余分に増えることもありません。

同梱の OpenViking から移る

OpenViking は以前、Hermes のツリーの中に同梱されていました。config.yaml にすでに memory.provider: openviking があるなら、ほとんどの利用者は何もする必要がありません。

• hermes update が、このプロバイダーを指定しているすべてのプロファイルのホームにカタログのプラグインを入れます。
• エージェントを最初に起動したとき（hermes chat、ゲートウェイ、デスクトップ）にまだプラグインが無ければ、Hermes がそれを入れ、入れたことを知らせます。
• security.allow_lazy_installs: false のときは、エージェントの起動経路では何も入れず、代わりに実行すべき hermes plugins install openviking のコマンドをそのまま表示します。

memory.provider、memory.openviking.*、.env の OPENVIKING_* のキー、~/.openviking/、そして OpenViking のサーバーにある記憶には手を触れません。確かめるには hermes memory status と hermes plugins list を使います。

Mem0

サーバー側で LLM が事実を抽出し、意味検索、順位の付け直し、重複の自動除去を行います。つなぎ方は 3 通りあります。Platform（Mem0 Cloud）、自己ホストのダッシュボード（Docker で自分が動かす Mem0 のサーバー）、OSS（自前の LLM とベクトルストアを使って、同じプロセス内で動かす Mem0）です。

mem0ai の SDK は、シェルか ~/.hermes/.env で MEM0_TELEMETRY=false を設定しないかぎり、 匿名の利用状況を PostHog へ送ります。

ツール（4 つ）: mem0_search（意味検索。platform では順位の付け直しも任意で使えます。既定では無効）、mem0_add（事実をそのまま保存）、mem0_update（ID を指定して更新）、mem0_delete（ID を指定して削除）

設定（Platform）:

hermes plugins install mem0   # from the plugin catalog
hermes memory setup    # select "mem0" → "Platform"
# Or manually:
hermes config set memory.provider mem0
echo "MEM0_API_KEY=your-key" >> ~/.hermes/.env

設定（OSS）:

hermes memory setup    # select "mem0" → "Open Source (self-hosted)"
# Or via flags:
hermes memory setup mem0 --mode oss --oss-llm openai --oss-llm-key sk-... --oss-vector qdrant

ファイルを書かずに内容だけ確かめるには、次のようにします。

hermes memory setup mem0 --mode oss --oss-llm-key sk-... --dry-run

設定（自己ホストのダッシュボード）: Docker で自分が動かす Mem0 のサーバー（ダッシュボードの REST API）につなぎます。

hermes memory setup    # select "mem0" → "Self-hosted server"
# Or via flags:
hermes memory setup mem0 --mode selfhosted --host http://localhost:8888 --api-key your-admin-api-key

手で設定することもできます。環境変数として書くなら、次のようにします。

echo "MEM0_HOST=http://localhost:8888" >> ~/.hermes/.env
echo "MEM0_API_KEY=your-admin-api-key" >> ~/.hermes/.env

mem0.json に書くなら、次のようにします。

{ "host": "http://localhost:8888", "api_key": "your-admin-api-key" }

プラグインは X-API-Key で認証し、サーバーの /search と /memories の経路を使います。api_key は任意です（AUTH_DISABLED のサーバーのときだけ省いてください）。mode: oss は設定しないでください。host より優先されてしまいます。

設定ファイル: $HERMES_HOME/mem0.json（挙動の設定）。~/.hermes/.env に置くのは、秘密である MEM0_API_KEY だけです。

OSS で対応しているもの:

モードの切り替え: hermes memory setup mem0 --mode <platform|selfhosted|oss> を実行し直すか、mem0.json を直接編集してください。

同梱の Mem0 から移る

Mem0 は以前、Hermes のツリーの中に（また pip の追加パッケージ hermes-agent[mem0] として）同梱されていました。config.yaml にすでに memory.provider: mem0 があるなら、ほとんどの利用者は何もする必要がありません。

• hermes update が、このプロバイダーを指定しているすべてのプロファイルのホームにカタログのプラグインを入れます。
• エージェントを最初に起動したとき（hermes chat、ゲートウェイ、デスクトップ）にまだプラグインが無ければ、Hermes がそれを入れ、入れたことを知らせます。
• security.allow_lazy_installs: false のときは、エージェントの起動経路では何も入れず、代わりに実行すべき hermes plugins install mem0 のコマンドをそのまま表示します。

memory.provider、$HERMES_HOME/mem0.json、.env の MEM0_* のキー、そして Mem0 Cloud・自分の Mem0 のサーバー・手元の OSS ストアに保存された記憶には手を触れません。確かめるには hermes memory status と hermes plugins list を使います。

Hindsight

知識グラフ、実体の名寄せ、複数の戦略を使った取り出しを備えた長期記憶です。hindsight_reflect ツールは、記憶をまたいだ統合を行うもので、他のプロバイダーにはありません。会話のターン（ツール呼び出しを含みます）を丸ごと自動で保持し、セッション単位で文書を追跡します。

ツール: hindsight_retain（実体の抽出を伴う保存）、hindsight_recall（複数戦略での検索）、hindsight_reflect（記憶をまたいだ統合）

設定:

hermes plugins install hindsight   # from the plugin catalog; answer "Use 'hindsight' as the memory provider now?"
hermes memory setup                # select "hindsight"
# Or manually:
hermes config set memory.provider hindsight
echo "HINDSIGHT_API_KEY=your-key" >> ~/.hermes/.env

プラグインは ~/.hermes/plugins/hindsight/（プロファイルごとのホーム）に置かれます。記憶プロバイダーを有効にするのは config.yaml の memory.provider で、plugins.enabled ではありません。導入時の確認に「はい」と答える（または --enable を付ける）とこの値が設定され、断ると変わらないので、あとから hermes memory setup で選べます。hermes plugins enable hindsight を実行しても、記憶プロバイダーは有効になりません。hermes memory setup、hermes memory status、hermes plugins list、ダッシュボードの記憶の設定は、どれもカタログから入れたプラグインでそのまま使えます。手元に組み込むモードでは、最初に使うときにプラグインが Hermes の遅延導入の経路を通して hindsight-all を入れます。この経路は security.allow_lazy_installs に従います。

ローカルモードの画面: hindsight-embed -p hermes ui start

設定ファイル: $HERMES_HOME/hindsight/config.json

設定できる項目の全容は上流の Hermes 連携ドキュメントを参照してください。

同梱の Hindsight から移る

Hindsight は以前、Hermes のツリーの中に（また pip の追加パッケージ hermes-agent[hindsight] として）同梱されていました。config.yaml にすでに memory.provider: hindsight があるなら、ほとんどの利用者は何もする必要がありません。

• hermes update が、このプロバイダーを指定しているすべてのプロファイルのホームにカタログのプラグインを入れます。表示される各行には、どのプロファイルの話かが書かれます。ターミナルでは、プラグインが使う Python の依存パッケージを用意する前に確認を求めます。このプロバイダーを使うプロファイルが複数あるときは、質問は 1 回だけで、その答えがすべてのプロファイルに当てはまります。ターミナルが無い場合（デスクトップアプリ、スクリプト、サービス）は誰も答えられないので、security.allow_lazy_installs がオン（既定）のプロファイルは確認なしで用意します。これがオフのプロファイルには、代わりに hermes -p <profile> plugins install hindsight という実行すべきコマンドがそのまま示され、ほかのプロファイルの移行は続きます。
• エージェントを最初に起動したとき（hermes chat、デスクトップ、ゲートウェイ、…）にまだプラグインが無ければ、Hermes が依存パッケージごとそれを入れて `✓ Memory provider 'hindsight' moved out of core — installed its plugin from the catalog (memory.provider and your stored memories are unchanged; check its settings with hermes memory status).` と表示します。メッセージングのプラットフォームでは、この行が最初の返信といっしょに届きます。
• エージェント起動時の導入ができなかった場合は、外部の記憶なしで黙って動くのではなく、その理由が表示されます。security.allow_lazy_installs: false のときは、警告にそのプロファイル用の導入コマンドが示されます。オフラインのときや導入を断ったときは、エラーと同じコマンドが表示されます。導入に失敗したあと 1 時間以内のエージェント起動では、導入を試さずにコマンドを表示し直すだけです。hermes update は毎回やり直します。
• エージェントの起動時には、何も質問しません（ターミナルはチャットの入力欄が使っているためです）。そのため、Hermes に一度も同梱されたことのないカタログのプロバイダー（たとえば mnemosyne）は、起動時には入りません。警告にそのプロファイル用の hermes plugins install <name> が示されるので、それを実行するか、ダッシュボードまたはデスクトップの Plugins ページから入れてください。

ディスク上で変わるのは次の点です。プラグインが ~/.hermes/plugins/hindsight/ に現れ、config.yaml に plugins.enabled: [hindsight] が加わります。memory.provider、$HERMES_HOME/hindsight/config.json、.env の HINDSIGHT_API_KEY、記憶の保管庫のデータには手を触れません。確かめるには hermes memory status（プロバイダーが動いているか）と hermes plugins list（プラグインが入って有効になっているか）を使います。

Holographic

手元の SQLite に事実を貯める仕組みです。FTS5 の全文検索、信頼度の採点、そして組み合わせた代数的な問い合わせのための HRR（Holographic Reduced Representations）を備えます。

ツール: fact_store（9 つの操作: add、search、probe、related、reason、contradict、update、remove、list）、fact_feedback（役に立った・立たなかったの評価で、信頼度の採点を鍛えます）

設定:

hermes plugins install holographic   # from the plugin catalog
hermes memory setup                  # select "holographic"
# Or manually:
hermes config set memory.provider holographic

設定ファイル: config.yaml の plugins.hermes-memory-store の下

ここにしかない機能:

• probe — 実体を指定した代数的な呼び出し（ある人や物についての事実をすべて）
• reason — 複数の実体にまたがる AND の組み合わせ問い合わせ
• contradict — 矛盾する事実の自動検出
• 非対称なフィードバックによる信頼度の採点（役に立てば +0.05、立たなければ -0.10）

カタログのプラグインには独自のリリースノートがあり、この一覧にない設定項目もあります。いまのツールの操作と設定は、その README を見てください。

同梱の Holographic から移る

Holographic は以前、Hermes のツリーの中に同梱されていました。config.yaml にすでに memory.provider: holographic があるなら、何もする必要はありません。

• hermes update が、このプロバイダーを指定しているすべてのプロファイルのホームにカタログのプラグインを入れます。
• エージェントを最初に起動したとき（hermes chat、ゲートウェイ、デスクトップ）にまだプラグインが無ければ、Hermes がそれを入れ、入れたことを知らせます。
• security.allow_lazy_installs: false のときは、エージェントの起動経路では何も入れず、代わりに実行すべき hermes plugins install holographic のコマンドをそのまま表示します。

貯めた事実（$HERMES_HOME/memory_store.db、または自分で設定した db_path）と plugins.hermes-memory-store の設定は以前とまったく同じように読み込まれるので、記憶が失われることはありません。確かめるには hermes memory status と hermes plugins list を使います。

Nous Research が暫定的に用意したコピー（NousResearch/hermes-plugin-holographic、現在はアーカイブ済み）を URL 指定で入れていた場合は、hermes plugins update holographic を実行するとカタログの項目へ移ります。データはそのままの場所に残ります。

RetainDB

ハイブリッド検索（ベクトル + BM25 + 順位の付け直し）、7 種類の記憶、差分圧縮を備えたクラウドの記憶 API です。

ツール（10 個）: retaindb_profile（利用者の像）、retaindb_search（意味検索）、retaindb_context（作業に関係する文脈）、retaindb_remember（種類と重要度を付けて保存）、retaindb_forget（記憶の削除）、そしてファイル関連の retaindb_upload_file、retaindb_list_files、retaindb_read_file、retaindb_ingest_file、retaindb_delete_file

設定:

hermes memory setup    # select "retaindb"
# Or manually:
hermes config set memory.provider retaindb
echo "RETAINDB_API_KEY=your-key" >> ~/.hermes/.env

ByteRover

brv の CLI を通した持続する記憶です。階層的な知識の木と、段階的な取り出し（あいまいな文字列検索から LLM による検索へ）を備えます。手元を基本としつつ、クラウドとの同期も任意で使えます。

ツール: brv_query（知識の木を検索）、brv_curate（事実・判断・型を保存）、brv_status（CLI のバージョンと木の統計）

設定:

# Install the CLI first
curl -fsSL https://byterover.dev/install.sh | sh

# Then configure Hermes
hermes memory setup    # select "byterover"
# Or manually:
hermes config set memory.provider byterover

主な特徴:

• 圧縮の直前に自動で抽出（文脈の圧縮で捨てられる前に、気づきを残します）
• 知識の木は $HERMES_HOME/byterover/ に置かれます（プロファイル単位）
• SOC2 Type II 認証を受けたクラウド同期（任意）

Supermemory

意味に基づく長期記憶です。利用者の像の呼び出し、意味検索、明示的な記憶のツール、そしてターンごとの会話の記録（セッションごと、4 時間の区切りごとに 1 つの文書）を備えます。

ツール: supermemory_store（明示的な記憶の保存）、supermemory_search（意味の近さでの検索）、supermemory_forget（ID かいちばん近い問い合わせで忘れる）、supermemory_profile（残り続ける像と最近の文脈）

設定:

hermes plugins install supermemory   # from the plugin catalog
hermes memory setup                  # select "supermemory"
# Or manually:
hermes config set memory.provider supermemory
echo 'SUPERMEMORY_API_KEY=***' >> ~/.hermes/.env

自己ホストの設定は次のとおりです。

npx supermemory local

hermes plugins install supermemory を実行したあと、hermes memory setup を実行する前に、 $HERMES_HOME/supermemory.json に base_url を設定してください。

{
  "base_url": "http://localhost:6767"
}

そのうえで hermes memory setup を実行し、手元のサーバーが表示した API キーを 入力します。先に接続先を設定しておくと、設定時の接続確認も手元に留まります。

設定ファイル: $HERMES_HOME/supermemory.json

環境変数: SUPERMEMORY_API_KEY（必須）、SUPERMEMORY_BASE_URL（base_url が設定されていないときの互換用の受け皿）、SUPERMEMORY_CONTAINER_TAG（設定を上書きします）。

基準 URL の優先順位は supermemory.json → SUPERMEMORY_BASE_URL → https://api.supermemory.ai です。SDK の操作と、設定と状態の確認は、すべてこの解決されたつなぎ先を使います。

主な特徴:

• 文脈の自動的な囲い込み — 保存するターンから呼び出した記憶を取り除き、記憶が記憶を汚す循環を防ぎます
• ターンごとの記録 — 終わったターンをその都度書き込みます。セッションごと、4 時間の区切りごとに 1 つの文書になります
• 書き込みに失敗したターンは、次のターン、セッション終了、/reset、終了処理のいずれかで再試行されます（少なくとも 1 回は届きます）
• 端から端まで自己ホストで完結する経路 — SDK と接続確認の要求が、同じ設定のつなぎ先を使います
• 最初のターンと、指定した間隔ごとに、像の事実を差し込みます
• プロファイル単位の入れ物 — container_tag に {identity} を使うと（例: hermes-{identity} → hermes-coder）、Hermes のプロファイルごとに記憶を分けられます
• 複数の入れ物のモード — enable_custom_container_tags を有効にして custom_containers の一覧を書くと、エージェントが名前を付けた入れ物をまたいで読み書きできます。自動の操作は主な入れ物に留まります。

<details> <summary>複数の入れ物の例</summary>

{
  "container_tag": "hermes",
  "enable_custom_container_tags": true,
  "custom_containers": ["project-alpha", "shared-knowledge"],
  "custom_container_instructions": "Use project-alpha for coding context."
}

</details>

問い合わせ先: Discord · [support@supermemory.com](mailto:support@supermemory.com)

同梱の Supermemory から移る

Supermemory は以前、Hermes のツリーの中に（また pip の追加パッケージ hermes-agent[supermemory] として）同梱されていました。config.yaml にすでに memory.provider: supermemory があるなら、ほとんどの利用者は何もする必要がありません。

• hermes update が、このプロバイダーを指定しているすべてのプロファイルのホームにカタログのプラグインを入れます（security.allow_lazy_installs が false でも動きます）。
• エージェントを最初に起動したとき（hermes chat、ゲートウェイ、…）にまだプラグインが無ければ、Hermes がそれを入れて ✓ Memory provider 'supermemory' moved out of core — installed its plugin from the catalog (your memory.supermemory settings and data are unchanged). と表示します。
• security.allow_lazy_installs: false のときは、エージェントの起動経路が代わりに 1 行だけ記録します — `Memory provider 'supermemory' is not installed; security.allow_lazy_installs is off — run hermes plugins install supermemory. — そのうえで、hermes plugins install supermemory` をご自身で実行します。

ディスク上で変わるのは次の点です。プラグインが ~/.hermes/plugins/supermemory/ に現れ、config.yaml に plugins.enabled: [supermemory] が加わります。Supermemory の SDK はプラグイン自身のパッケージ情報から入るので、追加パッケージ hermes-agent[supermemory] はもう要りません。memory.provider、$HERMES_HOME/supermemory.json、.env の SUPERMEMORY_* のキー、Supermemory のアカウントに保存された記憶には手を触れません。確かめるには hermes memory status（プロバイダーが動いているか）と hermes plugins list（プラグインが入って有効になっているか）を使います。

Memori

Memori Cloud を使う、構造化された長期記憶です。終わったターンを裏で取り込み、ツールを踏まえたターンの文脈を持ち、事実・要約・利用枠・登録・フィードバックのための明示的な呼び出しのツールを備えます。

ツール: memori_recall（長期記憶の検索）、memori_recall_summary（要約した文脈）、memori_quota（利用量と枠）、memori_signup（登録メールの依頼）、memori_feedback（連携についての意見の送信）

設定:

hermes-memori は外部の連携で、PM が管理するツール名ではありません。CLI は、 提供元の手順に沿って独立した環境へ入れてください。そのインストーラーを実行する前に、 使う予定の Hermes ホームを対象にしていること、そして Python の依存関係を宣言したプロバイダーを 提供することを確かめてください。外部のインストーラーに、Hermes が選んだ環境へ pip で 入れさせないでください。CLI が使えるだけでは、Hermes の中で Python のプロバイダーは使えるようになりません。 エントリーポイントだけの配布物は、それを含めたビルドを所有者が管理して用意する必要があります。

# Run only after confirming the external installer's integration contract above.
hermes-memori install
hermes config set memory.provider memori
hermes memory setup

インストーラーが、PM の管理するディレクトリ型プロバイダーの受け入れに対応していない場合は、 hermes pm install のようなパッケージのコマンドを勝手に作らず、その連携を提供元に依頼してください。 依存関係の用意がうまくいったら、Hermes を再起動してください。

プロバイダーの比較

プロファイルごとの分離

各プロバイダーのデータは、プロファイルごとに分けられます。

• 手元に保存するプロバイダー（Holographic、ByteRover）は $HERMES_HOME/ のパスを使い、これはプロファイルごとに異なります
• 設定ファイルを使うプロバイダー（Honcho、Mem0、Hindsight、Supermemory）は設定を $HERMES_HOME/ に置くので、プロファイルごとに自分の認証情報を持ちます
• クラウドのプロバイダー（RetainDB）は、プロファイル単位のプロジェクト名を自動で導きます
• 環境変数を使うプロバイダー（OpenViking）は、プロファイルごとの .env ファイルで設定します

プラグインカタログへ移るプロバイダー

記憶プロバイダーは Hermes 本体のツリーから、それぞれの作者のリポジトリへ移りつつあり、 プラグインカタログで配布されます。最初に移ったのは Hindsight で（同梱の Hindsight から移るを参照）、続いて Honcho（ 同梱されていた Honcho からの移行を参照）、Supermemory（ 同梱の Supermemory から移るを参照）、Mem0（ 同梱の Mem0 から移るを参照）、OpenViking（ 同梱の OpenViking から移るを参照）、Holographic（現在は itpartypattaya が保守。 同梱の Holographic から移るを参照）が移りました。RetainDB と ByteRover は 2026 年 10 月 15 日に本体から外れます。それぞれの単独のリポジトリは保守されておらず、 新しい保守者を募っています。利用する側で変わることはありません。 プロバイダーの名前も、それが読む設定も、データの置き場所も、道具もそのままです。 設定しているプロバイダーが Hermes に同梱されなくなったときは、hermes update が、そのプロバイダーを 指定しているすべてのプロファイルにカタログのプラグインを入れます。デスクトップアプリから更新する場合は、 エージェントが最初に起動したときに同じことをします。どの結果も、ターミナル、デスクトップ、 またはメッセージングのプラットフォームでの最初の返信で必ず知らされます。導入ができなかった場合 （security.allow_lazy_installs: false、オフライン、断ったとき）は、警告に実行すべき hermes plugins install <name> のコマンドがそのまま示されます。

記憶プロバイダーを作る

自分で作る方法は開発者ガイド: 記憶プロバイダーのプラグインを参照してください。