深度解析 Agent 記憶體工程：為什麼最蠢的方法贏了？ (Agent Memory Engineering)

原始來源與檔名：20260512_2026-05-05T094105+0800-Agent Memory Engineering.md

來源：[[@nicbstme]] / X (Twitter) — 2026-05-02 原始檔名：2026-05-05T094105+0800-Agent Memory Engineering.md

NAPKIN | 餐巾紙

餐巾紙公式

Complex Idea: Vector DBs + Semantic Search + Background RAG Agent. -> FAILED (Lossy, expensive, opaque). Winning Reality: Markdown Files + File System Tools (Read/Write/Edit) + Strict Prompt Discipline. -> WON (Cheap, reliable, auditable). Memory Injection Rule: NEVER mutate system prompts mid-session (kills Prefix Cache). Freeze snapshot or lazy-load.

這是一篇深入探討 Agent 記憶架構（Memory Engineering）的萬字長文摘要。作者比較了 Hermes, Codex CLI, 和 Claude Code 三大主流系統的底層實作。令人驚訝的結論是：過去兩年新創公司吹捧的向量資料庫與知識圖譜全軍覆沒，最終在生產環境中勝出的，是「Markdown 檔案 + 基礎 Bash 工具」。文章揭開了前綴快取 (Prefix Cache) 的經濟學如何決定記憶體的載入策略，以及「驗證紀律 (Verification)」遠比「自動淘汰 (Decay)」更有效。

一句話

為什麼你的記憶檔在不同 Agent 之間無法通用？因為模型是「針對特定外殼 (Harness) 進行微調的」。這篇重磅分析指出，Agent 記憶體的難點從來不是資料結構，而是「紀律與判斷」。文章比較了三種架構：Hermes 的單一檔案字元上限、Codex 的非同步兩階段 Cron Job 濃縮，以及 Claude Code 的「總是加上新鮮度警告的動態讀取」。最大的體悟是：千萬不要把動態記憶體直接塞進 System Prompt，這會打破快取機制讓你破產；而面對老舊記憶，與其寫複雜的演算法刪除它，不如強制要求 Agent 在讀取時「先驗證再相信」。

餐巾紙草圖

[ How Top Agents Do Memory ]

1. Storage Layer
   Hermes: Flat list separated by §.
   Codex: Strict JSON schema to Markdown blocks.
   Claude Code: Typed files (.md) in a project-encoded folder.

2. Injection Layer (Crucial for Prompt Cache)
   Hermes: Freezes snapshot at session start. (Cheap, but lags).
   Codex: Loads index only, grep full handbook on demand.
   Claude Code: System Prompt = Index only. Bodies = read via tool call.

3. Eviction/Trust Layer
   Codex: Usage count decay (30 days untouched = forgotten).
   Claude Code: "This memory is N days old. Verify before asserting as fact." (Brilliant).

ROUND 1: SKELETON | 骨架掃描

“這篇文章在說什麼”

現象: 複製記憶檔案到不同的 Agent 介面，效果卻截然不同。因為模型對「該如何讀寫記憶」的直覺，來自它後訓練 (Post-training) 時所搭配的特定外殼。
聰明架構的失敗: Vector DB, RAG, 知識圖譜之所以失敗，是因為它們太不透明、成本高、難以除錯。最終勝出的是最古老的基礎建設：文字檔 + grep。
三大架構比較:
- Hermes: 單一檔案 (MEMORY.md)，有字元上限，Session 啟動時建立快照，同步寫入，但當前 Session 的 System Prompt 不會更新。
- Codex: 雙階段異步 (Two-Phase Pipeline)。Session 閒置 6 小時後，小模型負責擷取特徵 (Signal Gate)，大模型負責將內容彙整進 MEMORY.md 手冊。
- Claude Code: 同步即時寫入。Index 永遠常駐在 System prompt，詳細內容由 Agent 自主呼叫 Read 工具讀取。
快取經濟學 (Prefix Cache Problem): System prompt 變更哪怕一個字元，後面的 Token 都會以原價計算。因此絕對不能在 Mid-session 修改 System prompt。
過濾雜訊 (The Signal Gate): Codex 寫了高達 570 行的提示詞，只為了教導小模型「如何判斷什麼是不需要儲存的廢話」。預設為 No-op (不寫入) 是關鍵。
驗證紀律 (The Verification Discipline): Claude Code 在每次讀取記憶體時，都會動態包裝一段文字：「此記憶已存在 N 天，請先透過 Grep 驗證路徑與函數是否仍存在再回答。」這是極度聰明的設計。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

核心論證鏈

經濟學決定架構 (Economics dictates architecture): 許多人以為 Hermes 凍結 Session 快照是技術缺陷，但作者指出這其實是「承重牆設計 (Load-bearing design choice)」。在 API 計費模式下，快取命中 (Cached input) 的價格只有未命中的十分之一。如果為了「即時記憶」而頻繁修改 System Prompt，會導致一場長對話的成本暴增 10 倍。
記憶是提示面，不是權威面 (Memory is a hint surface, not an authority surface): 開發環境是不斷變動的。如果把記憶體當作絕對事實，Agent 就會因為過時的路徑 (Stale claims) 而不斷出錯。Claude Code 強制要求「先驗證後使用」的紀律，用極低的 Prompt 成本解決了極為複雜的 Cache Invalidation (快取失效) 難題。

關鍵證據

作者親自檢視了三大系統的原始碼與運行狀態：
- Hermes 使用 \n§\n 作為分隔符的實作。
- Codex 透過 SQLite 追蹤 usage_count 與 last_usage 的機制。
- Claude Code 生成路徑 C--Users-name 處理多租戶 (Multi-tenancy) 隔離的技巧。

邊界條件

冷啟動問題 (Cold Start Problem): 作者坦承，這三大系統目前都無法解決 Day-1 體驗極差的問題。一個全新的使用者需要忍受數十次 Session 的摩擦，Agent 才能累積足夠的記憶。未來的突破點在於「一次性從現有資料 (Email, Calendar, 舊代碼) 中萃取初始記憶」。

ROUND 3: SOUL | 靈魂提取

“還能怎么用”

知識連結: 呼應了《21 個 CLAUDE.md 必備設定》中的理念：CLAUDE.md 負責處理靜態的「我是誰 (Identity)」，而 Auto Memory 系統負責處理動態的「專案特例與使用者偏好修正」。兩者是互補的。
深層洞見: “The binding constraint is judgment: deciding what is worth remembering, when to update, when to verify. Markdown files are just how you persist what the judgment produced.” (真正的瓶頸在於判斷力：決定什麼值得記、何時更新、何時驗證。Markdown 檔只是把判斷結果持久化的方式)。我們常把技術問題歸咎於儲存層，但 AI 的本質是決策層。教導 AI「不寫入無效訊息」的價值，遠大於建構一個能裝下無限訊息的超級資料庫。
行動呼籲: 如果你正在設計自己的 Agent Workflow 或 Prompt 模板，立刻加上這條護欄規則：「在引用過去的記憶（尤其是檔案路徑與程式碼函數）時，必須先使用 grep 或 ls 工具確認目標仍然存在，禁止憑空斷言。」這個小動作將使你的 Agent 穩定性提升十倍。