Muốn OpenClaw chạy qua đêm, anh em cần protocol chứ không chỉ cần cron

Có một kiểu triển khai agent nghe rất hấp dẫn trên giấy: giao việc ban đêm, sáng dậy có kết quả. Nhưng khi bắt đầu cho OpenClaw chạy dài bằng cron, tool, memory, skill, MCP và đủ loại ghi chú, nhiều anh em sẽ gặp cùng một vấn đề: agent không hỏng vì thiếu khả năng, mà hỏng vì workspace không có giao thức vận hành rõ ràng.

Bài chia sẻ trên Reddit gọi hướng này là “nightclaw protocol”. Mình thấy đây là một cách đặt vấn đề rất đúng: với agent chạy lâu dài, mô hình AI không phải toàn bộ “agent”. Agent thật sự là mô hình cộng với workspace protocol, tức cách mình tổ chức bối cảnh, quyền hạn, log, memory, failure mode và vòng kiểm tra sau mỗi lần chạy.

Vấn đề không nằm ở cron

Cron chỉ là cái đồng hồ. Nó gọi agent đúng giờ, nhưng không trả lời được mấy câu quan trọng:

• Agent được phép đọc gì, viết gì, và không được đụng vào đâu?
• Khi lỗi giữa chừng thì lưu trạng thái ở đâu?
• Lần sau agent biết việc nào đã làm, việc nào đang kẹt bằng cách nào?
• Skill nào là hướng dẫn bền vững, skill nào chỉ là ghi chú tạm?
• Khi workspace ngày càng phình ra, làm sao tránh nạp quá nhiều markdown không liên quan vào context?

Nếu không có câu trả lời, agent chạy qua đêm rất dễ biến thành một đống file rải rác: có log, có note, có plan, có output, nhưng không có schema. Sáng hôm sau nhìn vào không biết tin cái gì.

Workspace protocol nên có những lớp rõ ràng

Một “nightclaw protocol” thực dụng không cần phức tạp. Nhưng nó cần phân lớp để agent không tự nhét mọi thứ vào cùng một chỗ.

Mình sẽ bắt đầu bằng 5 lớp:

1. Instruction ổn định: quy tắc vận hành, red line, cách dùng tool, tiêu chuẩn hoàn thành.
2. Memory dài hạn: quyết định, preference, bài học đã được chắt lọc, không phải log thô.
3. Task state: trạng thái từng việc đang làm, blocker, bước tiếp theo, file liên quan.
4. Failure modes: lỗi đã gặp, dấu hiệu nhận biết, cách phục hồi, khi nào phải dừng.
5. Run logs: lịch sử chạy chi tiết, dùng để audit, không nên tự động nạp hết vào context.

Điểm quan trọng là mỗi lớp có mục đích khác nhau. Nếu agent cứ thấy gì cũng ghi vào memory dài hạn, memory sẽ nhiễu. Nếu cái gì cũng là skill, skill sẽ thành bãi rác context. Nếu chỉ có log mà không có task state, agent biết rất nhiều nhưng không biết phải làm gì tiếp.

Chống context pollution bằng “quyền nạp bối cảnh”

Một lỗi phổ biến là cho agent đọc quá nhiều tài liệu trước khi làm việc. Ý định thì tốt: càng nhiều context càng thông minh. Thực tế thì ngược lại: context thừa làm suy luận kém sắc hơn, nhất là với các việc có phạm vi hẹp.

Thay vì “đọc hết rồi tính”, workspace nên có luật nạp bối cảnh:

• Luôn đọc lớp lõi: identity, user preference, operating rules.
• Chỉ đọc project memory khi việc thuộc project đó.
• Chỉ đọc task state khi đang tiếp tục một task cụ thể.
• Chỉ đọc failure mode khi thấy dấu hiệu lỗi tương ứng.
• Không nạp log dài nếu chỉ cần trạng thái cuối.

Cách này biến workspace từ một thư mục đầy markdown thành một hệ thống truy xuất có chủ đích.

Agent chạy đêm cần biết khi nào phải dừng

Tự động hóa tốt không phải là chạy bất chấp. Với các phiên qua đêm, “dừng sạch” quan trọng ngang “làm tiếp”.

Một checklist tối thiểu trước khi cho agent tự chạy:

• Có file trạng thái ghi rõ mục tiêu, done criteria và bước tiếp theo.
• Có giới hạn quyền ghi/xóa, đặc biệt với repo, database, message, email hoặc API bên ngoài.
• Có nguyên tắc fallback: lỗi mạng thì thử lại mấy lần, lỗi dữ liệu thì dừng, lỗi quyền thì báo.
• Có log đủ để sáng hôm sau audit được agent đã làm gì.
• Có tiêu chuẩn “không chắc thì không publish/không gửi/không xóa”.

Phần này nghe khô, nhưng nó quyết định agent là đồng đội hay là rủi ro vận hành.

Bài học lớn: compounding nằm ở protocol

Nếu mỗi phiên agent chỉ là một cuộc chat mới, năng lực không tích lũy được nhiều. Nhưng nếu mỗi phiên biết cập nhật task state, rút bài học vào failure modes, chắt lọc quyết định vào memory, và giữ workspace sạch, thì năng lực bắt đầu compound.

Đây là điểm mình thích nhất trong ý tưởng “nightclaw”: agent không chỉ hoàn thành một việc, mà còn cải thiện môi trường để lần sau làm việc tốt hơn.

Anh em muốn thử có thể bắt đầu rất nhỏ:

• Tạo một thư mục tasks/ cho trạng thái việc dài hạn.
• Tạo một file failure-modes.md cho lỗi lặp lại.
• Viết quy tắc rõ: cái gì được đưa vào memory dài hạn, cái gì chỉ là log.
• Sau mỗi cron, bắt agent ghi lại “đã làm gì, kẹt gì, bước tiếp theo là gì”.
• Mỗi vài ngày, chắt lọc log thành quy trình bền vững.

Không cần biến workspace thành hệ thống quá nặng. Nhưng nếu đã muốn agent chạy qua đêm, mình nghĩ phải coi workspace như một sản phẩm vận hành, không phải chỉ là thư mục chứa prompt.