Agent Prompt Caching/ 智能体提示缓存

Prompt Caching（提示缓存）是将 Agent 每次请求中**固定不变的部分**——如系统提示词、工具定义 Schema、Few-Shot 示例、知识库前置文档——在服务端缓存，后续请求只需引用缓存 ID 而非重传全文，从而大幅度减少输入 Token 消耗和首 Token 延迟（TTFT）。本质上是用「一次存储」换「每次传输」的优化策略。

Prompt Caching 按实现层级分为三种形态：

**1. 服务端自动缓存（Provider-Managed）——最省心**

Anthropic、OpenAI 等 LLM 提供商在服务端对请求做前缀匹配，自动识别并缓存相同的 prompt 前缀。开发者无需任何代码改动——同一会话中，只要系统提示词和工具定义不变，后续请求的输入 Token 开销（按缓存命中部分计费）通常降至完整价格的 10-25%。Anthropic 要求缓存段 ≥ 1024 Token（Claude），OpenAI 自动缓存 ≥ 1024 Token 的前缀（至少 1KB）。核心限制：仅对**精确匹配**的前缀生效，任何微小改动（如多一个空格）都会导致缓存失效。

**2. 客户端显式缓存（Explicit Marking）——最精细**

开发者通过 API 参数主动标记缓存的起止位置（breakpoint）。例如 Anthropic 的 `cache_control` 允许在请求中标注：「从第 0 行到第 1500 行是系统提示词，应该缓存」。这种方式让开发者可以精确控制「缓存块」的边界，突破「仅前缀」的限制，支持缓存中间的任意段落（如工具 Schema 定义块、Few-Shot 示例块）。OpenAI 也推出了类似的 manual caching 功能。

**3. 应用层缓存（Application-Layer）——最灵活**

在 Agent 框架层面实现缓存逻辑，不依赖 LLM 提供商的缓存机制。适用于多模型切换场景（如同时使用 GPT-4 和 Claude），在应用侧做 prompt 哈希 + KV 存储缓存。工具如 LangChain 的 `InMemoryCache`、GPTCache（https://github.com/zilliztech/GPTCache）支持语义相似度匹配（非精确匹配），但命中率低于 provider 级别的字节级匹配。

关键数据：根据 Anthropic 官方数据，缓存命中的 prompt 片段计费仅为原价的 10%（写缓存）+ 按需读取，输入成本可降低 90%；首 Token 延迟（TTFT）可降低 50-85%。

• **测试一：缓存命中率与成本对比**

• 操作：构造一个典型的 Agent 对话场景（系统提示词 2000 Token + 工具定义 1500 Token），连续发送 20 轮对话（每轮用户输入不同，但系统提示词和工具定义不变）。启用 Prompt Caching，对比启用/禁用缓存的 Token 消耗

• 工具：Anthropic API（`cache_control`）+ Python 脚本批量请求；OpenAI API（自动缓存，无需额外参数，`usage.cache_read_input_tokens` 字段检测命中）；LangSmith（https://smith.langchain.com）追踪每次请求的 Token 明细

• 指标：缓存命中率（目标 ≥ 95%，即 20 轮中有 ≥ 19 轮命中缓存）、输入 Token 成本节省比例（目标 ≥ 80%）、TTFT 降低比例（目标 ≥ 50%）

• **测试二：缓存失效边界测试**

• 操作：准备同一套系统提示词，在每次请求中微调缓存段的内容——分别测试「加一个空格」「改一个字符」「重新排序工具定义」「新增一个工具」等场景，观察缓存是否仍生效

• 工具：自定义 Pytest 测试套件 + Anthropic `/v1/messages` API 直接调用

• 指标：记录每种改动是否导致缓存失效（返回的 `cache_creation_input_tokens` vs `cache_read_input_tokens` 变化），输出「缓存鲁棒性矩阵」（哪些改动安全、哪些触发失效）

• **测试三：多 Provider 缓存一致性验证**

• 操作：同一套系统提示词和工具定义，分别在 Anthropic Claude、OpenAI GPT-4o、Google Gemini 上发送 10 轮对话，对比三者的缓存行为差异（自动缓存 vs 手动标记 vs 不支持）

• 工具：LangChain 多模型适配器 + LiteLLM（https://github.com/BerriAI/litellm）统一接口

• 指标：各 Provider 的缓存命中率、TTFT 改善幅度、缓存粒度（前缀级 vs 段落级 vs 不支持）

1. **「静默失效」——缓存不命中但 API 不报错**：Prompt Caching 的命中是透明的——API 不会报错告诉你「缓存未命中」，只会正常返回结果但按全价计费。如果 Agent 的系统提示词中有动态变量（如时间戳、用户 ID、随机种子），每次请求的 prompt 都不同，缓存永远不命中——但开发者可能毫不知情。解决方案：在日志中显式监控 `cache_read_input_tokens`（OpenAI）或 `cache_read_input_tokens`（Anthropic），当多轮会话中这个值始终为 0 时发出告警。

1. **缓存粒度陷阱——改一行全失效**：服务端自动缓存通常采用「前缀匹配」策略——从 prompt 开头逐字节比对，一旦某个位置不同，该位置之后**所有内容**都无法命中缓存。这意味着如果 Agent 在系统提示词中动态插入了用户名字或当前时间，这些动态内容会「打断」缓存链。解决方案：将动态内容放到 prompt 末尾（用户消息中），保持系统提示词和工具定义的绝对静态；或者使用 Anthropic 的 `cache_control` 显式标记多个独立缓存块。

1. **缓存过期与 TTL 不确定性**：LLM 提供商的缓存有 TTL（Time-To-Live），通常 5-30 分钟不等，且不保证一定缓存。在高并发或冷启动场景下，缓存可能被优先驱逐。解决方案：不要依赖缓存 100% 命中来满足 SLA；将其作为「锦上添花」的优化，而非系统设计的硬性依赖（即：即使缓存全部失效，系统仍能正常工作只是成本更高）。

• Anthropic 官方 Prompt Caching 文档: https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching

• OpenAI Prompt Caching 指南: https://platform.openai.com/docs/guides/prompt-caching

• GPTCache: 开源语义缓存方案（Zilliz）: https://github.com/zilliztech/GPTCache

• LangChain Prompt Caching 集成指南: https://python.langchain.com/docs/how_to/prompt_caching/