零成本运维：5 人 AI Agent 团队的 cron 治理

50 个定时任务，5 个 AI Agent，1 个人管。没有运维 SaaS、没有告警平台、没有值班排班。凌晨三点，六个任务同时醒来，抢着用同一张显卡。

这篇文章记录的是我们的 AI Agent 团队怎么用 cron 治理这套系统——调度、监控、降级、自愈，四板斧，零成本。

┌─────────────────────────────────────────────────────┐
│                   ModelBase 服务器                     │
│         双卡 RTX 2080 Ti（44 GB）+ llama.cpp           │
├─────────────────────────────────────────────────────┤
│  韩梅梅(cron 主调度)                                  │
│    ├──> 投资决策 14 个任务                            │
│    ├──> 内容发布 8 个任务                             │
│    ├── 李雷 ──> 研发优化 7 个任务                     │
│    ├── 露西 ──> 数据采集                              │
│    ├── 小美 ──> 舆情监控                              │
│    └── 小瑞 ──> 心跳保活                              │
│         心跳 + PDCA 双层监控                           │
└─────────────────────────────────────────────────────┘
        50 个 cron | 37 个启用 | 0 元/月

先认识一下团队

我们的团队不是 5 个独立运行的 Agent，而是一个有分工的协作体，全住在一台服务器上：

成员	角色	干什么
韩梅梅	总调度 + 投资主管	50 个 cron 全挂在她名下，负责投资决策、日记、日报、博客发布
李雷	研发工程师	夜间被韩梅梅派遣，跑策略深挖和参数网格搜索
露西	数据采集员	凌晨采集宏观数据（美元/黄金/原油/VIX）、统计局数据
小美	内容编辑	B 站/YouTube 舆情监控、知识库更新
小瑞（Polly）	备用	心跳保活，随时待命

硬件就一台 ModelBase 服务器，双卡 RTX 2080 Ti 魔改版，单卡 22 GB，双卡共 44 GB。推理引擎是 llama.cpp，加载 Qwen 系列模型，走 new-api 代理层统一调度。没花一分钱买运维工具。

第一板斧：任务分层

50 个 cron 不是一锅粥。按职能分成四个象限，每个象限有独立的优先级和容错策略：

• 投资象限（P0）：盘前简报、盘中分析、收盘复盘等 14 个任务。失败立即告警，重试 3 次。全部锁在工作日（1-5），周末自动休眠——因为量化交易每天开盘就要用。
• 内容象限（P1）：早午晚报、B 站舆情、YouTube 监控等 8 个任务。失败静默，下个周期补。晚报没发出来天塌不下来。
• 研发象限（P2）：AutoQuant 优化、ReShare 优化、OpenCode 改代码等 7 个任务。失败跳过，只记日志。这些是「自驱动」的——AutoQuant 每日优化（30 1 * * *）会在凌晨自己找代码改进点，ReShare 优化（10 4 * * *）会自动修数据管道的 bug。Agent 自己改自己的代码，人类只看日报。
• 运维象限（P0）：心跳、系统巡检、健康扫描、日记等 8 个任务。失败连续 3 次才告警，容忍单次抖动。

第二板斧：错峰调度

50 个任务全挤在一个时间点跑，显卡会爆。看看凌晨的调度热力图：

高峰在凌晨 3 点——6 个任务同时醒来。这曾经出过事：collect_cron_results 在 03:00:23 跑起来汇总状态时，其他任务才启动 23 秒，还没跑完，全被误判成失败。连续三天假阴性。

解法是错峰。同在 3 点的 6 个任务，按分钟偏移错开：

任务	原时间	错峰后
Round 1 大周期筛选	03:00	03:05
韩梅梅日记	03:00	03:10
OpenCode 代码改进	03:00	03:05
QFII 持仓采集	03:00	03:15
日记博客发布	03:00	03:45

错峰的核心不是让任务跑得更快，是让它们别互相踩。collect_cron_results 现在放到所有任务之后才跑，看到的是终态，不是中间态。

第三板斧：静默治理

50 个任务如果每个都发报告，一天能收 50 条消息。没人看得过来。

