Memory agent không chỉ là vector DB

EverOS đáng chú ý không vì thêm một kho nhớ mới, mà vì ép team builder quyết định: memory nên là dữ liệu có thể sửa, hay chỉ là index để gọi lại?

“Agent của mình hôm qua nhớ khách thích báo cáo ngắn. Sáng nay nó lại trình bày như luận văn.”

Nếu bạn từng nghe câu này trong một buổi review demo nội bộ, xin chia buồn: bạn không gặp lỗi prompt, bạn gặp lỗi memory substrate — lớp nền nơi trí nhớ của agent được ghi, tìm lại, sửa và kiểm tra. Prompt chỉ là thế thủ mở đầu. Vào đối luyện thật, agent không có trí nhớ tử tế thì vài hiệp là lộ ngay.

EverOS xuất hiện đúng vào chỗ đau đó: một runtime open-source cho memory của AI agent, lưu trí nhớ dưới dạng Markdown, index bằng SQLite và LanceDB, tìm kiếm lai giữa BM25 và vector search, rồi tách memory phía user với memory phía agent. Nhưng điểm đáng bàn không phải là “lại có tool mới”. Điểm đáng bàn là: team bạn có muốn memory trở thành tài sản vận hành được, hay chỉ là thứ nằm sâu trong vector database và cầu mong nó trả đúng?

Sơ đồ tóm tắt ý chính của bài viết.

Chuyện đang diễn ra: memory đang bị hiểu quá hẹp

Nhiều team xây agent bắt đầu bằng công thức quen tay:

1. Lưu chat history.
2. Chunk nội dung.
3. Embed vào vector database.
4. Khi cần thì retrieve vài đoạn liên quan.

Cách này ổn cho bản demo. Nhưng khi agent chạy nhiều phiên, nhiều user, nhiều nhiệm vụ lặp lại, “nhớ lại đoạn giống giống” không còn đủ.

Long-term memory là lớp bộ nhớ dài hạn giúp agent nhớ thông tin qua nhiều phiên làm việc. Với builder, nó ảnh hưởng trực tiếp tới ba câu hỏi:

• Agent nhớ cái gì?
• Ai được sửa phần nhớ sai?
• Khi agent hành xử kỳ lạ, bạn debug từ đâu?

EverOS chọn một hướng khá rõ: mỗi record memory là file .md. Bạn có thể mở bằng editor, grep, sửa tay, đưa vào Git, hoặc xem bằng Obsidian. Đây không chỉ là sở thích Markdown. Đây là một quyết định kiến trúc: source of truth là file đọc được bởi người, còn index chỉ là lớp phục vụ truy vấn.

Nói thẳng ra thì, EverOS đang kéo memory ra khỏi hộp đen.

Bóc lớp đầu: Markdown-first không phải để nhìn cho sạch

Markdown-first nghĩa là memory được ghi thành tài liệu văn bản có cấu trúc nhẹ, thay vì chỉ tồn tại như vector hoặc JSON khó đọc. Với agent, điều này có hai tác dụng.

Thứ nhất, nó làm memory có thể audit. Nếu agent nhớ sai rằng khách hàng A “luôn muốn email tiếng Anh”, bạn có thể mở file và sửa. Không cần viết script xóa embedding, re-ingest toàn bộ, rồi hy vọng query sau tốt hơn.

Thứ hai, nó giúp memory có đời sống ngoài runtime. File Markdown có thể đi qua code review, version control, migration, backup. Với team Việt Nam đang build AI cho CRM, chăm sóc khách hàng, phân tích tài liệu nội bộ, đây là điểm rất thực dụng: người vận hành không nhất thiết phải biết vector database mới kiểm tra được agent đang nhớ gì.

Ví dụ cụ thể: giả sử team bạn làm agent hỗ trợ account manager. User-side memory có thể lưu:

# Profile: Khách hàng Minh An

