Hermes Agent 持久記憶系統：讓 AI 真的記住你和你的專案

跟 AI 工具打交道超過三個月，你一定踩過這個坑：開新 session，全部背景要重新交代。「這個專案用 TypeScript 不是 JavaScript」、「我的 SSH port 是 2222 不是 22」、「不要用 sudo 跑 Docker，我在 docker 群組裡」——同樣的話，講了不知道第幾遍。

這不是模型笨，是架構問題。大多數 AI 工具把「當前對話」和「跨 session 記憶」當成兩件事——前者有，後者沒有，或者需要你自己手動維護。

Hermes Agent 的記憶系統從設計之初就把這兩件事接在一起。

記憶系統的兩個文件

Hermes 的持久記憶住在兩份文件裡：

兩份文件都存在 ~/.hermes/memories/，每次 session 開始時注入到 system prompt——作為一個「凍結快照」，session 期間不會再更新（但代理可以在 session 中修改磁碟上的內容，下一個 session 才生效）。

凍結快照的設計是故意的：保持 LLM 的 prefix cache，讓 token 消耗可預期，不會因為記憶即時更新而讓每個 turn 的 context 都不一樣。

代理怎麼看到自己的記憶

session 開始時，記憶以這個格式出現在 system prompt 裡：

══════════════════════════════════════════════
MEMORY (your personal notes) [67% — 1,474/2,200 chars]
══════════════════════════════════════════════
User's project is a Rust web service at ~/code/myapi using Axum + SQLx§
This machine runs Ubuntu 22.04, has Docker and Podman installed§
SSH port is 2222, key at ~/.ssh/staging_ed25519

代理看到這個，就知道「我記得這些事，不需要再問用戶了」。67% 的容量使用率也告訴它「快滿了，下次新增前要整理」。

代理主動管理記憶：memory 工具

Hermes 代理用 memory 工具操作記憶——不是靠你提醒它，是它在判斷「這件事值得記下來」之後自動做：

• add：加一筆新記憶
• replace：更新已有記憶（用 substring 比對，不需要完整原文）
• remove：移除不再相關的記憶

# 代理學到你的 SSH 設定後
memory(action="add", target="memory",
       content="SSH port 2222, key at ~/.ssh/staging_ed25519")
 
# 你告訴它「其實我換到 3000 port 了」
memory(action="replace", target="memory",
       old_text="SSH port 2222",
       content="SSH port 3000, key at ~/.ssh/staging_ed25519")

Substring 比對設計讓代理不需要記住完整的原始文字，只需要一個唯一的片段就能定位那筆記憶。

什麼應該存、什麼不該存

這是記憶系統能不能真正發揮作用的關鍵——容量有限，每筆記憶都在佔資源。

代理應該主動存的

環境事實： 「這台機器跑 macOS 14，Homebrew 裝好了，Docker Desktop 開著，shell 是 zsh + oh-my-zsh」——一筆就覆蓋了一堆可能被反覆詢問的背景知識。

專案慣例： 「~/code/api 用 Go 1.22，sqlc 做 DB queries，chi router，測試用 make test 跑」——下次代理碰這個專案不用重新探索。

被糾正過的做法： 「不要用 sudo 跑 Docker，用戶在 docker 群組裡」——犯過的錯不要再犯，這是記憶系統最有價值的場景之一。

已完成的重要工作： 「2026-04-15 把資料庫從 MySQL 遷移到 PostgreSQL，遷移腳本在 ~/code/api/migrations/」——讓代理知道歷史狀態。

不該存的

太模糊的資訊： 「用戶在做一個專案」——沒有可操作性，佔了位置什麼都記不住。

容易重新查到的事： 「Python 3.12 支援 f-string nesting」——代理自己搜尋就知道，不值得佔記憶容量。

大塊原始資料： 日誌文件、大段代碼——太佔空間，應該用 session_search 找歷史對話。

Context files 已有的內容： 如果 .hermes.md 或 AGENTS.md 裡已經有專案說明，不用再存一份到 MEMORY.md。

容量管理：滿了怎麼辦

記憶滿了，代理收到的工具回應會是這樣：

{
  "success": false,
  "error": "Memory at 2,100/2,200 chars. Adding this entry (250 chars) would exceed the limit.",
  "current_entries": ["..."]
}

代理這時候應該：讀現有記憶 → 找可以合併或刪除的 → 整理之後再新增。

好的記憶條目長什麼樣：

# 好：資訊密度高，一筆覆蓋多個事實
User runs macOS 14, uses Homebrew, Docker Desktop and Podman installed. Shell: zsh with oh-my-zsh. Editor: VS Code with Vim keybindings.

# 好：具體可操作
Project ~/code/api uses Go 1.22, sqlc for DB queries, chi router. Run tests with 'make test'. CI via GitHub Actions.

# 不好：太模糊
User has a project they're working on.

# 不好：太囉嗦
On April 15th, the user mentioned that they have a project located at ~/code/api. I discovered it uses Go version 1.22 and...

Session Search：記憶之外的長尾

記憶系統有容量上限，但你跟 Hermes 的所有對話都存在 ~/.hermes/state.db（SQLite + FTS5 全文搜尋）。

session_search 工具讓代理可以查詢歷史對話：

hermes sessions list   # 瀏覽過去的 session

代理在內部調用 session_search 時，會找到相關的過去對話並用 Gemini Flash 做摘要——讓它能回答「上週我們討論那個 auth 遷移方案，最後怎麼決定的？」這類問題。

兩者互補：記憶存「常識」，session search 找「歷史」。

記憶系統的實際效果

用了記憶系統之後，Hermes 開新 session 的起點不一樣了——不是「你好，我是 AI，我可以幫你做什麼？」，而是「我記得你的 API 專案在用 Go 1.22，chi router，測試用 make test 跑」。

這個差異在長期使用時感受很明顯：你跟代理的對話越來越像是在跟一個真的了解你的工作環境的人說話，而不是每次都在教新人認識你的系統。

設計上的取捨是：容量有限。你不能把什麼都塞進去，反而要培養「這件事值不值得佔記憶空間」的判斷力——這跟 Hermes 整體的設計哲學一致：agent 應該有邊界和紀律，不是無限膨脹。

延伸閱讀

• Hermes Agent 入門課：系列總覽與閱讀地圖
• Skills 系統：讓 AI Agent 在對的時候做對的事
• 自動化能力：Cron 排程、子代理並行、Code Execution