Honcho メモリー

Honcho は AI 前提のメモリー基盤で、Hermes に組み込まれたメモリーの上に、対話的な推論と深いユーザーモデリングを足します。単純なキーと値の保存ではなく、会話が終わったあとにその内容を考え直すことで、ユーザーがどんな人か — 好み、話し方、目標、行動の傾向 — を捉えたモデルを保ち続けます。

Honcho が足すもの

対話的な推論: 会話のやり取りのたびに（dialecticCadence で間隔を決めます）、Honcho はそのやり取りを分析し、ユーザーの好み・習慣・目標についての気づきを導き出します。これが積み重なることで、エージェントはユーザーが口に出したことの先まで理解を深めていきます。この推論は複数回（1〜3 回）通すことができ、コールド用とウォーム用のプロンプトを自動で選び分けます。コールドスタートの問い合わせはユーザーの一般的な事実に、ウォームの問い合わせはセッション単位の文脈に重きを置きます。

セッション単位の文脈: 基本となる文脈には、ユーザー表現とピアカードに加えてセッションの要約も入るようになりました。これで、いまのセッションですでに話した内容をエージェントが把握でき、同じ話の繰り返しが減って話がつながります。

複数エージェントのプロフィール: 同じユーザーに複数の Hermes（たとえばコーディング用の相棒と、身の回りのことを頼む相棒）が話しかける場合、Honcho は「ピア」ごとに別々のプロフィールを保ちます。各ピアは自分の観測と結論だけを見るので、文脈が互いに混ざりません。

セットアップ

hermes memory setup    # select "honcho" from the provider list

手で設定する場合は次のとおりです。

# ~/.hermes/config.yaml
memory:
  provider: honcho

echo 'HONCHO_API_KEY=***' >> ~/.hermes/.env

API キーは honcho.dev で取得します。

構成

2 層で差し込まれる文脈

hybrid または context モードでは、Honcho は毎ターン、システムプロンプトに差し込む文脈を 2 層に組み立てます。

1. 基本となる文脈 — セッションの要約、ユーザー表現、ユーザー側のピアカード、AI 自身の表現、AI の識別カード。contextCadence の間隔で更新されます。「このユーザーは誰か」を受け持つ層です。
2. 対話的推論による追加分 — ユーザーのいまの状態と必要としていることについて、LLM がまとめた推論です。dialecticCadence の間隔で更新されます。「いま何が大事か」を受け持つ層です。

両方の層はつなげたうえで、contextTokens の上限（設定していれば）まで切り詰められます。

コールドとウォームのプロンプトの選び分け

対話的推論は、2 種類のプロンプトを自動で選び分けます。

• コールドスタート（基本となる文脈がまだない）: 一般的な問い合わせ — 「この人はどんな人か。好み、目標、仕事の進め方は何か」
• ウォームなセッション（基本となる文脈がある）: セッション単位の問い合わせ — 「このセッションでここまで話した内容を踏まえて、このユーザーについていま一番関係のある文脈は何か」

これは、基本となる文脈が入っているかどうかを見て自動的に決まります。

独立した 3 つの設定つまみ

費用と深さは、互いに独立した 3 つのつまみで決まります。

この 3 つは互いに影響しません。基本の文脈は頻繁に更新しつつ対話的推論はたまにだけ、といった組み合わせも、深い複数回の推論を低い頻度で、という組み合わせもできます。たとえば contextCadence: 1, dialecticCadence: 5, dialecticDepth: 2 なら、基本の文脈は毎ターン更新し、対話的推論は 5 ターンごとに動き、そのたびに 2 回通します。

対話的推論の深さ（複数回）

dialecticDepth が 1 より大きいと、対話的推論のたびに .chat() を複数回通します。

• 0 回目: コールドまたはウォームのプロンプト（前述のとおり）
• 1 回目: 自己点検 — 最初の見立ての足りないところを見つけ、直近のセッションから根拠を集めます
• 2 回目: 突き合わせ — それまでの結果に食い違いがないか調べ、最終的なまとめを出します

各回は比率に応じた推論レベルを使います（前半は軽く、本番の回は基準どおり）。回ごとのレベルは dialecticDepthLevels で上書きできます。3 回通すなら ["minimal", "medium", "high"] のように書きます。

前の回が強い手応えのある結果（長くて構造のある出力）を返していれば、そこで打ち切られます。深さ 3 が必ず LLM 呼び出し 3 回になるわけではありません。

セッション開始時の先読み

セッションの初期化時に、Honcho は設定された dialecticDepth のままバックグラウンドで対話的推論を走らせ、その結果を 1 ターン目の文脈の組み立てにそのまま渡します。まだ何も知らないピアに対して 1 回だけ通しても中身の薄い結果になりがちなので、ユーザーが話し出す前に点検と突き合わせまで回しておくわけです。1 ターン目までに先読みが間に合わなければ、1 ターン目は時間制限つきの同期呼び出しに切り替わります。

問い合わせに応じた推論レベル

自動で差し込まれる対話的推論は、問い合わせの長さに応じて dialecticReasoningLevel を上げます。120 文字以上で 1 段階、400 文字以上で 2 段階上がり、reasoningLevelCap（既定は "high"）が上限です。reasoningHeuristic: false にすると、自動の呼び出しはすべて dialecticReasoningLevel に固定されます。使えるレベルは minimal、low、medium、high、max です。

設定できる項目

Honcho の設定は ~/.honcho/config.json（全体）または $HERMES_HOME/honcho.json（プロファイル単位）に書きます。セットアップウィザードがこれを代わりにやってくれます。

認証つきの自前 Honcho サーバー

