Hermes Agent を読み解く — 記憶アーキテクチャと人格
連載「Hermes Agent を読み解く」第4回。
連載「Hermes Agent を読み解く」全10回
- 第1回 全体像と読み方
- 第2回 コアの会話ループ
- 第3回 状態管理とコンパクション
- 第4回 記憶アーキテクチャと人格（本記事）
- 第5回 ツールシステム
- 第6回 マルチエージェント並列
- [第7回 Kanban 永続タスクボード]
- [第8回 接続層とインタフェース総覧]
- [第9回 拡張運用]
- [第10回 セキュリティと安全運用]
はじめに — 圧縮するエージェントに人格はあるか
前回、Hermes は context が半分埋まると会話の中盤を要約して畳む、と書いた。畳むとは忘れることだ。では問いたい——毎ターン忘れていくエージェントに、連続した「その人らしさ」は宿るのか。
私はこの連載を通じて一つのテーゼを掲げている。人格 = 知能 × 記憶。モデルの賢さ（知能）だけでは人格は立ち上がらない。同じモデルでも、何を覚えていて、何を文脈として持ち込むかが違えば、振る舞いは別人になる。記憶は人格の動的な基盤だ。
そして圧縮はその基盤を脅かす。第4回は、Hermes がどうやってこの脅威に抗い、記憶を再注入することで人格の連続性を担保しているかを読む。
1. 記憶は 3 層
Hermes の記憶は時間スケールで 3 層に分かれる。
- 会話 context（揮発） — 今まさに window にある会話。圧縮で畳まれうる、最も儚い層
- MEMORY.md / USER.md（中期） — ファイルとして残る。エージェントの覚え書きと、ユーザー像
- 長期プロバイダ（永続） — 外部の専用メモリ基盤に貯める層
揮発層が圧縮で痩せても、中期・長期から引き直せる。これが連続性の鍵になる。
2. 抽象化層
長期記憶は単一実装に縛られない。MemoryProvider という抽象基底クラス（ABC）が窓口になっている。prefetch（先読み）/ sync_turn（ターン同期）/ on_session_*（セッション境界のフック）といったメソッドを定義し、各バックエンドがこれを実装する。
重要な制約が一つ。ビルトインのメモリは常時動き、外部プロバイダは 1 つだけ——という排他制御が効いている（memory_manager.py:245-265）。複数の外部メモリを同時にぶら下げて記憶が分裂する事故を、設計で防いでいる。
3. ライフサイクルと注入
ここが山場の核心だ。記憶をどのタイミングで、どこに差し込むか。
非同期先読み: メモリの取得は遅い（外部 API を叩くこともある）。だから Hermes は前のターンのうちに次ターン用の記憶を先読みしておき、次ターンの頭でそれを消費する。レイテンシをターン境界に隠す古典的だが効く手だ。
注入位置: 取得した記憶は <memory-context> タグでユーザーメッセージ側に注入される。ここが巧い。システムプロンプトは不変に保つ——記憶を system prompt に混ぜると毎ターン中身が変わり、prefix キャッシュが効かなくなる。ユーザーメッセージ側に寄せることで、system prompt を固定し、プロバイダの prefix キャッシュ（同一接頭辞の課金・遅延の節約）を温存する。記憶の鮮度とキャッシュ効率を両立させる判断だ。
スクラバ: ユーザー入力に <memory-context> のような制御タグが紛れ込むと、注入を偽装される恐れがある。これを防ぐため、注入前に入力をスクラブ（無害化）してタグ注入を弾く。第10回のプロンプトインジェクション論にもつながる防御だ。
4. ケーススタディ: Honcho
ビルトイン以外の長期プロバイダは 8 つ（honcho + 他 7）。代表として Honcho を見る。Honcho は対話相手を「peer」としてモデル化し、相手の心的状態の表象（representation）を構築する。
- peer / representation / peer card — 相手を peer として表象化し、要約カードを持つ
-
dialectic（
reasoning_level） — 記憶からの推論の深さを段階制御 - recall mode（hybrid / context / tools） — 思い出し方を、context 注入・ツール経由・両者ハイブリッドから選ぶ
-
SOUL.md seeding —
SOUL.mdで初期人格・前提を seed する
SOUL.md という命名に思想が出ている。記憶基盤が「魂の種」を持つ、という発想だ。本連載のテーゼと正面から響き合う。
5. Honcho 以外の 7 バックエンド比較
残る 7 つはこうだ（plugins/memory/ 直下のディレクトリ実測。エンドポイントは実コードで確認した値）。
| プロバイダ | 型 | ストレージ / 検索 | 要約の在処 | 外部サービス |
|---|---|---|---|---|
mem0 |
SaaS | サーバ側で事実抽出 + 意味検索 + rerank | サーバ | Mem0（正確な URL は要確認） |
supermemory |
SaaS | ドキュメント + profile、hybrid 検索。session 終了時に一括 ingest | プロファイル合成 | api.supermemory.ai/v4 |
retaindb |
SaaS | 意味検索 + dialectic。SQLite の耐久キューで書き込みをクラッシュ耐性化 | サーバ | api.retaindb.com |
openviking |
自前ホスト | 階層 KB（viking://）、L0/L1/L2 段階取得。commit 時に 6 カテゴリ自動抽出 |
自動抽出 |
127.0.0.1:1933（既定、ByteDance 系） |
byterover |
ローカル CLI |
brv CLI 経由の階層ツリー、LLM curation。prefetch は同期 |
LLM curate | ローカル ~/.brv-cli（任意でクラウド同期） |
hindsight |
クラウド/ローカル | ナレッジグラフ + 多戦略検索（意味/キーワード/エンティティ）。単一ライターキュー | reflect 合成 |
api.hindsight.vectorize.io / 埋込 localhost:8888
|
holographic |
完全ローカル | ローカル SQLite（facts + entity 解決 + 信頼スコア）。FTS5 + Jaccard + HRR（1024 次元、numpy 任意） | 無し（生事実 + trust 加重） | なし（memory_store.db） |
軸は 2 つ。SaaS かローカルか（記憶を外部に預けるか手元に置くか）、そして要約をどこで作るか（プロバイダ側で要約するか、Hermes 側で渡すか）。表を縦に眺めると、4 つは SaaS の薄いラッパー（サーバに丸投げ）、holographic は完全オフラインの本格実装（FTS5 + HRR をローカルで回す）、hindsight はクラウド/埋込の両対応、openviking は自前ホスト前提——と、はっきり性格が分かれる。プライバシーとレイテンシのトレードオフが、この選択に凝縮されている。ローカル LLM 派の私は当然 holographic のような手元完結型を選ぶが、要約品質との綱引きは残る。
SaaS 型プロバイダの内部アルゴリズムや正確なサーバ URL は、ローカルのコードだけでは確定できない。ここでは Hermes 側のインタフェースから読み取れる範囲に留める。
6. テーゼ — 圧縮と再注入
ここまでを一本の線にまとめる。
圧縮（第3回）は、人格の動的基盤である記憶を脅かす。会話 context を畳むたび、エージェントは「その人らしさ」を構成していた文脈を失いかける。
それを救うのが再注入だ。中期（MEMORY.md / USER.md）と長期プロバイダから、先読みされた記憶が次ターンの頭で <memory-context> として戻ってくる。畳んで忘れ、引き直して思い出す——この往復こそが、揮発する context の上に連続した人格を立ち上げる。
人格 = 知能 × 記憶。知能（モデル）が同じでも、記憶の層構造と再注入の設計が変われば、エージェントの人格は変わる。Hermes の記憶アーキテクチャは、この等式を実装に落とした一つの解答だ。
次回からは後半戦。エージェントの「能力」——tools/ の自己登録レジストリと、実際に呼べる全 71 ツールのカタログを端折らず並べる。
対応マップ章: §13, §18 / 行番号は hermes update でずれうる
クイックイタレート株式会社
IoT / 電力監視 / AI / 衛星・無線通信 / システムインテグレーション/
ローカル LLM・エージェント基盤に関するお問い合わせはお気軽にどうぞ。