一个真正自主的 Agent 不能只在人类发消息时才工作。我们的 OpenClaw 系统运行 54 个 cron 任务，覆盖 7 个域：投资（盘前分析、盘中监控、盘后总结、买入点监控）、研究（AI 前沿追踪、RSS 日报、Deep Block 深度探索）、运维（系统自查、文档审计、进程清理）、安全（月度红队、安全事件回顾）、记忆（每日反思、记忆压缩、VML 索引）、内容（社媒巡逻、选股研究）、评估（日报、周报、Golden Test）。这不是一个 crontab 文件——是一个有依赖关系的任务 DAG。

最大的工程挑战是资源竞争。早期我们让 Nous 自动迭代循环每小时跑一次，用 Opus 模型，maxConcurrentRuns=5。结果：NAS 虚拟机内存 6G 上限被打满，其他 cron 全部超时。修复：Nous 循环从 1h 改 4h，模型从 Opus 降到 Sonnet，maxConcurrentRuns 从 5 降到 1，时间错峰避开其他高负载任务。systemd 加了 MemoryHigh=5G / MemoryMax=6G / MemorySwapMax=2G 硬限制。

静默失败是比崩溃更危险的问题。一个 cron 任务超时了，它不会报错——它只是不产出。我们有三个任务连续三周超时才被发现：eval-weekly 因为 Flash 模型在会话层做多余操作，导致每次都卡在 60 秒上限。修复：payload.timeoutSeconds 提升到 300，bash 层加 timeout 120 硬杀，prompt 极简化去掉无关指令。教训：每个 cron 任务必须有可观测的输出——要么 announce 到频道，要么写文件，delivery=none 的任务更容易静默失败。

时间编排的原则：关键路径不能有冲突。盘前分析 08:30 必须在开盘 09:30 前完成——它不能和其他重计算任务撞车。买入点监控 10:30/11:30/13:30/14:30 四个时间点分散在盘中，每次执行时间控制在 2 分钟内。盘后数据更新 15:35 紧贴收盘，evaluation 16:00 依赖盘后数据。夜间 22:30 的反思任务是最重的——记忆合并、VML 索引、状态回写——给它最多的时间窗口和资源。

54 个任务已经接近人工维护的上限了。每次加一个新 cron 都要检查时间冲突、资源占用、依赖关系。我们已经修了 9 次 cron 相关的 bug（T3 自阻塞、ontology-gate 误拦 cron prompt、eval-daily 输出规则冲突、eval-weekly 反复超时等）。下一步可能需要一个 cron scheduler 的可视化面板（Cockpit 已经有 Cron 钟的雏形），以及自动冲突检测。从更大的视角看，cron 编排是 Agent 自主性的基础设施——没有它，Agent 就只是一个被动的聊天机器人。