AI响应缓存如何判断适用边界

给 AI 接口加缓存，先别急着选 Redis。真正要判断的是：同样的请求会不会重复，旧答案现在是否仍然正确，用户是否接受再次看到它。客服问答、编程 Agent、实时订单查询，对这三个问题的回答完全不同。

原文给出的主张很明确：重复且稳定的业务适合缓存答案；Agent 和长对话更适合缓存提示词前缀。文章用 ZRouter 的配置解释具体做法，但没有提供性能对照或成本实测。值得借鉴的是判断方法，以及那些容易把省钱变成错误回答的边界。

缓存答案和缓存前缀，解决的是两件事

响应缓存（response caching）直接复用已经生成的答案。精确缓存要求请求匹配，语义缓存则允许措辞不同、意思相近的问题命中。

提供商的提示词缓存（prompt caching）复用的是输入前缀的处理结果，每次仍然生成答案。它适合指令、工具定义等内容很长，但当前问题持续变化的请求。

先判断答案能不能复用，再讨论命中率。

作者提出三个条件：请求会重复，旧答案依然正确，产品允许重复答案。全部满足，才考虑响应缓存。

FAQ 和客服助手比较接近这个条件：问题反复出现，知识相对稳定，回答一致通常还是优点。作者建议同时使用精确缓存、语义缓存和提示词缓存。

语义匹配要从严格开始。ZRouter 默认阈值是 0.92，但文章没有证明它适合所有业务。TTL，也就是缓存有效期，应跟知识更新节奏对应。原文举例：帮助中心每周更新，可以从一小时开始，ZRouter 的语义缓存默认配置为 SEMANTIC_CACHE_TTL=3600。

创作功能则不同。用户点击「重新生成」，就是想看到新答案。ZRouter 支持通过 Cache-Control: no-cache 或 Cache-Control: no-store 跳过两层响应缓存。

订单状态、BTC 价格、API 是否故障，也不能靠长期保存的答案回答。作者建议获取实时工具或检索结果，静态指令仍可利用提示词缓存。

RAG 和编程 Agent，为什么不能只看问题文本

检索增强生成（RAG）的答案同时取决于问题和检索文档。用户问法没变，文档更新了，正确答案也可能跟着变。

作者认为精确缓存适合 RAG，前提是检索上下文已经进入请求体，并参与缓存键计算。这样文档内容变化，请求就会变化。只拿问题文本做语义匹配，则可能返回旧文档支撑的答案。

按原文描述，ZRouter 只对最后一条用户消息做语义匹配，其余请求内容仍需匹配，包括其他消息中注入的上下文，以及近期对话窗口。窗口参数是 SEMANTIC_CACHE_MAX_CONV_MESSAGES，默认值为 3。即便如此，知识库频繁更新时，作者仍建议缩短 TTL。

Embedding 还有另一种复用机会：重新建立索引时，相同文本块可以命中 /v1/embeddings 的精确缓存，避免重复计费。

编程 Agent 的风险来自任务状态。文件、工具结果和执行进度都在变化，旧答案很难直接复用；长指令、工具 schema 和文件内容形成的稳定前缀，却适合提示词缓存。

这里有两个条件：

• 静态内容放前面，变化内容放后面。时间戳、随机 ID 放在开头，或者工具列表反复换顺序，都可能破坏命中。
• 同一会话尽量保持路由稳定。提供商缓存绑定具体提供商、模型，而且往往与 API key 有关，换目标就可能遇到冷缓存。

ZRouter 用会话保持处理第二点：根据 Claude Code、Codex CLI、OpenCode 等工具的会话请求头，将会话请求留在相同目标和提供商 key 上。

真正危险的是命中了不该复用的答案

语义相近，不代表操作意图相同。「取消订阅」与「续订」可能因为共享大量词语而被错误匹配。作者建议从高阈值开始，观察错误命中，再逐步放宽。

缓存键也不能只包含提示词。模型、temperature、工具、响应格式发生变化，请求就已经不同，否则可能把 JSON 模式的答案返回给纯文本请求。

原文称，ZRouter 的语义缓存键包含所有顶层请求选项和提供商扩展，精确缓存键包含解析后的提供商和模型。精确缓存键还包含最终生效的 guardrail chain，即安全规则处理链，防止规则更新后继续返回未经新规则检查的旧答案。

多租户隔离更关键。涉及姓名、账户或历史记录的答案，必须按用户或账户划分缓存。ZRouter 将认证访问范围和服务端确定的用户路径纳入两类缓存键；客户 API key 绑定 /accounts/ACCOUNT_ID，客户端请求头不能覆盖这个绑定。自带密钥（BYOK）请求则完全绕过共享响应缓存。

另外，失败响应不能缓存，备用模型的答案也不该挂在主模型名下。原文称 ZRouter 不缓存失败响应，也不缓存经故障切换返回的响应。

内容更新同样需要处理：旧条目会活到 TTL 到期，大规模更新后应考虑主动清理。对于评估、数据集分类、夜间摘要等批处理，输入重复且时效要求低，可以在任务期间采用较长 TTL，降低失败重跑的成本。

我的判断

我认同作者把正确性放在命中率之前。尤其是 Agent：先整理输入前缀和路由，比直接缓存最终回答更符合任务持续变化的特点。

但这篇是工程经验和产品机制说明，没有给出命中率、错误命中率、延迟或费用的对照数据。0.92 和一小时 TTL 都只能作为起点，不能当成通用最优配置。

RAG 的精确缓存安全性也有前提：变化后的检索内容必须进入缓存键。如果应用在检索前就按用户问题返回缓存，文章的推理便不成立。

相比语义缓存，精确缓存更容易解释和排查，但覆盖不了不同问法。是否值得引入语义匹配，要看业务能否承受错误复用，以及是否具备评估和监控能力。文章没有提供这部分成本。

提示词缓存也不能理解为自动生效。原文解释了前缀和路由条件，但没有展开各提供商的具体命中规则、计费方式及支持范围，接入时仍需核对。

能拿来做什么

• 给客服或知识库接口加缓存前，先检查重复请求、答案时效和个性化内容，再选择精确或语义缓存，并让 TTL 对应实际更新节奏。
• 使用编程 Agent 时，检查相邻请求开头几百个 token 的差异，把日期和随机 ID 移到后面，同时确认路由是否保持会话稳定。
• 在 Node 服务端维护缓存键时，把租户身份和影响答案的请求参数纳入计算，并确认规则变化、错误响应和故障切换如何处理。
• 给「重新生成」等功能保留按请求绕过缓存的入口；排查旧答案时，也要能区分响应缓存命中和提示词缓存命中。