我花了 5 天除錯 OpenClaw Agent 的記憶體問題，以下是我學到的所有心得

我的 Agent 名叫 Chiti，它在 Telegram 上運行，為兩個 SaaS 產品處理客服、撰寫推文草稿、管理發票，並與我的共同創辦人在不同時區協作。它是我最接近初級員工的存在。

但好幾個星期以來，它一直忘東忘西。

不是那種不明顯的遺忘。我花一小時設定好一個每日定時任務，換個模型，下一輪對話 Chiti 就好像我們從沒談過這件事。我提起兩天前的決策，它一臉茫然。我請它繼續執行某個任務，它卻從頭來過。

所以我停止開發新功能，抽空花了 5 天，專門修復記憶問題。以下是我發現的一切、我弄壞的一切，以及真正有效的做法。

第 1 天：長對話後 Agent 忘光所有內容

第一個問題描述起來很簡單，診斷起來卻很痛苦。

在長對話後，Chiti 會開始遺失早期的上下文。不是逐漸消失，而是直接蒸發。我 20 則訊息前告訴它的事情不見了。我們在對話開頭做的決定？從沒發生過。

元兇是壓縮（compaction）。當對話填滿上下文視窗，OpenClaw 會將較舊的訊息壓縮成摘要，以騰出空間給新內容。摘要只保留大意，卻丟失細節：名稱、數字、確切決策——全部消失。

這其實是設計使然。上下文視窗是有限的。但預設行為把所有內容一視同仁，導致你在第 3 則訊息裡精心撰寫的指示，跟第 7 則的閒聊得到相同待遇。

我的做法：

我在壓縮之前啟用了記憶體刷新（memory flush）。這會指示 Agent 在壓縮器執行前，將重要的上下文寫入磁碟。

1{
2  "compaction": {
3    "memoryFlush": {
4      "enabled": true,
5      "softThresholdTokens": 4000
6    }
7  }
8}

當對話接近上下文限制時，OpenClaw 會觸發一輪靜默操作，提醒 Agent 在壓縮抹除之前，將持久性的事實儲存到 memory/YYYY-MM-DD.md。Agent 寫下重要內容，壓縮執行，就算上下文摘要遺失，重要資訊仍留存於磁碟。

我學到的事：

壓縮不是敵人，壓縮過程中遺失資訊才是。解決方法是在壓縮器接觸上下文之前，確保任何值得記住的內容都已寫入檔案。如果只存在於上下文視窗中，那就是暫時的；如果存在於磁碟上，就能存活。

第 2 天：搜尋回傳垃圾結果

隨著每日日誌不斷累積，MEMORY.md 也越來越長，我需要 Agent 真的能找到東西。內建的記憶搜尋回傳的結果不是不相關，就是錯過明顯的匹配。

問題出在搜尋後端。OpenClaw 預設的 SQLite 搜尋使用向量嵌入（語意相似度）來尋找相關區塊。它對廣泛查詢效果不錯，但很難處理精確匹配。我搜尋某個特定客戶名稱，卻得到完全不同的主題結果，只是語言相似。

我的做法：

我將記憶搜尋後端切換為 QMD。QMD 結合了 BM25（關鍵詞匹配）、向量嵌入和重新排序器。所以當我搜尋「Charles payment failure」時，它會找到包含那些確切詞彙的結果，以及語意相關的結果，再按相關性重新排序。

我還設定了 QMD 路徑，包含我的學習資料夾：

1{
2  "memory": {
3    "qmd": {
4      "paths": [
5        {
6          "path": "/Users/ramya/clawd",
7          "name": "memory-root",
8          "pattern": "MEMORY.md"
9        },
10        {
11          "path": "/Users/ramya/clawd",
12          "name": "memory-alt",
13          "pattern": "memory_alt.md"
14        },
15        {
16          "path": "/Users/ramya/clawd/memory",
17          "name": "memory-dir",
18          "pattern": "**/*.md"
19        },
20        {
21          "path": "/Users/ramya/clawd/learnings",
22          "name": "learnings",
23          "pattern": "**/*.md"
24        }
25      ]
26    }
27  }
28}

