🧠 Khi AI vẫn nhớ mà hành động như đã quên

Có lẽ vấn đề của một trợ lý AI làm việc lâu không chỉ là bộ nhớ ngắn. Đôi khi thông tin vẫn còn nguyên trong cuộc trò chuyện, nhưng đã thôi điều khiển hành vi. Một nghiên cứu mới của Meta AI gọi hiện tượng ấy là behavioral state decay — sự suy giảm trạng thái hành vi — và đề xuất một “người giữ ký ức” biết khi nào nên nhắc, khi nào nên im lặng.

Hãy hình dung người thợ phát hiện đường ống sau bức tường bị lệch và ghi vào sổ. Sau hàng chục việc nhỏ, anh lại khoan đúng chỗ ấy. Cuốn sổ không mất; nhưng vào khoảnh khắc cần thiết, ghi chú không còn ảnh hưởng đến quyết định.

Agent AI làm việc dài hơi cũng “quên” như vậy: đọc đúng một yêu cầu rồi vi phạm nó khi sửa lỗi khác; đã thấy một lệnh thất bại nhưng sau đó lại thử gần như y hệt; từng chẩn đoán đúng, rồi coi cùng tín hiệu lỗi như hoàn toàn mới.

Nhóm Yifan Wu và cộng sự tại Meta AI đặt cho thất bại ấy một cái tên khá chính xác: behavioral state decay. Trong bài báo Remember When It Matters: Proactive Memory Agent for Long-Horizon Agents, họ không hỏi đơn thuần “AI lưu được bao nhiêu?”, mà hỏi một câu khó hơn: ký ức nào phải được đưa trở lại đúng lúc để thật sự thay đổi hành động kế tiếp?

“Có trong ngữ cảnh” chưa có nghĩa là “đang có tác dụng”

Điểm hay nhất của bài báo, theo em, nằm ở sự phân biệt này.

Một thông tin có thể vẫn nằm trong transcript, thậm chí chưa bị đẩy khỏi cửa sổ ngữ cảnh, nhưng không còn tạo ra sức ép đáng tin cậy lên lựa chọn tiếp theo của mô hình. Tác giả gọi những thứ cần tiếp tục chi phối hành vi là execution state — trạng thái thực thi: yêu cầu của nhiệm vụ, dữ kiện về môi trường, những cách đã thử, nguyên nhân thất bại, phát hiện trung gian và các mục tiêu con còn dang dở.

Một bác sĩ không chỉ cần hồ sơ “có lưu” tiền sử dị ứng; thông tin ấy phải hiện diện đúng lúc kê thuốc. Khác biệt giữa lưu trữ và kiểm soát hành vi cũng là khác biệt giữa kho hồ sơ và trí nhớ hữu dụng.

Các hệ memory trước đây thường tập trung vào viết và truy xuất. Nhưng trong nhiệm vụ đang chạy, quá ít ký ức khiến agent lặp lỗi; quá nhiều lại tốn token, tăng độ trễ và gây phân tâm. Memory vì thế còn là bài toán can thiệp khi nào.

Một agent làm việc, một agent đứng bên cạnh giữ mạch

Kiến trúc của nhóm nghiên cứu khá trực quan. Action agent vẫn làm nhiệm vụ như cũ: gọi công cụ, quan sát phản hồi, sửa code, trò chuyện với người dùng hoặc thao tác trong môi trường. Mô hình này không bị sửa đổi. Bên cạnh nó là một memory agent riêng, theo dõi quỹ đạo gần đây và duy trì một ngân hàng ký ức có cấu trúc.

Ngân hàng ấy gồm ba phần:

• Status riêng tư: cách memory agent nhìn tiến độ, vấn đề chưa giải quyết và rủi ro còn mở. Phần này không được đưa cho action agent, để không làm bẩn ngữ cảnh làm việc.
• Knowledge memory: những dữ kiện tương đối ổn định như yêu cầu nhiệm vụ, thuộc tính môi trường, đường dẫn tệp, cấu hình, chi tiết API hay quan sát quan trọng đã được xác minh.
• Procedural memory: lịch sử thử-và-kết-quả — lệnh nào thất bại, cách sửa nào thành công, giả thuyết nào đã bị bác bỏ, tín hiệu chẩn đoán nào cần giữ lại.

Mỗi lần được kích hoạt, memory agent làm hai pha. Pha 1 dùng các thao tác rõ ràng để cập nhật trạng thái, lưu tri thức, lưu kinh nghiệm hoặc xóa mục lỗi thời — không tùy tiện viết lại lịch sử thành tóm tắt tự do. Pha 2 chọn gửi một lời nhắc ngắn, có căn cứ vào lần gọi action agent kế tiếp, hoặc không can thiệp.

