定时任务合理性与负载/死锁巡检

识雷达与 llm-wiki 自我优化 12:00`，agent/local - `40025af06ee9 / RMS线上发版/配置变更跟踪`，every 30m/no-agent，next run 也是 `12:00` - 风险判断：一个 agent + 一个 no-agent 同时跑，当前风险中等偏低；如果 12 点任务常做浏览器/网络操作，可能叠加负载。 ### 低 - **cron output 目录 20MB，未失控但可清理** - 证据：`~/.hermes/cron/output` 总大小 `20M`。 - 较大目录： - `ba78afa527b5`：`4.8M`，但任务已 paused。 - `4866141ee5e3`：`4.3M`，周检输出单次约 `800-900K`。 - 风险判断：磁盘风险低；主要是长期积累和审计噪音。 - **lock 文件存在但未见残留死锁证据** - 证据： - `~/.hermes/cron/.tick.lock` 0B，mtime `11:30:57` - `~/.hermes/cron/.jobs.lock` 0B - `ticker_heartbeat` / `ticker_last_success` 均为 `11:30` - 判断：看起来是正常 tick 锁，不像陈旧残留锁。 - **历史 Feishu 投递失败，近期未见新爆发** - 证据：gateway.log 中 7 月多次 `[230099] card table number over limit` 和 fallback failed；近期更多是 cron output preserved/chunking。 - 判断：历史问题，不是本次即时风险；长表格输出仍应避免。 ## 建议动作 1. **优先排查系统进程 `signpost_reporter` 高 CPU**：这不是 Hermes cron 直接问题，但已是当前 Mac mini 最大负载源；建议用户手动确认是否可重启该系统服务或重启机器窗口。 2. **把 `c3dee1e0c958 / TMEOA 扫码恢复自动感知` 从 every 1m 调到 3-5m，或加入“已登录后退避到 10-30m”逻辑**；它现在静默但持续每分钟写文件。 3. **错开 09:00 agent 任务**：建议把 `weekly skill radar` 从周一 09:00 改到 09:30 或 10:30，降低与 `AI 知识雷达`、`知识库早报` 的模型调用拥挤。 4. **为 agent 型 cron 设置更保守的失败上限/超时策略**：尤其关注日志里的 `attempt */9999`，避免模型服务 503 时长时间占用 gateway worker。 5. **检查 `83236dfdb31f / AI 知识雷达 09:00` 的脚本/工具调用**：近 3 天出现 90s/180s timeout，建议定位具体命令并加缓存、分页或更短超时。 6. **保留当前 paused 的告警守望系列任务暂停状态**：这些 every 5m/10m/30m agent 型任务如果恢复，会显著增加负载和消息噪音；恢复前应先改成 no-agent 预筛选。 7. **定期清理 cron output 老文件**：当前 20MB 不急，但可设置保留 30-60 天，避免审计目录持续膨胀。 本次检查已覆盖 cron 清单、系统负载/进程、Hermes 日志关键词、cron 目录/lock/output、 高频与重叠任务；未执行任何修改/暂停/删除操作。当前未发现需要立即处理的 cron 死锁或递归 loop。