Kho kiến thức OpenClaw: dùng MEMORY.md, RAG và vector search để AI nhớ đúng ngữ cảnh

Vì sao OpenClaw cần kho kiến thức?

Khi mới dùng AI coding agent, nhiều người có cảm giác phải nhắc đi nhắc lại cùng một thông tin: dự án dùng framework gì, convention đặt tên ra sao, không được sửa thư mục nào, cách chạy test như thế nào, quy tắc viết commit message, tiêu chuẩn code review, hoặc những quyết định kỹ thuật đã thống nhất từ trước. Nếu mỗi phiên làm việc đều bắt đầu lại từ con số 0, hiệu quả của AI sẽ giảm đáng kể.

Đó là lý do kho kiến thức OpenClaw trở thành một phần quan trọng trong workflow thực tế. Thay vì chỉ dựa vào đoạn hội thoại hiện tại, OpenClaw có thể tận dụng các lớp ngữ cảnh bền vững hơn như file MEMORY.md, tài liệu dự án, cơ chế RAG và tìm kiếm vector để truy xuất thông tin liên quan khi cần.

Nói đơn giản, kho kiến thức giúp OpenClaw “nhớ đúng thứ cần nhớ”. Không phải nhớ mọi thứ một cách mơ hồ, mà là lưu các quy tắc, thông tin nền, tài liệu và kinh nghiệm quan trọng để AI làm việc nhất quán hơn. Với dự án cá nhân, điều này giúp tiết kiệm thời gian. Với đội nhóm, nó giúp giảm sai lệch giữa các thành viên và giữa các phiên làm việc.

Nếu bạn vẫn đang ở bước cài đặt, có thể xem bài hướng dẫn cài OpenClaw trên ThanhTuan.VN tại đây: Hướng dẫn cài đặt OpenClaw trên Windows, macOS, Linux. Sau khi cài xong, việc xây dựng kho kiến thức là bước nên làm sớm nếu bạn muốn dùng OpenClaw lâu dài.

MEMORY.md là gì?

MEMORY.md có thể hiểu là một file ghi nhớ dành cho OpenClaw trong dự án. Đây là nơi bạn lưu các thông tin có tính ổn định: mục tiêu dự án, stack công nghệ, quy ước code, lệnh thường dùng, những điều không được làm, hoặc các quyết định kỹ thuật quan trọng.

Khác với README dành cho con người đọc tổng quan, MEMORY.md thường được viết theo hướng phục vụ AI làm việc. Nội dung nên ngắn gọn, rõ ràng, có tính chỉ dẫn. Ví dụ:

# Project Memory

- Dự án dùng Next.js App Router, TypeScript và Tailwind CSS.
- Không dùng `any` trừ khi có lý do rõ ràng.
- Component UI đặt trong `src/components`.
- API client đặt trong `src/lib/api`.
- Chạy kiểm tra bằng `npm run lint` và `npm run typecheck`.
- Không chỉnh sửa file migration cũ. Nếu cần thay đổi database, tạo migration mới.

Một file như vậy giúp OpenClaw tránh hỏi lại các thông tin lặp đi lặp lại. Khi bạn yêu cầu thêm component, nó biết nên đặt ở đâu. Khi sửa type, nó biết tránh any. Khi thay đổi database, nó biết không sửa migration cũ.

Nên ghi gì trong MEMORY.md?

Không nên biến MEMORY.md thành một cuốn sách dài. Càng dài, file càng khó bảo trì và có thể gây nhiễu. Hãy ưu tiên thông tin có giá trị lặp lại qua nhiều phiên làm việc.

Các nhóm nội dung nên có gồm:

• Tổng quan dự án: dự án làm gì, người dùng chính là ai, mục tiêu sản phẩm.
• Stack kỹ thuật: framework, ngôn ngữ, database, thư viện UI, công cụ build.
• Cấu trúc thư mục: nơi đặt component, service, type, test, tài liệu.
• Quy ước code: đặt tên, style, nguyên tắc tách hàm, xử lý lỗi.
• Lệnh thường dùng: install, dev, build, lint, test, typecheck.
• Vùng cấm hoặc cần hỏi trước: file production config, migration cũ, secret, dữ liệu thật.
• Quy trình làm việc: luôn lập kế hoạch trước khi sửa nhiều file, luôn tóm tắt diff sau khi sửa.

Ví dụ thực tế:

## Working Rules

- Trước khi sửa hơn 3 file, phải đề xuất kế hoạch và chờ xác nhận.
- Không xóa file nếu chỉ dựa trên suy đoán. Phải kiểm tra import và usage trước.
- Khi thêm dependency mới, giải thích lý do và đề xuất lựa chọn nhẹ nhất.
- Tài liệu viết bằng tiếng Việt, giọng rõ ràng, thực hành, không quảng cáo quá đà.

Những quy tắc này rất phù hợp với đội nhóm hoặc người làm nhiều dự án song song. Chúng giúp OpenClaw hành xử giống một cộng sự đã được onboarding.

