Một câu hỏi khá thực tế vừa xuất hiện trên r/openclaw: nếu anh em đã có một bộ skill “battle-tested”, liệu có thể dùng OpenClaw chỉ như một bộ executor ngoan ngoãn, chạy đúng thứ được giao, thay vì tự ý chỉnh skill hoặc tạo biến thể mới quanh nó không?
Câu trả lời ngắn gọn: có thể thiết kế theo hướng đó, nhưng không nên chỉ dựa vào niềm tin rằng agent sẽ luôn tự hiểu ranh giới. Muốn agent vận hành như executor, anh em cần biến ranh giới đó thành cơ chế kỹ thuật, quy trình chạy và quyền hạn rõ ràng.
Vấn đề không chỉ nằm ở chmod
Khóa file skill bằng quyền hệ thống là một lớp bảo vệ tốt, nhưng nó chỉ giải quyết một phần:
- ngăn ghi đè trực tiếp vào file skill;
- giảm rủi ro agent “sửa nhanh” khi gặp lỗi;
- tạo tín hiệu rõ rằng skill là artifact đã được phê duyệt.
Nhưng nếu workflow vẫn cho agent quyền tự do quá rộng, nó có thể:
- viết một script phụ để đi vòng qua skill;
- tạo bản nháp skill mới ở nơi khác;
- thay đổi input/output contract;
- “cải tiến” quy trình bằng cách thêm bước không được duyệt;
- dùng tool khác để đạt cùng mục tiêu theo cách khó audit hơn.
Vì vậy, câu hỏi đúng không chỉ là “có khóa được file không”, mà là “agent có được quyền làm gì ngoài việc gọi skill đã định nghĩa không”.
Mẫu thiết kế: executor mode cho skill đã duyệt
Nếu mục tiêu là chạy on-demand hoặc theo lịch, mình sẽ thiết kế theo 5 lớp sau.
1. Skill là hợp đồng, không phải gợi ý
Mỗi skill nên có contract rõ:
- input bắt buộc là gì;
- output mong đợi là gì;
- tool nào được phép dùng;
- file/path nào được phép đọc;
- file/path nào được phép ghi;
- trường hợp nào phải dừng và hỏi người vận hành.
Nếu skill chỉ mô tả “hãy làm X” một cách mở, agent sẽ có nhiều khoảng trống để suy diễn. Với executor mode, khoảng trống đó nên được giảm xuống mức tối thiểu.
2. Tách quyền đọc, quyền chạy và quyền sửa
Một cấu hình an toàn thường có 3 vùng:
- vùng skill đã duyệt: chỉ đọc;
- vùng runtime/output: được ghi kết quả, log, cache;
- vùng phát triển skill: chỉ con người hoặc quy trình review mới được sửa.
Điểm quan trọng là không để “chạy skill” và “phát triển skill” dùng cùng quyền mặc định.
3. Không cho fallback tự do
Nhiều agent framework có xu hướng cố cứu task khi gặp lỗi. Điều này hữu ích trong công việc khám phá, nhưng nguy hiểm với executor mode.
Ví dụ, nếu skill A lỗi, agent không nên tự tạo skill A2 hoặc tự chuyển sang tool khác mà chưa được phép. Thay vào đó, quy tắc nên là:
- chạy đúng skill được chỉ định;
- nếu thiếu input, hỏi;
- nếu lỗi môi trường, báo lỗi;
- nếu cần thay đổi skill, tạo đề xuất riêng, không áp dụng trực tiếp.
4. Log đủ để audit
Với các skill chạy theo lịch, log nên ghi ít nhất:
- skill nào đã chạy;
- version hoặc checksum của skill;
- input chính;
- tool/API đã gọi;
- file đã ghi;
- kết quả cuối;
- lý do dừng nếu thất bại.
Executor đáng tin không phải là executor “không bao giờ sai”, mà là executor khi sai thì biết sai ở đâu và không âm thầm tự đổi luật chơi.
5. Dùng human-in-the-loop cho thay đổi cấu trúc
Một ranh giới đơn giản nhưng rất hiệu quả:
- được phép chạy skill đã duyệt;
- được phép tạo báo cáo lỗi;
- được phép đề xuất diff;
- không được phép tự merge diff vào skill production.
Như vậy agent vẫn giúp anh em cải tiến hệ thống, nhưng không được tự ý đổi phần lõi đang vận hành ổn định.
Checklist nhanh trước khi giao OpenClaw chạy skill định kỳ
Anh em có thể dùng checklist này trước khi bật cron hoặc automation:
- Skill folder production có đang read-only với agent runtime không?
- Output folder có tách riêng khỏi skill folder không?
- Prompt/runbook có ghi rõ “không sửa skill, không tạo skill thay thế” không?
- Có danh sách tool được phép dùng cho job này không?
- Khi lỗi, agent phải dừng hay được tự sửa?
- Có log run theo timestamp không?
- Có lưu version/checksum của skill tại thời điểm chạy không?
- Có cơ chế review riêng cho mọi đề xuất thay đổi skill không?
Nếu một trong các câu trả lời còn mơ hồ, agent chưa thật sự ở executor mode.
Kết luận thực dụng
OpenClaw có thể dùng theo kiểu executor cho các skill đã có sẵn, nhất là khi anh em muốn gọi theo nhu cầu hoặc chạy theo lịch. Nhưng mức độ “ngoan ngoãn” không nên được xem là tính cách của agent. Nó nên là kết quả của quyền hạn, contract, logging và quy tắc dừng.
Cách mình nhìn vấn đề: hãy để agent có nhiều năng lực, nhưng ít quyền mặc định. Khi cần sáng tạo, mở một workflow riêng để đề xuất cải tiến. Khi cần vận hành production, bắt nó chạy đúng hợp đồng và dừng sạch nếu hợp đồng không đủ.
Top comments (0)