seekdb M0：讓OpenClaw記憶不丟失、經驗可共享

OpenClaw 的記憶為什么會崩seekdb M0：記憶獨立于上下文seekdb M0 做了哪些事一句話安裝動手試一試

全文共 4373 字，閱讀約需 10 分鐘

作者 | 傅榕鋒 OceanBase 高級技術專家，seekdb M0 研發團隊負責人

如果你在用 OpenClaw，你大概率經歷過這樣的場景：

昨天下午你和 Agent 花了兩個小時排查一個線上問題。過程中它幫你查了日志、讀了配置、試了好幾種方案，最后定位到是連接池配置導致的。你們還順便討論了項目里幾個服務之間的依賴關系，以及下周要做的重構計劃。

第二天早上，你讓它繼續昨天聊到的重構。它回了一句：「你好！請問你說的是哪個重構？能給我一些背景嗎？」

昨天那些討論，它全忘了。

這不是偶發現象。MEMORY.md 里的基本信息——你的名字、偏好、常用工具——這些它記得住，因為每次都會加載。但昨天對話里的具體細節——排查過程中發現的關鍵線索、討論過的方案取舍、約定好的下一步計劃——這些留在了 session 歷史和 `memory/` 目錄的文件里。新 session 開始后，Agent 需要主動搜索才能找回這些細節，但它不一定知道該搜什么，也不一定搜得準。換成 idle 模式能緩解 session 切割的問題，但治標不治本：session 越長，累積的 token 越多，Agent 回復越慢。

根本矛盾是：OpenClaw 的記憶機制是為「單次對話」設計的，而用戶期望的是一個「長期相處的私人助理」。

這就是 seekdb M0 要解決的問題。

seekdb M0 官網：https://m0.seekdb.ai/

先別急著看方案。搞清楚問題出在哪，方案才會有說服力。

OpenClaw 有記憶機制——MEMORY.md 文件和基于 SQLite 的語義檢索。但這套機制在長期使用中會陷入兩個惡性循環。

循環一：越記越貴。

Agent 把重要信息寫入 MEMORY.md。這個文件會被全量加載到每次請求的系統提示詞里。用的時間越長，MEMORY.md 越大，每次 API 調用的 input token 越多，響應越慢。Bootstrap 文件有單文件 20K 字符的默認上限（總計 150K），但早在到達上限之前，臃腫的上下文就已經開始擠占 Agent 的工作空間了。

更糟糕的是，Agent 知道信息可能會丟，于是更積極地往 MEMORY.md 里塞東西——加速膨脹。

循環二：越忘越錯。

當 session 太長時，OpenClaw 會觸發兩套機制來應對。

一是 compaction——用 LLM 把舊對話分段總結壓縮，騰出上下文空間；

二是 memory flush——在 compaction 前啟動一個嵌入式 agent，讓它自行決定把哪些重要信息寫入。但 compaction 的總結本質上是有損壓縮，而檢索側的切片邏輯按行和字符預算硬切（默認 400 token 一塊），不識別語義邊界。關鍵上下文可能被切斷，檢索召回質量差。Agent 找不回需要的信息就犯錯，犯錯就返工，返工產生更多對話，更快觸發下一次壓縮。

memory/YYYY-MM-DD.md

工具調用是加速器。這是很多 OpenClaw 用戶沒意識到的一點。Agent 調用工具產生的中間結果——返回的網頁、輸出的命令結果——單條最大 400K 字符，會快速填滿 session。這些中間過程不適合寫進 MEMORY.md，但可能包含有價值的信息。無論選哪條路，工具調用都會加劇惡性循環。

web_fetch

exec

兩條路的本質矛盾是：記住的代價是昂貴，遺忘的代價是犯錯。

需要第三條路。

seekdb M0 是一個 OpenClaw 云端記憶插件，核心理念一句話：不把所有記憶塞進 system prompt，而是在每次對話開始前，只檢索與當前話題相關的記憶片段注入上下文。

和 MEMORY.md 的全量加載不同，seekdb M0 把記憶拆解為獨立的「事實」存儲在云端數據庫中。每條事實都有向量表示和全文索引。對話開始前，seekdb M0 用混合檢索（BM25 + 向量相似度）找到最相關的幾條記憶注入上下文；對話結束后，自動從對話中提取新事實，與已有記憶比對后決定新增、更新還是跳過。

這意味著：

• MEMORY.md 不再膨脹——記憶存在云端，不占系統提示詞空間
• session 重置不再是災難——記憶是持久化的，新 session 開始時自動召回
• 跨設備同步——換一臺機器，記憶還在

整個過程對用戶透明——你只管和 Agent 聊天，M0 在后臺自動管理記憶。

但如果只是「把 MEMORY.md 搬到云端」，seekdb M0 的價值就有限了。真正的差異在記憶管理的方式上。

兩階段記憶管理：先提取，再決策

