AI Agent cần tài liệu, không chỉ bộ nhớ: đừng nhầm việc nhớ với việc hiểu

Bạn đã giải thích cho AI agent rằng dự án dùng một cơ chế đăng nhập mới. Agent làm đúng trong phiên hiện tại. Vài ngày sau, nó lại đề xuất cách tích hợp cũ — rất tự tin, thậm chí còn dẫn lại một trao đổi trước đó.

Tình huống giả định này gợi ra một câu hỏi: agent thực sự thiếu bộ nhớ, hay thiếu một nguồn thông tin đáng tin về trạng thái hiện tại của dự án?

Trong bài Agents Don’t Need Memory. They Need Documentation., Kevin Liao đưa ra một luận điểm mạnh: thay vì tập trung vào việc lưu và truy hồi những mảnh hội thoại, hãy cho agent một hệ thống tài liệu có cấu trúc để tham khảo và duy trì.[1] Đây là góc nhìn đáng cân nhắc, đặc biệt với coding agent làm việc qua nhiều phiên và nhiều thành viên trong nhóm.

Phạm vi: Bài viết diễn giải và phân tích quan điểm của Kevin Liao, dựa trên nguồn được đọc ngày 04/10/2026; không phải bản dịch nguyên văn hay benchmark độc lập. Những cấu trúc thư mục và quy trình triển khai bên dưới là đề xuất của AIDaLat.

1. Nhớ nhiều hơn chưa chắc hiểu đúng hơn

Liao mô tả một kiểu kiến trúc memory phổ biến: đọc transcript, rút ra những mẩu thông tin, đưa vào cơ sở dữ liệu truy hồi rồi chèn các mẩu gần với câu hỏi mới vào ngữ cảnh của mô hình. Theo tác giả, cách tiếp cận này dễ biến việc hiểu dự án thành một cuộc chọn lựa những đoạn văn “có vẻ liên quan”.[1]

Vấn đề cốt lõi nằm ở sự khác biệt giữa liên quan và còn đúng. Một đoạn nói về đăng nhập có thể rất gần câu hỏi trong không gian embedding, nhưng thuộc về kiến trúc đã bị thay thế. Một quyết định có thể đúng khi nhóm chỉ có một dịch vụ, nhưng không còn phù hợp sau khi hệ thống được tách thành nhiều thành phần.

Bài gốc chỉ ra năm rủi ro của cách dựa vào recall:[1]

Truy hồi theo độ tương tự: độ gần về ngữ nghĩa không tự xác nhận tính đúng đắn hay tính hiện hành.
Mất bối cảnh: mẩu ghi nhớ ngắn có thể bỏ qua động cơ, môi trường và điều kiện áp dụng.
Xem quá khứ như sự thật: hội thoại cũ không nhất thiết phản ánh codebase hôm nay.
Không biết điều mình chưa biết: agent có công cụ tìm kiếm nhưng chưa chắc nhận ra nó cần tìm gì.
Khó kiểm toán: người vận hành khó thấy toàn bộ các mẩu nào đang tồn tại, lỗi thời hoặc âm thầm ảnh hưởng đến kết quả.

Tuy nhiên, cần đọc những nhận định này như lập luận của tác giả, không phải kết quả đo đạc cho mọi hệ thống memory. Bài viết không đưa ra một benchmark so sánh có kiểm soát để kết luận toàn bộ giải pháp truy hồi đều thất bại.

2. Tài liệu khác gì một bản tóm tắt hội thoại?

Một bản tóm tắt trả lời: “Chúng ta đã nói gì?”. Tài liệu tốt trả lời: “Hiện tại hệ thống hoạt động thế nào, vì sao như vậy, và điều gì được phép thay đổi?”

Ví dụ, ghi nhớ có thể là:

“Nhóm từng thảo luận dùng nhà cung cấp xác thực A.”

Nhưng tài liệu quyết định cần thể hiện rõ hơn:

“Hệ thống hiện dùng nhà cung cấp B. Phương án A đã bị loại. Khi sửa luồng đăng nhập, kiểm tra tài liệu xác thực, cấu hình triển khai và bộ test liên quan.”

