大白話講清楚OpenClaw的記憶術
整理版優先睇
OpenClaw 記憶術：用索引代替全量加載，節省 90% Token
呢篇文章係嬌姐參考 OpenClaw 官方文檔，用大白話解釋佢嘅記憶機制。作者想解決 AI Agent 每次對話都加載全部記憶、浪費大量 token 嘅問題。整體結論係透過「輕量化常駐索引 + 按需要讀取詳細內容」嘅架構，可以將 token 消耗降低 88% 甚至 90% 以上，同時唔會損失任何知識。
OpenClaw 有兩層記憶：每日日誌自動加載最近兩日，長期記憶 MEMORY.md 只喺私聊主會話加載。另外提供 memory_search 同 memory_get 兩個工具，平時唔消耗 token，需要嗰陣先精確讀取特定文件。呢個設計相比傳統全量注入方案，每日 token 消耗可由 125,000 降至 15,000。
關鍵在於 MEMORY.md 只存放索引，而唔係詳細內容。索引包含文件名、適用場景，AI 可以快速判斷需要邊份文件，然後用工具按需要讀取。呢個思路唔只適用 OpenClaw，其核心原則已被提取為獨立開源庫 memsearch，可以插入任何 Agent 框架。
- OpenClaw 將記憶分為每日日誌（自動加載最近兩天）同長期記憶（私聊加載），歷史文件需靠按需讀取工具，減低 token 消耗。
- memory_search 用語義搜索找到相關文件，memory_get 精確讀取內容，兩者平時唔佔 token。
- 實測對比：全量注入每次對話消耗 12,500 tokens，每日 10 次共 125,000 tokens；改用索引按需讀取後每日僅 10,000-15,000 tokens，節省約 88%。
- MEMORY.md 只存索引（文件名、摘要、適用場景），詳細內容放 memory/*.md，AI 透過索引判斷後再調用工具讀取。
- 核心三原則：輕量化常駐文件、詳情按需讀取、索引寫清楚適用場景；呢個設計已開源為 memsearch，可遷移到其他 Agent 框架。
memsearch
OpenClaw 記憶架構的核心檢索庫，支援 BM25+向量混合檢索，可插入任何 Agent 框架。
點解 AI Agent 需要記憶術？
作者用一個助理同手冊嘅比喻：每次開工背曬 500 頁手冊（情景 A）同只記住目錄需要時翻書（情景 B），顯然情景 B 更聰明。但絕大多數 AI Agent 而家嘅工作方式，恰恰似情景 A。
呢個比喻道出咗問題核心：AI 需要喺需要時先『翻書』，而唔係每次『背全書』。
咁做可以將 token 消耗降低 90% 以上，同時唔損失任何知識。
Token 係 AI 處理文字嘅基本單位，中文大約每 1–2 個字對應 1 個 token，1000 箇中文字 ≈ 1000 個 token。每次對話都要將系統設定、記憶文件同對話內容打包發送，文件越大，成本越高。
OpenClaw 嘅兩層記憶架構
OpenClaw 官方文檔定義咗兩種記憶層，加載方式完全唔同。
- 第一層：每日日誌（自動加載）— memory/YYYY-MM-DD.md，僅自動加載當天同昨日兩個文件，其他歷史日誌唔會自動注入。
- 第二層：長期記憶（條件加載）— MEMORY.md，僅喺私聊主會話加載，羣組對話唔會加載，避免私隱洩漏。
MEMORY.md 唔係每次對話都加載，而係僅限私聊主會話，呢個係保護私隱嘅設計。
對於唔自動加載嘅歷史日誌同其他記憶文件，OpenClaw 提供兩個按需讀取工具：
- memory_search — 語義搜索，用 BM25 + 向量混合檢索，適合關鍵詞模糊或唔記得文件名時。
- memory_get — 精確讀取指定文件或特定行範圍，適合知道文件路徑需要完整內容時。
兩者分工明確：memory_search 負責『找到』，memory_get 負責『讀取』，平時都唔會自動消耗 token。
索引機制：AI 點樣知道去邊度揾？
呢個係整個方案嘅靈魂：MEMORY.md 唔存儲詳細內容，只存儲『索引』。
## 重要記憶索引
### 2026-03-13：性能優化與定時任務
- 文件：memory/2026-03-13.md
- 內容：Agent 使用頻率、Token 消耗分析、定時任務配置
- 適用場景：討論性能優化或 Cron 配置時
### 診斷規範
- 文件：memory/diagnostic-protocol.md
- 適用場景：用戶報告系統異常時對話流程變成：用戶提問 → AI 掃描 MEMORY.md 索引，匹配相關文件 → 調用 memory_get 精確讀取 → 基於詳細內容回答。
AI 知道『去邊度揾』信息，而唔需要『一直持有』信息。
作者用圖書館 vs 背書嘅類比總結：MEMORY.md 係圖書館目錄索引，memory/*.md 係各章節書籍，memory_search + memory_get 係檢索工具。
關鍵在於 MEMORY.md 只存放索引，唔存詳細內容，呢個係節省 token 嘅核心。
數字說話：Token 消耗對比
方案 A：全量注入—將所有信息塞入 MEMORY.md，每次對話基礎消耗約 12,500 tokens，一天 10 次對話約 125,000 tokens，大部分時候詳細信息根本用唔到。
方案 B：精簡索引 + 按需讀取—MEMORY.md 只有 2 KB，每次對話基礎消耗約 500 tokens，需要詳細文件時額外 5,000 tokens（僅該次），一天 10 次對話約 10,000–15,000 tokens。
成功由 125,000 降至 15,000，每日節省約 110,000 tokens，降幅約 88%。
常見疑問與總結
- Q: AI 會忘記呢啲知識嗎？A: 唔會。記憶源頭係磁盤上嘅 Markdown 文件，索引始終喺 MEMORY.md，詳細文件一直喺 memory/ 目錄，隨時可用 memory_get 讀取。
- Q: memory_search 搜唔準點算？A: OpenClaw 採用 BM25 + 向量混合檢索，並支持切換到 QMD 本地引擎提升召回率。建議喺索引嘅『適用場景』欄位寫得更具體。
- Q: 呢個思路只適用 OpenClaw 嗎？A: 唔係。OpenClaw 嘅記憶架構已被提取為獨立開源庫 memsearch，可插入任何 Agent 框架。
總結：按需讀取 = 唔係每次都加載，需要時先讀取。節省 token、唔丟知識、靈活高效，呢個係 OpenClaw 官方架構嘅核心設計哲學。
按需讀取 = 唔係每次都加載，需要時先讀取。
先關注後閲讀，嬌姐怕失去上進嘅你
先由一個問題開始
假設你係一位助理，每日要幫老闆處理事情。老闆喺第一日就畀咗你一本厚厚嘅工作手冊——足足 500 頁。
情景 A：每次開始工作之前，你要將呢 500 頁手冊由頭到尾背一次，先可以開始做嘢。
情景 B：你淨係記住手冊嘅目錄，需要邊一章就揭邊一章。
好明顯，情景 B 更加聰明。不過絕大多數 AI Agent 今日嘅工作方式，反而更加似情景 A。
重點：點樣令 AI Agent 好似聰明嘅助理咁——淨係喺需要嗰陣先「揭書」，而唔係每次都「背曬成本書」。呢件事可以將 token 消耗降低 90% 以上，同時唔會損失任何知識。
咩係 Token？先建立直覺
Token 係 AI 處理文字嘅基本單位。中文大約每 1–2 個字對應 1 個 token，英文每 3–4 個字母對應 1 個 token。粗略記住：1000 個中文字 ≈ 1000 個 token。
每次同 AI 對話，系統都需要將「對話上下文」打包發送畀模型。呢個上下文包括：
系統設定（話畀 AI 佢係邊個、有咩規則） 記憶文件（AI 需要「記住」嘅知識） 今次對話內容
上下文入面嘅每一個 token，都係實實在在嘅成本。文件越大，每次對話花費就越高。
OpenClaw 嘅兩層記憶架構
OpenClaw 官方文檔定義咗兩種記憶層，佢哋喺加載方式上完全唔同：
第一層：每日日誌（自動加載）
memory/YYYY-MM-DD.md — 每日嘅對話日誌，淨係自動加載今日同尋日兩個文件，其餘歷史日誌唔會自動注入。
第二層：長期記憶（條件加載）
MEMORY.md — 精心整理嘅長期知識庫，淨係喺主會話（私聊）入面加載，羣組對話唔會加載，以免個人私隱資料洩漏到羣組上下文。
注意：MEMORY.md 並唔係「每次對話都加載」，而係淨係限於私聊主會話。呢個係 OpenClaw 官方設計，用嚟保護個人私隱。
按需讀取嘅兩個工具
對於唔自動加載嘅歷史日誌同其他記憶文件，OpenClaw 提供咗兩個專門嘅按需讀取工具：
兩者分工好明確：memory_search 負責「揾到」，memory_get 負責「讀取」，平時都唔會自動消耗 token。
一個具體嘅對話示例
以下展示咗「按需讀取」喺 OpenClaw 實際工作入面嘅流程：
用戶說
幫我診斷一個系統性能問題。
AI 思考
用戶要診斷問題，我先用 memory_search 揾下係咪有相關嘅診斷規範。
AI 執行（兩步）
1. 調用 memory_search，查詢關鍵詞「診斷規範」 → 命中 memory/diagnostic-protocol.md
2. 調用 memory_get，精確讀取該文件完整內容
得今次對話消耗咗呢部分 token，下次對話唔會自動加載佢。
AI 回覆
根據診斷規範，我會由以下幾個維度檢查你嘅系統……（基於啱啱讀取嘅文件畀出專業回答）
提示：關鍵點在於——AI 知道「去邊度揾」資訊，而唔需要「一直持有」呢啲資訊。
數字說話：兩種方案嘅 Token 消耗對比
方案 A：將所有資訊塞入 MEMORY.md（唔推薦）
# MEMORY.md（50 KB）
## Agent 使用頻率分析
[詳細的表格和數據，5,000 tokens...]
## Token 消耗統計
[詳細的統計數據，3,000 tokens...]
## 定時任務配置
[完整的配置說明，2,500 tokens...]
## 診斷規範
[詳細的診斷步驟，2,000 tokens...]方案 B：精簡索引 + 按需讀取（推薦）
# MEMORY.md（2 KB，只有索引）
## 重要記憶索引
### 2026-03-13：性能優化
- 文件：memory/2026-03-13.md
- 關鍵發現：關閉 Cron 任務節省大量 token（個人實測）
### 診斷規範
- 文件：memory/diagnostic-protocol.md
- 適用場景：系統診斷的完整步驟詳細內容存放在獨立嘅 memory/*.md 文件入面，用 memory_search / memory_get 按需讀取。
成功：125,000 → 15,000，每日節省約 110,000 tokens，降幅約 88%。
索引機制：AI 點知去邊度揾？
呢個係成個方案嘅靈魂：MEMORY.md 唔儲存詳細內容，淨係儲存「索引」。
## 重要記憶索引
### 2026-03-13：性能優化與定時任務
- 文件：memory/2026-03-13.md
- 內容：Agent 使用頻率、Token 消耗分析、定時任務配置
- 適用場景：討論性能優化或 Cron 配置時
### 診斷規範
- 文件：memory/diagnostic-protocol.md
- 適用場景：用戶報告系統異常時
### 菜譜收藏
- 文件：discoveries/recipes.md
- 適用場景：用戶詢問食譜相關問題有咗呢個索引，實際對話流程變成：
1. 用戶提問：「定時任務點樣配置？」
↓
2. AI 掃描 MEMORY.md 索引，匹配到相關文件
↓
3. 調用 memory_get，精確讀取 memory/2026-03-13.md
↓
4. 基於讀取到嘅詳細內容，畀出專業回答
類比：圖書館 vs. 背書
常見疑問解答
問：AI 會「忘記」呢啲知識咩？
唔會。OpenClaw 嘅記憶源頭係磁碟上面嘅 Markdown 文件，模型「記住」嘅就係寫入呢啲文件嘅內容。索引始終喺 MEMORY.md 入面，詳細文件一直喺 memory/ 目錄，隨時可以用 memory_get 精確讀取。
問：memory_search 搜唔準點算？
OpenClaw 採用 BM25 + 向量混合檢索，仲支援切換到 QMD 本地引擎進一步提升召回率。如果查詢比較模糊，可以喺索引嘅「適用場景」字段寫得更具體，幫 AI 更準確噉觸發讀取。
問：呢個思路係咪淨係適用於 OpenClaw 咋？
唔係。OpenClaw 嘅記憶架構已經被抽出做獨立開源庫（memsearch），可以插入任何 Agent 框架。核心原則通用：Markdown 文件係事實來源，向量索引係檢索加速層，兩者配合實現「輕量常駐 + 按需讀取」。
總結：三個關鍵原則
重點：按需讀取 = 唔係每次都加載，需要嗰陣先讀取。節省 token、唔會唔見知識、靈活高效。呢個係 OpenClaw 官方架構嘅核心設計哲學。
先關注後閲讀，嬌姐怕失去上進的你
先從一個問題開始
假設你是一位助理，每天要幫老闆處理事務。老闆在第一天就給了你一本厚厚的工作手冊——足足 500 頁。
情景 A：每次開始工作前，你把這 500 頁手冊從頭到尾背一遍，才能開始幹活。
情景 B：你只記住手冊的目錄，需要哪章就翻哪章。
顯然，情景 B 更聰明。但絕大多數 AI Agent 今天的工作方式，恰恰更像情景 A。
重點：如何讓 AI Agent 像聰明的助理一樣——只在需要時才"翻書"，而不是每次都"背全書"。這件事能把 token 消耗降低 90% 以上，同時不損失任何知識。
什麼是 Token？先建立直覺
Token 是 AI 處理文字的基本單位。中文大約每 1–2 個字對應 1 個 token，英文每 3–4 個字母對應 1 個 token。粗略記：1000 箇中文字 ≈ 1000 個 token。
每次與 AI 對話，系統都需要把"對話上下文"打包發送給模型。這個上下文包括：
系統設定（告訴 AI 它是誰、有什麼規則） 記憶文件（AI 需要"記住"的知識） 本次對話內容
上下文裏的每一個 token，都是實實在在的成本。文件越大，每次對話花費越高。
OpenClaw 的兩層記憶架構
OpenClaw 官方文檔定義了兩種記憶層，它們在加載方式上完全不同：
第一層：每日日誌（自動加載）
memory/YYYY-MM-DD.md — 每天的對話日誌，僅自動加載當天和昨天兩個文件，其餘歷史日誌不會自動注入。
第二層：長期記憶（條件加載）
MEMORY.md — 精心整理的長期知識庫，僅在主會話（私聊）中加載，羣組對話中不會加載，以避免個人隱私信息泄漏到羣組上下文。
注意：MEMORY.md 並非"每次對話都加載"，而是僅限私聊主會話。這是 OpenClaw 官方設計，用於保護個人隱私。
按需讀取的兩個工具
對於不自動加載的歷史日誌和其他記憶文件，OpenClaw 提供了兩個專門的按需讀取工具：
兩者分工明確：memory_search 負責"找到"，memory_get 負責"讀取"，平時都不會自動消耗 token。
一個具體的對話示例
以下展示了"按需讀取"在 OpenClaw 實際工作中的流程：
用戶說
幫我診斷一個系統性能問題。
AI 思考
用戶要診斷問題，我先用 memory_search 找一下是否有相關的診斷規範。
AI 執行（兩步）
1. 調用 memory_search，查詢關鍵詞"診斷規範" → 命中 memory/diagnostic-protocol.md
2. 調用 memory_get，精確讀取該文件完整內容
只有這次對話消耗了這部分 token，下次對話不會自動加載它。
AI 回覆
根據診斷規範，我將從以下幾個維度檢查你的系統……（基於剛讀取的文件給出專業回答）
提示：關鍵點在於——AI 知道"去哪裏找"信息，而不需要"一直持有"這些信息。
數字說話：兩種方案的 Token 消耗對比
方案 A：把所有信息塞進 MEMORY.md（不推薦）
# MEMORY.md（50 KB）
## Agent 使用頻率分析
[詳細的表格和數據，5,000 tokens...]
## Token 消耗統計
[詳細的統計數據，3,000 tokens...]
## 定時任務配置
[完整的配置說明，2,500 tokens...]
## 診斷規範
[詳細的診斷步驟，2,000 tokens...]方案 B：精簡索引 + 按需讀取（推薦）
# MEMORY.md（2 KB，只有索引）
## 重要記憶索引
### 2026-03-13：性能優化
- 文件：memory/2026-03-13.md
- 關鍵發現：關閉 Cron 任務節省大量 token（個人實測）
### 診斷規範
- 文件：memory/diagnostic-protocol.md
- 適用場景：系統診斷的完整步驟詳細內容存放在獨立的 memory/*.md 文件中，用 memory_search / memory_get 按需讀取。
成功：125,000 → 15,000，每天節省約 110,000 tokens，降幅約 88%。
索引機制：AI 怎麼知道去哪裏找？
這是整個方案的靈魂：MEMORY.md 不存儲詳細內容，只存儲"索引"。
## 重要記憶索引
### 2026-03-13：性能優化與定時任務
- 文件：memory/2026-03-13.md
- 內容：Agent 使用頻率、Token 消耗分析、定時任務配置
- 適用場景：討論性能優化或 Cron 配置時
### 診斷規範
- 文件：memory/diagnostic-protocol.md
- 適用場景：用戶報告系統異常時
### 菜譜收藏
- 文件：discoveries/recipes.md
- 適用場景：用戶詢問食譜相關問題有了這個索引，實際對話流程變成：
1. 用戶提問："定時任務怎麼配置？"
↓
2. AI 掃描 MEMORY.md 索引，匹配到相關文件
↓
3. 調用 memory_get，精確讀取 memory/2026-03-13.md
↓
4. 基於讀取到的詳細內容，給出專業回答
類比：圖書館 vs. 背書
常見疑問解答
Q：AI 會"忘記"這些知識嗎？
不會。OpenClaw 的記憶源頭是磁盤上的 Markdown 文件，模型"記住"的就是寫進這些文件的內容。索引始終在 MEMORY.md 裏，詳細文件一直在 memory/ 目錄，隨時可用 memory_get 精確讀取。
Q：memory_search 搜不準怎麼辦？
OpenClaw 採用 BM25 + 向量混合檢索，並支持切換到 QMD 本地引擎進一步提升召回率。如果查詢較模糊，可以在索引的"適用場景"字段寫得更具體，幫助 AI 更準確地觸發讀取。
Q：這個思路只適用於 OpenClaw 嗎？
不是。OpenClaw 的記憶架構已被提取為獨立開源庫（memsearch），可插入任何 Agent 框架。核心原則通用：Markdown 文件是事實來源，向量索引是檢索加速層，兩者配合實現"輕量常駐 + 按需讀取"。
總結：三個關鍵原則
重點：按需讀取 = 不是每次都加載，需要時才讀取。節省 token、不丟知識、靈活高效。這是 OpenClaw 官方架構的核心設計哲學。