Một trong những hạn chế lớn nhất của AI Agent hiện nay không nằm ở khả năng suy luận hay độ chính xác của mô hình, mà lại đến từ một vấn đề đơn giản hơn nhiều: agent không nhớ gì sau khi kết thúc phiên làm việc. Mỗi lần khởi động một phiên mới, agent bắt đầu hoàn toàn từ đầu, không biết mình đã làm gì trước đó, không biết người dùng đã cung cấp thông tin gì, cũng không biết tác vụ nào đang còn dang dở. Đây là vấn đề mà Kevin Chen, kỹ sư tại Anthropic, gọi thẳng là "bị cô lập theo mặc định" trong một workshop kỹ thuật vừa được công bố.
Tại sao vấn đề này lại nghiêm trọng?
Đối với những người chỉ nói chuyện với chatbot AI thông thường, điều này có thể không phải là vấn đề. Chatbot như Claude hay ChatGPT được thiết kế để trả lời câu hỏi trong một cuộc hội thoại duy nhất: người dùng hỏi, chatbot trả lời, cuộc hội thoại kết thúc và mọi thứ xóa sạch là hoàn toàn chấp nhận được. Tuy nhiên, AI Agent lại khác. Agent được xây dựng để thực hiện các tác vụ phức tạp kéo dài qua nhiều phiên làm việc, có thể chạy tự động mà không cần người dùng giám sát liên tục. Một agent quản lý dự án cần nhớ deadline nào đang chạy. Một agent nghiên cứu cần biết mình đã đọc tài liệu nào và rút ra kết luận gì từ tuần trước. Nếu không có bộ nhớ liên tục, dù mạnh đến đâu, agent cũng không thể đảm nhận vai trò cộng tác viên dài hạn mà chỉ là công cụ tra cứu một lần.
Giải pháp 4 bước từ Anthropic
Anthropic giải quyết bài toán này bằng một quy trình gồm 4 bước rõ ràng, xoay quanh hai tính năng mới là Memory Store và Dreaming.
Bước 1: Tạo Memory Store
Memory Store là kho lưu trữ dạng hệ thống tệp được gắn trực tiếp vào phiên làm việc khi khởi tạo. Điểm kỹ thuật đáng chú ý là Anthropic chọn cách tích hợp Memory Store như một hệ thống tệp thật thay vì một cơ sở dữ liệu thông thường. Nhờ đó, agent có thể dùng các lệnh tìm kiếm quen thuộc để truy xuất thông tin thay vì phụ thuộc vào một giao diện truy vấn riêng biệt. Mỗi tệp trong Memory Store đều được lưu theo phiên bản, nghĩa là mọi thay đổi đều có thể truy vết lại. Khi tạo Memory Store, lập trình viên chỉ cần đặt tên và mô tả ngắn, sau đó có thể xem toàn bộ nội dung qua giao diện trình duyệt tệp trực quan trên bảng điều khiển. Memory Store không bị giới hạn theo tổ chức mà có thể tạo riêng theo từng người dùng hoặc từng không gian làm việc tùy nhu cầu.
Bước 2: Gắn Memory Store vào phiên làm việc
Khi tạo phiên làm việc mới, lập trình viên truyền vào mã định danh của Memory Store cùng hai tham số quan trọng. Tham số thứ nhất là đoạn hướng dẫn tùy chọn để định hướng agent nên ghi nhớ loại thông tin gì, ví dụ chỉ tập trung vào các quyết định đầu tư hoặc các mốc tiến độ dự án. Tham số thứ hai là quyền truy cập, mặc định là đọc và ghi, nhưng có thể đặt về chỉ đọc nếu muốn agent tham chiếu thông tin mà không được phép ghi đè. Khi phiên làm việc chạy, agent sẽ tự động đọc Memory Store trước để kiểm tra ngữ cảnh liên quan, sau đó ghi thông tin mới vào cuối phiên. Agent cũng tự tổ chức thông tin theo cấu trúc thư mục con bên trong Memory Store, và người dùng có thể định hướng cấu trúc này thông qua hướng dẫn khi tạo phiên. Ngoài ra, người dùng hoàn toàn có thể chỉnh sửa tệp bộ nhớ thủ công nếu agent ghi thông tin sai hoặc cần bổ sung thêm ngữ cảnh.
Bước 3: Chạy Dreaming để tối ưu hóa bộ nhớ
Việc cho agent tự do ghi vào Memory Store theo thời gian dẫn đến một vấn đề mới: kho lưu trữ phình to không kiểm soát, thông tin trùng lặp tích tụ, dữ liệu cũ không còn chính xác vẫn tồn tại. Dreaming được thiết kế để giải quyết đúng vấn đề này. Đây là tiến trình xử lý hàng loạt chạy nền bất đồng bộ, hoạt động trên kiến trúc đa agent: một agent điều phối sẽ khởi chạy các agent con, mỗi agent con chịu trách nhiệm rà soát một bản ghi phiên làm việc. Khi khởi chạy Dreaming, lập trình viên chỉ định Memory Store cần xử lý, danh sách các phiên làm việc cần rà soát, mô hình sử dụng là Claude Opus 4.7 hoặc Sonnet 4.6 tùy yêu cầu chất lượng và ngân sách, cùng các hướng dẫn bổ sung nếu muốn Dreaming tập trung vào một loại thông tin cụ thể. Các agent con sau đó thực hiện kiểm tra tính xác thực, bổ sung chi tiết còn thiếu như ngày tháng và các mã định danh cụ thể, loại bỏ thông tin trùng lặp, đánh dấu dữ liệu đã lỗi thời, đồng thời tạo tệp mục lục tổng hợp giúp agent tương lai đọc nhanh thay vì phải tìm kiếm toàn bộ kho. Dreaming được thiết kế để xử lý toàn diện nên tiêu thụ lượng token đáng kể, nhưng Anthropic cho biết tỉ lệ truy xuất từ bộ đệm đạt khoảng 95% trên phần lớn các lần chạy. Công ty cũng đang nghiên cứu phương án giảm chi phí thêm 50% thông qua cơ chế lên lịch theo đợt, tương tự mô hình xử lý hàng loạt hiện có.
Bước 4: Xem xét, phê duyệt và thay thế Memory Store cũ
Một điểm thiết kế quan trọng là Dreaming không chỉnh sửa trực tiếp Memory Store gốc mà tạo ra một kho lưu trữ đầu ra hoàn toàn mới. Sau khi Dreaming hoàn tất, người dùng có thể xem toàn bộ thay đổi dưới dạng so sánh trực quan trên bảng điều khiển, bao gồm những tệp nào được tạo mới, những thông tin nào được bổ sung, những mục nào bị loại bỏ. Đây là bước kiểm soát của con người trong quy trình, cho phép phát hiện và sửa lỗi trước khi kho lưu trữ mới được đưa vào sử dụng. Khi đã hài lòng với kết quả, lập trình viên gắn kho lưu trữ đầu ra vào các phiên làm việc tiếp theo và có thể tùy chọn đánh dấu kho lưu trữ cũ là không còn hoạt động để giữ số lượng Memory Store trong tổ chức ở mức hợp lý. Thao tác này không ảnh hưởng đến các phiên làm việc cũ đã sử dụng kho lưu trữ gốc trước đó.
Kiến trúc ba lớp
Nhìn tổng thể, Kevin Chen mô tả kiến trúc này gồm ba lớp chồng lên nhau: phiên làm việc là đơn vị tạm thời và cô lập, Memory Store kết nối thông tin giữa các phiên, và Dreaming liên tục tối ưu hóa chất lượng bộ nhớ theo thời gian. Cách tiếp cận này giải quyết một vấn đề mà trước đây lập trình viên thường phải tự xử lý bằng cách nhồi toàn bộ ngữ cảnh vào đầu mỗi phiên mới, vừa tốn chi phí vừa không hiệu quả khi khối lượng thông tin tích lũy ngày càng lớn. Với Memory Store và Dreaming, bộ nhớ của agent không chỉ tồn tại liên tục mà còn tự cải thiện theo thời gian, biến agent thành trợ lý công việc đáng tin cậy hơn bao giờ hết.
