Cron 成本防护

防止因 AI Agent 的 Cron 任务配置错误而导致的静默式 Token 预算耗尽。

快速审计清单

每次配置 Cron 任务，或调查成本激增问题时，请执行以下检查项：

1. 会话隔离（关键）

检查每个 Cron 任务是否存在会话绑定冲突：

cron list (includeDisabled: true)

高风险信号：

• sessionKey: "agent:main:main" 与 sessionTarget: "isolated" 同时存在 → 陈旧绑定，将引发模型冲突
• agentId 指向与会话所有者不同的 Agent → 跨 Agent 模型污染
• consecutiveErrors >= 3 → 极可能陷入重试循环
• lastError 中包含 LiveSessionModelSwitchError → 已确认模型切换循环

修复方法：删除该任务并重新创建，创建时**不指定** sessionKey，并显式设置 sessionTarget: "isolated"。

2. 模型冲突

在多 Agent 场景下（例如：Agent A 使用 Claude，Agent B 使用 GPT），每个 Agent 的 Cron 任务必须严格限定于其所属 Agent。

• 为每个 Cron 任务显式设置 agentId
• 若 payload 支持，需显式指定 model
• 严禁 Agent B 的 Cron 任务继承 Agent A 的会话模型

3. 系统提示词大小

审计已注入的 workspace 文件：

wc -c MEMORY.md SOUL.md AGENTS.md TOOLS.md USER.md QUEUE.md

目标：注入总大小 **＜ 20KB**。将大文件（如 playbook、心跳模板、参考文档等）移至 references/ 目录，按需读取。

4. 成本监控

sessions_list (limit: 10, messageLimit: 1)

重点关注 estimatedCostUsd 较高但输出 token 数量较低的会话——这是重试循环的典型特征。

诊断：Token 激增

如需详细诊断步骤及事件后检查清单，请参阅 references/diagnosis.md。

预防规则

1. 每个 Cron 任务：必须设置 sessionTarget: "isolated"，且不得存在陈旧的 sessionKey
2. 每个 Cron 任务：必须显式指定 timeoutSeconds（禁止无限超时）
3. 多 Agent 场景：每个 Cron 任务必须显式设置与其应运行 Agent 完全匹配的 agentId
4. 修改默认模型后：须全面审计所有 Cron 任务是否存在模型冲突
5. 每周例行检查：遍历全部 Cron 任务的 consecutiveErrors 字段 —— 凡 ≥ 3 均需立即调查