Bộ nhớ agent không phải món topping

Agent production không thắng nhờ nhét thêm context. Thứ đáng bàn là thiết kế memory như hạ tầng: có scope, có lọc nhiễu, có đường nạp dữ liệu tử tế.

Niềm tin phổ biến nhất tuần này: cứ model mới hơn, context window dài hơn, agent sẽ nhớ tốt hơn.

Mình hiểu vì sao niềm tin đó hấp dẫn. Nó giống đứng trước căn bếp và nghĩ: “Nồi to hơn thì nấu được món ngon hơn.” Nhưng nếu bạn đổ cả rau héo, xương vụn, giấy gói, nước rửa chén vào cùng một nồi, nồi có to mấy cũng chỉ tạo ra một thứ rất khó gọi tên.

Điểm đáng soi trong chuyện Engram của Weaviate không phải là “ồ, thêm một managed service cho agent memory”. Điểm đáng soi là một tín hiệu rõ hơn: memory đang rời khỏi tầng prompt và bước xuống tầng hạ tầng.

Sau bài này, nếu bạn đang build agent thật, mình muốn bạn đổi một cách nghĩ: đừng hỏi “agent của mình nhớ được bao nhiêu?”. Hãy hỏi: ký ức nào được phép sống lâu, thuộc scope nào, được lấy lại bằng cơ chế nào, và ai chịu trách nhiệm khi nó sai?

Sơ đồ tóm tắt ý chính của bài viết.

Cái đang diễn ra: memory hết là mẹo prompt

Engram được giới thiệu như một managed memory and context service — dịch gọn là dịch vụ quản lý bộ nhớ và ngữ cảnh cho agent. Nó nhận các event thô, ồn, phát sinh trong quá trình agent chạy; biến chúng thành memory có cấu trúc, bền hơn, có scope rõ; rồi phục vụ lại qua retrieval kết hợp semantic và keyword.

Có vài thuật ngữ cần neo nhanh:

• long-context degradation: chất lượng trả lời giảm khi nhét quá nhiều ngữ cảnh dài vào model, nhất là phần thông tin nằm giữa input.
• scoped memory: bộ nhớ có phạm vi, ví dụ theo user, team, project, workflow; không phải ai cũng thấy mọi thứ.
• hybrid semantic and keyword retrieval: tìm kiếm kết hợp nghĩa gần nhau và từ khóa chính xác.

Đọc kỹ thì đây không phải câu chuyện “agent giờ có trí nhớ”. Agent trước giờ vẫn có thể lưu log, append hội thoại, nhét lại transcript. Nhưng đó là kiểu đổ nguyên liệu vào kho rồi bảo đầu bếp tự phân loại lúc khách đã gọi món.

Vấn đề production nằm ở chỗ khác: khi agent chạy lâu, dữ liệu cũ không tự biến thành hiểu biết đúng. Nó chỉ biến thành một đống lịch sử nếu bạn không có pipeline xử lý memory.

Mổ xẻ: ba lỗi khiến agent càng chạy càng rối

Weaviate nêu ba failure modes rất đáng để builder ghi lên bảng trắng.

Thứ nhất là long-context degradation. Nhiều team phản xạ bằng cách gửi cả cuộc trò chuyện về model ở mỗi lượt. Ban đầu thấy tiện. Sau đó latency tăng, cost tăng, và chất lượng câu trả lời đôi khi giảm vì model phải bơi trong một hồ chữ quá dài.

Ví dụ cụ thể: giả sử agent support của bạn từng xử lý một khách hàng đổi gói dịch vụ ba lần. Nếu bạn nhét toàn bộ thread chat, email, ticket, ghi chú nội bộ vào prompt, model có thể lẫn giữa trạng thái cũ và trạng thái mới. Thứ bạn cần không phải “toàn bộ lịch sử”, mà là một memory đã được chưng cất: khách hiện đang ở gói B, từng yêu cầu không gọi điện, ưu tiên nhận email tiếng Việt.

