Cache Guard 是一个面向智能体会话的成本控制技能，目标是阻止提示词缓存抖动与 token 失控消耗。它建议在读取图片或截图之前加载使用，适用于视觉 QA、渲染检查、UI 验证等场景。
【核心机制】 提示词缓存是一种前缀匹配，分为三层：tools → system → messages。缓存读取成本为基准输入价的 0.1 倍，缓存写入成本为 1.25 倍，两者相差 12.5 倍。只要每一次调用都重新读取了缓存前缀，长对话就是廉价的。
请求中任何位置出现图片，都会使整个 messages 层失效。下一次调用会以 1.25 倍的写入价重写整段对话历史，重写成本等于当时的上下文大小。据资料说明，在一个 80 万 token 的会话中，看一眼截图约花费 80 万缓存写入 token，即便图片本身只有约 1–2k token；生产环境测量显示，某会话 91% 的成本来自图片触发的重写，图片本身仅占 token 的 0.13%。
其他触发全量重写的情况：缓存 TTL 过期（空闲超过 5 分钟，下次唤醒会重写全部内容）、切换模型、会话中途变更工具集或 MCP、编辑较早的历史记录。机制细节与价格计算见 references/mechanism.md。
【规则】 R1 —— 将图片读取批量合并到一条消息：读 1 张图和读 10 张图的重写成本相同，不要跨轮次逐张查看截图；先累积路径，再在单条消息中用并行的 Read 调用一次性读完，并在该轮内得出全部结论。
R2 —— 只看一次，写下来，永不重读：查看图片后立即把结论追加到笔记文件（如 qa-notes.md），格式为 文件名 → 结论 → 所需修复；此后引用笔记即可。为“再确认一次”而重读图片会重复整个上下文的重写。
R3 —— 把视觉任务委托给子代理（上下文很大时的最佳选择）：子代理拥有自己的小型隔离上下文，它读取图片只重写它自己的几 k token，而非你的几十万 token，其中间噪音也不会进入你的历史。可使用 Task/Agent 工具（general-purpose 可用），并附上资料中给出的指令模板：要求以纯文本回复、绝不返回图片数据，逐图给出 PASS/FAIL、一行理由以及失败时的确切修复方案。子代理使用的是同一模型，结论质量取决于你把“什么算正确”写得有多具体，因此需要把判定标准作为文本传入。主会话只收到简短的文本结论，其缓存前缀保持完好。子代理调用本身可能不享受缓存，但这无关紧要，因为其上下文很小。
R4 —— 必须内联读取时，要尽早读取：重写成本等于当时的上下文大小。把视觉检查前置，不要拖到长会话末尾；如果会话已经很大，优先使用 R3 或开新会话，而非内联读取。
R5 —— 让批量数据远离上下文：通过退出码、文件大小或 grep 摘要来验证渲染/构建，而不是把输出倾倒进对话；只读取需要的行（offset/limit），绝不要 cat 大文件或粘贴 base64；把大型中间结果写入文件，传递路径而非内容。
R6 —— 长时运行代理的会话卫生：以连续突发方式工作。空闲超过 5 分钟的巨大会话每次唤醒都要付出全量重写成本；对于周期性监控，应把每一轮作为全新的一次性会话运行（状态放磁盘），而不是唤醒一个巨大的对话。在图片密集的工作流中，于工作单元边界清除或重启；持久状态应保存在文件中，而非对话记录里。绝不要在会话中途切换模型或增删工具（含 MCP），二者都会使整个缓存失效。
【决策表】 上下文小（约 <50k）、图片少、一次性检查：内联读取，全部放在一条消息中（R1），记录结果（R2）。 上下文大（约 >150k）或需要重复视觉检查：委托给子代理（R3）。 带截图的周期性循环（监控、渲染监视）：每轮使用全新的一次性会话（R6）。 图片此前已查看过：使用笔记，不要重读（R2）。 需要验证渲染/构建：用退出码、文件大小或 grep，不要倾倒输出（R5）。
【验证是否生效】 每个 API 响应中的 usage 会说明真实情况：健康的会话表现为 cache_read_input_tokens 远大于 cache_creation_input_tokens（目标 ≥10:1；写入与读取之比接近 1:3 或更差意味着发生了抖动）。审计历史会话可使用资料中给出的命令： node scripts/audit-session.mjs --hours 5 # 按消耗对最近会话排序 node scripts/audit-session.mjs --detail <sid8> # 针对单个会话的逐调用取证 输出中需要留意的标记：IMG-REWRITE（图片破坏了 messages 层）和 TTL-WAKE（空闲超过 5 分钟，唤醒时整个上下文被重写）。
【限制】 资料未提供该技能的安装方式、支持平台、是否收费或价格等具体信息。