OpenClaw rất giỏi tự động hóa, nhưng cũng vì thế mà chỉ cần một script sai mô hình là đủ biến một nhu cầu nhỏ thành một “cron bomb” đúng nghĩa.
Câu chuyện đang được bàn trên r/openclaw khá buồn cười nhưng cũng rất đáng để anh em đang cho agent đụng vào email, cron hoặc tác vụ nền đọc kỹ. Một bạn chỉ muốn cho OpenClaw theo dõi email mới. Kết quả là sau khoảng một ngày, hệ thống đã tự sinh hơn 13 nghìn cron jobs.
Chuyện gì đã xảy ra
Theo phần cập nhật của chủ thớt, script được tạo ra là một watcher IMAP poll Gmail mỗi 5 giây. Vấn đề không nằm ở việc đọc email, mà ở cách phản ứng với mỗi email mới:
- mỗi email unseen lại tạo ra một cron one-shot mới
- không có cơ chế gộp sự kiện
- không có chống trùng lặp
- không có giới hạn tốc độ
- không có hàng đợi trung tâm để hấp thụ burst
Khi hộp thư có spam, notification hoặc email hệ thống đến liên tục, logic này gần như chắc chắn sẽ phình to rất nhanh. Thay vì có một worker bền vững xử lý luồng email, hệ thống lại đẻ thêm job cho từng event.
Gốc rễ không phải email, mà là mô hình tác vụ
Điểm đáng học ở đây là nhiều anh em hay mô tả bài toán theo kiểu “cứ thấy email mới thì làm gì đó”. Nếu agent hiểu sai abstraction, nó sẽ chọn cách dễ nhất về mặt local reasoning:
- quét liên tục
- thấy item mới
- tạo job mới
- lặp lại
Cách này nhìn có vẻ hoạt động ở quy mô nhỏ, nhưng rất dễ nổ khi đem vào môi trường thật. Với các bài toán dạng watcher, thứ cần thiết thường là một trong ba mô hình sau:
1. Một tiến trình nền duy nhất
Dùng một worker hoặc service duy nhất để poll rồi xử lý tuần tự. Trạng thái được giữ ở một chỗ, dễ quan sát và dễ dừng.
Phù hợp khi:
- số nguồn dữ liệu ít
- logic xử lý không quá nặng
- cần đơn giản hóa vận hành
2. Một cron cố định, không tự sinh thêm cron
Nếu vẫn muốn dùng cron, hãy giữ đúng tinh thần của cron:
- một job cố định chạy theo chu kỳ
- mỗi lần chạy sẽ đọc trạng thái cuối cùng
- xử lý phần chênh lệch
- thoát sạch sau khi xong
Điều quan trọng là cron không được tự nhân bản dựa trên input runtime nếu chưa có guardrail rất chặt.
3. Queue + worker
Nếu khối lượng event có thể tăng đột biến, queue thường là mô hình lành mạnh hơn:
- watcher chỉ ghi event vào queue
- worker đọc queue và xử lý
- retry, backoff, dedupe và rate limit nằm ở lớp xử lý
- số lượng worker được kiểm soát độc lập với số event
Đây là kiểu thiết kế chịu tải tốt hơn nhiều so với việc sinh cron vô hạn.
5 guardrail nên có trước khi cho agent đụng vào email
1. Chống trùng lặp theo message-id hoặc UID
Mỗi email cần có khóa idempotency rõ ràng. Nếu cùng một email bị đọc lại 20 lần, hệ thống vẫn chỉ nên xử lý một lần.
2. Giới hạn tạo tác vụ mới
Đặt quota cứng cho số job hoặc số event được tạo trong một khoảng thời gian:
- tối đa X job mỗi giờ
- tối đa Y email được enqueue mỗi phút
- nếu vượt ngưỡng thì chuyển sang chế độ cảnh báo thay vì tiếp tục tạo thêm việc
3. Tách watcher khỏi executor
Watcher chỉ quan sát và ghi nhận. Nó không nên vừa theo dõi vừa tự ý tạo thêm scheduler entry nếu chưa qua lớp kiểm soát.
4. Có dry-run và log dễ đọc
Trước khi chạy thật, anh em nên ép agent đi qua một vòng dry-run để xem chính xác nó định làm gì khi gặp 1 email, 10 email và 100 email.
5. Có kill switch rõ ràng
Một hệ thống tự động hóa mà không có nút dừng nhanh thì sớm muộn cũng làm mình trả giá. Tối thiểu nên có:
- một service name rõ ràng để stop ngay
- một cờ enable/disable ở config
- một nơi tập trung để nhìn thấy tổng số job đang hoạt động
Điều chủ thớt đã làm đúng sau khi sự cố xảy ra
Phần cleanup trong bài Reddit thực ra là một checklist rất ổn:
- kill tiến trình watcher đang chạy
- đổi tên script để nó không tự bật lại
- dừng và gỡ service liên quan
- vô hiệu toàn bộ cron jobs còn sót
- cập nhật lại trạng thái job
Đó là cách xử lý đúng thứ tự: cắt nguồn sinh lỗi trước, rồi mới dọn phần hậu quả.
Bài học cho anh em dùng OpenClaw trong production nhỏ
Mình nghĩ điểm đáng nhớ nhất không phải là “đừng đưa email cho agent”, mà là:
- đừng giao trực tiếp một vòng lặp vô hạn cho agent mà không có quota
- đừng để agent tự viết scheduler động rồi tin rằng nó sẽ tự giới hạn
- đừng đánh giá workflow chỉ bằng việc nó chạy được trong 5 phút đầu
Một automation tốt cần chịu được spam, input bẩn, retry, restart và duplicate event. Nếu chưa nghĩ tới các trường hợp đó thì workflow vẫn đang ở mức demo, chưa phải vận hành.
Checklist ngắn trước khi triển khai watcher email
Anh em có thể tự rà nhanh bằng danh sách này:
- có idempotency key cho từng email chưa
- có quota tạo job chưa
- có queue hoặc ít nhất là state file chống xử lý lặp chưa
- có cảnh báo khi số job tăng bất thường chưa
- có cách tắt khẩn cấp trong dưới 1 phút chưa
- có test với hộp thư nhiều spam hoặc notification chưa
Nếu còn thiếu quá nửa số này, mình sẽ chưa cho workflow chạy nền dài ngày.
Góc nhìn rộng hơn
Những câu chuyện như thế này rất có ích vì nó nhắc anh em rằng agent không chỉ cần thông minh ở bước viết code. Nó còn phải được đặt vào một khung vận hành đúng.
Khi bài toán là polling, scheduling, email hoặc automation nền, thiết kế hệ thống thường quan trọng hơn cả prompt. Chỉ cần sai abstraction ở lớp đầu tiên, agent có thể tối ưu rất chăm chỉ theo một hướng hoàn toàn sai.
Với anh em đang build các workflow kiểu “đọc email rồi làm việc giúp mình”, lời khuyên ngắn gọn là: bắt đầu bằng mô hình đơn giản, quan sát được, có quota cứng, và chỉ tăng độ tự động khi đã chứng minh được nó không tự đẻ thêm rủi ro.
Top comments (0)