Bộ nhớ AI agent: Anthropic dạy agent nhớ và tự sửa sai

Tuần trước, bạn và Claude Code thống nhất một quyết định kiến trúc: service mới dùng PostgreSQL, không dùng MongoDB, vì team đã có sẵn quy trình backup. Hôm nay bạn mở phiên mới, nhờ agent viết migration, và nó thản nhiên tạo collection MongoDB. Bạn nhắc lại, nó xin lỗi, sửa xong. Tuần sau, phiên khác, nó lại quên.

Đó là nỗi đau lớn nhất của người dùng coding agent hiện nay: mỗi phiên trò chuyện là một khởi đầu mới, agent không mang theo ký ức, hoặc mang theo ký ức sai. Ngày 6/11/2026, Anthropic đăng bài nghiên cứu “The components of agent memory” của Lance Martin — lần đầu một lab lớn hệ thống hoá cách agent nhớ xuyên phiên, kèm số liệu đánh giá cụ thể. Bài viết này giải thích kiến trúc đó, đọc đúng các con số, và rút ra những quy tắc bạn áp dụng được ngay.

Agent “nhớ” nghĩa là gì

Anthropic định nghĩa hẹp và rõ: bộ nhớ của agent là kiến thức Claude thu được từ kinh nghiệm — tương tác với người dùng, nhiệm vụ được giao — và giữ lại giữa các phiên dưới dạng context mà nó có thể đọc lại sau này.

Định nghĩa này loại trừ ba thứ hay bị nhầm là bộ nhớ: cập nhật trọng số trong lúc huấn luyện, học trong phiên (in-context learning), và compaction — bản tóm tắt Claude tự viết để thay các turn cũ khi cửa sổ context đầy. Bộ nhớ, theo nghĩa của bài nghiên cứu, là thứ tồn tại giữa các phiên, dưới dạng file và văn bản mà phiên sau đọc được.

Anthropic mượn một câu của Kierkegaard: đời người chỉ hiểu được khi nhìn lại, nhưng phải sống về phía trước. Agent cũng vậy — phải quyết định cái gì đáng lưu trước khi biết tương lai cần gì. Con người giải quyết việc này một phần nhờ giấc ngủ: hồi hải mã phát lại trải nghiệm gần đây khi não offline, dần chắt lọc thành tri thức dài hạn. Anthropic đề xuất agent làm điều tương tự, dựa trên ý tưởng sleep-time compute của Letta và UC Berkeley: dùng thời gian rảnh giữa các tương tác để sắp xếp lại context đã có. Quá trình đó gọi là dreaming.

Kiến trúc 4 lớp bộ nhớ

Bài nghiên cứu mô tả bộ nhớ agent thành bốn lớp xếp chồng, từ thô tới tinh:

1. Transcripts — nhật ký sự kiện. Mọi việc agent làm được ghi lại thành log có thể tìm kiếm — lớp nền đầy đủ nhất, nhưng cũng ồn ào nhất.
2. Memory notes — ghi chú. Claude tự viết ghi chú về điều có thể quan trọng sau này: quyết định đã chốt, quy tắc đã kiểm chứng, cái bẫy đã gặp. Ghi chú là dự đoán — viết một quy tắc xuống là dự đoán mẫu đó sẽ lặp lại.
3. Representations — biểu diễn, điển hình là wiki. Wiki là tập hợp các trang do Claude viết và duy trì, mỗi trang gom những gì nó biết về một chủ đề và liên kết tới các ghi chú khác — tạo thành bản đồ để agent lần theo khi cần tìm ký ức.
4. Injected context — context nạp sẵn. Một phần nhỏ ký ức được nạp vào đầu mọi phiên sau, để agent không cần tìm kiếm, thậm chí không cần biết có thứ để tìm.

Dreaming là vòng chạy offline nối các lớp lại với nhau: đọc lại transcript để sửa ghi chú sai, xây và dọn wiki, quyết định fact nào xứng đáng được đẩy lên lớp nạp sẵn.

