Hermes Agent Memory 解讀：限制同取捨
嗨，我是 Lena。關於 Hermes Agent memory，我一直有個問題拖住冇認真拆開。每次有人形容佢係「會學習嘅 agent」，我都會停一停。到底學咗啲咩？又記咗喺邊度？我翻過幾次 docs，先覺得自己勉強有半個答案。以下係我留意到嘅嘢。
我寫呢篇，唔係以 Hermes 建構者嘅身份，而係以一個旁觀者嘅身份：我睇住呢個系統夠耐，慢慢睇到佢嘅 memory 喺邊啲地方真係做到大家預期嘅事，又喺邊啲地方其實靜靜地冇做到。兩者之間嘅落差，比 marketing 語言暗示嘅大。老實講清楚，係值得嘅。
Hermes memory 實際儲存咗啲咩
我第一件要 unlearn 嘅事係：Hermes 唔係只有一套 memory system。佢有幾套，而且做嘅唔係同一份工。 我見過大部分混亂，都係因為大家將佢哋當成同一樣嘢。
MEMORY.md, USER.md, and frozen session snapshots
內建呢一層，係放喺 ~/.hermes/memories/ 入面嘅兩個 markdown files。根據 Hermes 官方 memory documentation，MEMORY.md 上限大約係 2,200 characters（大約 800 tokens），用嚟保存 environment facts、project conventions，同埋 agent 覺得值得留低嘅 lessons。USER.md 細啲——大約 1,375 characters，約 500 tokens——用嚟保存關於你嘅 preferences。
兩個 file 都會喺 session start 時以 frozen snapshot 形式載入，再注入到 system prompt 入面。呢個詞——frozen——就係我第一次讀嗰陣一直漏咗嘅重點。session 中途寫入嘅內容會即刻 persist 到 disk，但 active prompt 入面嘅 snapshot 唔會 refresh，要等下一個 session 開始先會更新。
我喺呢度停咗一陣。呢個解釋咗一種我見過、但之前擺唔到位嘅行為：agent 儲存咗某樣嘢，亦都話自己儲存咗，但之後又好似未真正有嗰樣嘢咁繼續做。呢個唔係 bug——係 snapshot model。明白呢點之後，幾個細小嘅不一致感就唔再咁不一致。
「Persistent」喺實務上即係咩
呢度嘅「persistent」真係有作用，但佢做嘅嘢比 marketing 字眼暗示嘅窄。Files 會跨 sessions 保留。佢哋係 agent-curated，唔係 agent-recorded——由 LLM 決定咩值得保存。而且佢哋係有意設上限嘅：細而穩定嘅 system prompt，先可以令 prefix caching 有效率；而 prefix caching 亦係點解 agent 感覺反應快嘅原因之一。
所以，當有人話 Hermes「記得」時，更準確啲通常係：一個細小、刻意設邊界嘅 notebook，會喺每次 session 頂部重新載入；旁邊仲有一個可搜尋嘅過往對話 archive。兩樣唔同嘅嘢，兩種唔同嘅 access patterns。
Hermes memory 擅長做咩
我想公平啲講。內建 system 係真係有用——只係佢唔係大部分人一開始想像嗰樣嘢。
Preferences, environment facts, recurring context
佢最啱保存細小、耐用、經常相關嘅 facts。例如：
- "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 堆多咗，佢亦會 consolidate——例如將三條「project uses X」合併成一段 project description。喺好短或者範圍好窄嘅 sessions 入面，你可能完全見唔到寫入——呢個係 feature，唔係 failure。大部分短任務本來就唔應該污染你嘅長期 notebook。
我亦留意到 memory entries 有一個 security-scanning step，用嚟捉 prompt-injection attempts。呢點係我喺 Hermes GitHub source 見到嘅，我幾欣賞呢個細節。佢係細，但正正係呢種細節會話畀你知：有人諗過當一個 LLM 負責寫自己嘅 memory 時，會有咩地方可能出事。
Hermes memory 解決唔到咩
呢度我就要慢落嚟。好多期望會喺呢度斷開。我唔覺得係 system 做錯咗——我反而覺得係 memory 呢個詞承載咗太多意思。
Bounded memory, session resets, no automatic validation of learned behavior
有幾件事值得老實講：
Memory 係有邊界嘅。 environment 大約 ~2,200 chars，user 大約 ~1,375 chars。去到 limit 之後，agent 要先 consolidate 或者移除 entries，先可以加新嘢。細緻嘅 specifics，可能就喺呢個過程入面被壓縮走。 呢個係最常見嘅 surprise——人哋以為 memory 會增長；其實唔會。細小而固定嘅 budget，就係呢個設計。
Session 中途寫入，唔會喺同一個 session 入面出現。 frozen snapshot model 意味住 agent 會按開始時載入嘅內容行動，即使之後寫咗新 entries。重開 session，佢哋先會入到 context。如果你需要 agent 即刻按佢剛剛寫低嘅嘢做，就喺 conversation 入面明確引用——唔好期待佢自動出現。
Agent 必須自己 決定 要保存。 內建 memory 係 judgment-based。冇 automatic transcription。可設定嘅 nudge_interval 會定期提示 agent reflect，但喺短 sessions 入面，你真係可能見到 empty files。我可能諗得太多，但我覺得呢個係整個設計最少被講清楚嘅部分。
冇 automatic validation。 如果 agent 保存咗一條「lesson learned」，但嗰條 lesson 其實係錯嘅，冇任何機制會標記佢。嗰個 fact 會一直留喺 snapshot，直到有其他嘢替換佢。Memory 唔等於 verified knowledge——佢只係某個 model 喺某個時間點覺得值得保留嘅嘢。
Memory is not the same as reusable capability
呢部分我仲要返去重讀自己嘅 notes。Hermes 亦都有 skills——放喺 ~/.hermes/skills/ 入面嘅 markdown documents，用嚟記錄 procedures、用過嘅 tools，同埋 work 過嘅 steps。Skills 會喺複雜任務之後 reactively 建立（通常係 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 點樣 debug OAuth flow；一個 skill 可能會。將兩者混埋一齊，我覺得係大家話「agent 冇學習」時最大嘅混亂來源。佢可能真係有 learning——只係唔係發生喺你檢查緊嗰一層。
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 可以 call 一個 session_search tool 去 retrieve 過往 conversations，之後再用一個 small model summarize。
有兩個 details 值得知道。
FTS5 係 keyword-based。 佢係一個強大、工程上成熟嘅 index——SQLite FTS5 documentation 有講佢點樣 tokenize content，並按 tokens matching——但佢 match 嘅係 exact tokens，唔係 meaning。如果過往 session 講過 "authentication microservice uses Redis"，你問 "what did I tell you about the auth service?"，佢未必 retrieve 到。agent 要知道要 call session_search，而且 要用啱 query terms。呢度冇 entity resolution，冇 relationship tracking，亦冇 semantic rephrasing。
Session search 唔係 automatic。 佢係一個由 agent 決定 call 唔 call 嘅 tool。如果 agent 回答前冇諗到要 call，過往 conversation 就唔會被 consult。呢個係 behaviour gap，唔係 storage gap——data 喺度，只係 retrieval 冇發生。
呢度係我見到人最容易 frustrate 嘅地方。佢哋見過 agent 三個星期前討論過某件事，就假設佢會自然浮現。有時會。好多時唔會，因為冇嘢 trigger search。Vectorize 喺佢哋嘅 troubleshooting article on Hermes memory 入面對呢啲 failure modes 有個幾有用嘅 breakdown，我返去睇咗兩次。
Practical design advice for long-running Hermes workflows
我其實有少少猶豫要唔要俾 advice——我只係一個 data point。但睇咗一段時間之後，有幾樣嘢好突出。
將內建 memory 當成一個細 notebook，唔係 database。 任何需要隨 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 列出八個 pluggable options——Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, and Supermemory。佢哋係 additively 疊喺 MEMORY.md 同 USER.md 上面，而後兩者會照常運作。內建層唔會消失；external 嗰層係補返佢做唔到嘅部分。
特別講 cross-session user modelling，Honcho 用嘅係 peer-based approach——user 同 AI 都被 model 成 peers，各自有自己嘅 representation，並隨住時間由 observations 更新。呢個同 flat fact store 係好唔同嘅 design philosophy。我仲喺度諗，咩時候我會用佢，咩時候一個簡單啲嘅 vector store 已經夠。但 multi-pass dialectic reasoning 係有趣嘅，尤其係 cold-start 同 warm-session 嘅分別。
唔好將 memory 同 capability 混淆。 如果你想 agent 下次將某件事 做得 更好，你大概需要 skill，而唔係 memory entry。如果你想佢下次一定 正確，memory 同 skills 都唔會幫你 validate——你要自己做。呢個就係我一直返去諗嘅地方。
FAQ
Hermes Agent memory 會唔會隨時間變聰明？
Files 會累積 facts。呢件事算唔算「更聰明」，要睇你點定義。agent 會用 snapshot 入面嘅內容，但佢唔會對 memory edits 嘅 history 做 reasoning，除非你加咗一個會做呢件事嘅 external provider。我會小心使用 learn 呢個詞。
點解幾個 sessions 之後，MEMORY.md 仲係空嘅？
最可能係 agent 從來冇判斷到有任何嘢值得保存——短或者 task-focused sessions 好多時都唔會產生 writes。檢查你嘅 nudge_interval config；如果你想要唔依賴 agent judgment 嘅 automatic capture，就可以考慮 external provider。
我可唔可以直接將 limit 調大？
可以。Character limits 可以喺 ~/.hermes/config.yaml 入面設定。但 cap 存在係有原因嘅——snapshot 越大，留俾 actual conversation 嘅空間越少，prefix-cache benefits 亦會越弱。大啲唔係免費。
Memory 喺 session 中途會點？
Writes 會落 disk。active prompt 唔會 refresh，要等下一個 session。呢個係 expected。如果你嘗試依賴同一個 session 入面嘅 memory updates，會花好多時間 debug。
Session search 同 memory 係同一樣嘢嗎？
唔係。Memory 係 always-loaded snapshot。Session search 係對過往 conversations 做 on-demand keyword lookup。機制唔同，latency 唔同，failure modes 亦唔同。
我仲未準備好 close 呢件事。Hermes Agent memory 呢套 stack 入面仲有好多嘢值得繼續觀察——尤其係 external providers 背後有幾個月 data 之後，佢哋會點樣表現。暫時嚟講，我嘅理解就停喺呢度。
