OpenClaw 記憶資料怎麼留才不會越積越亂？做好保留、淘汰與人工覆核

在線上環境維運 OpenClaw 一陣子後，很多團隊常會遇到一個尷尬的狀況：原本以為餵給代理（Agent）的筆記和歷史資料越多，它就會越聰明；結果資料一多，AI 反而開始拿舊資料打臉新規則。

最典型的狀況，就是代理把幾個月前除錯用的臨時設定當作現行規章、把某一次手動排解問題的特例當成長期偏好，甚至在好幾筆相似的專案筆記之間抓取矛盾的資訊。記憶維護的重點從來不是把工作區全部清空，而是讓留下來的每一行文字，都有明確的用途、有效期限、資料來源與負責確認的人。

在 Metadata 把記憶拆成四種屬性

如果把日誌、對話紀錄、正式規格全塞在同一個資料夾，後面根本沒辦法自動化處理。要避免混亂，建議一開始就在 Metadata 清楚註記這四類屬性，別單靠檔名去猜：

• 穩定事實（Stable Facts）：像是正式服務名稱、標準 API 端點路徑、團隊已確認的架構規則。這類資料變動頻率低，是系統運作的基本盤。
• 短期工作狀態（Ephemeral States）：例如當前任務的執行進度、待辦清單或中途產生的暫存變數。任務一旦結束，這些內容就該退出工作區。
• 偏好與決策邊界（Preferences & Decisions）：特定使用者的格式要求、資安限制或操作原則。這類資料一定要標註適用範圍，免得被無差別套用到其他情境。
• 候選推論與外部摘錄（Candidate Data）：尚未經過人工確認的推論、工具抓回來的參考草稿。這類內容屬於低信任資料，不能直接當成事實使用。

設定保存期限，關鍵在於「到期後的動作」

為記憶設定到期日，如果只是在資料庫多填一個日期欄位，基本上沒有實質幫助。更重要的問題是：時間一到，這筆資料該怎麼處理？

不同屬性的記憶，到期處置應該完全不同：

• 穩定事實：雖然能長期保存，但維運團隊每季至少該盤點一次，確認架構有沒有悄悄改動。
• 短期工作狀態：任務只要狀態變成完成、取消或逾期中斷，就該自動封存隔離，免得下次執行被代理誤判成未完工的狀態。
• 偏好與決策：可以長期保留，但務必加上版本編號（Version）與有效範圍。只要新版本上線，舊版本就該標示為棄用。
• 候選推論：設定極短的驗證期（例如 7 到 14 天）。如果這段時間內沒人確認有效性，直接轉入封存或丟棄，別讓未經驗證的推測長久佔據檢索庫。

淘汰舊資料前的三道安全過濾

清理過期內容時，最忌諱直接把資料永久刪除。動手淘汰前，先過這三道篩選：

1. 現行流程還有人在用嗎？ 先檢查排程中的任務或腳本有沒有相依這筆資料。如果還有引用，應先更新依賴對象或提供相容的替代內容。
2. 有沒有更新、更明確的版本？ 遇到內容相似或重複的紀錄，只保留來源最交代得清楚、定義範圍最新且最完整的那一份，不要讓代理在兩個差不多選項中猜測。
3. 刪掉後能不能隨時重新生成？ 如果是快取資料，清理風險相對低；如果是難以重現的歷史脈絡，建議降級封存。至於來源不明的內容，就算文字寫得再合理，也別順手升格成正式事實。

每次執行淘汰，後台日誌都應詳實記下資料 ID、清理原因、操作者與執行時間戳記，確保往後出問題隨時能回溯。

將人工覆核鎖定在高風險記憶

並非每一筆瑣碎對話都需要工程師肉眼檢查，把精力集中在真正有風險的環節，系統才能長久維運。

只要會影響系統權限、對外付款、發布通知、資安邊界的記憶資料，寫入或修改前務必加入人工覆核（Human-in-the-Loop）。

審核人員不能只看「語氣順不順、內容像不像對的」，更要仔細確認資料來源是哪裡、最後修改時間、適用範圍，以及現階段被哪些任務所依賴。覆核結果應明確分成保留、修訂、降級為參考、或立即淘汰。這裡有個重要的連動機制：一旦已審核的內容日後被改動，原有的核准狀態必須立即失效，強制重新送審，防止未經檢驗的改動被代理直接採納。

建立可回復的 Dry-Run 清理機制

安全的維運架構，絕不在線上環境直接覆寫或直接硬刪除。建議建立階梯式的防護管道：

1. 產出候選清單：系統先根據排程規則，掃描出到期、重複、來源遺失或邏輯衝突的項目。
2. 執行模擬（Dry-run）：先跑一次預覽報表，查看本次清理預計影響幾筆資料、牽涉到哪些運作中的任務，確認影響範圍無誤後才繼續。
3. 移至隔離封存區：確認清理的項目，先搬移到帶有時間戳記的封存目錄，並保留 14 到 30 天的還原窗口。在觀察期內若發現排程異常，可以隨時一鍵還原。
4. 固定案例驗收：每次清理完畢後，用三個固定情境做回歸測試：一個驗證能否正確讀取長期事實、一個驗證能否忽略過期工作狀態、一個驗證面對新舊衝突時是否會主動暫停回報。只有這三關都通過，才能確認這輪清理真正安全。

常見問答（FAQ）