代理定时任务体检

先解决什么问题

定时跑的 AI Agent 任务最麻烦的不是"跑挂了"，而是"看起来没挂"。Job 状态返回成功，日志里没有报错，但下游什么也没发生——输出为空、消息重复发送、或者因为上下文太大每次都在超时边缘徘徊。另一种常见情况是同一个任务被调度了两次，甚至三次，互相覆盖结果。

更隐蔽的是重试循环：失败计数一直在涨，每次重启后短暂恢复然后再次失败，没人注意到。还有一种是调度频率过高，任务间隔短于下游系统消费速度，导致积压和重复触发。

agent-cron-audit 就是用来处理这一类问题的。

它怎么工作

这个技能检查四类输入：调度配置、运行历史、模型选择、任务输出。然后按风险分组输出发现：

• 静默失败：任务正常结束但没有产生有用的下游动作
• 重复调度：两个以上的活跃 schedule 实际在跑同一个任务
• 重试循环：反复失败、重启、回退但始终没有恢复
• 调度过频：间隔短于任务本身或下游消费者能承受的范围
• 过时自动化：schedule 还活跃，但上游信号或下游接收方已经失效
• 模型选择风险：模型过强、过弱、或上下文过重，不适合这个循环任务
• 上下文膨胀：每次循环都拖入过大的上下文、旧历史或完整日志

输出固定六个部分：最优先修复项、Top 5 发现、原始证据（已脱敏）、可复制的验证提示词、暂不建议的操作、相关技能指针。每个发现都带置信度标签（High / Medium / Low），并且在给出任何建议之前先展示证据。

适用边界

只读是核心约束。 这个技能不会编辑、禁用、删除、重启或自动修复任何任务。所有建议都停留在"建议"层面，实际修改需要人工验证后自行执行。

它不做账单计算，不把 token 数量换算成具体金额，不提供仪表盘或导出功能，也不上传日志或调用外部 LLM。如果你要排查的是已知任务的 token 浪费，应该用 waste-audit；如果是部署后的成本/模型变更风险，应该用 agent-cost-eval-kit。

所有检查在本地完成，密钥、API token、聊天 ID、服务器路径都会在证据中被脱敏处理。