Lịch chạy không phải là biên tập viên tự chủ
“Lấy Markdown gốc, sửa rồi đăng.”
Nghe cực kỳ đơn giản.
Cho đến khi bạn tự động hóa nó.
Hệ thống phải đọc Markdown, quyết định có đủ điều kiện đăng chưa, kiểm tra 12 ngôn ngữ, xóa tiêu đề thừa, kiểm tra liên kết, xuất bản, mở trang thật để xem, quay lại nếu lỗi, tìm nguyên nhân, sửa, chạy lại rồi kiểm tra xem có làm hỏng chỗ nào khác không.
Đột nhiên băng chuyền còn phải kiêm luôn tổng biên tập.
Vấn đề không phải Cloudflare Workers, tác vụ hẹn giờ hay GitHub Actions yếu.
Chúng giỏi một loại việc khác.
Tự động hóa truyền thống rất mạnh khi lặp lại quy trình đã biết. Nhà máy nội dung lại nhận văn bản khác nhau và lỗi khác nhau. Nhiều trường hợp cần đọc, hiểu, sửa và xác minh.
Đó là bài toán của agent nhiều hơn là bài toán cron.
1. Cùng một pipeline không có nghĩa là cùng một công việc
Nhà máy bài viết trông giống sản xuất hàng loạt.
Đầu vào: Markdown. Đầu ra: bài đã xuất bản.
Vì vậy rất dễ nghĩ chỉ cần chạy cùng một quy trình 100 lần.
Nhưng văn bản không phải con ốc tiêu chuẩn.
Bài A có tiêu đề kỳ lạ. Bài B thiếu một trong 12 ngôn ngữ. Bài C đã dịch nhưng dùng cụm từ người địa phương không tìm kiếm. Bài D vô tình đưa ghi chú SEO nội bộ vào nội dung. Bài E có liên kết tiếp thị hợp lệ nhưng đặt ở vị trí rất vô lý. Bài F đã xuất bản thành công nhưng trạng thái vẫn ghi “đang chạy”.
Tất cả đều nằm trong cùng quy trình xuất bản.
Nhưng cách sửa khác nhau.
Đầu vào thay đổi thì hình dạng lỗi cũng thay đổi.
2. Scheduler rất giỏi chạy công việc đã biết
GitHub Actions chạy workflow được định nghĩa trước khi có sự kiện, kích hoạt thủ công hoặc đến lịch.[1]
ChatGPT Scheduled Tasks cũng chạy tác vụ vào thời gian đã chọn hoặc khi có sự kiện được hỗ trợ.[2]
Cloudflare Workers rất mạnh cho xử lý request, công việc định kỳ và kết nối dịch vụ.
Các hệ thống này trả lời tốt:
“Khi nào chạy?” “Chạy script nào?” “Lệnh vừa rồi thành công chưa?” “Nếu điều kiện này đúng thì bước tiếp theo là gì?”
Nhưng những câu hỏi sau là chuyện khác:
“Tiêu đề này có giống dịch máy quá không?” “Đoạn này đúng, nhưng có ích cho người đọc không?” “Liên kết hợp lệ, nhưng tại sao lại đặt ở đây?” “Lỗi hôm nay có thật sự giống lỗi hôm qua không?”
Scheduler có đồng hồ.
Nó không tự nhiên có trực giác của biên tập viên.
3. Phần khó nhất là khép kín cả vòng lặp cải tiến
Không chỉ là sửa một lần.
Phải làm đủ:
phát hiện lỗi, chẩn đoán nguyên nhân, sửa, chạy lại, kiểm tra kết quả thật, tìm tác dụng phụ, và thử giả thuyết khác nếu lần sửa đầu sai.
Con người làm việc này khá tự nhiên.
Trong tự động hóa, từng chuyển trạng thái phải được thiết kế.
Khó chịu nhất là “thành công một nửa”.
Trang đã đăng nhưng trạng thái chưa cập nhật.
Bản dịch hoàn tất nhưng một ngôn ngữ trống.
Repository đã đổi nhưng production chưa cập nhật.
Nếu chỉ chạy lại tất cả, có thể xuất bản trùng hoặc xử lý trùng.
Vì vậy tự động hóa bền vững không chỉ nhắm đến “không bao giờ lỗi”.
Nó cần:
chạy lại mà không làm hỏng kết quả cuối.
Cloudflare Workflows hỗ trợ các bước bền vững, lưu kết quả và retry; tài liệu cũng nhấn mạnh việc thiết kế thao tác an toàn khi được lặp lại.[3][4]
4. Cloudflare giỏi phục hồi, nhưng phục hồi không phải phán đoán biên tập
Cloudflare Workflows có thể lưu trạng thái của quy trình nhiều bước, retry bước bị lỗi và tiếp tục từ phần đã hoàn thành.[3]
Cloudflare Queues có thể retry và đưa thông điệp thất bại nhiều lần vào Dead Letter Queue.[5]
Điều này rất phù hợp với:
lỗi mạng tạm thời, API thất bại, timeout, thông điệp liên tục xử lý không được, công việc phải tiếp tục sau.
Nhưng có một loại vấn đề khác:
“Tiếng Tây Ban Nha hiểu được, nhưng người địa phương không tìm bằng cách này.”
“Nội dung đúng, nhưng tiêu đề phụ này làm bài khó đọc hơn.”
Tăng retry từ 3 lên 10 không tạo ra năng lực biên tập.
Nó chỉ có thể lặp lại cùng một lỗi 10 lần rất đều đặn.
Retry không thay cho phán đoán.
5. GitHub Actions là bàn làm việc tốt, không phải biên tập viên tự chủ
GitHub Actions rất hữu ích cho việc có quy tắc rõ ràng.
Chạy test. Kiểm tra file. Build. Deploy khi đạt điều kiện. Chạy script định kỳ.
Đó là thế mạnh của nó.[1]
Nhưng Actions không tự đọc bài rồi nghĩ:
“Vấn đề thật ra nằm ở phần mở đầu chứ không phải tiêu đề.”
Có thể gọi AI trong workflow.
Nhưng khi đó bài toán khó chuyển thành:
AI cần thấy ngữ cảnh gì, được phép sửa gì, xác minh kết quả thế nào, và tiếp tục ra sao sau khi lỗi.
Đưa chương trình họp biên tập cho máy khoan rồi trách nó không điều phối được cuộc họp thì hơi oan cho máy khoan.
6. Tách đường bình thường và đường ngoại lệ tốt hơn cố đạt 100% tự động
Nhà máy thực tế nên có hai luồng.
Luồng bình thường: máy xử lý thứ kiểm tra được
Ví dụ:
- có đủ file bắt buộc
- đủ 12 ngôn ngữ
- không có trường trống
- URL đúng định dạng
- ID không trùng
- lệnh xuất bản thành công
- trang production truy cập được
Workers, script và Actions rất hợp cho phần này.
Luồng ngoại lệ: cô lập lỗi và tiếp tục
Một bài lỗi không nên dừng cả dây chuyền.
Ghi lại lý do. Đưa bài đó sang một bên. Tiếp tục bài tiếp theo.
Có thể phân loại:
- thiếu ngôn ngữ
- cấu trúc sai
- lỗi liên kết
- lỗi xuất bản
- cần xem xét nội dung
- chưa rõ nguyên nhân
Nếu 90 trong 100 bài qua tự động thì xuất bản 90 bài đó.
Không cần bắt 90 bài khỏe mạnh đứng chờ vì 10 bài còn lại đang gặp khủng hoảng.
Bỏ qua ngoại lệ và tiếp tục.
7. Giao ngoại lệ cho agent có thể đọc repository
Ngoại lệ thường cần đọc, suy luận, sửa và xác minh.
Đây là nơi coding agent phù hợp.
Tài liệu Codex Cloud mô tả các tác vụ trong môi trường dự án đã chuẩn bị, nơi agent có thể điều tra lỗi, thay đổi mã, chạy kiểm tra và tiếp tục cùng tác vụ đám mây trên thiết bị được hỗ trợ.[6]
Trong nhà máy nội dung, agent có thể là bàn sửa chữa:
lấy bài thất bại, đọc Markdown gốc, xem kết quả tạo ra, đọc nhật ký lỗi, xem code nếu cần, sửa, chạy kiểm tra, đăng lại, và xem trang thực tế.
Không cần tiêu tốn khả năng suy luận mạnh cho mọi trường hợp bình thường.
Việc dễ để máy làm.
Việc lạ để agent xử lý.
8. Khi một ngoại lệ lặp lại nhiều lần, biến nó thành quy tắc tự động
Hàng đợi ngoại lệ không nên thành bãi rác vĩnh viễn.
Nếu cùng một lỗi xuất hiện nhiều lần, nó không còn là ngoại lệ. Nó là mẫu.
Nếu một ngôn ngữ thường xuyên bị thiếu, thêm kiểm tra tự động.
Nếu cùng một tiêu đề thừa hay lọt vào, thêm validator.
Nếu xuất bản thành công nhưng cập nhật trạng thái thường lỗi, kiểm tra trang production trước rồi tự sửa trạng thái.
Trình tự hợp lý là:
cho nhà máy chạy, thu thập lỗi thật, dùng agent sửa trường hợp hiếm, tìm mẫu lặp, sau đó chỉ tự động hóa các mẫu thường gặp.
Cố dự đoán mọi lỗi trước khi chạy thật là cách tuyệt vời để xây nhà máy mãi mãi mà không sản xuất gì.
Kết luận: scheduler là băng chuyền, agent AI là bàn sửa chữa
Cloudflare, tác vụ hẹn giờ và GitHub Actions có thể gây thất vọng nếu ta mong chúng hoạt động như biên tập viên tự chủ.
Nhưng đó là hai vai trò khác nhau.
Hệ thống theo lịch nên:
khởi động, kiểm tra điều kiện rõ ràng, đẩy trường hợp bình thường đi tiếp, cô lập trường hợp lỗi, và giữ dây chuyền chạy.
Agent nên trả lời:
“Tại sao bài này kỳ lạ?” “Cần sửa gì?” “Sửa xong thật sự ổn chưa?”
Kiến trúc thực tế rất đơn giản:
Tự động hóa đường dễ. Không để một ngoại lệ chặn cả lô. Chỉ gửi ngoại lệ cho agent. Ngoại lệ lặp lại thì biến thành quy tắc máy.
Nhà máy nội dung không cần một băng chuyền biết suy nghĩ về mọi thứ.
Nó cần một băng chuyền không dừng và một bàn sửa chữa thông minh cho những hộp rơi khỏi dây chuyền.
- GitHub Docs, Workflows docs.github.com
- OpenAI Help Center, Scheduled tasks in ChatGPT help.openai.com
- Cloudflare Docs, Build your first Workflow developers.cloudflare.com
- Cloudflare Docs, Rules of Workflows developers.cloudflare.com
- Cloudflare Docs, Dead Letter Queues developers.cloudflare.com
- OpenAI Help Center, Using Codex Cloud help.openai.com
