先说一个很多人第一次看 Agent 账单时的困惑：钱主要花在两件事上——每轮都在重发的系统提示词，和同一个问题反复查出来的结果。前者是输入侧的「固定开销」，后者是「重复劳动」。传统后端遇到这种情况早就加缓存了，但在 Agent 圈子里，缓存常常是最后才被想起来的那一环。
原因不难理解：大家觉得 Agent 的请求每次都不一样。但真实情况恰恰相反——Agent 的请求重复度远高于普通对话。它有固定的系统提示词、固定的工具定义、固定的知识片段，还有大量结构相似的子任务。这些正是缓存最擅长处理的东西。
这篇把 Agent 能用的缓存拆成三类，按落地顺序讲清楚：先做哪类、怎么量效果、以及那个最该防的事故——缓存中毒。
三类缓存，先分清楚
第一类：提示词缓存（Prompt Caching）。把请求前缀（系统提示词、工具定义、长文档）在服务端预计算并缓存，下次命中就不用重新算一遍。这是模型厂商层面提供的能力，几乎零改造成本。
第二类：结果缓存。你自己在应用层做的，把「输入 → 输出」存起来。工具调用结果、检索结果、模型回复都能存。
第三类：语义缓存。结果缓存的升级版——不要求输入完全一致，而是算向量相似度，问法不同但意思相同也能命中。
三类的复杂度、收益和风险完全不同，落地顺序建议是：先一、再二、最后三。
第一步：提示词缓存——性价比最高，先做这个
核心规则只有一条：把不变的东西放前面，把变的东西放后面。
主流的提示词缓存都是「前缀匹配」——从第一个 token 开始逐字比对，一旦遇上不一致的地方，后面全部失效。所以你的请求结构应该是：
系统提示词 → 工具定义 → 知识片段或长文档 → 对话历史 → 本轮用户输入
把易变内容（时间戳、用户 ID、随机种子、当前日期）往前塞，是最常见的错误——它会让整个前缀每次都失效，缓存命中率直接归零。
四个实操要点：（1）固定前缀尽量长。多数厂商有最小可缓存长度门槛，太短不计入。（2）注意缓存有效期。通常是几分钟到一小时，定时任务间隔太长，命中率天然就低。（3）把动态内容标准化。比如时间戳精确到天而不是秒，就能减少前缀变动。（4）工具定义的序列化顺序要固定。顺序一变，前缀就变了。
这一层的收益有多大？在「长系统提示词 + 大量工具定义」的重型 Agent 场景下，命中后输入侧的计费常见能降到原来的几分之一到十分之一。具体怎么算 Agent 的账，参见 AI Agent 成本怎么算、怎么省。
第二步：结果缓存——把「重复查询」按住
结果缓存分两块做，优先级不同。
工具结果缓存优先级最高。Agent 最容易重复调用的就是查询类工具：查商品、查库存、查天气、查汇率。这些数据在短周期内基本不变，缓存五分钟就能挡掉大量重复调用。做法是给工具包一层：缓存 key 用「工具名 + 规范化参数」，值存结果加时间戳。但有一条铁律——写操作绝不能缓存。下单、发邮件、删文件这类工具，缓存等于制造事故。
检索结果缓存次之。RAG 场景下，相同的 query 会反复出现，缓存「query → 命中片段」能显著降低向量库压力，也能顺手改善检索稳定性。检索本身怎么优化，参见 知识库检索怎么做才准确。
模型回复缓存要格外谨慎。只有当输入完全确定、且不依赖对话上下文时才可用。多轮对话里直接缓存整段回复，很容易把上一个用户的答案给到下一个用户。
第三步：语义缓存——收益最大，坑也最多
语义缓存的逻辑是：把输入向量化，和历史输入比相似度，超过阈值就返回对应的历史输出。
它适合什么场景？大量用户问同一类问题——客服 FAQ、产品参数查询、政策口径查询。这类场景里，十个用户的问法差异全是噪音，语义缓存能把命中率从百分之几拉到几十。
但它有一个致命风险：相似不等于等价。「怎么退款」和「怎么拒绝退款」、「能退货吗」和「不能退货吗」，向量距离可能很近，答案却完全相反。所以语义缓存必须做三件事：（1）阈值宁可高一点。拿不准就放行给模型，别为了命中率牺牲正确性。（2）对否定词和数字做硬校验。涉及金额、日期、正否的输入，命中后必须再走一遍规则比对。（3）按业务分池。不同产品线、不同权限等级的缓存不要混在一起，否则会出现跨权限的信息泄露。
缓存中毒：最该防的一类事故
「缓存中毒」指错误的、过期的或带恶意的内容被写进缓存，之后所有命中它的请求都拿到错答案。在 Agent 场景里，它比传统缓存更危险——因为错答案会被 Agent 当成事实继续往下推理，错误会一路放大。
四道防线：（1）所有缓存都必须设 TTL。永不过期的缓存是定时炸弹。（2）版本化。提示词、知识库、工具定义任一变更，都要把相关缓存整体失效。（3）只缓存可信来源。用户输入、外部网页抓取的内容不要直接进结果缓存，这正是 AI Agent 提示词注入攻击怎么防 里讲的间接注入入口。（4）留命中日志。每次命中都要记录「命中了哪条」，否则出了问题无法回溯，参考 AI Agent 审计查询字段怎么设计。
命中率怎么量：三个指标
光上缓存不看数据，等于白上。至少要盯三个数：命中率（命中次数除以总请求数）、命中收益（省下的 token 或金额）、错误命中率（命中后被打回或人工纠正的比例）。第三个最关键——很多人只看前两个，结果命中率很漂亮，用户体验却在掉。
还要注意缓存的「有效期错配」：业务对数据新鲜度的要求，必须和缓存的 TTL 匹配。查库存缓存五分钟可能没事，查价格缓存五分钟就可能报错价。
五个常见坑
坑一：把时间戳放在提示词最前面。看起来无害，实际上让每次请求的前缀都不同，提示词缓存全军覆没。坑二：给写操作加了缓存。重复下单、重复发通知，后果发生在真实世界。坑三：缓存了带权限差异的内容。A 部门查到的结果被 B 部门命中，属于数据事故，参见 AI Agent 权限管理怎么做。坑四：语义缓存阈值调太低。为了好看的命中率把阈值压下去，错误答案会明显增多。坑五：变更后不失效。知识库更新了，缓存还在返回旧口径，正是 知识库陈旧内容怎么巡检 要拦的那类问题。
适合人群
适合：已经在跑 Agent、账单开始变贵的团队；有大量重复查询或 FAQ 类请求的服务；长系统提示词加多工具定义的重型 Agent。不适合：还在原型阶段、请求量很小的项目——这时候优化缓存，收益还不如先把提示词写清楚。
总结
Agent 缓存，一条落地顺序：先把提示词结构理顺（不变的前置），再做工具与检索结果缓存（写操作除外），最后才上语义缓存（阈值宁高勿低）。三条心法：缓存必须有过期时间和版本；命中率要和错误命中率一起看；涉及权限、金额、正否的判断永远不能交给相似度。缓存省的是钱，但省下来的钱要建立在「答得一样对」之上。