Thứ hai là messy raw data — dữ liệu thô lộn xộn. Interaction của user không sạch. Người dùng đổi ý. Team sửa chính sách. Một câu từng đúng tháng trước có thể sai hôm nay. Nếu bạn gom raw events vào database rồi mỗi lần query mới bảo LLM tự hòa giải mâu thuẫn, bạn đang đẩy phần khó nhất sang thời điểm tệ nhất: lúc cần trả lời nhanh và đúng.

Thứ ba là multi-agent context fragmentation. Khi một request đi qua nhiều agent — ví dụ planner, researcher, coder, reviewer — mỗi agent có thể giữ một mảnh ngữ cảnh riêng. Nếu không có memory chung nhưng được phân quyền và phân scope, workflow sẽ giống mấy người nấu chung một bếp mà mỗi người giấu một nửa công thức.

Nói thẳng ra thì: memory không phải transcript dài hơn; memory là state được quản trị.

Khung quyết định: tách event, memory, index

Để tránh bị cuốn theo hype “managed memory”, mình sẽ nhìn nó bằng một khung ba lớp. Team nào build agent production cũng nên tự trả lời ba lớp này trước khi chọn tool.

1. Event log: chuyện gì đã xảy ra?

Đây là lớp ghi nhận sự kiện thô: user nói gì, agent gọi tool nào, kết quả API ra sao, action nào thành công hay thất bại.

Event log cần đầy đủ để audit, debug, replay. Nhưng không phải event nào cũng xứng đáng trở thành memory. Một câu user gõ nhầm, một tool call lỗi, một trạng thái tạm thời trong checkout không nên sống mãi trong trí nhớ agent.

2. Curated memory: điều gì đáng nhớ?

Đây là lớp quan trọng nhất. Curated memory là ký ức đã qua lọc: sở thích ổn định, quyết định đã chốt, constraint của dự án, bài học sau một lần sửa lỗi.

Nếu bạn là tech lead, hãy định nghĩa policy kiểu:

• Memory nào được tạo tự động?
• Memory nào cần xác nhận của user hoặc hệ thống?
• Memory nào có ngày hết hạn?
• Khi hai memory mâu thuẫn, cái nào thắng?

Engram đáng chú ý vì nó đặt vấn đề “raw, noisy agent events” phải được biến thành structured, durable, scoped memories. Dù bạn dùng Engram hay tự build, tư duy này mới là phần cần giữ.

3. Retrieval index: lấy lại bằng cách nào?

Đây là lớp phục vụ memory trở lại agent. Embeddings là biểu diễn văn bản thành vector để máy tìm những nội dung gần nghĩa. Nhưng chỉ vector search không đủ trong nhiều workflow. Có lúc bạn cần semantic match, có lúc cần keyword chính xác như mã đơn hàng, tên repo, version API.

Vì vậy hybrid retrieval đáng quan tâm. Với agent coding, câu “tìm các quyết định liên quan đến auth middleware” khác với “tìm chính xác file auth_middleware_v2.md”. Một bên cần gần nghĩa, một bên cần đúng tên.

Pinecone nhắc một chuyện khác: memory cũng cần đường nhập hàng

Nguồn liên quan từ Pinecone về bulk import nghe như chuyện vector database, nhưng nó chạm đúng một phần bị nhiều team bỏ qua: nạp dữ liệu ban đầu vào hệ thống memory/retrieval.

Bulk import là cách nạp dữ liệu lớn theo lô, bỏ qua đường ghi từng request thông thường để đi thẳng từ object storage vào index builder. Pinecone đang miễn phí bulk import đến 1 TB cho Standard và Enterprise plan, kèm credit tự động theo thông báo của họ; sau 1 TB là $0.25/GB, giảm từ $1/GB. Họ cũng nêu 1 TB có thể chứa khoảng 130 triệu record ở 1024 dimensions với metadata điển hình.

Tại sao chuyện này liên quan đến agent memory?

