Agent Caching Strategies/ 智能体缓存策略

缓存策略是智能体的「过目不忘」能力——通过 Prompt 缓存、语义缓存和结果缓存三层架构，让 Agent 不再每次都从零开始思考。把每次调用都视为「初次见面」的 Agent 是在烧钱，聪明地用缓存就是在赚钱：重复调用成本可降低 50%-90%，延迟从秒级降到毫秒级。

Agent 缓存分为三层，自上而下延迟递减、命中率递增：

**1. Prompt 缓存（Prompt Caching）——「系统提示不用反复读」**

2024-2025 年各大模型厂商相继推出 Prompt Caching API（Anthropic 2024年8月、OpenAI 2024年10月、Google Gemini 2024年9月），核心思想是：同一会话中重复出现的长前缀（如 system prompt、工具定义、少样本示例）只计一次 Token 费用。

• Anthropic：自动缓存长前缀，缓存命中后读取费用为原价的 10%，写入按全价

• OpenAI：需显式标记缓存断点（breakpoint），命中后输入 Token 打 5 折

• Google Gemini：context caching，创建缓存后小时级复用，成本降至 1/4

**2. 语义缓存（Semantic Cache）——「相似问题不再重新推理」**

不同于传统精确匹配缓存，语义缓存用向量相似度判断两个问题是否「本质相同」。例如"查一下今天的 BTC 价格"和"比特币现在多少钱"在语义上是同一个问题，返回缓存结果而无需再次调用 LLM + 工具。

• 架构：用户 query → embedding 向量 → 向量数据库（如 Qdrant/Milvus）检索 top-K 相似 → 相似度 ≥ 阈值（如 0.92）→ 直接返回缓存结果

• 典型工具：GPTCache（LLM 生态最成熟的语义缓存框架）、LangChain CacheBackedEmbeddings

**3. 结果缓存（Result Cache）——「工具调用结果不过期不重调」**

Agent 经常重复调用同一工具（如「查北京天气」「读今天的新闻头条」），结果缓存将工具调用（函数名 + 参数）作为 key，返回值作为 value，设置合理的 TTL。这是三层中最简单但收益最大的：天气 TTL=30min、新闻 TTL=1h、股价 TTL=5min、文档内容 TTL=24h。

• 存储：Redis（推荐，内存 + TTL 天然支持）或本地 LRU Cache

• 关键决策：TTL 怎么设置？原则是「数据变化频率 < TTL」，天气 30 分钟、股价 5 分钟、企业文档 24 小时、API 文档 7 天

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

• 操作：构造 100 轮长对话（system prompt 5000 tokens + 工具定义 3000 tokens），前 50 轮用同一 system prompt（应触发缓存），后 50 轮每次微调 1 个字符破坏缓存。通过 API response 的 `cache_creation_input_tokens` / `cache_read_input_tokens` 字段追踪命中率

• 工具：Anthropic API（https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching）或 OpenAI API（https://platform.openai.com/docs/guides/prompt-caching）。使用 Python `anthropic` SDK 的 `usage` 对象

• 指标：缓存命中率 ≥ 90%（前 50 轮），缓存破坏后命中率陡降为 0%。总成本相比不启用缓存降低 ≥ 70%

• 测试二：语义缓存命中率与质量验证

• 操作：预先填充 200 组 Q&A 对到 GPTCache。发送 50 个语义等价但表述不同的变体问题（如同义词替换、语序调整、中英混用），统计缓存命中数。同时用 LLM-as-Judge 对比缓存返回结果和实时计算结果的一致性

• 工具：GPTCache（https://github.com/zilliztech/GPTCache）+ Qdrant（https://qdrant.tech）向量数据库。相似度阈值设为 0.92

• 指标：语义缓存命中率 ≥ 60%（50 个变体中 ≥ 30 个命中），缓存结果与实时结果一致性 ≥ 95%，缓存延迟 < 10ms vs 实时调用 2s+

• 测试三：结果缓存的 TTL 过期验证

• 操作：Agent 连续 100 次调用同一个对外部 API（如天气接口），前 80 次在 TTL 有效期内应全量命中缓存，第 81 次在 TTL 过期后应触发实际 API 调用。用 Redis MONITOR 命令实时观察缓存命中和穿透

• 工具：Redis（https://redis.io）+ redis-py 客户端 + LangChain 的 InMemoryCache / RedisCache

• 指标：TTL 内命中率 100%（0 次穿透），过期后首次穿透后重新缓存。API 总调用次数从 100 降至 ≤ 5（假设 TTL 覆盖足够长），成本降低 ≥ 90%

1. **Prompt 缓存的「一个字符破坏全部」**：Anthropic 和 OpenAI 的 Prompt Caching 是前缀匹配，缓存从第一条消息开头计算。如果你在 system prompt 中拼接了动态时间戳（如"现在是 2026-07-07 14:32:15"），缓存每次都被破坏，命中率为 0。正确做法：把动态内容放在末尾（user message），静态内容（工具定义、角色设定）放最前面。

1. **语义缓存的「假命中」风险**：相似度阈值调得太低（如 0.85），会把「今天 BTC 价格多少」和「ETH 价格多少」视为同类问题返回错误缓存。阈值调得太高（如 0.98），命中率太低形同虚设。最佳实践是用一个小型 BERT 模型做二分类器——先判断两个问题是否「同义」，再查缓存，而非单纯依赖余弦相似度。

1. **结果缓存导致「信息茧房」**：Agent 缓存了新闻搜索结果 1 小时，但期间发生了重大事件，Agent 还在给用户返回过时的缓存结果。解决：对关键数据源（新闻、股价、天气）使用更短的 TTL，并在缓存值中附带 `cached_at` 时间戳，Agent 输出时标注「数据获取于 X 分钟前」，让用户自行判断时效性。

• Anthropic Prompt Caching 官方文档（自动缓存 + 成本降低 90%）: https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching

• OpenAI Prompt Caching 指南（手动断点 + 5 折优惠）: https://platform.openai.com/docs/guides/prompt-caching

• Google Gemini Context Caching（小时级缓存复用）: https://ai.google.dev/gemini-api/docs/caching

• GPTCache：LLM 语义缓存框架（GitHub 7k+ stars）: https://github.com/zilliztech/GPTCache

• LangChain Cache 模块（内存/Redis/SQLite 多种后端）: https://python.langchain.com/docs/how_to/llm_caching/