yakeworld IO_CONTRACT
- input: 无（直接触发）
- output: 诊断报告 JSON + 优化建议列表
- 副作用: 可能调用 cronjob action=update/remove/create
对应原则：P1（智能原子包含诊断逻辑）
核心流程
Step 1: 数据采集
cronjob action=list
获取所有 cron 任务的完整状态。
Step 2: 诊断矩阵
对每个任务运行以下检查：
| 检查项 | 条件 | 严重度 |
|---|---|---|
| 已暂停 | enabled=false 或 paused=true |
HIGH |
| 错误状态 | last_status="error" |
HIGH |
| 配置错误 | no_agent=True 且 model 不为 null |
MEDIUM |
| 配置错误 | 非 no_agent 但无 model 指定 |
HIGH |
| 配置错误 | 非 no_agent 但 deliver="local"（不投递到聊天） |
MEDIUM |
| 配置冗余 | no_agent=True 且 deliver="origin" |
LOW |
| 付费任务 | provider 包含 "deepseek" |
INFO（需人工确认） |
| 频率过高 | schedule 包含 every 且间隔 < 1h |
INFO |
| 功能重叠 | 多个任务做同一件事（如 D8 扫描 + bib 标准化） | MEDIUM |
| 批量超时 | 多个 no_agent 或脚本任务同时 timeout → 检查 codex profile 完整性 (ls ~/.codex/profiles/) |
HIGH |
Step 3: 功能重叠检测
按关键词分组任务名和描述：
# 论文管线
paper_keywords = ["paper", "quality", "bib", "d8", "d10a", "repair", "review", "scan"]
# 进化循环
evolution_keywords = ["evolution", "evolve", "probe", "full", "cycle"]
# 监控
monitor_keywords = ["heartbeat", "monitor", "scan", "check", "audit", "sync"]
同一组内如果多个任务使用相同或相似 model + 做相似内容，标记为重叠。
Step 4: 频率聚类
按执行频率分组：
高频 (< 1h): 每 30m
中频 (1-4h): every 2h, every 360m
低频 (daily): 0 6 * * *, 0 9 * * *
超长 (monthly): 0 9 1 * *
识别同一组内可合并的任务。
Step 5: 输出报告
=== CRON 诊断报告 ===
总任务: N
Agent: M (付费 X, 免费 Y)
Script: K
已暂停: P
错误: E
=== 付费任务 ===
1. name: model, schedule, cost_impact
=== 功能重叠 ===
1. [论文管线] task-A + task-B → 建议合并
=== 配置问题 ===
1. [HIGH] task-X: enabled=false, last_status=error
2. [MEDIUM] task-Y: deliver=local 不投递
=== 优化建议 ===
1. 删除 task-Z (已暂停, 无活跃使用)
2. 合并 task-A + task-B → unified-task
3. 修复 task-Y deliver 配置
Golden 集合 · GOLDEN SET
- Golden Input: 直接触发（无参数）—
cronjob action=list采集 15 个 cron 任务全量状态 - Golden Output: 诊断报告 JSON（总任务数/付费/已暂停/错误数与清单交叉一致）+ 优化建议列表，每条建议对应一个可执行 action（update/remove/create）；典型结果：15→10-11 任务、付费 6→4
- Golden Error: 批量 no_agent 任务同时 timeout 且
ls ~/.codex/profiles/缺失 → 判 HIGH 级配置错误，先核对 codex profile 完整性再批量操作
优化操作模式
清理模式（推荐直接执行）
# 删除已暂停任务
cronjob action=remove job_id="<id>"
# 删除已完成的一次性任务
cronjob action=remove job_id="<id>"
# 合并任务：删除旧任务 → 创建新任务
cronjob action=remove job_id="<old>"
cronjob action=create schedule="..." model="..." prompt="..."
修复模式
# 修复 deliver 配置
cronjob action=update job_id="<id>" deliver="origin"
# 修复配置错误
cronjob action=update job_id="<id>" model="..." provider="..."
优化原则
- 先删后加：删除无效/冗余任务优先于修复配置
- 合并同类：功能重叠的任务合并为一个，减少 API 消耗
- 保留价值：每个保留的任务必须有明确用途和独立价值
- 频率合理：心跳类 30m 可接受，扫描类 ≤4h 合理，论文任务 daily 足够
- 付费控制：DeepSeek 付费任务控制在 4-6 个，其余用免费模型
典型优化结果
| 指标 | 优化前 | 优化后 |
|---|---|---|
| 总任务数 | 15 | 10-11 |
| 付费任务 | 6 | 4 |
| 已暂停 | 2 | 0 |
| 功能重叠 | 3 组 | 0 |
| 配置错误 | 1 | 0 |
示例 · EXAMPLES
输入：直接触发（cronjob action=list 采集 15 个任务）
输出：诊断报告 JSON — 总任务 15（付费 6, 已暂停 2, 错误 1）；功能重叠 3 组（D8 扫描 + bib 标准化）；优化建议 5 条（remove×2, update×2, merge×1）→ 执行后 10 任务、付费 4
输入：批量 no_agent 任务同时 timeout + ls ~/.codex/profiles/ 缺失
输出：HIGH 级配置错误判定 → 先修复 codex profile 完整性，再执行批量操作
约束规则 · RULES
- 先删后加：删除无效/冗余任务优先于修复配置
- 付费（DeepSeek）任务控制在 4-6 个，其余用免费模型
- 心跳类 30m 可接受，扫描类 ≤4h，论文任务 daily 足够
- 批量 no_agent 任务同时 timeout 时必须先检查 codex profile 完整性
- 每个优化建议必须对应一个可执行 action（update/remove/create）
参考
references/cron-diagnostics-pattern.md— 诊断模式详细步骤
Operational Steps
- 列出全部 cron 任务（cron 配置目录 /
hermes cron list） - 逐任务评估健康度：频率、调度冲突、deliver 配置、付费成本
- 识别功能重叠与配置错误（对照健康度表）
- 输出诊断报告 JSON + 优化建议列表（update/remove/create）
Pitfalls
- 功能重叠：多个任务监控同一目标 → 合并（如文献监控与收割）
- 已暂停任务残留：暂停后未删除，占用配额
- deliver 配置错误：目标未配置导致结果静默丢失
- 付费任务成本失控：高频率付费任务需降频或合并
Verification
- 诊断报告 JSON 输出成功且字段完整
- cron 任务清单交叉验证：总任务数/付费任务数/已暂停数一致
- 每个优化建议对应一个可执行 action（update/remove/create）
Genes (策略基因)
紧凑策略表示。条件→策略。需要深度时参考完整文档。
- [CRON-001] 任务处于已暂停或错误状态 → 优先执行删除操作以清理无效配额，而非尝试修复
- [CRON-002] 多个任务功能重叠（如相同关键词分组） → 合并为单一任务以减少 API 消耗并消除冗余
- [CRON-003] 批量 no_agent 任务同时超时 → 立即检查 codex profile 完整性，修复环境后再执行批量操作
- [CRON-004] 付费模型（DeepSeek）任务数量超过 4-6 个 → 将低价值任务降级为免费模型或合并，以控制成本
- [CRON-005] 任务配置为 no_agent 但指定了 model 或 deliver 为 local → 修正配置错误，确保非代理任务不依赖模型且结果正确投递
- [CRON-006] 任务执行频率过高（间隔 < 1h）且非心跳类 → 降低执行频率（扫描类 ≤4h，论文类 daily）以优化资源使用