TROISINH
Làm quen AgentCác thành phần cốt lõi

Memory: Cách agent nhớ context qua conversations

Tại sao agent AI cần bộ nhớ? Giải thích kiến trúc memory 3 tầng (working, short-term, long-term), cách agent ghi nhớ người dùng và tự nâng cấp qua từng phiên...

Nếu bạn từng chat với ChatGPT và phải nhắc lại "như tôi vừa nói 3 tin nhắn trước", bạn đã thấy vấn đề của agent không có memory. Agent thực chiến không thể là "vàng mã" — chúng cần ghi nhớ bạn là ai, bạn thích gì, và các task đang dang dở từ hôm qua. Memory biến agent từ một hàm API stateless thành một "nhân viên số" có trí nhớ liên tục.

Vấn đề

LLM (Large Language Model) theo bản chất là stateless — mỗi lần bạn gọi API, nó như một người vừa thức dậy không nhớ gì về quá khứ. Bạn phải gửi lại toàn bộ lịch sử chat trong mỗi request để nó "nhớ", nhưng cách này nhanh chóng bất khả thi: context window (giới hạn đầu vào) của GPT-4 là 128K tokens, nhưng giá tiền tính theo token — gửi lại 50 trang lịch sử cho mỗi câu hỏi ngắn là đốt tiền vô nghĩa.

Hơn nữa, con người không nhớ theo cách "paste toàn bộ sách vào đầu". Chúng ta có working memory (nhớ số điện thoại vừa nghe để gọi lại), episodic memory (nhớ bữa trưa hôm qua ăn gì), và semantic memory (biết Paris là thủ đô Pháp). Agent cũng cần phân tầng như vậy. Nếu không, chúng sẽ mắc "bệnh vàng mã": lặp lại câu hỏi, không nhớ đã gửi file nào, và đề xuất giải pháp trùng lặp với tuần trước.

Ý tưởng cốt lõi

Kiến trúc memory cho agent có 3 tầng chính, ánh xạ trực tiếp đến cách bộ não người hoạt động:

Working Memory (Bộ nhớ làm việc)

Đây chính là context window — không gian token trực tiếp mà LLM "nhìn thấy" khi suy nghĩ. Giống như bạn chỉ giữ được 4-7 mẩu thông tin trong đầu cùng lúc (theo nghiên cứu tâm lý học), agent cũng chỉ xử lý được một khối context nhất định. Tầng này chứa:

  • Message history gần nhất (thường 4-10 turns)
  • System prompt (SOUL.md) — "bản chất" của agent
  • Tool schemas và ngữ cảnh task hiện tại

Sliding Window là kỹ thuật cơ bản: khi đầy, ta xóa tin nhắn cũ nhất (FIFO). Nhưng tin nhắn quan trọng có thể bị xóa nhầm, nên cần Summarization — nén 10 tin nhắn thành 1 đoạn tóm tắt ngắn gọn, giữ lại ý chính mà không tốn token.

Short-term Memory (Bộ nhớ ngắn hạn — Session Memory)

Khi agent tắt đi, context window mất sạch. Short-term memory là lớp persistence giữ lại trạng thái phiên làm việc giữa các lần "tỉnh dậy". Trong OpenClaw và Claude Code, đây là file MEMORY.md hoặc SQLite database:

  • Lịch sử hội thoại đã tóm tắt
  • Các file đang được chỉnh sửa
  • Biến và trạng thái tool call dở dang

Ví dụ thực tế: Bạn nhờ agent viết báo cáo, nó tìm được 5 nguồn tài liệu, nhưng chưa kịp tổng hợp thì bạn tắt máy. Short-term memory lưu lại "Đã tìm 5 sources: [links], đang ở bước outline introduction" — khi bạn mở lại, agent không phải tìm lại từ đầu.

Long-term Memory (Bộ nhớ dài hạn — Knowledge Base)

Đây là kho kiến thức bên ngoài context window mà agent có thể retrieve (tìm lại) khi cần. Thường dùng Vector Database — một thư viện thông minh lưu trữ "bản tóm tắt toán học" (embeddings) của tài liệu:

User hỏi: "Anh ấy thích màu gì?"
→ Agent không nhớ trong context window
→ Search vector DB với query "user preference color"
→ Retrieve: "User thích màu xanh dương — ghi chú từ 3 tháng trước"
→ Trả lời chính xác

Kiến trúc này gọi là RAG (Retrieval-Augmented Generation) — khi memory trong đầu không đủ, agent "tra cứu hồ sơ" giống như bác sĩ xem bệnh án cũ.

Sơ đồ luồng dữ liệu

User Input 

[Working Memory] ← Tải SOUL.md (identify) + Recent messages

Cần thông tin cũ? → Query [Vector DB] (Long-term)

LLM Reasoning → Output

Lưu vào [Short-term] (MEMORY.md) + Cập nhật [Vector DB] nếu có fact mới

Ví dụ cấu hình đơn giản trong OpenClaw:

<!-- SOUL.md - Luôn load vào working memory -->
Bạn là Assistant chuyên về data analysis. 
Style: Ngắn gọn, dùng tiếng Việt.
Memory: Kiểm tra MEMORY.md trước khi trả lởi.

