LongMemory：把「時間」放回 AI 記憶的本地優先記憶引擎
Local persistent memory store for LLM applications including claude desktop, github copilot, codex, antigravity, etc.
秒懂
- 它是什麼？
- LongMemory 是一個以 SQLite 為基礎的本地記憶引擎，強調時間真實性、不可變內容與治理邊界。它不只是一套 RAG 管線，而是把「當時的事實」與「現在的事實」分開處理的認知架構。
- 適合誰用？
- LongMemory 適合需要時間感知與治理邊界的 AI 應用，例如多租戶助手、法遵紀錄或需要追溯事實變遷的專案。它不適合只想快速做向量搜尋的團隊，因為它的核心價值在於時間與治理模型，而這需要你改變對記憶的思考方式。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
不是另一條 RAG 管線
多數號稱記憶的系統，本質上是把文字切塊、嵌入、然後回傳最近的向量。LongMemory 的 README 直接點出這個問題：這種做法無法回答「某個時間點什麼為真」、「新事實是否取代舊事實」、「哪個來源有權威性」。LongMemory 把這些問題當成第一公民。它用 SQLite 做持久化，強調不可變的內容、來源紀錄與時間真實性。對工程師而言，這意味著你不必在應用層自己維護事實版本表，而是由記憶引擎幫你處理。
時間真實性：錄入時間與有效時間分離
LongMemory 的核心設計是「錄入時間」與「有效時間」分離。錄入時間是記憶被寫入的時刻，有效時間是該事實真正成立的時刻。這在 recall 時產生四種模式：strict 套用時間、矛盾、契約、信心與接地閘門；historical 保留被取代的舊事實，例如查詢「一月時的部署區域」；associative 混合語意、詞彙、實體、激活與圖譜訊號；world_grounded 則要求目前的外部證據。這不是花俏的 API 設計，而是對「事實會改變」的直接回應。若你的應用需要回答「當時的狀態」而非「現在的狀態」，這種分離才有意義。
從 npm 套件到 Docker 服務的啟動路徑
最快的使用方式是安裝 npm 套件。文件給了一個 10 秒範例：import { createMemory } 之後呼叫 ingest 寫入文字，再用 recall 查詢。沒有外部服務，記憶存在記憶體。若要持久化，傳入 store: 'sqlite' 與 db_path，重新開啟同一檔案就會還原所有節點、世界、實體、邊與時間歷史。CLI 版本提供 init 與 recall 指令，例如 longmemory recall "current project priorities" --mode associative。要當成服務跑，可以從原始碼建置，API 預設監聽 127.0.0.1:7331，也可以用 Docker 映像 ghcr.io/caviraoss/longmemory。docker compose 加上 --profile ui 會啟動儀表板在 port 3000。整體安裝路徑算清晰，但依賴 pnpm 與 corepack，若你的環境沒有這些工具，得先處理。
治理與不可變內容：記憶不是可以亂改的資料
LongMemory 把治理直接放進記憶模型。project、tenant、user、team、role、agent、task 與 framework 這些範圍都會被強制執行。工具參數無法覆蓋伺服器綁定的執行身分，這對多租戶應用是關鍵。另外，內容、向量、雜湊與來源不會被 recall 或衰減過程改寫，這保證了稽核軌跡。文件提到生命週期包含確定性衰減、明確強化、合併、壓縮與再合併。這表示記憶不只是寫入與讀取，而是會隨時間變化的動態系統。對需要法遵或稽核的應用，不可變性是賣點；但對只想快取對話內容的開發者，這種複雜度可能過頭。
整合面：MCP、VS Code 與各種代理主機
LongMemory 提供多種操作表面：HTTP、MCP、儀表板、VS Code 擴充、n8n 等。MCP 有兩種啟動方式：本機 stdio 用 longmemory mcp --db .longmemory/project.db --project current，HTTP 則用 LONGMEMORY_API_KEY 環境變數搭配 longmemory serve --mcp-http。文件列出 13 個高階治理工具，以及可讀的資源與代理工作流程提示。整合清單包含 Claude Code、Codex、ChatGPT、Copilot Chat、Cline 等，session porter 可以把這些工具的紀錄匯入。這讓 LongMemory 不只是函式庫，而是代理生態系中的記憶層。但要注意，這些整合大多需要你自行設定 API key 與權限，文件沒有提供逐步教學。
限制與不適用的場景
LongMemory 的文件沒有隱藏它的前提：它需要 embedding 服務。支援 OpenAI 相容 API、Gemini、AWS Bedrock、Ollama 等，但這表示你不能完全離線，除非自己跑 Ollama 或本地 HTTP 模型。第二個限制是 SQLite 的寫入瓶頸。SQLite 是單寫入者的資料庫，若你的應用需要高並發寫入，這會成為瓶頸。文件沒有提供分散式部署選項，所以 scale-out 不是它的設計目標。第三，它仍在 Beta，v1.3.0 是 2025 年 12 月釋出，但版本號帶有 Beta 標記，代表 API 可能變動。若你的專案需要長期穩定，這點要考慮。最後，若你的需求只是「找出相似段落」，LongMemory 的學習曲線與記憶模型會是多餘的。
替代方案與本質差異
最直接的替代品是向量資料庫如 Chroma 或 Qdrant，再加上自己維護時間戳與版本。但這就回到 LongMemory 想解決的問題：你必須自己處理事實取代、來源權威與權限過濾。另一類是 RAG 框架如 LlamaIndex，它提供檢索管線，但時間真實性不是核心。LongMemory 的差異在於把「時間」與「治理」當成資料模型的一部分，而不是事後加上的欄位。若你的應用只需要最近的事實，傳統向量檢索加上 updated_at 欄位可能就夠。但若你需要回答「當時的決策依據」或「誰在何時看到什麼」，LongMemory 的內建機制會省下大量自製程式碼。
維護成本與授權考量
LongMemory 使用 Apache-2.0 授權，這對商業使用相對友善，但你必須保留版權聲明。專案最後一次推送是 2026 年 8 月，代表目前仍在積極開發。作為 Beta 軟體，升級成本可能包含 schema 變更或 API 調整。你需要自行追蹤 release note，例如 v1.2.2 到 v1.3.0 之間就有多次更新。若你採用 Docker 部署，映像檔更新是例行工作，但若你深入使用記憶模型，任何內部格式變動都可能需要遷移。文件沒有提供備份或還原的詳細指引，所以你需要自己設計 SQLite 檔案的備份策略。整體來說，這不是一個裝了就不管的套件，而是需要你理解其記憶生命週期的工具。
編輯結論
LongMemory 適合需要時間感知與治理邊界的 AI 應用，例如多租戶助手、法遵紀錄或需要追溯事實變遷的專案。它不適合只想快速做向量搜尋的團隊，因為它的核心價值在於時間與治理模型，而這需要你改變對記憶的思考方式。採用前應先驗證：你的 embedding 服務是否與 OpenAI 相容，以及你是否願意接受 SQLite 的單機寫入限制。若你的應用只需簡單的相似度檢索，現有的向量資料庫加上時間戳欄位可能更輕量。最後，確認你對 Apache-2.0 的條款沒有疑慮，並準備好自己維護這個仍在 Beta 階段的引擎。
社群筆記