<!-- Canonical URL: https://ask.atlascloud.ai/zh/when-prompt-caching-reduces-coding-agent-costs -->

# 提示词缓存什么时候才能真正降低编码智能体成本？

> 当大量请求复用足够大且字节级稳定的前缀，并且缓存读取的节省超过实现复杂度与未命中成本时，提示词缓存才能降低编码智能体成本。应根据真实用量记录测量缓存输入，而不是假设所有重复指令都享受折扣。

提示词缓存真正有价值的场景，是智能体反复发送同一段很长的开头，而不是提示词在人看来“差不多”。如果前部出现时间戳、重新排序的工具列表、变化的工作区摘要或动态请求 ID，后面的稳定内容也可能全部失去复用机会。

重新设计提示词前，先查看真实请求的用量元数据：有多少输入 token 可进入缓存、多少被报告为缓存读取、前缀多久变化一次，以及当前模型和协议是否确实提供缓存收益。

## 建立未缓存基线

先计算输入成本，因为缓存不会减少输出 token 或工具执行。

```text
uncached_input_cost = requests * input_tokens_per_request * input_rate
```

费率必须使用一致单位，通常是每百万 token 的价格。不要凭记忆填写折扣，应查询具体模型的最新价格和用量字段。

| 组成部分 | 请求之间是否稳定 | 建议位置 |
|---|---|---|
| 系统规则 | 通常稳定 | 最前 |
| 工具 Schema | 通常稳定 | 前部 |
| 仓库规范 | 经常稳定 | 前部 |
| 任务检查点 | 有时稳定 | 中部 |
| 用户请求 | 很少稳定 | 后部 |
| 实时工具输出 | 不稳定 | 最后 |

## 用变量计算盈亏平衡

设 `P` 为稳定前缀 token 数，`R` 为请求总数，`W` 为缓存写入费率，`H` 为缓存读取费率，`U` 为普通输入费率：

```text
uncached = R * P * U
cached = P * W + (R - 1) * P * H
savings = uncached - cached
```

这是假设首次之后全部命中的理想情况。若实测命中比例为 `h`，应把后续请求项换成 `H` 与 `U` 的加权组合，并在两侧加入按普通费率计算的非前缀 token。

只有在计入未命中与工程开销后节省仍为正，缓存才具有经济价值。

## 把稳定内容放在前面

按从稳定到易变的顺序组织：

* 系统与安全指令。
* 按确定顺序排列的工具定义。
* 仓库规范和长期参考内容。
* 精简任务检查点。
* 当前用户请求。
* 最新工具输出。

Schema 应采用确定性序列化。避免前缀内的随机排序、空白改写、时间戳和请求专属注释。稳定内容应明确版本化，让真正变化造成的未命中可以解释。

## 保持前缀有用，而不只是很长

臃肿前缀可能提高缓存读取量，却同时增加总 token 并分散模型注意力。应删除过时工具、重复规则和与当前任务无关的参考文件。

衡量每个成功编码结果的成本，而不只是命中率。如果更短的未缓存提示词能用更少回合完成任务，它可能优于命中率很高但噪声很多的提示词。

## 记录请求与实际结果

记录模型、协议、前缀版本、总输入 token、可用时的缓存 token、输出 token、延迟、工具调用数、重试数和任务结果。缺失字段应标为不可用，而不是零。

| 指标 | 作用 |
|---|---|
| 缓存 token 占比 | 确认真正发生了复用 |
| 未命中原因 | 发现意外的前缀变化 |
| 每任务请求数 | 找到抵消节省的循环 |
| 每次被接受修改的成本 | 把 token 与有效工作关联 |
| 重试率 | 发现缓存以外的可靠性成本 |

连续一周的代表性任务，比把一条合成提示词重复一百次更有参考价值。

## 注意路由和会话边界

缓存行为可能受模型、供应商、区域、保留窗口和路由影响。网关或回退机制可能把请求转到没有相同热前缀的路由，因此缓存性能应视为所选路由的实测属性。

Atlas Cloud 通过一个 API 暴露多种 LLM 格式，但公开协议指南没有承诺统一的提示词缓存折扣。作出成本结论前，应检查当前模型和控制台；使用[LLM 协议](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=when-prompt-caching-reduces-coding-agent-costs)选择兼容格式，并通过[模型目录](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=when-prompt-caching-reduces-coding-agent-costs)查看最新信息。

## 避免虚假的节省

更低的输入费用可能掩盖更多回合、失败工具调用或反复重建上下文。缓存读取与应用层存储、检索也不是同一概念，它们解决的问题不同。

不要因为内容可能被缓存就放入秘密信息。应遵守供应商数据控制与自身保留要求，缓存架构不能替代访问控制。

## 使用实际的采用门槛

只有在以下条件成立时采用：

* 稳定前缀有意义并经常复用。
* 实际用量报告缓存读取。
* 计入实测未命中率后仍能节省。
* 前缀版本管理简单且确定。
* 任务质量与回合数没有恶化。

否则，应先缩短提示词、只检索相关文件并压缩智能体循环。

## 结论

当一个大而有用、字节级稳定的前缀在某条确实报告低价缓存输入的路由上被反复使用时，提示词缓存才会降低编码智能体成本。把稳定内容放在前面，使用当前费率计算盈亏平衡，记录真实任务，并衡量每次被接受修改的成本。若提示词过度膨胀或智能体需要更多回合，高命中率也不代表成功。

## FAQ

### 哪些内容最适合提示词缓存？

稳定的系统指令、工具 Schema、仓库规范和很少变化的参考资料，比实时日志或最新用户消息更适合。

### 为什么可变内容应放在稳定前缀之后？

前缀缓存通常依赖完全一致的开头。把时间戳、请求 ID 或变化上下文放在前面，会让后续稳定内容也无法命中。

### 提示词缓存一定会降低延迟吗？

不一定。结果取决于供应商实现、缓存状态、路由、模型、请求大小和负载。延迟与成本应分开测量。

### 怎样计算盈亏平衡点？

根据预期复用次数比较普通输入成本、缓存写入成本和缓存读取成本，再加入工程成本与未命中率。

### 工具定义可以缓存吗？

如果供应商与所选协议把工具定义纳入缓存，它们可以成为重复前缀的一部分。不要猜测，应查看用量元数据。

### 应该缓存完整的编码会话记录吗？

通常不应该。会话每轮都在变化。应先放稳定指令与 Schema，再追加精简检查点和当前请求。