Điểm khác biệt không chỉ là độ dài. Tài liệu đã được biên tập thành tri thức có chủ đích: có phạm vi, trạng thái, lý do và đường dẫn để xác minh. Lịch sử hội thoại vẫn có giá trị, nhưng không nên tự động trở thành quy định hiện hành.

3. Đổi vòng lặp: đọc trước, cập nhật sau

Liao đề xuất chuyển từ vòng lặp prompt → build → forget sang prompt → consult → build → update. Agent đọc các tài liệu liên quan trước khi làm; sau khi hoàn thành, nó sửa thông tin lỗi thời và bổ sung phần còn thiếu trong lúc bối cảnh công việc vẫn còn đầy đủ.[1]

Có thể diễn giải thành bốn bước thực dụng:

Nhận yêu cầu: xác định phạm vi, mục tiêu và tiêu chí hoàn thành.
Tham khảo: đọc bản đồ dự án, quy ước và tài liệu liên quan; đối chiếu với code hoặc hệ thống thực tế.
Thực hiện: sửa code, chạy test, kiểm tra kết quả và ghi nhận các quyết định mới.
Cập nhật: sửa tài liệu bị ảnh hưởng, đánh dấu quyết định bị thay thế và giữ liên kết tới bằng chứng.

Lợi ích kỳ vọng là phiên tiếp theo không phải ghép lại hàng chục mảnh hội thoại để đoán tình hình. Nhưng lợi ích đó chỉ xuất hiện nếu bước cập nhật thực sự được làm — một kho Markdown bỏ quên cũng có thể sai như một bộ nhớ lỗi thời.

4. Một file AGENTS.md chưa phải toàn bộ hệ thống tri thức

Theo Liao, AGENTS.md hữu ích để agent không bước vào dự án một cách mù mờ, nhưng một file duy nhất không đủ chứa hướng dẫn, đặc tả, quyết định, nghiên cứu và chỉ mục của cả dự án.[1]

AIDaLat đề xuất dùng file này làm điểm vào, không làm nơi nhét mọi thứ. Cấu trúc minh họa:

AGENTS.md                 # Quy tắc ngắn và đường dẫn bắt đầu
README.md                 # Mục tiêu, cách chạy dự án
docs/
  index.md                # Bản đồ tài liệu theo loại công việc
  architecture.md         # Kiến trúc hiện hành
  decisions/              # Quyết định và lý do, gồm phương án bị thay thế
  specs/                  # Yêu cầu và tiêu chí nghiệm thu
  runbooks/               # Quy trình vận hành, triển khai, xử lý sự cố
  research/               # Ghi chép API/thư viện, nguồn và ngày kiểm tra

Không nhất thiết phải tạo thư mục riêng chỉ cho AI. Một bộ tài liệu dùng được cho cả người và agent sẽ dễ được review và duy trì hơn. Cũng không cần bắt agent đọc toàn bộ kho ở mỗi lượt: chỉ mục nên chỉ ra tài liệu cần đọc cho từng loại nhiệm vụ.

5. Operator Memory: hiện thực hóa bằng Markdown

Tác giả cho biết ông bắt đầu bằng một thư mục internal/ để lưu đặc tả, kế hoạch và chỉ mục, rồi phát triển cách làm đó thành plugin Operator Memory. Theo mô tả trong bài, công cụ cung cấp một “bộ não” Markdown để agent tham khảo trước khi làm và cập nhật sau khi làm; các tài liệu có thể đọc, sửa, commit và chia sẻ trong nhóm.[1]

Liao nhấn mạnh thiết kế này không dùng vector database, embeddings hay các daemon nền chuyên tổng hợp, hợp nhất và viết lại ký ức. Ông cũng cho biết đã sử dụng hệ thống hơn một năm và dẫn tới mã nguồn mở của dự án.[1]

Đây là trải nghiệm do người phát triển công cụ tự báo cáo. Nó giúp hiểu động lực thiết kế, nhưng chưa đủ để xác định mức tiết kiệm token, độ chính xác hay hiệu quả so với một hệ thống khác. Bài học đáng lấy trước tiên là cách tổ chức tri thức, không phải mặc định mọi nhóm cần cài thêm một plugin.