flowchart TD
    A[Phiên làm việc<br/>Transcript: log sự kiện] --> B[Memory notes<br/>Ghi chú: quyết định, quy tắc, cái bẫy]
    B --> C[Wiki<br/>Biểu diễn: trang liên kết theo chủ đề]
    C --> D[Injected context<br/>Nạp sẵn vào mọi phiên sau]
    D -.-> A
    E[Dreaming<br/>pass offline] -. sửa ghi chú sai .-> B
    E -. xây & dọn wiki .-> C
    E -. chọn fact đẩy lên .-> D
    A -. đối chiếu transcript .-> E

Dreaming không phải lớp thứ năm. Nó là quá trình chạy giữa các lớp, lúc agent không bận phục vụ người dùng.

Dreaming khác gì RAG và compaction

Ba khái niệm này hay bị gộp chung, nhưng chúng giải quyết ba vấn đề khác nhau:

RAG trả lời “tìm ở đâu”, compaction trả lời “nhường chỗ thế nào”, dreaming trả lời “cái gì trong quá khứ đáng tin và đáng giữ”. Dreaming cần transcript làm ground truth: nó so sánh ghi chú với log gốc, chứ không tin ghi chú một cách mù quáng.

Ba thí nghiệm, ba bài học

1. CL-Bench: ghi chú giúp agent học từ sai lầm

Thí nghiệm đầu dùng một task trong Continual Learning Bench (CL-Bench) 1.0: Claude trả lời chuỗi câu hỏi bằng cách tra cứu database, sau mỗi câu được biết đáp án đúng và có thể viết ghi chú cho câu sau. Mỗi câu hỏi bắt đầu trong một phiên mới hoàn toàn, trừ một thư mục memory tồn tại xuyên suốt. Thí nghiệm chạy trên Claude Managed Agents.

Kết quả, tính theo điểm thưởng trung bình (không bộ nhớ → có bộ nhớ):

Điểm đáng chú ý không nằm ở con số tuyệt đối mà ở cách các model dùng memory. Sonnet 4.6 chỉ dừng ở mức nêu giả thuyết về lý do trả lời sai, ghi lại thành nhiều file rời rạc toàn phỏng đoán chưa kiểm chứng. Opus 5 là model đầu tiên khép kín vòng học: mỗi ghi chú gồm một quy tắc, cách nó biết quy tắc đó đúng, đáp án các câu trước, và cảnh báo về những cái bẫy đã phát hiện. Opus 5.5 và Sonnet 5.5 cũng khép được vòng này.

Nói cách khác, model càng mạnh càng biến memory thành vòng học có kiểm chứng, chứ không phải kho lưu trữ. Model yếu hơn hưởng lợi nhiều nhất từ hướng dẫn tường minh: khi được nhắc đọc memory trước khi trả lời rồi kiểm chứng giả thuyết của mình, Sonnet 4.6 tăng từ 0,330 lên 0,641 — gần gấp đôi. Sonnet 5 tự làm việc này 9 trên 10 lần mà không cần nhắc; Sonnet 4.6 làm chưa tới một nửa số lần.

Ngược lại, ra quy tắc cứng về cái gì được ghi lại lại phản tác dụng với model mạnh. Khi Anthropic thử quy tắc “chỉ ghi lại thất bại”, Opus 5 mất 0,234 điểm tăng trưởng, Opus 4.7 mất 0,150. Nói cho model biết memory dùng để làm gì thì tốt; ra lệnh cứng nó phải ghi cái gì thì làm nó dở đi.

2. Pokémon Red: ghi càng nhiều, nhớ càng dở

Thí nghiệm thứ hai kiểm tra khả năng phán đoán cái gì đáng lưu. Anthropic cho Claude chơi Pokémon Red, mỗi model có một thư mục memory để đọc và ghi trong lúc chơi, rồi so sánh thư mục của Sonnet 3.7 và Fable 5 ở khoảng 10.000 bước chơi.

Sonnet 3.7 ghi lại mọi thứ có thể quan trọng: 413 file trong 225 thư mục — mỗi trận đấu, mỗi vật phẩm, mỗi nhân vật đều có file riêng — và chỉ giành được 1 huy hiệu. Trạng thái game thay đổi liên tục nên bản ghi chi tiết nhanh chóng lỗi thời; tới bước 10.000, trong 17 bước tiếp theo nó tạo 6 file, xoá 9 file, mà không thực hiện hành động nào trong game.

