- Hermes Agent không có một 'bộ nhớ' duy nhất - nó có ba tầng hoạt động ở ba tốc độ khác nhau.
- Tầng 1 là hai file Markdown nhỏ luôn nằm trong context.
- Tầng 2 là SQLite FTS5 cho phép tìm kiếm toàn văn lịch sử hàng tuần.
- Tầng 3 là 8 external memory provider kết nối thêm khi cần.
TL;DR
Hermes Agent giải quyết vấn đề "agent quên mọi thứ" bằng ba tầng memory độc lập. Tầng 1: hai file Markdown nhỏ (tổng 3,575 chars) luôn inject vào system prompt mỗi session. Tầng 2: SQLite với FTS5 lưu toàn bộ conversation - tìm kiếm ngược lại hàng tuần. Tầng 3: 8 external provider (Mem0, Zep, Letta...) cho deep persistent memory. Ba tầng phục vụ ba nhu cầu khác nhau - cùng hoạt động song song, không thay thế nhau.
Vấn đề gốc rễ - tại sao agent cứ quên?
Mọi AI agent hiện nay đều có cùng kiến trúc cơ bản: nhận input, xử lý trong context window, trả output, reset. Khi session kết thúc, context window xóa sạch. Không có cơ chế nào tự động lưu lại những gì đã học.
Hậu quả thực tế: bạn đã giải thích project conventions cho agent vào thứ Hai, thứ Ba nó lại hỏi y chang câu đó. Bạn đã mất 20 phút debug một lỗi với agent hôm qua, hôm nay nó lặp lại đúng sai lầm đó. Mỗi session là một tờ giấy trắng mới.
Hermes giải quyết điều này không phải bằng cách tăng context window (giải pháp tốn kém và không bền vững) mà bằng cách thiết kế ba tầng memory có mục đích rõ ràng.
Tầng 1 - Hai file Markdown nhỏ, luôn có mặt
Tầng cốt lõi nhất của Hermes chỉ là hai file text đơn giản lưu trên disk:
- MEMORY.md (tối đa 2,200 chars): ghi chú của agent về environment, project conventions, tool quirks, và lessons learned
- USER.md (tối đa 1,375 chars): profile của bạn - tên, communication preferences, skill level, những thứ cần tránh
Cả hai đều được inject vào system prompt như một frozen snapshot khi session bắt đầu. Nếu agent viết thêm memory entry trong lúc đang chat, thay đổi đó ghi xuống disk ngay lập tức nhưng chỉ xuất hiện trong system prompt ở session tiếp theo.
Khi memory gần đầy (khoảng 80% capacity - hiển thị phần trăm trong system prompt header), agent phải consolidate: merge các entry liên quan thành phiên bản dense hơn, chỉ giữ lại thông tin thực sự có giá trị. Đây là cách Hermes maintain tầng memory nhỏ nhưng luôn relevant.
Ưu điểm của tầng này: luôn có mặt trong context, zero latency. Nhược điểm: dung lượng rất nhỏ, chỉ đủ cho facts quan trọng nhất.
Tầng 2 - SQLite FTS5, tìm kiếm toàn lịch sử
Mọi conversation của Hermes - dù qua CLI hay messaging platform - đều được lưu vào SQLite database với full-text search (FTS5). Agent có thể tìm kiếm ngược lại hàng tuần conversation từ cơ sở dữ liệu này.
File này nằm tại ~/.hermes/state.db - WAL-mode safe, FTS5-indexed. Đây là thứ khiến câu hỏi "chúng ta đã thảo luận về X ba tuần trước" thực sự có thể trả lời được.
Trade-off rõ ràng giữa Tầng 1 và Tầng 2:
- Tầng 1: luôn có trong context nhưng dung lượng cực nhỏ
- Tầng 2: dung lượng không giới hạn nhưng cần active search + LLM summarization mỗi khi truy xuất
Nguyên tắc thiết kế: critical facts sống ở Tầng 1, mọi thứ khác searchable theo nhu cầu từ Tầng 2.
Tầng 3 - 8 external memory provider
Với những trường hợp cần deep persistent memory vượt ra ngoài SQLite local, Hermes ship với 8 pluggable provider chạy song song với built-in memory (không thay thế). Chỉ một provider có thể active tại một thời điểm.
Khi bất kỳ external provider nào được kích hoạt, Hermes tự động:
- Prefetch relevant memories trước mỗi turn
- Sync conversation turns sau mỗi response
- Extract memories khi session kết thúc
Tám provider bao gồm các options như Mem0, Zep, Letta và các dịch vụ tương tự - mỗi provider có profile phù hợp khác nhau về latency, pricing và loại memory được lưu trữ.
Ba tầng hoạt động cùng nhau như thế nào
Hãy hình dung một workflow cụ thể: bạn debug một lỗi phức tạp liên quan đến database migration.
- Tầng 1 inject ngay vào context: "Project dùng PostgreSQL 16, không dùng ORMnative, convention viết raw SQL với named params." Fact này quan trọng và hay dùng - xứng đáng có mặt trong mọi session.
- Tầng 2 được query khi agent nhận ra vấn đề liên quan: "Tuần trước chúng ta đã debug vấn đề deadlock tương tự..." và tóm tắt context từ session cũ để đưa vào conversation hiện tại.
- Tầng 3 (nếu enable) prefetch thêm context từ external system - ví dụ Mem0 có thể pull ra patterns agent đã học về codebase này từ nhiều tuần trước.
Sau khi fix xong, agent tự viết skill mới: quy trình debug database migration cụ thể cho project này. Skill đó sống trong ~/.hermes/skills/ và là một dạng memory thứ tư - nhưng đây là procedural memory (cách làm việc), khác với factual memory ở ba tầng trên.
Kết
Ba tầng memory của Hermes không phải là over-engineering. Mỗi tầng giải quyết một trade-off khác nhau: tốc độ vs dung lượng, local vs distributed, factual vs procedural. Thiết kế này cho phép Hermes hoạt động hiệu quả ngay cả với RAM hạn chế trong khi vẫn có khả năng tra cứu lịch sử sâu khi cần.
Bài tiếp theo trong series sẽ đi vào phần thú vị nhất: Self-Evolving Skills và GEPA - cách Hermes tự viết playbook, tự dọn dẹp skill library, và tối ưu skills offline bằng phương pháp vượt trội hơn reinforcement learning mà không cần một GPU nào.