AI agent memory: thiết kế bộ nhớ có kiểm soát với rubric 36 điểm

AI agent memory là gì?

Trả lời ngắn: AI agent memory là cơ chế ghi, tổ chức và truy xuất thông tin để agent dùng lại trong cùng một thread hoặc qua nhiều session. Nó không đồng nghĩa với việc model “tự học”, cũng không chỉ là nhét toàn bộ lịch sử chat vào prompt. Một thiết kế có kiểm soát phải trả lời được sáu câu hỏi: ghi gì, từ nguồn nào, ai được đọc, khi nào truy xuất, kiểm tra ra sao và khi nào quên.

Bài này cung cấp một bộ công cụ thực hành v1.0 để bạn thiết kế và kiểm tra memory:

• Mẫu memory record — YAML
• Rubric memory 36 điểm — CSV
• Bộ 8 test retrieval — CSV

Giới hạn: toolkit này là khung biên tập do Đũa Thần AI tổng hợp, chưa được xác thực như standard, benchmark hay security certification. Điểm số không phải phần trăm an toàn và không chứng minh production readiness.

Hình 1. Memory hữu ích không chỉ cần nơi lưu; nó cần retrieval và evaluation tách biệt.

Rà soát ngày 07/09/2026. Owner sửa nội dung: Nghiêm Xuân Hào. Gửi yêu cầu đính chính qua trang liên hệ.

Working context khác long-term memory thế nào?

Working context là thông tin model nhìn thấy trong lần chạy hiện tại: system instruction, lịch sử hội thoại, tool result và tài liệu vừa truy xuất. Long-term memory là dữ liệu tồn tại qua nhiều thread hoặc session và chỉ đi vào context khi hệ thống truy xuất nó.

CoALA mô tả language agent với các memory module, action space và quy trình ra quyết định; đây là một kiến trúc khái niệm, không phải chuẩn bắt buộc (Sumers và cộng sự, 2023). MemGPT minh họa một hướng khác: quản lý nhiều tầng memory theo cảm hứng từ virtual memory của hệ điều hành để làm việc vượt quá context window hữu hạn (Packer và cộng sự, 2023).

Long context cũng không tự động giải quyết memory. Thực nghiệm Lost in the Middle cho thấy hiệu năng truy xuất có thể giảm khi thông tin liên quan nằm giữa một input dài; kết quả phụ thuộc task và model được thử, nên không nên biến phát hiện này thành quy luật tuyệt đối (Liu và cộng sự, 2023; TACL 2024).

Cách chia semantic–episodic–procedural cũng xuất hiện trong tài liệu LangChain; chính tài liệu này lưu ý long-term memory là bài toán phức tạp, không có một giải pháp phù hợp cho mọi trường hợp (LangChain, Memory overview, truy cập 07/09/2026).

Đừng hỏi “lưu được bao nhiêu”; hãy hỏi “record nào được phép sống”

Một memory record tối thiểu nên là nguyên tử, có nguồn và có vòng đời. Đừng lưu cả transcript nếu mục đích chỉ cần một preference đã được người dùng xác nhận. Đừng lưu secret, access token hay dữ liệu nhạy cảm chỉ vì agent có thể nhìn thấy chúng.

Mẫu YAML đi kèm bắt buộc các trường:

1. memory_type: semantic, episodic hoặc procedural;
2. subject_scope: user, team, organization hoặc task;
3. source và observed_at;
4. evidence_class: confirmed, receipt, inference hoặc unknown;
5. sensitivity và mục đích sử dụng;
6. người ghi, người review và trạng thái redaction;
7. expires_at, review_at, version và record bị thay thế;
8. liên kết tới outcome/eval và receipt xóa.

OWASP liệt kê memory poisoning và lưu dữ liệu nhạy cảm trong memory mà không mã hóa/redact là rủi ro của AI agent. Checklist này là hướng dẫn an ninh cộng đồng, không phải bằng chứng rằng một control riêng lẻ đã đủ (OWASP AI Agent Security Cheat Sheet, truy cập 07/09/2026).

Lifecycle 6 bước cho mỗi memory

