Series 3 - Bài 1: Bốn loại Memory của AI Agent

Khi nói về "memory" của AI Agent, hầu hết người dùng nghĩ đến conversation history — những gì đã nói trong session hiện tại. Đây chỉ là một trong bốn loại memory hoàn toàn khác nhau về cơ chế, persistence, và use case.

Hiểu taxonomy này quyết định bạn thiết kế agent có thể nhớ đúng thứ đúng lúc, hay agent liên tục mất context quan trọng.

Taxonomy 2×2

                  Scope
              In-Context    External
           ┌─────────────┬─────────────┐
 Short     │  Working    │  Episodic   │
 term      │  Memory     │  Store      │
           ├─────────────┼─────────────┤
 Long      │  System     │  Semantic   │
 term      │  Prompt     │  Store      │
           └─────────────┴─────────────┘

Hai trục:

• Scope: In-context (nằm trong context window) vs External (nằm ngoài, cần retrieval)
• Duration: Short-term (session-scoped) vs Long-term (persist qua sessions)

Loại 1: Working Memory (In-Context, Short-term)

Working memory là messages[] array — toàn bộ conversation history trong session hiện tại.

Working Memory structure:

[
  { role: "user",      content: "Refactor processLoan" },
  { role: "assistant", content: [tool_use: read_file] },
  { role: "user",      content: [tool_result: file content] },
  { role: "assistant", content: "I see the issue..." },
  { role: "user",      content: "Also fix the tests" },
  // ...tiếp tục grow
]

Đặc điểm:

• Luôn available, không cần retrieval
• Giới hạn bởi context window
• Mất khi session kết thúc
• Đắt nhất về token cost

Best for: Conversation flow trong một task, tool results, intermediate reasoning steps.

Anti-pattern: Dùng working memory để lưu mọi thứ. Sau 20 turns, context window bắt đầu đầy và phải trim.

Loại 2: System Prompt (In-Context, Long-term)

System prompt là long-term memory được inject vào đầu mỗi session. Nó persist không phải vì được lưu trong conversation — mà vì developer hardcode nó.

System Prompt as Long-term Memory:

  Injected một lần, tồn tại suốt session:

  "You are working on MSB banking system.
   The codebase uses Spring Boot + Oracle.
   Core entities: LoanApplication, CreditLimit.
   Never modify T24 integration files directly.
   Always run tests before reporting completion."

  → Agent "nhớ" ngữ cảnh này suốt session
  → Không tốn token trong conversation history
  → Nhưng không thể update trong runtime

Đặc điểm:

• Luôn available, kích hoạt ngay từ đầu
• Static — không thể thay đổi trong session
• Token cost trả một lần, amortized qua nhiều turns
• Phải viết và maintain thủ công

Best for: Project conventions, agent behavior rules, domain knowledge cố định.

Anti-pattern: Đưa dynamic information (file contents, API results) vào system prompt. Nó sẽ stale.

Loại 3: Episodic Store (External, Short-term)

Episodic store lưu lịch sử các sessions — những gì agent đã làm trước đây trong project.

Episodic Store structure:

Session 2025-05-20:
  Task: "Refactor payment service"
  Files modified: [payment.service.ts, payment.spec.ts]
  Outcome: success
  Key decisions: "Dùng Strategy pattern thay if/else chain"

Session 2025-05-22:
  Task: "Add loan validation"
  Files modified: [loan.service.ts]
  Outcome: success, 3 tests added
  Key decisions: "Validation logic tách riêng vào LoanValidator class"

Session 2025-05-25 (current):
  Task: "Fix bug in credit limit calculation"
  Context retrieved:
    ← Từ episodic store: recent file changes
    ← Key decisions có liên quan

Đặc điểm:

• Persist qua sessions
• Cần retrieval (search by date, task, file)
• Giúp agent hiểu "history" của project
• Phải implement storage (file, database)

Best for: "Agent nhớ chúng ta đã quyết định gì lần trước", audit trail, debugging.

Anti-pattern: Inject toàn bộ episodic history vào context. Chỉ retrieve relevant episodes.

Loại 4: Semantic Store (External, Long-term)

Semantic store là knowledge base lớn hơn — documentation, codebase knowledge, domain expertise — được truy xuất theo semantic similarity.

Semantic Store (RAG):

Knowledge base:
  [doc1] Spring Boot best practices
  [doc2] Oracle query optimization
  [doc3] MSB credit limit domain rules
  [doc4] T24 integration patterns
  [doc5] ...

Query: "How to handle concurrent credit limit updates?"
  ↓
Vector search: find relevant chunks
  ↓
Retrieve: [doc3 chunk 5], [doc2 chunk 12]
  ↓
Inject vào context của LLM

Đặc điểm:

• Unlimited storage ngoài context window
• Cần vector search infrastructure
• Retrieval quality quyết định agent quality
• Latency thêm từ retrieval step

Best for: Large knowledge bases, documentation search, codebase understanding.

Anti-pattern: Dùng RAG cho small knowledge base (<100 docs). Overhead không xứng.

Kết hợp các loại: Thực tế

Agent tốt kết hợp nhiều loại memory:

  System Prompt (Long-term, in-context):
    Project conventions, behavior rules
    → Always available, no retrieval

  Episodic Store (Short-term, external):
    Recent session history, file change log
    → Retrieve relevant episodes khi start session

  Semantic Store (Long-term, external):
    Documentation, API references
    → Retrieve on-demand khi agent cần

  Working Memory (Short-term, in-context):
    Current conversation, tool results
    → Live, grows during session

Trade-off: More Memory ≠ Better Agent

Thêm memory → thêm relevant context
           → thêm noise
           → thêm retrieval cost
           → thêm token cost

Balance:
  Inject chỉ những gì agent thực sự cần
  cho task hiện tại.
  Memory không dùng đến = noise = degraded quality.

Kết luận

• Bốn loại memory: Working, System Prompt, Episodic Store, Semantic Store.
• Phân biệt theo hai trục: in-context vs external, short-term vs long-term.
• Working memory là session conversation — rich nhưng ephemeral và tốn kém.
• System prompt là long-term knowledge tĩnh — inject một lần, tồn tại suốt session.
• Episodic store là lịch sử sessions — cần storage và retrieval để persist.
• Semantic store là knowledge base lớn — cần vector search, phù hợp với large corpora.
• Inject memory chọn lọc — thêm noise bằng irrelevant memory còn tệ hơn không có.