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。