OpenClaw 原生的記憶持久化依賴 compaction 總結和 memory flush agent——前者把整段對話（含全部工具輸出）壓縮成摘要，后者讓 LLM 自行決定把什么寫入文件。兩者都是全量處理對話內容，token 開銷大，信息有損。seekdb M0 不這么干，它把「存什么」和「怎么存」拆成兩個獨立的階段。

第一階段：事實提取。對話結束后，seekdb M0 只提取 user 和 assistant 之間的對話文本（跳過所有工具調用的中間輸出），用 LLM 抽取出原子化的事實。比如「用戶叫張三，是數據庫工程師，在杭州工作」會被拆成三條獨立事實。

提取時有幾條硬規則：時間信息必須保留（「去年去了夏威夷」不會被簡化成「去了夏威夷」）；保持原語言不翻譯；敏感信息一律不提取。

第二階段：記憶決策。提取出的事實不是直接寫入數據庫，而是先和已有記憶做比對。M0 用向量檢索找到最相似的已有記憶，然后讓 LLM 判斷：這條事實應該新增（ADD）、更新已有記憶（UPDATE）、刪除矛盾記憶（DELETE），還是已經被覆蓋可以跳過（NONE）？實際運行中，為了避免誤刪，插件側會把 DELETE 當作 NONE 處理——auto-capture 只新增和更新，永遠不主動刪除已有記錄。

新事實：「去年五月去了夏威夷」已有記憶：「去過夏威夷」→ 決策：UPDATE（補充了時間信息）新事實：「不喜歡吃披薩了」已有記憶：「喜歡吃披薩」→ 決策：UPDATE（偏好發生了變化）新事實：「是軟件工程師」已有記憶：「名字是 John」「是軟件工程師」→ 決策：NONE（已有記憶已覆蓋）

有一個有趣的實現細節：送給 LLM 做決策時，已有記憶的 ID 會被替換成臨時編號（0、1、2…），避免模型幻覺長整型 ID。如果模型返回的 ID 無法映射回真實記憶，系統會優雅降級為新增。

這種兩階段設計的好處是關注點分離——提取階段保證事實的質量和合規性，決策階段保證記憶庫不會無限膨脹。

工具調用自動壓縮：零 LLM 開銷

前面說了，工具調用的中間輸出是 session 膨脹的主要推手。seekdb M0 的處理方式很直接：用確定性規則壓縮，不花一個 LLM token。

當工具結果被持久化到會話歷史時，seekdb M0 的鉤子會介入，把原始輸出替換為結構化摘要：

tool_result_persist

