Bộ nhớ dài hạn cho AI Agent 2026: Mem0, Letta, Zep và kiến trúc Memory-Augmented LLM
Posted on: 5/16/2026 9:07:54 AM
Table of contents
- 1. Vì sao AI Agent cần "bộ nhớ" riêng?
- 2. Bốn loại bộ nhớ theo CoALA Framework
- 3. Kiến trúc tổng quan của một Memory Layer
- 4. Mem0 — Hybrid memory cho ứng dụng cá nhân hóa
- 5. Letta (MemGPT) — LLM như một hệ điều hành
- 6. Zep + Graphiti — Temporal Knowledge Graph
- 7. So sánh trực diện ba hệ
- 8. Mốc thời gian phát triển memory layer
- 9. Pattern thiết kế Memory cho production
- 10. Build vs Buy — Quyết định trong 5 câu hỏi
- 11. Tương lai gần: Memory + Skills + Procedural learning
- 12. Kết luận
- Tài liệu tham khảo
1. Vì sao AI Agent cần "bộ nhớ" riêng?
Một sự thật phũ phàng mà nhiều người mới làm việc với LLM bỏ qua: mô hình ngôn ngữ về bản chất là stateless. Mỗi lần bạn gọi chat.completions.create(), model nhận lại một mảng messages hoàn toàn mới và không có chút ký ức nào về cuộc trò chuyện trước. Toàn bộ "trí nhớ" của một chatbot ChatGPT-style hiện nay thực chất là... bạn (hoặc framework) nhét lại history vào prompt.
Cách làm "nhét history" này hoạt động tốt khi cuộc hội thoại ngắn, nhưng đụng phải 3 rào cản nghiêm trọng khi bạn xây AI Agent chạy dài hạn:
Memory layer chính là mảnh ghép biến một chatbot vô danh thành trợ lý biết bạn — biết bạn dị ứng tôm, biết dự án bạn đang làm dùng .NET 10, biết tuần trước bạn đã hỏi câu này rồi và câu trả lời nào hợp khẩu vị. Năm 2026, đây không còn là tính năng "nice to have" mà là cấu trúc bắt buộc của bất kỳ agent nào muốn vượt qua phase prototype.
2. Bốn loại bộ nhớ theo CoALA Framework
Trước khi đi vào framework cụ thể, cần thống nhất một bảng phân loại. CoALA (Cognitive Architectures for Language Agents) — paper từ Princeton/Google mở rộng và được cộng đồng đón nhận rộng — mượn ý từ khoa học nhận thức, chia memory của agent thành 4 loại tương ứng cách bộ não con người tổ chức ký ức:
graph TB
A[AI Agent] --> B[Working Memory
Context window hiện tại]
A --> C[Long-Term Memory]
C --> D[Episodic Memory
Sự kiện đã xảy ra
khi nào, ở đâu]
C --> E[Semantic Memory
Sự thật, định nghĩa,
kiến thức về thế giới]
C --> F[Procedural Memory
Kỹ năng, quy trình,
cách làm việc]
style A fill:#e94560,stroke:#fff,color:#fff
style B fill:#f8f9fa,stroke:#e94560,color:#2c3e50
style C fill:#16213e,stroke:#fff,color:#fff
style D fill:#f8f9fa,stroke:#e94560,color:#2c3e50
style E fill:#f8f9fa,stroke:#e94560,color:#2c3e50
style F fill:#f8f9fa,stroke:#e94560,color:#2c3e50
2.1. Working Memory (Bộ nhớ làm việc)
Chính là context window mà LLM đang xử lý ngay lúc này. Nhanh nhất, nhưng đắt nhất và nhỏ nhất. Ví với máy tính, đây là RAM — đóng app là mất sạch.
2.2. Episodic Memory (Bộ nhớ tự truyện)
Lưu lại các sự kiện cụ thể đã xảy ra, kèm bối cảnh thời gian. "User Anh Tú đã hỏi về Aspire vào 14/05/2026 và phản hồi rằng câu trả lời quá dài". Đây là loại memory cho phép agent học từ kinh nghiệm.
2.3. Semantic Memory (Bộ nhớ ngữ nghĩa)
Tri thức về thế giới — định nghĩa, sự thật, mối quan hệ. "Anh Tú là Software Architect", "anhtu.dev dùng SQL Server". Khác episodic ở chỗ nó không gắn với một sự kiện cụ thể, là kiến thức tổng quát đã trích xuất.
2.4. Procedural Memory (Bộ nhớ thủ tục)
Cách làm một việc — workflow, prompt patterns, skill đã được tinh chỉnh. Trong Letta đây là "memory blocks" có thể edit, trong Anthropic Skills đây là folder skills/ chứa SKILL.md. Loại memory này thường bị bỏ quên nhưng cực kỳ quan trọng để agent tự cải thiện theo thời gian.
3. Kiến trúc tổng quan của một Memory Layer
Bất kỳ hệ memory production nào cũng có 5 thành phần lõi sau, dù tên gọi mỗi vendor khác nhau:
sequenceDiagram
participant U as User
participant A as AI Agent
participant M as Memory Layer
participant V as Vector Store
participant G as Graph DB
participant L as LLM
U->>A: "Tôi vừa chuyển sang dùng Postgres"
A->>M: retrieve(user_id, query)
M->>V: semantic search
M->>G: graph traversal
V-->>M: top-k facts
G-->>M: related entities
M-->>A: relevant context
A->>L: prompt + context + new msg
L-->>A: response
A->>M: write(extract_facts(turn))
M->>L: extractor LLM
L-->>M: structured facts
M->>V: upsert embeddings
M->>G: update entities + edges
A-->>U: response
5 thành phần cần phân biệt rõ:
- Extractor — LLM hoặc heuristic trích xuất fact đáng nhớ từ hội thoại thô.
- Storage backend — vector DB (cho semantic), graph DB (cho quan hệ), KV (cho truy cập nhanh theo key).
- Retriever — chiến lược lấy memory: vector top-k, graph traversal, hybrid rerank.
- Updater — xử lý mâu thuẫn (user nói "tôi sống ở Hà Nội", tuần sau nói "tôi vừa chuyển vào Sài Gòn" — phải invalidate fact cũ).
- Consolidator — periodic summarization, dedup, garbage collection.
Cảnh báo thiết kế
Đừng nhầm memory layer với RAG. RAG lấy tri thức từ corpus công khai (docs, wiki, file PDF) và stateless theo user. Memory layer lưu cá nhân hóa theo user và thay đổi theo thời gian. Cùng dùng vector DB nhưng vòng đời và schema hoàn toàn khác.
4. Mem0 — Hybrid memory cho ứng dụng cá nhân hóa
Mem0 chọn cách tiếp cận "drop-in library": bạn có app đang dùng OpenAI/Anthropic SDK, thêm vài dòng để bao bọc, hệ thống tự lo trích xuất và lưu fact.
Mô hình ba tầng
Mem0 chia memory theo phạm vi truy cập:
- User-level — sự thật về một user, dùng được trên mọi session, mọi agent.
- Session-level — context trong một cuộc hội thoại cụ thể.
- Agent-level — "kiến thức nghề" mà agent học từ tất cả user (vd: agent CSKH nhận ra phàn nàn pattern X thường đi kèm bug Y).
Backend hybrid
Mem0 không bám một loại store: nó kết hợp vector (Qdrant/PGVector cho semantic search), graph (Neo4j cho quan hệ entity) và key-value (cho truy cập nhanh theo user_id). Tradeoff: dễ tích hợp, nhưng phải vận hành nhiều store.
Ví dụ tích hợp
from mem0 import Memory
from openai import OpenAI
mem = Memory() # tự cấu hình Qdrant + Neo4j local
client = OpenAI()
def chat(user_id: str, message: str) -> str:
# 1. Truy hồi memory liên quan
memories = mem.search(query=message, user_id=user_id, limit=5)
context = "\n".join([m["memory"] for m in memories["results"]])
# 2. Prompt + memory
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": f"Memory về user:\n{context}"},
{"role": "user", "content": message},
],
)
reply = response.choices[0].message.content
# 3. Ghi memory mới từ turn này
mem.add(messages=[
{"role": "user", "content": message},
{"role": "assistant", "content": reply},
], user_id=user_id)
return reply
# Lần 1
chat("anhtu", "Tôi dị ứng đậu phộng")
# Lần 2 (vài tuần sau)
chat("anhtu", "Gợi ý món tráng miệng cho tôi")
# -> agent biết tránh đậu phộng dù không được nhắc lại
5. Letta (MemGPT) — LLM như một hệ điều hành
Letta (tên mới của MemGPT) đẩy ý tưởng triệt để hơn: coi context window như RAM, và để chính LLM quản lý việc page in/page out giữa các tầng memory như một OS. Đây là cách tiếp cận "stateful agent runtime" — agent không chỉ dùng Letta cho memory, agent chạy bên trong Letta.
Mô hình ba tầng kiểu OS
graph LR
A[LLM Context Window
Core Memory] -->|page out| B[Recall Memory
Conversation history
tìm kiếm được]
B -->|archive| C[Archival Memory
Vector DB
kiến thức lâu dài]
C -->|tool call: archival_memory_search| A
B -->|tool call: conversation_search| A
style A fill:#e94560,stroke:#fff,color:#fff
style B fill:#16213e,stroke:#fff,color:#fff
style C fill:#2c3e50,stroke:#fff,color:#fff
- Core Memory — một block nhỏ luôn nằm trong context. Agent tự đọc, tự sửa block này qua tool call
core_memory_replace. Đây là nơi lưu "persona" và những fact tối quan trọng. - Recall Memory — lịch sử hội thoại đầy đủ, agent search bằng
conversation_search. - Archival Memory — vector store cho kiến thức lâu dài, agent ghi qua
archival_memory_insertvà đọc quaarchival_memory_search.
Điểm độc đáo 2026: Letta Code & Skill Library
Bản nâng cấp 2026 đưa Letta Code — agent code đứng #1 trên Terminal-Bench trong nhóm open-source model-agnostic — với "Skill Library" và "Context Repositories". Memory được commit, branch và rollback bằng Git, biến memory thành artifact có thể versioning. Đây là bước rất hợp với xu hướng memory-as-code.
Khi nào chọn Letta?
Khi agent cần chạy tự chủ trong nhiều ngày liền mà không có user can thiệp (autonomous research, monitoring, long-horizon planning). Mô hình "LLM tự quản memory" hợp với workload đó hơn là kiểu "framework tự nhồi context" của Mem0.
6. Zep + Graphiti — Temporal Knowledge Graph
Zep chọn con đường khác cả Mem0 lẫn Letta: thay vì lưu chunks text + embeddings, Zep dựng temporal knowledge graph qua engine Graphiti. Mọi fact đều có timestamp và quan hệ giữa các entity được mô hình hóa tường minh.
Vì sao temporal lại quan trọng?
Tình huống kinh điển: user nói "Tôi từng sống ở London, giờ chuyển sang Tokyo". Vector search ngây thơ sẽ trả cả hai fact, agent lúng túng không biết user đang ở đâu. Zep hiểu được state change vì mỗi edge có valid_from / invalid_at:
(User:anhtu) -[LIVED_IN {valid_from: 2020, invalid_at: 2025}]-> (City:London)
(User:anhtu) -[LIVED_IN {valid_from: 2025, invalid_at: null}]-> (City:Tokyo)
Khi agent hỏi "user đang sống ở đâu?", Zep chỉ trả về edge invalid_at IS NULL.
Benchmark LongMemEval
Đây là điểm Zep thắng đậm: trên LongMemEval với GPT-4o, Zep đạt 63.8% còn Mem0 dừng ở 49.0% — chênh 15 điểm trong tác vụ multi-hop, temporal reasoning. Latency giảm tới 90% so với cách nhồi full history. Trên DMR (Deep Memory Retrieval — benchmark gốc của MemGPT), Zep cũng vượt với 94.8% vs 93.4%.
7. So sánh trực diện ba hệ
| Tiêu chí | Mem0 | Letta (MemGPT) | Zep + Graphiti |
|---|---|---|---|
| Triết lý | Drop-in library | Agent runtime + virtual memory | Knowledge graph as a service |
| Backend chính | Hybrid: vector + graph + KV | Postgres + pgvector + recall log | Neo4j-style temporal graph |
| Memory types nổi bật | User / Session / Agent | Core / Recall / Archival | Entity / Edge / Episode |
| Xử lý mâu thuẫn theo thời gian | Override fact cũ | Agent tự edit block | Bi-temporal: valid_from / invalid_at |
| LongMemEval (GPT-4o) | 49.0% | ~52% (baseline MemGPT) | 63.8% |
| Use case tối ưu | Chatbot cá nhân hóa, app SaaS | Autonomous long-horizon agent | Enterprise CRM, multi-doc reasoning |
| Self-host | Có (Apache 2.0) | Có (Apache 2.0) | Có (Community Edition) |
| Đường cong học | Thấp — 5 dòng code | Trung bình — phải hiểu agent loop | Cao — phải design graph schema |
8. Mốc thời gian phát triển memory layer
9. Pattern thiết kế Memory cho production
9.1. Write-on-summarize, không phải write-every-turn
Ghi memory ngay sau mỗi turn rất tốn: bạn phải gọi LLM extractor mỗi lần. Pattern hiệu quả hơn là buffer N turn rồi mới summarize, hoặc detect "significant turn" (user share fact mới, agent đưa ra quyết định lớn) rồi mới ghi.
9.2. Phân tách Hot vs Cold memory
Không phải memory nào cũng cần load lên context mỗi turn. Hot tier (last 7 ngày) giữ inline, cold tier (older) chỉ load khi retriever ranking đủ cao. Giảm token cost mà không mất recall.
9.3. Conflict resolution rõ ràng
Khi user nói thông tin mới mâu thuẫn fact cũ — invalidate hay merge? Quy tắc đơn giản hữu hiệu: fact gần đây luôn thắng, nhưng giữ lại lịch sử cho audit. Zep làm sẵn, Mem0 phải tự code.
9.4. PII và quyền truy cập
Memory chứa thông tin cá nhân — phải có cơ chế forget(user_id, scope) để tuân thủ GDPR/CCPA. Không phải vendor nào cũng làm tốt việc xóa khỏi vector DB lẫn graph DB cùng lúc.
9.5. Đừng để agent self-poison
Nếu agent ghi nhớ chính output của mình như fact, sau vài turn nó sẽ tự khẳng định những điều bịa. Best practice: chỉ extract fact từ user message, agent output chỉ dùng cho recall (lịch sử hội thoại), không cho semantic.
Pitfall thường gặp
Đánh đồng "lưu được" với "nhớ tốt". Vector DB rất dễ lưu nhưng retrieve sai thì agent vẫn "quên". Luôn đo bằng dataset benchmark có ground truth (LongMemEval, DMR), không chỉ test cảm tính.
10. Build vs Buy — Quyết định trong 5 câu hỏi
| Câu hỏi | Trả lời "Có" → Buy (Mem0/Zep) | Trả lời "Có" → Build (custom) |
|---|---|---|
| Workload chính có phải chatbot/assistant? | ✓ | |
| Cần ship trong < 1 tháng? | ✓ | |
| Có yêu cầu compliance khắt khe (on-prem, data sovereignty)? | ✓ | |
| Cần custom retrieval logic rất riêng? | ✓ | |
| Team có ≥ 2 ML engineer dedicated? | ✓ |
Khuyến nghị thực dụng: luôn bắt đầu bằng Mem0 để có baseline trong vài ngày, rồi đo bằng LongMemEval style dataset của chính bạn. Chỉ migrate sang Zep/custom khi gap thực sự lớn và justify được công vận hành.
11. Tương lai gần: Memory + Skills + Procedural learning
Hai xu hướng sẽ định hình memory layer 12 tháng tới:
- Procedural memory trở thành first-class. Anthropic Skills, Letta Skill Library đều chỉ cùng hướng: skill (cách làm) phải versioned và share được giữa các agent. Memory không chỉ là "biết cái gì" mà còn là "biết làm thế nào".
- Cross-agent shared memory. Khi multi-agent system phổ biến (A2A protocol, ADK), nhu cầu agent A ghi memory để agent B đọc tăng vọt. Letta Conversations API và Zep "shared graph namespace" là bước đầu.
Memory layer 2026 đã đi qua giai đoạn "vector DB là đủ" — đó là chuyện 2023. Hệ thống đáng tin tức nay phải xử lý temporality, conflict, multi-modal extraction và procedural learning. Chọn đúng layer ngay từ đầu sẽ tiết kiệm bạn 6 tháng rewrite về sau.
12. Kết luận
Nếu phải tóm 1 câu: memory là cái mà LLM không có sẵn, và là cái phân biệt một demo đẹp với một sản phẩm thật. Ba lựa chọn dẫn đầu 2026 đại diện cho 3 triết lý khác nhau — Mem0 cho tốc độ tích hợp, Letta cho agent tự chủ dài hạn, Zep cho enterprise cần temporal reasoning. Không có lựa chọn "tốt nhất" — chỉ có lựa chọn phù hợp use case.
Lời khuyên thực dụng: đừng để đến khi đã có 10K user mới nghĩ tới memory. Thiết kế memory layer ngay từ ngày đầu, dù chỉ là wrapper đơn giản quanh Redis. Bạn sẽ cảm ơn chính mình 6 tháng sau khi user bắt đầu hỏi "sao bot không nhớ tôi?".
Tài liệu tham khảo
- Zep: A Temporal Knowledge Graph Architecture for Agent Memory (arXiv:2501.13956)
- MemGPT is now part of Letta — Letta blog
- Agent Memory: How to Build Agents that Learn and Remember — Letta
- State of AI Agent Memory 2026 — Mem0
- letta-ai/letta — GitHub repository
- Best AI Agent Memory Frameworks in 2026 — Atlan
- What Is AI Agent Memory? — IBM Think
- AI agent memory: types, architecture & implementation — Redis
Disclaimer: The opinions expressed in this blog are solely my own and do not reflect the views or opinions of my employer or any affiliated organizations. The content provided is for informational and educational purposes only and should not be taken as professional advice. While I strive to provide accurate and up-to-date information, I make no warranties or guarantees about the completeness, reliability, or accuracy of the content. Readers are encouraged to verify the information and seek independent advice as needed. I disclaim any liability for decisions or actions taken based on the content of this blog.