很多 AI agent 团队都会在某个阶段被一句话推动去做自动化：既然这件事每天都要做，为什么不让 agent 定时跑？这句话听起来非常合理，所以日报汇总、客户数据同步、内容巡检、工单分流、报表生成，很快都会被塞进 cron 或任务队列里。第一周看起来常常也还不错，任务自动开始、自动完成、自动发消息，效率提升很直观。
问题是，scheduled run 真正难的地方从来不是“按时触发”，而是“重复运行时怎么保持边界稳定”。一旦你把 AI agent 放进 recurring automation，你就会同时碰到这些现实问题：输入数据每天都在变、外部系统会晚到、时区和节假日会错位、前一天失败的任务到底要不要补跑、补跑时会不会把已经发出的副作用再发一次。
所以 recurring automation 不是给现有 run 外面套一个 cron，而是重新定义 run identity、时间窗口、可补偿范围和人工接力规则。没有这层设计，所谓“自动化”很快会从省人力变成天天早上第一件事就是查异常。
建议结合 AI agent Deadline 与超时预算、AI agent 幂等与去重实践、AI agent 准入控制与配额闸门 和 AI agent Harness 崩溃恢复与 Wake 流程 一起看。
先分清你在做哪类“定时”
| 自动化类型 | 典型例子 | 真正要管的变量 |
|---|---|---|
| 固定时点执行 | 每天 08:00 生成日报 | 时区、节假日、迟到数据 |
| 时间窗口执行 | 每小时巡检一次异常站点 | 窗口重叠、补跑范围、失败回补 |
| 业务截止前执行 | 每周一 09:00 前给销售准备线索 | deadline、优先级和人工接管 |
| 事件堆积后的批处理 | 夜间统一处理白天积压任务 | catch-up、吞吐、幂等和速率限制 |
如果系统把这些场景都统称为“cron job”，后面几乎一定会在补跑语义上混乱。因为同样是“昨天没跑成”，日报和巡检的补跑价值并不一样。
Scheduled run 的 identity 应该包含窗口，不该只有时间戳
最常见的设计错误，是把 recurring automation 的 runId 建成“某时刻触发了一次任务”。这样看起来简单，但一旦补跑和重试混进来，系统就会分不清：
- 这是 2026-05-13 08:00 的正式日报
- 还是那次日报的补跑
- 还是那次补跑里的某个 step 重试
更稳的做法，是让 run identity 显式包含业务窗口。例如：
{
"jobKey": "daily_sales_brief",
"window": "2026-05-13@Asia/Shanghai",
"executionType": "primary | catchup | retry",
"idempotencyKey": "daily_sales_brief:2026-05-13"
}
一旦窗口被建进 identity，系统才能判断“今天这份日报到底已经有没有成功产出过”，而不是被时间戳和重试次数绕晕。
真正麻烦的不是错过触发，而是输入在窗口结束后还会变
很多 recurring automation 会天然面对迟到数据。比如凌晨 1 点跑跨境订单汇总，可某些支付回执 1 点 20 才到；8 点生成日报，但部分 CRM 字段 8 点 10 才同步完。于是系统必须回答一个现实问题：你要冻结输入，还是接受迟到后补？
这件事没有统一答案，但必须提前定规则：
- 如果目标是高一致性报表，就应该冻结窗口，并把迟到数据归到下一次或补报流程
- 如果目标是尽快给业务一个近似结果，可以允许 late update，但必须标记“这是修订版”
最糟糕的情况是系统什么都没定义，只是一边默认按点触发，一边又允许无标记补写。最后用户手上看到的每一份“自动生成结果”都不确定是不是最终版本。
自动化的稳定不靠“永不失败”，靠 catch-up 边界清楚
每个 recurring job 都应该回答：
- 错过一轮后要不要补跑
- 可以补多少轮
- 补跑时是否降级，例如只生成内部结果，不自动外发
- 如果 backlog 已堆积，是否应该先限流而不是全部追上
这些规则如果没有，任务队列很容易在一次外部系统抖动后集体补跑，把模型额度、第三方 API 配额和人工审核队列一起打爆。很多团队把这叫“恢复”，其实是把昨天的故障变成今天的更大故障。
一个经常被忽视的事故：夏令时和节假日比模型还容易把自动化搞坏
某团队给全球销售团队做每周线索摘要，默认每周一早上 8 点发送。功能本身没问题，直到一轮夏令时切换后，欧洲区的摘要在本地时间 9 点才发出，而亚洲区恰好遇到当地法定假期，自动外发的摘要没人处理。更麻烦的是：
- 系统按 UTC 定时，没有业务区域窗口概念
- 节假日没有 pause policy
- 同一 job 在不同区域共享一个“本周已发送”标记
结果是某些区域延迟，某些区域误判为已完成，还有一些区域把节假日积压任务在第二天早上一起补发。
最后修复不是“把 cron 写复杂点”，而是给 job 加了 business calendar、region-specific window 和 pause / resume contract。这个例子很能说明问题：自动化的真实复杂度往往来自业务日历，而不是模型调用本身。
真正值钱的自动化，不是无人值守，而是可预测
很多系统做 recurring automation 的心态像在追求全自动驾驶，希望任务从此不需要人看。但在企业环境里，更现实的目标通常是：
- 任务什么时候会跑，大家能预测
- 任务错过后会怎么补，大家能预测
- 自动化不该做的副作用，系统会自己刹住
如果你现在要先做一件事，优先把每个 recurring job 的 window、catch-up 和 side-effect policy 写清楚。只要这三件事说不明白，自动化跑得越勤，系统就越像在重复放大自己的边界错误。
延伸阅读：