Im lặng là một hành động hạng nhất. Memory chỉ nên lên tiếng khi yêu cầu sắp bị vi phạm, cách làm thất bại sắp bị lặp, chẩn đoán còn hiệu lực hoặc mục tiêu con bị bỏ quên; nó không nên biến thành “quân sư toàn năng”.

Trong thí nghiệm chính, memory agent chạy ở bước đầu và sau đó ở mỗi bước, nhìn cửa sổ gần nhất gồm 8 message, cùng mô tả nhiệm vụ và ngân hàng hiện tại. Bài báo cũng nêu khả năng kích hoạt chọn lọc hơn — chẳng hạn sau lỗi công cụ, test thất bại hoặc lệnh bị lặp — nhưng chưa kiểm nghiệm nó trong thiết lập chính.

Kết quả: lời nhắc đúng lúc có thể đổi tỷ lệ hoàn thành

Nhóm thử kiến trúc trên hai loại công việc. Terminal-Bench 2.0 gồm các nhiệm vụ terminal thực tế: đọc tệp, chạy lệnh, sửa code, gỡ lỗi và vượt qua bộ kiểm tra ẩn. Bộ này có 89 nhiệm vụ, nhưng kết quả chính dùng 85 cặp chạy hợp lệ, loại bốn lỗi Docker không liên quan đến hành vi agent. τ²-Bench kiểm tra agent hội thoại dùng công cụ trong ba miền dịch vụ — hàng không, bán lẻ và viễn thông — tổng cộng 278 nhiệm vụ: 50, 114 và 114.

Tất cả số dưới đây là pass@1, tức tỷ lệ thành công của một lần chạy; mức tăng được tính bằng điểm phần trăm, không phải phần trăm tương đối. Memory agent trong bảng chính là Claude Opus 4.6.

• 58,8 − 49,1 = 9,7 nếu trừ các số đã làm tròn; Table 1 của bài báo in +9,6 pp, nên bài này giữ nguyên con số chính thức và ghi rõ sai lệch làm tròn/biên tập đó.

Lợi ích lớn hơn với Sonnet 4.5, nhưng không biến mất khi action agent đã là Opus 4.6. Điều này gợi ý memory không chỉ bù cho một mô hình yếu. Tuy vậy, hiệu quả phụ thuộc miền: với Opus ở airline, điểm số không đổi; với Sonnet, airline và retail tăng mạnh hơn telecom.

Ví dụ định tính cho thấy memory nhắc agent tin hồ sơ Regular đã được công cụ xác minh thay vì lời tự nhận Gold của người dùng; đưa điều khoản “vé basic economy không thể sửa” trở lại trước thao tác; và giữ ràng buộc, chẩn đoán hay lần sửa thất bại xuyên qua nhiều vòng debug.

Table 2 nói gì: không phải cứ nhắc nhiều là tốt

Ablation trên τ²-Bench dùng Sonnet 4.5 làm action agent và Opus 4.6 làm memory agent. Bảng này là một loạt chạy riêng: vì vậy, cấu hình “full” có retail 57,0% và micro 61,2%, khác kết quả chính 58,8% và 61,8% ở Table 1. Không nên trộn hai bảng như cùng một phép đo.

Trong Table 2, baseline có macro 57,5%, micro 55,0%. Hệ đầy đủ đạt 64,3% macro và 61,2% micro, đồng thời tăng cả ba miền: airline 78,0%, retail 57,0%, telecom 57,9%.

Khi quản lý memory nhưng phơi toàn bộ ngân hàng vào ngữ cảnh mỗi bước, hệ đạt 61,5% macro và 58,6% micro — thấp hơn hệ đầy đủ lần lượt 2,8 và 2,6 điểm. Khi buộc phải nhắc ở mọi bước, điểm macro là 63,5%, micro 61,5%. Nó hơn hệ chọn lọc 0,3 điểm micro, nhưng tác giả cho rằng mức này nằm trong biến thiên kỳ vọng; xét macro cân bằng ba miền, khả năng im lặng vẫn tốt hơn.

Biến thể chỉ can thiệp, không có ngân hàng bền vững đạt 61,0% macro và 60,8% micro. Nó làm telecom tăng đến 66,7% nhưng kéo airline xuống 62,0%, thấp hơn baseline 68,0% — một dấu hiệu rằng lời khuyên không được neo vào trạng thái đã duy trì có thể thiếu ổn định. Mem0, dùng ADD rồi truy xuất vector+BM25 top-10, đạt 62,1% macro và 60,8% micro; nó cải thiện trung bình nhưng không nâng airline khỏi 68,0%.

Table 2 không chứng minh chọn lọc thắng mọi chỉ số: “always inject” nhỉnh hơn micro. Kết luận đúng mức là duy trì trạng thái cộng với chọn lọc thời điểm cho cải thiện cân bằng nhất giữa các miền; retrieval hay phơi toàn bộ memory chưa giải quyết được bài toán điều khiển.

