OpenClaw 記憶體外掛的選擇，直接決定你的 AI agent 到底是每次對話都從零開始，還是能累積三個月的工作脈絡。 截至 2026 年 3 月，OpenClaw 在 GitHub 上累積超過 257,000 顆星，ClawHub 生態系已有 5,700 多個社群外掛。光是記憶體相關的選項就至少有六種以上——預設的 memory-core、memory-lancedb、memory-lancedb-pro、OpenViking（Volcengine/字節跳動）、gigabrain、Hindsight、Basic Memory、Cognee，還有 Shopify 創辦人 Tobi Lütke 做的 QMD。
這篇文章根據實際安裝和使用經驗，比較其中四個最具代表性的方案：預設 memory-core、memory-lancedb-pro、OpenViking、gigabrain。每個方案的檢索架構、安裝成本和適用場景不同，選錯了要嘛浪費 token，要嘛 agent 記性跟金魚一樣。
先搞懂問題：OpenClaw 預設記憶怎麼運作
OpenClaw 的記憶系統建在純 Markdown 檔案上。agent 的長期記憶存在 MEMORY.md，每日紀錄存在 memory/YYYY-MM-DD.md。底層用 SQLite 建索引，搭配 FTS5 全文檢索和 sqlite-vec 向量搜尋。
啟動新對話時，系統自動載入當天和昨天的日誌加上 MEMORY.md。更早的記憶？agent 得主動呼叫 memory_search 工具才找得到。問題出在兩個地方：第一，agent 要自己判斷什麼值得記住，手動寫入檔案；第二，MEMORY.md 長到一定程度後，每次對話都會重新讀取整個檔案，token 消耗開始失控。
LanceDB 官方部落格用 LoCoMo10 基準測試做了三種後端的系統性比較。預設 memory-core 的任務完成率約 35.65%，切換到 LanceDB 基本版就有明顯提升，再換到 memory-lancedb-pro 則進一步拉開差距。原因不只是「向量搜尋比較好」，而是工具呼叫流程本身就不一樣。
memory-lancedb-pro：目前最實用的升級路徑
memory-lancedb-pro 是 CortexReach 團隊開發的增強版 LanceDB 記憶外掛，定位是預設 memory-lancedb 的直接替代品。安裝方式是 npm i memory-lancedb-pro@beta，然後在 openclaw.json 裡把 memory slot 指向它。
跟預設版本比，核心差異在檢索管線。預設版本只做向量搜尋，memory-lancedb-pro 加了完整的混合檢索流程：向量搜尋加 BM25 全文檢索，透過 RRF（Reciprocal Rank Fusion）融合分數，再用 Jina reranker-v3 做交叉編碼器重排序。最後疊上時間衰減（Weibull decay）、重要性加權、長度正規化和 MMR 多樣性過濾。
| 功能 | 預設 memory-core | memory-lancedb-pro |
|---|---|---|
| 檢索方式 | FTS5 + sqlite-vec | 向量 + BM25 混合，RRF 融合 |
| 重排序 | 無 | Jina / SiliconFlow / Voyage 交叉編碼器 |
| 記憶生命週期 | 永久保留 | Weibull 衰減，高頻存取自動提升 |
| 工具呼叫次數 | 兩次（search → get） | 一次（recall 直接回傳） |
| 多範圍隔離 | 無 | global / agent / project / user 層級 |
| 管理 CLI | 無 | openclaw memory-pro list/search/stats/delete |
| 嵌入模型 | OpenAI text-embedding-3-small | 任何 OpenAI-API 相容（OpenAI / Gemini / Jina / Ollama） |
實際使用上，memory-lancedb-pro 解決了兩個日常痛點。一是「記憶太多之後檢索品質下降」：BM25 處理精確匹配（像 API key 格式、特定錯誤訊息），向量搜尋處理語意相似度，兩者互補。二是「跨專案記憶汙染」：多範圍隔離功能可以讓不同 agent 或專案各自維護獨立記憶空間。
配置推薦用 Jina 同時處理嵌入和重排序。嵌入用 jina-embeddings-v5-text-small（1024 維），重排序用 jina-reranker-v3，候選池 12 筆，最低分數門檻 0.6。向量權重 0.7、BM25 權重 0.3 是社群測試後公認的平衡點。
要注意的是，memory-lancedb-pro 的 auto-capture（自動擷取）每回合最多存 3 筆記憶，用 LLM 做六類分類（偏好/事實/決定/實體/技巧/錯誤修復）。如果需要從歷史對話批量萃取記憶，推薦搭配 JSONL 蒸餾管線：在每次 /new 指令後，systemd worker 用 Gemini Map-Reduce 處理對話 JSONL，萃取出 0-20 條高信號記憶寫回 LanceDB。
OpenViking：字節跳動的結構化上下文資料庫
OpenViking 來自字節跳動旗下的火山引擎 Viking 團隊，2026 年 1 月開源，到 3 月已累積超過 15,000 顆 GitHub 星。OpenViking 自稱「Context Database」，不只是記憶外掛，而是把 agent 需要的所有上下文（記憶、資源、技能）統一管理。
架構上最大的差異是「檔案系統範式」。OpenViking 用 viking:// 協議建立虛擬檔案系統，agent 可以像在終端機操作一樣用 ls、find、tree 瀏覽上下文結構。這跟傳統 RAG 的「扁平向量儲存」完全不同。
更關鍵的是三層上下文載入機制：
| 層級 | token 量 | 用途 |
|---|---|---|
| L0（摘要） | ~100 tokens | 一句話描述，用於快速相關性判斷 |
| L1（概覽） | ~2,000 tokens | 結構化摘要，足夠做規劃決策 |
| L2（詳情） | 完整內容 | 只在 agent 真正需要深入時按需載入 |
agent 多數時候只需要 L0/L1，不用把整份文件塞進 prompt。這就是為什麼 OpenViking 在 LoCoMo10 基準測試上，task completion rate 從預設的 35.65% 提升到 52.08%，同時輸入 token 成本降了 83-96%。
安裝比 memory-lancedb-pro 複雜一些。需要 Python 環境、嵌入 API（OpenAI text-embedding-3-large 約 USD 0.13/M tokens），還需要一台至少 2 CPU、4GB RAM 的機器跑 OpenViking 服務端。設定檔用 ~/.openviking/ov.conf，需要配置 VLM 模型（用於文字理解）和嵌入模型。
OpenViking 適合的場景是：agent 需要管理大量外部文件（GitHub repo、技術文件、專案文檔），而且跨對話的上下文需求複雜。如果你的 agent 主要是記住使用者偏好和日常對話脈絡，memory-lancedb-pro 就夠了。如果 agent 要在 20 份技術文件裡精準定位特定段落，OpenViking 的檔案系統範式就有優勢。
gigabrain：世界模型取向的記憶引擎
gigabrain 走了跟前兩者完全不同的路。它不只存文字片段，還建立「世界模型」：entities（實體）、beliefs（信念）、syntheses（綜合結論）、open loops（待解決事項）。全部存在本地 SQLite + FTS5 裡。
架構是這樣的：agent 對話時，gigabrain 透過 capture 機制把資訊分類存入 registry。recall 階段則由 orchestrator 自動選擇最適合的檢索策略：快速上下文、實體摘要、時間軸摘要，或驗證導向的回溯。它還支援原生同步到 MEMORY.md（雙向），以及 Obsidian vault 鏡像，方便用 Obsidian 瀏覽和管理 agent 記憶。
實際體感是 agent 開始產生「跨脈絡的連結」。舉例來說，你在一次對話裡提到某個同事負責認證模組，三週後問「認證權限找誰」，gigabrain 的世界模型能透過實體關係直接關聯，而不是靠語意相似度碰運氣。
代價是延遲。世界模型的維護需要額外運算，在 Mac Mini M4 上能感覺到每次回應多了一點等待時間。而且 gigabrain 相對年輕（截至 2026 年 3 月版本 0.5.x），社群生態不如 memory-lancedb-pro 成熟。
安裝方式是 openclaw plugins install @legendaryvibecoder/gigabrain，然後跑 setup 腳本。它也支援 Claude Code 和 Codex CLI，不限定 OpenClaw 環境。
嵌入模型的選擇：Gemini Embedding 2 值得關注
不管用哪個記憶外掛，嵌入模型的品質直接影響檢索準確度。Gemini Embedding 2（gemini-embedding-2-preview）是 Google 在 2026 年 3 月 10 日發布的公開預覽版，有幾個特點讓它適合搭配 OpenClaw 記憶系統：
第一，Matryoshka Representation Learning（MRL）支援動態維度：768、1536、3072。768 維的品質跟 3072 幾乎一樣，但儲存量只有四分之一。100 萬筆向量在 3072 維約 12 GB，768 維降到 3 GB。
第二，免費額度夠個人使用。Gemini API 的免費層每分鐘 1,500 次請求，pricing 是 USD 0.15/M tokens。對個人 agent 來說，月成本可能低於 USD 1。
第三，原生多模態。Gemini Embedding 2 同時支援文字、圖片、影片、音訊和 PDF 嵌入到同一個向量空間。這表示你可以把截圖和對話文字一起索引，agent 搜尋時能跨模態找到相關內容。
memory-lancedb-pro 的嵌入層相容任何 OpenAI-API 格式的 provider，所以切換到 Gemini 只要改 config 裡的 baseURL 和 model 欄位。
四種方案怎麼選
| 維度 | memory-core（預設） | memory-lancedb-pro | OpenViking | gigabrain |
|---|---|---|---|---|
| 安裝複雜度 | 零（內建） | 低（npm install + config） | 中高（Python + 服務端） | 中（npm + setup script） |
| 檢索品質（LoCoMo10） | 35.65% | 顯著高於預設 | 52.08%（官方數據） | 未公開基準 |
| token 成本 | 高（整檔載入） | 中（按需檢索） | 低（L0/L1/L2 分層） | 中 |
| 適用場景 | 輕度使用、短期對話 | 日常 agent、多專案管理 | 大量文件管理、企業級 | 需要關係推理的複雜工作流 |
| 延遲 | 低 | 低-中 | 中 | 中-高 |
| 社群成熟度 | 最高（官方） | 高（活躍開發中） | 中（早期，v0.2.x） | 低（v0.5.x） |
如果你現在要做一個選擇，我的建議是：先裝 memory-lancedb-pro 搭配 Jina 嵌入和重排序。這是投資報酬率最高的升級路徑——安裝 10 分鐘，效果馬上有感。等你的 agent 跑了一兩個月、記憶量到了幾百條以上，再評估要不要加 OpenViking 處理外部文件，或用 gigabrain 做更深層的知識關聯。
如果你不想自己管 OpenClaw 的基礎架構，Anthropic 在 2026 年 3 月底推出的 Claude Code Channels 是另一條路。透過 Discord 或 Telegram 直接跟 Claude Code 互動，不用自建 gateway。不過 Channels 目前的記憶和外掛生態還比不上 OpenClaw 社群的深度。
OpenClaw 記憶外掛跟 Claude Code 的記憶系統差在哪？
OpenClaw 記憶外掛用外部向量資料庫（LanceDB、SQLite）做持久化儲存和語意檢索，agent 的記憶可以跨對話、跨週甚至跨月保留。Claude Code 內建的記憶是 CLAUDE.md 加上 session 內的 context window，重啟後只保留 CLAUDE.md 裡手動寫入的內容。兩者可以互補：在 Claude Code 環境裡也能安裝 gigabrain 或 memsearch 外掛來增強記憶。
memory-lancedb-pro 的嵌入模型該選哪個？
社群主流推薦 Jina embeddings-v5-text-small（1024 維），原因是支援 task-aware 嵌入（查詢時用 retrieval.query、儲存時用 retrieval.passage），跟 Jina reranker 搭配效果最好。如果要省成本，Gemini Embedding 2 的免費額度很大方。如果完全離線運作，Ollama 搭配 bge-m3 是可行的替代方案。
OpenViking 跟 memory-lancedb-pro 可以同時用嗎？
可以，但不建議同時啟用兩者的 auto-recall。OpenViking 官方測試有附帶 memory-core 啟用和停用兩種設定，結果差異不大（51.23% vs 52.08%）。實務上比較好的做法是讓 OpenViking 管外部資源和文件，memory-lancedb-pro 管對話產生的偏好和決策記憶，各司其職。
在 Mac Mini 上跑 OpenClaw 記憶外掛，硬體門檻是什麼？
Mac Mini M4 基本款（16GB RAM）可以跑 OpenClaw 加 memory-lancedb-pro，沒問題。如果要加 OpenViking 服務端和離線嵌入模型（如 Ollama + bge-m3），建議至少 32GB RAM。gigabrain 的 SQLite 世界模型本身不吃太多記憶體，但如果同時跑 nightly 維護管線會有短暫的 CPU 尖峰。API 費用方面，中度使用的 Anthropic API 成本大約 USD 10-15/天，嵌入 API 另計。
記憶外掛的安全性考量有哪些？
OpenClaw 在 2026 年初曾爆出 CVE-2026-25253（CVSS 8.8）的遠端代碼執行漏洞，已在 2026.1.29 版修補。記憶外掛本身儲存在本機 SQLite 或 LanceDB 裡，資料不會離開你的機器（除非你主動設定外部 API）。但要注意：auto-capture 會把對話內容萃取後存入記憶資料庫，如果對話裡包含機敏資訊（API key、密碼），可能會被永久儲存。memory-lancedb-pro 有 scope 隔離功能，可以限制特定 agent 的記憶存取範圍。
引用來源
- LanceDB — Memory for OpenClaw: From Zero to LanceDB Pro
- GitHub — CortexReach/memory-lancedb-pro
- GitHub — volcengine/OpenViking
- MarkTechPost — Meet OpenViking: An Open-Source Context Database for AI Agent Systems
- GitHub — legendaryvibecoder/gigabrain
- Google Blog — Gemini Embedding 2: Our first natively multimodal embedding model
- VentureBeat — Anthropic just shipped an OpenClaw killer called Claude Code Channels
我們團隊替客戶評估 AI Agent 的導入方案，包括 OpenClaw、Claude Code 和 n8n 的比較。記憶系統的選擇是我們在實際部署中反覆踩坑的環節——特別是跨專案記憶汙染和 token 成本失控這兩個問題，在 memory-lancedb-pro 的多範圍隔離和混合檢索出來之前，幾乎沒有好的解法。
如果你在評估 OpenClaw 或 Claude Code 的企業導入策略，或者想搞清楚哪種記憶架構適合你的場景，歡迎跟 Tenten 團隊預約諮詢。
