seekdb M0：讓OpenClaw記憶不丟失、經(jīng)驗可共享

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

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

作者 | 傅榕鋒 OceanBase 高級技術(shù)專家，seekdb M0 研發(fā)團隊負責人

如果你在用 OpenClaw，你大概率經(jīng)歷過這樣的場景：

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

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

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

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

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

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

seekdb M0 官網(wǎng)：https://m0.seekdb.ai/

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

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

循環(huán)一：越記越貴。

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

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

循環(huán)二：越忘越錯。

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

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

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

memory/YYYY-MM-DD.md

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

web_fetch

exec

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

需要第三條路。

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

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

這意味著：

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

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

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

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

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

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

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

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

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

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

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

工具調(diào)用自動壓縮：零 LLM 開銷

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

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

tool_result_persist

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

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

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

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

經(jīng)驗系統(tǒng)：從應屆生到專家

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

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

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

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

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

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

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

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

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

M0 的經(jīng)驗系統(tǒng)有四個階段：

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

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

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

反饋閉環(huán)：Agent 在對話中被注入了某條經(jīng)驗后，本輪對話的執(zhí)行結(jié)果（成功或失敗）會作為反饋信號自動上報。成功的執(zhí)行驅(qū)動經(jīng)驗晉升，反復失敗的執(zhí)行讓低質(zhì)量經(jīng)驗被淘汰。

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

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

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

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

openclaw.json

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

# 確認服務正常curl -s https://m0.seekdb.ai/health# 創(chuàng)建記憶實例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。周末喜歡打羽毛球。

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

開一個新 session，測試召回：

幫我寫一個組件

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

再看看經(jīng)驗的效果：

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

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

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

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

memory/

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

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

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

這是 seekdb M0 真正想做的事。

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