Prompt Caching 作为一等约束
来源：grapeot，2026-04-04
核心判断
Prompt caching 在成熟 harness 中是 viability constraint（可行性条件），不是成本优化。
它同时决定：
- 系统的成本基线（cache hit vs miss 有 10 倍成本差距）
- 交互延迟（128K token prompt，cache hit 500ms vs miss 13秒）
- 哪些系统架构能够存在（sub-agent 并行、speculation 模式）
为什么 Cache Discipline 反向塑造 Harness Design
缓存匹配基于严格的前缀比对，精确到 token 级别。哪怕改了一个空格，从改动位置往后的所有内容都无法命中。
这个约束渗透到多个子系统：
- Compaction 顺序：从尾部删而非从头部删（OpenClaw PR #58036）
- Tool definitions 排列：必须确定性排序，动态加载的抖动会导致 cache break
- 图片裁剪时机：延迟裁剪优于激进裁剪
- Sub-agent 参数传递：必须共享与父进程一致的 cache key
实践原则（来自 Manus 团队）
- Keep prefix stable
- Make context append-only
- Mask tools don't remove them（通过 logit masking 控制工具可用性，而非列表增删）
Sub-agent 的隐性成本
每个 sub-agent 启动时建立独立的 API 会话，主 agent 精心维护的缓存对 sub-agent 完全无效。短生命周期的 sub-agent 意味着一次缓存冷启动。
度量先于优化
Claude Code 源码中的 promptCacheBreakDetection.ts 追踪缓存断裂的来源：system prompt 变了？工具列表顺序变了？历史消息被修改？
无法度量的东西无法改进。
关联
- harness-engineering/overview — Harness Engineering 总览
- 上下文管理 — 上下文管理
- claude-code/overview — Claude Code 的 prompt caching 实现