AI Agent的LLM記憶方案選哪個？
對GitHub上AI Agent記憶相關熱門專案的分析，包括mem0、MemPalace等，比較其架構、優缺點及衝突解決策略。
近日，一篇深入分析GitHub上AI Agent記憶專案的文章引起了廣泛關注。該文章指出，在GitHub上標記為“memory”的6187+個公共倉庫中，前十大專案有八個是AI Agent記憶專案，這一類別在兩年前幾乎不存在，如今卻主導了討論。
這些專案可以分為嵌入式/本地優先（如MemPalace、memvid、agentmemory）和客戶端-伺服器/雲端（如mem0、supermemory、OpenViking、hindsight）兩類。少數專案如supermemory和mem0則完全擁抱雲原生架構。
專案詳解：
- mem0 (⭐57.3k)：通用AI Agent記憶層，擁有多級記憶（使用者/會話/Agent）、圖記憶支援、多訊號檢索（語義、BM25、實體）以及與30多種向量儲存的整合。它是該領域資金最充足的專案，獲得Y Combinator支援並融資2400萬美元。其基準測試成績優異：LoCoMo 91.6、LongMemEval 94.8、BEAM 64.1。採用僅新增（ADD-only）演算法，避免原地更新的複雜性。但需要外部LLM（預設OpenAI），自託管設定複雜（需要Docker、PostgreSQL、Neo4j）。
- MemPalace (⭐53.2k)：本地優先的AI記憶系統，靈感來自古典記憶術——位置記憶法。它逐字儲存內容（從不總結或壓縮），透過語義搜尋檢索。內建知識圖譜（含時間有效性）、AAAK壓縮索引和29個工具的MCP伺服器。基準測試表現驚人：原始R@5 96.6%，混合檢索98.4%，結合LLM重排序超過99%。完全本地執行，無需API金鑰。但處於Beta階段，依賴ChromaDB可能存在穩定性問題。
- Understand-Anything (⭐47.8k)：AI編碼助手的外掛，將程式碼庫轉化為互動式知識圖譜。採用多Agent管道，結合Tree-sitter（確定性結構分析）和LLM語義增強。嚴格來說並非記憶系統，而是程式碼理解工具。需要Node.js 22+、pnpm 10+，語義層依賴LLM增加了延遲和成本。
- TiDB (⭐40.1k)：雲原生分散式SQL資料庫，相容MySQL，支援ACID事務、HTAP、基於HNSW的向量搜尋和資料庫分支，專為AI Agent設計。可統一服務於所有四層Agent記憶（短期、情景、程式、語義）。優勢在於MySQL相容性、橫向擴充套件、AI原生特性。但分散式系統複雜度高，向量搜尋仍處於Beta階段。
- OpenViking (⭐25k)：開源上下文資料庫，採用檔案系統正規化（viking:// URI）分層組織記憶、資源和技能。其層級上下文載入系統（L0/L1/L2）旨在提高token效率。可實現高達91%的token減少，精度提升3.39倍，檢索延遲低於0.2秒。但版本極早（v0.3.x），設定複雜，採用限制性AGPL-3.0許可。
跨專案分析顯示，衝突解決策略多樣：mem0採用僅新增+檢索時排名；MemPalace使用時間戳和餘弦相似度去重；TiDB依賴Raft共識和MVCC；Understand-Anything在確定層無衝突，語義層覆蓋舊結果。推薦選擇取決於具體需求：如需高效能基準和生態系統，選mem0；若重視隱私和本地控制，選MemPalace；若需結構化程式碼理解，選Understand-Anything；若需要統一資料庫解決方案，選TiDB。