AI Agent的記憶系統：我們如何讓13個Agent跨Session保持上下文

為什麼AI Agent會「失憶」？

你有沒有遇到過這種情況：跟AI聊了半小時，它幫你規劃好了一套方案，第二天重開對話，它什麼都不記得了。這不是Bug，這是LLM的根本架構設計——上下文視窗是有限的，Session結束就清空。

但小火龍實驗室的13個Agent每天要協作完成幾十個任務，跨Session、跨頻道、跨天。如果每次都從零開始，效率會砍掉一大半。

經過將近20天的實戰打磨，我們摸索出一套三層記憶架構。

就是LLM的Context Window。快、準，但短暫。適合當次任務的指令傳遞和回傳值，Session結束即消失。

每個Agent都有 memory/YYYY-MM-DD.md 檔案。任務完成後，立刻寫入：做了什麼、踩了什麼坑、下游觸發了什麼。第二天開工前讀昨天的檔案，5分鐘恢復上下文。

提煉版的「大腦」。不是每天的流水帳，而是值得長期保留的認知：架構決策、踩坑總結、團隊規範。每週審查一次，刪掉過期項目，合併重複文件。

單一方案都有失效場景。純Context Window：規模一大成本爆炸。純檔案系統：檢索效率差。純向量資料庫：運維複雜度太高。三層覆蓋了完整的時間軸：即時（context）→短期（daily）→長期（MEMORY）。

教訓一：寫記憶的觸發機制比寫什麼更重要。早期Agent完成任務後經常忘記寫記憶。後來我們直接把記憶寫入要求放進任務說明範本——自動觸發，不靠Agent主動性。

教訓二：記憶需要結構才能被檢索到。非結構化的日常記錄很難搜尋。我們標準化了格式：專案標籤、結論、檔案變更、教訓、hashtag。memory_search的命中率從~30%提升到~75%。

教訓三：記憶維護本身是一個任務。不定期整理，MEMORY.md會無限膨脹，檢索品質下降。我們現在每週用一次heartbeat專門做記憶維護——讀近期日誌，提煉值得長期保留的內容。

三層體系之前：每個Session開始需要8-15k token的上下文（重新說明背景）。之後：日常記憶預載1-3k，MEMORY.md載入2-4k，整體開銷約減半，而且任務完成品質明顯提升，因為上下文是真正相關的。