Awesome-Agent-Memory：LLM 記憶地圖

這份 GitHub 清單整理 LLM 和多模態 Agent 的記憶系統、基準測試與論文，幫開發者快速看懂 memory 生態。

說真的，這份清單很像地圖。它把一個很亂的領域，硬生生整理成可讀的結構。Awesome-Agent-Memory 目前有 500 顆 stars、54 個 forks。這不是小玩具。它把 long-term memory、retrieval、context retention 和 agent reasoning 放在同一張桌上。

你可能會想問，記憶這件事有多重要。講白了，LLM 沒有記憶，就很像每次開會都失憶。上下文窗再大，也不等於能長期記住使用者偏好、歷史任務和舊資料。這份 repo 的價值，就是把這些東西拆開來看。

這份清單到底給你什麼

它不是單一模型，也不是一個 SDK。它比較像一份選型索引。你可以從裡面看出，記憶系統到底要存什麼、什麼時候取回、怎麼壓縮、怎麼判斷有沒有幫上忙。這件事很實際，因為 agent 的 memory 可以是聊天摘要，也可以是 graph database，還可以是接在 coding assistant 後面的 retrieval pipeline。

這份 repo 把混亂切成幾塊。它分成 products、surveys、benchmarks、papers，再把研究方向拆成 nonparametric memory、text memory、graph memory、multimodal memory、parametric memory、agent evolution、continual learning、context engineering 和 memory security。對開發者來說，這種分類比一堆行銷詞有用多了。

更重要的是，它讓你知道自己卡在哪一層。你如果只是要讓 assistant 記住用戶設定，可能不需要 graph。你如果要做跨 session 的任務追蹤，就得看 retrieval 和 persistence。你如果碰到多模態資料，那又是另一套問題。

• 產品區：Claude-Mem、Mem0、Zep、Cognee
• 研究區：retrieval、graph memory、multimodal memory、parametric memory
• 評估區：plain-text benchmarks、multimodal benchmarks、dynamic simulation environments
• 維護訊號：開源資源會加粗，排序也更前面

產品區透露市場怎麼分裂

如果你只看產品區，就會發現這個市場沒有單一答案。Claude-Mem 偏向 session capture 和 compression，適合 coding agent。Mem0 主打通用 memory layer。Zep 走 real-time temporal knowledge graphs。Cognee 則是 graph 加 vector 的混合路線。

這種分裂很正常。因為 memory 不是一個功能，而是一組系統設計。有人要的是插件。有人要的是服務。有人要的是可追蹤的關係網。你如果做產品，先問「要記什麼」，再問「怎麼記」，通常比直接挑工具有效。

清單裡也收了 Letta，它以前叫 MemGPT。這個專案在 agent memory 圈子裡很有代表性，因為它把研究和產品化都碰了一點。老實說，這類專案比那些只有 demo 的東西更值得看。

“Memory is the next frontier for AI systems,” Sam Altman said in OpenAI’s June 2026 post announcing Dreaming.

這句話很直白。它對應到這份清單的核心態度。memory 不是附加功能。它正在變成 agent 的基礎層，像 retrieval infrastructure 一樣重要。

基準測試比 demo 更誠實

Agent memory 很容易在 demo 裡看起來很神。它可以記得你的名字、你的技術棧、你上次的任務。可是一到真實使用，問題就來了。它能不能在隔了幾天後找回正確資料。它會不會把舊訊息當新訊息。它會不會記錯人。

這也是為什麼 benchmark 很重要。這份 repo 收了 plain-text benchmarks、multimodal benchmarks 和 dynamic environments。這三類東西，剛好對應到文字記憶、跨模態對齊、以及環境變化下的穩定性。對工程師來說，這比看產品頁面有意義太多。

如果你要做選型，至少要看四件事。第一，retrieval 準不準。第二，stale memory 清不清得掉。第三，壓縮後會不會丟資訊。第四，記憶有沒有真的提升推理，而不是只是增加 token 消耗。

• Plain-text benchmarks：測長時間文字回憶
• Multimodal benchmarks：測圖像、影片、文字是否對齊
• Dynamic environments：測任務變動後還準不準
• Simulation environments：測靜態資料集看不到的失敗

這份清單也連到 OpenAI、Perplexity 和 Cloudflare 的內容。這代表 memory 已經不是研究室裡的邊角題，而是產品需求的一部分。問題只剩下，誰能證明自己真的有用。

開發者該怎麼比工具

如果你現在要做 agent，這份 repo 最實用的地方，是它讓比較變得有框架。你不必用「哪個最潮」來選。你可以直接看 memory model、storage style、和 workload。這樣比較接近工程現場，也比較不會被 demo 騙。

我會先看三個面向。第一，是否支援跨 session。第二，是否能處理結構化關係。第三，是否有清楚的 API 和文件。很多工具看起來都很像，實際上差在資料模型和 retrieval policy。這些差異，會直接影響維護成本。

你如果是做台灣常見的 SaaS、客服 bot、或 coding assistant，選擇就更現實了。小團隊通常不需要最複雜的 memory graph。你要的是穩定、可觀測、可回收。這比一次塞滿所有能力更重要。

• Claude-Mem：適合 coding workflow 的 session replay
• Mem0：偏通用 agent-memory layer
• Graphiti：temporal graph memory，適合關係型回憶
• Cognee：graph + vector 的混合索引

清單還提到 TeleMem，它主打成為 Mem0 的高效替代方案。這種對照很有價值，因為它不是只講概念，而是直接把實作丟出來比。工程師最需要的就是這種資訊。

這個領域現在卡在哪

記憶系統的核心問題，不是能不能存。是存了之後能不能用，而且不會亂用。LLM 的 context window 一直變大，但長期 agent 還是需要 memory policy。你總不能把所有歷史對話都塞進 prompt，那樣 token 成本會先爆掉。

這也是為什麼 retrieval、compression、graph、以及 memory security 會一起出現。它們不是互相取代，而是互相補洞。你要的是正確性、成本、延遲、隱私，四個一起看。只看其中一個，常常會踩雷。

我覺得這份清單的真正價值，在於它把「記憶」從抽象詞變成工程問題。你可以開始問更具體的問題。哪些資料該長期保存。哪些記憶該過期。哪些 context 應該壓縮。哪些應該直接刪掉。

接下來該怎麼用這份地圖

如果你正在做 agent 產品，我會建議先從這份 repo 挑一條路線。先選你要的 memory 類型，再看對應 benchmark，最後才決定要不要上 graph 或多模態。這樣比較不會一開始就把架構搞太重。

更直接一點說，先別急著追功能數量。先確認你的產品真的需要長期記憶。很多場景只要 session memory 就夠了。真正需要跨天、跨任務、跨媒體記憶的產品，其實沒那麼多。

如果你最近在評估 Awesome-Agent-Memory，我的建議很簡單：把它當成選型起點，不要當成答案。先看 benchmark，再看資料模型，最後看你能不能把 memory 的失誤成本控住。這才是做產品的人該碰的現實。