## Facts
- Ưu tiên báo cáo theo tuần, không theo ngày.
- Không muốn nhận file Excel nếu đã có dashboard.

## Episodes
- 2026-06-12: Phàn nàn vì agent gửi lại câu trả lời quá dài.

## Foresights
- Khi gửi cập nhật, nên bắt đầu bằng 3 bullet chính.

Nếu dữ liệu này nằm trong một vector store thuần túy, nó giống như võ sinh bị bịt mắt: vẫn phản xạ được, nhưng bạn khó biết cú đánh đến từ bài tập nào. Markdown giúp team xem lại bài quyền.

Bóc lớp hai: hybrid retrieval là để giảm sai pha, không để trang trí

EverOS dùng hybrid retrieval — truy xuất lai — kết hợp BM25, vector search và scalar filtering trong một query.

• BM25: tìm kiếm theo từ khóa truyền thống, mạnh khi câu hỏi có cụm từ cụ thể như mã khách hàng, tên module, thuật ngữ nội bộ.
• Vector search: tìm theo ngữ nghĩa, hữu ích khi user diễn đạt khác nhưng ý giống nhau.
• Scalar filtering: lọc theo metadata như user_id, project_id, thời gian, loại memory.

Điểm này đáng chú ý vì memory của agent không giống search web. Bạn không chỉ cần đoạn “có vẻ liên quan”; bạn cần đúng người, đúng phiên, đúng loại trí nhớ.

Hình dung thế này: agent hỗ trợ hai khách hàng đều tên “An”, một người ghét email dài, một người lại thích phân tích chi tiết. Vector search có thể kéo nhầm nếu chỉ dựa vào ngữ nghĩa. Scalar filter theo customer_id là đòn chặn tối thiểu. BM25 giúp bắt đúng thuật ngữ. Vector search giúp không bỏ sót diễn đạt mềm hơn.

Qdrant Edge cũng đang đẩy một hướng gần kề: vector search chạy on-device cho các tình huống cần memory ở gần nơi dữ liệu phát sinh, như robot hoặc thiết bị riêng tư. Tín hiệu chung không phải là “vector ở đâu cũng thắng”, mà là retrieval đang dịch chuyển về gần workflow thật hơn: có lúc ở server, có lúc ở edge, có lúc nằm cạnh file Markdown.

Bóc lớp ba: Cases và Skills mới là phần dễ bị hype quá tay

EverOS tách memory thành hai đường: user-side memory gồm Profiles, Episodes, Facts, Foresights; agent-side memory gồm Cases và Skills.

Skill ở đây có thể hiểu là trí nhớ thủ tục: agent rút ra cách làm lặp lại được từ các case trước. Ví dụ sau vài lần xử lý ticket billing, agent học được quy trình: kiểm tra invoice ID, đối chiếu plan, xem lịch sử downgrade, rồi mới đề xuất phản hồi.

Đây là phần hấp dẫn nhất, nhưng cũng là phần cần giữ tay. Self-evolving skills — kỹ năng tự tiến hóa — nghe rất đã với demo, nhưng trong production bạn phải hỏi:

• Skill mới có cần approval trước khi dùng không?
• Skill cũ bị sai thì rollback thế nào?
• Skill được học từ một khách hàng có được áp dụng sang khách hàng khác không?
• Ai chịu trách nhiệm khi agent “học” một shortcut nguy hiểm?

Benchmark do vendor tự báo cáo có thể là tín hiệu ban đầu, không nên là quyết định cuối. Với memory runtime, benchmark truy xuất chỉ đo một phần. Thứ cần test thêm là drift của memory, quyền sửa, khả năng rollback, và hành vi khi dữ liệu mâu thuẫn.

Trong dojo, lên đai không phải vì thuộc nhiều thế, mà vì biết lúc nào không nên ra đòn. Agent cũng vậy.

Framework quyết định: dùng, chờ, hay bỏ qua?

