2026 Agent Memory 開源項目推薦

先看結論：如果你要輕量、通用、容易接入的長期記憶層，先評估 Mem0；如果你的重點是狀態化 Agent 執行環境，優先看 Letta；需要時間關係圖與事件演化，可評估 Zep／Graphiti；若你在意圖式上下文、推理、決策溯源與治理，則應把 Semantica 放在前排。這不是單純的排名，而是先定義 Agent 要記住什麼，再選正確抽象層。

這篇文章適合準備為聊天 Agent 或任務 Agent 加入長期記憶的開發者，也適合需要自託管、資料控制與權限隔離的企業團隊。如果你正在比較圖記憶與 Agent 執行時，下面的指標會比 GitHub Star 數更能幫你作出可落地的選擇。

更新提醒：本文最後更新於 2026 年 8 月 14 日，資料核實自四個專案的官方 GitHub 倉庫、部署文件與架構說明；若專案調整授權、開源邊界、維護狀態或主版本，應重新驗證本文結論。

先把「記住什麼」拆成五種資料

很多 Agent Memory 對比文章一開始就比較向量資料庫、API 或延遲，但如果你連記憶內容都沒有定義，任何排名都可能失真。你至少要把需求拆成以下五類：

• 使用者偏好：例如語氣、格式、工作習慣、常用工具與長期設定。
• 任務狀態：例如目前處理到哪一步、已完成哪些工具呼叫、下一個待辦是什麼。
• 事件時間線：例如某項決定何時成立、何時失效，以及前後狀態如何變化。
• 知識關係：例如人物、產品、文件、客戶與事件之間的關聯。
• 決策來源：例如 Agent 為什麼選擇某個方案、引用了哪份資料、誰批准了結果。

這五類資料不應由同一種儲存抽象強行承擔。向量記憶擅長語意相似度，不代表它天然理解時間和因果；狀態化 Agent 擅長維持工作上下文，也不等於它是一套企業知識圖譜；圖式系統能表達關係與來源，但部署和資料建模成本通常更高。

再按抽象層理解四個項目

Mem0：通用記憶層的優先候選

Mem0 將自己定位為 AI Agent 的通用記憶層，主要使用「寫入記憶、依條件搜尋、再把相關內容交給 Agent」的整合方式。官方倉庫同時列出 Library、自託管伺服器與 Cloud Platform 三種使用形態；自託管路徑採用 Docker Compose，並且自託管伺服器預設啟用驗證。(github.com)

這使 Mem0 適合以下情境：

• 你要先解決使用者偏好與跨對話記憶。
• 你不想立即改造現有 Agent 執行框架。
• 你需要在本地控制記憶服務、模型與儲存依賴。
• 你願意自行處理認證、備份、監控與刪除政策。

但你要留意，開源記憶層不等於所有託管平台功能都能在本地完整重現。官方文件將自託管伺服器與 Cloud Platform 分開描述，因此評估時應逐項確認儀表板、權限、進階抽取、遷移工具及支援方式，而不是只看「是否 Apache-2.0」。

Letta：把記憶放進 Agent 執行時

Letta 的方向不是單獨提供一個記憶 API，而是建構可持續運作、可學習和可修改自身記憶的狀態化 Agent 平台。官方倉庫明確標示 Letta 曾用名 MemGPT，並指出目前主力開發已轉移至新的 Agent 與 App Server 路線。(github.com)

如果你的 Agent 需要保存工作狀態、人格設定、工具使用脈絡，以及跨工作階段持續執行，Letta 的抽象層會比單純向量記憶更自然。官方 Docker 文件也說明，本地部署時需要自行配置模型與嵌入模型，資料可透過掛載目錄持久化，並可啟用伺服器密碼保護。(docs.letta.com)

它的代價是架構耦合較深。你不是只加入一個 memory.search() 函式，而是要理解 Agent 狀態、記憶區塊、工具、伺服器與模型提供者之間的邊界。若你只需要在現有 LangChain、LlamaIndex 或自建流程中補一層偏好記憶，Letta 可能會超出需求。

Zep 與 Graphiti：時間關係圖要分開看

Zep 現行官方倉庫將自身定位為端到端的 context engineering platform，重點是把聊天紀錄、業務資料與事件整理成關係感知的上下文；其說明也提到以 Graphiti 建立時間知識圖，並根據事實的有效與失效時間組裝 Agent 上下文。(github.com)