我學到的事：

純語意搜尋理論上聽起來不錯，但在專有名詞、特定數字和精確片語上卻失效。混合搜尋（關鍵詞 + 向量 + 重新排序）在真實世界的 Agent 記憶中明顯更好。如果你的 Agent 找不到你確定存在於檔案中的資料，瓶頸很可能在搜尋後端，而不是檔案本身。

第 3 天：Agent 找到了卻不使用

這是最令人沮喪的一天。我確認搜尋功能正常，可以手動查詢並得到正確結果。但在實際對話中，Chiti 不會提取相關的上下文，即使這些內容明顯存在於記憶中。

問題在於提取（retrieval）不是自動的。Agent 必須自己決定要搜尋。如果對話沒有觸發正確的線索，它就不會去查資料。

我的做法：

我在啟動順序（boot sequence）中加入了明確的提取指示。不是寄望 Agent 會在需要時自動搜尋，而是直接告訴它何時該搜尋：

markdown

開始任何任務之前：

• 搜尋每日日誌以取得相關上下文
• 檢查 LEARNINGS.md 中關於此類任務的規則
• 如果提及客戶，請搜尋其歷史紀錄

我還建立了一個提取測試。我會在每日日誌中植入一個特定標記，像是「MARKER: 2026-02-20 — 記得在聲明代碼已推送之前，務必檢查 git 狀態。」然後等待，再開始新對話，問：「昨天的標記是什麼？」如果 Agent 找到了，提取就正常；如果沒有，就是有問題。

我學到的事：

「資訊存在」和「Agent 使用資訊」是兩回事。你兩者都需要。搜尋基礎設施處理前者，啟動指示和提取習慣處理後者。請分別測試。

第 4 天：讓它不受壓縮影響

到這一天，我已經有了記憶刷新、混合搜尋和提取指示。但我仍然在特定情境下遺失上下文：在很長的對話中，壓縮執行了多次。

問題在於記憶刷新在每次壓縮週期中只觸發一次。如果對話長到需要兩三次壓縮，只有第一次會獲得刷新處理。之後的內容都有風險。

我的做法：

我設定了上下文剪枝（context pruning），讓它與壓縮協同運作：

1{
2  "contextPruning": {
3    "mode": "cache-ttl",
4    "ttl": "6h",
5    "keepLastAssistants": 3
6  }
7}

這樣會積極地剪除超過 6 小時的舊上下文，同時保留最後 3 次助手回應。結合記憶刷新，Agent 會在早期將重要內容寫入磁碟，舊上下文在造成溢出前就被清理掉。

我還添加了一個 MARKER 測試協定：每次重大配置變更後，就在每日日誌中植入一個標記，並測試在壓縮邊界前後的提取。如果標記存活，變更就有效；如果沒有，就是有東西壞了。

我學到的事：

長時間對話才是記憶系統真正被考驗的時候。短對話很少觸發壓縮。真正的問題發生在長達 2 小時的深度工作階段，你會遺失上下文卻找不到原因。請在高負載下測試你的記憶系統，而不只是在快速對話中測試。

第 5 天：系統提示詞有 28% 是冗餘

這一天，一切都串起來了。我執行了 /context detail，然後盯著數字發呆。

我的 Agent 在讀取我的訊息之前，就已經載入了 11,887 個 token 的系統提示詞。51 個技能，其中 20 個我從來沒用過。MEMORY.md 有 200 行公司 Wiki 內容，每次對話都載入。而且我有兩個互相衝突的啟動順序——一個在 BOOT.md（OpenClaw 甚至不認得這個檔案），另一個埋在 AGENTS.md 的第 200 行。

最糟的是，每次我切換模型，Chiti 就忘光一切。沒有交接協定。沒有把當前上下文寫回。就這麼消失了。

根本原因：

OpenClaw 在每次新對話中會自動讀取這些檔案：AGENTS.md、SOUL.md、TOOLS.md、IDENTITY.md、HEARTBEAT.md、MEMORY.md。