MEMORY.md khác gì với prompt thông thường?

Prompt thông thường chỉ tồn tại trong phiên chat hoặc một tác vụ cụ thể. Bạn có thể nói: “Hãy viết code theo style rõ ràng”, nhưng sang phiên khác có thể phải nhắc lại. MEMORY.md thì bền hơn, nằm trong repo và có thể được dùng lại nhiều lần.

Có thể xem prompt là yêu cầu ngắn hạn, còn memory là bối cảnh dài hạn. Ví dụ:

• Prompt: “Sửa lỗi validate email trong form đăng ký.”
• Memory: “Dự án dùng Zod cho validation, message lỗi viết bằng tiếng Việt, form đặt trong src/features/auth.”

Khi hai phần này kết hợp, OpenClaw sẽ hiểu cả nhiệm vụ trước mắt lẫn quy tắc nền. Đây là điểm khác biệt lớn giữa dùng AI kiểu hỏi đáp và dùng AI như một agent làm việc trong dự án.

RAG trong OpenClaw: truy xuất đúng tài liệu khi cần

RAG là viết tắt của Retrieval-Augmented Generation, tạm hiểu là “sinh câu trả lời có hỗ trợ truy xuất”. Thay vì chỉ dựa vào kiến thức đã học sẵn hoặc đoạn chat hiện tại, hệ thống sẽ tìm trong kho tài liệu liên quan rồi đưa phần phù hợp vào ngữ cảnh để AI trả lời.

Trong thực tế, RAG rất hữu ích khi bạn có nhiều tài liệu nội bộ:

• Tài liệu API.
• Quy trình triển khai.
• Hướng dẫn vận hành.
• Quy tắc nghiệp vụ.
• Tài liệu khách hàng.
• Ghi chú kiến trúc.
• Log quyết định kỹ thuật.

Ví dụ bạn hỏi:

Theo tài liệu nội bộ, khi đơn hàng thanh toán thất bại thì hệ thống cần xử lý trạng thái như thế nào?

Nếu kho kiến thức đã có tài liệu nghiệp vụ, OpenClaw có thể truy xuất đoạn liên quan thay vì đoán. Điều này đặc biệt quan trọng với hệ thống có logic riêng, không thể suy ra từ kiến thức chung trên Internet.

Vector search giúp tìm theo ý nghĩa, không chỉ theo từ khóa

Tìm kiếm truyền thống thường dựa vào từ khóa. Nếu bạn tìm “đăng nhập”, hệ thống sẽ tìm đúng chữ “đăng nhập”. Nhưng trong tài liệu có thể dùng từ “xác thực”, “login”, “authentication” hoặc “sign in”. Nếu chỉ tìm theo từ khóa, bạn dễ bỏ sót.

Vector search giải quyết vấn đề này bằng cách tìm theo ngữ nghĩa. Nội dung tài liệu được chuyển thành vector, tức biểu diễn số học của ý nghĩa. Khi bạn đặt câu hỏi, câu hỏi cũng được chuyển thành vector. Hệ thống sẽ tìm các đoạn có ý nghĩa gần nhất, kể cả khi không trùng từ khóa.

Ví dụ bạn hỏi:

Người dùng quên mật khẩu thì quy trình xử lý ra sao?

Vector search có thể tìm được tài liệu có tiêu đề “Password reset flow”, “Khôi phục tài khoản” hoặc “Reset credential policy”. Đây là lợi thế rất lớn khi kho tài liệu ngày càng lớn và dùng nhiều thuật ngữ khác nhau.

Khi nào dùng MEMORY.md, khi nào dùng RAG?

Một cách phân biệt đơn giản:

• MEMORY.md phù hợp với thông tin ngắn, ổn định, cần áp dụng thường xuyên.
• RAG phù hợp với tài liệu dài, nhiều chi tiết, chỉ cần truy xuất khi có câu hỏi liên quan.
• Vector search là cơ chế giúp RAG tìm đúng đoạn tài liệu theo ý nghĩa.

Ví dụ nên đặt trong MEMORY.md:

- Dự án dùng PostgreSQL và Prisma.
- Không sửa migration cũ.
- API lỗi trả về format `{ code, message }`.

Ví dụ nên để trong kho RAG:

• Tài liệu 20 trang về quy trình hoàn tiền.
• Toàn bộ đặc tả API đối tác vận chuyển.
• Hướng dẫn vận hành production.
• Lịch sử quyết định kiến trúc.

Nếu bạn đưa mọi thứ vào MEMORY.md, file sẽ phình to và khó đọc. Nếu bạn đưa cả quy tắc ngắn vào RAG, OpenClaw có thể không luôn truy xuất đúng lúc. Vì vậy, nên dùng kết hợp.

Cách xây dựng kho kiến thức cho dự án nhỏ

Với dự án cá nhân hoặc website vừa phải, bạn không cần làm quá phức tạp. Hãy bắt đầu bằng một file MEMORY.md ở thư mục gốc repo.

Cấu trúc gợi ý:

# MEMORY.md

