Vì sao OpenClaw cần tối ưu lại memory?

Có một hiểu nhầm khá phổ biến khi build trợ lý AI kiểu OpenClaw: nhiều người nghĩ cứ nhồi thêm memory là agent sẽ thông minh hơn. Thực tế thường ngược lại: memory càng phình, càng trùng lặp, càng thiếu phân tầng thì agent càng dễ trả lời loãng, chậm, lệch ưu tiên, thậm chí nhớ sai.

Với OpenClaw, memory không chỉ là chỗ để nhớ. Nó là phần hạ tầng quyết định agent có giữ được continuity giữa các session hay không, có phối hợp đa agent ổn hay không, và có phân biệt được đâu là sự thật chuẩn, đâu chỉ là ngữ cảnh phụ trợ hay không.

Vì sao tối ưu memory lại quan trọng?

1) Giảm nhiễu, tăng độ đúng

Sau 3 lần cấu trúc lại, kiến trúc memory đã bắt đầu đi theo hướng khá chuẩn:

• mind/MEMORY.md = nguồn sự thật dài hạn cho người đọc
• Postgres + pgvector = canonical machine memory
• mem0/openmemory = shared collaboration memory cho nhiều agent
• memory/YYYY-MM-DD.md = log theo ngày, mang tính raw timeline
• LanceDB = lớp cũ, chỉ còn vai trò migration/archive

Đây là hướng đúng. Nhưng nếu không tối ưu định kỳ, mấy thứ sau sẽ xảy ra:

• cùng một quyết định bị ghi ở nhiều nơi
• note tạm thời bị lẫn với fact dài hạn
• mem0 chứa quá nhiều nugget rác, agent search ra trúng nhầm
• log hằng ngày phình to nhưng không được chưng cất lên canonical memory

Khi đó agent không mất trí nhớ, mà tệ hơn: nhớ quá nhiều thứ không đáng nhớ.

2) Giữ thứ tự ưu tiên giữa các lớp memory

Một hệ memory tốt không chỉ cần nhiều dữ liệu, mà cần biết tin cái gì trước.

Policy trong workspace nên là:

1. latest explicit user instruction
2. mind/MEMORY.md
3. Postgres structured state
4. mem0
5. nếu còn mơ hồ thì mới hỏi lại

Cái hay ở đây là OpenClaw đã tách được:

• canonical truth
• semantic recall
• raw logs

Nếu không tối ưu, thứ tự này sẽ bị phá vỡ trên thực tế. Agent sẽ kéo phải những mẩu context dễ match hơn, thay vì những gì đúng hơn.

3) Tăng hiệu suất cho multi-agent

Khi chạy một agent thì memory bừa bộn đã khó chịu. Khi chạy nhiều agent thì nó thành bug hệ thống.

Trong runbook nên là, mem0 được dùng làm shared collaboration memory, còn task state thật nằm ở queue / task system / notebook / file / Postgres, vì:

• mem0 hợp cho handoff, blocker, fact ngắn
• không ép semantic memory phải gánh vai trò task database
• giảm nguy cơ agent A hiểu sai thứ agent B ghi dở dang

Tối ưu memory ở đây có nghĩa là giảm duplicate, tăng atomicity, chuẩn hóa metadata, và có cơ chế promote từ memory phụ sang memory chuẩn khi thông tin đã được verify.

4) Giảm chi phí ngầm

Memory kém tổ chức không chỉ làm sai câu trả lời. Nó còn làm tăng:

• token đọc context
• số lần retrieval không cần thiết
• thời gian agent dò tìm đúng nguồn
• công sức dọn rác về sau

Nói thẳng: memory không tối ưu là một dạng technical debt lặng lẽ. Ban đầu chưa đau, nhưng tới lúc workflow dài, nhiều task, nhiều agent, nó đẻ lỗi rất mất thời gian để debug.

Tối ưu bằng cách nào?

1) Dedupe trước khi write

