Honchoは、Hermes の組み込みメモリシステムの上に、弁証法的推論と高度なユーザーモデリング機能を追加した、AI ネイティブのメモリバックエンドです。単純なキー・バリューストレージとは異なり、Honcho は会話が行われた後に推論することで、ユーザーがどのような人物であるか – 好み、コミュニケーションスタイル、目標、行動パターン – の動的モデルを維持します。

Hermes エージェント☤ 入門 : 機能 – コア : Honcho メモリ

作成 : Masashi Okumura (@classcat.com)
作成日時 : 08/14/2026
バージョン : Hermes Agent v0.20.1 (2026.8.13)

* 本記事は hermes-agent.nousresearch.com/docs の以下のページを参考にしています :

Features – Core : Honcho Memory

* サンプルコードの動作確認はしておりますが、必要な場合には適宜、追加改変しています。

Hermes エージェント☤ 入門 : 機能 – コア : Honcho メモリ

ℹ️ Honcho はメモリプロバイダプラグインです。
Honcho はメモリプロバイダシステムに統合されています。以下のすべての機能は、統一されたメモリプロバイダ・インターフェースを通じて利用できます。

Honcho が付け加えること

機能	組み込みメモリ	Honcho
セッション間永続性	✔ ファイルベースの MEMORY.md/USER.md	✔ API を使用したサーバーサイド
ユーザープロファイル	✔ エージェントの手動キュレーション	✔ 自動弁証法推論
セッション概要	–	✔ セッションスコープのコンテキスト注入
マルチエージェント分離	–	✔ ピアごとのプロファイル分離
観測モード	–	✔ 統一観測または指向性観測
結論 (得られた知見)	–	✔ サーバー側でのパターンに関する推論
履歴検索	✔ FTS5セッション検索	✔ 結論に対するセマンティック検索

弁証法的推論 : 会話の各ターン (dialecticCadence によって制御) の後、Honcho はやり取りを分析し、ユーザーの好み、習慣、目標に関する洞察を導出します。これらの洞察は時間とともに蓄積され、ユーザーが明示的に述べた内容を超えた、より深い理解をエージェントに与えることができます。この弁証法は、自動的なコールド/ウォーム・プロンプト選択による複数パスの深度 (1-3 パス) をサポートします – コールドスタートクエリは一般的なユーザーファクトに焦点を当て、ウォームクエリはセッションスコープのコンテキストを優先します。

セッションスコープのコンテキスト : 基本コンテキストに、ユーザー表現とピアカードに加えてセッション概要が含まれるようになりました。これにより、エージェントは現在のセッションで既に議論された内容を把握でき、重複を減らし、継続性を確保できます。

マルチエージェントプロファイル : 複数の Hermes インスタンスが同じユーザーと会話する場合 (例えば、コーディングアシスタントやパーソナルアシスタントなど)、Honchoは個別の「ピア (peer)」プロファイルを維持します。各ピアは自身の観測結果と結論のみを参照できるため、コンテキストの相互汚染を防ぎます。

セットアップ

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

Or configure manually:

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

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

Get an API key at honcho.dev.

アーキテクチャ

2 層コンテキスト注入

各ターン (ハイブリッドモードまたはコンテキストモード) で、Honchoはシステムプロンプトに注入される 2 層のコンテキストを組み立てます :

基本コンテキスト – セッション概要、ユーザー表現、ユーザー・ピアカード、AI 自己表現、AI アイデンティティ・カード。contextCadenceで更新されます。これは「このユーザーは誰か (who is this user)」という層です。
弁証法的補足 : ユーザーの現在の状態とニーズに関する LLM 合成推論。dialecticCadenceで更新されます。これは「今、何が重要か (what matters right now)」という層です。

両方の層は連結され、contextTokens の予算 (設定されている場合) に合わせて切り詰められます。

コールド/ウォームプロンプトの選択

この弁証法 (dialectic) システムは、以下の 2 つのプロンプト・ストラテジーから自動的に選択します :

コールドスタート (基本コンテキストがまだない場合) : 一般的な質問 ― 「この人は誰ですか？その人の好み、目標、仕事のスタイルは何ですか？」(“Who is this person? What are their preferences, goals, and working style?”)
ウォームセッション (基本コンテキストが存在する場合) : セッションスコープの質問 ― 「このセッションでこれまでに話し合われた内容を踏まえて、このユーザーに関する最も関連性の高いコンテキストは何ですか？」(“Given what’s been discussed in this session so far, what context about this user is most relevant?”)

これは、基本コンテキストが既に設定されているかどうかに基づいて自動的に行われます。

3 つの直交する設定ノブ

コストと深度は、3 つの独立したノブで制御されます :

(ノブ – 制御 – デフォルト)
contextCadence – context() API 呼び出し間のターン数 (基本層更新) – 1
dialecticCadence – peer.chat() LLM 呼び出し間のターン数 (弁証法的層更新) – 2 (推奨 1–5)
dialecticDepth – 弁証法的呼び出し毎の .chat() のパス数 (1-3) – 1

これらは直交しています – コンテキストの高頻度な更新で弁証法頻度を低くしたり、低頻度でマルチパスの弁証法を深く実行したりできます。例: contextCadence: 1, dialecticCadence: 5, dialecticDepth: 2 は、毎ターン基本コンテキストを更新し、5 ターンごとに弁証法を実行し、各弁証法実行で 2 パスを実行します。

弁証法深度 (複数パス)

dialecticDepth > 1 の場合、弁証法呼び出しごとに複数の .chat() パスが実行されます :

