OOOMETA/OS
← 返回洞察

2026 年 9 月 · 8 分钟阅读

agent 成本的第一控制变量是上下文:缓存命中率比 token 单价更真实

agent 成本的第一控制变量是上下文:缓存命中率比 token 单价更真实

关键定义

提示缓存(prompt caching) 供应商把已计算的 KV 张量按提示词前缀缓存,后续共享该前缀的请求按约 0.10× 输入价计费(最高约 90% 折扣),模型输出逐字节不变。它只影响输入侧 token,输出 token 从不打折。

缓存命中率(cache hit rate) 命中已缓存前缀的请求占全部请求的比例。Anthropic 5 分钟档在命中率约 30% 以下时,写溢价会让缓存反而更贵;稳定前缀负载命中率长期低于 60% 属于结构性问题。

Keepalive(保活心跳) 在工具执行或人工审批等暂停期间,按定时器重发提示词前缀以刷新缓存 TTL、防止缓存被逐出。实测显示在 Anthropic 5 分钟 TTL 下经济间隔约 4 分钟,而非 30 秒的惯例。

如果你的 agent 账单在涨,先别急着换模型。2026 年的两份实证指向同一个结论:agent 成本的第一控制变量不是 token 单价,而是上下文布局与缓存生命周期——同一个模型、同一套提示词,仅仅改变内容顺序,成本就能差一倍以上。定价表决定单价,上下文设计决定你付几个单位。

证据一:缓存是 agent 负载的救星,但只在命中率够高时成立

提示缓存的机制是前缀复用:供应商把已计算的 KV 张量缓存起来,后续共享同一前缀的请求按约 0.10× 输入价计费,Anthropic 与 OpenAI 较新模型最高约 90% 折扣,Google 隐式缓存约 75%,DeepSeek 自动缓存约 0.1× 读价且无存储费(厂商 2026 年公布定价)。因为模型不重算已见过的内容,输出逐字节不变——这是唯一「免费且无损」的降本手段。PwC 团队的实证研究《Don’t Break the Cache》(arXiv 2601.06007,2026-02)在 500 多个 agent 会话、约 1 万 token 系统提示下测得:API 成本降 41-80%,首 token 延迟改善 13-31%。但同一研究也给出反直觉的警告:朴素的全量上下文缓存,在某些配置下反而会抬高延迟——缓存不是开关,是设计。

分水岭是命中率。Anthropic 5 分钟档有 +25% 写溢价,盈亏平衡点约每写 1 次需 1.4 次读;命中率低于约 30% 时,写溢价会超过读的节省,缓存反而更贵。对稳定前缀负载,命中率长期低于 60% 基本可以断定是结构问题,而不是运气问题(数字口径见文末 Digital Applied 2026-06 指南)。

证据二:ProjectDiscovery 的 7% → 84%:把工作记忆移出系统提示词

最有说服力的案例来自 ProjectDiscovery:把动态工作记忆从系统提示词里搬出来、放到末尾的用户消息后,缓存命中率从 7% 提到 84%,整体 LLM 成本降 59%,9.8 亿 token 改由缓存供应。原理是前缀缓存以字面 token 序列为键:前缀里任何一个字符变化,都会使该块及之后的所有内容失效。所以提示词必须按稳定性排序——工具定义、系统提示、参考文档放在前面,对话历史、实时查询放在最后。

证据三:暂停是缓存的头号杀手,keepalive 是解药

agent 循环是「思考—行动—等待」:发送请求后跑一次构建、跑一轮测试、或等人工审批,动辄几分钟。等跟随请求发出时,前缀缓存往往已被逐出——Anthropic 默认 TTL 5 分钟、OpenAI 空闲 5-10 分钟清空——于是重新按全价 prefill。arXiv 2607.19214《Keeping the Cache Warm Pays》(2026-07)给出量化答案:30 秒心跳能在 600 秒空隙里保持 40/40 前缀缓存(无心跳基线 0/48),暂停后请求成本最高省 12.5×;且 keepalive 成本随间隔单调下降,最优解是 TTL 允许的最大间隔——Anthropic 5 分钟档约 4 分钟,比 30 秒惯例省 8 倍保活开销。

另一个反直觉结论来自同一研究的供应商对照:DeepSeek 重 prefill 太便宜、不值得为它保活,Google 缓存几乎从不逐出——keepalive 对这两家只买延迟、不省钱。逐出点实测:Anthropic 约 5 分钟、DeepSeek 约 10 分钟、OpenAI 约 30 分钟、Google 几乎不逐出。你的供应商决定了保活策略有没有意义。

我们的判断:缓存命中率才是 agent 成本 KPI

行业讨论 agent 成本时,90% 的注意力花在「选哪个模型」「砍多少单价」上,这是上一轮 token 价格战的遗产。但 2026 年的账单结构已经变了:输入 token 常常远多于输出,而输入里的大部分是反复重发的同一段上下文。于是真正决定账单的三个变量是——前缀里有多少静态内容、动态内容放在哪、暂停期间缓存是否还活着。三个变量都不是模型属性,是上下文设计。

我们用自己的架构验证这套逻辑。OOMeta 的 agent 跑在 deepseek-v4-flash(自动前缀缓存、无存储费)与 gemini-3.5-flash 上,长会话叠加技能文件(SKILL.md)按需加载,构成天然稳定的可缓存前缀;「LLM 提议、脚本持久化」的原则让状态落在磁盘而不是上下文里,从源头控制前缀膨胀。日更 cron 队列的系统提示几乎不变,重复执行率极高——这是缓存友好负载,命中率就是我们最该盯的成本指标。另一面,凡是需要人工审批的高价值流程,暂停分钟级,keepalive 直接决定那一段是 0.1× 还是全价。

