ClawMem – 開源代理記憶體，搭載SOTA本地GPU檢索

我一直在開發ClawMem，這是一個開源上下文引擎，讓AI編程代理能夠跨會話擁有持久記憶。它兼容Claude Code（鉤子+MCP）和OpenClaw（ContextEngine插件+REST API），兩者可以共享同一個SQLite儲存庫，因此你的CLI代理和語音/聊天代理能基於同一記憶體運作，無需任何同步。檢索架構是個拼裝怪，這基本上就是我的開發流程。我從最近的專案和研究裡挑出最好的部分，把它們縫合在一起：[QMD](https://github.com/tobi/qmd)用於多信號檢索管線（BM25+向量+RRF+查詢擴展+交叉編碼器重排序），[SAME](https://github.com/sgx-labs/statelessagent)用於結合內容類型半衰期和共激活強化的複合評分，[MAGMA](https://arxiv.org/abs/2501.13956)用於多圖遍歷的意圖分類（語義、時序和因果波束搜索），[A-MEM](https://arxiv.org/abs/2510.02178)用於自我演化的記憶筆記，以及[Engram](https://github.com/Gentleman-Programming/engram)用於去重模式和時序導航。這些原本都不是設計來協同工作的。讓它們協調一致是主要的工作量。在推理方面，QMD的原始堆疊使用300MB的嵌入模型、1.1GB的查詢擴展LLM和600MB的重排序器。這些可以透過llama-server在GPU上運行，或透過node-llama-cpp（Metal、Vulkan或CPU）進行進程內處理。但更有趣的路徑是SOTA升級：ZeroEntropy的蒸餾配對zembed-1+zerank-2。這些是目前MTEB上排名最高的嵌入和重排序模型，並且專為協同工作設計。重排序器是從與嵌入器相同的老師模型蒸餾而來，因此它們共享語義空間。你需要約12GB VRAM來運行兩者，但檢索質量明顯優於預設堆疊。如果你完全不想在本地運行模型，也有雲端嵌入選項。針對Claude Code，它會鉤入生命週期事件。上下文提取會在每次提示時觸發以注入相關記憶，決策提取器和交接生成器捕獲會話狀態，反饋迴圈會強化實際被引用的筆記。這自動處理了大約90%的檢索。另外10%是28個用於顯式查詢的MCP工具。對於OpenClaw，它註冊為ContextEngine插件，具有相同的生命週期鉤子映射，外加5個供代理直接呼叫的REST API工具。它在Bun上運行，使用單一SQLite儲存庫（WAL模式，FTS5+vec0）。所有內容都在設備上；除非你選擇雲端嵌入，否則沒有雲端依賴。整個系統是自包含的。這是一個打磨中的進行中作品，不是成品。我是獨立開發者。程式碼庫約19K行，主要儲存模組是一個4K行的上帝物件，可能需要拆分。當然，系統的效果取決於你索引的內容。只有三個記憶檔案的儲存庫自然會給出稀薄的結果。而包含你的專案文檔、研究筆記和決策記錄的儲存庫，則能提供真正有用的東西。我真心想聽聽大家對兩個問題的看法：(1) 有沒有人嘗試過在本地運行SOTA嵌入+重排序模型來處理代理記憶體？質量差異是否值得消耗VRAM？(2) 對於那些運行多個代理介面（CLI+語音/聊天）的人，你們目前是如何處理共享記憶體的？