Đừng để memory của OpenClaw thành ghi chú phẳng: khi nào nên dùng API và schema

Một chia sẻ khá đáng chú ý trên r/openclaw: có người dùng bỏ cách để agent ghi nhớ bằng một file Markdown phẳng, rồi thay bằng một lớp API Node.js/Express + PostgreSQL với schema chặt. Điểm hay không nằm ở việc “dùng Postgres cho sang”, mà ở cách họ ép memory đi qua hợp đồng dữ liệu rõ ràng.

Nếu anh em đang dùng OpenClaw cho dự án dài hơi, đây là một bài học rất thực tế: memory không chỉ là nơi lưu chữ. Memory là một phần của kiến trúc hệ thống.

Vấn đề với memory dạng file phẳng

File kiểu MEMORY.md rất tiện để bắt đầu nhanh:

• dễ đọc bằng mắt;
• dễ sửa tay;
• không cần hạ tầng phụ;
• phù hợp cho sở thích, ghi chú nhỏ, hoặc các workflow chưa ổn định.

Nhưng khi dự án lớn dần, nó có vài điểm yếu rõ:

• thông tin cũ và mới nằm cạnh nhau, agent dễ nhặt nhầm quyết định đã lỗi thời;
• không có schema để phân biệt “quyết định kiến trúc”, “ý tưởng thử nghiệm”, “todo”, “ghi chú tạm”;
• không có cơ chế bắt buộc cập nhật một nguồn sự thật duy nhất;
• khi context dài, agent có thể diễn giải lại memory theo cách nghe hợp lý nhưng sai.

Nói ngắn gọn: file phẳng tốt cho ghi chú, nhưng không tự biến thành hệ thống quản lý trạng thái đáng tin cậy.

Cách làm đáng học: memory như một API

Trong chia sẻ gốc, tác giả tạo một middleware Node.js/Express, phía sau là PostgreSQL. Agent không được tự do “ghi vài dòng vào memory”, mà phải gọi tool/API với payload đúng kiểu.

Ví dụ thay vì ghi:

Database dùng Postgres, có thể thêm Redis sau.

Agent phải gửi một record có cấu trúc kiểu:

{
  "area": "database",
  "decision": "Use PostgreSQL as primary relational store",
  "status": "accepted",
  "rationale": "Need strict schema and reliable retrieval for architecture rules",
  "supersedes": null
}

Điểm quan trọng là API trở thành “cổng kiểm soát”:

• thiếu trường bắt buộc thì từ chối;
• sai loại dữ liệu thì từ chối;
• quyết định mới có thể ghi đè hoặc đánh dấu thay thế quyết định cũ;
• khi agent cần trả lời, hệ thống lấy đúng record liên quan và inject vào context.

Đây là khác biệt lớn giữa “nhớ thêm một đoạn văn” và “duy trì trạng thái hệ thống”.

Khi nào nên dùng cách này

Mình nghĩ không phải ai cũng cần dựng hẳn backend cho memory. Nhưng cách này rất đáng cân nhắc nếu anh em có một trong các dấu hiệu sau:

• dự án kéo dài nhiều tuần hoặc nhiều tháng;
• có nhiều quyết định kỹ thuật thay đổi theo thời gian;
• agent thường nhắc lại thiết kế cũ dù đã đổi;
• nhiều agent cùng làm việc trên một project;
• có workflow cần kiểm toán: ai quyết định gì, lúc nào, vì sao;
• sai memory có thể gây hậu quả thật, ví dụ sửa schema, deploy nhầm, xóa dữ liệu, gọi nhầm API.

Còn nếu chỉ dùng OpenClaw để tóm tắt, viết nháp, làm việc cá nhân nhẹ, hoặc automation đơn giản, MEMORY.md vẫn có thể đủ tốt.

Một thiết kế thực dụng hơn cho anh em mới bắt đầu

Không nhất thiết phải nhảy thẳng sang một hệ thống phức tạp. Có thể đi theo 3 tầng:

Tầng 1: File Markdown có kỷ luật

Dùng khi dự án nhỏ. Nhưng nên chia rõ:

## Decisions
## Current architecture
## Deprecated notes
## Open questions
## Next actions

Quan trọng nhất: có mục “Deprecated notes” để agent không coi mọi thứ trong file là sự thật hiện tại.

Tầng 2: SQLite hoặc Postgres cho quyết định quan trọng

Chỉ đưa những thứ dễ gây lỗi vào database:

• API routes;
• database schema;
• credential policy;
• deployment steps;
• accepted architecture decisions;
• danh sách việc không được làm.

Các ghi chú mềm vẫn để Markdown.

Tầng 3: Tool/API bắt buộc cho memory quan trọng

Khi workflow đã ổn định, hãy ép agent ghi memory qua tool call có schema. Ví dụ:

• create_architecture_decision;
• update_api_contract;
• mark_decision_deprecated;
• get_current_project_rules.

Lúc này memory không còn là “một chỗ agent thích ghi gì thì ghi”, mà là một phần của hệ thống quyền hạn và kiểm soát chất lượng.

Checklist trước khi thay memory mặc định

Nếu anh em muốn thử hướng này, nên kiểm tra nhanh:

• Memory nào cần chính xác tuyệt đối?
• Memory nào chỉ là ghi chú tham khảo?
• Có cần lịch sử thay đổi không?
• Quyết định cũ được xử lý thế nào?
• Agent có được sửa record cũ không, hay chỉ được đề xuất?
• Khi trả lời, retrieval lấy “mọi thứ liên quan” hay chỉ “trạng thái hiện tại”?
• Nếu database/API lỗi thì agent dừng hay fallback sang Markdown?

Đặc biệt, đừng biến mọi ghi chú thành bảng dữ liệu. Làm vậy dễ tạo thêm ma sát mà không tăng độ tin cậy tương ứng.

Bài học chính

Điểm mình thích trong chia sẻ này là nó đổi câu hỏi từ:

“Lưu memory ở đâu?”

sang:

“Memory nào cần được bảo vệ bằng schema, trạng thái và quy trình cập nhật?”

Với agent workflow, đây là một thay đổi tư duy quan trọng. Càng dùng OpenClaw cho việc thật, anh em càng nên phân loại memory theo mức độ rủi ro. Những thứ rủi ro thấp có thể để Markdown. Những thứ quyết định hành vi hệ thống nên đi qua API, schema, log và cơ chế cập nhật rõ ràng.

Memory tốt không phải là memory dài hơn. Memory tốt là memory biết đâu là sự thật hiện tại, đâu là lịch sử, và đâu chỉ là ghi chú tạm.