Nocturne Memory：把 AI 記憶從向量檢索搬到可回滾的樹狀資料庫
A lightweight, rollbackable, and visual Long-Term Memory Server for MCP Agents. Say goodbye to Vector RAG and amnesia. Empower your AI with persistent, graph-like structured memory across any model, session, or tool. Drop-in replacement for OpenClaw.
秒懂
- 它是什麼？
- 這個 MCP Server 用 SQLite 或 PostgreSQL 存記憶，用路徑定址、用 diff 回滾，取代向量 RAG 的機率式召回。它解決的是跨模型、跨會話的身分延續問題，代價是你得自己管一個資料庫和一套審核流程。
- 適合誰用？
- 如果你同時在多個 MCP 客戶端之間切換模型，又希望記憶不隨平台消失，Nocturne Memory 的獨立 Server 架構值得部署一套來驗證；如果你只需要單一平台內的對話連續性，或無法接受由人類審核 AI 的記憶寫入，那它會變成多餘的中介層。動手前先確認三件事：你的 Python 是否在 3.10 以上、Node.js 是否可用於首次建置 Dashboard、以及你的客戶端要指向 backend/mcp_server.py 還是 backend/mcp_wrapper.py（Antigravity 走後者）。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 20 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解的不是檢索準確率，是換模型就失憶
多數記憶方案把資料綁在平台內：ChatGPT 的記憶留在 ChatGPT，Claude 的記憶留在 Claude。README 把這件事講得很直白，換一個模型，一切歸零。Nocturne Memory 的做法是把記憶抽出來放進一個獨立的 MCP Server，LLM 只是連上來的客戶端。今天用 Claude，明天用 Gemini，後天換本地模型，讀到的是同一份資料。
目標使用者因此不是「想讓聊天機器人記得我上次問過什麼」的人，而是把 AI 當成一個跨工具持續存在的角色在經營的人。README 的用例很能說明這個定位：一個是工作策略討論，AI 主動去讀 core://work_jobstation/strategic_position 與 commercialization 兩條記憶；另一個是情緒陪伴，使用者只說「沒力氣洗澡，也沒力氣吃飯」，AI 讀了 core://salem/survival_state 之後直接回覆「那就都不做」。這不是問答輔助，是把累積數月的私人上下文當成推論前提。
它同時支援 Namespace 隔離，README 舉的例子是同時養 Alice 與 Bob 兩個不同人格，各自擁有獨立記憶空間。這個設計是為了避免多個角色互相污染彼此的記憶庫，在單一使用者跑多個代理時是必要的。
路徑定址取代相似度召回
README 明確說「Say goodbye to Vector RAG」，改用 graph-like structured memory。從範例看，實際的資料組織方式是階層式路徑：system://boot 是開場載入的核心設定，core://work_jobstation/commercialization 是某個主題下的子節點，core://nocturne/salem/dynamics/nipple_size_calibration_slut_shaming 這種長路徑說明節點可以一直往下長。
檢索動作有兩個：read_memory 直接按路徑取節點，search_memory 用關鍵字找。範例中的呼叫順序是固定的，先 read_memory("system://boot")，再 search_memory 或直接讀具體路徑。這代表資料流是「開場只載入骨架，其餘按需拉取」，而不是把整庫塞進 context。README 給的數字是：在 96.9 萬字的記憶庫中，首條訊息僅載入 7.2K 字；過去 30 天全庫 78% 的記憶曾在某次對話中被想起。這兩個數字來自專案自己的說明，我沒有獨立驗證。
這個設計的關鍵差異在於可控性。向量檢索回傳的是「最相近的幾段」，你無法預測這次會撈到什麼；路徑定址回傳的是「你指定或 AI 明確選中的節點」，可審計、可重現。代價是 AI 必須知道路徑名稱，這依賴 system://boot 裡寫了足夠的索引，或搜尋功能足夠準。README 沒有說明 search_memory 的實作是關鍵字比對還是其他方式，這是我無法從材料確認的部分。
從 clone 到接上客戶端
安裝只有兩步。前置需求是 Python 3.10 以上，以及 Node.js，後者用於首次啟動時自動建置 Dashboard 前端。
第一步：
git clone https://github.com/Dataojitori/nocturne_memory.git cd nocturne_memory pip install -r backend/requirements.txt
第二步是在你的 MCP 客戶端設定裡加入這個 Server。README 在安裝段落被截斷，沒有給出完整的 JSON 範例，但給了一個容易踩到的細節：Antigravity 的 args 必須指向 backend/mcp_wrapper.py，用來解決 Windows 的 CRLF 問題；其他客戶端指向 backend/mcp_server.py。
如果不想自己裝，README 提供一個公共 Demo，位址是 https://misaligned.top/mcp。OpenAI Codex 在 .codex/config.toml 中加：
[mcp_servers.nocturne_memory_demo] url = "https://misaligned.top/mcp"
Antigravity 則在 MCP 設定中加 serverUrl 欄位，值相同。要注意 Demo 是唯讀，只開放 read_memory 與 search_memory，寫入能力必須自架。這個限制很重要：記憶系統的價值大半在寫入與審核，只讀 Demo 能驗證的是檢索體驗，不是完整工作流。
讀者也要注意，README 的 MCP 設定範例只涵蓋 Codex 與 Antigravity 兩種寫法，其餘客戶端（Cursor、Claude Desktop、GitHub Copilot 等）的具體 JSON 結構需要自行對照各客戶端文件。
版本安全網與人類審核閘門
README 的截圖標題透露了幾個機制：Memory Explorer 是樹狀瀏覽，Memory Detail 可即時編輯內容、元數據與觸發條件，Review & Audit 提供可視化 diff 與一鍵接受或回滾，版本安全網則寫明「AI 每次操作自動備份，清理需人類確認」。
這是整個專案最實質的設計主張。多數記憶方案讓模型直接寫入，錯了就錯了；Nocturne Memory 把 AI 的寫入當成待審變更，人可以看 diff 再決定接受或回滾。對於會累積數十萬字、且其中包含私人情緒內容的記憶庫來說，這個閘門是必要的，因為一次錯誤的覆寫可能抹掉幾個月的上下文。
代價是流程變重。如果 AI 每次寫入都要人確認，高頻的記憶更新就不可行，使用者會被審核佇列綁住。README 沒有說明是否存在自動接受規則、批次審核或信任層級設定，這是我從材料無法確認的部分，也是實際導入前最該先問清楚的一件事。
儲存層支援 SQLite 與 PostgreSQL 兩種，README 的徽章列出這個組合。SQLite 適合單機單人，PostgreSQL 適合需要並發或多裝置存取的場景，但材料沒有給出兩者的切換方式或遷移路徑。
不適合它的三種情況
第一，如果你只需要單一平台內的對話連續性，這個架構是多餘的。你等於在自己和模型之間插了一個資料庫、一個 MCP Server、一套審核介面，換來的是你本來就不需要的跨模型可攜性。
第二，如果你的記憶內容是大量非結構化的文件，需要的是「從十萬份文件裡找出相關段落」，路徑定址會逼你事先決定樹狀結構。向量檢索在這種場景反而省事，因為它不需要你設計階層。Nocturne Memory 的樹狀組織假設你願意維護一套分類，這個維護成本會隨記憶量上升。
第三，README 中收錄的對話範例包含明確的成人內容與帶有羞辱語言的互動。這不是技術問題，但決定了它能不能出現在某些環境裡。團隊或組織導入前必須先確認這類內容是否符合可接受使用規範，因為記憶庫一旦建立，這些內容就是持久化的。
另外，README 自稱是 OpenClaw 的 drop-in replacement，但材料沒有說明替換的具體步驟或 API 對應關係，這句話目前無法從提供的內容驗證。
與向量 RAG 的實際差異
拿向量資料庫加 RAG 管線來比最直接。那條路線的流程是：文件切塊、算嵌入、存向量索引、查詢時用相似度取回 top-k 段落塞進 context。它的優點是不需要事先設計結構，丟進去就能查。
Nocturne Memory 走的是另一條：記憶是具名節點，有固定路徑，有版本歷史，有觸發條件。檢索不是「找最像的」，而是「讀指定的」加上「搜尋命名的」。這個差異在除錯時最明顯：RAG 撈錯段落你很難解釋為什麼，因為那是嵌入空間的距離問題；路徑讀錯你可以直接打開 Memory Explorer 看到是哪個節點內容寫壞了，然後改它、看 diff、決定要不要回滾。
但反過來說，RAG 的擴充是無痛的，你丟進更多文件不會讓結構崩壞。Nocturne Memory 的樹狀結構需要人維護，節點放錯位置、命名不一致、舊節點沒清理，都會讓 AI 的檢索路徑失準。README 提到「孤兒恢復」出現在 2.5.4 版的功能列表裡，這暗示節點失去父層參照是實際會發生的問題。
兩者並非互斥。你可以把 Nocturne Memory 當成核心人格與長期事實的儲存層，把向量檢索留給大量文件問答。README 沒有提到這種混用方式，但架構上不衝突。
維護成本與授權
專案以 MIT 授權發布，這意味著你可以商用、修改、再散布，只要保留著作權聲明。我不提供法律建議，實際使用前請自行確認授權全文與你的使用情境是否相符。
維護面有幾項要納入考量。Python 3.10 以上的門檻不算高，但 Node.js 只在首次啟動時用於建置前端，這表示升級版本後可能需要重新建置。儲存層有 SQLite 與 PostgreSQL 兩條路徑，選擇 PostgreSQL 就等於多一個要備份、要升級的服務。
版本節奏可以從近期 release 看出輪廓：2.5.2 是重大 Bug 修復與中文支援，2.5.4 加入 Boot 預設切換與孤兒恢復，2.5.6 處理 MCP 2.0 相容性與長文本改進。三個版本分別對應穩定性、資料完整性與協定相容性，說明維護是活躍的，但也代表升級時要留意 MCP 協定層的變動，客戶端與 Server 的版本可能需要同步。
README 提到有 docs/testing.md 這份後端測試說明。在把真實記憶寫進去之前，先照著跑一遍後端測試，會比直接信任文件更踏實。
編輯結論
如果你同時在多個 MCP 客戶端之間切換模型，又希望記憶不隨平台消失，Nocturne Memory 的獨立 Server 架構值得部署一套來驗證；如果你只需要單一平台內的對話連續性，或無法接受由人類審核 AI 的記憶寫入，那它會變成多餘的中介層。動手前先確認三件事：你的 Python 是否在 3.10 以上、Node.js 是否可用於首次建置 Dashboard、以及你的客戶端要指向 backend/mcp_server.py 還是 backend/mcp_wrapper.py（Antigravity 走後者）。先跑一次 read_memory("system://boot") 看回傳的內容是否符合你對「核心設定」的預期，再決定要不要把真實記憶寫進去。
社群筆記