Đây là nguyên tắc đáng giữ nhất: đừng ghi thêm nếu thực ra chỉ đang lặp lại ý cũ.

Trước khi tạo memory mới, nên check:

• ý này đã có trong mind/MEMORY.md chưa?
• Postgres machine memory đã có bản structured chưa?
• mem0 đã có entry tương đương chưa?
• nếu đã có, nên update/promote thay vì append tiếp

Mỗi entry nên là 1 ý chính, ngắn, searchable, có context.

2) Tách rõ “fact”, “decision”, “hypothesis”, “handoff”

Runbook hiện tại của mem0 làm đúng điểm này bằng metadata kiểu:

• type=fact
• type=decision
• type=hypothesis
• type=todo
• type=blocker
• type=handoff

Đây không phải chuyện trang trí. Nó giúp agent:

• biết cái nào đáng tin
• biết cái nào chỉ là giả thuyết
• biết cái nào dùng để tiếp sức cho agent khác

Nếu memory nào cũng là text tự do, sớm muộn retrieval cũng trả về mớ hỗn độn.

3) Chỉ promote thứ đã được verify

Không phải cái gì agent thấy hữu ích cũng đáng thành canonical memory.

Rule tốt là:

• note tạm → ở daily log hoặc mem0
• thứ có reuse trung bình/cao → Postgres machine memory
• thứ ổn định lâu dài → mind/MEMORY.md

Nói cách khác, memory nên có pipeline thăng hạng:
raw note -> shared recall -> canonical state

Không có pipeline này thì hệ thống hoặc là quên quá nhanh, hoặc là giữ rác quá lâu.

4) Đặt TTL cho memory mang tính tác vụ

Policy nên gợi ý kiểu:

• global facts/decisions: ttl=none
• project operational notes: 30–90 ngày
• task scratch/handoff: 7–30 ngày

Đây là phần cực đáng làm thật, vì task-level memory thường là nơi phình nhanh nhất. Nếu không có TTL hoặc cleanup cadence, mem0 sẽ biến thành bãi rác semantic.

5) Có lịch vệ sinh memory định kỳ

Một hệ memory khỏe cần maintenance, không chỉ architecture.

Tối thiểu nên có:

• hàng tuần: prune duplicate trong mem0/Postgres machine memory
• hàng tuần: distill log ngày sang durable memory
• hàng tháng: xóa preferences hoặc constraint đã lỗi thời

Nói ngắn gọn: memory cũng cần garbage collection kiểu vận hành, không phải chỉ ở tầng database.

Khi nào cần tối ưu lại memory?

Có 6 dấu hiệu khá rõ:

1) Agent bắt đầu trả lời đúng kiểu na ná đúng

Nó không sai hẳn, nhưng dùng context cũ, lẫn note tạm với rule thật, hoặc nhắc lại một quyết định đã bị thay thế.

2) Cùng một fact xuất hiện ở nhiều file/layer

Ví dụ một rule vừa nằm ở daily log, vừa ở mem0, vừa ở Postgres, vừa bị copy sang docs khác — nhưng nội dung hơi lệch nhau.

3) Retrieval ra quá nhiều kết quả có vẻ liên quan nhưng ít cái thật sự hữu ích

Đây là triệu chứng điển hình của memory noise.

4) Multi-agent handoff hay bị trượt

Agent sau không biết đâu là outcome thật, đâu là note nháp, đâu là blocker cũ đã giải quyết.

5) Chi phí context tăng lên rõ rệt

Muốn làm một việc nhỏ mà phải đọc quá nhiều file, quá nhiều log, quá nhiều note lặp.

6) Sau vài tuần hoặc vài tháng làm việc liên tục

Dù chưa thấy lỗi lớn, vẫn nên tối ưu theo chu kỳ. Đừng chờ đến lúc hệ nhớ sai mới dọn.

---

Nếu anh em đang build OpenClaw hoặc một hệ AI agent tương tự, đừng xem memory là phần phụ. Nó chính là phần backend của continuity.