提示缓存与上下文复用-把长任务Agent的推理成本压下来

小助手

252人浏览 · 2026-11-03 08:30:57

小助手 · 2026-11-03 08:30:57 发布

文章目录

摘要

Agent 跑一个任务要调几十次模型，每次都把系统提示、工具定义、历史对话重新发一遍，token 成本就这样被重复计费吃掉。提示缓存是最直接的降本手段，但命中率往往低得离谱——不是技术不行，是提示组织方式有问题。本文讲提示缓存的命中条件、提示该怎么分层组织、以及多轮与多 Agent 场景下怎么把复用率真正做上去。2026 奇点智能技术大会（11 月 20-21 日·北京万达文华酒店）智能体应用创新专题会涉及这类成本工程。

▸ 核心结论：提示缓存的收益取决于命中率，而命中率取决于提示是否「前缀稳定」——动态内容必须后置
▸ 关键权衡：缓存粒度越粗命中率越高但越不灵活；过度追求复用会让提示结构僵化，改一处影响全部
▸ 适合谁读：做 Agent 应用、编排框架与成本优化的工程同学——发现 token 账单涨得比用户量快的团队

提示缓存
  账      一     重复计算到底浪费了多少
  条件    二     什么情况下能命中
  组织    三     提示怎么分层才稳定
  多轮    四     多轮对话的复用
  多体    五     多 Agent 场景
  度量    六     命中率怎么观测
  坑      七     常见误区
  落地    八     清单与衔接大会

一、重复计算到底浪费了多少

10 月 8 日 Anthropic 发布 Claude Haiku 5.5，官方给出的数字是速度提升约 30%、成本下降 75% 到 90%；同期 Copilot 也把 Agent 能力改成了按额度计费。模型侧在拼命降价，平台侧在精细计费——两边一起挤压之下，应用层把自己的 token 浪费管住，就成了最直接的一笔降本。本文聊的就是怎么管。

一个典型 Agent 任务：系统提示 2000 token，工具定义 3000 token，领域知识 5000 token，历史对话 10000 token，本轮新增输入 300 token。跑 30 轮下来，真正的新增内容不到一万 token，重复发送的部分却超过五十万。这就是为什么很多团队上线 Agent 后发现 token 消耗是同等问答量的几十倍——不是模型变贵了，是你在为同样的前缀反复付费。提示缓存的价值就在这里：前缀部分只算一次、按折扣计费，后续请求直接复用。

二、什么情况下能命中

命中条件比很多人想的严格：

前缀必须逐 token 完全一致。多一个空格、换一个标点都不算。
匹配是从第一个 token 开始的连续前缀，中间改一个字，后面全部失效。
缓存有生命周期，通常是几分钟到一小时不命中就被清掉，低频场景等于没缓存。
部分实现要求前缀长度过阈值才缓存，几百 token 的短前缀可能根本不进缓存。

理解这四条，就能明白为什么很多团队开了缓存却没省到钱：提示模板里塞了时间戳、会话 ID、动态检索结果，第一个 token 起就不一致，命中率自然接近零。

还有一种隐性浪费比重复前缀更大：为了「保险」把大量无关上下文塞进提示。典型表现是每次都把整个知识库的摘要塞进去，或者把历史工具返回的完整 JSON 原样保留。这些内容的 token 成本是实的，但对当前决策的贡献往往接近零。做一次审计很有必要：统计提示里每一段的实际引用率，把长期不被使用的段落删掉，收益通常比调缓存还大。

三、提示怎么分层才稳定

把提示按变化频率分层，是提升命中率最有效的动作：

第一层（几乎不变）：角色设定、输出格式规范、安全约束。放最前。
第二层（低频变化）：工具定义、领域知识、产品文档。放中间，按版本整体更新。
第三层（每轮变化）：检索到的实时内容、本轮用户输入、中间结果。放最后。

这个顺序不能反。很多团队习惯先把用户问题写在最前面「让模型先看到问题」，结果用户问题一变后面全部失效。正确的做法是让稳定的部分占据前缀，动态的部分沉到尾部。另一个细节：工具定义的顺序也要固定，别按调用频率动态排序。

