前面几篇搭好了"人查 Agent"的被动体系。本篇回答最后一块拼图：怎么把"人查 Agent"变成"Agent 主动找人"——四类 cron 任务的实测配置、cron 失败三板斧、以及让体系自愈的主动巡检闭环。

定时任务体系：让 Agent 体系"活起来"的 cron 实践

01–06 篇搭出来的体系有个共同特征：都是"人查 Agent"——你问它才答，你不问它就闲着。这套体系是"被动"的。本篇回答最后一块拼图：怎么把"人查 Agent"变成"Agent 主动找人"。 靠的是 cron 定时任务 + 一套"主动巡检自愈"的闭环。

先说结论：

1. cron 是让 Agent 体系从"工具"变成"助理"的分水岭——工具是你用的，助理是它来找你的。
2. 四类任务各有用途：内容型、待办型、巡检型、汇总型。
3. cron 失败三板斧（时间错开 / 超时调大 / 手动触发验证）能解决绝大多数问题。
4. 最关键的一条：让"巡检 Agent"去巡检"其他任务"，形成自愈闭环——这是"主动找人"的最高形态。

一、为什么 cron 是"从工具到助理"的分水岭

被动体系的天花板很明显：Agent 再聪明，你不去问它，它就永远在暗处。你的待办没人提醒、市场异动没人播报、任务失败了没人管——这些"该发生但没人触发"的事，全卡在"谁来发起第一步"上。

cron 解决的就是"谁来发起"：由时间触发，Agent 主动干活、主动推送。 三个标志性的转变：

• 你早上不用翻笔记看今天有什么事 → 每天 8:00 一条待办简报推到 IM
• 你不用天天盯着行业新闻 → 每天 5:00 / 6:30 两条内容简报自动入库 + 推送
• 任务失败了没人知道 → 每小时巡检 Agent 自动发现、自动修

"助理"和"工具"的分界，就画在"它会不会主动来找我"这条线上。cron 是画这条线的唯一手段。

二、四类任务（实测配置）

我这套体系里的 cron 任务，按用途分四类，全部实测在跑：

三条配置铁律（从实测沉淀，直接给结论）：

• timeoutSeconds 留足：内容型任务是"多轮搜索 + 生成"，实测 90–292 秒。超时贴脸，任务会在"快完成了"被掐断。我的做法：按手动触发实测耗时的 2–3 倍设超时（292s 的任务给 1800s）。
• 触发时间错开：两个任务别挤在同一分钟。isolated session 池会资源竞争，表现是 Request was aborted（几百 ms 就终止）。我错开到 5:00 / 6:30 解决。
• 待办型是"口述即记录"闭环的读端（09 篇细讲）：你平时想到什么就往全局待办文件丢一句，cron 每天 8:00 读它、按优先级排序、给建议，推到你手机上。

三、cron 失败三板斧

排查 cron 任务失败，按顺序用，覆盖绝大多数情况：

第一板斧：时间错开（治资源竞争） 症状 Request was aborted 且耗时极短——多个任务同时触发，session 池竞争。错开触发时间。

第二板斧：超时调大（治"快完成被掐"） 症状 Job execution timed out——任务真实耗时贴着上限。先看手动触发的真实耗时，超时调到 2–3 倍。

第三板斧：手动触发验证（治"不敢乱改"）

前两条是"猜"，这条是验证：

openclaw cron run <job-id>     # 手动触发一次，复现真实耗时

然后看四个状态字段定位卡在哪一环：

手动触发把"定时"变量去掉了：手动能跑通、定时跑不通 → 锁定在触发时间/资源竞争；手动也跑不通 → 任务本身（超时/模型/逻辑）的问题。

四、主动巡检闭环：让 Agent 巡检 Agent

前三节是"人管 Agent"，这里翻过来：让一只专门干运维的蜂（我叫它"微澜"）去巡检其他所有任务，发现异常自动修。 这是"主动找人"的最高形态——人不再去查，体系自己会查自己。

微澜每小时跑六步：检查任务状态 → 识别异常 → 诊断根因 → 应用修复（超时调大/切模型/强制重跑）→ TDAI L0 记忆泄漏巡检（06 篇的防复发手段）→ 记报告 + 清理 3 天前记录。

关键设计：自动修复有边界。

• 可以自动修：超时调大、模型回退切换这类"机械型"故障——直接动手。
• 必须人授权：涉及业务逻辑的改动（任务该不该存在、产出内容对不对）——只报告、只留痕，不下手，等人拍板。

让 Agent 自愈可以，但不能让它"自作主张改我的业务"。这条边界必须写死在 SOP 里。

五、交付静默原则

Agent 主动推送有边界，不是"有事没事都发"。两条纪律：

• 23:00–08:00 非紧急不打扰——凌晨任务跑完先存着，早上一条汇总。
• 结果推 IM，不靠人查——交付走消息通道，不是"生成在某个目录里等我自己去看"。一旦要人主动去查，就又退化回"工具"了。

六、最终结论与教训

1. cron 是"工具 → 助理"的分水岭：没有它，再聪明的 Agent 也只是被动等着被问的工具。
2. 失败三板斧按"猜 → 验证"用：时间错开、超时调大是"猜"，手动触发 + 看四个状态字段是"验证"。
3. 让 Agent 巡检 Agent，但给自动修复画边界：机械型故障自愈，业务逻辑人拍板。
4. 生成成功 ≠ 送达成功：lastRunStatus 和 lastDeliveryStatus 两个字段都要看。只看了前者，你会带着"任务没问题"的错觉漏掉"东西没送到人手上"。
5. "先跑通再修" 是排障通用纪律（08 篇还会再遇到）：把链路拆成能单独验证的最小段逐段通，别整段混着调。

一句话总结：cron 给了 Agent 体系"主动性"，但主动性要配两样东西才守得住——失败三板斧（排障手段）和巡检闭环（自愈机制）。缺一，体系迟早从"助理"退化回"工具"。

下一篇预告：《08｜运维踩坑合集：备份链、模型回退、更新故障》——让这套体系 7×24 稳定运行的工程纪律：备份链怎么留、密钥怎么管、模型 fallback 回退链怎么配、以及"更新失败三兄弟"的固定 SOP。

互动：你的 Agent 体系里有"主动推送"吗？还是也停在"你问它才答"？评论区聊聊。