獨立的記憶 API，夾在應用與 LLM 之間
大型語言模型本身是無狀態的，每開一個對話它對你一無所知。多數人靠把整段歷史塞回 context 來假裝它有記憶,但這條路又慢又貴,而且 context 一爆就全忘。Mem0 把「記憶」抽成一層獨立服務:對話結束時,它從訊息裡萃取出值得長期保存的事實(偏好、決策、人名、專案脈絡),存進向量庫;下次對話開始,它依語意把最相關的幾條撈回來,只把這幾條注入 prompt。
Mem0 是一層 add / search / get_all 的記憶 API，夾在你的應用和 LLM 之間，不是 RAG 框架，也不是聊天機器人。官方定位：「Mem0(mem-zero)為 AI 助理與 Agent 補上一層智慧記憶，讓互動個人化。」它的記憶有層級:User、Session、Agent 三種範圍,讓「這個使用者長期偏好」「這場對話的脈絡」「這個 Agent 自己的經驗」彼此不互相污染。
2026 年 4 月那篇隨附論文(arXiv:2504.19413)講了它為什麼這樣做:在 LoCoMo 長對話基準上,記憶式回答的準確率從 71.4 拉到 91.6;LongMemEval 從 67.8 拉到 93.4;而且因為只撈幾條而非整段歷史,單次操作 token 用量壓在 6.7K–7.0K、p50 延遲 0.88–1.09 秒。換句話說,記憶層不只「記得更多」,還「算得更少」。
User 訊息
search
注入 context
LLM 回答
add
萃取事實
存入向量庫
Mem0 ("mem-zero") enhances AI assistants and agents with an intelligent memory layer, enabling personalized AI interactions.
兩行指令安裝，以 OpenAI 金鑰啟動記憶
Mem0 的「函式庫模式」沒有伺服器、沒有帳號:pip install mem0ai(或 Node 端 npm install mem0ai)就裝好了。預設它用 OpenAI 當 LLM 跟 embedding 模型,所以先 export OPENAI_API_KEY=...,接著 from mem0 import Memory; memory = Memory() 即可開工。需要實體抽取等進階 NLP,改裝 pip install mem0ai[nlp] 並下載 spaCy 模型。
# 基本安裝
pip install mem0ai
# 需要進階 NLP / 實體抽取時
pip install "mem0ai[nlp]"
python -m spacy download en_core_web_sm
# 給它一支金鑰(預設用 OpenAI 當 LLM + embedding)
export OPENAI_API_KEY=sk-...from mem0 import Memory
memory = Memory()
memory.add("我偏好深色主題,還有 vim 鍵位", user_id="alice")
results = memory.search(query="alice 喜歡什麼設定?", filters={"user_id": "alice"}, top_k=3)
for entry in results["results"]:
print(entry["memory"])CLI 與瀏覽器外掛：不寫 code 也能操作記憶
Node 端 npm install -g @mem0/cli 裝一支命令列工具,mem0 init 跑一次設定精靈,之後在終端機就能加記憶、查記憶。另外官方有一個瀏覽器外掛(README 列出 ChatGPT 等場景),把你在不同 AI 聊天工具裡累積的偏好同步成同一份記憶。
npm install -g @mem0/cli
mem0 init
mem0 add "Prefers dark mode and vim keybindings" --user-id alice
mem0 search "What does Alice prefer?" --user-id alice核心 API：add 寫入、search 撈回，其餘為管理介面
Mem0 的 API 面很小：add 把對話變成記憶、search 把記憶撈回來，其餘 get_all / update / delete 是管理用。複雜度在於它周邊的功能：記憶範圍(User / Session / Agent)、可換的 LLM 與向量庫、圖譜記憶、自架伺服器、託管平台、CLI、瀏覽器外掛、各家 Agent 框架整合。下面這張表把它能做的事拆成一格一格。
Core API · 01
memory.add()
寫進記憶
把訊息(可以是整段對話)丟進去,Mem0 自動萃取出值得長期保存的事實再存進向量庫。帶 user_id / agent_id / run_id 決定它屬於誰。
Core API · 02
memory.search()
撈回記憶
用一句 query 做語意檢索,filters 鎖範圍、top_k 控數量,回傳最相關的幾條。這幾條才是你要注入 prompt 的東西,不是整段歷史。
Core API · 03
memory.get_all()
列出全部
把某個 user / session 的全部記憶倒出來，用於稽核、除錯，或讓使用者自己查閱「AI 記得哪些事」。透明度直接內建。
Core API · 04
update · delete · reset
修改與遺忘
單筆更新、單筆刪除,也能整個 reset 清空。讓你的產品能誠實地實作「忘記我這件事」這個按鈕。
Scope · 05
user_id / run_id / agent_id
三層記憶
User 是跨對話的長期偏好，Session(run)是這一場對話的脈絡，Agent 是這個 Agent 自己累積的經驗。三種範圍彼此隔離，不互相污染。
Config · 06
Memory.from_config()
換掉預設模型
預設用 OpenAI 當 LLM 與 embedding，一份 config dict 即可改成其他供應商或本機模型，呼叫碼不變。
Config · 07
vector_store
換掉向量庫
Qdrant、Chroma、pgvector 等多種後端可選,從本機檔案到雲端託管都行。記憶要存哪由你決定,API 表面一致。
Graph · 08
graph memory
圖譜記憶
啟用後 Mem0 會把人、事、關係建成知識圖,跨記憶邊界做實體連結;撈回時不只比語意相似,還能順著關係走。
Hosted · 09
MemoryClient
託管平台
到 app.mem0.ai 拿 API Key,同一套 add / search,記憶存在 Mem0 雲端,附 Dashboard 與用量分析。零維運。
Self-Host · 10
docker compose up
自架伺服器
把記憶層跑在自己的基礎建設上,內建 Dashboard 與 API Key 管理。給在意資料落地、要自己掌控的團隊。
CLI · 11
@mem0/cli
命令列記憶
npm 全域裝一支工具，mem0 init / add / search 在終端機操作記憶，不需撰寫程式碼，方便接腳本或快速試驗。
Integrations · 12
LangGraph · CrewAI · Vercel AI SDK
接進你的 Agent
官方有 LangGraph、CrewAI、Vercel AI SDK、Claude Code、Cursor、Windsurf 等整合，另有用於 ChatGPT 等聊天工具的瀏覽器外掛，將記憶層掛接到現有 Agent 框架。
函式庫 / 自架 / 雲端:一張表決定
| 面向 | 函式庫 Library | 自架伺服器 Self-Hosted | 雲端平台 Cloud Platform |
|---|---|---|---|
| 最適合 | 測試、原型 | 想跑在自己基礎建設上的團隊 | 零維運的正式上線 |
| 怎麼開始 | pip install mem0ai | docker compose up | 到 app.mem0.ai 註冊 |
| Dashboard | — | 有 | 有 |
| 帳號與 API Key 管理 | — | 有 | 有 |
| 進階功能 | — | 部分 | 全部 |
記憶層的正確用法：範圍、數量與部署選擇
Mem0 的 API 很短，但用法差異大：記憶範圍沒分好、撈太多條、模型沒換，會抵消它原本省下的成本。下面這幾條全部從官方 README、文件與隨附論文整理。
先把記憶範圍分清楚
大多數人只傳 user_id 就上路。但「這一場對話的短期脈絡」應該用 run_id 隔開，「這個 Agent 自己的經驗」用 agent_id。三層混在一起，短期對話內容會污染長期偏好。
來源 · mem0 官方文件 · 記憶範圍
top_k 別調太大
quickstart 用的是 top_k=3，這是有意的設定。Mem0 的設計前提是只撈幾條最相關的記憶；撈 20 條塞進 prompt，等於回到塞整段歷史的做法，反而慢、貴、又把雜訊餵給模型。
來源 · README · quickstart + 基準方法
add 可以直接吞整段對話
不用自己切句子。把 [{"role":"user",...},{"role":"assistant",...}] 整個訊息陣列丟給 memory.add(),Mem0 會自己萃取出值得記的事實;你只負責決定它屬於哪個 user / session。
來源 · README · chat_with_memories
把 assistant 的回覆也存進去
官方範例特意先 messages.append 助理的回覆、再 add，因為 AI 給出的承諾（例如「好，我幫你改成深色主題」）也是應被記住的事實，不只使用者說的話才算數。
來源 · README · quickstart 程式碼
[nlp] extra 不是預設
基本的 pip install mem0ai 不含進階 NLP / 實體抽取相依。要用就裝 pip install "mem0ai[nlp]" 並下載 spaCy 模型(python -m spacy download en_core_web_sm),別等到 production 才發現缺。
來源 · README · 安裝說明
先用函式庫驗證,要規模再搬伺服器
三種部署的 API 幾乎相同：先 pip install 跑通邏輯，確認需要多人協作、Dashboard 或 API Key 管理後，再換成 docker compose up 自架或 app.mem0.ai 託管，呼叫碼不需重寫。
來源 · README · 部署比較表
換本機模型壓 token 帳單
預設每次 add / search 都會打 OpenAI(萃取事實 + 算 embedding)。研究或內部工具用 Memory.from_config() 把 LLM 與 embedder 指到本機模型,成本就和你自己的算力綁定。
來源 · mem0 官方文件 · 設定
要不要圖譜記憶?先讀那篇論文
arXiv:2504.19413 詳細說明「純向量」與「向量 + 圖譜」的取捨：圖譜在多實體、多跳關係的場景才划算。先看論文裡的數字，再決定要不要多接一個圖資料庫。
來源 · arXiv:2504.19413
從安裝到跨對話記憶驗證的完整範例
下面這段示範：第一次對話裡 Alice 告訴助理她的偏好；隔天用一支全新的、沒有任何 context 的程序再開一次，助理照樣記得「繁體中文、TypeScript、不要 emoji」。中間沒有手動塞歷史，全由 memory.add 與 memory.search 完成。指令依官方 README quickstart 寫成。
> pip install mem0ai
> export OPENAI_API_KEY=sk-...
> python
$ >>> from mem0 import Memory
$ >>> memory = Memory()
$ >>> messages = [
$ ... {"role":"user","content":"我是 Alice,前端工程師。回我訊息用繁體中文,程式碼用 TypeScript,不要 emoji。"},
$ ... {"role":"assistant","content":"好的 Alice,我記下了:繁體中文回覆、TypeScript、無 emoji。"}]
$ >>> memory.add(messages, user_id="alice")
$ >>> exit()
> python chat.py
$ You: 幫我寫一個 debounce 函式
claude: AI: 沒問題 Alice,這是 TypeScript 版的 debounce:
claude: export function debounce<T extends (...a: any[]) => void>(fn: T, ms: number) {
claude: let t: ReturnType<typeof setTimeout>;
claude: return (...a: Parameters<T>) => { clearTimeout(t); t = setTimeout(() => fn(...a), ms); };
claude: }
ok: [mem0] 沒有新事實要加(問題與既有偏好一致)· event = NONE
$ You: exit
claude: Goodbye!
「它記得 Alice 用 TypeScript」這件事，是 search 撈出來、再注入 prompt 的結果，不需要手動維護對話歷史。
這段為什麼值得拆解
關鍵在「隔天、全新程序」這一行。傳統做法要嘛把整段歷史存進資料庫每次撈出來塞 prompt（貴、慢、會爆），要嘛乾脆不記。**Mem0 的做法是把對話蒸餾成幾條事實存著，需要時只撈最相關的幾條。**因此 token 用量穩定、延遲可控，使用者體感是「這個 AI 認得我」。
另一個細節：範例特意把 assistant 的回覆也放進 messages 再 add。AI 給出的承諾也是記憶的一部分，這是「個人化助理」與「只查偏好的 chatbot」之間的實作分界。
記憶層的成本、限制與維運責任
從原型到生產部署的後續步驟
函式庫模式只是起點。Mem0 的每一層都可以替換：模型、向量庫、部署方式、整合框架。下一步通常不是學新 API，而是把它接到現有的系統上。
接下來可以做的五件事
**1. 換掉預設模型與向量庫。**用 Memory.from_config() 把 LLM、embedder 指到指定供應商或本機模型，把記憶存進 Qdrant、Chroma、pgvector，呼叫碼不需更動。
**2. 認真分記憶範圍。**把 user_id / run_id / agent_id 想成資料表的索引:長期偏好、單場對話脈絡、Agent 自身經驗各走各的,撈回來才乾淨。
**3. 評估要不要圖譜記憶。**多實體、多跳關係(誰屬於哪個團隊、哪個專案依賴哪個服務)的場景,開圖譜記憶讓檢索順著關係走;先用 arXiv:2504.19413 裡的數字判斷划不划算。
**4. 接進你的 Agent 框架。**LangGraph、CrewAI、Vercel AI SDK、Claude Code、Cursor、Windsurf 都有官方整合;要做瀏覽器端就掛官方的記憶外掛(README 列出 ChatGPT 等場景)。
**5. 決定部署形態。**原型用函式庫,團隊協作用自架伺服器(docker compose up,內建 Dashboard 與 API Key 管理),要零維運上線就上 app.mem0.ai 託管版。
最該讀的三份延伸閱讀
① docs.mem0.ai：完整的 API、設定、整合、自架與平台文件。 ② arXiv:2504.19413：隨附論文，記憶層方法、基準測試、純向量 vs 圖譜的取捨分析。 ③ github.com/mem0ai/mem0：原始碼、examples/ 範例、Node SDK 與 CLI。
Mem0 ("mem-zero") enhances AI assistants and agents with an intelligent memory layer, enabling personalized AI interactions.