一条停了七天的任务
那天翻自动化任务的监控面板，我看到云端一条每天深夜跑的任务，状态是红的。
它是一个资料补全任务，抓外部 API 把本地库缺的字段填上，工作日每天 23:55 触发。最后一次执行记录停在 7 月 13 日，进度 65%。到我看见它的时候，已经整整七天没动过。
没有告警。没有失败记录。它只是不跑了，而我以为它每天都在跑。
同一天我还发现另一件事：本地和云端各有一条任务，同一个数据源、同一个操作目标、同一个触发时间。两边都在做同一件事，做了两个星期。
于是我停下来做了一次审计。
第一步：把两边的任务全摆到一张表上
不要凭记忆列。从调度器里把配置导出来，逐条填表：
| # | 执行方 | 触发时间 | 频率 | 上次运行 | 状态 | 输入 / 输出 |
|---|---|---|---|---|---|---|
| 1 | 云端 | 每日 03:00 | 每日 | 07-06 ✅ | 正常 | 外部源 → 本地库 |
| 2 | 云端 | 工作日 23:55 | 工作日 | 07-13 🔴 | 停滞 7 天 | 外部 API → 字段补全 |
| 3 | 本地 | 周日 11:30 | 每周 | 07-06 ✅ | 待恢复 | 邮件 → 网站入库 |
| … |
7 月 20 日那份面板上的数字是：云端 10 条，本地 8 条（其中 1 条已禁用），合计 18 条。
最后一列是关键。前面几列调度器里都有，只有“输入 / 输出”需要你手动补——而这一列决定了下一步会不会砍错。
第二步：分清三种关系，别急着砍
填完表再逐对比较，每对关系归入三类之一：
直接重叠 → 去掉执行方标签后，任务描述可以互换
同一个数据源 + 同一个操作目标 + 同一份输出
处理：留一个，禁一个
流水线上下游 → A 的输出是 B 的输入，有时间先后依赖
处理：都留，统一命名前缀
互补无冲突 → 各管不同领域，无交集
处理：不动我差点在第二类上犯错。
云端周日 09:00 生成一份周报邮件，本地周日 11:30 读邮件把内容入库到网站。两条任务名字长得很像，触发时间只差两个半小时，功能描述都带“周报”两个字。按名字判断，这就是重复。
但它不是。前者产出邮件，后者消费邮件。砍掉任何一条，整条链路当场断掉——邮件没人读，或者根本没邮件可读。
判断依据只能是输入输出，不能是名字相似度。
第三步：比的不是谁写得好，是谁跑得起
确认真正重叠之后，选留哪一边。我用的比较维度是三个：
- 额度单价：两边计费方式不同，同样一次执行的真实成本差好几倍
- 执行稳定性：谁的历史失败率低，谁的降级链更完整
- 数据访问位置：需要直接碰本地文件系统和 git 的活，云端做不了；需要抓网页、发邮件的活，本地做更绕
那条资料补全任务最后是云端独占，因为它主要是外部 API 调用，云端更便宜也更稳。本地那条禁用。
第四步：报告归 AI，签字归人
审计的采集、分类、成本比较，我全交给 Agent 做。它做得比我细，也不会漏。
但停用这一步必须我自己点。
这不是不信任。是因为有一类信息 Agent 拿不到：资产归属。
我遇到过这样的情况：让它清理一批空转任务，它按“空转”这个标准执行得很彻底，其中有些其实不在它的管辖范围内。判断本身没错——那些任务确实在空转；缺的是“这个归谁管”这个维度，而这个维度我没在授权时讲清楚。
授权范围和资产归属是两件事。你授权它做判断，不等于授权它处置所有东西。边界没划清，责任在授权的人。
所以现在面板上写死一条：任何停用动作，Agent 只能提议，人来签字。
第五步：禁用，不删除
disable 和 delete 是两个动作，别混用。
禁用保留了三样东西：原始配置、历史执行记录、随时恢复的能力。审计判断错了——比如把流水线误判成重叠——一条 enable 就能退回来。删了就得重写，而重写时你已经不记得当初的触发时间和 prompt 细节。
勤俭持家和一刀切的区别就在这里：前者是可逆的。
第六步：自检也要按需，别变成新的浪费
去重之后，被保留的跨方任务需要一个核查机制。但核查任务自己也烧额度。
我一开始想的是每天巡检，后来发现这是花钱雇人看着花钱。改成两条：
- 低频抽查：每周一次，排在被核查任务的执行日之后
- 异常才展开：正常就一行记录，异常才写详细报告并通知
核查任务的 prompt 大致长这样：
读取 <进度文件>，确认本周是否有新的执行记录。
如果有：随机抽 5 条输出检查完整性，一行记录结果。
如果没有：标记停滞，写明最后一次执行时间，通知我。
不要修复，不要重跑，只报告。最后那句“不要修复，不要重跑”很重要。核查任务的职责是发现问题，不是自己上手——否则它会变成第三个消耗源，而且你分不清问题是被修好了还是被掩盖了。
三个反直觉的发现
最贵的不是重复跑，是静默失败。 重复跑浪费的是双份额度，账面上看得见。那条停了七天的任务，浪费的是七天的数据缺口，而我完全不知情。定时任务最大的成本不是 token，是你以为它在工作。
建了没跑过的任务也有成本。 云端 10 条里有 6 条状态是“待首次运行”，建了两个星期一次没跑过。它们不烧额度，但烧维护注意力——每次看面板都要重新判断一遍“这条是干嘛的、为什么没跑、还要不要”。配置本身就是一种负债。
10 条里只有 2 条是绿的。 剩下的是 6 条没跑过、1 条停滞、1 条待审查。这个比例比我审计前预估的差得多。我原以为问题是“有些任务重复了”，实际问题是“大部分任务根本没在工作”。
一条原则
定时任务的默认状态应该是关着的。每一条能长期跑下去的任务，都得靠一次真实的产出来续期，而不是靠“当初建它的时候觉得有用”。
审计检查清单：
- 任务全量清单是从调度器导出的，不是凭记忆列的
- 每条都填了输入 / 输出，重叠判断基于此而非名字
- 停用动作由人签字，Agent 只提议
- 用 disable 不用 delete
- 核查任务是低频的，且明确“只报告不修复”
关于这套做法背后的成本观，我另写了一篇 AI 的待机功耗，讲为什么“勤俭持家”在自动化这件事上不是抠门。