其他所有檔案——LEARNINGS.md、每日日誌、文件、參考檔案——Agent 必須自己使用工具去讀取。如果指示要讀取那些檔案的內容不在任何自動載入的檔案中（特別是 AGENTS.md），Agent 就永遠不會看到它們。

我的 BOOT.md 包含了完整的啟動順序。但 OpenClaw 不會自動載入 BOOT.md。所以那些指示就只是靜靜待在那裡，沒人讀取，毫無作用。

我的做法：

我做了完整的審計與清理：

1. 將啟動順序移到 AGENTS.md 的最上方（唯一可靠的啟動指令位置）
2. 刪除 BOOT.md（OpenClaw 不認得）
3. 刪除 BOOTSTRAP.md（一次性入門檔案，已完成，卻每次都浪費 361 個 token）
4. 將 MEMORY.md 從 200 行縮減到 90 行，把參考文件移到 docs/ 資料夾
5. 移除 20 個從未使用的行銷技能，它們每次對話吃掉 3,000 個 token
6. 加入寫入紀律：每項任務記錄其結果，每次錯誤變成一條規則
7. 加入交接協定：在模型切換或對話結束前，Agent 將當前上下文寫入每日日誌

現在啟動順序長這樣：

markdown

在執行任何動作之前：

1. 讀取 USER.md
2. 讀取 learnings/LEARNINGS.md
3. 讀取 memory/YYYY-MM-DD.md（今天 + 昨天）
4. 讀取 MEMORY.md（僅主要對話，絕不在群組中）
5. 讀取 PROTOCOL_COST_EFFICIENCY.md
6. 輸出：LOADED: USER | LEARNINGS | DAILY | MEMORY | PROTOCOL

寫入紀律：

markdown

每項任務完成後：

1. 記錄決策 + 結果 → memory/YYYY-MM-DD.md
2. 如果有錯誤 → 附加到 learnings/LEARNINGS.md
3. 如果有重要上下文 → 更新 MEMORY.md（僅在心跳審查時，絕不在任務進行中直接更新）

交接協定：

markdown

在對話結束或模型切換前：

將 HANDOVER 區段寫入 memory/YYYY-MM-DD.md：

• 討論了什麼
• 決定了什麼
• 待辦任務與確切細節
• 後續步驟

結果：

• 系統提示詞：11,887 → 8,529 token
• 技能：51 → 32
• 對話 token：18,280 → 14,627
• 輕量化 28%。同一個 Agent。同一個模型。只是少了噪音。

我學到的事：

真正的修復不是增加更多檔案，而是移除那些無用的檔案。系統提示詞中的每個 token 都是 Agent 在每則訊息中必須背負的開銷。未使用的技能、腫脹的記憶檔案、系統甚至不讀取的檔案——它們都在默默累積。

我希望第一天就知道的規則

經過 5 天弄壞東西再修好，以下是我會給任何設定 OpenClaw 記憶的人建議的規則：

1. 只有這些檔案會自動載入：AGENTS.md、SOUL.md、TOOLS.md、IDENTITY.md、USER.md、HEARTBEAT.md、MEMORY.md。

所有其他檔案都需要在 AGENTS.md 中有明確的讀取指示。如果不在啟動順序中，Agent 就看不到它。BOOT.md 在 OpenClaw 中不是真實存在的東西。我之前有好幾個星期都有這個檔案，但它什麼都沒做。

2. 啟動順序放在 AGENTS.md 的最上方。

不是在檔案中間，也不是在底部。就是最上方。自動載入的檔案會被注入系統提示詞，所以啟動指示必須是 Agent 處理的第一件事。

3. 寫入紀律比讀取紀律更重要。

大多數人設定檔案讓 Agent 讀取，卻從不強制寫回。如果 Agent 不把決策、結果和錯誤記錄到磁碟，那些東西就只存在於上下文視窗。而上下文視窗會被壓縮。寫回是讓暫時的上下文變成永久記憶的方法。

4. 在任務進行中絕對不要直接寫入 MEMORY.md。

