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

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:

200Kcontext window tối đa của Claude/GPT-4 trước khi chất lượng tụt
$0.015chi phí mỗi 1K input token với model cao cấp — tăng tuyến tính theo history
73%tỉ lệ "lost in the middle" — thông tin nằm giữa context dài bị bỏ qua
độ dài hội thoại thực tế của một user gắn bó 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
Hình 1 — Bốn loại memory trong CoALA framework

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
Hình 2 — Sequence diagram của một memory layer điển hình

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
Hình 3 — Mô hình virtual memory của Letta/MemGPT
  • 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_insert và đọc qua archival_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%.

63.8%Zep — LongMemEval (GPT-4o)
49.0%Mem0 — LongMemEval (GPT-4o)
94.8%Zep — DMR benchmark
90%giảm latency so với full-history

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

10/2023
Paper MemGPT (Charles Packer et al., UC Berkeley) đặt nền móng cho "LLM as OS" — đề xuất hierarchical memory với function call.
06/2024
Princeton/Google publish CoALA framework — chuẩn hóa terminology cho memory của agent (working, episodic, semantic, procedural).
07/2024
Mem0 ra mắt v1 — hybrid store, tích hợp với mọi LLM SDK chính.
01/2025
Zep công bố paper Graphiti trên arXiv — temporal knowledge graph cho agent memory, đánh bại MemGPT trên DMR.
2025
MemGPT đổi tên thành Letta — chuyển từ "memory library" sang "agent platform" hoàn chỉnh.
Q1/2026
Letta Code phát hành — agent coding đứng #1 model-agnostic trên Terminal-Bench, đưa memory về dạng Git-versioned.
Q1/2026
LongMemEval benchmark trở thành chuẩn de-facto để so sánh memory layer. Zep chiếm ngôi đầu.

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