自前で立てた Honcho サーバーに Hermes を向けるとき、hermes honcho setup（および hermes memory setup）はベース URL のあとに ローカルの JWT／ベアラートークンを尋ねます。サーバーの AUTH_JWT_SECRET（Honcho の compose の環境変数）で署名した JWT を貼れば、認証つきでアクセスできます。AUTH_USE_AUTH=false で動かしているサーバーなら空のままで構いません。このローカルのトークンはホストブロックの下（honcho.json の hosts.<host>.apiKey）に、クラウド用の apiKey とは別に保存されるので、あとで Cloud or local? の質問を cloud に戻しても、どちらの認証情報も失われません。

設定の全一覧

セッションの持ち方は、Honcho のセッションを自分の作業にどう対応させるかを決めます。

• per-session — hermes を実行するたびに新しいセッションになります。まっさらな状態から始まり、記憶はツールで取り出します。使い始めたばかりの人におすすめです。
• per-directory — 作業ディレクトリごとに Honcho のセッションを 1 つ持ちます。実行をまたいで文脈が積み上がります。
• per-repo — git リポジトリごとにセッションを 1 つ持ちます。
• global — すべてのディレクトリで 1 つのセッションを使います。

想起モードは、記憶が会話にどう流れ込むかを決めます。

• hybrid — 文脈がシステムプロンプトに自動で差し込まれ、かつツールも使えます（いつ問い合わせるかはモデルが決めます）。
• context — 自動の差し込みだけで、ツールは出しません。
• tools — ツールだけで、自動の差し込みはありません。エージェントが honcho_reasoning や honcho_search などを自分で呼ぶ必要があります。

想起モードごとの設定の効き方:

tools モードでは、主導権は完全にモデルにあります。使いたいときに honcho_reasoning を、自分で選んだ reasoning_level で呼び出します。間隔や上限の設定が効くのは、自動の差し込みがあるモード（hybrid と context）だけです。

ゲートウェイでの識別子の対応づけ

ここでの設定が意味を持つのは、Hermes のゲートウェイを動かしているときだけです。ゲートウェイは、利用者がプラットフォーム固有の実行時 ID（Telegram の UID、Discord の snowflake、Slack のユーザー）を持ってやって来る唯一の入口です。CLI、TUI、デスクトップのセッションには実行時 ID がなく、常に peerName に行き着くので、ゲートウェイを使っていなければこれらのキーは何もしません。

セットアップウィザードはゲートウェイのプラットフォームがつながっているかを調べ、なければこの手順ごと飛ばします。動くときは 1 つだけ質問し — *このゲートウェイには誰が話しかけますか* — その答えからキーを決めます。

質問のところで [e] を選ぶと、3 つのキーを直接設定できます。

解決の処理はキーを上から順に試し、最初に当たったものを使います。pinUserPeer → userPeerAliases[id] → runtimePeerPrefix + id → 生の実行時 ID → peerName → セッションキーでの代替、の順です。

観測（directional と unified）

Honcho は会話を、ピア同士がメッセージをやり取りするものとして扱います。各ピアには 2 つの観測の切り替えがあり、これは Honcho の SessionPeerConfig と 1 対 1 で対応します。

ピア 2 つ × 切り替え 2 つで、フラグは 4 つになります。observationMode はその組み合わせに名前を付けたものです。

ピアごとに細かく決めたいときは、明示的な observation ブロックで組み合わせを上書きします。

"observation": {
  "user": { "observeMe": true,  "observeOthers": true },
  "ai":   { "observeMe": true,  "observeOthers": false }
}

よくある使い方は次のとおりです。

Honcho のダッシュボードで設定したサーバー側の切り替えは、手元の既定値より優先されます。Hermes がセッションの開始時にそれを取り込みます。

ツール

Honcho をメモリープロバイダーとして有効にすると、5 つのツールが使えるようになります。

CLI コマンド

hermes honcho のサブコマンドは、Honcho が有効なメモリープロバイダーになっているときにだけ登録されます（config.yaml の memory.provider: honcho）。入れたばかりのときは hermes memory setup honcho で Honcho を直接設定してください（hermes memory setup を実行して一覧から選んでも構いません）。そのあと次に実行したときから hermes honcho のサブコマンドが現れます。

hermes memory setup honcho    # Configure Honcho directly (works before activation)
hermes honcho status          # Connection status, config, and key settings
hermes honcho setup           # Redirects to `hermes memory setup` (post-activation alias)
hermes honcho strategy        # Show or set session strategy (per-session/per-directory/per-repo/global)
hermes honcho peer            # Show or update peer names + dialectic reasoning level
hermes honcho mode            # Show or set recall mode (hybrid/context/tools)
hermes honcho tokens          # Show or set token budget for context and dialectic
hermes honcho identity        # Seed or show the AI peer's Honcho identity
hermes honcho sync            # Sync Honcho config to all existing profiles
hermes honcho peers           # Show peer identities across all profiles
hermes honcho sessions        # List known Honcho session mappings
hermes honcho map             # Map current directory to a Honcho session name
hermes honcho enable          # Enable Honcho for the active profile
hermes honcho disable         # Disable Honcho for the active profile
hermes honcho migrate         # Step-by-step migration guide from openclaw-honcho

hermes honcho からの移行

以前、単独の hermes honcho setup を使っていた場合は次のようになります。

1. これまでの設定（honcho.json または ~/.honcho/config.json）はそのまま残ります
2. サーバー側のデータ（記憶、結論、ユーザーのプロフィール）もそのまま残ります
3. config.yaml に memory.provider: honcho を設定すれば、また動き出します

ログインし直したり設定をやり直したりする必要はありません。hermes memory setup を実行して「honcho」を選べば、ウィザードが今ある設定を見つけます。

詳しい説明

すべての項目はメモリープロバイダー — Honcho にあります。