每家 AI agent 供應商都在說「memory」，但在架構上它通常不是同一件事：在 stock LLM setup 裡，LLM 本身沒有真正的 memory，只有 context window；所謂 agent memory 的差別，其實在於「什麼被寫下來」以及「之後怎麼把它放回模型眼前」。Mem0、Zep、Letta 用同一個詞，分別解三種不同問題；映射錯了，你可能會為不需要的機制多付成本，或做出會在關鍵處默默忘記的產品。
先用一個很直覺、也很常見的場景開場：支援型 agent 在同一個 thread 裡第三次問客戶「你可以再描述一次帳單錯誤嗎？」但客戶其實已經講過兩次。這時候行銷頁面說「bot remembers every customer」，你也會立刻覺得怪——它不是真的記得，它多半只是把還塞得進 context window 的內容再讀一次，然後把那種「連續性」當成記憶。客戶感覺得出來，你也感覺得出來。
所以問題不是「要不要記憶」這麼抽象；問題是更硬的那句：對話一旦滾出 context window，什麼東西會被外部系統寫下來？又會以什麼形式、在什麼時機，被取回並放回 prompt？今天市面上叫「agent memory」的東西，基本都在回答這一題，只是回答法差很多。
先把「AI agent memory」拆成一個可對照的問題
在 LLM 這邊，真正穩固的底層事實是：LLM 沒有持久記憶，只有 context window；超出視窗的對話就消失，除非外部系統把它寫下來，之後再取回。也因此，任何 agent memory 的設計，都可以用同一組維度去看：寫下什麼、怎麼表示、怎麼取回、取回後怎麼影響生成。
寫下什麼（what gets written down）：是原始對話？還是抽取後的離散事實與偏好？還是「事件 + 時間」？
怎麼表示（representation）：vector、key-value storage、knowledge graph、temporal knowledge graph，或是像 OS 一樣的分層儲存（main context / recall storage / archival storage）。
怎麼取回（retrieval problem）：是找相似片段（常見會說找 k 個最相似 chunks，k 就是取回的數量）？還是能回答「什麼改變了、何時改變」？
適用情境與代價：你到底是在解「跨 session、跨天、跨關係」的持久性，還是只是在修補「同一段對話別讓人重複」？
講到這裡，很多人會忍不住想跳去問「那 RAG 呢？」——先按住。RAG（retrieval-augmented generation）很常被拿來跟 memory 混在一起，因為兩者都在「外部取回東西再塞回 prompt」。但它們要解的「遺忘」不一定相同。這點等一下會在選型那段一次收掉，免得來回重複。
Mem0：抽取離散事實/偏好，存起來再拉回來
Mem0 最接近多數人聽到「give my agent memory」時腦中想像的樣子：它會看著一段對話，抽取出離散的 facts 與 preferences（例如「user prefers dark mode」、「user's flight is on the 14th」），把這些東西存起來，讓你之後不必把整段 transcript 再餵回去也能把重點拉回來。
從公開資訊看，Mem0 是 open-source 專案，上面也有 hosted API；由 Taranjeet Singh 和 Deshraj Yadav 建立。它在 late 2025 拿到 $24 million（seed plus Series A），backers 包含 Basis Set Ventures、Peak XV、Y Combinator——這更像是一個訊號：這個「記憶層」類別已經不只是 side projects，有真正在燒的 venture money 進來了。
底層儲存的描述是 vector 加上 key-value storage；付費層在基礎之上再加一層 knowledge graph，讓事實之間的關係也能被追蹤，而不是只把每個 fact 當作孤立的條目。它的主打是「three lines of code」那種接法；而且老實說，對一大票 use cases 來說，這種「剛剛好」的機械量反而最對：customer support bot、會記得你飲食限制的 personal assistant、會記得你命名規範的 coding assistant——都在這個範圍內。
如果硬要用比喻，Mem0 比較像一個檔案櫃：它不打算把整本對話錄音帶都保存並重播，而是把你可能會再用到的「小條目」抽出來、貼標籤、放進抽屜。乾淨。也很實用。
Zep：用 Graphiti 做時間型知識圖譜，把「何時」放進事實本體
Zep 在架構上走得更深，也是在這裡，「這是不是只是 RAG 換名字」這個問題會變得最尖銳。Zep 的核心是 Graphiti：一個 temporal knowledge graph engine，時間（time）被當成每個 fact 的 first-class property，而不是事後才補上的 metadata。
差異可以用原文那個例子抓住：不是只有「user likes coffee」這種靜態句子，Graphiti 底下的圖可以表示「user liked coffee as of March，switched to tea in June」，並且能推理哪一個 fact 在「現在」才是成立的。這就不只是找相似段落而已；它想處理的是「狀態變了沒有、什麼時候變」這種問題。
Zep 也把記憶組織成 layered subgraphs：episodic（raw events）、semantic（extracted entities and relationships）、community（更高層的 summaries）。這其實是在宣告：它的 retrieval problem 不是「找 k 個最相似 chunks」那種單層相似度檢索，而是另一種更結構化的取回與推理。這就是原文所說的那條「誠實的界線」：retrieval-augmented generation 主要是找相關文本；temporal graph 能回答「what changed, and when」。
但有一個很現實、也很需要在選型前就知道的 caveat：Zep 的 self-hostable Community Edition 已經 discontinued。也就是說，「我先自架試試看」這條路在 Zep 產品層面已經不在了。你現在比較像是兩個 real choices：要嘛用 Zep Cloud，它是 credit-consumption model；要嘛往下用 open-source 的 Graphiti library 自己搭配 graph database 去跑——這會給你圖引擎本體，但不會自動包含 Zep 那個打包好的 retrieval layer。
講到 credit-consumption model，有些團隊會立刻皺眉。正常。因為這會把成本跟使用量綁得很緊，尤其在你還沒確定「時間推理」到底是不是必要的時候。但反過來說，如果你真的需要回答「目前哪個偏好才算數」或「改變發生在何時」，那種只靠相似度找文本的方式就會一直卡住——你會一直補規則、一直補 prompt，然後越補越像在打補丁。很煩。
Letta：從 MemGPT 來的「換頁」模型，把 context window 當成 RAM 管
Letta 是三者裡最 odd one out 的那個，而且它也最乾淨地符合「not just RAG」這句話。它的起點是 MemGPT：UC Berkeley 在 2023 的研究論文，由 Charles Packer、Sarah Wooders 和合作者提出。核心想法很 OS-flavored：把 LLM 的 context window 類比成 operating system 的 physical RAM。
OS 的直覺你很熟：RAM 不可能無限大，所以系統會 pages data in and out，在 RAM 和 disk 之間換頁，讓程式有「我好像有很多記憶體」的錯覺。MemGPT 把這個概念搬到 LLM 上：有一小塊永遠在 prompt 裡的 main context，外面再接 recall storage（過去對話）與 archival storage（長期知識）；並且讓模型自己透過 function calls 決定要把哪些資訊載入或卸載，維持那種「有限 context 但像有更大空間」的運作方式。
它在 late 2024 改名成 Letta，部分原因就是為了清掉「MemGPT」這個詞被同時拿來指論文、codebase、以及一整類 chatbot 的混亂。Letta 今天的形態是 open-source 的 agent framework，加上一個 hosted 的 Letta Cloud；其中一個更有辨識度的點是 Agent Development Environment：它讓 agent 的 memory blocks 與 context window 變得透明、而且可被開發者直接編輯，而不是全部藏在 vector store 後面。
如果要把比喻落回機制：Mem0 是「抽取條目、放抽屜」；Zep/Graphiti 是「關係地圖加上時間軸」；Letta 比較像「memory manager」——它在管的不是某一種資料結構本身，而是「在有限 context window 下，哪些東西要進 prompt、哪些先放外面」這種調度問題。很像 OS，但對象從程式變成 chat model。
RAG、context window、memory layer：別把三種需求混成一鍋
如果你的 agent 工作是針對靜態文件集回答問題——例如 policy manual、codebase、product catalog——那就是 retrieval-augmented generation（RAG），full stop。這時候再加一層「記憶」通常是在解你沒有的問題：你真正要的是把相關文件片段取回來，不是把使用者偏好或歷史狀態跨 session 保存。
另一種常見誤會是：你以為你要 memory，但其實你只是不想讓使用者在同一段對話裡重複。這種「同一個 sitting 內的連續性」很多時候用更大的 context window 可能就是整個解法——不需要抽取、不需要 knowledge graph、更不需要 paging logic。
memory layers 會「賺回成本」的情境，通常是那種資訊必須活過對話本身：跨 session、跨天、跨一段跟使用者的關係，而且你的 agent 需要「越用越懂你」，而不是每次從零開始。這裡才是你該認真挑 Mem0、Zep、Letta 這類東西的地方。
突然想到一個很現場的感覺：很多產品 demo 做得很順，是因為 demo 沒有跨天、沒有跨 session、也沒有真正的「變更」。一旦你遇到「March 喜歡咖啡、June 換茶」這種狀態漂移，或是你需要精準地記住「14th 的航班」這種離散事實，或者你要在長對話裡不斷換頁維持重點，才會知道自己到底缺哪一塊。就，會露餡。
如何把三者放回同一張地圖：你在修哪一種「遺忘」？
Mem0、Zep、Letta 都在賣 agent memory，但它們分別對應三種不同的遺忘修補方式：Mem0 偏向「抽取並保存離散事實/偏好以便之後取回」，Zep 偏向「用 Graphiti 的時間型知識圖譜處理事實隨時間變化」，Letta 偏向「用 MemGPT 的換頁概念在有限 context window 下做記憶管理」。選擇取決於你要修正的是哪一種遺忘，而不是哪一個名字聽起來更像『有記憶』。
你要的是「偏好與小事別忘」：像「user prefers dark mode」這種離散條目，Mem0 的路線就很貼近直覺；你要的是把重點寫下來、需要時拉回來，而不是保存整段。
你要的是「狀態會變，還要問得出何時變」：Zep/Graphiti 的 temporal knowledge graph 才在解這題。它不是單純找相似文本，而是能表達 March 與 June 的差異，並推理「現在」哪個才算數。
你要的是「對話很長，context window 不夠，但又要維持重點」：Letta 的 OS 換頁類比最接近你在做的事：main context / recall storage / archival storage，加上 function calls 讓模型決定要 pages data in and out。
同樣一句「我們需要 memory」，落到不同產品上其實是完全不同的工程。這也是一開始那個警告的技術版：映射錯了，你要嘛買了太重的機器，結果只是想要更大的 context window；要嘛以為 RAG 就夠了，結果真正需要跨 session 保存的偏好一直丟，丟到使用者生氣。
產品與元件的邊界：Zep、Zep Cloud、Graphiti library，別混淆
Zep 這條線特別容易混在一起，所以乾脆單獨說清楚：Graphiti 是 temporal knowledge graph engine；Zep 是圍繞 Graphiti 打包出來的產品化層；而 Zep Cloud 是目前你在 Zep 產品面可用的選項之一，採 credit-consumption model。
如果你不想用雲端、或你需要更可控的自建，你可以「往下」用 open-source 的 Graphiti library，自己接 graph database 跑起來。這會讓你拿到圖引擎，但你也要接受：你拿到的是元件，不是整套 Zep 的 packaged retrieval layer。少了那層，你要自己補齊很多工程細節。這不是好或壞，只是邊界要先認清。
還有一個事實層面的提醒：Zep 的 self-hostable Community Edition 已 discontinued。這會直接影響你原本如果想走「先用 CE 試水溫」的路徑——現在不行了，至少就原文描述是這樣。
最後的警語：這個類別比看起來更年輕，而且變動很快
Mem0、Zep、Letta 都不是「不成熟」的代名詞，但這整個 agent memory 類別確實 younger than it looks。它在 moving fast enough 的狀態：你今天讀到的架構細節，可能 within the year 就會 shift；自架選項可能出現，也可能消失；定價模型也還在被公開地摸索中。
所以結論其實不華麗：你不一定需要任何一個。你可能只要 RAG；你可能只要更大的 context window；你也可能真的需要一個 memory layer，讓資訊跨 session、跨天持久存在。真正該先回答的是：你要修正的「遺忘」是哪一種。依現有資訊看，這個問題短期內不會消失。
