Agent không nhớ gì — lỗi thiết kế đắt nhất năm nay

Agent AI của bạn thông minh nhưng quên sạch sau mỗi phiên. Memory không phải tính năng phụ — nó là hạ tầng quyết định agent có dùng được thật hay không.

"Agent thông minh lắm rồi, cần gì nhớ?"

Giả sử bạn thuê một trợ lý mới — giỏi, nhanh, xử lý logic tốt. Nhưng mỗi sáng đến công ty, người này quên sạch mọi thứ ngày hôm qua. Bạn phải brief lại từ đầu: "Dự án A đang ở phase 2, anh B thích format X, chị C ghét khi report thiếu số liệu."

Mệt không? Đó chính xác là thứ đang xảy ra với hầu hết agent AI trên production.

Nhiều team mình biết xây agent rất kỹ — chọn model ngon, prompt chặt chẽ, tool calling mượt mà — nhưng quên mất một thứ: memory. Kết quả? Agent chạy đúng trong từng session, nhưng chuỗi session thì rời rạc như những mảnh ghép không ai ráp.

Khoan — memory cho agent phức tạp hơn bạn nghĩ

Khi nói "memory", bản năng đầu tiên của developer là nghĩ đến conversation history — đẩy mấy message gần nhất vào context window. Dịch sang tiếng thể thao: đó như một đội bóng chỉ nhớ 5 phút cuối trận, không hề biết đối thủ có thói quen gì từ hiệp 1.

Thực tế, memory cho agent có ít nhất hai tầng:

Short-term memory — những gì agent cần trong phiên làm việc hiện tại. Context window đang xử lý tốt phần này, nhưng nó có giới hạn vật lý. Nhét nhiều quá thì latency tăng, chi phí tăng, và model bắt đầu "lơ đãng" với thông tin ở giữa (hiện tượng lost-in-the-middle mà ai làm RAG cũng từng đau đầu).

Long-term memory — những pattern, preference, quyết định đã xảy ra qua nhiều phiên. Đây mới là thứ biến agent từ "chatbot có tool" thành trợ lý thực sự. Và đây cũng là thứ hầu hết hệ thống đang thiếu.

Weaviate gần đây chia sẻ một góc nhìn đáng suy ngẫm sau hai tuần dogfooding sản phẩm memory của họ với Claude Code: memory không phải feature — nó là infrastructure. Khi agent scale lên, cái vòng lặp stateless sụp đổ, và continuity trở thành bài toán hệ thống cần bảo trì chủ động.

Hai kịch bản — bạn đang ở cái nào?

Kịch bản 1: Team backend 4 người ở Sài Gòn, xây coding assistant nội bộ.

Agent giúp review code, suggest refactor, viết test. Tuần đầu ai cũng khen "nhanh ghê." Tuần thứ ba, dev bắt đầu bực: "Sao nó cứ suggest cái pattern mình đã reject 10 lần?" — vì agent không nhớ preference của từng dev. Mỗi session là một tờ giấy trắng.

Fix tạm: team nhét thêm một file team-conventions.md vào system prompt. Nhưng file này nặng dần, context window bị chiếm, và không ai muốn maintain cái file đó.

Fix đúng: tách memory thành layer riêng — mỗi lần agent nhận feedback "đừng dùng pattern này", nó ghi vào long-term memory. Lần sau gặp tình huống tương tự, query memory trước khi suggest. Giống cầu thủ xem lại băng hình trận trước để không lặp sai lầm.

Kịch bản 2: Startup edtech ở Hà Nội, agent hỗ trợ học viên.

Agent trả lời câu hỏi về khoá học, gợi ý bài tập. Mỗi lần học viên quay lại, agent hỏi lại từ đầu: "Bạn đang học khoá nào?" Trải nghiệm như gọi hotline — nhấn phím 1, nhấn phím 2, lặp lại lần thứ n.

Khi thêm memory layer lưu context của từng học viên (đang học chapter nào, hay sai ở dạng bài gì, thích giải thích kiểu nào), agent đột nhiên biến từ FAQ bot thành gia sư biết mặt biết tên.

Cái bẫy "nhớ nhiều = tốt"

Đến đây nhiều bạn sẽ nghĩ: "OK, vậy log hết mọi thứ vào database rồi query lại."

Plot twist: nhớ quá nhiều cũng chết.

Hình dung thế này: một huấn luyện viên ghi chép MỌI bước chạy của vận động viên trong 3 năm, không phân loại, không đánh dấu. Đến lúc cần xem lại chiến thuật, mở sổ ra thấy hàng nghìn trang — vô dụng.

Memory cho agent cũng vậy — không phải bài toán lưu trữ, mà là bài toán context engineering: chọn cái gì nhớ, quên cái gì, tổ chức ra sao để lúc cần thì lấy đúng thứ cần. Đây là lý do Weaviate gọi nó là "infrastructure" chứ không phải "feature" — vì nó cần pipeline riêng, cần maintenance, cần chiến lược decay (thông tin cũ mất giá trị theo thời gian).

Như mình đã chia sẻ trong bài về RAG pipeline, rác vào thì rác ra. Memory mà không có curation cũng chỉ là đống rác được đánh index cẩn thận.

Thử ngay chiều nay: 3 bước prototype memory layer

Không cần sản phẩm phức tạp — bạn có thể bắt tay vào trong một buổi chiều:

Bước 1: Phân loại memory. Ngồi liệt kê: agent của bạn cần nhớ gì giữa các session? User preference? Quyết định đã đưa ra? Convention của team? Viết ra một list ngắn — đây là schema cho memory store.

Bước 2: Chọn storage đơn giản nhất. Bắt đầu với một vector database open-source (Weaviate, Qdrant, hay ChromaDB đều được). Mỗi "memory" là một document ngắn, embed rồi lưu. Khi agent bắt đầu session mới, query top-k memories liên quan, inject vào context.

# Ví dụ minh họa đơn giản
import weaviate

client = weaviate.connect_to_local()
memories = client.collections.get("AgentMemory")

# Lưu memory mới
memories.data.insert({
    "content": "User A không thích singleton pattern",
    "agent": "code-reviewer",
    "created_at": "2026-04-10"
})

# Query memory trước khi respond
results = memories.query.near_text(
    query="suggest design pattern for service class",
    limit=5
)

Bước 3: Thêm feedback loop. Sau mỗi session, agent tự đánh giá: "Có gì đáng nhớ từ phiên này không?" rồi ghi lại. Đây là bước nhiều team bỏ qua, nhưng lại tạo ra khác biệt giữa agent "dùng được" và agent "không thể thiếu."

Vậy có nên thêm memory cho mọi agent?

Thật ra là không. Memory layer thêm complexity: thêm latency (query trước mỗi response), thêm cost (storage + embedding), thêm bảo trì (memory lỗi thời thì agent hành xử sai còn hơn không nhớ gì).

Với agent đơn giản, one-shot, stateless có khi lại tốt hơn — ít bug, dễ debug, rẻ. Nhưng nếu agent của bạn tương tác nhiều session với cùng user, hoặc cần maintain context dài hạn cho một project, thì memory là hạ tầng sống còn chứ không phải nice-to-have.

Mà nói cho cùng — agent không có memory giống cầu thủ không bao giờ xem băng hình đối thủ: vẫn đá được, nhưng cứ dính hoài cùng một miếng.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng