AI Agent có “nhớ” gì không? Thiết kế Context, State và Memory cho Production

Một AI agent trả lời được theo mạch hội thoại rất dễ tạo cảm giác nó “nhớ” người dùng. Nhưng trong production, đây là một từ dễ gây hiểu nhầm. Model không tự giữ ký ức giữa các request. Hệ thống quyết định request nào được ghép thêm dữ liệu nào, dữ liệu đó được lưu bao lâu, ai có quyền đọc, và khi workflow dừng giữa chừng thì có thể chạy lại an toàn hay không.

Vì thế, trước khi nói đến agent có memory, cần tách bốn khái niệm thường bị gộp làm một:

• Context là dữ liệu được đưa vào đúng request hiện tại: instruction, input, retrieval result và tool result cần thiết.
• State là trạng thái tiến trình của một session hoặc workflow: agent đang ở bước nào, tool nào đã chạy và bước tiếp theo là gì.
• Memory là dữ liệu bền vững có thể dùng qua nhiều session: preference đã được đồng ý lưu, fact đã xác minh, hay summary có chủ sở hữu rõ ràng.
• Knowledge/RAG là nguồn tri thức như tài liệu, policy, ticket hoặc catalog. Nó không tự động là memory của user.

Tách bốn lớp này không phải chuyện đặt tên. Nó quyết định agent có bị lộ dữ liệu tenant khác, lặp một tool call khi resume, tăng token vô hạn, hay trả lời bằng một “kí ức” đã hết hạn hay không.

Một request production thực sự đi qua những gì?

Luồng tối thiểu thường là:

1. Application gửi request cùng identity đã xác thực.
2. Admission layer gắn tenant, user và session hoặc thread identity.
3. Context builder chọn instruction, input hiện tại, evidence từ RAG, memory hợp lệ và tool result cần thiết.
4. Agent workflow thực thi; checkpoint state sau các bước quan trọng.
5. Hệ thống trả response, handoff hoặc đưa vào một bước chờ phê duyệt.

Identity phải đi cùng dữ liệu. Không nên retrieval memory của user A chỉ bằng một userId không có tenant boundary, access scope và kiểm tra quyền đọc tương ứng.

Context không phải là toàn bộ lịch sử chat

Context là working set của request. Nó nên nhỏ, có mục đích và có ngân sách token. Một context builder tốt thường trả lời được bốn câu hỏi:

• Bằng chứng nào là cần thiết để hoàn thành task này?
• Dữ liệu nào người gọi được phép xem ở thời điểm này?
• Item nào còn hiệu lực và đáng tin?
• Nếu bỏ item này đi, câu trả lời hoặc tool decision có thay đổi không?

Đừng mặc định append toàn bộ hội thoại cũ vào prompt. Cách đó làm chi phí và độ trễ tăng theo thời gian, đồng thời đưa vào ý định đã đổi, tool result cũ hoặc thông tin không còn quyền truy cập.

Một cách đơn giản hơn là duy trì summary có cấu trúc cho session, sau đó chỉ lấy một số turn gần nhất và evidence liên quan đến task. Khi cần tài liệu doanh nghiệp, retrieval phải áp dụng filter theo tenant, ACL, loại tài liệu và phiên bản trước khi kết quả đi vào prompt.

Ví dụ pseudocode:

session = loadSessionSummary(tenantId, sessionId)
evidence = searchKnowledge(tenantId, task, principal=userId, onlyAuthorized=true)
memories = retrieveMemory(tenantId, userId, task, notExpired=true)
return fitToTokenBudget(session, evidence, memories, task)

Search knowledge và retrieve memory phải kiểm tra quyền trước khi trả item, không phải sau khi prompt đã được lắp.

State: thứ giúp workflow resume mà không làm lại việc cũ

State không nhằm làm agent “có trí nhớ”. Nó giúp workflow có thể quan sát và khôi phục.

Nếu agent đã gửi yêu cầu tạo ticket, gọi thanh toán, cập nhật CRM hoặc chờ human approval thì một lần retry không được biến thành một lần thực thi thứ hai. Vì vậy state nên giữ:

• Thread hoặc session làm phạm vi của workflow.

• State version và step hoặc node hiện tại.

• Tool call đang chạy, đã thành công hoặc đã thất bại.

• Idempotency key của action có side effect.

• Thời gian checkpoint và chính sách expiry.

  checkpoint = stateStore.load(threadId) actionKey = threadId + step + createTicket if actionKey in checkpoint.completedActions: return priorResult(actionKey) result = ticketService.create(idempotencyKey=actionKey) stateStore.checkpoint(threadId, nextStep=summarizeResult)