提示分层（稳定 → 动态）
  ┌──────────────────────────────┐
  │ L1 角色设定 / 输出规范 / 安全约束 │ 几乎不变
  ├──────────────────────────────┤
  │ L2 工具定义 / 领域知识 / 文档     │ 低频变化
  ├──────────────────────────────┤
  │ L3 历史对话（增量追加）           │ 每轮增长
  ├──────────────────────────────┤
  │ L4 检索结果 / 本轮输入 / 中间结果  │ 每轮变化
  └──────────────────────────────┘
  缓存命中 = 从 token 0 起的连续前缀完全一致
  破坏因素：时间戳、会话ID、动态排序、中途压缩历史

四、多轮对话的复用

多轮是缓存收益最大的场景，也是最容易做坏的场景。要点：

增量追加而非重建：每轮只把新增内容追加到上一轮之后，不要每轮重新拼装完整提示。
历史压缩要小心：一旦压缩历史，前缀就变了，后面所有缓存失效。压缩时机要选在会话冷下来之后。
工具结果要稳定序列化：同一个工具两次调用返回的 JSON 字段顺序不同，也会破坏前缀。
分支要收敛：如果做过多路采样或回溯，注意它们会分叉出多条前缀，只有主路径能被复用。

工程上一个实用技巧是给会话加一个「前缀指纹」日志，一旦指纹异常变化就告警，能快速定位是谁破坏了缓存。

五、多 Agent 场景

多 Agent 架构下缓存更难做，因为每个子 Agent 的提示各不相同。可行策略：

共享前缀：所有子 Agent 共用同一份系统提示与工具集，差异部分放到各自的尾部。
角色模板固定：子 Agent 的角色描述用固定模板，不随任务动态生成。
调度亲和：把同一会话的请求路由到同一实例，避免缓存分散在多台机器上。
分层缓存：主 Agent 的规划上下文单独缓存，子 Agent 的执行上下文单独缓存。

路由亲和这一条最容易被忽略：缓存是实例本地的，请求打散到十台机器等于把缓存切成了十份，命中率直接掉一个量级。

六、命中率怎么观测

没有度量就没法优化。至少要看四个数：

整体命中率：缓存命中 token 占总输入 token 的比例，这是最终指标。
按层命中率：分别看系统提示层、工具层、历史层的命中情况，定位是哪一层在漏。
前缀失效次数：会话中途前缀被迫重建的次数，次数高说明历史压缩或动态插入太频繁。
成本对比：开缓存前后的实际账单，别只看命中率，最终要看钱。

把这四个数做成看板，每周看一次。命中率突然下降通常意味着有人改了提示模板，这种回归没有看板根本发现不了。

缓存与质量的冲突也要提前想清楚。为了让前缀稳定，有人会把个性化信息挪走，结果模型少了关键上下文，回答质量下降。这不是缓存的问题，是提示结构的问题。正确的做法是把个性化内容放在动态层，但保持它的格式稳定——变化的只是内容，不是结构。这样既保留质量，又不破坏前缀。

七、常见误区

几个高频坑：以为开了缓存开关就自动省钱，实际命中率不到百分之十；把检索结果插在提示中间，每轮检索内容不同导致后半段全部失效；为了「个性化」在系统提示里塞用户 ID 和时间，直接毁掉前缀；缓存有效期太短而请求间隔太长，等于白缓存；只算命中率不算成本，最后发现折扣后的收益覆盖不了缓存本身的存储开销。核心提醒就一句：缓存是结构设计问题，不是开关问题。

最后提醒一个容易忽略的收益点：缓存不只省钱，还省时间。命中缓存的部分跳过预填充计算，长提示场景下的首 token 时延会明显下降。所以即使成本压力不大，缓存也值得做——它同时改善账单和体验，这种双赢的优化不多见。度量时记得把时延收益也记进去。

八、衔接大会专题

Agent 的成本控制、上下文工程、推理优化，属于大会智能体应用创新与开发实践专题的典型话题。2026 奇点智能技术大会与 C++ 及系统软件技术大会同期举办，时间 2026 年 11 月 20-21 日，地点北京万达文华酒店，共设 9 大专题、70 余场演讲，覆盖大模型技术、Agentic Scaling、AI 原生软件研发、AI 计算平台、企业级 AI 原生应用与落地、智能体应用创新与开发实践、多模态与世界模型演进、从具身智能到物理 AI、AI+ 行业应用实践。被 token 账单困扰的团队可以在这一专题找到不少实操经验。