LLM Agent Prompt Cache 深入浅出：从原理到设计实现与评估闭环

在 LLM Agent 系统里，很多人一开始优化的是模型选型、温度参数、工具编排，但上线后最先撞到的瓶颈通常是三件事：延迟、成本、稳定性。而这三件事，往往都能通过一个看似“朴素”的能力显著改善——Prompt Cache（提示缓存）。

这篇文章会按“是什么 → 为什么 → 怎么做 → 怎么评估”的顺序，帮你建立一套可落地的方法论。

---

1. Prompt Cache 到底在缓存什么？

1.1 先澄清一个误区

Prompt Cache 不是“把最终答案存起来”这么简单。对 Agent 来说，至少有四类可缓存对象：

1. 前缀上下文（Prefix）：例如系统提示词、角色说明、固定工具规范、长文档摘要。
2. 中间推理产物（Intermediate Artifacts）：例如检索结果、工具调用结果、结构化计划。
3. 模型响应（Completion）：同输入下的最终输出。
4. 执行轨迹片段（Trajectory Segment）：某个子任务在 ReAct/Plan-Execute 中的稳定步骤。

如果你只缓存第 3 类，收益往往有限；真正高收益通常来自第 1、2 类，因为复用率高且 token 占比大。

1.2 Agent 场景下的缓存粒度

常见的三个粒度：

• 请求级缓存：同一个用户请求重试时复用。
• 会话级缓存：同一会话多轮对话复用（如用户画像、会话摘要）。
• 全局级缓存：跨用户复用稳定公共上下文（如产品文档索引、政策规则解析结果）。

经验上：

• 延迟优化优先做请求级；
• 成本优化优先做会话级 + 全局级；
• 稳定性优化要重点做中间工具结果缓存和降级兜底。

---

2. 为什么 Prompt Cache 在 Agent 中收益更大？

Agent 比普通 Chat Completion 更“吃缓存”，因为它天然是多阶段流水线：

用户输入
  → 意图识别
  → 计划生成
  → 工具检索/调用
  → 结果整合
  → 最终回答

每个阶段都可能触发一次或多次 LLM 调用。假设平均每轮 4 次模型调用，只要缓存命中 1~2 次，中位延迟和 token 成本都会明显下降。

更关键的是，Agent 存在大量“伪动态内容”：

• 看起来每次都不同，实则 80% 是稳定前缀；
• 工具查询参数变化小，结果可短期复用；
• 类似任务反复出现（客服、知识问答、代码审查）。

所以 Agent 的 Prompt Cache 不是“锦上添花”，而是生产可用性的基础设施。

---

3. 设计篇：如何设计一个可用的 Prompt Cache

3.1 先做缓存对象分层

建议至少分三层：

L1：进程内热缓存（内存）

• 目标：极低延迟（微秒～毫秒）。
• 存储：最近高频 key（LRU/LFU）。
• 适合：短 TTL 的工具结果、会话热点片段。

L2：分布式缓存（Redis/Memcached）

• 目标：跨实例共享，低延迟。
• 存储：中等体量 prompt 片段、embedding 检索结果、结构化计划。
• 适合：大部分线上命中路径。

L3：对象存储/数据库（S3/Blob + 元数据表）

• 目标：大对象、长 TTL、可追溯。
• 存储：长文档处理结果、离线预计算上下文。
• 适合：冷数据和审计需求。

一句话：L1 抢延迟，L2 抢命中，L3 抢成本与留痕。

3.2 键（Cache Key）设计是成败关键

推荐键结构：

{tenant}:{app}:{model}:{prompt_version}:{tool_schema_version}:{normalized_input_hash}

其中关键点：

• tenant/app：避免租户数据串读。
• model：不同模型行为不同，不能混用。
• prompt_version：提示词升级后自动失效。
• tool_schema_version：工具参数结构变化后避免脏命中。
• normalized_input_hash：输入归一化后再哈希。

归一化可做：

• 去除无语义差异的空白和时间戳；
• 统一大小写、单位、标点；
• 对 JSON 参数做 canonical 序列化（字段排序）。

重点：不要直接 hash 原始字符串。你需要 hash“语义等价输入”。

3.3 缓存值（Value）不只存文本

建议 value 至少包含：

{
  "payload": "...",
  "created_at": "2026-03-07T12:00:00Z",
  "ttl_s": 600,
  "source": "llm|tool|retrieval",
  "cost_tokens_saved": 1320,
  "quality_guard": {
    "safety_level": "low_risk",
    "schema_valid": true
  }
}

这样你才能做后续评估：省了多少 token、是否带来质量回退、是否命中过高风险内容。

3.4 失效策略：TTL + 事件驱动双轨制

只靠 TTL 往往不够。建议组合：

• 时间失效（TTL）：例如 FAQ 结果 1h，天气 2min。
• 事件失效（Event-driven Invalidation）：文档更新、工具 schema 升级、权限变更时主动删 key。
• 版本失效（Version bump）：prompt_version/tool_schema_version 自动“软失效”。

实践中，把“会不会错”作为 TTL 的主因：

• 高风险任务（法律、医疗、交易）TTL 短甚至禁用全局缓存；
• 低风险任务（文案润色、通用说明）TTL 可更激进。

3.5 一致性与并发：防击穿、防雪崩、防污染

需要至少三个机制：

1. SingleFlight / 请求合并：同 key 并发 miss 时仅一次回源。
2. Stale-While-Revalidate（SWR）：过期后先返回旧值，再异步刷新。
3. 写入校验（Write Guard）：缓存前做 schema 验证与安全检查，防止错误结果污染缓存。

---

4. 实现篇：一个可落地的工程方案

