---
name: cache-keeper
description: 通过定时发送轻量保活消息,维持当前会话的服务端 prompt 缓存,降低输入 token 成本;smart 模式为活动锚定的重置链式——回合开始删任务、回合结束重建,对话期间零触发
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` 时启用重置链式模式,省略则为定点循环模式)。

参数位置容错(按用户习惯兼容):若 `$action` 为 `smart`(如 `/cache-keeper smart`),视为 `on smart`,间隔取 `$interval`(缺省 15);若 `$action` 为 `on` 且 `$interval` 为 `smart`(如 `/cache-keeper on smart`),视为 `on smart`、间隔默认 15。

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

## 两种模式

- **定点循环(默认)**:一个 `*/N * * * *` 循环任务,锚定墙钟整点刻。健壮(调度器兜底,单次失败不影响后续),但任务结束时会有一次多余补发。循环任务 7 天后自动过期,需 refresh。
- **重置链式(smart)**:一次性任务 + 三段机制——
  1. **回合开始删任务**:每一轮对话开始处理用户消息之前,先删除当前等待中的保活任务——本轮对话期间不存在任何到点触发,从根源消除"输出完立刻补投保活";
  2. **回合结束建下一跳**:回复发送前,重建"当前时间 + N 分钟"的新一跳(见下文"持续义务");
  3. **触发续链**:若连续 N 分钟无任何对话,任务触发,由你重建下一跳。

  效果:保活只在**连续 N 分钟无对话活动**后触发,时机锚定最后一次活动;对话期间零触发、零补投。无 7 天过期。风险:回合被中断(Escape、崩溃)时可能"已删未建",链条静默中断——这是"开始删"的代价,建议偶尔 status 抽查;上下文压缩后若遗忘维护义务,未删任务仍在,自动退化为纯链式行为(仍会续跳,不会更坏)。

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

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

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

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

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

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

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

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

## smart 模式的持续义务(每轮对话:开始删、结束建)

`on smart` 成功后,从下一轮起,在本会话**每一轮对话**执行以下维护(顺序固定):

**回合开始时——处理用户消息之前,作为本轮第一个动作**:

1. 对记住的保活任务 id 调用 `CronDelete`;若报 id 不存在,改为 `CronList` 找到 prompt 含"缓存维护消息"的一次性任务再删除;
2. 若 `CronList` 也找不到任何保活任务(用户已 `off` 或断链),**停止维护、不重建**,本义务终止;
3. 删除成功后正常处理用户消息——本轮期间不存在任何等待中的触发。

**回合结束时——回复发送之前**:

4. 用 Bash 执行 `date '+%Y-%m-%d %H:%M %z'` 获取当前时间,计算"当前时间 + N 分钟"得到 T(N 取自被删任务 prompt 中文本 B 的数字);
5. 调用 `CronCreate`(`cron`: 按 T 逐字段填 `分 时 日 月 *`,`prompt`: 逐字复用被删任务的原 prompt,`recurring`: false),记住新 id。

**其他规则**:

6. 维护是后台动作:不要在回复中向用户汇报,除非用户问起或出错;
7. 保活触发那一跳(文本 B 的续链回合)不需要开始删除——任务触发时已自我消耗;若 CronList 显示其仍存在,按第 1 步处理即可。

边界:回合被中断(Escape、崩溃)时可能出现"已删未建",链条静默中断,用 `/cache-keeper status` 抽查即可发现,重新 `on smart` 起链。上下文压缩后若遗忘本义务,未删任务会按链式触发续跳,退化为纯链式行为。开销提示:每轮约 3 次工具调用(开始 CronDelete + 结束 date + CronCreate);高频连续对话时总开销可能高于定点循环,可在用户抱怨开销时建议切换。

## 各 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),记住任务 id;
   d. 自此启用上文"持续义务":此后每轮对话开始时删除等待中的任务、回复结束前重建为"当前时间 + N 分钟";
   e. 若用户同时要求 retire,告知 retire 仅支持定点循环,本次未启用。
7. 完成后告知用户:任务 id、模式、间隔、下次触发时间,并按模式提醒:
   - 通用:任务只绑定**当前会话**,新开会话需重新 on;CLI 关闭期间不触发,resume 恢复后继续
   - 定点循环:**7 天后自动过期**,届时用 `/cache-keeper refresh` 重建
   - retire(retire 默认启用时):说明阈值 K 与时长(默认 4 小时);退休后会话再 resume 也不会触发保活,需重新 `on` 恢复;提醒"超长任务可能误触发退休"的风险,可用 `retire off` 关闭
   - smart:保活只在连续 N 分钟无对话后触发,对话期间零触发;每轮有一次维护开销;回合中断可能静默断链,建议偶尔 `/cache-keeper status` 抽查;上下文压缩后退化为纯链式续跳

### off — 关闭保活

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

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

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

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

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

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

- 保活只在会话**空闲**时触发;正在执行长任务时会顺延并合并,不会打断工作。
- 定时任务永远不会在模型输出中途插入;触发被挂起,等回合结束才合并补投——smart 模式通过"回合开始先删任务"让对话期间不存在可挂起的触发,从根上避免了回合结束瞬间的补投。
- 定点循环的多余补发:任务结束时合并补发的那一跳是浪费(任务最后的请求刚刷新过缓存),单次浪费约等于一次缓存命中的微型请求,频率与长任务个数成正比。这是结构性下限:cron 触发即请求,无法在发送前拦截。
- smart(重置链式)消除了对话期间的一切保活触发,代价是每轮约 3 次工具调用,以及回合中断时"已删未建"的静默断链风险。低频对话、长任务多的场景净收益为正;高频碎碎念对话时可能得不偿失,建议切回定点循环。
- 冷会话自动退休(retire,定点循环默认 4 小时):利用信封中的 coalescedCount 判断闲置时长,超阈值后自删,退休后的会话 resume 时不再触发保活。注意**超长任务与离线无法区分**,显式指定的阈值低于 4 小时时需确认;resume 当下的那一次补发无法避免(触发即请求),retire 保证它是最后一次。
- CLI 关闭期间不触发;恢复同一会话(resume)后,定点循环自动继续,smart 会补投一次并续链。
- 缓存窗口是服务端行为(约 20 分钟以上,随负载波动),本 skill 无法保证命中率,效果以用量明细为准。
- 保活本身有极小开销:每次触发是一次微型请求。