Vì nhiều team bắt đầu agent bằng demo nhỏ: vài trăm document, vài cuộc hội thoại, vài prompt. Nhưng production thường cần seed một corpus thật: docs nội bộ, ticket lịch sử, runbook, changelog, quyết định kiến trúc, FAQ. Nếu đường nhập dữ liệu ban đầu quá đắt hoặc quá chậm, team sẽ test trên lát cắt đồ chơi rồi ngạc nhiên khi production cư xử khác.

Một vài thuật ngữ trong flow này:

• upsert: ghi hoặc cập nhật từng record vào index.
• Parquet: định dạng file dạng cột, hợp cho dữ liệu lớn.
• object storage: kho lưu file kiểu S3, dùng để đặt dữ liệu trước khi import.

Điểm mình muốn bạn giữ lại: memory service không sống một mình. Nó cần chiến lược ingest, làm sạch, versioning, và evaluation. Nếu không, bạn chỉ thay một cái kho bừa bộn bằng một cái kho có hóa đơn đẹp hơn.

Điều đáng giữ: câu hỏi hạ tầng, không phải tên sản phẩm

Nếu team bạn đang cân nhắc lớp memory cho agent, đây là checklist đủ dùng trong một buổi chiều:

1. Vẽ vòng đời memory

Từ event thô → candidate memory → memory được duyệt → memory hết hạn hoặc bị ghi đè.

1. Chia scope ngay từ đầu

Tối thiểu nên có user scope, org/team scope, project scope. Đừng để agent support lôi ký ức của khách A sang khách B.

1. Định nghĩa conflict policy

Khi memory cũ nói “dùng Python 3.10” và memory mới nói “đã nâng lên Python 3.12”, hệ thống chọn theo timestamp, nguồn tin, hay xác nhận của maintainer?

1. Tách retrieval cho người và máy

Agent cần context ngắn, đúng việc. Người vận hành cần audit trail dài, đầy đủ. Hai nhu cầu này không nên dùng cùng một prompt nhồi hết mọi thứ.

1. Đo cost theo lượt gọi thật

Đừng chỉ đo storage. Hãy đo cả retrieval latency, token được đưa lại vào model, số lần memory sai làm agent đi lệch.

Hình dung thế này: nếu memory là phần nước dùng, bạn không muốn mỗi bát phở phải ninh lại toàn bộ xương từ đầu. Nhưng bạn cũng không muốn dùng nồi nước đã để qua ba mùa mà không ai biết trong đó có gì.

Điều nên bỏ qua: FOMO “agent có trí nhớ”

Có ba thứ mình sẽ không vội mua chỉ vì một launch mới.

Một là demo agent “nhớ bạn thích gì” nhưng không nói memory được xóa, sửa, audit ra sao. Với sản phẩm thật, quyền quên và quyền sửa đôi khi quan trọng hơn quyền nhớ.

Hai là lời hứa context dài sẽ giải quyết hết. Context window lớn giúp được một phần, nhưng không thay thế được memory có cấu trúc. Nhét thêm không đồng nghĩa với hiểu đúng.

Ba là kiến trúc multi-agent mà mỗi agent có memory riêng nhưng không có contract chia sẻ. Nếu planner nhớ một kiểu, executor nhớ một kiểu, reviewer nhớ kiểu khác, bạn sẽ debug bằng niềm tin và cà phê nguội.

Với team Việt Nam quy mô nhỏ, mình sẽ không bắt đầu bằng kiến trúc quá hoành tráng. Nếu là mình, mình sẽ chọn một workflow có giá trị rõ — ví dụ agent support nội bộ cho dev docs — rồi build tối thiểu ba lớp: event log, curated memory, retrieval index. Sau đó mới quyết định dùng managed service như Engram, vector database có bulk import, hay tự dựng một phần.

Kết lại: cái mới đáng bàn không phải agent “nhớ dai” hơn, mà là team có dám đối xử với memory như hạ tầng nghiêm túc hay vẫn nêm đại vào prompt rồi cầu may. Bếp nóng thì ai cũng muốn ra món nhanh; nhưng nêm ký ức quá tay, agent sẽ mặn miệng trước khi kịp thông minh.

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