Nếu bạn đang cân nhắc EverOS hoặc một runtime memory tương tự, mình sẽ không hỏi “tool này có hay không”. Mình sẽ hỏi bốn biến sau.

| Câu hỏi | Nếu câu trả lời là có | Nếu câu trả lời là không |
|---|---|---|
| Memory có cần người sửa tay không? | Markdown-first đáng thử | Vector DB thuần có thể đủ |
| Agent có chạy qua nhiều phiên/user không? | Cần tách profile, facts, episodes | Chat history đơn giản có thể sống được |
| Có yêu cầu local-first không? | EverOS/Qdrant Edge đáng xem | Managed memory service có thể nhanh hơn |
| Skill tự học có ảnh hưởng quyết định thật không? | Cần approval, audit, rollback | Có thể để ở mức gợi ý nội bộ |

Khuyến nghị thực dụng:

Nên thử EverOS nếu bạn đang build agent có memory dài hạn, cần inspect bằng mắt, muốn self-host hoặc local-first, và team đã đủ kỷ luật để review memory như review config.

Nên chờ nếu pipeline agent của bạn vẫn chưa ổn định, prompt còn đổi mỗi ngày, schema nghiệp vụ chưa rõ. Memory runtime lúc này có thể chỉ làm bạn lưu lại nhiều rác hơn.

Nên bỏ qua tạm thời nếu bài toán của bạn chủ yếu là search tài liệu tĩnh. Khi đó, đầu tư vào parsing, chunking, evaluation và retrieval pipeline có thể đáng hơn. LiteParse thêm Markdown cho PDF-to-Markdown là một tín hiệu cùng hướng: trước khi nói memory thông minh, hãy đảm bảo đầu vào có cấu trúc đủ sạch.

Một buổi để kiểm chứng, không cần cưới ngay

Bạn có thể test quyết định này trong một buổi, không cần thay cả stack.

1. Chọn một workflow có lặp lại

Ví dụ: agent hỗ trợ support ticket, agent viết release note, hoặc agent tóm tắt cuộc họp khách hàng.

1. Viết 10 memory record bằng Markdown

Chia rõ Facts, Episodes, Foresights. Đừng embed vội. Mở file ra xem người vận hành có hiểu không.

1. Tạo 10 câu query đối nghịch

Gồm câu có keyword chính xác, câu diễn đạt vòng vo, câu cố tình gây nhầm giữa hai user.

1. So BM25-only, vector-only, hybrid

Không cần benchmark hoành tráng. Chỉ cần ghi: query nào trả đúng, query nào kéo nhầm, query nào cần filter.

1. Giả lập memory sai

Sửa một fact thành sai, rồi xem quy trình phát hiện và rollback mất bao lâu. Đây mới là bài test production.

Nếu sau bài test, điểm đau lớn nhất của bạn là “khó biết agent đang nhớ gì”, EverOS đáng đưa vào shortlist. Nếu điểm đau vẫn là “agent chưa làm đúng bước cơ bản”, quay lại orchestration — cách điều phối nhiều bước và tool — trước đã.

Điều nên giữ lại, điều nên bỏ qua

Điều đáng giữ từ EverOS không phải là tên framework. Đó là một nguyên tắc: memory của agent nên là vật thể vận hành được. Đọc được, sửa được, version được, lọc được, và có biên giới rõ giữa trí nhớ về user với kỹ năng của agent.

Điều nên bỏ qua là cảm giác phải chạy theo mọi release memory mới. Agent không cần thêm trí nhớ nếu team chưa biết sẽ quên cái gì, nhớ cái gì, và ai được quyền sửa ký ức đó.

Sau bài này, mình mong bạn đổi một câu hỏi: đừng hỏi “nên dùng vector database nào cho memory?”, hãy hỏi “memory của agent có đủ minh bạch để team chịu trách nhiệm chưa?”. Đai đen của agent không nằm ở việc nhớ nhiều, mà ở chỗ nhớ đúng và chịu cho người kiểm tra.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng