đang phân tích cuộc tranh luận hiện tại về "filesystem vs database" cho bộ nhớ của agent: hiện tại tôi thấy có 2 trường phái trong cách chúng ta xây dựng bộ nhớ của agent. một bên, chúng ta có trường phái "giao diện tệp là tất cả những gì bạn cần". bên kia, chúng ta có trường phái "filesystem chỉ là cơ sở dữ liệu tồi". "giao diện tệp là tất cả những gì bạn cần". những người dẫn đầu như anthropic, letta, langchain & llamaindex đang nghiêng về giao diện tệp vì "các tệp thực sự hiệu quả như bộ nhớ của agent". • công cụ bộ nhớ của anthropic coi bộ nhớ như một tập hợp các tệp (việc triển khai lưu trữ được để cho nhà phát triển quyết định) • công cụ xây dựng agent của langsmith cũng đại diện cho bộ nhớ dưới dạng một tập hợp các tệp (dữ liệu được lưu trữ trong một cơ sở dữ liệu và các tệp được cung cấp cho agent như một filesystem) • letta cho biết rằng các công cụ filesystem đơn giản như grep và ls đã vượt trội hơn các công cụ bộ nhớ hoặc truy xuất chuyên dụng trong các bài kiểm tra của họ • llamaindex lập luận rằng đối với nhiều trường hợp sử dụng, một filesystem được tổ chức tốt với tìm kiếm ngữ nghĩa có thể là tất cả những gì bạn cần các agent rất giỏi trong việc sử dụng filesystem vì các mô hình được tối ưu hóa cho các tác vụ lập trình (bao gồm cả các thao tác CLI) sau khi đào tạo. đó là lý do tại sao chúng ta thấy một mô hình "filesystem ảo" nơi giao diện agent và việc triển khai lưu trữ được tách rời. "filesystem chỉ là cơ sở dữ liệu tồi". nhưng sau đó bạn có những tiếng nói như dax từ opencode người đã chỉ ra rằng "một filesystem chỉ là loại cơ sở dữ liệu tồi nhất". swyx và các đồng nghiệp trong lĩnh vực cơ sở dữ liệu cảnh báo về việc vô tình tái phát minh các cơ sở dữ liệu bằng cách giải quyết vấn đề bộ nhớ của agent. Tránh viết các phiên bản tồi hơn của: • chỉ mục tìm kiếm, • nhật ký giao dịch, • cơ chế khóa, các sự đánh đổi...