Một checkpoint tốt hỗ trợ restart, review và human-in-the-loop. Nhưng state cần TTL rõ ràng; không phải mọi workflow đều đáng giữ mãi.

Memory dài hạn: chỉ lưu thứ có quyền được dùng lại

Long-term memory nên được xem là dữ liệu sản phẩm có lifecycle, không phải một kho transcript. Trước khi ghi, cần biết item đó thuộc về ai, được dùng cho mục đích nào, có nguồn nào, confidence ra sao và khi nào hết hạn.

Một item memory nên có tối thiểu:

• Tenant và subject owner.
• Type, ví dụ preference, verified fact hoặc session summary.
• Source và thời điểm cập nhật.
• Access scope.
• Expiry hoặc retention policy.

Không nên lưu mọi suy đoán của model thành memory. Việc ghi memory nên có policy riêng: chỉ ghi preference được xác nhận, fact có nguồn tin cậy, hoặc summary được đánh dấu rõ là session summary. Những item có tác động lớn nên có approval hoặc review path.

RAG và memory: gần nhau trong code, khác nhau trong trách nhiệm

Một hệ thống có thể dùng cùng một nền tảng dữ liệu cho cả retrieval, state và memory. Nhưng logic phân quyền, retention và đánh giá của ba loại dữ liệu này không được gộp làm một.

5 failure mode thường thấy

1. Lưu toàn bộ chat history như memory

Nó làm context phình to, kéo theo thông tin cũ và không giúp phân biệt fact với một câu nói nhất thời.

2. Dùng một memory key cho nhiều tenant hoặc nhiều user

Memory retrieval phải có tenant boundary và subject scope. Chỉ cần sai khóa phân vùng là dữ liệu có thể đi sang context của người không được phép thấy nó.

3. Resume workflow mà không có idempotency

Checkpoint cho biết agent đang ở đâu, nhưng không tự làm tool call an toàn. Mỗi thao tác có side effect cần idempotency key hoặc deduplication ở service đích.

4. Không có TTL và đường xóa dữ liệu

State tạm thời, preference dài hạn, audit log và knowledge document có retention khác nhau. Đừng dùng một chính sách xóa cho tất cả.

5. Retrieval có semantic similarity nhưng không có authorization

Vector similarity không thay thế cho access control. Query có thể tìm đúng về mặt ngữ nghĩa nhưng vẫn phải bị chặn nếu principal không có quyền xem source đó.

Thiết kế tối thiểu để bắt đầu

• Chọn identity chuẩn: tenant, user/subject, session/thread và service principal.
• Định nghĩa rõ item nào là context, state, memory và knowledge.
• Đặt token budget cho context builder; ưu tiên evidence có nguồn và còn hiệu lực.
• Checkpoint sau những node có side effect, approval hoặc chạy dài.
• Gắn idempotency key cho tool action có thể bị retry/resume.
• Lưu source, scope, expiry và policy cho mỗi memory item.
• Áp ACL trước retrieval; đừng dựa vào model để tự bỏ dữ liệu không được phép.
• Ghi trace cho retrieval set, state version, tool outcome, latency và token usage.
• Có đường xoá, sửa và review memory theo subject/tenant.

Kết luận

Agent không cần “nhớ tất cả” để hữu ích. Nó cần nhìn đúng dữ liệu, ở đúng thời điểm, trong đúng quyền hạn; workflow cần dừng và chạy lại mà không tạo side effect lặp; còn dữ liệu dùng lại cần có owner và vòng đời rõ ràng.

Khi tách Context, State, Memory và Knowledge thành các lớp có trách nhiệm riêng, team mới có thể tối ưu từng phần: context gọn hơn, workflow dễ khôi phục hơn, retrieval có kiểm soát hơn và việc vận hành ít phụ thuộc vào cảm giác rằng model đang tự hiểu mọi thứ.

Đọc thêm về góc nhìn đưa AI từ PoC lên production: Đưa OpenAI từ PoC lên production: Architecture, RAG, evaluation và integration trong hệ thống doanh nghiệp.

Nguồn tham khảo

• LangGraph persistence
• MongoDB Atlas: Memory for AI agents with LangGraph
• Amazon Bedrock: Manage memory

Ghi chú tác giả

Tác giả hiện làm việc tại TitanBases trong các dự án liên quan đến MongoDB, AI application architecture và production engineering. Bài viết tổng hợp các góc nhìn kỹ thuật về context, state và memory cho AI agent.