Fable 5 viết 9 file trong 2 thư mục, cộng một file global.md ở gốc, và giành 4 huy hiệu. Nó bỏ qua những thứ màn hình đã cho biết — số tiền, vị trí trên bản đồ — vì lưu chúng là thừa. Nó chỉ lưu thứ phải tự suy ra: chiến lược, kế hoạch, quy tắc đã kiểm chứng. File global.md đóng vai trò bảng điều khiển: mục tiêu hiện tại, kế hoạch đánh gym, và chính các quy tắc dùng memory của nó. Opus 5.5 dùng cách tiếp cận tương tự, thư mục nhỏ, và đã chơi thắng game.

Bài học rất thực tế: bộ nhớ không phải kho lưu trữ, mà là bộ lọc. Lưu thứ môi trường không tự nói cho bạn biết. Còn thứ đọc lại được từ màn hình, từ log, từ trạng thái hệ thống — đừng lưu.

3. Wiki 128 phiên: từ nhân viên mới tới nhân viên kỳ cựu

Thí nghiệm thứ ba kiểm tra wiki như một biểu diễn của bộ nhớ. Anthropic dùng kho tài liệu nội bộ của Stainless, công ty họ mua lại hồi tháng 5: khoảng 350.000 file, chừng 420 triệu token. Họ soạn 25 câu hỏi về kho này, cho Claude công cụ search, và yêu cầu Claude xây wiki bằng dreaming. Trong 128 phiên, các agent Opus 5 khám phá file, viết hoặc sửa trang wiki liên kết, gộp trùng lặp, kiểm chứng tuyên bố với nguồn.

Kết quả theo tỉ lệ tiêu chí chấm đạt được:

Wiki một mình không thắng search. Nhưng wiki cộng search thì thắng, và còn tiết kiệm khoảng 20.000 token mỗi câu hỏi. Wiki lớn dần từ 103 trang và 766 liên kết sau 2 phiên lên 222 trang và 12.893 liên kết sau 128 phiên. Anthropic ví quá trình này như một nhân viên mới dần thành nhân viên kỳ cựu: những vòng dreaming đầu, wiki còn nghèo; càng mơ nhiều, bản đồ tri thức càng giàu.

Nhưng wiki không phải lúc nào cũng giúp. Với 24 câu hỏi về một vụ sáp nhập, phần lớn cần tổng hợp nhiều tài liệu, wiki đạt 87% so với 73% của search. Ngược lại, với task mà tiêu chí chấm lấy được từ một tài liệu duy nhất bằng search văn bản, wiki không cho thấy lợi ích rõ rệt. Có trường hợp wiki phình to hơn cả tài liệu gốc: 10 tài liệu 115 KB biến thành wiki 68 trang 203 KB, gấp 1,77 lần.

Một chi tiết đáng giá cho ai chạy nhiều agent song song: nhiều agent cùng ghi vào một bảng chung các điều khoản hợp đồng và ghi đè lên nhau, kết quả chỉ còn 41 trên 57 fact (72%). Anthropic cho Claude tự phản chiếu thất bại, đề xuất thay đổi hướng dẫn, rồi xây lại wiki: mỗi hợp đồng một trang riêng, một agent viết, trích điều khoản nguyên văn thay vì tóm tắt vào bảng chung. Lần này 57 trên 57 fact được giữ, brief đạt 100% tiêu chí. Dreaming còn vá lỗ hổng xuyên phiên: một pass thứ hai phát hiện 9 liên kết trỏ tới trang wiki chưa tồn tại, chuyển hướng chúng về trang đúng, và thêm 3 trang mới, gồm cả trang mục lục.

Dreaming sửa sai như thế nào

Phần thuyết phục nhất là câu chuyện Mt. Moon trong Pokémon Red. Người chơi phải đi qua hang Mt. Moon, cửa vào phía tây, cửa ra phía đông. Gần cửa vào có một gờ đá một chiều: rơi xuống là quay lại đường cũ, không có đường leo lên. Claude dùng PokéCenter gần cửa hang làm mốc, và đã ghi sai rằng PokéCenter nằm phía đông.

