cache-keeper · git:20260820.c57fc8b · 2026-08-20 · sha256 891a5147c56d6a72

cache-keeper git:20260820.c57fc8bA

Immutable. This exact content never changes and is served at /api/v1/blob/891a5147c56d6a72.

---
name: cache-keeper
description: 通过定时发送轻量保活消息,维持当前会话的服务端 prompt 缓存,降低输入 token 成本
type: prompt
whenToUse: 当用户想要维持 Kimi Code 会话缓存、减少缓存过期导致的重复输入计费,或管理缓存保活定时任务时
arguments:
  - action
  - interval
  - mode
---

# Cache Keeper — 会话缓存保活管理

你在**当前会话**中直接操作 cron 工具完成任务。**禁止派子代理**——缓存绑定主会话前缀,子代理是独立上下文,派子代理执行本 skill(包括建任务这类"杂活")完全无效或得不偿失,一律内联执行。

用户意图由参数给出:`action` = `$action`(on / off / status / refresh,省略时视为 status),`interval` = `$interval`(分钟,仅 on 时使用,默认 15),`mode` = `$mode`(仅 on 时使用;值为 `smart` 时启用链式模式,省略则为定点循环模式)。

**自动退休(retire)默认开启**:定点循环模式默认带 4 小时退休阈值。从完整参数 `$ARGUMENTS` 中解析:`retire <时长>`(如 `retire 4h`、`retire 480m`)覆盖默认时长;`retire off` 或 `no-retire` 显式关闭;链式 smart 模式不支持 retire(信封不含累计计数)。详见下文退休条款。

## 两种模式

- **定点循环(默认)**:一个 `*/N * * * *` 循环任务,锚定墙钟整点刻。健壮(调度器兜底,单次失败不影响后续),但任务结束时会有一次多余补发。循环任务 7 天后自动过期,需 refresh。
- **链式(smart)**:一次性任务自我续链——每次触发后由你重建"当前时间 + N 分钟"的下一跳。时机锚定"最后一次活动",无浪费、无 7 天过期;但任何一跳重建失败会导致**静默断链**,无告警。

## 保活消息文本(逐字使用,不得修改)

定点循环模式使用文本 A:

```
缓存维护消息:不用思考,直接回复"收到"两个字即可,不要做任何其他事情。
```

启用 retire 时(定点循环默认启用,阈值 4 小时),在文本 A 末尾**追加**以下退休条款(尖括号替换后逐字固定,之后不再改动):

```
例外条款:如果本条消息信封中的 coalescedCount ≥ <K>(约 <H> 无活动),先调用 CronDelete 删除本任务实现自动退休(不为冷会话继续付费),然后回复"收到"。
```

- `<K>` = 退休时长 ÷ 间隔,向上取整(默认 4h ÷ 15min = 16)
- `<H>` = 退休时长的人类可读写法(如"4 小时")
- 显式指定的 retire 时长 < 4 小时时,提醒用户误伤风险并确认(忙碌与离线都会推高 coalescedCount,无法区分);默认 4 小时无需确认
- retire 仅支持定点循环;链式任务的信封不含累计计数,无法使用
- 退休生效后任务即被删除:该会话之后无论怎样 resume,都不会再有保活触发,除非重新 `on`

链式模式使用文本 B,创建第一跳时把 `<N>` 替换为实际间隔分钟数;之后每跳逐字复用本条(含数字),不得改动:

```
缓存维护消息:第一步,用 Bash 执行 date 获取当前时间,然后调用 CronCreate 创建一个 <N> 分钟后触发的一次性任务(recurring: false),prompt 逐字复用本条消息文本;第二步,回复"收到"两个字。除此之外不要做任何其他事情。
```

## 各 action 的操作步骤

### on — 开启保活

