Hermes Agent Memory 入門：限界とトレードオフ
こんにちは、Lena です。Hermes Agent memory について、ずっと後回しにしていた問いがありました。誰かがそれを「学習する agent」と説明するたびに、私は少し立ち止まってしまう。何を、正確に学ぶのか。そして、それはどこに記憶されるのか。ドキュメントを何度か読み返して、ようやく半分くらい答えに近づけた気がしました。ここでは、そのとき気づいたことを書いています。
私は Hermes を作った人としてではなく、しばらくこのシステムを眺めてきた人として書いています。Hermes の memory が期待どおりに働く場所と、静かにそうではない場所。その差は、マーケティングで使われる言葉が示すより大きい。そこは正直に見ておく価値があると思いました。
Hermes memory が実際に保存しているもの
最初に手放さなければいけなかった誤解があります。Hermes には単一の memory system があるわけではありません。複数あり、それぞれ役割が違います。 私が見てきた混乱の多くは、それらをひとつのものとして扱うところから来ています。
MEMORY.md, USER.md, and frozen session snapshots
組み込みの層は、~/.hermes/memories/ に置かれる2つの markdown file です。Hermes 公式 memory documentationによると、MEMORY.md はおよそ 2,200 characters（約 800 tokens） で上限があり、環境に関する事実、プロジェクトの慣習、agent が残す価値があると判断した学びを保持します。USER.md はもう少し小さく、約 1,375 characters、約 500 tokens。こちらはあなたに関する preferences を保持します。
この2つは、session start 時に frozen snapshot として 読み込まれ、system prompt に注入されます。この frozen という言葉が、最初に読んだとき私が見落としていた部分でした。session の途中で書き込まれた内容はすぐに disk に永続化されます。しかし active prompt の snapshot は、次の session が始まるまで更新されません。
ここで少し考え込みました。これは、以前見たけれど説明できなかった挙動をうまく説明してくれます。agent が何かを保存し、「保存しました」と言う。そのあとで、まだそれを持っていないかのように振る舞う。これは bug ではなく、snapshot model なのです。そこが分かると、小さな不整合に見えていたものが、不整合ではなくなりました。
実務でいう「persistent」とは何か
ここでの「persistent」は確かに意味があります。ただし、マーケティング上の言葉が連想させるより、ずっと狭い意味です。ファイルは sessions をまたいで残ります。けれど、それは agent-curated であって、agent-recorded ではありません。何を保存する価値があるかは LLM が判断します。そして上限があるのも意図的です。小さく安定した system prompt があるから prefix caching は効率的になり、prefix caching は agent の反応が速く感じられる理由の一部でもあります。
だから、誰かが Hermes は「覚えている」と言うとき、より正確にはこうです。小さく、意図的に境界を設けた notebook が各 session の先頭で読み込まれる。そして、それとは別に、過去の会話を検索できる archive が並んで存在する。これは別々の仕組みであり、アクセスのされ方も違います。
Hermes memory が得意なこと
ここは公平に見たいです。組み込みの system は本当に便利です。ただ、多くの人が最初に想像するものではないだけです。
Preferences, environment facts, recurring context
得意なのは、小さく、長く使えて、頻繁に関係する事実です。たとえば：
- "User's project is a Rust web service using Axum + SQLx"
- "User prefers concise responses, dislikes verbose explanations"
- "This machine runs Ubuntu 22.04, has Docker installed"
こういう context は毎回 system prompt に入っていてよいものですし、Hermes はそこをうまく扱います。agent は保存する価値があると判断したときに自動で保存します。entries が増えてくると、consolidation も行います。たとえば3つの「project uses X」という行を、ひとつの project description にまとめるようなことです。短い session や狭い範囲の session では、何も書き込まれないこともあります。それは feature であって failure ではありません。ほとんどの短いタスクは、長期 notebook を汚すべきではないからです。
memory entries に対して prompt-injection attempts を検出する security-scanning step があることにも気づきました。Hermes GitHub sourceで見つけた細部ですが、私はこういう部分が好きです。小さな実装の話に見えます。でも、自分自身の memory を LLM が書くときに何が壊れうるかを、誰かが考えた跡でもあります。
Hermes memory が解決しないこと
ここでは少し足を止める必要がありました。多くの期待はここで崩れます。system が間違ったことをしているからではないと思います。むしろ、memory という言葉が背負っている意味が多すぎるのです。
Bounded memory, session resets, no automatic validation of learned behavior
正直に見ておいたほうがよい点がいくつかあります。
Memory には境界があります。 environment 用に約 ~2,200 chars、user 用に約 ~1,375 chars。上限に達すると、agent は新しいものを追加する前に entries を consolidate するか、削除しなければなりません。その過程で、細かなニュアンスは圧縮されて消えることがあります。 これが一番よくある驚きです。人は memory が増えていくものだと思いがちですが、そうではありません。小さく固定された予算こそが、この設計です。
Session の途中で書いたものは、同じ session には現れません。 frozen snapshot model では、agent は開始時に読み込んだものに基づいて動きます。そのあとで新しい entries を書いたとしても同じです。session を再起動すると、それらは context に入ります。agent に今書いたばかりの内容に基づいて動いてほしいなら、会話の中で明示的に参照する必要があります。自動で現れるとは期待しないほうがよいです。
Agent は保存するかどうかを 判断 しなければなりません。 組み込み memory は judgment-based です。自動の文字起こしではありません。設定可能な nudge_interval が定期的に agent に振り返りを促しますが、短い sessions では本当に empty files のままになることがあります。深読みしすぎかもしれませんが、ここがこの設計で一番伝わっていない部分だと思っています。
Automatic validation はありません。 agent が「lesson learned」を保存し、その lesson が実は間違っていたとしても、それを自動で指摘するものはありません。その fact は、何かに置き換えられるまで snapshot に残ります。Memory は verified knowledge と同じではありません。ある時点で、ある model が、残す価値があると考えたものにすぎません。
Memory is not the same as reusable capability
ここは自分のメモを読み返す必要がありました。Hermes には skills もあります。~/.hermes/skills/ に置かれる markdown documents で、手順、使った tools、うまくいった steps を記録します。Skills は複雑なタスクのあとに反応的に作られます（典型的には 5+ tool calls）。そして progressive disclosure によってオンデマンドで読み込まれます。Level 0 は skill names と short descriptions の一覧だけで、Level 1 は必要になった specific skill の全文を読み込みます。
Memory と skills は別物です。どちらも markdown files に見えるとしても。
Memory は「この user は何を好み、どんな environment にいるか」です。Skills は「この種類の task をどう実行するか」です。preference は agent に OAuth flow の debug 方法を教えてくれません。skill なら教えてくれるかもしれません。この2つを混同することが、「agent が学習していない」と言われるときの最大の混乱源だと思います。学習しているのかもしれない。ただし、あなたが確認している層ではないのです。
Cross-session recall, session search, and where people get confused
MEMORY.md と USER.md に加えて、Hermes はすべての CLI と messaging sessions を ~/.hermes/state.db の SQLite に保存し、FTS5 full-text search を使います。agent は session_search tool を呼び出して過去の conversations を retrieve でき、それらは小さな model によって summarized されます。
知っておくとよい点が2つあります。
FTS5 は keyword-based です。 これは強力で、よく設計された index です。SQLite FTS5 documentation には、content をどのように tokenize し、それらの tokens に基づいて match するかが説明されています。ただし match するのは exact tokens であって、意味ではありません。過去の session で "authentication microservice uses Redis" と言っていたとしても、"what did I tell you about the auth service?" と聞くと retrieve できないかもしれません。agent は session_search を呼ぶべきだと分かっていて、かつ 正しい query terms を使う必要があります。entity resolution も、relationship tracking も、semantic rephrasing もありません。
Session search は automatic ではありません。 それは agent が呼ぶかどうかを判断する tool です。agent が回答前にそれを呼ぶべきだと思わなければ、過去の conversation は参照されません。これは storage gap ではなく behaviour gap です。data はそこにあります。ただ retrieval が起きていないのです。
ここで人は一番 frustrate しやすいように見えます。3週間前に agent が何かを話していたのを見たので、自然に出てくるはずだと思う。出てくることもあります。でも多くの場合、出てきません。search を trigger するものがなかったからです。Vectorize の troubleshooting article on Hermes memory は、こうした failure modes をうまく整理していて、私は2回読み返しました。
Practical design advice for long-running Hermes workflows
助言を書くのは少しためらいます。私はひとつの data point にすぎません。ただ、しばらく見ていて目立ったことはいくつかあります。
組み込み memory は database ではなく、小さな notebook として扱う。 conversation length に応じて拡張する必要があるものは、そこに置くべきではありません。常に context に入っていてほしい安定した facts に使い、budget が尽きれば detail は圧縮されると受け入れる。
大事なことは明示する。 "Remember that my production database runs on port 5433" と言うほうが、agent が自分でそれを flag してくれるのを期待するよりうまくいきます。組み込み memory は curated であって recorded ではありません。そして、何が重要かについての agent の判断は、いつもあなたと一致するとは限りません。
Structured recall が必要なら external provider を使う。 Hermes memory providers page には8つの pluggable options が載っています。Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, and Supermemory です。これらは MEMORY.md と USER.md の上に additively 乗るもので、既存の2つはそのまま動き続けます。組み込み層が消えるわけではありません。external な層が、そこではできないことを補います。
特に cross-session user modelling については、Honcho が peer-based approach を取っています。user と AI の両方を peers として model し、それぞれが自分の representation を持ち、時間とともに observations から更新されます。これは flat fact store とはかなり違う design philosophy です。私自身、どんな場面でこれを選び、どんな場面ではもっと単純な vector store で十分なのか、まだ考えているところです。ただ、multi-pass dialectic reasoning は面白い。特に cold-start と warm-session の区別は気になります。
Memory と capability を混同しない。 次回 agent に何かをよりうまく 実行 してほしいなら、必要なのはおそらく memory entry ではなく skill です。そして次回それが 正しい ことを望むなら、memory も skills も検証してはくれません。検証するのはあなたです。私は結局、ここに戻ってきます。
FAQ
Hermes Agent memory は時間とともに賢くなりますか？
ファイルには facts が蓄積されます。それを「賢くなる」と呼ぶかどうかは、何を意味するか次第です。agent は snapshot にあるものを使いますが、memory edits の history を推論するわけではありません。そういうことをする external provider を追加していない限りは。ここで learn という言葉を使うなら、かなり慎重でいたいです。
なぜ何回か sessions を使っても MEMORY.md が空なのですか？
おそらく agent が保存する価値のあるものを判断しなかったからです。短い session や task-focused な session では、writes が発生しないことはよくあります。nudge_interval config を確認してみてください。agent の判断に頼らず automatic capture が必要なら、external provider を使うほうがよいかもしれません。
Limit を大きくすればいいだけでは？
できます。character limits は ~/.hermes/config.yaml で設定できます。ただし cap には理由があります。snapshot が大きくなるほど、実際の conversation に使える余地は減り、prefix-cache benefits も弱くなります。大きくすることは無料ではありません。
Session の途中で memory はどうなりますか？
writes は disk に保存されます。active prompt は次の session まで更新されません。これは想定された動作です。同じ session 内の memory updates に頼ろうとすると、debug に時間を使うことになります。
Session search は memory と同じですか？
いいえ。Memory は常に読み込まれる snapshot です。Session search は、過去の conversations に対するオンデマンドの keyword lookup です。仕組みも、latency も、failure modes も違います。
この話をまだ閉じる気にはなれません。Hermes Agent memory の stack には、これからも見ておきたいものがたくさんあります。特に、external providers が数か月分の data を持ったあとにどう振る舞うのか。今のところ、私の理解はここにあります。