Từ ghi chú sai đó, mọi suy luận sau đều lệch: bước ra khỏi PokéCenter, Claude tuyên bố “Mt. Moon ở sau lưng mình” và cập nhật ghi chú “Mt. Moon DONE”. Vài hành động sau, nó rơi khỏi gờ đá, quay lại đường cũ, công cụ điều hướng không hiển thị cú rơi, nên nó kết luận “mình đã đi quá xa về phía tây” — vẫn tin mình đúng. Trong lần chạy với ghi chú chưa sửa, nó rơi xuống đường cũ ba lần, rồi bỏ cuộc và quay về Pewter City, thị trấn trước ngọn núi, mà không bao giờ tới được Cerulean City.

Anthropic chạy dreaming trên thư mục memory chứa ghi chú sai: Claude đối chiếu ghi chú với transcript gốc, phát hiện lỗi, viết lại. Với ghi chú đã sửa, nó đi thẳng vào hang và tới được Cerulean City. Transcript đóng vai trò ground truth — đó là cốt lõi thực hành của dreaming: một vòng kiểm tra nền, rẻ, đối chiếu ghi chú với log thô.

6 quy tắc thực hành rút ra từ số liệu

Từ ba thí nghiệm trên, đây là những quy tắc áp dụng được ngay, kể cả khi bạn không chạy hệ thống dreaming tự động:

Quy tắc 6 có một hệ quả trực tiếp cho người dùng Claude Code: lớp injected context phải nhỏ, vì file hướng dẫn càng dài thì mức tuân thủ càng giảm, theo chính tài liệu của Claude Code mà Anthropic trích dẫn. Claude Code chỉ nạp 200 dòng đầu hoặc 25 KB đầu của MEMORY.md — phần đó đóng vai trò mục lục, chỉ cho Claude biết nó biết gì và tìm ở đâu, thay vì nhồi toàn bộ ký ức vào mọi phiên.

Đặt vào bức tranh các công cụ đã có

Kiến trúc 4 lớp giúp xếp các công cụ blog đã viết vào đúng vị trí: Claude-mem là plugin memory thực tế cho Claude Code, giải quyết lớp ghi chú và lớp nạp sẵn; Auto Ontology xây lớp ngữ nghĩa đã chứng nhận giữa database và agent, gần lớp biểu diễn (wiki) nhưng cho dữ liệu có cấu trúc; Headroom nén log và tool output ngay trên máy, giải quyết transcript phình to ở lớp nền; Graphify biến codebase thành knowledge graph truy vấn được, một dạng biểu diễn khác của lớp wiki, xây từ code thay vì transcript.

Theo mình, điểm khác biệt của bài nghiên cứu là nó không bán công cụ nào. Nó mô tả cơ chế mà mọi công cụ trên đều chạm vào một phần: ghi chú, biểu diễn, nạp sẵn, và vòng rà soát nền nối chúng lại. Hiểu cơ chế rồi, bạn chọn công cụ theo lớp mình đang thiếu, thay vì lắp thêm plugin vào chỗ đã đủ.

Khi agent nhớ sai: xử lý và rollback

Ghi chú sai là rủi ro lớn nhất của bộ nhớ agent: phiên sau tin tưởng và hành động theo nó. Cách xử lý theo đúng cơ chế dreaming:

1. Phát hiện: khi agent lặp lại lỗi cũ hoặc quyết định trái với quyết định đã chốt, đừng sửa hành vi — kiểm tra ghi chú. Lỗi thường nằm ở lớp memory notes, không phải ở model.
2. Đối chiếu transcript: mở log phiên gốc nơi quyết định được đưa ra. Transcript là ground truth; ghi chú chỉ là diễn giải.
3. Sửa tại chỗ, ghi rõ nguồn: viết lại ghi chú, kèm cách bạn biết nó đúng và trạng thái đã xác nhận — đúng mẫu Opus 5 dùng trong CL-Bench.
4. Rollback: nếu không chắc ghi chú nào đúng, xoá ghi chú đáng ngờ khỏi lớp nạp sẵn và để agent đọc lại transcript khi cần. Thà không nhớ còn hơn nhớ sai: ghi chú sai nạp vào mọi phiên sẽ nhân lỗi lên.
5. Phòng ngừa: tập trung pass rà soát vào thông tin hay thay đổi, điều chỉnh nhịp rà soát theo tần suất ghi chú được đọc — đúng hai gợi ý Anthropic để mở cuối bài.