每日日誌是原始資料且只能附加。MEMORY.md 是經過策劃的長期記憶。如果你讓 Agent 把任何東西都丟進 MEMORY.md，它會在幾週內腫成 200 行的垃圾。請在定期審查（心跳或定時任務）時透過提煉近期每日日誌的洞察來策劃 MEMORY.md。我從另一位 OpenClaw 用戶那裡學到這點，他發現他的 Agent 就是這樣做——用未經整理的噪音讓 MEMORY.md 腫脹到無法使用。

5. LEARNINGS.md 是最被低估的檔案。

Agent 每次犯錯，都應該變成一條規則。「未檢查 git 狀態前，絕不聲明代碼已推送。」「不要在群組聊天中讀取完整的 MEMORY.md。」「排程前務必確認使用者的時區。」這些規則會累積。幾週後，你的 Agent 就擁有了一套從自身失敗中建立的個人操作手冊。

6. 測試提取，而不只是儲存。

儲存資訊和提取資訊是兩個不同問題。我曾經有索引過、可搜尋的檔案，但 Agent 從未存取過，因為它不知道要去尋找。植入標記，跨對話測試，跨模型切換測試。如果 Agent 找不到你昨天儲存的東西，儲存就沒有意義。

7. 交接協定是模型切換的解決方案。

當你切換模型時，OpenClaw Agent 會遺失所有上下文。新模型從全新的上下文視窗開始——它只會看到自動載入的檔案。如果沒有交接協定在切換前將當前狀態傾倒到每日日誌，新模型就不知道之前發生了什麼。這是我好幾個星期來最大的痛點。

8. 定期執行 /context detail。

這個指令會精確顯示是什麼在吃掉你的 token。你忘記安裝過的技能、不知不覺長大的檔案、你從未使用的工具。我找到了 20 個未使用的技能，每次對話燒掉 3,000 個 token。那是在每則訊息上、對你從未碰過的功能背負 3,000 token 的開銷。

9. 混合搜尋勝過純語意搜尋。

BM25（關鍵詞）+ 向量（意義）+ 重新排序的結果明顯優於單獨使用向量。客戶名稱、特定數字、確切片語——語意搜尋會錯過這些。關鍵詞搜尋能抓住它們。兩者都用。

10. 壓縮不是敵人，未寫入的上下文才是。

我花了幾天對抗壓縮，才發現解決方法更簡單：在壓縮執行前，確保所有重要內容都已寫入檔案。記憶刷新會自動處理這點。如果存在磁碟上，就能存活壓縮。如果只在對話中，就有風險。

我目前的設定

供參考，我的工作區現在長這樣：

workspace/

├── AGENTS.md （啟動順序 + 寫入紀律 + 交接協定）

├── SOUL.md （人格與行為）

├── IDENTITY.md （名稱、角色）

├── USER.md （擁有者資訊）

├── TOOLS.md （工具使用指南）

├── HEARTBEAT.md （自動化簽到行為）

├── MEMORY.md （策劃過的長期記憶，約 90 行）

├── PROTOCOL_COST_EFFICIENCY.md

├── learnings/

│ └── LEARNINGS.md （從錯誤中學習的規則）

├── memory/ （每日日誌：YYYY-MM-DD.md）

├── docs/ （從 MEMORY.md 移出的參考文件）

│ ├── tweetsmash-arch.md

│ ├── knowledge-transfer.md

│ ├── infrastructure.md

│ └── group-chat-rules.md

└── skills/ （32 個技能，從 51 個減少）

系統提示詞：8,529 token。對話 token：14,627 / 200,000 上下文視窗（7.3%）。Agent 啟動，讀取所需內容，寫下學到的東西，在模型切換前交接上下文。

花了 5 天才達到這個狀態。大部分時間都在學習破除「更多檔案等於更好記憶」的假設。事實並非如此。紀律才是關鍵。我的實驗仍在持續進行中。

我正在和共同創辦人一起打造 TweetSmash 與 LinkedMash——社交媒體書籤工具。我會在 X 上分享關於在生產環境中運行 OpenClaw Agent 的學習心得：@code_rams