Có thể huấn luyện một “người giữ mạch” open-weight không?

Gọi Opus 4.6 ở mỗi bước memory là tốn kém. Vì thế nhóm thử huấn luyện Qwen3.5-27B làm memory agent, trong khi giữ nguyên action agent Qwen3.5-122B-A10B. Họ dùng SETA cho supervised fine-tuning (SFT) và reinforcement learning bằng GRPO; Terminal-Bench được giữ lại để kiểm tra chuyển giao.

SFT bắt chước các trajectory từ memory agent được prompt, dạy cả thao tác ngân hàng ở Pha 1 lẫn quyết định nhắc/im lặng ở Pha 2. Sau đó GRPO tối ưu hiệu quả hạ nguồn. Vì reward từ verifier ở cấp nhiệm vụ rất thưa so với số lần memory được gọi, cập nhật tập trung vào các pivot turn được rollout offline gắn nhãn là có khả năng ảnh hưởng thành công.

Kết quả SETA cho thấy model nền chưa huấn luyện không chỉ vô ích mà còn gây hại: reward giảm từ 0,709, 56 bài giải được xuống 0,693, 54 bài. SFT đưa reward lên 0,720, 58 bài; GRPO lên 0,734, vẫn 58 bài. Trên 85 nhiệm vụ Terminal-Bench giữ lại, memory agent đã huấn luyện nâng pass@1 của action agent từ 37,6% lên 41,1%, tức +3,5 điểm phần trăm.

Đây mới là bằng chứng ban đầu: bài báo chưa cho thấy model open-weight đạt mức của Opus memory, hay chuyển giao rộng ngoài các môi trường terminal liên quan.

Cái giá của việc nhớ — và của việc nhắc sai

Kiến trúc plug-and-play là ưu điểm thực dụng: không phải sửa action model hay harness nền, chỉ thêm context tạm thời khi cần. Nhưng không có bữa trưa miễn phí. Một memory agent riêng tạo thêm lượt suy luận, token và độ trễ; trong thí nghiệm chính nó còn chạy mỗi bước. Bài báo không đưa bảng chi phí tiền, token hay latency, nên ta không thể kết luận mức tăng pass@1 có lợi về kinh tế trong triển khai thật.

Can thiệp cũng có thể sai. Phân tích thất bại ghi nhận memory agent đôi lúc nói một suy đoán với độ chắc chắn quá cao, lặp lại điều action agent đã biết, hoặc nêu một lo ngại hợp lý nhưng không cần thiết khiến agent xác minh thêm. Nói cách khác, vấn đề còn lại chủ yếu là calibration: biết lúc nào im lặng.

Hướng mở gồm huấn luyện chung hai agent, học trigger và chọn giữa nhắc nguyên văn với trừu tượng hóa. Với một lần chạy mỗi task, hai benchmark và vài họ model, chưa thể kỳ vọng mọi agent dài hạn tăng tương tự.

Bài học thực hành cho người xây agent

Nếu rút nghiên cứu này thành vài nguyên tắc triển khai, em sẽ giữ năm điều:

1. Theo dõi trạng thái thực thi, đừng chỉ tóm tắt hội thoại. Tách ràng buộc ổn định khỏi lịch sử thử-sai và khỏi ghi chú tiến độ nội bộ.
2. Cho phép sửa và xóa. Memory lỗi thời mà không thể cập nhật có thể nguy hiểm hơn không nhớ.
3. Nhắc ngắn, cụ thể, có nguồn từ trạng thái đã lưu. “Đừng làm vậy vì lệnh X đã thất bại với lỗi Y” hữu dụng hơn lời khuyên chiến lược chung chung.
4. Biến im lặng thành lựa chọn hạng nhất. Đánh giá cả tác hại của nhắc thừa, không chỉ tỷ lệ truy xuất đúng.
5. Đo end-to-end và đo chi phí. Memory tốt không phải memory viết đẹp; nó phải cải thiện verifier/task success đủ để bù token, latency và nguy cơ can thiệp sai.

Điều em thấy sâu ở bài báo là: trí nhớ không nằm trọn trong kho dữ liệu, mà trong mối liên hệ giữa quá khứ và hành động đúng lúc. Agent dài hạn không chỉ cần cửa sổ ngữ cảnh lớn hơn; nó cần giữ điều quan trọng đủ gần để có sức nặng — và đủ khiêm tốn để không biến ký ức thành tiếng ồn.

Nguồn

• Bài báo: Remember When It Matters: Proactive Memory Agent for Long-Horizon Agents — Yifan Wu và cộng sự, Meta AI, 2026.
• Mã nguồn: github.com/yifannnwu/proactive-memory-agent
• Benchmark SETA được bài báo sử dụng: github.com/camel-ai/seta