下面给出简化版架构：

┌──────────────┐
│ API Gateway  │
└──────┬───────┘
       │
┌──────▼──────────────┐
│ Agent Orchestrator  │
│ 1) build cache key  │
│ 2) check L1/L2      │
│ 3) miss -> call LLM │
│ 4) validate + write │
└──────┬──────────────┘
       │
 ┌─────▼─────┐   ┌───────────┐
 │ L1 Memory │   │ L2 Redis  │
 └───────────┘   └─────┬─────┘
                       │
                  ┌────▼─────┐
                  │ L3 Store │
                  └──────────┘

4.1 伪代码：读路径

def cached_infer(ctx, prompt_obj):
    key = build_key(ctx, normalize(prompt_obj))

    hit = l1.get(key)
    if hit:
        return hit, "L1"

    hit = l2.get(key)
    if hit:
        l1.set(key, hit, ttl=short_ttl(hit))
        return hit, "L2"

    # 防击穿
    with singleflight_lock(key):
        hit2 = l2.get(key)
        if hit2:
            l1.set(key, hit2, ttl=short_ttl(hit2))
            return hit2, "L2-race"

        resp = llm_call(prompt_obj)
        if is_cacheable(resp, ctx):
            val = enrich_metadata(resp)
            l2.set(key, val, ttl=decide_ttl(ctx, val))
            l1.set(key, val, ttl=short_ttl(val))
        return resp, "MISS"

4.2 可缓存判定（Cacheability Policy）

至少用规则引擎控制：

• 含 PII/敏感字段的响应默认不进入全局缓存；
• 明确包含“实时性强”标记的数据（股价、库存）仅请求级缓存；
• 低置信度输出（如结构化校验失败）不缓存。

4.3 观测埋点（Observability）

每次请求记录：

• cache_hit（L1/L2/L3/MISS）
• latency_ms
• input_tokens / output_tokens
• estimated_cost
• quality_proxy_score（规则或小模型评估分）

没有埋点，就没有优化闭环。

---

5. 评估篇：如何证明你的缓存“有效且安全”

很多团队只看命中率，这是不够的。要至少看四组指标。

5.1 效率指标（Efficiency）

• Hit Rate：整体命中率 + 分层命中率（L1/L2）。
• P50/P95 Latency：尤其关注 P95 改善。
• Token Saved Rate：节省 token / 总 token。
• Cost Down %：单位请求成本下降比例。

5.2 质量指标（Quality）

• Answer Equivalence Rate：命中缓存 vs 实时生成，语义一致率。
• Task Success Rate：任务成功率是否下降。
• Hallucination Delta：幻觉率是否上升。

建议用离线回放集 + 在线 shadow 流量联合评估。

5.3 风险指标（Risk）

• Stale Error Rate：因过期或知识变更导致错误的比例。
• Cross-Tenant Leak Rate：跨租户串读（理应 0）。
• Sensitive Cache Ratio：敏感内容误缓存比例。

5.4 稳定性指标（Reliability）

• Cache Backend Availability：缓存服务可用性。
• Fallback Success Rate：缓存故障时回源成功率。
• Thundering Herd Events：击穿事件数量。

---

6. A/B 实验怎么做才靠谱

推荐最小实验设计：

• 实验单元：用户或会话级随机分桶；
• 对照组：禁用 Prompt Cache；
• 实验组：开启全链路缓存策略；
• 观察周期：至少覆盖业务高峰 + 低谷（如 7~14 天）。

核心判定：

1. 成本显著下降；
2. 延迟显著下降；
3. 质量无统计显著回退；
4. 风险指标保持在阈值内。

如果 1 和 2 提升，但 3/4 不达标，说明你的缓存是“快但不稳”，不能直接全量。

---

7. 常见坑位与规避建议

坑 1：只缓存最终答案，不缓存中间结果

• 后果：命中率低，收益不稳定。
• 建议：优先缓存长前缀和工具输出。

坑 2：key 里不带版本号

• 后果：prompt 更新后旧缓存污染。
• 建议：强制 prompt_version 入 key。

坑 3：没有租户隔离

• 后果：数据安全事故。
• 建议：tenant 维度强隔离 + 加密存储。

坑 4：以命中率为唯一优化目标

• 后果：命中率高但答案变旧、业务质量下滑。
• 建议：把质量和风险指标纳入 SLO。

坑 5：缓存故障没有降级路径

• 后果：缓存挂了，主链路雪崩。
• 建议：默认可回源，且设置限流熔断。

---

8. 一套可执行的落地路线图（90 天）

第 1 阶段（1~2 周）：

• 打通埋点（命中、延迟、token、质量代理分）；
• 只做请求级 + 会话级缓存；
• 实现基础 TTL 和版本化 key。

第 2 阶段（3~6 周）：

• 上 Redis 分布式缓存；
• 增加 SingleFlight / SWR；
• 接入事件失效（文档更新、权限更新）。

第 3 阶段（7~12 周）：

• 建立离线回放评估集；
• 开展 A/B 与灰度发布；
• 加入风险防护（敏感内容过滤、租户隔离审计）。

到这个阶段，你的 Prompt Cache 不只是“省钱插件”，而是 Agent 平台能力的一部分。

---

9. 结语

Prompt Cache 的本质不是“缓存文本”，而是把 Agent 执行中可复用的认知与计算结果工程化沉淀下来。设计得好，它同时提升：

• 效率（更快）
• 成本（更省）
• 稳定性（更稳）

真正成熟的实践一定是“三位一体”：设计合理、实现可控、评估闭环。如果你把这三件事做完整，Prompt Cache 会成为你 Agent 系统从 Demo 走向生产的分水岭。