Bài học rút ra

1. Bộ nhớ là dự đoán, không phải lưu trữ. Ghi chú tốt kèm bằng chứng và trạng thái kiểm chứng, như Opus 5 khép vòng học trong CL-Bench.
2. Ít mà đúng hơn nhiều mà sai. Fable 5 với 9 file và một global.md đi xa hơn Sonnet 3.7 với 413 file trong 225 thư mục.
3. Đừng ra quy tắc cứng cho model mạnh. Nói “có thư mục memory” là đủ với Opus 4.7 trở lên; quy tắc “chỉ ghi thất bại” làm Opus 5 mất 0,234 điểm tăng trưởng. Hướng dẫn tường minh chỉ thực sự giúp model yếu — Sonnet 4.6 gần như tăng gấp đôi khi được nhắc đọc memory và kiểm chứng giả thuyết.
4. Ghi chú sai là lỗi hệ thống, không phải lỗi model. Một ghi chú sai vị trí PokéCenter đủ làm cả lần chạy rơi vào vòng lặp ba lần rồi bỏ cuộc. Cách sửa là đối chiếu transcript, không phải nhắc agent “nhớ cho kỹ”.
5. Wiki chỉ có giá trị khi đi cùng search và khi task cần tổng hợp. Wiki một mình sau 128 phiên đạt 48%, dưới search một mình (53%); kết hợp cả hai đạt 61% và tiết kiệm khoảng 20.000 token mỗi câu hỏi.
6. Lớp nạp sẵn phải nhỏ và làm nhiệm vụ mục lục. Claude Code chỉ nạp 200 dòng đầu hoặc 25 KB của MEMORY.md. Nhồi thêm vào đó không làm agent nhớ tốt hơn, mà làm nó tuân thủ kém đi.
7. Song song hoá cần một writer một trang. Nhiều agent cùng ghi vào một bảng chung ghi đè lẫn nhau, mất 16 trên 57 fact; tách mỗi hợp đồng thành một trang riêng, một agent viết, trích nguyên văn, đạt 100%.

Phạm vi kiểm chứng

Bài viết kiểm chứng ngày 7/11/2026 với bài gốc của Anthropic, “The components of agent memory”, tác giả Lance Martin, đăng ngày 6/11/2026. Các số liệu CL-Bench đọc từ chú thích của biểu đồ trong bài gốc (Opus 5.5 0,655 → 0,838; Sonnet 5.5 0,644 → 0,833; Opus 5 0,564 → 0,828; Opus 4.7 0,383 → 0,700; Sonnet 5 0,306 → 0,610; Sonnet 4.6 0,330 → 0,364), đối chiếu với bản tóm tắt của ExplainX. Số liệu Pokémon, wiki và các chi tiết về dreaming đều lấy trực tiếp từ bài gốc.

Bài gốc là nghiên cứu thiết kế, không phải thông báo sản phẩm: Anthropic không tuyên bố Claude Code đang dùng dreaming, và bài viết này cũng không claim điều đó. Các thí nghiệm chạy trên Claude Managed Agents; tính năng auto memory của Claude Code (nạp 200 dòng đầu hoặc 25 KB của MEMORY.md) được bài gốc trích dẫn như một ví dụ về lớp injected context, không phải bằng chứng dreaming đã có trong sản phẩm. Nhịp chạy và chi phí của dreaming còn là câu hỏi mở theo chính Anthropic. Mọi số liệu đều là đánh giá nội bộ của Anthropic, chưa có đo lường độc lập; thí nghiệm Pokémon so sánh một lần chạy mỗi model. Các con số như 0,655 hay 20.000 token là kết quả đo trong điều kiện thí nghiệm của Anthropic, không phải benchmark hay thông số cấu hình. Bài viết không chạy lại bất kỳ thí nghiệm nào, không test Claude Code với dreaming, và không đo hiệu năng trên môi trường của tác giả.