最近在整理 AI 助理的長期記憶時，我又被一件看起來很小的事情提醒：記憶系統最危險的地方，往往不是「忘記」，而是「太有自信地清掉不該清的東西」。
聽起來很像廢話對吧？但真的開始讓 AI 自己做每日整理、歸檔、去重、摘要、更新技能庫之後，你會發現它已經不是單純的筆記工具，而是一個需要維運邊界的系統。差別只在於，它的資料長得比較像文字，不像資料庫那麼有威嚴而已。
記憶不是只有一種形狀
很多人談 AI Agent 的 memory，第一個想到的是向量資料庫。把內容 embedding 起來，查詢時 recall，聽起來很高級，也確實有用。
但在實務上，我更常看到的是混合型記憶：
- 有些是 file-backed memory，存在 markdown、json、yaml 裡；
- 有些是 topic memory，像是某個領域或專案的長期摘要；
- 有些是 daily log，保留最近發生的原始脈絡；
- 有些才是真正的 vector DB 記憶，用語意搜尋召回。
問題來了：當你叫 AI「整理記憶」的時候，它到底在整理哪一種？
如果沒有講清楚，它很容易把「我看得到的檔案」誤認成「全部的記憶系統」。更糟的是，它可能開始用同一套標準處理完全不同生命週期的資料。日誌可以歸檔，topic memory 要合併，vector memory 需要查詢與刪除工具，skill 文件則是作業手冊。這些東西混在一起清，災難就開始了。
看起來像垃圾的東西，不一定是垃圾
這次整理時，有一個細節很有意思：某些候選內容看起來很像噪音，例如 metadata、model、transcript、archive、artifact 這類字眼。
如果你只用直覺判斷，很容易下結論：「這些應該是系統殘留，可以刪。」
但實際上不一定。
metadata 可能記錄了自動擷取規則；model 可能是某個流程指定的模型策略；transcript 可能說明為什麼某段歷史不能只看最後摘要；archive 可能是資料搬遷後的指向；artifact 則可能是某個工作流輸出物的約定。
也就是說，這些字眼本身不是垃圾，必須回到上下文判斷。AI 最容易犯的錯，是把「像垃圾的格式」當成「沒有價值的內容」。
這件事其實跟工程維運很像。你在一台老系統裡看到一個叫 temp 的資料表，第一反應可能是想清掉；但資深工程師會先問：「誰在寫它？誰在讀它？刪掉後有沒有 rollback？」因為我們都知道，很多 production 系統最可怕的依賴，名字都取得很隨便。
自動清理前，先定義操作權限
我現在越來越覺得，AI Agent 的記憶整理不能只靠 prompt 說「請小心」。這太脆弱了。
比較好的做法，是把操作分層：
flowchart TD
A[讀取最近記錄] --> B[分類：日誌 / 主題 / 技能 / 向量記憶]
B --> C[產生候選項目]
C --> D{是否具備操作工具與回復路徑？}
D -- 否 --> E[只回報限制，不執行刪除]
D -- 是 --> F[小批次處理]
F --> G[驗證：讀回 / 搜尋 / diff]
G --> H[寫入維運紀錄]
這張圖的重點不是流程漂亮，而是中間那個判斷：有沒有操作工具與回復路徑？
例如 file-backed memory 可以用 git diff、讀回確認、必要時 revert。可是 vector DB 如果沒有 list、delete、merge 的可靠工具，你就不應該假裝自己真的整理完了。最多只能說：「我掃描了可見檔案，向量記憶目前無法直接盤點。」
這句話看起來很保守，但我喜歡這種保守。因為它誠實。
技術主管最怕的不是系統有限制，而是系統不知道自己有限制。AI Agent 也是一樣。它不需要每次都無所不能，它需要在不能做的地方停下來，清楚告訴你邊界在哪裡。
Skill 也會腐爛
另一個延伸出來的觀察是：AI 的 skill library 其實不是文件庫，而是維運手冊。
文件庫可以放著不動，頂多過時；維運手冊過時就會害人。
當某次整理發現「這個 skill 沒提醒要區分 file-backed memory 和 vector memory」時，正確做法不是只在當次任務裡記住，而是立刻把這個坑補回 skill。否則下次另一個 agent、另一個 session、另一個凌晨的 cron job，還是會踩同一個坑。
這也是我覺得 AI 工作流真正有趣的地方：它不是一次性自動化，而是會累積操作經驗的系統。每次踩坑，如果只停留在對話紀錄裡，那叫聊天；如果能回寫到可重複使用的流程裡，那才叫工程化。
當然，這裡也有反面風險。你不能什麼都寫進 skill，否則 skill 會變成另一種垃圾堆。我的做法是只記三種東西：
- 曾經造成錯誤判斷的前提；
- 下次必須先檢查的限制；
- 可以驗證結果的具體方法。
其他像心情、流水帳、一次性狀態，就讓它留在 daily log，不要污染作業手冊。
記憶系統需要的是稽核感
做久了我有一個感覺：AI Agent 的長期記憶，不該只追求「記得更多」，而是要追求「記得可稽核」。
可稽核的意思是：
- 我知道這段記憶從哪裡來；
- 我知道它目前被放在哪一層；
- 我知道誰可以修改它；
- 我知道修改後怎麼確認沒有弄壞；
- 我知道刪除前有沒有備份或替代來源。
這些聽起來很傳統，甚至有點無聊。但企業系統很多年累積下來的教訓就是：無聊的稽核設計，通常是半夜少被叫醒的原因。
AI Agent 也是系統。只要它開始替你整理資料、更新規則、生成報告、改寫流程，它就不再只是「一個會聊天的介面」。它變成一個會動手的操作者。操作者就需要權限、邊界、紀錄和驗證。
我的結論
如果你正在做 AI 助理或內部 Agent，我會建議不要太早迷戀「記憶多強」。先問幾個比較土、但比較救命的問題：
這些記憶分幾層？哪些能自動改？哪些只能建議？哪些刪了可以回復？哪些看起來像垃圾但其實是規則？當工具不足時，Agent 會不會誠實停手？
記憶系統的成熟，不是它永遠不忘，而是它知道什麼可以忘、什麼不能亂忘，以及忘記之前要留下什麼證據。
這大概也是我最近越來越相信的一件事：AI 自動化要變可靠，靠的不是更神的模型，而是更像工程師的維運邊界。
模型負責聰明，系統負責不要太聰明過頭。這兩件事，缺一個都會出事。