Hình 2. Mỗi bước phải tạo evidence; “đã lưu” chưa phải là kết quả kiểm tra.

1. Capture: ghi candidate, chưa ghi “sự thật”

Candidate phải có source ID, timestamp và subject scope. Text do model suy ra vẫn là inference, cho đến khi policy hoặc người có thẩm quyền xác nhận.

2. Classify: xác định type và sensitivity

Tách fact, experience và procedure. Phân loại public, internal, personal hoặc restricted trước khi persistence. Nếu chưa biết mức nhạy cảm, mặc định hold thay vì tự hạ cấp.

3. Redact: bỏ phần không cần thiết

Giữ record nhỏ nhất phục vụ mục đích đã nêu. Prompt không phải lớp phòng thủ đáng tin duy nhất cho dữ liệu nhạy cảm; OWASP cảnh báo restriction trong system prompt có thể bị bỏ qua hoặc bypass (OWASP, Sensitive Information Disclosure, truy cập 07/09/2026).

4. Store: namespace và version

Tách namespace theo user/team/organization. Mỗi update tạo version hoặc liên kết supersedes; không ghi đè âm thầm. Record dùng chung nên read-only đối với agent nếu agent không có quyền thay policy.

5. Retrieve: lọc quyền trước similarity

Thứ tự an toàn hơn là: scope/permission → expiry → evidence class → relevance → top-k cap. Similarity cao không biến record ngoài quyền thành dữ liệu được phép đọc.

6. Expire: quên có receipt

Expiry, xóa theo yêu cầu và supersession phải có kết quả kiểm tra. Sau delete, chạy lại test retrieval để chắc record cũ không trở lại qua cache, index hoặc bản sao khác.

Nên nhớ gì, nên quên gì?

Hình 3. “Forget” là control vận hành; không phải mất dữ liệu tình cờ vì context bị cắt.

Nên cân nhắc giữ: preference người dùng đã xác nhận; instruction được duyệt; procedure gắn với outcome thành công; fact có source và freshness; failure đã phân loại để tạo regression test.

Không nên đưa vào memory dùng lại: secret/password; dữ liệu ngoài mục đích được phép; fact hết hạn; inference không nhãn; nội dung chứa instruction từ nguồn không tin cậy; record không xác định được subject scope.

Lưu ý thêm: persistence của nhà cung cấp và memory của ứng dụng là hai lớp khác nhau. Ví dụ, tài liệu Data Controls của OpenAI mô tả retention khác nhau giữa endpoints và tính năng, và các điều kiện này có thể thay đổi; hãy kiểm tra trang hiện hành cùng cấu hình tài khoản thay vì suy đoán (OpenAI, Data controls in the OpenAI platform, truy cập 07/09/2026).

Rubric 36 điểm: chấm thiết kế, không chấm “độ thông minh”

Rubric có 12 tiêu chí, mỗi tiêu chí từ 0–3:

• 0: không có evidence;
• 1: có mô tả nhưng chưa test;
• 2: đã test happy path;
• 3: đã test happy path, negative case và có receipt.

Bốn nhóm gồm scope/source/sensitivity/purpose, atomicity/truth/freshness/conflict, và retrieval relevance/isolation/abstention/deletion. Tổng tối đa 36 chỉ để so sánh các phiên bản của cùng một hệ thống.

Dừng rollout dù tổng điểm cao nếu một veto thất bại: scope isolation, sensitive-data control, consent/purpose, abstention khi thiếu evidence hoặc deletion verification. Không dùng tổng điểm để bù cho một lỗi chặn.

Cách dùng trong 30 phút

1. Tải rubric 36 điểm.
2. Chọn 10 memory record thật đã được khử dữ liệu nhạy cảm.
3. Chấm từng tiêu chí bằng evidence link, không chấm theo cảm giác.
4. Chạy 8 retrieval tests.
5. Ghi failure class: WRITE, SCOPE, FRESHNESS, RETRIEVAL, ABSTENTION hoặc DELETE.
6. Sửa một lớp mỗi lần rồi chạy regression test.

Ví dụ: agent chuẩn bị cuộc họp

