第一次和智能体打交道的人通常会被一个现象吓到。同样的问题直接问模型一次只要几毛钱塞给智能体跑一轮任务账单可能翻几倍甚至几十倍。不是模型偷偷加价而是智能体每次调用都要把系统提示、工具定义、历史对话、中间结果全部重新送一遍。这就像每次开会都要求所有人从头读一遍合同全文而真正新增的内容只有一行。所以我看到“缓存读取降价75%”这种消息时第一反应不是“输入便宜了”而是“智能体负载的账单逻辑终于要变天了”。如果缓存读取价格下降75%那意味着原本最贵的那部分重复上下文变成了几乎廉价的公共资源。按标题测算它能推动智能体负载整体成本下降约45%。这个数字听起来很诱人但真正值得研究的不是数字本身而是它背后的成本结构变化以及你该怎么利用这个变化把应用从“演示级”推进到“可长期运行级”。注意我这里的分析基于标题给出的场景假设Claude Fable 5.1 将缓存读取价格下调75%。具体的API定价、缓存策略、计费方式可能随版本和地区调整。落地前你需要以官方文档和实际账单为准。但这不影响我们拆解“为什么缓存降价对智能体影响这么大”这个本质问题。1. 先看明白智能体负载的账单到底贵在哪里1.1 智能体请求不是一次问答而是一串“带着全量记忆”的调用先搞清楚我们说的“成本”是什么。普通的文本生成你输入一段Prompt模型返回一段回答账单就是这一次模型的输入Token和输出Token。但智能体不是这样。它通常要执行一个循环接收用户任务、理解、规划、调用工具、拿到工具结果、再次理解、生成下一步行动直到任务完成。每走一步都要调用一次模型。问题在于每一步调用不是只带上最新的一步。为了让模型保持连贯你必须把整个会话的上下文都带上。这个上下文包括系统提示规定智能体是什么角色、用什么风格、有哪些策略。工具定义每个工具的说明、参数、使用约束有时还有几十个工具的JSON Schema。对话历史从第一句用户问题到当前这一步的所有消息。中间结果比如工具返回的日志、代码、表格、错误信息。外部数据比如检索回来的知识、文件内容、数据库查询结果。每一次模型调用都要重新发送这些内容。任务越长上下文越大调用次数越多账单就呈叠加式增长。这不是线性增长而是接近几何级数每多一步不仅要为新输出付费还要为前面所有步骤的重复输入再付一次费。1.2 重复上下文才是成本大头你可能会想上下文就算重复发送一次也没多少吧但如果你把一个真实的智能体请求抓下来看会发现输入Token中真正“新增”的部分往往只占很小比例。假设一个客服智能体系统提示500 Token工具定义2000 Token历史对话3000 Token每轮用户输入和工具结果大概500 Token。那么下一次调用时5000 Token是重复的只有500 Token是新的。比例是10:1。在小规模测试中10倍重复还不太心疼。但一旦放到生产环境每天几万次调用重复Token的消耗就变成成本主体。而且上下文还会累积多轮对话里历史消息越来越长工具调用链里中间结果越来越多多智能体协作场景里每个智能体都要共享全局上下文。重复上下文在总费用中的占比可以轻松超过80%。所以很多团队做智能体第一版Demo跑得飞快一到内测就发现API账单飞速上涨。不是模型贵是架构让模型不得不反复“重读”同样的内容。这也解释了为什么缓存读取降价75%能成为智能体成本优化的关键事件。1.3 缓存读取降价75%意味着什么如果按标题场景理解缓存读取价格下降75%就相当于原本每1万Token重复输入的单价降到了原来的四分之一。注意这里不是免单而是把最贵的“反复全价重发”变成“低价命中缓存”。从成本结构看如果一个智能体请求中80%的Token是重复上下文而这部分重复上下文以缓存读取方式计费价格又降到原来的25%那么这部分费用就变成原来的四分之一。整体成本就能明显下降。标题里给出整体压45%说明不是所有请求都能命中缓存、也不是所有Token都能走缓存读取但这依然是一个幅度很大的结构优化。更重要的一点是降价之后缓存读取的经济账在工程上会被重新算。以前你会刻意控制上下文长度、减少历史消息、压缩工具定义甚至牺牲一部分智能体能力来省成本。现在缓存读取便宜了你可以更大胆地往上下文里放系统知识、工具示例、长期记忆而不必担心成本爆炸。这才是这次降价真正改变的地方。2. 缓存读取降价的杠杆作用不只是省一次费用2.1 从单次省钱到整体成本压低的传导逻辑很多人会把“缓存读取降价75%”理解为“我的API账单少25%”或“少75%”这都不准确。它真正的作用是降低每一轮重复上下文的边际成本进而从三个层面传导到整体成本。第一多轮对话场景中单次调用的输入费用下降。因为每轮调用都有大量重复上下文降价后这部分从全价变为折价。第二工具调用频繁的智能体每次工具返回后模型都要再次读取完整上下文这个读取次数很多降价后的累计效益更明显。第三长任务场景中上下文可能超过缓存窗口但合理设计后大部分前缀仍能命中成本也能持续压低。所以整体45%是一个综合结果。它包含缓存命中率、Token分布、任务类型、上下文长度等因素。不要指望所有请求都缓存也不要认为便宜了就能乱用。理解这个传导逻辑你才能正确预估自己的节省幅度。2.2 为什么整体能压45%而不是75%如果缓存读取降价75%为什么整体不是降低75%原因很简单缓存读取不是所有成本。智能体负载的成本至少包括四块正常输入Token首次发送或未命中缓存的前缀Token按标准输入价格计费。缓存读取Token命中了缓存前缀的那部分Token按降价后的缓存读取价格计费。输出Token模型的生成结果通常比输入价格更贵不受缓存降价影响。其他成本比如工具调用次数、外部API费用、基础设施成本、调度开销等也不在缓存降价范围内。假设一个请求里重复上下文占总输入Token的80%而缓存完全命中那么输入费用降幅大约是80% × (1-25%) 60%。但输出Token仍占很大比例。如果输出Token占了总费用的50%那么整体降幅就变成30%左右。再加上一些请求未命中、有些前缀无法缓存最终落到45%是合理的量级。反过来说如果你的应用是输出密集型缓存降价带来的整体节省会更小。这说明一个关键判断缓存降价的最大受益者是“输入密集、重复上下文占比高”的负载而不是所有负载。智能体正好符合这个特征所以标题场景才有意义。2.3 成本结构变了使用方式也要变价格下降不是让你躺平而是改变了优化的优先级。以前你用尽全力压缩提示词、减少历史消息、给工具定义瘦身现在你可以重新权衡。比如以前为了控制Token你可能故意不把某个详细的工具使用示例放进系统提示而是让模型靠名字猜测。现在缓存便宜了你可以在系统提示里放更完整的示例、更长的背景文档、更明确的约束条件让模型更稳定地完成任务。因为这份“长提示”一旦缓存每次读取都便宜整体效果反而更好。这意味着成本优化从“尽量少写”变成“把该写的一次写够然后让缓存承担重复读取”。不是鼓励堆Token而是把一次性构建成本变成摊销成本。3. 真正用好缓存降价要从工作流和代码层面配合3.1 先确认你的调用链支持prompt caching别急着高兴先检查你的SDK、API版本和调用方式是否支持缓存读取。大多数大模型API都提供Prompt Caching能力但不同平台有不同规则有的需要显式开启缓存参数有的会自动缓存前缀有的只支持特定模型版本有的要求缓存内容不少于某个最小Token数。以常见实现为例缓存的最小长度通常在1024或4096 Token以上太短的前缀不会触发缓存。另外缓存有TTL比如5分钟、1小时超过时间会失效。如果你的智能体每次调用间隔超过TTL就需要重新支付正常输入价格再重新建立缓存。因此设计调用间隔和会话粘性很重要。一个稳妥的验证方法是先写一个最小脚本用同一段前缀连续调用两次看账单或日志中第二次调用的输入价格是否变为缓存读取价格。如果API返回里包含cache creation和cache read的usage字段就能明确判断。这一步不确认好后面做的所有优化都是空中楼阁。3.2 设计稳定的前缀系统提示、工具定义、长期记忆放前面缓存命中的前提是前缀完全一致。Token序列按前缀匹配只要前缀中有任何字符变化缓存就从变化点之后失效。所以你要把“几乎不变”的内容放在最前面把“经常变化”的内容放在后面。推荐的结构系统提示版本固定 工具定义JSON Schema 核心知识库指令不变 长期记忆历史窗口如固定格式 当前任务描述可变 最近对话轮次按时间顺序 工具返回结果最新以Claude Code这类编码智能体为例它的系统提示、工具列表、工作流说明通常很长且固定每个请求都重复。如果这些内容排在前面缓存命中率会非常高。而每次用户提问、代码差异、文件内容等动态信息排在后面就不会破坏缓存。要养成一个习惯任何需要长期复用的内容都尽量写成稳定模板。哪怕是日期、版本号也尽量放到后面或单独字段。否则这些看起来很小的变化会让缓存全部失效前功尽弃。3.3 确认缓存命中和失效的策略使用缓存读取不是“我加了缓存前缀就一定能省钱”。你需要在代码里记录和评估命中情况。常见的做法是在响应里读取cache_read_input_tokens和cache_creation_input_tokens字段。把这两个值计入日志和监控面板。计算命中率cache_read_tokens / (cache_read_tokens cache_creation_tokens normal_input_tokens)。对命中率低的请求分析前缀稳定性。如果命中率低多半是前缀经常变动。比如系统提示里放了动态时间或随机ID或者使用了错误的上下文拼接顺序。修复方法就是把变动内容移到后面或者把动态内容提炼出来单独作为消息。另外要注意缓存内容安全。当你更新了系统提示或工具定义时要主动让缓存重新生成。有些SDK提供cache_control参数用来标记哪些内容需要缓存。没有标记时只有自动缓存的规则生效。正确标记能减少缓存空间的浪费。3.4 结合批量任务的成本估算理解了缓存机制后对你的智能体负载做一次成本估算会让优化更有依据。你可以按这个公式粗算单次调用成本 正常输入Token × 正常输入单价 缓存创建Token × 缓存创建单价 缓存读取Token × 缓存读取单价 输出Token × 输出单价注意缓存创建的价格通常高于正常输入因为后台需要记录并存储。在实际操作中第一次调用不省钱甚至会略贵。但从第二次开始如果前缀命中就按缓存读取计价。所以成本优化的目标是让同一个前缀在TTL内被多次读取读取次数越多摊销效果越好。批量任务是最能体现这个优势的场景。比如你要用智能体处理1000份文档系统提示和工具定义保持不变每次任务只是替换输入文档内容。只要保持前缀一致每一份文档的模型调用都能命中缓存。以前1000份文档要重复支付1000次系统提示费用现在几乎只付一次创建费用加999次读取费用。这就是缓存降价带来的规模效应。4. 适合谁、不适合谁缓存降价的适用边界4.1 适合多轮对话、工具调用、长上下文分析、代码生成助手先看最适合的场景。多轮对话助手每一轮都要携带完整历史缓存降价可以显著降低单用户会话的持续成本。工具调用智能体每次工具调用前后都要重新发送系统提示和工具定义。这类负载的重复率极高是缓存降价的最大受益者。长上下文分析比如分析整份代码库、长篇文档、审计报告。如果多次提问同一个文档缓存可以把“文档内容”变成廉价资源。代码生成与代码编辑工具Claude Code这类工具中系统提示、工具规则、工作区说明都是固定前缀。实际使用中一个会话可能产生几十次模型调用缓存优势非常明显。多智能体协作框架Agent A、Agent B共享的全局指令和工具协议如果能设计成稳定前缀也能获得成本优势。这些场景的共同点是同一个上下文被反复读取动态内容占比较低。4.2 不适合一次性短查询、随机性太强的任务、频繁变化的前缀缓存降价不是万能药。有些场景应用它意义不大甚至可能增加成本。一次性短查询前缀长度不足最小缓存阈值或只调用一次就结束缓存创建成本反而比普通输入更贵。每次请求前缀都变的场景比如在系统提示里附带实时日期、随机ID、用户级动态配置每次调用都会重新创建缓存。以输出为主的场景比如只生成一句话分类结果输入很少输出占比高缓存降价对整体帮助有限。任务之间有大量共享外部数据但外部数据会被实时修改的场景数据一变缓存就失效收益不稳定。如果你发现自己的负载命中率一直很低不用硬套缓存优化先考虑把公共部分抽出来或者接受当前的成本结构。技术方案要匹配负载特征不能为了用缓存而用缓存。4.3 需要补的工程配套日志、监控、成本预算缓存降价不是改一个参数就结束。要把这个机制变成长期稳定的优势至少需要三块工程配套。第一日志。记录每一次调用的cache_creation、cache_read、normal_input和output token以及命中率。没有日志你永远不知道缓存是否生效、失效的原因是什么。第二监控。在监控面板上放一个“缓存命中率”指标。如果某天该指标突然下跌说明你的前缀模板被意外改动、SDK升级、或TTL过期策略调整。及时的监控可以避免账单悄悄回升。第三成本预算。给每个智能体会话、每个用户或每个项目设置Token用量阈值。缓存降价后成本下降但如果你用量也成倍上涨总账单仍然可能更高。成本工程的目标是让单位有用结果的花费下降而不是压制总支出。5. 从一次降价看智能体落地的成本工程5.1 成本问题不是降价能单独解决的缓存读取降价75%听起来像是一次红利但把成本压力完全寄托在一次降价上是一种危险的偷懒。智能体落地的成本问题从来不只是API单价问题。它还包括架构合理性、任务规划效率、工具调用次数、失败后重试策略、人类审核成本、异常处理成本。一个大概率会发生的事当你发现缓存便宜了你会更放心地给模型塞更多上下文或者让智能体多尝试几个工具。如果收益上涨这是好事如果只是增加无意义的调用总成本还是会上升。所以降价应该被当成优化空间而不是停止思考的理由。我见过不少团队第一版智能体演示很惊艳一到生产就发现成本失控。根本原因不是单价贵而是任务设计让模型做了大量低价值重复操作。缓存降价能缓解一部分重复输入开销但不会帮你优化工具调用链也不会帮你决定什么时候该停止。这些还是人的工作。5.2 一个可复用的成本优化框架从单次、会话到系统我把智能体负载的成本优化分成三个层面你可以在实际项目中按顺序使用。第一层单次请求层面。优化输入内容去掉冗余的上文把动态信息后置确认缓存机制生效。这一层的目标是降低单次调用的Token消耗。第二层会话层面。设计好上下文的生命周期明确哪些内容该长期缓存、哪些该淘汰。控制历史消息长度、工具结果的保留策略、中间推理的压缩方式。这一层的目标是提高整个会话内多次调用的综合命中率。第三层系统层面。从业务目标出发减少不必要的模型调用。比如判断任务是否一定需要大模型完成。尽量复用可结构化查询的结果不必每次重算。对工具调用设置最大轮数和超时。失败重试前先确认是输入问题还是工具问题别盲目重发。对低价值输出使用更小的模型或更短的回复。缓存降价属于第一层和第三层之间的桥梁它让单次请求结构更合理也让系统愿意保留更多公共知识。但你要记住真正的成本优化是把模型调用当作整个流程中的一个环节来管理而不是孤立地追逐某个优惠。5.3 下一步最该做什么如果你正在开发智能体应用而且还没有做过成本审计那么现在最合适做的事情不是急着改代码而是先画一张成本地图。把一次完整任务拆开记录调用了多少次模型每次调用的输入Token、输出Token各是多少其中重复携带的上下文有多少缓存命中了多少命中率是多少哪些调用是可以合并、跳过或改用规则的如果用上Fable 5.1的缓存读取优惠预计能省多少画完这张地图你会看到成本黑洞到底在哪儿。然后针对占比最大的那一块用我们前面讲的缓存前缀设计、会话生命周期和批量摊销去修。这个流程可以反复使用每次版本迭代后重新审计成本工程才会成为可持续的能力。最后说回标题里的那个判断缓存读取降价75%让智能体负载整体成本下降约45%。这个数字很有吸引力但它真正的价值不是“省了多少钱”而是它让一种新的产品设计变得可能你可以构建拥有丰富系统提示、长期记忆、大量工具定义和多轮协作的智能体而不再被重复Token的费用吓住。对做智能体的人来说这才是这个变化最值得关注的地方。不必急着压榨每一分钱。先把一次任务跑通再看缓存命中率最后才谈规模化。然后你会发现成本下降不一定是“扣出来的”也可能是“算清楚之后结构优化出来的”。
缓存读取降价75%：智能体负载成本下降45%的底层逻辑
第一次和智能体打交道的人通常会被一个现象吓到。同样的问题直接问模型一次只要几毛钱塞给智能体跑一轮任务账单可能翻几倍甚至几十倍。不是模型偷偷加价而是智能体每次调用都要把系统提示、工具定义、历史对话、中间结果全部重新送一遍。这就像每次开会都要求所有人从头读一遍合同全文而真正新增的内容只有一行。所以我看到“缓存读取降价75%”这种消息时第一反应不是“输入便宜了”而是“智能体负载的账单逻辑终于要变天了”。如果缓存读取价格下降75%那意味着原本最贵的那部分重复上下文变成了几乎廉价的公共资源。按标题测算它能推动智能体负载整体成本下降约45%。这个数字听起来很诱人但真正值得研究的不是数字本身而是它背后的成本结构变化以及你该怎么利用这个变化把应用从“演示级”推进到“可长期运行级”。注意我这里的分析基于标题给出的场景假设Claude Fable 5.1 将缓存读取价格下调75%。具体的API定价、缓存策略、计费方式可能随版本和地区调整。落地前你需要以官方文档和实际账单为准。但这不影响我们拆解“为什么缓存降价对智能体影响这么大”这个本质问题。1. 先看明白智能体负载的账单到底贵在哪里1.1 智能体请求不是一次问答而是一串“带着全量记忆”的调用先搞清楚我们说的“成本”是什么。普通的文本生成你输入一段Prompt模型返回一段回答账单就是这一次模型的输入Token和输出Token。但智能体不是这样。它通常要执行一个循环接收用户任务、理解、规划、调用工具、拿到工具结果、再次理解、生成下一步行动直到任务完成。每走一步都要调用一次模型。问题在于每一步调用不是只带上最新的一步。为了让模型保持连贯你必须把整个会话的上下文都带上。这个上下文包括系统提示规定智能体是什么角色、用什么风格、有哪些策略。工具定义每个工具的说明、参数、使用约束有时还有几十个工具的JSON Schema。对话历史从第一句用户问题到当前这一步的所有消息。中间结果比如工具返回的日志、代码、表格、错误信息。外部数据比如检索回来的知识、文件内容、数据库查询结果。每一次模型调用都要重新发送这些内容。任务越长上下文越大调用次数越多账单就呈叠加式增长。这不是线性增长而是接近几何级数每多一步不仅要为新输出付费还要为前面所有步骤的重复输入再付一次费。1.2 重复上下文才是成本大头你可能会想上下文就算重复发送一次也没多少吧但如果你把一个真实的智能体请求抓下来看会发现输入Token中真正“新增”的部分往往只占很小比例。假设一个客服智能体系统提示500 Token工具定义2000 Token历史对话3000 Token每轮用户输入和工具结果大概500 Token。那么下一次调用时5000 Token是重复的只有500 Token是新的。比例是10:1。在小规模测试中10倍重复还不太心疼。但一旦放到生产环境每天几万次调用重复Token的消耗就变成成本主体。而且上下文还会累积多轮对话里历史消息越来越长工具调用链里中间结果越来越多多智能体协作场景里每个智能体都要共享全局上下文。重复上下文在总费用中的占比可以轻松超过80%。所以很多团队做智能体第一版Demo跑得飞快一到内测就发现API账单飞速上涨。不是模型贵是架构让模型不得不反复“重读”同样的内容。这也解释了为什么缓存读取降价75%能成为智能体成本优化的关键事件。1.3 缓存读取降价75%意味着什么如果按标题场景理解缓存读取价格下降75%就相当于原本每1万Token重复输入的单价降到了原来的四分之一。注意这里不是免单而是把最贵的“反复全价重发”变成“低价命中缓存”。从成本结构看如果一个智能体请求中80%的Token是重复上下文而这部分重复上下文以缓存读取方式计费价格又降到原来的25%那么这部分费用就变成原来的四分之一。整体成本就能明显下降。标题里给出整体压45%说明不是所有请求都能命中缓存、也不是所有Token都能走缓存读取但这依然是一个幅度很大的结构优化。更重要的一点是降价之后缓存读取的经济账在工程上会被重新算。以前你会刻意控制上下文长度、减少历史消息、压缩工具定义甚至牺牲一部分智能体能力来省成本。现在缓存读取便宜了你可以更大胆地往上下文里放系统知识、工具示例、长期记忆而不必担心成本爆炸。这才是这次降价真正改变的地方。2. 缓存读取降价的杠杆作用不只是省一次费用2.1 从单次省钱到整体成本压低的传导逻辑很多人会把“缓存读取降价75%”理解为“我的API账单少25%”或“少75%”这都不准确。它真正的作用是降低每一轮重复上下文的边际成本进而从三个层面传导到整体成本。第一多轮对话场景中单次调用的输入费用下降。因为每轮调用都有大量重复上下文降价后这部分从全价变为折价。第二工具调用频繁的智能体每次工具返回后模型都要再次读取完整上下文这个读取次数很多降价后的累计效益更明显。第三长任务场景中上下文可能超过缓存窗口但合理设计后大部分前缀仍能命中成本也能持续压低。所以整体45%是一个综合结果。它包含缓存命中率、Token分布、任务类型、上下文长度等因素。不要指望所有请求都缓存也不要认为便宜了就能乱用。理解这个传导逻辑你才能正确预估自己的节省幅度。2.2 为什么整体能压45%而不是75%如果缓存读取降价75%为什么整体不是降低75%原因很简单缓存读取不是所有成本。智能体负载的成本至少包括四块正常输入Token首次发送或未命中缓存的前缀Token按标准输入价格计费。缓存读取Token命中了缓存前缀的那部分Token按降价后的缓存读取价格计费。输出Token模型的生成结果通常比输入价格更贵不受缓存降价影响。其他成本比如工具调用次数、外部API费用、基础设施成本、调度开销等也不在缓存降价范围内。假设一个请求里重复上下文占总输入Token的80%而缓存完全命中那么输入费用降幅大约是80% × (1-25%) 60%。但输出Token仍占很大比例。如果输出Token占了总费用的50%那么整体降幅就变成30%左右。再加上一些请求未命中、有些前缀无法缓存最终落到45%是合理的量级。反过来说如果你的应用是输出密集型缓存降价带来的整体节省会更小。这说明一个关键判断缓存降价的最大受益者是“输入密集、重复上下文占比高”的负载而不是所有负载。智能体正好符合这个特征所以标题场景才有意义。2.3 成本结构变了使用方式也要变价格下降不是让你躺平而是改变了优化的优先级。以前你用尽全力压缩提示词、减少历史消息、给工具定义瘦身现在你可以重新权衡。比如以前为了控制Token你可能故意不把某个详细的工具使用示例放进系统提示而是让模型靠名字猜测。现在缓存便宜了你可以在系统提示里放更完整的示例、更长的背景文档、更明确的约束条件让模型更稳定地完成任务。因为这份“长提示”一旦缓存每次读取都便宜整体效果反而更好。这意味着成本优化从“尽量少写”变成“把该写的一次写够然后让缓存承担重复读取”。不是鼓励堆Token而是把一次性构建成本变成摊销成本。3. 真正用好缓存降价要从工作流和代码层面配合3.1 先确认你的调用链支持prompt caching别急着高兴先检查你的SDK、API版本和调用方式是否支持缓存读取。大多数大模型API都提供Prompt Caching能力但不同平台有不同规则有的需要显式开启缓存参数有的会自动缓存前缀有的只支持特定模型版本有的要求缓存内容不少于某个最小Token数。以常见实现为例缓存的最小长度通常在1024或4096 Token以上太短的前缀不会触发缓存。另外缓存有TTL比如5分钟、1小时超过时间会失效。如果你的智能体每次调用间隔超过TTL就需要重新支付正常输入价格再重新建立缓存。因此设计调用间隔和会话粘性很重要。一个稳妥的验证方法是先写一个最小脚本用同一段前缀连续调用两次看账单或日志中第二次调用的输入价格是否变为缓存读取价格。如果API返回里包含cache creation和cache read的usage字段就能明确判断。这一步不确认好后面做的所有优化都是空中楼阁。3.2 设计稳定的前缀系统提示、工具定义、长期记忆放前面缓存命中的前提是前缀完全一致。Token序列按前缀匹配只要前缀中有任何字符变化缓存就从变化点之后失效。所以你要把“几乎不变”的内容放在最前面把“经常变化”的内容放在后面。推荐的结构系统提示版本固定 工具定义JSON Schema 核心知识库指令不变 长期记忆历史窗口如固定格式 当前任务描述可变 最近对话轮次按时间顺序 工具返回结果最新以Claude Code这类编码智能体为例它的系统提示、工具列表、工作流说明通常很长且固定每个请求都重复。如果这些内容排在前面缓存命中率会非常高。而每次用户提问、代码差异、文件内容等动态信息排在后面就不会破坏缓存。要养成一个习惯任何需要长期复用的内容都尽量写成稳定模板。哪怕是日期、版本号也尽量放到后面或单独字段。否则这些看起来很小的变化会让缓存全部失效前功尽弃。3.3 确认缓存命中和失效的策略使用缓存读取不是“我加了缓存前缀就一定能省钱”。你需要在代码里记录和评估命中情况。常见的做法是在响应里读取cache_read_input_tokens和cache_creation_input_tokens字段。把这两个值计入日志和监控面板。计算命中率cache_read_tokens / (cache_read_tokens cache_creation_tokens normal_input_tokens)。对命中率低的请求分析前缀稳定性。如果命中率低多半是前缀经常变动。比如系统提示里放了动态时间或随机ID或者使用了错误的上下文拼接顺序。修复方法就是把变动内容移到后面或者把动态内容提炼出来单独作为消息。另外要注意缓存内容安全。当你更新了系统提示或工具定义时要主动让缓存重新生成。有些SDK提供cache_control参数用来标记哪些内容需要缓存。没有标记时只有自动缓存的规则生效。正确标记能减少缓存空间的浪费。3.4 结合批量任务的成本估算理解了缓存机制后对你的智能体负载做一次成本估算会让优化更有依据。你可以按这个公式粗算单次调用成本 正常输入Token × 正常输入单价 缓存创建Token × 缓存创建单价 缓存读取Token × 缓存读取单价 输出Token × 输出单价注意缓存创建的价格通常高于正常输入因为后台需要记录并存储。在实际操作中第一次调用不省钱甚至会略贵。但从第二次开始如果前缀命中就按缓存读取计价。所以成本优化的目标是让同一个前缀在TTL内被多次读取读取次数越多摊销效果越好。批量任务是最能体现这个优势的场景。比如你要用智能体处理1000份文档系统提示和工具定义保持不变每次任务只是替换输入文档内容。只要保持前缀一致每一份文档的模型调用都能命中缓存。以前1000份文档要重复支付1000次系统提示费用现在几乎只付一次创建费用加999次读取费用。这就是缓存降价带来的规模效应。4. 适合谁、不适合谁缓存降价的适用边界4.1 适合多轮对话、工具调用、长上下文分析、代码生成助手先看最适合的场景。多轮对话助手每一轮都要携带完整历史缓存降价可以显著降低单用户会话的持续成本。工具调用智能体每次工具调用前后都要重新发送系统提示和工具定义。这类负载的重复率极高是缓存降价的最大受益者。长上下文分析比如分析整份代码库、长篇文档、审计报告。如果多次提问同一个文档缓存可以把“文档内容”变成廉价资源。代码生成与代码编辑工具Claude Code这类工具中系统提示、工具规则、工作区说明都是固定前缀。实际使用中一个会话可能产生几十次模型调用缓存优势非常明显。多智能体协作框架Agent A、Agent B共享的全局指令和工具协议如果能设计成稳定前缀也能获得成本优势。这些场景的共同点是同一个上下文被反复读取动态内容占比较低。4.2 不适合一次性短查询、随机性太强的任务、频繁变化的前缀缓存降价不是万能药。有些场景应用它意义不大甚至可能增加成本。一次性短查询前缀长度不足最小缓存阈值或只调用一次就结束缓存创建成本反而比普通输入更贵。每次请求前缀都变的场景比如在系统提示里附带实时日期、随机ID、用户级动态配置每次调用都会重新创建缓存。以输出为主的场景比如只生成一句话分类结果输入很少输出占比高缓存降价对整体帮助有限。任务之间有大量共享外部数据但外部数据会被实时修改的场景数据一变缓存就失效收益不稳定。如果你发现自己的负载命中率一直很低不用硬套缓存优化先考虑把公共部分抽出来或者接受当前的成本结构。技术方案要匹配负载特征不能为了用缓存而用缓存。4.3 需要补的工程配套日志、监控、成本预算缓存降价不是改一个参数就结束。要把这个机制变成长期稳定的优势至少需要三块工程配套。第一日志。记录每一次调用的cache_creation、cache_read、normal_input和output token以及命中率。没有日志你永远不知道缓存是否生效、失效的原因是什么。第二监控。在监控面板上放一个“缓存命中率”指标。如果某天该指标突然下跌说明你的前缀模板被意外改动、SDK升级、或TTL过期策略调整。及时的监控可以避免账单悄悄回升。第三成本预算。给每个智能体会话、每个用户或每个项目设置Token用量阈值。缓存降价后成本下降但如果你用量也成倍上涨总账单仍然可能更高。成本工程的目标是让单位有用结果的花费下降而不是压制总支出。5. 从一次降价看智能体落地的成本工程5.1 成本问题不是降价能单独解决的缓存读取降价75%听起来像是一次红利但把成本压力完全寄托在一次降价上是一种危险的偷懒。智能体落地的成本问题从来不只是API单价问题。它还包括架构合理性、任务规划效率、工具调用次数、失败后重试策略、人类审核成本、异常处理成本。一个大概率会发生的事当你发现缓存便宜了你会更放心地给模型塞更多上下文或者让智能体多尝试几个工具。如果收益上涨这是好事如果只是增加无意义的调用总成本还是会上升。所以降价应该被当成优化空间而不是停止思考的理由。我见过不少团队第一版智能体演示很惊艳一到生产就发现成本失控。根本原因不是单价贵而是任务设计让模型做了大量低价值重复操作。缓存降价能缓解一部分重复输入开销但不会帮你优化工具调用链也不会帮你决定什么时候该停止。这些还是人的工作。5.2 一个可复用的成本优化框架从单次、会话到系统我把智能体负载的成本优化分成三个层面你可以在实际项目中按顺序使用。第一层单次请求层面。优化输入内容去掉冗余的上文把动态信息后置确认缓存机制生效。这一层的目标是降低单次调用的Token消耗。第二层会话层面。设计好上下文的生命周期明确哪些内容该长期缓存、哪些该淘汰。控制历史消息长度、工具结果的保留策略、中间推理的压缩方式。这一层的目标是提高整个会话内多次调用的综合命中率。第三层系统层面。从业务目标出发减少不必要的模型调用。比如判断任务是否一定需要大模型完成。尽量复用可结构化查询的结果不必每次重算。对工具调用设置最大轮数和超时。失败重试前先确认是输入问题还是工具问题别盲目重发。对低价值输出使用更小的模型或更短的回复。缓存降价属于第一层和第三层之间的桥梁它让单次请求结构更合理也让系统愿意保留更多公共知识。但你要记住真正的成本优化是把模型调用当作整个流程中的一个环节来管理而不是孤立地追逐某个优惠。5.3 下一步最该做什么如果你正在开发智能体应用而且还没有做过成本审计那么现在最合适做的事情不是急着改代码而是先画一张成本地图。把一次完整任务拆开记录调用了多少次模型每次调用的输入Token、输出Token各是多少其中重复携带的上下文有多少缓存命中了多少命中率是多少哪些调用是可以合并、跳过或改用规则的如果用上Fable 5.1的缓存读取优惠预计能省多少画完这张地图你会看到成本黑洞到底在哪儿。然后针对占比最大的那一块用我们前面讲的缓存前缀设计、会话生命周期和批量摊销去修。这个流程可以反复使用每次版本迭代后重新审计成本工程才会成为可持续的能力。最后说回标题里的那个判断缓存读取降价75%让智能体负载整体成本下降约45%。这个数字很有吸引力但它真正的价值不是“省了多少钱”而是它让一种新的产品设计变得可能你可以构建拥有丰富系统提示、长期记忆、大量工具定义和多轮协作的智能体而不再被重复Token的费用吓住。对做智能体的人来说这才是这个变化最值得关注的地方。不必急着压榨每一分钱。先把一次任务跑通再看缓存命中率最后才谈规模化。然后你会发现成本下降不一定是“扣出来的”也可能是“算清楚之后结构优化出来的”。