讓 AI Agent 學會做夢：記憶的睡眠循環機制
記憶的腐爛問題 跑了兩個月的 AI agent，記憶檔案從幾 KB 膨脹到幾十 KB。一開始沒什麼感覺，直到某天 agent 引用了一個三週前就被推翻的技術決策，我才意識到問題有多嚴重。 記憶不是寫進去就沒事了。沒有維護的記憶，比沒有記憶更危險——因為 agent 會很有信心地根據過時資訊做決策。 人類的記憶會在睡眠中自動整理：重要的強化、矛盾的修正、不用的淡化。AI agent 的記憶沒有這個機制，所以得自己造一個。 靈感來源：Karry 的 Orb 直接觸發這個想法的，是 Karry 寫的一篇文章：《認知アップグレードの本当のループ——AI Agent の記憶設計から學んだ 3 つのこと》。 Karry 運營自己的 AI agent「Orb🔮」超過兩個月，得出一個跟主流完全不同的結論：記憶系統的核心不是 Vector DB，是認知循環。他指出三個真正的難題： 什麼時候該忘？ — 頻率衰減不夠用，年用一次但救命的記憶不能丟 AI 會捏造記憶 — 搜尋結果為空 ≠ 記錄不存在 教訓寫了也不一定有效 — 「知道」和「做到」之間有巨大的鴻溝 他的解法是三層記憶（L0 原始日誌 → L1 回顧摘要 → L2 長期記憶）加上「Hard Constraint」——犯錯兩次就強制鎖死，不靠自覺靠系統。 這些觀點跟我自己踩坑的經驗高度吻合，但我的問題不完全一樣。Karry 著重在「怎麼讓記憶影響行為」，我面對的是更前面一步：怎麼讓記憶自己保持乾淨。 Orb 做了什麼，我做了什麼不同 Karry 的 Orb 和我的 agent 有很多共通點——都用 Markdown 檔案、都分層、都相信簡單架構。但設計哲學有幾個明顯的差異： Karry’s Orb 我的做法 記憶儲存 Markdown + LLM 多段抽取 Markdown + LLM，但加了 Gemini embedding 做向量索引 遺忘策略 P0/P1/P2 分級 + 人工 review P0/P1/P2 分級 + 自動化腳本 (janitor/expire) 防呆機制 Hard Constraint（犯兩次就鎖） 分析/執行分離（反芻只建議，main session 決策） 獨特機制 — 「做夢」——冷記憶隨機抽取找跨領域洞察 記憶維護 LLM 每日抽取 cron 四件套：janitor + reflect + dream + expire 矛盾處理 手動 反芻引擎自動檢測，但人工確認修改 最大的差異是：Karry 更信任 agent 自己管記憶（自動壓縮、自動昇格），我更偏向讓 agent 當顧問、人類做最終決策。 ...