パス 0 : コールドまたはウォームプロンプト（上記参照）
パス 1 : 自己監査 ― 初期評価のギャップを特定し、最近のセッションからのエビデンスを統合します。
パス 2 : 調整 ― 以前のパス間の矛盾をチェックし、最終的な統合結果を生成します。

各パスは、比例した推理レベルを使用します (初期のパスは軽量、メインパスには基本レベル)。dialecticDepthLevels を使用すると、パスごとのレベルをオーバーライドできます – e.g., 深度 3 で実行する場合 [“minimal”, “medium”, “high”]。

前のパスで強力なシグナル (長い構造化された出力) が返された場合、パスは早期に終了しますので、深度3 は必ずしも 3回の LLM 呼び出しを意味するわけではありません。

設定オプション

Honcho の設定は、~/.honcho/config.json (グローバル) または $HERMES_HOME/honcho.json（プロファイルローカル) で行います。セットアップウィザードがこれらの設定に対応します。

設定例

{
  "hosts": {
    "hermes": {
      "peerName": "xxx",
      "aiPeer": "hermes",
      "workspace": "hermes",
      "pinUserPeer": false,
      "observationMode": "directional",
      "writeFrequency": "async",
      "recallMode": "hybrid",
      "dialecticCadence": 2,
      "dialecticReasoningLevel": "low",
      "sessionStrategy": "per-session",
      "enabled": true,
      "saveMessages": true
    }
  },
  "baseUrl": "http://localhost:8000"
}

認証付き自己ホスト型 Honcho

Hermes を自己ホスト型の Honcho サーバーに接続する場合、`hermes honcho setup` (及び `hermes memory setup`) では、ベース URL の後にローカル JWT / ベアラートークンの入力を求めます。認証アクセスを有効にするには、サーバーの AUTH_JWT_SECRET (Honcho compose 環境変数) で署名された JWT を貼り付けます; AUTH_USE_AUTH=false で実行されているサーバーの場合は、この部分を空白のままにします。ローカルトークンは、クラウド apiKey とは別に、ホストブロック (honcho.json の hosts.<host>.apiKey) に保存されるため、後で Cloud or local? のプロンプトをクラウドに戻す際に、どちらの認証情報も失うことはありません。

完全な設定リファレンス

(キー – デフォルト – 説明)
contextTokens – null (uncapped) – ターンごとに自動注入されるコンテキストのトークン予算。上限を設定するには整数 (e.g. 1200) を設定します。単語の境界で切り捨てられます。
contextCadence – 1 – context() API 呼び出し間の最小ターン数 (ベース層の更新)
dialecticCadence – 2 – peer.chat() LLM 呼び出し間の最小ターン数 (弁証法層)。推奨 1-5。ツールモードでは関係ありません – モデル呼び出しは明示的に行われます。
dialecticDepth – 1 – 弁証法呼び出しあたりの .chat() パスの回数。1-3 に制限されます。
dialecticDepthLevels – null – パスごとの推論レベルのオプション配列、e.g. [“minimal”, “low”, “medium”]。比例的なデフォルト値をオーバーライドします。
dialecticReasoningLevel – ‘low’ – 基本推論レベル：minimal, low, medium, high, max
dialecticDynamic – true – true の場合、モデルは tool パラメータを介して呼び出しごとに推論レベルをオーバーライドできます。
dialecticMaxChars – 600 – システムプロンプトに注入される弁証法の結果の最大文字数
recallMode – ‘hybrid’ – hybrid (自動注入＋ツール)、context (注入のみ)、tools (ツールのみ)
writeFrequency – ‘async’ – メッセージをフラッシュするタイミング: async (バックグラウンドスレッド)、turn (同期)、session (終了時のバッチ)、または整数 N
saveMessages – true – Honcho API へのメッセージの永続化を行うかどうか
observationMode – ‘directional’ – directional (すべてオン) または unified (共有プール)。より詳細な制御を行うには、observation オブジェクトを使用してオーバーライドします。
messageMaxChars – 25000 – add_messages() で送信されるメッセージあたりの最大文字数。超過した場合は分割されます。
dialecticMaxInputChars – 10000 – peer.chat() への弁証法クエリ入力の最大文字数
sessionStrategy – ‘per-directory’ – per-directory, per-repo, per-session, または global
pinUserPeer – false – ゲートウェイのみ。true の場合、すべてのプラット・フォームユーザーは peerName に集約されます。
userPeerAliases – {} – ゲートウェイのみ。ランタイム ID のピアへのマップ（{“7654321”: “alice”}）。多対一
runtimePeerPrefix – “” – ゲートウェイのみ。Namespaces unknown runtime IDs (telegram_7654321) when no alias matches

観察 (Observation)（Directional vs. Unified）

Honchoは会話をピア同士がメッセージを交換するものとしてモデル化しています。各ピアには、Honcho の SessionPeerConfig に1対1でマップする 2 つの観察トグルがあります :

(トグル – 効果)
observeMe – Honcho は、自身のメッセージからこのピアの表現を構築します。
observeOthers – このピアは他のピアのメッセージを観察します (ピア間の推論に提供)

Two peers × two toggles = four flags. observationMode は省略したプリセットです :

プリセット	ユーザフラグ	AI フラグ	意味
“directional” (デフォルト)	me: on, others: on	me: on, others: on	完全な相互監視。ピア間の弁証法が可能になります – 「ユーザの発言と AI の応答に基づいて、AI はユーザーについて何を知っているのか」
“unified”	me: on, others: off	me: off, others: on	共有プールセマンティクス ― AI はユーザーのメッセージのみを監視し、ユーザーピアは自身のモデル化のみを行います。

Override the preset with an explicit observation block for per-peer control:

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

以上

月	火	水	木	金	土	日
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31