落地清单:今天就能做的四个动作

① 先看缓存命中率,再谈换模型

从供应商 dashboard 或 gateway 日志取命中率。稳定前缀负载低于 60% = 结构问题,先修结构;命中率过 80% 再考虑模型选型。

② 把动态内容移到提示词末尾

工作记忆、实时状态、临时指令全部放进最后的用户消息。前缀按稳定性排序:工具定义→系统提示→参考文档→对话历史→实时查询。

③ 给「等工具、等审批」的流程加 keepalive

间隔取 TTL 的 80% 左右:Anthropic 5 分钟档用约 4 分钟,OpenAI 用约 4 分钟。暂停超过逐出点的流程才值得保活;纯批处理无暂停的不用。

④ 选供应商时把缓存折扣和写溢价一起算

DeepSeek、OpenAI 无写溢价,适合间歇负载;Anthropic 1 小时档写溢价高,适合低频长会话;Google 显式缓存有存储费,读量大才划算。

行动建议:先回答一个问题,再动手

给 AI App lead 的决策问题:你的缓存命中率是多少?如果答案是「没看过」,那 41-80% 的成本空间大概率正躺在那里。把命中率接进成本 dashboard,做上面四件事,两周后对比账单——我们赌你会得出和我们一样的结论:agent 成本的第一控制变量不是模型,是上下文。

OOMeta AI

OOMeta 是 AI 原生的咨询与产品公司:一个人类、一群数字员工、一套运营智能。我们自己的 agent 每天跑在 deepseek-v4-flash 与 gemini-3.5-flash 上,用「LLM 提议、脚本持久化」控制上下文膨胀,用按需加载的技能文件维持可缓存前缀。上下文工程不是论文里的概念,是我们控制自身成本的方式,也是我们为客户设计 agent 系统时的默认杠杆。

预约诊断会

参考来源:arXiv 2601.06007《Don’t Break the Cache: An Evaluation of Prompt Caching for Long-Horizon Agentic Tasks》(PwC 团队,2026-02-03,独立研究)arxiv.org/abs/2601.06007 · arXiv 2607.19214《Keeping the Cache Warm Pays: Keepalive Economics for Agentic Workloads》(2026-07-24,独立研究)arxiv.org/abs/2607.19214 · Digital Applied《Prompt Caching in 2026: Cut LLM Costs, Keep Quality》(2026-06-16,含 ProjectDiscovery 案例与各家定价表)www.digitalapplied.com/blog/prompt-caching-2026-cut-llm-costs-engineering-guide · Anthropic Prompt Caching 文档(写溢价/TTL 档位,厂商口径)platform.claude.com/docs/en/build-with-claude/prompt-caching · OpenAI Prompt Caching 文档(厂商口径)platform.openai.com/docs/guides/prompt-caching

常见问题

为什么 agent 负载是缓存的最差用户?+

agent 的循环是「思考—行动—等待」:发送请求后跑工具或等审批几分钟,跟随请求到来时前缀缓存往往已被逐出——Anthropic 默认 TTL 5 分钟、OpenAI 空闲 5-10 分钟清空——于是重新按全价做 prefill。暂停越久,缓存越容易被浪费。

缓存真能省钱吗,数字是多少?+

arXiv 2601.06007(2026-02,PwC 团队):在 500 多个 agent 会话、约 1 万 token 系统提示下,提示缓存把 API 成本降低 41-80%、首 token 延迟改善 13-31%。但省不省取决于命中率——命中率过低时写溢价反而让缓存更贵。

命中率多低会亏钱?+

Anthropic 5 分钟档写溢价 +25%,盈亏平衡点约每写 1 次需 1.4 次读;命中率低于约 30% 时读的节省覆盖不了写溢价。稳定前缀负载命中率低于 60% 通常意味着前缀里有动态内容泄漏(Digital Applied 2026-06 口径)。

如何把命中率从个位数提到 80% 以上?+

按稳定性排序提示词内容:工具定义→系统提示→参考文档→对话历史→实时查询,动态工作记忆移到末尾的用户消息里。ProjectDiscovery 把工作记忆移出系统提示词后,命中率从 7% 提到 84%,LLM 总成本降 59%,9.8B token 来自缓存。

工具执行或人工审批暂停时怎么办?+

用 keepalive:暂停期间定时重发前缀刷新缓存。arXiv 2607.19214(2026-07)实测 30 秒心跳能在 600 秒空隙保持 40/40 前缀缓存(基线 0/48),暂停后请求成本最高省 12.5×;Anthropic 5 分钟 TTL 下最优间隔约 4 分钟,比 30 秒惯例省 8 倍保活开销。

各家供应商的缓存策略有什么不同?+

Anthropic 显式断点 + 写溢价(5 分钟档 +25%、1 小时档 +100%);OpenAI 自动缓存无写溢价、较新模型可 24 小时扩展;Google 隐式缓存约 75% 折扣、显式缓存另收存储费;DeepSeek 自动缓存约 0.1× 读价、无存储费(以上为 2026 年厂商公布定价)。DeepSeek 重 prefill 太便宜、Google 几乎不逐出,keepalive 对这两家只买延迟。