Cron Jobs cho Agent: Tự động chạy theo lịch — Từ cron job 'chết' đến agent 'sống'

Bạn đã có agent phục vụ qua Telegram, Slack hay Web, nhưng mỗi lần cần chạy báo cáo lúc 8 giờ sáng, bạn vẫn phải... tự bấm nút. Đó không phải là tự động hóa. Để AI thực sự thay thế workflow định kỳ, agent cần khả năng "tự thức dậy" — và cron jobs là cách ta đánh thức chúng, không chỉ như một đoạn script vô tri, mà như một nhân viên nối tiếp công việc từ hôm qua.

Vấn đề

Cron job truyền thống — những đoạn bash script chạy lúc 3h sáng — là stateless. Chúng chạy, xuất log, rồi chết. Không có khái niệm "hôm qua tôi đã xử lý tới record nào", "lỗi đang pending hay đã fix", hay "người dùng A đang chờ phản hồi gì". Điều này ổn cho việc xóa log file hay backup database, nhưng thảm họa với business workflow cần continuity: báo cáo tài chính cần biết "hôm qua ta đã tính tới dòng nào", agent monitoring cần nhớ "lỗi này đã tái phát lần thứ mấy".

Bên cạnh đó, nếu agent luôn đợi human-in-the-loop để kích hoạt, ta mất đi ý nghĩa của automation. Ai sẽ bấm nút để gửi báo cáo 8h sáng thứ 7? Và nếu người đó quên, hệ thống monitoring sẽ có "blind spot" kéo dài 48 giờ cho tới khi ai đó để ý.

Cách tiếp cận cũ — dùng Zapier hay n8n kết hợp LLM qua API call — cũng chưa đủ. Mỗi lần chạy là một context window trắng tinh, agent "đần độn" lặp lại từ đầu như người bị mất trí nhớ ngắn hạn.

Ý tưởng cốt lõi

Cron jobs cho agent không chỉ là "gọi API theo lịch". Đó là một kiến trúc rehydration — đánh thức một quá trình tư duy đã ngủ đông, nạp lại toàn bộ ngữ cảnh lịch sử, rồi mới thực thi.

Hãy hình dung ba tầng:

1. Trigger Layer — Lịch biểu là "báo thức" Thay vì chờ POST request từ người dùng, scheduler (OpenClaw, LangSmith hay Claude Code /loop) phân tích biểu thức cron như 0 9 * * 1-5 (8h sáng, thứ 2 tới thứ 6). Nhưng điểm khác biệt: trigger này không chỉ là "start signal", mà là "identity resurrection signal" — tín hiệu tái sinh.

2. State Hydration — Nạp lại ký ức Trước khi LLM được gọi, agent phải tái lập "bản ngã" của phiên làm việc trước:

• Đọc lại SOUL.md (định nghĩa vai trò, giới hạn)
• Truy vấn vector DB để lấy MEMORY.md — những gì đã học từ lần chạy trước
• Kiểm tra checkpoint trong SQLite/Redis: "task nào đang pending", "file nào đang chờ review"
• Nạp lại tool schemas và ephemeral context từ lần chạy cũ

Đây là bước khiến agent cron khác biệt với cron script truyền thống. Script chỉ cần biến môi trường; agent cần narrative continuity — câu chuyện công việc liên tục.

3. Sandboxed Execution — Làm việc rồi "ngủ tiếp" Agent chạy trong container tách biệt (Docker/E2B), có giới hạn thời gian (timeout 10–30 phút), và tự kết thúc sau khi hoàn thành workflow — không giống server long-running. Kết quả được đẩy async tới dashboard (LangSmith traces) hoặc notification channel (Telegram/Slack), thay vì blocking chờ người xem.

"À, chỉ vậy thôi" — khoảnh khắc aha Khác với cron job bash "chạy rồi chết", agent cron là continue conversation with time. Mỗi lần "thức dậy", agent không bắt đầu tabula rasa (bảng trắng), mà nối tiếp đoạn hội thoại với thực tại đã bị gián đoạn. Nó nhớ là "hôm qua ta đang nghi ngờ chỉ số CPU bất thường", nên hôm nay sẽ kiểm tra trend chứ không chỉ đọc snapshot.

Ví dụ cấu hình thực tế trong Claude Code:

/loop --every 1h --for 24 "Kiểm tra server load, nếu cao hơn 80% thì scale up. Ghi nhớ quyết định vào MEMORY.md"

Trong OpenClaw, bạn có thể định nghĩa scheduled task trong AGENTS.md:

## DailyReportAgent
- **Schedule**: `0 8 * * *` (Asia/Ho_Chi_Minh)
- **Hydration**: Load yesterday's pending list from /workspace/checkpoints/daily.json
- **Action**: Generate sales report → Send Zalo OA → Archive to S3

Tại sao nó hoạt động

Logic thiết kế dựa trên sự khác biệt về ontology: cron script là pure function (input cố định → output cố định), còn agent là dynamical system với trạng thái nội tại (internal state). Khi bạn tái tạo state qua hydration, bạn biến một quá trình stochastic (ngẫu nhiên) thành correlated stochastic process — có tính liên tục thống kê giữa các lần chạy.

Trade-off: Chi phí tái tạo context Hydration không miễn phí. Nạp 4K–8K tokens của SOUL.md + MEMORY.md mỗi lần chạy tốn token và latency. Nhưng chi phí này là insurance premium chống lại "state drift" — hiện tượng agent quên mất ngữ cảnh và đưa ra quyết định ngẫu nhiên (random walk) giữa các lần chạy.

Theo benchmark cộng đồng, dùng GLM-5 (744B) cho scheduled tasks rẻ hơn ~6 lần so với Claude Opus, khiến cron jobs agent có thể chạy 24/7 mà không đốt tiền API.

Ý nghĩa thực tế

Ai đang dùng?

• Claude Code: Native /loop support cho health check và refactoring định kỳ
• OpenClaw: Ecosystem Telegram/WhatsApp agents tự gửi báo cáo sáng thứ 2
• LangSmith: Scheduled graphs cho data pipeline evaluation tự động

Hạn chế — Những gì nó KHÔNG giải quyết

1. Silent failures: Agent cron chết âm thầm nhiều hơn agent interactive (không có người nhìn stack trace ngay). Debug async harder.
2. Zombie problem: Agent là "nhân viên không người giám sát" ca đêm. Nếu bị compromise lúc 2h sáng, nó có thể exfiltrate data liên tục cho tới khi bạn thức.
3. State drift: Chạy nhiều tuần không human validation, agent có thể tích lũy "hallucinated assumptions" — ví dụ tự tin rằng một API đã deprecated vẫn còn hoạt động, rồi loop lỗi.

Đào sâu hơn

Tài liệu chính thức:

• LangSmith Cron Jobs: Hướng dẫn schedule graph job với cron expressions
• Claude Code /loop: Tính năng lặp lại tác vụ định kỳ trong IDE

Bài liên quan TroiSinh:

Mở rộng:

• ScheduleMe: Multi-Agent Calendar Assistant (2025) — Nghiên cứu agent lập lịch thông minh
• Reddit discussion: "Cron reliability issues in OpenClaw" — Thực tế triển khai và lỗi thường gặp khi agent cron "không chịu dậy"