# ScheduleWakeup

在 `/loop` 动态模式下调度何时恢复工作。该工具让 Claude 能够自主控制任务迭代节奏，休眠指定时间后以相同的循环提示词再次触发。

## 何时使用

- 在 `/loop` 动态任务中自主控制节奏，迭代间隔取决于工作状态而非固定时钟
- 等待耗时较长的构建、部署或测试运行完成后再检查结果
- 在当前没有特定信号需要监视时，在迭代之间插入空闲等待
- 运行无用户提示的自主循环——将字面量哨兵值 `<<autonomous-loop-dynamic>>` 作为 `prompt` 传入
- 轮询即将发生状态变化的进程（使用较短延迟以保持缓存热态）

## 参数

- `delaySeconds`（数字，必填）：距恢复的秒数。运行时会自动将值限制在 `[60, 3600]` 范围内，无需手动限制。
- `reason`（字符串，必填）：一句简短的句子，解释所选延迟时间的原因。显示给用户并记录到遥测数据中。请具体说明——"正在检查耗时较长的 bun 构建"比"等待中"更有用。
- `prompt`（字符串，必填）：唤醒时触发的 `/loop` 输入。每轮传入相同的字符串，使下次触发能重复执行该任务。对于无用户提示的自主循环，传入字面量哨兵值 `<<autonomous-loop-dynamic>>`。

## 示例

### 示例 1：短暂延迟以重新检查快速变化的信号（保持缓存热态）

构建刚刚启动，通常需要两到三分钟完成。

```json
{
  "delaySeconds": 120,
  "reason": "检查预计约 2 分钟后完成的 bun 构建",
  "prompt": "检查构建状态并报告任何错误"
}
```

120 秒的延迟使对话上下文保持在 Anthropic 提示缓存中（TTL 5 分钟），因此下次唤醒更快、成本更低。

### 示例 2：较长的空闲等待（接受缓存未命中，分摊至更长的等待时间）

数据库迁移正在运行，通常需要 20–40 分钟。

```json
{
  "delaySeconds": 1200,
  "reason": "迁移通常需要 20–40 分钟；20 分钟后再检查",
  "prompt": "检查迁移状态，完成后继续"
}
```

唤醒时缓存将会冷却，但 20 分钟的等待足以分摊单次缓存未命中的代价。每 5 分钟轮询一次会以相同的缓存未命中代价重复 4 次，毫无收益。

## 注意事项

- **5 分钟缓存 TTL**：Anthropic 提示缓存在 300 秒后过期。延迟低于 300 秒可保持上下文热态；延迟超过 300 秒则在下次唤醒时产生缓存未命中。
- **避免恰好设置 300 秒**：这是最糟糕的选择——既承担了缓存未命中的代价，又没有获得实质性更长的等待时间。要么降至 270 秒（保持缓存热态），要么提交到 1200 秒或更长（一次缓存未命中换来更长的等待）。
- **空闲等待的默认值**：当没有特定信号需要监视时，使用 **1200–1800 秒**（20–30 分钟）。这让循环能定期检查，而不会每小时因无意义的缓存未命中损耗 12 次。
- **自动限制范围**：运行时会将 `delaySeconds` 限制在 `[60, 3600]` 范围内。低于 60 的值变为 60；超过 3600 的值变为 3600。无需自行处理这些边界。
- **省略调用即结束循环**：如果打算停止迭代，请勿调用 ScheduleWakeup。省略该调用即可结束循环。
- **每轮传入相同的 `prompt`**：`prompt` 字段在每次调用时必须携带原始 `/loop` 指令，以便下次唤醒知道要恢复哪个任务。
