Memory 3 tầng: Index → Topic files → Session transcripts

Định nghĩa

Memory 3 tầng là kiến trúc lưu trữ ngoài (external memory) phân cấp gồm Index (bản đồ), Topic files (kho kiến thức chi tiết), và Session transcripts (nhật ký thô), cho phép AI agent duy trì tính liên tục của trạng thái dự án qua nhiều phiên làm việc bằng cách truy xuất thông tin theo độ chi tiết giảm dần.

Giải thích chi tiết

Tầng 1: Index (MEMORY.md) - Bản đồ dẫn đường

Index là file "bảng chỉ dẫn" đặt tại thư mục gốc, thường có tên MEMORY.md hoặc CLAUDE.md. Đây không phải tài liệu cho người đọc, mà là "bộ nhớ khởi động" cho AI.

File này chứa:

• Tổng quan cấp trúc dự án (tech stack, conventions)
• Danh mục các Topic files đang active
• Quyết định kiến trúc quan trọng (architectural decisions)
• Trạng thái hiện tại của dự án

Khi bắt đầu phiên mới, AI nạp Index trước tiên. Từ đó, AI biết cần đọc thêm những Topic files nào, thay vì phải quét toàn bộ codebase hoặc dựa vào Context Window vốn đã bị reset.

Tầng 2: Topic files - Kiến thức tinh chế

Topic files là các file markdown riêng lẻ trong thư mục con (ví dụ: .claude/topics/ hoặc .ai/memory/), mỗi file đại diện cho một chủ đề cụ thể như authentication.md, database-schema.md, hoặc api-contracts.md.

Khác với transcripts, Topic files là tri thức đã được curation:

• Chứa domain knowledge, giải thích lý do thiết kế (design rationale)
• API contracts và interface definitions
• Kết quả tóm tắt từ các phiên thảo luận trước
• Được cập nhật có chủ đích khi kiến thức thay đổi

Tầng này giải quyết vấn đề "thursday problem" - khi bạn thuê agent vào thứ Hai và thứ Năm, agent thứ Năm vẫn biết agent thứ Hai đã quyết định gì về schema, mà không cần đọc lại toàn bộ lịch sử chat.

Tầng 3: Session transcripts - Nhật ký thô

Transcripts là bản ghi nguyên văn toàn bộ cuộc hội thoại giữa người dùng và AI trong một phiên làm việc. Thường lưu dưới dạng file text hoặc JSON tại .claude/sessions/ với timestamp.

Tầng này phục vụ:

• Audit trail: Kiểm tra lại AI đã thực hiện gì
• Training data: Tinh chỉnh (distill) thành Topic files
• Recovery: Khi cần khôi phục trạng thái chi tiết của một phiên cụ thể

Compression ratio tại tầng này cao nhất - thông tin chưa được xử lý, nhưng đầy đủ nhất.

Cơ chế truy xuất phân cấp

Thay vì "bơm" toàn bộ dự án vào Context Window (vốn có giới hạn và tốn kém), AI tuân theo luồng:

1. Bootstrap: Nạp Index (thường dưới 500 tokens)
2. Selective Loading: Từ Index, xác định Topic files liên quan đến task hiện tại (ví dụ: đang làm API thì chỉ đọc api-contracts.md)
3. Contextual Operation: Thực hiện task với thông tin đã nạp
4. Write Back: Cập nhật Topic files hoặc Index nếu có thay đổi kiến trúc

Đây chính là sự khác biệt giữa "bộ nhớ trong" (Context Window - như RAM) và "bộ nhớ ngoài" (File system - như ổ đĩa).

Ví dụ thực tế

Claude Code Memory System

Claude Code triển khai chính xác pattern 3 tầng này trong thư mục .claude/:

.claude/
├── MEMORY.md          # Index: "Dự án này dùng FastAPI, SQLAlchemy, có 3 topic chính..."
├── topics/
│   ├── auth.md        # Chi tiết về JWT, refresh token flow
│   ├── db-schema.md   # Entity relationships, migration rules
│   └── frontend.md    # React conventions, component structure
└── sessions/
    ├── 2024-01-15-build-auth.log
    └── 2024-01-16-refactor-db.log

Khi bạn mở Claude Code vào ngày mới, nó đọc MEMORY.md trước. Nếu bạn yêu cầu "thêm tính năng quên mật khẩu", Claude tự động đọc thêm topics/auth.md để biết flow hiện tại, thay vì đoán mò hoặc scan lại toàn bộ code.

Anthropic JSON Feature List trong SWE-agent

Trong paper về SWE-agent, Anthropic sử dụng biến thể của 3 tầng để tránh "overwriting" (agent quên đã làm xong và làm lại từ đầu):

• Index: progress.json chứa danh sách features với trạng thái (todo, wip, done)
• Topic: {feature-name}.md chứa spec chi tiết và implementation notes
• Transcripts: session-{id}.log

Pattern "anti-overwrite" đảm bảo khi agent khởi động lại, nó kiểm tra progress.json (tầng Index) trước, thấy "Database Migration: done" thì không thực hiện lại, mà chuyển sang "API Integration: todo".

Session Handoff trong Multi-agent Workflow

Khi agent A (backend specialist) hoàn thành và chuyển sang agent B (frontend):

1. Agent A cập nhật topics/api-contracts.md với endpoint mới tạo (tầng 2)
2. Agent A ghi nhật ký vào sessions/backend-session-15.log (tầng 3)
3. Agent B khởi động, đọc MEMORY.md (tầng 1), thấy note "API docs ở topics/api-contracts.md"
4. Agent B đọc file đó, biết chính xác payload structure, không cần hỏi lại

Đây chính là session handoff pattern - truyền state giữa các phiên và giữa các agent khác nhau qua cấu trúc file chia sẻ.

Ứng dụng

AI Engineer (Xây dựng hệ thống production)

Dùng 3-layer memory để xây dựng coding agent cho dự án kéo dài nhiều tuần. Thiết kế harness với:

• MEMORY.md tự động append khi có quyết định kiến trúc mới
• Script kiểm tra xem Topic files có bị "stale" (lỗi thời) so với code không
• Transcripts rotation (xóa sau 30 ngày) để tiết kiệm disk

Tech Lead (Thiết kế quy trình team)

Thiết lập quy chuẩn cho team dùng AI cộng tác:

• MEMORY.md trở thành "single source of truth" về tech stack, ngăn developer A dùng React hooks còn developer B dùng class components
• Topic files là nơi review kiến trúc trước khi chấp nhận vào codebase
• Transcripts là audit log để biết ai đã yêu cầu AI refactor đoạn code nào

Nhà phát triển MCP/Agent Framework

Khi xây dựng MCP (Model Context Protocol) server, ánh xạ 3 tầng thành:

• Index → MCP resource list (resources/list endpoint)
• Topic → MCP resources với URI scheme memory://{topic-name}
• Transcripts → MCP logging hoặc persistence layer

Cho phép bất kỳ client nào (Claude Desktop, Cursor, v.v.) truy cập bộ nhớ dự án theo chuẩn giao thức.

So sánh

Memory 3 tầng là điểm cân bằng (sweet spot) giữa "dễ triển khai" (chỉ là file text) và "có cấu trúc" (curated knowledge), khác biệt so với RAG thuần tuý chỉ dựa vào semantic similarity. Trong khi RAG giúp tìm "cái gì liên quan", 3-layer memory giúp biết "cái gì quan trọng và đã được thống nhất".

Bài viết liên quan

Cùng cụm

Đọc tiếp