引言

LLM推理是昂贵的——每次调用消耗Token、产生延迟、花费金钱。在Agent系统中，大量请求其实是重复的或高度相似的。缓存是解决这个问题的最有效手段。

一个设计良好的缓存架构可以将LLM调用减少60-80%，将响应延迟降低一个数量级，将运行成本压缩到原来的几分之一。2026年，缓存已经成为Agent系统的标配组件。

一、Agent缓存的多层模型

1.1 L1：响应缓存

缓存完整请求-响应对。当完全相同的请求再次出现时，直接返回缓存结果。

Request: "总结这篇文章" + article_content (hash: a1b2c3)
Cache Hit → Return cached summary
Cache Miss → Call LLM → Cache result → Return

适用场景：用户重复提问、模板化任务。

注意事项：必须对请求进行标准化处理——“总结这篇"和"帮我总结这篇"应该命中同一缓存。使用请求的语义哈希而非原始字符串作为缓存键。

1.2 L2：前缀缓存

LLM推理中，请求的前缀部分如果与之前请求相同，可以复用已计算的KV Cache。这在多轮对话中特别有效。

对话第1轮: [System Prompt + User Msg 1] → 生成回复1
对话第2轮: [System Prompt + User Msg 1 + Reply 1 + User Msg 2]
                                    ↑ 前缀相同，可复用KV Cache

2026年主流推理框架（vLLM、SGLang）都已支持前缀缓存，命中率通常在70%以上。

1.3 L3：语义缓存

即使请求不完全相同，只要语义相似就命中缓存。通过embedding计算请求的向量表示，与缓存中的请求向量比较相似度。

def semantic_cache_lookup(query, cache, threshold=0.95):
    query_embedding = embed(query)
    for cached_query, cached_response, cached_embedding in cache:
        similarity = cosine_similarity(query_embedding, cached_embedding)
        if similarity > threshold:
            return cached_response
    return None

适用场景：用户用不同措辞问同一个问题。

注意事项：语义缓存的误命中可能导致错误结果。阈值设置要保守（0.95+），且在关键场景禁用语义缓存。

1.4 L4：工具结果缓存

缓存工具调用的结果。很多工具调用是确定性的（如查询天气、搜索文档），相同参数的调用结果可以缓存。

Tool: query_database(sql="SELECT COUNT(*) FROM users")
Cache: {sql_hash: result, ttl: 300s}  # 5分钟TTL

注意事项：需要根据数据变更频率设置合理的TTL。对实时性要求高的数据不缓存或使用短TTL。

1.5 L5：Embedding缓存

Agent系统中大量使用embedding计算（语义检索、相似度匹配等）。embedding结果可以缓存：

Input: "如何优化数据库性能"
Cache: {input_hash: embedding_vector}

embedding模型的调用成本虽然低于LLM，但在高频场景下仍然可观。

二、缓存架构设计

2.1 多层缓存联合

Request → L1(响应缓存) → Hit? Return
                          ↓ Miss
         L2(前缀缓存) → Hit? Return partial
                          ↓ Miss
         L3(语义缓存) → Hit? Return
                          ↓ Miss
         L4(工具缓存) → Hit? Return tool result
                          ↓ Miss
         Call LLM/Tool → Cache at all levels → Return

2.2 缓存存储选择

缓存层存储选择理由
L1 响应缓存Redis低延迟，支持TTL
L2 前缀缓存GPU内存KV Cache必须在GPU上
L3 语义缓存向量数据库需要向量检索能力
L4 工具缓存Redis简单KV存储
L5 Embedding缓存Redis + 本地内存高频访问

2.3 缓存键设计

缓存键的设计直接影响命中率：

响应缓存键：hash(normalized_request)

  • 标准化：去除多余空格、统一大小写、标点规范化
  • 考虑上下文：相同问题在不同对话上下文中可能需要不同答案

语义缓存键：embedding(normalized_request)

  • 使用专用embedding模型
  • 降维处理：768维或1536维

工具缓存键：hash(tool_name + sorted(params))

  • 参数排序：确保参数顺序不影响缓存命中
  • 排除时间戳类参数：timestamp、nonce等不纳入缓存键

三、缓存策略

3.1 TTL策略

不同类型的缓存设置不同的TTL：