Giả sử người dùng nói: “Từ nay, gửi agenda bằng tiếng Việt.” Một record hợp lý là preference đã xác nhận, user-scoped, có timestamp và review date. Câu “người dùng ghét slide dài” do model tự suy ra không được nâng thành fact. Link họp có access token không được lưu vào memory. Quyết định đã được phê duyệt về cấu trúc agenda có thể là procedural memory, nhưng phải có version và owner.

Khi chuẩn bị cuộc họp tiếp theo, agent lọc đúng user scope, loại record expired, lấy preference liên quan và ghi memory ID vào decision trail. Outcome “agenda đã được duyệt” đi vào episodic memory chỉ sau khi có receipt, không phải sau câu tự thuật “tôi đã hoàn tất”.

Nếu bạn mới xây agent, bắt đầu từ khung SPAR để giao việc có kiểm soát. Khi đã có memory, thêm bộ test và scorecard đánh giá AI agent để kiểm tra retrieval cùng outcome, thay vì chỉ kiểm tra câu trả lời dễ đọc.

FAQ

Vector database có phải long-term memory không?

Không nhất thiết. Vector database là một cơ chế lưu và semantic retrieval. Memory còn cần policy ghi, namespace, quyền, freshness, version, evaluation và delete. Bạn cũng có thể triển khai một số memory bằng relational database, document store hoặc file có kiểm soát.

Context window lớn có thay thế memory không?

Không. Context window lớn cho phép đưa nhiều input vào một run; long-term memory quản lý persistence qua session. Input dài vẫn có thể tạo nhiễu hoặc khiến thông tin quan trọng khó được dùng ổn định.

Agent có nên tự ghi memory không?

Chỉ khi có write policy rõ, schema validation, scope, redaction, versioning và test. Với policy hoặc dữ liệu dùng chung, read-only hay human approval thường là điểm khởi đầu thận trọng hơn.

Làm sao biết retrieval tốt?

Dùng một labeled test set gồm relevant, irrelevant, cross-scope, stale, conflicting, poisoned và deleted records. Đo ít nhất việc lấy đúng record, không lấy record cấm và biết abstain khi không có evidence. Không gộp tất cả thành một “memory score” duy nhất.

Xóa record trong database đã đủ chưa?

Chưa chắc. Hãy kiểm tra cache, search index, backup policy, derived summary và vendor persistence phù hợp kiến trúc thực tế. Ghi deletion receipt và chạy retrieval retest.

Bước tiếp theo

Bắt đầu với một use case hẹp và 8 test đã cung cấp. Nếu hệ thống không vượt qua scope isolation, abstention hoặc deletion, hãy giữ memory ở chế độ read-only hoặc tắt persistence cho đến khi có evidence sửa lỗi.

Muốn review một workflow cụ thể? Gửi sơ đồ memory, ba record mẫu đã khử dữ liệu nhạy cảm và kết quả test; Đũa Thần AI sẽ giúp bạn xác định câu hỏi cần kiểm tra, không hứa chứng nhận an toàn.

Nguồn tham khảo

• Sumers, Theodore R. và cộng sự. Cognitive Architectures for Language Agents (CoALA), arXiv:2309.02427, phiên bản 2023. Truy cập 07/09/2026. Bản ghi arXiv.
• Packer, Charles và cộng sự. MemGPT: Towards LLMs as Operating Systems, arXiv:2310.08560, phiên bản 2023. Truy cập 07/09/2026. Bản ghi arXiv.
• Liu, Nelson F. và cộng sự. Lost in the Middle: How Language Models Use Long Contexts, arXiv:2307.03172; xuất bản TACL 2024. Truy cập 07/09/2026. Bản ghi arXiv.
• LangChain. Memory overview, tài liệu hiện hành. Truy cập 07/09/2026. Tài liệu.
• OWASP Cheat Sheet Series. AI Agent Security Cheat Sheet, tài liệu hiện hành. Truy cập 07/09/2026. Tài liệu.
• OWASP GenAI Security Project. LLM02:2025 Sensitive Information Disclosure, phiên bản 2025. Truy cập 07/09/2026. Tài liệu.
• OpenAI. Data controls in the OpenAI platform, tài liệu hiện hành. Truy cập 07/09/2026. Tài liệu.