## Project Overview
Dự án là website nội dung về công nghệ, viết bằng Next.js và Markdown.

## Tech Stack
- Next.js
- TypeScript
- Tailwind CSS
- Markdown/MDX

## Content Rules
- Bài viết tiếng Việt, giọng thực hành, dễ hiểu.
- Không dùng tiêu đề giật gân.
- Ưu tiên ví dụ cụ thể.

## Commands
- Dev: `npm run dev`
- Build: `npm run build`
- Lint: `npm run lint`

## Safety
- Không sửa file cấu hình deploy nếu chưa hỏi.
- Không in secret từ `.env`.

Sau đó, bạn có thể yêu cầu OpenClaw:

Hãy đọc MEMORY.md trước, sau đó giúp tôi tạo bài viết mới theo đúng quy tắc nội dung của dự án.

Hoặc:

Dựa trên MEMORY.md, kiểm tra bài viết này có đúng giọng văn và cấu trúc không.

Chỉ với một file đơn giản, trải nghiệm làm việc đã nhất quán hơn nhiều.

Cách xây dựng kho kiến thức cho đội nhóm

Với đội nhóm, nên có quy trình rõ hơn. MEMORY.md không nên là nơi ai muốn ghi gì cũng được. Nếu không kiểm soát, file có thể chứa thông tin cũ, mâu thuẫn hoặc quá dài.

Một quy trình phù hợp:

1. Tạo MEMORY.md ban đầu với các quy tắc cốt lõi. 2. Review nội dung memory như review code. 3. Khi có quyết định kỹ thuật mới, cập nhật memory nếu quyết định đó ảnh hưởng lâu dài. 4. Định kỳ dọn các ghi chú đã lỗi thời. 5. Với tài liệu dài, đưa vào thư mục docs hoặc kho RAG thay vì nhồi vào memory.

Ví dụ khi đội nhóm quyết định chuyển từ REST sang GraphQL cho một module, memory chỉ cần ghi ngắn:

- Module báo cáo mới dùng GraphQL. Không thêm REST endpoint mới cho reporting nếu chưa được duyệt.

Chi tiết schema, query, mutation nên nằm trong tài liệu riêng để RAG truy xuất khi cần.

Tránh biến kho kiến thức thành nguồn sai lệch

Kho kiến thức chỉ hữu ích nếu nó đúng và cập nhật. Một MEMORY.md lỗi thời còn nguy hiểm hơn không có memory, vì OpenClaw có thể dựa vào thông tin sai để sửa code.

Một số lỗi thường gặp:

• Ghi stack cũ nhưng dự án đã chuyển công nghệ.
• Lệnh test không còn chạy được.
• Quy tắc thư mục không khớp cấu trúc hiện tại.
• Ghi “không dùng thư viện X” nhưng code đã dùng X ở nhiều nơi.
• Để quá nhiều ghi chú tạm thời trong memory.

Bạn có thể định kỳ yêu cầu OpenClaw kiểm tra:

Đối chiếu MEMORY.md với cấu trúc dự án hiện tại. Liệt kê điểm nào có vẻ lỗi thời hoặc không còn đúng. Chưa sửa file.

Sau đó mới cập nhật. Đây là cách bảo trì nhẹ nhàng nhưng hiệu quả.

Bảo mật khi dùng kho kiến thức

Không nên đưa secret, token, mật khẩu, private key hoặc dữ liệu khách hàng vào MEMORY.md hay kho tài liệu dùng cho RAG. AI chỉ cần biết tên biến môi trường, không cần biết giá trị thật.

Ví dụ nên ghi:

- Dự án cần biến môi trường `STRIPE_SECRET_KEY`, nhưng không bao giờ in giá trị key ra phản hồi.

Không nên ghi:

- STRIPE_SECRET_KEY=sk_live_...

Nếu dùng kho kiến thức cho công ty, hãy phân quyền tài liệu theo nhóm. Không phải agent hoặc người dùng nào cũng cần truy cập mọi tài liệu. Với tài liệu nhạy cảm như hợp đồng, dữ liệu khách hàng, thông tin tài chính, cần có chính sách riêng.

Kết luận

Kho kiến thức OpenClaw là bước nâng cấp quan trọng nếu bạn muốn dùng AI agent một cách nghiêm túc. MEMORY.md giúp lưu các quy tắc ngắn hạn nhưng bền vững trong dự án. RAG giúp truy xuất tài liệu dài khi cần. Vector search giúp tìm theo ý nghĩa thay vì chỉ theo từ khóa.

Khi kết hợp đúng, OpenClaw sẽ bớt hỏi lại, ít đoán mò hơn và làm việc nhất quán hơn với quy trình của bạn. Hãy bắt đầu nhỏ: tạo một MEMORY.md gọn gàng, ghi những quy tắc thật sự quan trọng, sau đó mở rộng dần sang tài liệu và RAG khi dự án lớn hơn. Một kho kiến thức tốt không cần đồ sộ, nhưng phải đúng, rõ và được bảo trì thường xuyên.

—