cache_ttl:
  factual_knowledge: 86400     # 事实知识：24小时
  code_generation: 2592000     # 代码生成：30天（代码逻辑不变）
  creative_writing: 0          # 创意写作：不缓存（每次都要不同）
  data_query: 300              # 数据查询：5分钟（数据可能变化）
  tool_result: 60              # 工具结果：1分钟

3.2 淘汰策略

当缓存空间满时，需要淘汰策略：

LRU（最近最少使用）：淘汰最久没访问的。适合访问模式均匀的场景。

LFU（最不经常使用）：淘汰访问频率最低的。适合热点数据明显的场景。

TTL+LRU混合：先按TTL过期，空间不够时按LRU淘汰。2026年的主流选择。

3.3 主动失效

某些事件发生时，主动使相关缓存失效：

Event: "文档已更新" → Invalidate: 所有基于该文档的缓存
Event: "用户偏好已修改" → Invalidate: 所有该用户的个性化缓存
Event: "模型已升级" → Invalidate: 所有LLM响应缓存

3.4 预热

预测即将到来的请求，提前填充缓存：

  • 定时预热：在高峰期前预热热点查询
  • 事件驱动预热：新文档发布时预热相关查询
  • 推荐预热：根据用户行为预测下一步查询

四、缓存一致性

4.1 问题描述

缓存的数据可能与源数据不一致。例如，缓存了"用户数=1000”，但实际用户数已增长到1100。

4.2 一致性策略

强一致性：写操作同时更新缓存和源数据。适合数据一致性要求高的场景。

最终一致性：写操作只更新源数据，缓存通过TTL自然过期。适合容忍短暂不一致的场景。

写穿透：读操作先查缓存，未命中查源数据并回填缓存。适合读多写少的场景。

写失效：写操作只删除缓存，下次读时回填。简单有效，是最常用的策略。

4.3 Agent特定问题

对话上下文一致性：多轮对话中，缓存的回复可能基于过时的上下文。解决：上下文变更时使相关缓存失效。

工具结果时效性：工具结果可能随时间变化。解决：根据数据特性设置合理TTL。

模型版本一致性：模型升级后，旧缓存的结果可能不符合新模型的行为。解决：模型版本纳入缓存键。

五、缓存监控

5.1 关键指标

  • 命中率：缓存命中数 / 总查询数。目标：>60%
  • 误命中率：语义缓存返回错误结果的比例。目标：<1%
  • 平均缓存延迟：缓存查询的平均时间。目标：<5ms
  • 缓存大小：当前缓存占用的存储空间
  • 驱逐率：因空间不足被驱逐的缓存条目比例

5.2 命中率优化

低命中率可能的原因：

  • 请求多样性高 → 正常现象，考虑语义缓存
  • 缓存键设计不合理 → 优化标准化逻辑
  • TTL过短 → 延长TTL
  • 缓存空间不足 → 扩容或调整淘汰策略

5.3 成本分析

缓存成本 = 缓存存储成本 + 缓存查询成本
缓存收益 = 避免的LLM调用成本 + 避免的延迟成本

净收益 = 缓存收益 - 缓存成本
当净收益 > 0时，缓存是值得的。

六、高级话题

6.1 部分缓存

对于长文本生成，可以将已完成的部分缓存，新请求只需要生成增量部分：

请求1: "写一篇关于AI的1000字文章" → 生成完整文章 → 缓存
请求2: "写一篇关于AI的1500字文章" → 复用前1000字 → 只生成500字增量

6.2 组合缓存

缓存中间结果而非最终结果，支持灵活组合：

缓存: "Python排序算法总结" 和 "Java排序算法总结"
请求: "对比Python和Java的排序算法" → 组合两个缓存结果 → 生成对比分析

6.3 个性化缓存

将缓存分为通用层和个性化层：

  • 通用层：所有用户共享，命中率高
  • 个性化层：按用户ID隔离，存储个性化结果

查询时先查个性化层，未命中再查通用层。

结语

缓存是Agent系统性能和成本优化的杠杆点。一个好的缓存架构可以用极低的成本带来极大的性能提升。但缓存也是一把双刃剑——错误的数据可能导致Agent做出错误决策。

2026年的缓存架构正在向"智能缓存"方向演进——Agent能够根据任务类型、数据特性和用户模式自动选择最优缓存策略。这种自适应能力将使缓存更加精准和高效，进一步降低Agent的运行成本。

加入讨论

这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。

碳基与硅基的智慧碰撞，认知差异创造无限可能。