MemMachine：把代理記憶拆成三層，代價是你要同時養 Neo4j 與 SQL
Universal memory layer for AI Agents. It provides scalable, extensible, and interoperable memory storage and retrieval to streamline AI agent state management for next-generation autonomous systems.
秒懂
- 它是什麼？
- MemMachine 是 Apache-2.0 的 Python 專案，替 AI 代理提供跨 session 的長期記憶。它把記憶分成 working、episodic、profile 三類，episodic 走圖資料庫、profile 走 SQL，並附上 MCP server 與多個框架的整合範例。
- 適合誰用？
- 如果你的代理需要跨 session 記住使用者偏好與對話脈絡，而且團隊已經在跑 Neo4j，MemMachine 的三層記憶切分與 Python SDK 值得進評估清單；如果只是想在同一次對話內維持 context，或不想維運圖資料庫，這個專案的儲存前提會先把你擋在門外。動手前先確認兩件事：memmachine-server 的部署方式與版本對應關係，以及 episodic memory 寫入時實際會呼叫哪個 LLM provider，因為這兩項決定了你的成本結構與資料落地位置。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解的問題：代理換一次 session 就失憶
多數 LLM 應用在對話結束後就丟掉上下文。使用者下週回來，代理不記得他偏好靠走道座位，也不記得上次談到哪個階段。把整段歷史塞進 prompt 是最直覺的作法，但脈絡長度有上限，成本也隨 token 數上升。MemMachine 的定位就是把這件事外部化：README 開頭寫的是「Stop building stateless agents」，並宣稱用 5 行左右的程式碼就能接上持久記憶。
它的目標讀者寫得很明確：開發 AI 代理與助理的工程師、實驗代理架構的研究者，以及需要跨 session 記憶的團隊。範例代理涵蓋 CRM、醫療導航、個人理財顧問與寫作助理。這幾個場景的共同點是使用者會反覆回來，而且每次回來都預期對方記得自己。反過來說，單次問答、無狀態的批次推論，接上 MemMachine 只是多一層網路與儲存開銷。
三層記憶的分工，以及它為什麼需要兩種資料庫
MemMachine 把記憶切成三類。Working memory 是當前 session 的短期上下文；Episodic memory 是跨 session 的對話脈絡，README 描述為 graph-based；Profile memory 放的是長期使用者事實與偏好，存在 SQL 裡。這三層不是同一份資料的三種視圖，而是三種不同的查詢模式。
分工的理由在架構圖的說明裡：episodic memory 進圖資料庫，profile memory 進 SQL。對話脈絡的查詢常常是「跟這段話相關的過去事件有哪些」，這種關聯展開用圖走訪比在關聯式資料表裡做多層 join 自然。使用者偏好則是典型的鍵值式事實，「alice 的座位偏好是什麼」用 SQL 一行查完。分開存的代價，是部署時你同時要維運 Neo4j 與一套 SQL 資料庫。這不是可以省略的細節，而是這個專案最基本的維運前提。
值得注意的是三層之間的邊界由誰決定。README 沒有交代 episodic 與 profile 的寫入是由 LLM 抽取後自動分類，還是由呼叫端明確指定。範例裡出現 metadata={"category": "travel"} 這樣的參數，暗示呼叫端可以附帶標籤，但這是否影響資料最終落在哪一層，從現有材料看不出來。這是評估時應該先讀 API Reference 確認的地方。
從 pip install 到第一次 search：實際會打到的介面
README 的 Quick Start 分成兩步。先安裝 client：
pip install memmachine-client
再建立連線與記憶實例。範例中 MemMachineClient 以 base_url 指向本機 8080 埠，接著用 get_or_create_project 取得專案，參數是 org_id 與 project_id。真正承載記憶的是 project.memory(...)，它接受 group_id、agent_id、user_id、session_id 四個識別碼。這四個維度決定了「誰的記憶」以及「哪一段對話」，設計上等於把多租戶隔離直接寫進 API 簽名。
寫入用 memory.add()，回傳值在範例註解中顯示為 AddMemoryResult(uid='...')。查詢用 memory.search()，回傳結構相當深：results.content.episodic_memory.long_term_memory.episodes[0].content。從這條路徑可以看出，search 的結果按記憶類型分層，episodic 底下再分 long_term_memory，最後才是 episodes 陣列。
這裡有個容易被忽略的前提。README 在 Quick Start 開頭就標明：這段程式碼需要一個執行中的 MemMachine Server。也就是說 pip install memmachine-client 裝的是客戶端，不是完整系統。你可以自己架 server，也可以用官方託管服務。兩種路線的資料落地位置與維運責任完全不同。
除了 Python SDK，README 列出 RESTful API、TypeScript SDK 與 MCP server 三種介面。MCP 部分提供兩個指令：memmachine-mcp-stdio 給 Claude Desktop 這類 stdio 客戶端，memmachine-mcp-http 給網頁端。這意味著不想寫程式的人也能透過支援 MCP 的工具接上記憶層。
框架整合清單很長，但整合深度要自己驗
README 列出八個整合：LangChain、LangGraph、CrewAI、LlamaIndex、AWS Strands、n8n、Dify、FastGPT，各自對應 repo 中的一個目錄。涵蓋面從程式框架一路延伸到 n8n 這種無程式碼工作流工具，對照的是不同團隊的技術棧。
清單長不等於每個整合都同等成熟。README 只給了一行描述，例如 LangGraph 是「Stateful memory for LangGraph workflows」，沒有說明它接的是 checkpointer、store 還是自訂節點。這對採用決策有實質影響：如果整合是包成 LangGraph 的 store 介面，那你的 state 讀寫路徑就受該介面的語意限制；如果是自訂節點，控制權就大得多。
我的看法是，這份清單應該當成入口索引，而不是相容性保證。真正要驗的是你打算用的那一個目錄底下的程式碼，看它呼叫的是 memory.add 與 memory.search 這兩個基本操作，還是另外依賴了未公開的介面。八個整合同時維護也需要人力，版本落後是合理的預期。
什麼情況下它會變成錯的工具
第一個明確的限制是儲存前提。episodic memory 依賴圖資料庫，README 指名 Neo4j。如果你已經有一組 PostgreSQL 或 SQLite 在跑，導入 MemMachine 等於在既有資料層旁邊再加一個需要備份、需要監控、需要版本升級的圖資料庫。對小團隊來說，這個維運負擔可能超過記憶功能帶來的價值。
第二個限制是 server 依賴。client 單獨裝起來沒有任何作用，README 明講需要執行中的 server。這代表離線環境、單機 CLI 工具、或邊緣裝置上的代理，都不適合直接套用。你必須先解決 server 的部署問題，才輪到評估記憶品質。
第三個是 LLM 依賴的模糊地帶。README 說 MemMachine 是 LLM agnostic，支援 OpenAI、Anthropic、Bedrock、Ollama 等。但記憶的寫入與檢索通常需要模型參與，例如從對話中抽出事實、或對查詢做語意匹配。這些步驟在哪裡發生、用哪個 provider、是否會把使用者對話送到外部 API，README 沒有交代。對醫療或金融這類範例場景，這是必須先釐清的問題。
最後，這個專案在 2026 年 5 月到 9 月之間連續發布多個 0.3.x 版本，版號仍在 0 開頭。這不是品質判斷，而是提醒你 API 形狀可能還會變動，鎖定版本與閱讀對應版本的 release notes 是必要的。
替代路線：自己接向量庫，或直接用框架內建記憶
最直接的替代方案是自己拼：向量資料庫加一張使用者偏好表，在 agent 迴圈裡手動寫入與檢索。差別在檢索方式。向量庫做的是相似度近鄰搜尋，把對話當成可比較的文本片段；MemMachine 的 episodic memory 走圖，把對話之間的關聯當成可走訪的邊。前者擅長「找出語意相近的過去片段」，後者理論上更能處理「A 事件導致 B 事件，B 又跟 C 相關」這種多跳關係。代價是你得自己決定圖的節點與邊怎麼定義，而 MemMachine 把這層封裝起來了。
另一條路是用框架自帶的記憶機制，例如 LangGraph 的 checkpointer 或各框架的 conversation buffer。這些方案的優點是零額外部署，缺點是記憶通常綁在單一 session 或單一執行緒上，跨 session 的長期事實需要自己另外存。MemMachine 想補的正是這一段。
選擇的關鍵不是功能多寡，而是你的檢索需求是不是真的需要圖走訪。如果多數查詢只是「這個使用者說過什麼關於 X 的事」，向量檢索加 SQL 就夠了，多加一個 Neo4j 沒有對應回報。
授權、維護成本與升級前該確認的事
授權是 Apache-2.0，寬鬆授權，允許商用與修改，附帶專利授權條款。這裡只陳述授權類型，具體條款與你的使用情境是否相符，仍需自行確認或諮詢法務。
維護成本主要來自三個方向。一是 server 的部署與升級，client 與 server 版本需要對應，README 沒有提供相容性矩陣。二是圖資料庫的維運，Neo4j 的備份、索引調整與版本升級都是獨立的工作項。三是整合層，八個框架整合各自追蹤上游變動。
導入前我建議先確認三件事：memmachine-server 的部署文件是否涵蓋你打算用的環境；episodic memory 寫入時會呼叫哪個 LLM provider、資料是否離開你的網路；以及 search 回傳的結果排序依據是什麼，因為 results.content.episodic_memory.long_term_memory.episodes 這個結構只告訴你資料怎麼放，沒告訴你為什麼第一筆是它。
編輯結論
如果你的代理需要跨 session 記住使用者偏好與對話脈絡，而且團隊已經在跑 Neo4j，MemMachine 的三層記憶切分與 Python SDK 值得進評估清單；如果只是想在同一次對話內維持 context，或不想維運圖資料庫，這個專案的儲存前提會先把你擋在門外。動手前先確認兩件事：memmachine-server 的部署方式與版本對應關係，以及 episodic memory 寫入時實際會呼叫哪個 LLM provider，因為這兩項決定了你的成本結構與資料落地位置。
社群筆記