<!-- MEMORY.md - Short-term persistence -->
## Session 2024-01-15
- User đang làm dự án: "Sales Dashboard Q1"
- Đã xử lý file: sales_data.csv (20k rows)
- Lỗi đang fix: Column 'revenue' có giá trị null ở row 1542

Tại sao nó hoạt động

Bản chất của Transformer là attention mechanism — mô hình chú ý vào tất cả token trong context window để dự đoán token tiếp theo. Nhưng attention là zero-sum: nếu nhồi nhét 10,000 dòng code vào context, model phải "chia sự chú ý" mỏng đi, dẫn đến lost in the middle — quên chi tiết ở giữa văn bản dài.

Memory architecture giải quyết bằng tách biệt thời gian và không gian:

  • Thời gian: Short-term memory dùng file/local DB để lưu trữ ngoài context, chỉ nạp khi cần.
  • Không gian: Vector DB tìm kiếm ngữ nghĩa (semantic search) thay vì keyword match, cho phép retrieve chính xác thông tin liên quan từ triệu documents mà chỉ tốn 500-1000 tokens trong context.

Trade-off chính là cost vs. coherence:

  • Không memory: Rẻ tiền mỗi turn (ít token) nhưng tốn tiền công người dùng phải nhắc lại.
  • Full context: Tốn kém (nhiều token) và chậm.
  • Hybrid memory (3 tầng): Tối ưu chi phí — chỉ nạp thông tin relevant vào working memory.

So sánh với kiến trúc không memory:

Đặc điểmStateless APIAgent có Memory
PersonalizationKhông cóNhớ tên, style, project history
Multi-session taskThất bạiTiếp tục từ chỗ dở
Token costTăng dần theo độ dài chatỔn định (chỉ tải summary + relevant)
LatencyTăng khi history dàiNhanh (context window gọn)

Ý nghĩa thực tế

Trải nghiệm người dùng (UX): Agent có memory trở thành "colleague" thay vì "calculator". Sau 3 tuần làm việc, nó biết bạn hay dùng pandas thay vì polars, biết project đang dùng Tailwind chứ không phải Bootstrap, và tự động đề xuất pattern bạn ưa thích mà không hỏi lại.

Hiệu quả tài chính: Trong production, việc dùng Vector DB (như Pinecone, Weaviate, hoặc Chroma local) giảm 60-80% token consumption cho long-horizon tasks. Thay vì gửi 50 trang tài liệu vào prompt, agent chỉ gửi 2-3 đoạn liên quan nhất.

Ai đang dùng:

  • Claude Code: Dùng CLAUDE.md (SOUL tương đương) và context files để nhớ project structure.
  • OpenClaw: MEMORY.md tự động cập nhật sau mỗi session, lưu trong ~/.config/openclaw/memory/.
  • Customer Support Agents: Nhớ lịch sử ticket của khách hàng để không yêu cầu "mời anh/chị mô tả lại vấn đề" lần thứ 5.

Hạn chế:

  • Context staleness: Nếu file MEMORY.md không tự cập nhật khi user đổi preference, agent sẽ áp dụng "bản chất cũ" cho vấn đề mới.
  • Retrieval noise: Vector DB đôi khi lấy nhầm thông tin liên quan nhưng không đúng context (ví dụ: lấy "tôi ghét màu xanh" từ năm 2020 trong khi user đã đổi ý năm 2024).
  • "Lost in the middle": Dù có RAG, nếu working memory quá dài (>20k tokens), model vẫn bỏ qua chi tiết quan trọng ở giữa prompt.

Đào sâu hơn

Tài liệu chính thức

  • Anthropic: Claude Code Documentation — "Context and Memory Management" — hướng dẫn cấu trúc CLAUDE.md và MEMORY.md để tối ưu context window.

Bài viết liên quan TroiSinh

Cùng cụm (Core Components):

LLM — Bộ não của Agent

Hiểu bản chất reasoning và decision-making — nơi memory được "sử dụng"

Tools & Actions

Cho agent "tay chân" để hành động — memory giúp chọn tool phù hợp qua thời gian

SOUL.md: Định nghĩa tính cách agent

Phần "identity" luôn resident trong working memory

Planning & Reasoning

Cách agent dùng memory để lên kế hoạch đa bước

Đọc tiếp (Level 1 — Phát triển Agent):

Thiết lập & Chạy agent đầu tiên

Hands-on: Cấu hình SQLite và Vector DB cho agent thực tế

Memory Architecture: Short-term, Working, Long-term

Deep dive vào neuroscience của AI memory và các kỹ thuật consolidation

Conversation History: Pruning và Summarization

Chiến thuật nén lịch sử hội thoại để không mất context quan trọng

Tài liệu mở rộng

  • Paper: "Recursively Summarizing Enables Long-Term Dialogue Memory in Large Language Models" (arXiv:2308.15022) — kỹ thuật summarization đệ quy.
  • Blog: Letta (previously MemGPT) — "RAG vs Agent Memory" — phân biệt rõ retrieval knowledge và episodic memory.
  • GitHub: OpenClaw repository — thư mục /docs/memory với ví dụ MEMORY.md cho các loại agent khác nhau (coding, research, creative).

On this page