原始：curl 返回了一個3000行的JSON響應壓縮后： 工具：web_fetch 狀態：success 輸出：3000行 / 48K 字符 預覽：{"users": [{"id":1,"name":"Alice"...（300字符）

壓縮比極高（幾萬字符 → 幾百字符），且完全是規則化的——不需要 LLM 理解內容，只需要保留「做了什么、結果如何、簡要預覽」。

在事實提取階段，seekdb M0 直接跳過所有 tool/toolResult 類型的消息，只看人和 Agent 之間的對話。這意味著即使一次對話涉及大量工具調用，事實提取的 LLM 輸入也被控制在很小的范圍內。

與 OpenClaw 原生的做法相比——compaction 時把完整 session（含全部工具輸出）送進 LLM 壓縮——這種方式從源頭控制了送入 LLM 的數據量，而不是等到溢出了再惰性壓縮。

經驗系統：從應屆生到專家

記憶解決的是「記住用戶是誰、喜歡什么」的問題。但 OpenClaw 用戶還有另一個困擾：Agent 有 skill，但沒有實踐經驗。

一個裝了各種 skill 的 OpenClaw Agent，就像一個剛從學校畢業的學生——專業知識有了，但真正上手辦事時，會遇到各種課本里沒寫過的問題。

舉個例子：線上服務報 503，Agent 排查時發現日志里滿是「connection refused」，但數據庫正常。來回折騰二十分鐘后才發現問題在連接池——一條慢查詢卡住了所有連接。kill 掉慢查詢，服務恢復。

這種排障經驗不會寫在任何 skill 的說明文檔里——「數據庫健康但服務報 connection refused 時，檢查連接池是否被慢查詢耗盡」——這是純粹的實踐智慧，只有踩過坑才知道。

問題是：下次另一個 OpenClaw 用戶遇到一模一樣的癥狀，他的 Agent 又得從頭摸索二十分鐘。

人類有同樣的困境——新人排障靠試錯，老師傅一眼就能看出問題。但人和 Agent 有一個根本區別：人不能共享大腦，Agent 可以。

這就是 seekdb M0 的經驗系統要做的事：讓一個 OpenClaw Agent 踩過的坑，所有 OpenClaw Agent 都能受益。

第一個 Agent 花二十分鐘排查出的結論，第二個 Agent 在遇到相似癥狀時直接就能看到——不是因為它自己經歷過，而是因為有別的 Agent 已經經歷過并分享了經驗。

經驗（experience）和記憶（memory）是兩種不同的東西。記憶是個人事實——「用戶喜歡深色模式」「用戶住在杭州」。經驗是通用智慧——「數據庫健康但服務連不上時優先檢查連接池」「部署到容器時需要設置 LANG=C.UTF-8 否則中文會亂碼」。

M0 的經驗系統有四個階段：

自動蒸餾：當一次對話成功完成且涉及工具調用時，seekdb M0 會在后臺異步分析這次交互，提煉出可復用的經驗。這個過程是非阻塞的，不影響正常對話。

分級驗證：新經驗不會立刻對外公開。它有一個生命周期——Draft（剛提取，僅對創建者可見）→ Published（正向反饋累積達到閾值后進入公開池，所有用戶可檢索）→ Deprecated（負向反饋比例過高，標記淘汰）。

自動注入：下次有 Agent 遇到類似場景時，seekdb M0 會在對話開始前檢索相關經驗，和記憶一起注入上下文。Agent 不需要主動去「查經驗」，相關經驗會自動出現在它的視野里。

反饋閉環：Agent 在對話中被注入了某條經驗后，本輪對話的執行結果（成功或失敗）會作為反饋信號自動上報。成功的執行驅動經驗晉升，反復失敗的執行讓低質量經驗被淘汰。

這套機制的關鍵在于：經驗中不包含原始對話內容，只保留蒸餾后的通用知識。一個用戶的隱私信息不會通過經驗系統泄露給其他用戶。隔離是共享的前提。

OpenClaw 的哲學是「讓 Agent 自己干」，seekdb M0 的安裝也遵循這個原則。你只需要對自己的 Agent 說一句話：

閱讀https://m0.seekdb.ai/SKILL.md 并按說明安裝與配置 m0。

Agent 讀取這份文檔后，會自主完成全流程：檢測 OpenClaw 版本 → 獲取 Access Key → 下載插件源碼 → 寫入配置 → 重啟 Gateway。全程無需用戶手動操作。

openclaw.json

人類開發者也可以用更直接的方式驗證服務：

# 確認服務正常curl -s https://m0.seekdb.ai/health# 創建記憶實例curl -s -X POST https://m0.seekdb.ai/api/instances/ \ -H"Content-Type: application/json"\ -d'{"name": "my-memory"}'

返回的字段就是你的 Access Key，之后所有記憶操作都通過這個 Key 認證。

ak

告訴 Agent 一些關于你的事情：

我叫李明，是一名前端工程師，在上海工作。我喜歡 TypeScript 和 React，討厭寫 CSS。周末喜歡打羽毛球。

對話結束后，seekdb M0 會自動提取出 5-6 條事實，經過記憶決策后存入云端。

開一個新 session，測試召回：

幫我寫一個組件

你沒有指定技術棧，但 M0 已自動檢索到你的技術偏好，Agent 會主動提及「技術棧是 React + TypeScript 嗎？」——而不是從零問起。它已經知道你是誰了。

再看看經驗的效果：

假設之前有其他 OpenClaw 用戶的 Agent 在排障過程中總結出了一條經驗——「當服務返回 connection refused 但數據庫進程正常時，優先檢查連接池是否被慢查詢耗盡，而不是反復重啟服務」。這條經驗經過多次驗證后被發布到公開池。

現在你的 Agent 遇到了類似的 503 報錯，seekdb M0 在對話開始前自動檢索到了這條經驗并注入上下文。你的 Agent 不會再花二十分鐘反復重啟，而是直接去檢查慢查詢——五分鐘內解決問題。

最后官宣一下：seekdb M0 今天正式上線了。

回到最初的問題：為什么你的 OpenClaw 會記憶退化？因為它的記憶依賴 MEMORY.md 全量加載和被動的搜索檢索。MEMORY.md 越寫越大，上下文越來越擠；歷史記憶散落在文件中，Agent 需要主動搜索才能想起來，但它不一定知道該搜什么。記得多了會貴，記得少了會忘。這是本地記憶架構的固有局限，不是配置能解決的。

memory/

seekdb M0 選擇的路是：把記憶從上下文中解放出來——獨立存儲、按需檢索、跨 session 持久化。不再全量加載，而是在對的時間想起對的事情。

更讓我興奮的是經驗系統。OpenClaw 社區每天有大量 Agent 在日常工作中積累實踐經驗，但這些經驗是孤立的——每個 Agent 都在獨立試錯。

OpenClaw Agent 有了 skill，就像畢業生有了專業知識。但真正讓它們成為專家的，是經驗。而和人類不同的是，Agent 之間可以直接共享大腦。

這是 seekdb M0 真正想做的事。

• seekdb M0 云端記憶服務：https://m0.seekdb.ai
• PowerMem 開源項目：https://github.com/oceanbase/powermem
• seekdb D0 體驗入口：https://d0.seekdb.ai