1. 先调用 `CronList`。若已存在 prompt 含"缓存维护消息"的任务(任一模式),告知用户已在运行(报告 id、模式、下次触发时间),不要重复创建,直接结束。
2. 确定间隔 N:`$interval` 为数字则使用,否则用 15。小于 5 或大于 60 时先向用户确认。
3. 处理 retire(仅定点循环):从 `$ARGUMENTS` 解析——含 `retire off` / `no-retire` 则关闭;含 `retire <时长>` 则用指定时长(时长 < 4 小时时提醒误伤风险并确认);均未出现则**默认启用,时长 4 小时**。启用时计算 K = 时长 ÷ N 向上取整。
4. `$mode` 为 `smart` 时走链式(步骤 6),否则走定点循环(步骤 5)。
5. **定点循环**:调用 `CronCreate`(`cron`: `*/N * * * *`,`recurring`: true;`prompt`: 未启用 retire 用文本 A,启用则用"文本 A + 退休条款")。
6. **链式 smart**:
   a. 用 Bash 执行 `date '+%Y-%m-%d %H:%M %z'` 获取本地当前时间;
   b. 计算"当前时间 + N 分钟"得到触发时刻 T,注意分钟跨小时、跨天、跨月的进位;
   c. 调用 `CronCreate`(`cron`: 按 T 逐字段填 `分 时 日 月 *`,`prompt`: 已替换 `<N>` 的文本 B,`recurring`: false)。
   d. 若用户同时要求 retire,告知 retire 仅支持定点循环,本次未启用。
7. 完成后告知用户:任务 id、模式、间隔、下次触发时间,并按模式提醒:
   - 通用:任务只绑定**当前会话**,新开会话需重新 on;CLI 关闭期间不触发,resume 恢复后继续
   - 定点循环:**7 天后自动过期**,届时用 `/cache-keeper refresh` 重建
   - retire(retire 默认启用时):说明阈值 K 与时长(默认 4 小时);退休后会话再 resume 也不会触发保活,需重新 `on` 恢复;提醒"超长任务可能误触发退休"的风险,可用 `retire off` 关闭
   - 链式 smart:无 7 天过期,但可能**静默断链**,建议偶尔 `/cache-keeper status` 抽查

### off — 关闭保活

1. 调用 `CronList`,找到 prompt 含"缓存维护消息"的任务(两种模式通用,含带退休条款的变体)。
2. 对其 id 调用 `CronDelete`,向用户确认已删除。
3. 找不到就明说"当前没有运行中的保活任务",不要删除其他任务。

### status — 查看状态(默认)

1. 调用 `CronList`,筛出 prompt 含"缓存维护消息"的任务。
2. 报告:是否存在、模式(按 recurring 字段区分:true=定点循环,false=链式)、是否带退休条款(prompt 含"例外条款")、任务 id、cron 表达式、下次触发时间、已运行天数(ageDays)。
3. 定点循环且 ageDays ≥ 6 时建议 refresh;链式任务不存在过期问题,不需要此提醒。

### refresh — 续期重建(仅定点循环)

1. 调用 `CronList`,若存在 prompt 含"缓存维护消息"且 `recurring: true` 的任务,记录其 cron 表达式与完整 prompt(保留退休条款)后对其执行 `CronDelete`,再用原间隔、原 prompt 按 on 的步骤 5 重建。
2. 若当前是链式任务,告知用户链式无 7 天过期、无需 refresh;若怀疑断链(很久没触发过),改用 `/cache-keeper on smart` 重新起链。
3. 完成后告知新任务 id 与新的周期起点。

## 说明与边界(用户问起时如实回答)

- 保活只在会话**空闲**时触发;正在执行长任务时会顺延并合并,不会打断工作。
- 定点循环的多余补发:任务结束时合并补发的那一跳是浪费(任务最后的请求刚刷新过缓存),单次浪费约等于一次缓存命中的微型请求,频率与长任务个数成正比。这是结构性下限:cron 触发即请求,无法在发送前拦截。
- 冷会话自动退休(retire,定点循环默认 4 小时):利用信封中的 coalescedCount 判断闲置时长,超阈值后自删,退休后的会话 resume 时不再触发保活。注意**超长任务与离线无法区分**,显式指定的阈值低于 4 小时时需确认;resume 当下的那一次补发无法避免(触发即请求),retire 保证它是最后一次。
- 链式模式无补发浪费,但每跳成本略高(多一次 date + CronCreate 调用),且存在静默断链风险。
- CLI 关闭期间不触发;恢复同一会话(resume)后,定点循环自动继续,链式会补投一次并续链。
- 缓存窗口是服务端行为(约 20 分钟以上,随负载波动),本 skill 无法保证命中率,效果以用量明细为准。
- 保活本身有极小开销:每次触发是一次微型请求。