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

，当前没有 pending；不是每分钟启动 agent。 - 扫码感知、cookie 刷新、RMS 共用 CDP `51074`，未见跨脚本共享互斥；扫码感知还会导航“第一个 page”，可能干扰登录或采集。 - 繁星阁任务 `a101e2378bae`（周一/四 18:00）也直接调用汇报总线脚本；调度器的**同 job 防重入不覆盖这种跨入口调用**。 - 最近24小时日志未见 `already running`、`Fire claim lost` 或明确死锁信号。 ### 中｜早间 agent 重叠，知识库可能读到半成品 - `83236dfdb31f` 今天实际运行 **09:00–09:29，29.65分钟、52次模型调用**。 - 与 `2c08fbba1510` 的 **09:00–09:09** 重叠。 - 又与 `0c49d4bb5faa` 的 **09:15–09:24** 重叠；两者都操作 `~/llm-wiki`，早报还会发布内容。 - 雷达期间多次出现 Firecrawl `403`，增加无效尝试。当前配置未显式设置 `cron.max_parallel_jobs`。 ### 低｜仓库更新失败、输出和锁文件 - **`c29f4708765b`｜每日04:30｜last_status=`error`**：今天检查30个仓库，其中 `youth/docker/cli_proxy_api/CLIProxyAPI` 连接 GitHub 443 超时，日志为 `75001 ms`；同时投递失败。脚本已有命令超时和锁，不像无限循环。 - Cron 目录约 **27.47 MiB / 1,234 文件**；最大单文件是历史 wiki-lint 输出，约1.14MB，暂无容量风险。 - 发现 **20 个零字节 lock 文件**，`lsof` 未见打开者。**不能按文件存在或 mtime 判死锁，也不建议直接删除。** ## 建议动作 1. **先修投递路径**：核验 `origin.thread_id` 到根消息 reply 的解析及现用 Feishu adapter；修复后用一条消息验证原 topic，再补发缺失报告，**不要重跑整套研究任务**。 2. **调整自动更新机制**：建议先暂停 `f85d82aa9345`，改为人工维护窗口；更新、补丁验证、重启和重启后验收分阶段留结果，避免由会被重启杀掉的 agent 自证成功。 3. **给高频脚本加硬边界**：CDP 单次等待设15–30秒，总执行设明确上限；ssh/scp/rsync 加执行超时，并确保超时清理子进程。 4. **加资源级互斥**：登录刷新共享一个非阻塞锁，保留原二维码会话、采集用独立 tab；注意父脚本调用刷新脚本时不要重复获取同一锁。汇报总线另设发布锁和临时输出目录。 5. **错开知识库任务**：早报移到雷达完成之后，例如10:00，并检查完成标记；weekly skill radar 移出09:00。可先把 cron 并发上限设为2，再观察脚本延迟。 6. **降低无效工作和噪音**：无变化跳过发布；扫码重发间隔按既定偏好改为10分钟；Firecrawl 遇确定性403立即换可用来源，不反复调用。 7. **保留失败事件而非只看 latest**：扫码恢复通知应保留待投递状态，送达后再确认；下次重点观察投递恢复、更新闭环、跨任务冲突及超时后的子进程残留。 **检查范围已完成，未修改任务、脚本、配置或重启服务。** 本次 `cronjob` 工具未开放，使用 `hermes cron list --all` 及原始记录替代；执行库普通只读连接失败后，已用不可变只读模式读取。账本仅保留09-13 16:11之后的记录，更早情况以上述日志为准。