但你不能把 Zep 和 Graphiti 當成同一個開源產品。Zep 是產品平台與託管服務方向，Graphiti 是可獨立使用的開源時間知識圖框架。Zep 的舊 Community Edition 已被標示為不再支援，相關程式碼移到 legacy 目錄；因此「Zep 是否完整支援本地部署」必須改問「你要部署的是 Graphiti 元件，還是 Zep 的完整產品能力」。(github.com)

Graphiti 適合保存會變動的事實，例如客戶職位、專案狀態、設備配置或事件關係。官方倉庫列出 Neo4j、FalkorDB、Neptune 等資料庫驅動，也提供遙測停用設定；自託管時，你需要把圖資料庫、模型呼叫、索引、備份和安全更新一起納入維運範圍。(github.com)

Semantica：面向上下文、推理與治理

Semantica 的抽象層更接近 Graph-Native Infrastructure，而非一般「把對話轉成向量」的記憶套件。官方架構說明包括 Context Graph、決策紀錄、因果推理、衝突偵測、W3C PROV-O 溯源、SHACL／OWL 治理，以及 RDF 與標籤屬性圖儲存。(github.com)

這種路線適合需要回答「Agent 為什麼作出這個決策」的系統，例如金融審核、企業知識管理、合規工作流或多 Agent 共用知識層。它也能與既有 LLM、向量儲存和 Agent 框架並存，而不是要求你全面替換現有技術棧。

相對地，Semantica 的導入前置工作較多。官方生產部署建議使用 Docker 或 Kubernetes，並配置持久化圖儲存與向量儲存；這代表你必須先設計本體、實體、事件、來源與權限模型，不能只把它當成一個即插即用的聊天記憶 API。

接著檢查寫入、更新與遺忘能力

生產環境最容易被忽略的不是「能不能搜到」，而是「搜到的內容是否仍然正確」。你至少要測以下四種操作：

1. 記憶抽取：Agent 是否只保存可重用的事實，而不是把整段對話無差別寫入。
2. 衝突處理：使用者由「住在台北」改成「已搬到高雄」時，舊資訊是覆蓋、並存，還是標示失效時間。
3. 時間變化：任務狀態是否能從進行中變成完成，並保留變更原因。
4. 刪除與遺忘：使用者要求刪除資料後，主記憶、向量索引、快取、備份與日誌是否都能按政策處理。

Mem0 適合先做通用記憶抽取與檢索基線；Zep／Graphiti 更適合時間性和關係性資料；Letta 把記憶更新放進 Agent 狀態管理；Semantica 則更強調衝突、來源、決策和治理。這些不是同一個維度，因此不宜用單一分數強行排序。

再核對自託管與資料控制邊界

你可以用以下方式快速判斷本地部署是否真的可行：

• Mem0：官方提供 Library 與 Self-Hosted Server，伺服器可透過 Docker Compose 啟動；你仍需自行配置模型、儲存、認證、備份與監控。
• Letta：官方提供 Docker 執行方式，資料可掛載到本地目錄，並可用自託管 App Server；但嵌入模型與模型提供者設定不能省略。
• Graphiti：開源圖框架可獨立部署，但會引入圖資料庫與圖檢索維運責任；這不代表 Zep Cloud 的全部平台功能都會出現在本地。
• Semantica：官方倉庫列出多種 RDF、標籤屬性圖和向量儲存後端，彈性較高，但也意味著部署拓撲與權限設計較複雜。

如果企業要求完全離線，還要另外確認模型和嵌入服務是否能在內網運作。某個記憶專案標示「可本地部署」，只代表記憶服務本身能在本地啟動，不代表整條資料鏈沒有外部 API、遙測、模型或託管控制面板依賴。

用治理指標檢查多 Agent 場景

多 Agent 系統不能只共用一個記憶集合。你需要先回答：

• 哪些記憶可由所有 Agent 讀取？
• 哪些資料只屬於單一使用者、專案或租戶？
• 一個 Agent 寫入的結論，另一個 Agent 是否能看見來源？
• 發生錯誤記憶時，誰可以更正、撤銷或追蹤變更？
• 你能否匯出審計紀錄，而不是只看到最後一次搜尋結果？

Letta 更適合以 Agent 狀態和工作記憶為中心的應用；Zep／Graphiti 適合關係、事件與時間變化；Semantica 在決策紀錄、來源、規則和衝突管理方面更符合高治理要求；Mem0 則適合先建立通用記憶層，再由你的應用程式補上租戶隔離、審計和權限中介。

FAQ：把長尾選型問題放回實際部署

Semantica 和 Mem0 哪個更適合自託管？

