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

一10:00 BRK/RKLB周报｜均ok**，分别耗时 **53.9 / 27.2分钟**；BRK又与10:30智谱周报重叠。 - 多项任务会更新同一 `llm-wiki` 入口、日志、索引或发布目录。**尚无损坏证据，但存在竞态和重复索引成本。** ### 中｜网络等待缺少脚本内上限 - **`e353051ee8d9`｜议事厅发布｜每15分钟｜ok** - **`4e1ac6dc2ff9`｜汇报总线｜every 30m｜ok** - 最近执行最长均不足3秒，但源码中的后续 `ssh/rsync/scp` 未设 `subprocess timeout`，也未见脚本级互斥。连接建立后的挂起可能长期占用执行槽；调度器默认脚本上限为 **3600秒**。 - RMS 脚本另有未逐次限时的 `ws.recv()`；修好依赖后应一并处理。 ### 中｜飞书回退投递可能制造重复 - 10:54，BRK任务日志出现： `'ReplyMessageResponse' object has no attribute 'get', falling back to standalone` - 随后记录投递成功，因此**不是最终投递失败**；但首次发送结果解析异常后再次发送，存在重复消息风险，不能只看 `last_status=ok`。 ### 低｜高频任务与残留文件目前可控 - **`c3dee1e0c958`｜扫码恢复感知｜every 1m｜ok**：no_agent、非阻塞互斥锁、空闲快速返回、正常静默；保留记录中实际执行间隔中位数约 **120秒**，最长 **27.6秒**，未见循环发消息。 - 上述四项高频任务均为 **no_agent**；没有启用中的分钟级 Agent 任务。已暂停的5项告警 Agent 不构成当前负载。 - Cron目录约 **36.33MiB**；**23个零字节锁文件**符合常驻锁文件设计，不能因文件旧就判断死锁。Ticker心跳正常，未见失控日志增长或当前锁阻塞。 - 7个 `browser_harness.daemon` 已运行约29–35天、PPID=1，但 CPU均为0；属于待确认的旧常驻进程，不是已证实卡死。 ## 建议动作 1. **优先修复RMS**：由你决定是否先暂停；随后显式使用业务解释器，验收依赖导入和一次真实采集，再恢复周期运行。 2. **发布脚本补边界**：给议事厅、汇报总线增加非阻塞互斥、网络命令超时和单轮总预算；RMS补WebSocket读取超时。 3. **先错峰、再限制共享写入**：三份股票周报至少错开60分钟，早报放到雷达完成后；知识库索引/发布使用共享资源锁。不要将全部Cron串行化，避免堵住扫码恢复。 4. **修飞书返回值兼容与幂等**：正确解析SDK响应；取得成功消息ID后，不应因解析异常再次发送。 5. **保留现有降噪措施**：保持分钟任务no_agent、空闲静默、异常去重；5项已暂停的高频Agent不要直接批量恢复。 6. **降低Mini负载先找真正大户**：优先核对聚合worker与SSH隧道的吞吐、轮询频率；旧browser daemon确认无引用后再清理，不按运行时长直接杀进程。 7. **处理失效记忆插件噪音**：近7天 `agent.log` 有334条OpenViking不可达警告。确认仍需使用后修复；否则建议停用或退避告警，不自动新增常驻服务。 **审计范围已完成，未修改任务、脚本、配置或重启服务。** 本轮未提供 `cronjob` 工具，已用CLI和持久记录替代；只读SQLite直连失败后使用缓存快照核对。`.env`读取被拒，故未确认环境变量是否覆盖并发/超时设置。下一轮重点观察RMS失败是否归零、飞书回退是否消失及Swap是否持续增长。