6. Đừng thay “sùng bái memory” bằng “sùng bái documentation”

Tiêu đề bài gốc có sức gợi, nhưng lựa chọn thực tế không nhất thiết là bỏ bộ nhớ để dùng tài liệu. Cần phân loại thông tin theo vai trò:

Trạng thái tác vụ: việc đang làm, bước đã hoàn thành, phần còn thiếu — phù hợp với task state hoặc nhật ký phiên.
Sở thích ổn định: ngôn ngữ, cách trình bày, quy ước riêng của người dùng — có thể lưu trong hồ sơ ngắn.
Tri thức dự án hiện hành: kiến trúc, quy trình, yêu cầu, quyết định — nên có tài liệu được duy trì và review.
Lịch sử: trao đổi cũ và lý do hình thành quyết định — giữ để truy vết, không coi tất cả là chỉ dẫn đang có hiệu lực.

Đây là cách phân lớp do AIDaLat đề xuất. Tìm kiếm ngữ nghĩa vẫn có thể giúp tìm tài liệu trong kho lớn; điều quan trọng là kết quả tìm được dẫn tới nguồn có trạng thái và bằng chứng, thay vì một đoạn rời rạc được mặc nhiên xem là sự thật.

Tài liệu cũng không được ưu tiên mù quáng hơn thực tế. Nếu runbook nói dịch vụ chạy ở cổng A nhưng cấu hình đang dùng cổng B, agent cần nhận diện mâu thuẫn, kiểm tra và cập nhật — không chỉ làm theo file vì nó có tên “documentation”.

7. Bắt đầu nhỏ: một quy trình có thể kiểm tra

Thay vì tạo hàng trăm trang Markdown ngay từ đầu, hãy thử với một nhóm công việc thường lặp lại, chẳng hạn triển khai ứng dụng hoặc sửa luồng xác thực.

Trước khi làm: agent đọc chỉ mục và tài liệu liên quan; xác nhận thông tin quan trọng với code, cấu hình hoặc API.

Sau khi làm: chạy kiểm thử phù hợp, sửa tài liệu bị ảnh hưởng và ghi rõ quyết định nào đã thay thế quyết định cũ. Với thay đổi nhạy cảm như quyền truy cập hay thao tác production, tài liệu do agent viết vẫn cần người có trách nhiệm review.

Khi đánh giá: đo số lần agent lặp lại lỗi cũ, số lần cần nhắc lại quy ước, mức lệch giữa tài liệu và thực tế, cùng chi phí đọc và cập nhật. Đừng kết luận hiệu quả chỉ vì kho tài liệu trông gọn gàng.

Một tài liệu hữu ích nên trả lời được: ai chịu trách nhiệm, áp dụng ở đâu, kiểm tra lần cuối khi nào và bằng chứng nằm ở đâu. Không cần mọi trang đều phức tạp; cần thông tin đủ rõ để người hoặc agent biết khi nào phải nghi ngờ nó.

Kết luận: thứ cần giữ lại là hiểu biết đã được kiểm chứng

Điểm mạnh nhất trong lập luận của Kevin Liao không phải lời phủ định tuyệt đối về memory. Đó là lời nhắc rằng lưu lại quá khứ và quản lý tri thức hiện tại là hai công việc khác nhau.

Agent làm việc lâu dài cần một cách tiếp cận giúp nó tìm được bối cảnh đầy đủ, phân biệt quyết định hiện hành với ý tưởng đã bỏ, và để lại tài liệu tốt hơn sau mỗi lần thay đổi. Markdown, chỉ mục, review và kiểm chứng có thể là một điểm bắt đầu đơn giản.

Đừng chỉ hỏi “agent có nhớ không?”. Hãy hỏi “agent đang dựa vào nguồn nào, nguồn đó còn đúng không, và ai có thể kiểm tra nó?”.

Sources

[1] https://liao.gg/blog/agents-dont-need-memory — Agents Don’t Need Memory. They Need Documentation. — Kevin Liao