如果你要的是可快速接入的通用記憶層，Mem0 的自託管伺服器與容器化啟動路徑較直接；如果你需要決策紀錄、因果關係、來源追蹤、衝突偵測與本體治理，Semantica 更貼近企業級圖式上下文。不過兩者的資料庫、模型與維運責任不同，應以實際部署文件逐項核對。

Zep 與 Letta 的 Agent Memory 有什麼區別？

Zep 的核心方向是把對話、事件與業務資料整理成具時間性的關係上下文，適合做跨事件檢索；Letta 則更接近完整的狀態化 Agent 執行環境，記憶會和 Agent 的工作狀態、工具與持續運作流程結合。Zep 不等於 Graphiti，前者是產品平台，後者是其開源圖元件。

AI Agent 長期記憶應該選向量還是知識圖譜？

偏好、簡短事實與相似語意檢索通常可先用向量記憶；如果問題涉及人物、事件、時間變化、因果鏈或來源證明，知識圖譜更合適。實務上不必二選一，先把向量檢索作為基線，再以圖關係補足時間、實體與決策溯源。

哪些 Agent Memory 項目支援本地部署？

Mem0 官方提供自託管伺服器路徑；Letta 官方文件提供以 Docker 執行 App Server 的方式；Semantica 的開源倉庫則列出本地圖儲存與向量儲存選項。Zep 的現行方向需要特別區分，Zep Cloud 是託管產品，開源的 Graphiti 是可獨立部署的圖框架，不能把兩者功能直接合併計算。

生產環境如何評估 Agent 記憶效果？

不要只測試搜尋是否返回結果。你應準備含偏好、狀態變更、矛盾事實、刪除要求與來源追蹤的固定資料集，分別測試召回正確性、過期記憶處理、衝突處理、刪除後殘留、權限隔離與故障恢復，最後才比較延遲與維運成本。

最後用同一套資料集做公平驗收

建議你不要直接把真實使用者資料導入四個候選項目，而是先建立一份可重播的測試集，至少包含：

• 使用者偏好：同一偏好重複表達、改寫與撤回。
• 任務狀態：待辦、進行中、完成、失敗和重新開啟。
• 時間事件：同一人物或專案在不同日期出現不同狀態。
• 矛盾內容：新舊資訊同時存在，要求系統解釋目前採用哪一個。
• 來源要求：要求 Agent 說明結論來自哪段對話、文件或事件。
• 刪除要求：刪除某一使用者或租戶後，檢查搜尋、快取和匯出結果。

驗收時，至少記錄「是否找回正確記憶」、「是否誤用過期資料」、「是否能處理衝突」、「是否保留來源」、「是否完成權限隔離」五類結果。延遲和成本可以在第二階段比較，但不能拿沒有統一條件的宣傳數字直接下結論。

你也可以參考 Agent Memory 部署與環境準備方向，把模型、圖資料庫、向量儲存、備份和測試腳本固定在同一份部署文件中。若團隊需要短期建立隔離的測試環境，則應先確認 Mac 雲端租用方案 是否符合你的模型、容器與連線需求。

四類團隊的選擇結論

• 原型團隊：首選 Mem0，備選 Letta。前者較適合快速加入跨對話記憶，後者適合你已經確定要以狀態化 Agent 為核心。
• 狀態化 Agent 團隊：首選 Letta，備選 Mem0。若 Agent 需要長時間執行、保留工作狀態與工具脈絡，應優先測試 Letta 的執行時整合。
• 知識圖譜項目：首選 Graphiti／Zep 路線，備選 Semantica。前者偏時間關係上下文，後者偏圖式上下文與治理。
• 高治理要求項目：首選 Semantica，備選 Graphiti 加上自建審計層。若決策來源、衝突處理與政策驗證是硬性要求，不應只依靠向量相似度。

無論你最後選哪兩個候選方案，都建議先進行雙軌測試：同一份資料集、同一組查詢、同一套刪除和權限案例，連續觀察記憶品質，再決定是否遷移生產資料。這比根據 Star 數、單次展示或沒有公開條件的速度數字作決定可靠得多。

如果你目前用的是自建向量資料庫或臨時雲端環境，常見缺點是模型依賴分散、部署狀態難以重現、資料權限邊界不清，以及測試環境和正式環境不一致。對需要反覆安裝、切換模型與執行驗收腳本的團隊來說，臨時租用 Mac 環境通常比長期維護一台閒置工作站更容易快速建立隔離測試；你可以先查看 ZavCloud 的 Mac 開發環境說明，再按照實際工作負載判斷是否值得租用。