静默铁律：全部正常时返回 [SILENT]，不发任何消息。只有异常或修复时才报告，而且不超过 500 字。

这个规则写在每个 cron 的 prompt 里。比如系统 PDCA 任务：

输出规则：全部正常时返回 [SILENT]，不发送报告。
有异常或修复时报告不超过 500 字。

心跳任务（0 * * * *，每小时一次）也是静默的。24 小时跑 24 次，正常时你一条消息都收不到。只有在连续失败、或者检测到偏差时，才会在飞书群里弹出一张心跳卡片。

效果是：安静等于健康，吵闹才是问题。我从每天刷 50 条消息，变成一天只收到两三条——全是真正需要处理的。

第四板斧：健康监控

静默有个副作用：任务挂了你可能不知道。所以需要两层保险。

第一层：心跳保活。 韩梅梅每小时跑一次心跳（agent-heartbeat 技能），检查所有 Agent 的存活状态。连续 3 次没心跳才告警——容忍单次抖动，但不容忍持续死亡。

第二层：每日系统 PDCA。 凌晨 4 点，一个专门的 sys-pdca 任务会做完整系统体检：检查进程池、扫描日志已知模式、跑健康检查清单。发现问题自动修，修不了才报告。

这两层叠加，形成「实时心跳 + 每日体检」的监控闭环。心跳管「活没活」，PDCA 管「好不好」。

成本账

零成本是怎么算的：

项目	传统方案成本	我们的方案
定时调度	AWS EventBridge / 阿里云定时任务，约 $20/月	Hermes Agent cron 引擎，0
监控告警	Datadog / Grafana Cloud，约 $15/月	心跳 + PDCA + 飞书卡片，0
日志聚合	ELK Cloud / Loki Cloud，约 $30/月	本地 state.db + 日记 cron，0
运维人力	1 个兼职运维	1 个 Agent 自治，0

硬件折旧不算（反正本来就有）。模型推理用自己的显卡，不走 API 计费。唯一的外部依赖是飞书机器人做消息推送——免费额度够用。

总账：每月 0 元。 代价是前期搭体系花了时间，以及你得自己写 PDCA 技能。

踩过的坑

这套体系不是一次成型的。记录三个真金白银的教训：

坑一：并发抢占。 凌晨 3 点 6 个任务同时启动，显卡显存不够分。解法就是上面说的错峰调度——按分钟偏移，别全挤在整点。

坑二：假阴性。 collect_cron_results 把正在运行的任务误判成失败，连续三天。根因是检测时机不对——任务刚启动 23 秒就去查状态，当然还没完成。教训：删症状不等于修根因，第一天删报错记录没用，得改检测逻辑本身。

坑三：Token 限流。 夜间是批量窗口，多个任务同时调模型，会把 new-api 代理层的 Token 配额打满。解法是给重任务降优先级——研发类任务（AutoQuant 优化、OpenCode）排到凌晨 1 点和 3 点，避开投资类任务的高峰。

这套体系适合谁

如果你也满足这几个条件，可以照搬：

• 有自己的 GPU 服务器（不用很大，双卡 2080 Ti 够了）
• 用 Hermes Agent 或类似的 Agent 框架，支持 cron 调度
• 有多个 AI Agent 需要协作（不一定是 5 个，2 个也行）
• 不想为运维花钱，但愿意花时间搭体系

不适合的场景：任务数少于 10 个（杀鸡用牛刀）、需要严格的 SLA 保证（这套没有秒级监控）、或者纯用 API 不自建推理（那 Token 费就是主要成本了）。

50 个 cron 跑 5 个 Agent，每月 0 元运维。不是因为我们抠门，是因为这套系统自己会管自己。

参考

• 非定时任务衰减律：「记得做」等于「不会做」 — 为什么不定时任务会自动消失
• 删症状≠修根因：collect_cron_results 连续三天假阴性的教训 — 假阴性事件的完整复盘
• 谁来看守看守——自治 AI Agent 系统的静默故障与元监控设计 — 元监控的设计思路
• Hermes Agent 官方文档 — cron 引擎和 Agent 调度