メモリープロバイダー

Hermes Agent には外部メモリープロバイダーのプラグインが 8 つ同梱されていて、組み込みの MEMORY.md や USER.md を超えて、セッションをまたいで残る知識をエージェントに持たせられます。同時に有効にできる外部プロバイダーは 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: openviking   # or honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory

しくみ

メモリープロバイダーが有効なとき、Hermes は次の処理を自動で行います。

1. プロバイダーの持つ情報をシステムプロンプトに差し込む（そのプロバイダーが知っていること）
2. 各ターンの前に関連するメモリーを先読みする（バックグラウンドで動き、処理は止めません）
3. 応答のたびに会話のやり取りをプロバイダーへ送る
4. セッション終了時にメモリーを抽出する（対応しているプロバイダーの場合）
5. 組み込みメモリーへの書き込みを外部プロバイダーにも反映する
6. プロバイダー固有のツールを追加する（エージェントがメモリーを検索・保存・管理できるようになります）

組み込みのメモリー（MEMORY.md / USER.md）はこれまでどおり動きます。外部プロバイダーはそこに足すものです。

選べるプロバイダー

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 memory setup        # select "honcho" — runs the Honcho-specific post-setup

以前からある hermes honcho setup コマンドも今なお動きます（内部で hermes memory setup に転送されます）が、これは Honcho を有効なメモリープロバイダーに選んだあとでしか登録されません。

画面のない端末やリモート環境: ブラウザーのない環境（SSH 越し、リモート VM）でクラウド認証をするときは、ウィザードの認証方法の質問で device を選んでください。CLI が短いコードと確認用のリンクを表示するので、別の端末のブラウザーでそのリンクを開いて承認すれば設定が完了します。API キーを写す作業は要りません。使えるローカルブラウザーが見つからないとき、ウィザードは自動でこの選択肢を既定にします。

設定ファイル: $HERMES_HOME/honcho.json（プロファイル単位）または ~/.honcho/config.json（全体）。読み込む順番は $HERMES_HOME/honcho.json > ~/.hermes/honcho.json > ~/.honcho/config.json です。設定の一覧と 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 つにつき、ユーザー側のピアが 1 つと AI 側のピアが 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>

設定の一覧と 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 configure Hermes
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_AGENT=hermes

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

主な特徴:

• 段階的な文脈の読み込み: L0（約 100 トークン）→ L1（約 2k）→ L2（全文）
• セッションの確定時にメモリーを自動で抽出（プロフィール、好み、対象、出来事、事例、傾向）
• 知識を階層でたどるための viking:// URI

OPENVIKING_ACCOUNT と OPENVIKING_USER は、手元・信頼済みのモードで使われます。 OPENVIKING_AGENT は OpenViking のなかでの Hermes のピア ID で、ピア単位のメモリーに使われます。 Hermes は OpenViking への要求に User-Agent: openviking-memory-hermes/<version> を付けて送ります。 これはハーネスを表す標準的な識別子で、利用者ごとの識別子は含まれませんし、要求が余分に増えることもありません。

Mem0

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

ツール（4 個）: mem0_search（意味検索。platform モードでは再ランク付けも選べます。既定は無効）、mem0_add（事実をそのまま保存）、mem0_update（ID を指定して更新）、mem0_delete（ID を指定して削除）

設定（Platform）:

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 を直接書き換えます。

Hindsight

知識グラフ、対象の名寄せ、複数の方法を組み合わせた検索を備えた長期メモリーです。hindsight_reflect ツールはメモリー同士をつないでまとめるもので、ほかのプロバイダーにはありません。ツール呼び出しを含む会話のやり取りを丸ごと自動で保持し、セッション単位で文書として追跡します。

ツール: hindsight_retain（対象を抜き出して保存）、hindsight_recall（複数の方法での検索）、hindsight_reflect（メモリー同士をつないでまとめる）

設定:

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

セットアップウィザードは依存関係を自動で入れ、選んだモードに必要なものだけを入れます（クラウドなら hindsight-client、ローカルなら hindsight-all）。hindsight-client >= 0.4.22 が必要です（古い場合はセッションの開始時に自動で更新されます）。

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

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

設定の詳しい説明はプラグインの README にあります。

Holographic

FTS5 の全文検索、信頼度の採点、そして組み合わせ計算のできる HRR（Holographic Reduced Representations）を備えた、手元の SQLite による事実の保管庫です。

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

設定:

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）

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

Supermemory のグラフ API を使った、意味に基づく長期メモリーです。プロフィールの想起、意味検索、明示的なメモリー操作のツール、そしてセッション終了時の会話の取り込みができます。

ツール: supermemory_store（明示的にメモリーを保存）、supermemory_search（意味の近さで検索）、supermemory_forget（ID または一番近い問い合わせで忘れる）、supermemory_profile（残り続けるプロフィールと直近の文脈）

設定:

hermes memory setup    # select "supermemory"
# Or manually:
hermes config set memory.provider supermemory
echo 'SUPERMEMORY_API_KEY=***' >> ~/.hermes/.env

自前サーバーの場合は次のとおりです。

npx supermemory local

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 の操作、設定時や状態確認のための接続、会話の取り込みは、いずれも決まった接続先を使います。

主な特徴:

• 文脈の囲い込みを自動で行い、思い出したメモリーを保存対象のやり取りから取り除いて、メモリーが自分自身を汚していくのを防ぎます
• セッション全体の取り込み — セッションの区切りで会話をまとめて一度に送ります
• セッション終了時の会話の取り込み（/v4/conversations へ）により、Supermemory 側でより厚いプロフィールとグラフを作れます
• 自前サーバーへの経路が最初から最後まで揃っていて、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)

Memori

Memori Cloud を使った、構造のある長期メモリーです。終わったやり取りをバックグラウンドで取り込み、ツールの内容も踏まえた文脈を持ち、事実・要約・利用量・登録・フィードバックのための明示的な想起ツールを備えます。

ツール: memori_recall（長期メモリーの検索）、memori_recall_summary（要約された文脈）、memori_quota（利用量・上限）、memori_signup（登録メールの依頼）、memori_feedback（連携についての意見の送信）

設定:

pip install hermes-memori
hermes-memori install
hermes config set memory.provider memori
hermes memory setup

プロバイダーの比較

プロファイルごとの分離

各プロバイダーのデータはプロファイルごとに分かれています。

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

メモリープロバイダーを作る

自分で作る方法は開発者ガイド: メモリープロバイダープラグインにあります。