把前幾篇的歸納放上天平，這一篇專門做一件事：分清楚 @wquguru 原文裡哪些是可獨立佐證的事實/業界共識、哪些是他的觀察或推論、哪些帶有產品立場，並補上他著墨不足的記憶新風險。這不是要否定文章價值——它是一篇相當好的綜述——而是任何想照著做的人都該有的防身術。
可獨立佐證 vs 僅為主張
較容易佐證（屬於公開事實或業界共識）：
- 規則檔的存在與定位：Claude Code 用
CLAUDE.md、Codex 用AGENTS.md，且官方把「人寫的規則」與「auto memory」分開——可對 Claude Code 官方記憶文件核對。 - 「context = 工作台、RAG = 外部資料庫、memory = 狀態層」的分工，以及「context 像 RAM、長期記憶像 disk」的比喻——這是 agent memory 領域的共同直覺，最早見於 MemGPT（2023）。
- reflection／技能沉澱的機制——Stanford Generative Agents（Park et al., 2023）已有明確原型：以 recency × importance × relevance 加權檢索，並把高層洞察寫回 memory stream。
- EverOS 確為開源 repo、採 Markdown + SQLite + LanceDB——repo 與官網可見。
僅為主張、推論或價值判斷（不應當成定論）：
- 「五層架構」是作者個人的整理框架，不是業界公認的標準分類。它好用、好記，但與學術界常用的切法（參數 vs 非參數記憶、短期 vs 長期、情節 vs 語意 vs 程序記憶）並不一一對應；把它當成「一種有用的視角」而非「唯一正確的分類」。
- **「memory 同時是治理系統」**是有價值的設計主張，但如何在系統層強制執行（而非寄望模型自覺），文中著墨少，仍是開放問題。
- **「EverOS 是目前最好的工程起點」**是帶利益關係的價值判斷（見 落地工程 的利益揭露），非中立結論。
- 原文引用的各工具內部細節（Hermes 超限報錯、OpenClaw 的 DREAMS.md、某交易專案的具體 memory 內容等）多來自作者本機觀察與個人專案，外部讀者無法逐項核實，宜當「作者的一手經驗陳述」看待。
作者著墨不足、但必須補上的記憶新風險
原文第九節已誠實列出五類問題（錯誤記憶永久化、過期資訊續存、prompt injection 持久污染、隱私與刪除不可逆、summary 把證據變二手結論），這部分判斷與安全研究界一致，值得肯定。可再補強的是，記憶投毒已是有實證的攻擊面，而非理論顧慮：
- MINJA（Memory Injection Attack）：研究顯示，僅透過正常使用者互動的「query-only」攻擊，就能對有持久記憶的 agent 達到極高的注入成功率，無需任何提權。
- MemoryGraft / 持久化經驗污染：攻擊者不靠即時越獄，而是把「看似成功的惡意經驗」植入長期記憶，利用 agent「模仿過去成功軌跡」的傾向，讓污染跨 session 反覆生效——比單次 prompt injection 嚴重得多。
這正好給作者「Markdown 可讀可 diff」的主張一個持平註腳：可讀檔案讓污染更可事後追查、可人工 diff 出可疑寫入，這是真實優點；但它並不自動阻止寫入——若沒有寫入時的來源校驗與信任邊界，可讀性只解決了「事後查得到」，沒解決「當下擋得住」。記憶的可審計性是防禦的必要條件，不是充分條件。
平衡的結論
公允地說，這篇文章的價值在於把零散的工具行為整理成一個連貫的分層心智模型：它讓「為什麼 CLAUDE.md 不該塞日誌」「為什麼常駐記憶要短」「為什麼 bug memory 要寫成 postmortem」這些直覺有了統一框架，治理記憶與 self-evolution 兩節尤其有見地。但讀者要記得三件事：分層是作者的視角而非標準、治理與執行之間仍有落差、收尾推介 EverOS 帶有產品立場。最務實的用法是把它當成設計 agent 記憶時的檢查清單與心智模型，而不是照抄的架構藍圖；凡是涉及「哪個工具最好、哪種做法最對」，都回到官方文件與自己的場景再驗證一遍。
🔍 待解問題
- 能不能把「五層架構」對映到學術界的記憶分類，建立一張更嚴謹的對照表，看哪些層其實是同一回事的不同命名？
- 記憶治理（來源/置信度/過期性/可刪除性）有沒有可落地的開源實作與評測基準，而不只是設計原則？
- 在「Markdown 可讀」的前提下，寫入時的來源校驗與信任邊界該怎麼設計，才能把 MINJA／MemoryGraft 這類投毒擋在寫入階段？
🕒 更新紀錄
- 2026-06-27 — 建立客觀檢視：逐項區分可佐證事實與作者主張、標示 EverOS 的產品立場，並補入記憶投毒（MINJA／MemoryGraft）作為作者風險清單的延伸。