之前在做智能体类应用时最头疼的往往不是功能逻辑而是 Prompt 越来越长之后每次调用的 token 费用肉眼可见地上涨。尤其当系统提示词动辄几千 token、工具定义一大堆、多轮对话还要反复传递历史上下文时账单数字几乎和产品迭代速度成正比。最近关注到 Rohan Paul 对 Claude Fable 5.1 缓存读取降价 75% 的分析里面提到智能体负载的整体成本能压低约 45%这个数字对做 AI 应用的同学来说相当有吸引力。本文结合缓存读取的原理、智能体负载的特征以及成本测算方式完整拆解这次降价的降本逻辑并给出实际可落地的缓存配置思路和注意事项。1. 背景与核心概念1.1 为什么智能体应用的成本普遍偏高先从一个最常见的现象说起。假设你正在做一个客服机器人或者一个能调用多个工具的 AI 助手这类应用通常被称为智能体Agent应用。它们的典型特征是系统提示词很长往往包含角色设定、回复格式、情绪风格等大量固定文本。工具定义Function Calling / Tool Use经常占据大量 token例如天气查询、订单查询、数据库操作等工具描述。多轮对话需要携带完整历史上下文以便模型理解当前会话状态。每次执行任务可能涉及多轮模型调用例如先规划、再调用工具、最后汇总回答。在这些特征叠加之下一次完整任务消耗的 token 数量相当可观而其中很大一部分是重复读取的固定内容比如系统提示词、工具定义、以及前几轮已经生成过的历史消息。如果每次调用都要为这些重复内容重新计费成本自然居高不下。1.2 缓存读取的基本思路缓存读取Cache Read并不是一个新概念。它的核心思路是当模型在同一会话或一段时间内重复接收到相同的前缀文本时服务端可以复用已经计算过的处理结果而不是从头开始重新处理一遍。在大模型 API 的计费模型中通常有三类费用缓存写入Cache Write首次写入缓存时价格一般比普通输入略高。缓存读取Cache Read后续命中缓存时读取价格明显降低。普通输入Base Input未启用缓存时每次输入都按标准输入价格计费。Claude Fable 5.1 缓存读取降价 75%意味着命中缓存后的输入成本大幅下降。对于智能体这类“固定前缀 动态后缀”的负载来说缓存命中率往往很高因此整体成本降幅远比表面数字更可观。1.3 为什么降价 75% 能撬动 45% 的整体成本降幅这里需要强调一个关键认知缓存读取价格降低 75% 不代表总成本下降 75%因为不是所有 token 都能命中缓存缓存写入也需要额外成本而且缓存还有有效期限制。真正让整体成本下降约 45% 的原因主要来自智能体负载的结构特征。如果一个请求中 80% 的内容都是固定前缀系统提示词、工具定义、历史上下文那么这部分内容从“普通输入价”变成“缓存读取价”单价直接大幅下降而动态部分用户最新消息、工具返回结果等只占很小比例。于是整体价格被拉低。下面我们来做一个简化的数学推演帮助理解这个比例关系。假设一次请求总输入 token 为 10,000。其中固定前缀为 8,000 token动态输入为 2,000 token。普通输入价格为 P。缓存写入价格为 1.25P常见定价高于普通输入。缓存读取价格原本为 0.5P降价 75% 后变为 0.125P。未启用缓存时一次输入成本为10,000 × P 10,000P启用缓存后首次请求8,000 × 1.25P 2,000 × P 10,000P 2,000P 12,000P首次请求反而更贵了因为要支付缓存写入的额外成本。但后续请求缓存已建立只读缓存8,000 × 0.125P 2,000 × P 1,000P 2,000P 3,000P与未启用缓存的 10,000P 相比成本下降了 70%。如果整个会话中有一次首次请求、九次缓存读取请求那么总成本为12,000P 9 × 3,000P 39,000P而未启用缓存时十次请求的总成本为10 × 10,000P 100,000P成本降幅为(100,000P - 39,000P) / 100,000P 61%当然这个比例取决于固定前缀的占比、缓存命中率、请求次数等。Rohan Paul 给出的约 45% 整体成本降幅是在更保守、更接近真实智能体负载的假设下得出的结论但它足以说明缓存读取降价对智能体应用具有极其明显的降本效果。2. 环境准备与版本说明2.1 适用前提在进一步阅读本文的实战配置之前你需要明确一个前提当前大模型 API 的缓存功能通常有版本和模型维度限制不同模型的缓存策略、定价、有效期都可能不同。Claude Fable 5.1 的缓存读取降价 75%属于模型服务端的定价调整用户侧不需要改动原有业务逻辑只需要在 API 调用中显式声明缓存控制参数。2.2 技术环境建议以下环境是本文示例所用的配置思路你可以根据自己的项目实际情况调整操作系统Windows / macOS / Linux 均可无特殊要求。编程语言Python 3.9本文示例使用 Python。依赖库anthropicSDK或使用 OpenAI 兼容接口时使用openaiSDK。IDEVS Code、PyCharm 均可。网络环境目标 API 服务可正常访问。示例项目结构agent-cost-demo/ ├── main.py ├── config.py ├── requirements.txt └── logs/ └── usage.log2.3 安装依赖pip install anthropic如果你的项目中已经使用了openai库并且目标模型支持 OpenAI 兼容模式则可以继续使用openai库。下面两个小节分别展示基于anthropicSDK 的配置方式以及 HTTP 直接调用时的 Header 写法。请根据自身项目版本对照使用。3. 缓存配置与原理拆解3.1 显式声明缓存控制参数大多数支持缓存的模型 API 都要求用户在请求中显式声明哪些内容需要缓存。以anthropicSDK 为例在构造消息时可以通过cache_control参数标记固定前缀from anthropic import Anthropic client Anthropic(api_keyyour-api-key) response client.messages.create( modelclaude-fable-5.1, max_tokens1024, system[ { type: text, text: 你是一个智能客服助手请用专业、友好的语气回答用户问题。, cache_control: {type: ephemeral} } ], messages[ {role: user, content: 我想查询一下订单状态} ] ) print(response.usage)在这个例子中system字段中的文本被标记为可缓存。cache_control.type设置为ephemeral表示使用临时缓存短期有效。后续请求如果 system 前缀完全一致即可命中缓存读取。3.2 HTTP 请求头中的缓存标注方式如果你不是通过 SDK 调用而是直接使用 HTTP 请求通常是在请求体的某个字段中标注缓存控制参数。具体字段名称与模型服务商有关建议查阅对应版本的技术文档。下面是一个常见示例思路并非所有服务都完全一致{ model: claude-fable-5.1, max_tokens: 1024, system: [ { type: text, text: 你是智能体拥有调用工具的权限。, cache_control: { type: ephemeral } } ], messages: [ { role: user, content: 请帮我查一下天气 } ], tools: [ { type: function, function: { name: get_weather, description: 查询天气, parameters: { type: object, properties: { city: { type: string } }, required: [city] } } } ] }实际项目中你需要根据你所使用的模型版本和服务商文档确认cache_control放在哪个层级、支持哪些取值。由于不同版本的接口存在差异建议先在测试环境中验证请求是否报错再上线使用。3.3 缓存命中的关键条件缓存不是无条件命中的。要想获得缓存读取降价的效果必须满足以下条件前缀完全一致系统提示词、工具定义、消息历史的前缀必须逐字相同任何细微改动都会导致缓存失效。例如在系统提示词末尾加一个空格都可能让缓存无法命中。缓存未过期ephemeral 缓存的默认有效期通常较短可能是 5 分钟或 1 小时具体取决于服务端策略。超过有效期后缓存被清空下一次请求需要重新写入缓存。输入顺序一致多轮对话中历史消息的顺序必须严格保持稳定不能出现插入、删除或重排。请求包含缓存控制参数如果某些请求没有声明缓存控制参数该请求本身不会读取缓存。这就意味着在做智能体应用时我们需要把系统提示词、工具定义、固定上下文等设计成稳定前缀避免频繁变动才能最大化缓存命中率。3.4 缓存写入与缓存读取的区别在计费上缓存写入Cache Write和缓存读取Cache Read是两套价格。缓存写入通常比普通输入略贵因为它需要服务端进行额外的索引和存储操作。而缓存读取则是实打实的打折价。所以在设计请求结构时有一个常见误区把所有能缓存的内容都塞进第一个请求。这不一定划算因为缓存写入成本更高。正确思路是将长期不变的内容系统提示词、工具定义放入缓存前缀。将每次可能变化的内容用户输入、工具返回结果放在缓存前缀之后。合理利用 TTL有效期如果两次调用间隔时间较长缓存已经过期那么重新写入的代价可能高于不启用缓存。3.5 一个完整的成本对比示例假设你的智能体一次任务包含 5 次模型调用每次调用输入 8,000 token其中 7,000 token 是固定前缀系统提示词 工具定义 历史摘要1,000 token 是动态输入当前用户消息、工具返回值。如果未启用缓存5 次请求全部按普通输入计费 总输入 token 5 × 8,000 40,000 费用 40,000 × 普通输入单价如果启用缓存第一次请求写入缓存后四次命中缓存第一次请求 7,000 × 缓存写入单价 1,000 × 普通输入单价 后四次请求 7,000 × 缓存读取单价 1,000 × 普通输入单价 总费用 第一次费用 4 × 后续费用假设普通输入单价为 3 美元 / 百万 token缓存写入单价为 3.75 美元 / 百万 token降价前缓存读取单价为 1.5 美元 / 百万 token降价后缓存读取单价为 0.375 美元 / 百万 token未启用缓存40,000 / 1,000,000 × 3 0.12 美元启用缓存且降价后第一次7,000/1,000,000 × 3.75 1,000/1,000,000 × 3 0.02625 0.003 0.02925 美元 后四次4 × (7,000/1,000,000 × 0.375 1,000/1,000,000 × 3) 4 × (0.002625 0.003) 4 × 0.005625 0.0225 美元 总计0.02925 0.0225 0.05175 美元成本降幅(0.12 - 0.05175) / 0.12 56.875%这个比例高于 45%原因在于我们的假设中固定前缀占比很高、命中率也很高。实际项目中如果固定前缀占比下降到 50%动态输入占比上升降幅会接近 45% 甚至更低这也和 Rohan Paul 的分析结论吻合缓存降价对长前缀、高命中率的智能体负载效果最明显。4. 实战案例构建一个支持缓存读取的智能体成本优化示例下面我们通过一个完整可运行的 Python 示例演示如何在实际智能体代码中集成缓存控制并输出每次请求的 usage 信息方便你观察缓存命中后的 token 成本和费用变化。4.1 创建项目结构先建立项目目录和文件mkdir agent-cost-demo cd agent-cost-demo touch main.py config.py requirements.txt mkdir -p logs4.2 编写配置文件config.py用于集中管理模型名称和 API Key# 文件路径config.py import os API_KEY os.getenv(ANTHROPIC_API_KEY, your-api-key) MODEL_NAME claude-fable-5.1 MAX_TOKENS 1024这里建议通过环境变量传入 API Key避免把密钥硬编码在代码中。4.3 编写核心代码在main.py中实现一个简单的多轮对话函数每一轮都携带相同的系统提示词和工具定义并启用缓存控制# 文件路径main.py import time from anthropic import Anthropic from config import API_KEY, MODEL_NAME, MAX_TOKENS client Anthropic(api_keyAPI_KEY) SYSTEM_PROMPT ( 你是一个智能客服助手负责回答用户关于订单、物流、售后的相关问题。 请始终保持语气友好、简洁、专业。当用户询问不相关问题时请礼貌引导回主题。 ) TOOLS [ { type: function, function: { name: query_order, description: 查询订单状态, parameters: { type: object, properties: { order_id: {type: string} }, required: [order_id] } } } ] def chat_with_cache(user_message: str, history: list) - str: 发送一次带缓存控制的消息。 history 为已经结束的对话消息列表格式为 [{role: user/assistant, content: ...}] messages history [{role: user, content: user_message}] response client.messages.create( modelMODEL_NAME, max_tokensMAX_TOKENS, system[ { type: text, text: SYSTEM_PROMPT, cache_control: {type: ephemeral} } ], toolsTOOLS, messagesmessages ) usage response.usage print( 本次使用情况 ) print(f输入 tokens: {usage.input_tokens}) print(f输出 tokens: {usage.output_tokens}) if hasattr(usage, cache_creation_input_tokens): print(f缓存写入 tokens: {usage.cache_creation_input_tokens}) if hasattr(usage, cache_read_input_tokens): print(f缓存读取 tokens: {usage.cache_read_input_tokens}) return response.content[0].text def main(): history [] # 第一轮用户询问订单 reply1 chat_with_cache(我想查询订单 123456 的状态, history) print(f助手回复{reply1}) history.append({role: user, content: 我想查询订单 123456 的状态}) history.append({role: assistant, content: reply1}) time.sleep(2) # 第二轮继续追问物流 reply2 chat_with_cache(订单 123456 现在到哪了, history) print(f助手回复{reply2}) history.append({role: user, content: 订单 123456 现在到哪了}) history.append({role: assistant, content: reply2}) time.sleep(2) # 第三轮追问售后 reply3 chat_with_cache(我想申请退款怎么操作, history) print(f助手回复{reply3}) if __name__ __main__: main()这段代码做的事情如下将固定的SYSTEM_PROMPT设置为可缓存内容。每一轮对话都携带完整历史记录因此固定前缀在各轮之间保持一致理论上后几轮可以命中缓存读取。打印usage中的缓存写入和缓存读取 token 数方便你核对是否真正命中了缓存。4.4 运行与验证设置环境变量并运行export ANTHROPIC_API_KEYsk-xxxx python main.py预期输出中第一轮可能会看到cache_creation_input_tokens大于 0表示写入缓存后续轮次可能会看到cache_read_input_tokens大于 0表示命中了缓存读取。如果所有轮次都没有缓存相关字段说明当前模型版本或接口配置不支持缓存或者缓存已过期。4.5 结果说明需要说明的是不同服务商对usage字段的命名可能不同。例如input_tokens普通输入 token 数。cache_creation_input_tokens缓存写入 token 数。cache_read_input_tokens缓存读取 token 数。在计费时这三个字段分别按对应单价计算。通过观察这些数值你可以判断自己的智能体应用是否真正从缓存读取降价中获益。另外如果你使用的是 OpenAI 兼容接口缓存控制参数名称可能会变成cache或其他形式请以对应 API 文档为准。5. 智能体负载中的缓存适配策略缓存读取降价 75% 是一个通用利好但在智能体场景中如何合理设计请求结构来充分利用缓存仍然有一些工程技巧。5.1 固定系统提示词与动态指令分离不少团队习惯在系统提示词中既写角色设定又拼接当前任务相关的临时指令。这会导致系统提示词频繁变化缓存命中率大幅下降。更好的做法是将角色设定、回复风格、通用规则等长期不变的内容固定为global_prefix。将临时任务指令放在用户消息的开头或者单独字段中。保持global_prefix字符串逐字稳定不掺入时间戳、用户 ID、随机数等动态信息。5.2 工具定义的静态化智能体通常需要定义多个工具。工具定义本身是一段较长的 JSON 文本非常适合作为缓存前缀。但很多团队在每次请求时动态生成工具定义例如根据用户当前意图只传入部分工具或者动态修改工具描述这会破坏前缀一致性。建议做法是将工具定义整理为静态 JSON 文件每次请求加载同一个对象。如果需要动态禁用某些工具可以不走“删除工具定义”的方式而是在系统提示词中说明“本次任务只允许使用以下工具xxx”仍然保留完整工具列表作为缓存前缀避免破坏前缀。如果确实需要动态增减工具建议将工具列表按固定顺序拼接新增工具只追加到末尾减少前缀变动范围。5.3 多轮对话历史的前缀管理多轮对话中历史消息越长固定前缀占比越高缓存收益越明显。但历史消息会不断增长如果每次都把完整历史放入输入最终会超过模型上下文限制。这里有一个平衡问题既要保持前缀稳定以利用缓存又要控制上下文长度。常见的策略是使用滚动窗口只保留最近 N 轮对话但要注意前缀截断会导致缓存失效。使用历史摘要将早期对话压缩成一段摘要将摘要插入到历史消息最前面。只要摘要不变后续消息可以继续命中缓存。合理设置 TTL如果任务时间跨度较长缓存可能在任务中途过期需要考虑将长时间任务拆分为多个短会话。5.4 合理设置缓存过期时间Claude 的ephemeral缓存属于短期缓存通常适用于对话间隔较短的场景。如果你的智能体负载是异步批量任务可能每次请求间隔数分钟甚至更久缓存命中率会下降这时需要重新评估缓存收益。在实际项目中可以这样设计在线客服场景用户发言间隔通常在几秒到几分钟缓存命中率高非常适合启用缓存读取。离线批处理场景每个请求可能间隔不同批次缓存过期概率高可以考虑关闭缓存或仅对超长前缀启用。定时任务场景如果任务之间共享完全相同的系统提示词可以在任务开始时先发送一次预热请求写入缓存再在短时间内继续执行后续请求。6. 常见问题与排查思路6.1 缓存命中率为 0问题现象常见原因解决思路每次请求都出现cache_creation_input_tokens但几乎没有cache_read_input_tokens缓存前缀每次都在变化例如系统提示词中拼接了时间戳、随机 ID或者请求间隔时间超过 TTL检查系统提示词是否逐字一致将动态内容移到缓存前缀之后缩短请求间隔查看 TTL 是否符合预期缓存读取字段一直为 0接口版本不支持缓存或者未传cache_control参数确认模型版本支持缓存确认cache_control正确传入缓存写入和缓存读取字段同时存在但数值异常大前缀中包含过长且变化频繁的内容将稳定前缀与动态内容分离优先缓存系统提示词和工具定义以下是部分判断“缓存前缀是否变化”的辅助日志代码# 文件路径logs_check.py import hashlib import json SYSTEM_PROMPT 你是一个智能客服助手请保持友好语气。 TOOLS [ { type: function, function: { name: query_order, description: 查询订单, parameters: {type: object, properties: {}} } } ] def build_prefix_hash(): prefix json.dumps({ system: SYSTEM_PROMPT, tools: TOOLS }, ensure_asciiFalse, sort_keysTrue) return hashlib.md5(prefix.encode()).hexdigest() if __name__ __main__: print(缓存前缀指纹, build_prefix_hash())你可以把这个指纹打印到日志中对比不同请求之间是否一致。如果指纹变化说明前缀有改动。6.2 启用缓存后首轮请求反而更贵问题现象常见原因解决思路第一次请求费用比未启用缓存时高缓存写入单价高于普通输入单价首次请求需要额外支付写入成本这是正常现象。评估整体成本时需要看多次请求的累计费用而不是单次请求请求次数很少缓存收益不明显如果一次会话只有 1 到 2 次调用缓存写入成本可能高于节省的费用在请求次数较少的场景下优先缓存超长前缀如工具定义 长系统提示词短前缀不必启用缓存6.3 缓存导致回复内容异常问题现象常见原因解决思路后续请求似乎没有读取最新消息由于历史消息拼接顺序错误前缀包含的部分内容被错误截断或覆盖检查 messages 列表的构造逻辑确保每次追加消息的顺序正确系统提示词更新后回复风格没有变化缓存前缀没有更新还在使用旧的内容修改系统提示词时等待缓存过期或主动清理缓存在测试环境验证新前缀生效后再发布6.4 请求报错system 字段格式不支持 cache_control问题现象常见原因解决思路400 错误提示 cache_control 字段位置错误当前 SDK 版本过旧或模型版本不支持在 system 字段中设置缓存升级 SDK查阅当前版本 API 文档将缓存控制参数调整到 messages 字段中的首条消息报错提示 ephemeral 不是合法取值当前服务端仅支持其他缓存类型如 session 或 persistent以官方最新文档为准改用对应取值7. 最佳实践与工程建议7.1 命名与代码结构在代码层面建议将缓存相关的配置集中管理避免散落在各个业务模块中。例如可以新建一个cache_policy.py文件统一导出系统提示词、工具列表和缓存控制函数# 文件路径cache_policy.py from anthropic.types import TextBlockParam SYSTEM_PROMPT 你是一个智能客服助手支持订单查询、物流跟踪、售后处理。 TOOLS [ { type: function, function: { name: query_order, description: 查询订单状态, parameters: { type: object, properties: { order_id: {type: string} }, required: [order_id] } } }, { type: function, function: { name: track_logistics, description: 查询物流信息, parameters: { type: object, properties: { order_id: {type: string} }, required: [order_id] } } } ] def build_system_block() - list[TextBlockParam]: return [ { type: text, text: SYSTEM_PROMPT, cache_control: {type: ephemeral} } ]在业务代码中调用build_system_block()即可便于统一调整缓存策略。7.2 日志记录与成本监控不要等到月底看到账单才发现成本异常。建议在每次模型调用后记录 usage 信息并将 token 费用汇总到监控大盘。以下是一个简单示例# 文件路径usage_logger.py import json import time def log_usage(usage: dict, log_path: str logs/usage.log): log_entry { timestamp: time.time(), input_tokens: usage.get(input_tokens, 0), cache_creation_input_tokens: usage.get(cache_creation_input_tokens, 0), cache_read_input_tokens: usage.get(cache_read_input_tokens, 0), output_tokens: usage.get(output_tokens, 0), } with open(log_path, a, encodingutf-8) as f: f.write(json.dumps(log_entry, ensure_asciiFalse) \n)在每次调用结束后调用log_usage(usage)后续可以通过收集这些日志来统计缓存命中率、平均成本等指标。建议至少统计两个核心指标缓存读取 token 占总输入 token 的比例。平均每次请求的实际费用。7.3 最小权限与安全边界在使用 API Key 时务必遵循最小权限原则不要在代码仓库中明文提交 API Key使用环境变量或密钥管理服务。为不同环境配置不同的 Key例如测试环境与生产环境隔离。如果 API Key 泄露立即吊销并更换。在日志中不要打印完整的请求内容和响应内容尤其包含用户个人信息时需要进行脱敏处理。7.4 缓存策略的动态开关在生产环境中建议提供缓存策略的动态开关便于在出现问题时快速回退。例如可以在配置中心新增一个标志位cache.enabledtrue代码中判断该标志位决定是否在请求中附加cache_control参数。这样即使缓存功能出现问题也可以通过配置快速关闭而不需要重新发布版本。7.5 性能与成本的平衡缓存读取降价 75% 之后单次调用的成本确实下降了但智能体应用的整体成本还与以下因素相关任务拆分的粒度如果每次任务被拆成过多次模型调用总 token 数会上升。Prompt 设计的精简程度即使缓存读取便宜了缓存写入和动态输入仍然按较高价格计费所以 Prompt 仍然需要控制长度。工具调用的复杂度工具返回结果往往较长这部分内容无法缓存需要关注动态输入的增长。因此最理想的做法是把缓存降价的收益与 Prompt 工程优化叠加使用而不是因为缓存便宜了就在 Prompt 中堆砌无用信息。7.6 灰度发布与效果评估建议先在小范围流量中启用缓存策略对比开启前后的成本数据。具体步骤如下选择一类负载特征稳定的接口例如客服机器人或知识库问答。在测试环境验证缓存控制参数生效。取 10% 生产流量开启缓存观察日志中的缓存读取占比。对比启用缓存前后的费用和延迟。确认无异常后逐步扩大到全量流量。缓存读取降价 75% 是一个很好的契机但只有通过数据验证才能确认你的智能体负载到底能从缓存中节省多少成本。8. 总结与后续学习建议通过本文的分析和示例你应该已经理解了几个关键点智能体负载成本偏高的根源在于大量重复的固定前缀例如系统提示词、工具定义和历史上下文。缓存读取降价 75% 后长前缀、高命中率的智能体场景可以把整体成本压低约 45%但前提是要保证前缀稳定性、控制缓存写入成本、理解缓存有效期。在代码层面通过cache_control参数标记可缓存内容即可改动成本很低关键是合理的请求结构设计。接下来可以继续深入的方向包括研究不同会话策略下缓存命中率的差异例如短会话 vs 长会话。结合函数回调、多 Agent 协作等复杂智能体场景做更细粒度的成本拆解。熟悉日志监控和账单分析建立常态化的成本巡检机制。如果你的智能体应用目前还没有启用缓存建议先在测试环境按本文的示例跑一遍观察 usage 中的缓存写入和缓存读取字段再结合自己的请求量级测算成本和收益。毕竟 45% 的成本降幅对于规模化运行的 AI 应用来说是一笔相当可观的优化空间。 缓存读取降价75%：智能体应用如何实现成本直降45%
之前在做智能体类应用时最头疼的往往不是功能逻辑而是 Prompt 越来越长之后每次调用的 token 费用肉眼可见地上涨。尤其当系统提示词动辄几千 token、工具定义一大堆、多轮对话还要反复传递历史上下文时账单数字几乎和产品迭代速度成正比。最近关注到 Rohan Paul 对 Claude Fable 5.1 缓存读取降价 75% 的分析里面提到智能体负载的整体成本能压低约 45%这个数字对做 AI 应用的同学来说相当有吸引力。本文结合缓存读取的原理、智能体负载的特征以及成本测算方式完整拆解这次降价的降本逻辑并给出实际可落地的缓存配置思路和注意事项。1. 背景与核心概念1.1 为什么智能体应用的成本普遍偏高先从一个最常见的现象说起。假设你正在做一个客服机器人或者一个能调用多个工具的 AI 助手这类应用通常被称为智能体Agent应用。它们的典型特征是系统提示词很长往往包含角色设定、回复格式、情绪风格等大量固定文本。工具定义Function Calling / Tool Use经常占据大量 token例如天气查询、订单查询、数据库操作等工具描述。多轮对话需要携带完整历史上下文以便模型理解当前会话状态。每次执行任务可能涉及多轮模型调用例如先规划、再调用工具、最后汇总回答。在这些特征叠加之下一次完整任务消耗的 token 数量相当可观而其中很大一部分是重复读取的固定内容比如系统提示词、工具定义、以及前几轮已经生成过的历史消息。如果每次调用都要为这些重复内容重新计费成本自然居高不下。1.2 缓存读取的基本思路缓存读取Cache Read并不是一个新概念。它的核心思路是当模型在同一会话或一段时间内重复接收到相同的前缀文本时服务端可以复用已经计算过的处理结果而不是从头开始重新处理一遍。在大模型 API 的计费模型中通常有三类费用缓存写入Cache Write首次写入缓存时价格一般比普通输入略高。缓存读取Cache Read后续命中缓存时读取价格明显降低。普通输入Base Input未启用缓存时每次输入都按标准输入价格计费。Claude Fable 5.1 缓存读取降价 75%意味着命中缓存后的输入成本大幅下降。对于智能体这类“固定前缀 动态后缀”的负载来说缓存命中率往往很高因此整体成本降幅远比表面数字更可观。1.3 为什么降价 75% 能撬动 45% 的整体成本降幅这里需要强调一个关键认知缓存读取价格降低 75% 不代表总成本下降 75%因为不是所有 token 都能命中缓存缓存写入也需要额外成本而且缓存还有有效期限制。真正让整体成本下降约 45% 的原因主要来自智能体负载的结构特征。如果一个请求中 80% 的内容都是固定前缀系统提示词、工具定义、历史上下文那么这部分内容从“普通输入价”变成“缓存读取价”单价直接大幅下降而动态部分用户最新消息、工具返回结果等只占很小比例。于是整体价格被拉低。下面我们来做一个简化的数学推演帮助理解这个比例关系。假设一次请求总输入 token 为 10,000。其中固定前缀为 8,000 token动态输入为 2,000 token。普通输入价格为 P。缓存写入价格为 1.25P常见定价高于普通输入。缓存读取价格原本为 0.5P降价 75% 后变为 0.125P。未启用缓存时一次输入成本为10,000 × P 10,000P启用缓存后首次请求8,000 × 1.25P 2,000 × P 10,000P 2,000P 12,000P首次请求反而更贵了因为要支付缓存写入的额外成本。但后续请求缓存已建立只读缓存8,000 × 0.125P 2,000 × P 1,000P 2,000P 3,000P与未启用缓存的 10,000P 相比成本下降了 70%。如果整个会话中有一次首次请求、九次缓存读取请求那么总成本为12,000P 9 × 3,000P 39,000P而未启用缓存时十次请求的总成本为10 × 10,000P 100,000P成本降幅为(100,000P - 39,000P) / 100,000P 61%当然这个比例取决于固定前缀的占比、缓存命中率、请求次数等。Rohan Paul 给出的约 45% 整体成本降幅是在更保守、更接近真实智能体负载的假设下得出的结论但它足以说明缓存读取降价对智能体应用具有极其明显的降本效果。2. 环境准备与版本说明2.1 适用前提在进一步阅读本文的实战配置之前你需要明确一个前提当前大模型 API 的缓存功能通常有版本和模型维度限制不同模型的缓存策略、定价、有效期都可能不同。Claude Fable 5.1 的缓存读取降价 75%属于模型服务端的定价调整用户侧不需要改动原有业务逻辑只需要在 API 调用中显式声明缓存控制参数。2.2 技术环境建议以下环境是本文示例所用的配置思路你可以根据自己的项目实际情况调整操作系统Windows / macOS / Linux 均可无特殊要求。编程语言Python 3.9本文示例使用 Python。依赖库anthropicSDK或使用 OpenAI 兼容接口时使用openaiSDK。IDEVS Code、PyCharm 均可。网络环境目标 API 服务可正常访问。示例项目结构agent-cost-demo/ ├── main.py ├── config.py ├── requirements.txt └── logs/ └── usage.log2.3 安装依赖pip install anthropic如果你的项目中已经使用了openai库并且目标模型支持 OpenAI 兼容模式则可以继续使用openai库。下面两个小节分别展示基于anthropicSDK 的配置方式以及 HTTP 直接调用时的 Header 写法。请根据自身项目版本对照使用。3. 缓存配置与原理拆解3.1 显式声明缓存控制参数大多数支持缓存的模型 API 都要求用户在请求中显式声明哪些内容需要缓存。以anthropicSDK 为例在构造消息时可以通过cache_control参数标记固定前缀from anthropic import Anthropic client Anthropic(api_keyyour-api-key) response client.messages.create( modelclaude-fable-5.1, max_tokens1024, system[ { type: text, text: 你是一个智能客服助手请用专业、友好的语气回答用户问题。, cache_control: {type: ephemeral} } ], messages[ {role: user, content: 我想查询一下订单状态} ] ) print(response.usage)在这个例子中system字段中的文本被标记为可缓存。cache_control.type设置为ephemeral表示使用临时缓存短期有效。后续请求如果 system 前缀完全一致即可命中缓存读取。3.2 HTTP 请求头中的缓存标注方式如果你不是通过 SDK 调用而是直接使用 HTTP 请求通常是在请求体的某个字段中标注缓存控制参数。具体字段名称与模型服务商有关建议查阅对应版本的技术文档。下面是一个常见示例思路并非所有服务都完全一致{ model: claude-fable-5.1, max_tokens: 1024, system: [ { type: text, text: 你是智能体拥有调用工具的权限。, cache_control: { type: ephemeral } } ], messages: [ { role: user, content: 请帮我查一下天气 } ], tools: [ { type: function, function: { name: get_weather, description: 查询天气, parameters: { type: object, properties: { city: { type: string } }, required: [city] } } } ] }实际项目中你需要根据你所使用的模型版本和服务商文档确认cache_control放在哪个层级、支持哪些取值。由于不同版本的接口存在差异建议先在测试环境中验证请求是否报错再上线使用。3.3 缓存命中的关键条件缓存不是无条件命中的。要想获得缓存读取降价的效果必须满足以下条件前缀完全一致系统提示词、工具定义、消息历史的前缀必须逐字相同任何细微改动都会导致缓存失效。例如在系统提示词末尾加一个空格都可能让缓存无法命中。缓存未过期ephemeral 缓存的默认有效期通常较短可能是 5 分钟或 1 小时具体取决于服务端策略。超过有效期后缓存被清空下一次请求需要重新写入缓存。输入顺序一致多轮对话中历史消息的顺序必须严格保持稳定不能出现插入、删除或重排。请求包含缓存控制参数如果某些请求没有声明缓存控制参数该请求本身不会读取缓存。这就意味着在做智能体应用时我们需要把系统提示词、工具定义、固定上下文等设计成稳定前缀避免频繁变动才能最大化缓存命中率。3.4 缓存写入与缓存读取的区别在计费上缓存写入Cache Write和缓存读取Cache Read是两套价格。缓存写入通常比普通输入略贵因为它需要服务端进行额外的索引和存储操作。而缓存读取则是实打实的打折价。所以在设计请求结构时有一个常见误区把所有能缓存的内容都塞进第一个请求。这不一定划算因为缓存写入成本更高。正确思路是将长期不变的内容系统提示词、工具定义放入缓存前缀。将每次可能变化的内容用户输入、工具返回结果放在缓存前缀之后。合理利用 TTL有效期如果两次调用间隔时间较长缓存已经过期那么重新写入的代价可能高于不启用缓存。3.5 一个完整的成本对比示例假设你的智能体一次任务包含 5 次模型调用每次调用输入 8,000 token其中 7,000 token 是固定前缀系统提示词 工具定义 历史摘要1,000 token 是动态输入当前用户消息、工具返回值。如果未启用缓存5 次请求全部按普通输入计费 总输入 token 5 × 8,000 40,000 费用 40,000 × 普通输入单价如果启用缓存第一次请求写入缓存后四次命中缓存第一次请求 7,000 × 缓存写入单价 1,000 × 普通输入单价 后四次请求 7,000 × 缓存读取单价 1,000 × 普通输入单价 总费用 第一次费用 4 × 后续费用假设普通输入单价为 3 美元 / 百万 token缓存写入单价为 3.75 美元 / 百万 token降价前缓存读取单价为 1.5 美元 / 百万 token降价后缓存读取单价为 0.375 美元 / 百万 token未启用缓存40,000 / 1,000,000 × 3 0.12 美元启用缓存且降价后第一次7,000/1,000,000 × 3.75 1,000/1,000,000 × 3 0.02625 0.003 0.02925 美元 后四次4 × (7,000/1,000,000 × 0.375 1,000/1,000,000 × 3) 4 × (0.002625 0.003) 4 × 0.005625 0.0225 美元 总计0.02925 0.0225 0.05175 美元成本降幅(0.12 - 0.05175) / 0.12 56.875%这个比例高于 45%原因在于我们的假设中固定前缀占比很高、命中率也很高。实际项目中如果固定前缀占比下降到 50%动态输入占比上升降幅会接近 45% 甚至更低这也和 Rohan Paul 的分析结论吻合缓存降价对长前缀、高命中率的智能体负载效果最明显。4. 实战案例构建一个支持缓存读取的智能体成本优化示例下面我们通过一个完整可运行的 Python 示例演示如何在实际智能体代码中集成缓存控制并输出每次请求的 usage 信息方便你观察缓存命中后的 token 成本和费用变化。4.1 创建项目结构先建立项目目录和文件mkdir agent-cost-demo cd agent-cost-demo touch main.py config.py requirements.txt mkdir -p logs4.2 编写配置文件config.py用于集中管理模型名称和 API Key# 文件路径config.py import os API_KEY os.getenv(ANTHROPIC_API_KEY, your-api-key) MODEL_NAME claude-fable-5.1 MAX_TOKENS 1024这里建议通过环境变量传入 API Key避免把密钥硬编码在代码中。4.3 编写核心代码在main.py中实现一个简单的多轮对话函数每一轮都携带相同的系统提示词和工具定义并启用缓存控制# 文件路径main.py import time from anthropic import Anthropic from config import API_KEY, MODEL_NAME, MAX_TOKENS client Anthropic(api_keyAPI_KEY) SYSTEM_PROMPT ( 你是一个智能客服助手负责回答用户关于订单、物流、售后的相关问题。 请始终保持语气友好、简洁、专业。当用户询问不相关问题时请礼貌引导回主题。 ) TOOLS [ { type: function, function: { name: query_order, description: 查询订单状态, parameters: { type: object, properties: { order_id: {type: string} }, required: [order_id] } } } ] def chat_with_cache(user_message: str, history: list) - str: 发送一次带缓存控制的消息。 history 为已经结束的对话消息列表格式为 [{role: user/assistant, content: ...}] messages history [{role: user, content: user_message}] response client.messages.create( modelMODEL_NAME, max_tokensMAX_TOKENS, system[ { type: text, text: SYSTEM_PROMPT, cache_control: {type: ephemeral} } ], toolsTOOLS, messagesmessages ) usage response.usage print( 本次使用情况 ) print(f输入 tokens: {usage.input_tokens}) print(f输出 tokens: {usage.output_tokens}) if hasattr(usage, cache_creation_input_tokens): print(f缓存写入 tokens: {usage.cache_creation_input_tokens}) if hasattr(usage, cache_read_input_tokens): print(f缓存读取 tokens: {usage.cache_read_input_tokens}) return response.content[0].text def main(): history [] # 第一轮用户询问订单 reply1 chat_with_cache(我想查询订单 123456 的状态, history) print(f助手回复{reply1}) history.append({role: user, content: 我想查询订单 123456 的状态}) history.append({role: assistant, content: reply1}) time.sleep(2) # 第二轮继续追问物流 reply2 chat_with_cache(订单 123456 现在到哪了, history) print(f助手回复{reply2}) history.append({role: user, content: 订单 123456 现在到哪了}) history.append({role: assistant, content: reply2}) time.sleep(2) # 第三轮追问售后 reply3 chat_with_cache(我想申请退款怎么操作, history) print(f助手回复{reply3}) if __name__ __main__: main()这段代码做的事情如下将固定的SYSTEM_PROMPT设置为可缓存内容。每一轮对话都携带完整历史记录因此固定前缀在各轮之间保持一致理论上后几轮可以命中缓存读取。打印usage中的缓存写入和缓存读取 token 数方便你核对是否真正命中了缓存。4.4 运行与验证设置环境变量并运行export ANTHROPIC_API_KEYsk-xxxx python main.py预期输出中第一轮可能会看到cache_creation_input_tokens大于 0表示写入缓存后续轮次可能会看到cache_read_input_tokens大于 0表示命中了缓存读取。如果所有轮次都没有缓存相关字段说明当前模型版本或接口配置不支持缓存或者缓存已过期。4.5 结果说明需要说明的是不同服务商对usage字段的命名可能不同。例如input_tokens普通输入 token 数。cache_creation_input_tokens缓存写入 token 数。cache_read_input_tokens缓存读取 token 数。在计费时这三个字段分别按对应单价计算。通过观察这些数值你可以判断自己的智能体应用是否真正从缓存读取降价中获益。另外如果你使用的是 OpenAI 兼容接口缓存控制参数名称可能会变成cache或其他形式请以对应 API 文档为准。5. 智能体负载中的缓存适配策略缓存读取降价 75% 是一个通用利好但在智能体场景中如何合理设计请求结构来充分利用缓存仍然有一些工程技巧。5.1 固定系统提示词与动态指令分离不少团队习惯在系统提示词中既写角色设定又拼接当前任务相关的临时指令。这会导致系统提示词频繁变化缓存命中率大幅下降。更好的做法是将角色设定、回复风格、通用规则等长期不变的内容固定为global_prefix。将临时任务指令放在用户消息的开头或者单独字段中。保持global_prefix字符串逐字稳定不掺入时间戳、用户 ID、随机数等动态信息。5.2 工具定义的静态化智能体通常需要定义多个工具。工具定义本身是一段较长的 JSON 文本非常适合作为缓存前缀。但很多团队在每次请求时动态生成工具定义例如根据用户当前意图只传入部分工具或者动态修改工具描述这会破坏前缀一致性。建议做法是将工具定义整理为静态 JSON 文件每次请求加载同一个对象。如果需要动态禁用某些工具可以不走“删除工具定义”的方式而是在系统提示词中说明“本次任务只允许使用以下工具xxx”仍然保留完整工具列表作为缓存前缀避免破坏前缀。如果确实需要动态增减工具建议将工具列表按固定顺序拼接新增工具只追加到末尾减少前缀变动范围。5.3 多轮对话历史的前缀管理多轮对话中历史消息越长固定前缀占比越高缓存收益越明显。但历史消息会不断增长如果每次都把完整历史放入输入最终会超过模型上下文限制。这里有一个平衡问题既要保持前缀稳定以利用缓存又要控制上下文长度。常见的策略是使用滚动窗口只保留最近 N 轮对话但要注意前缀截断会导致缓存失效。使用历史摘要将早期对话压缩成一段摘要将摘要插入到历史消息最前面。只要摘要不变后续消息可以继续命中缓存。合理设置 TTL如果任务时间跨度较长缓存可能在任务中途过期需要考虑将长时间任务拆分为多个短会话。5.4 合理设置缓存过期时间Claude 的ephemeral缓存属于短期缓存通常适用于对话间隔较短的场景。如果你的智能体负载是异步批量任务可能每次请求间隔数分钟甚至更久缓存命中率会下降这时需要重新评估缓存收益。在实际项目中可以这样设计在线客服场景用户发言间隔通常在几秒到几分钟缓存命中率高非常适合启用缓存读取。离线批处理场景每个请求可能间隔不同批次缓存过期概率高可以考虑关闭缓存或仅对超长前缀启用。定时任务场景如果任务之间共享完全相同的系统提示词可以在任务开始时先发送一次预热请求写入缓存再在短时间内继续执行后续请求。6. 常见问题与排查思路6.1 缓存命中率为 0问题现象常见原因解决思路每次请求都出现cache_creation_input_tokens但几乎没有cache_read_input_tokens缓存前缀每次都在变化例如系统提示词中拼接了时间戳、随机 ID或者请求间隔时间超过 TTL检查系统提示词是否逐字一致将动态内容移到缓存前缀之后缩短请求间隔查看 TTL 是否符合预期缓存读取字段一直为 0接口版本不支持缓存或者未传cache_control参数确认模型版本支持缓存确认cache_control正确传入缓存写入和缓存读取字段同时存在但数值异常大前缀中包含过长且变化频繁的内容将稳定前缀与动态内容分离优先缓存系统提示词和工具定义以下是部分判断“缓存前缀是否变化”的辅助日志代码# 文件路径logs_check.py import hashlib import json SYSTEM_PROMPT 你是一个智能客服助手请保持友好语气。 TOOLS [ { type: function, function: { name: query_order, description: 查询订单, parameters: {type: object, properties: {}} } } ] def build_prefix_hash(): prefix json.dumps({ system: SYSTEM_PROMPT, tools: TOOLS }, ensure_asciiFalse, sort_keysTrue) return hashlib.md5(prefix.encode()).hexdigest() if __name__ __main__: print(缓存前缀指纹, build_prefix_hash())你可以把这个指纹打印到日志中对比不同请求之间是否一致。如果指纹变化说明前缀有改动。6.2 启用缓存后首轮请求反而更贵问题现象常见原因解决思路第一次请求费用比未启用缓存时高缓存写入单价高于普通输入单价首次请求需要额外支付写入成本这是正常现象。评估整体成本时需要看多次请求的累计费用而不是单次请求请求次数很少缓存收益不明显如果一次会话只有 1 到 2 次调用缓存写入成本可能高于节省的费用在请求次数较少的场景下优先缓存超长前缀如工具定义 长系统提示词短前缀不必启用缓存6.3 缓存导致回复内容异常问题现象常见原因解决思路后续请求似乎没有读取最新消息由于历史消息拼接顺序错误前缀包含的部分内容被错误截断或覆盖检查 messages 列表的构造逻辑确保每次追加消息的顺序正确系统提示词更新后回复风格没有变化缓存前缀没有更新还在使用旧的内容修改系统提示词时等待缓存过期或主动清理缓存在测试环境验证新前缀生效后再发布6.4 请求报错system 字段格式不支持 cache_control问题现象常见原因解决思路400 错误提示 cache_control 字段位置错误当前 SDK 版本过旧或模型版本不支持在 system 字段中设置缓存升级 SDK查阅当前版本 API 文档将缓存控制参数调整到 messages 字段中的首条消息报错提示 ephemeral 不是合法取值当前服务端仅支持其他缓存类型如 session 或 persistent以官方最新文档为准改用对应取值7. 最佳实践与工程建议7.1 命名与代码结构在代码层面建议将缓存相关的配置集中管理避免散落在各个业务模块中。例如可以新建一个cache_policy.py文件统一导出系统提示词、工具列表和缓存控制函数# 文件路径cache_policy.py from anthropic.types import TextBlockParam SYSTEM_PROMPT 你是一个智能客服助手支持订单查询、物流跟踪、售后处理。 TOOLS [ { type: function, function: { name: query_order, description: 查询订单状态, parameters: { type: object, properties: { order_id: {type: string} }, required: [order_id] } } }, { type: function, function: { name: track_logistics, description: 查询物流信息, parameters: { type: object, properties: { order_id: {type: string} }, required: [order_id] } } } ] def build_system_block() - list[TextBlockParam]: return [ { type: text, text: SYSTEM_PROMPT, cache_control: {type: ephemeral} } ]在业务代码中调用build_system_block()即可便于统一调整缓存策略。7.2 日志记录与成本监控不要等到月底看到账单才发现成本异常。建议在每次模型调用后记录 usage 信息并将 token 费用汇总到监控大盘。以下是一个简单示例# 文件路径usage_logger.py import json import time def log_usage(usage: dict, log_path: str logs/usage.log): log_entry { timestamp: time.time(), input_tokens: usage.get(input_tokens, 0), cache_creation_input_tokens: usage.get(cache_creation_input_tokens, 0), cache_read_input_tokens: usage.get(cache_read_input_tokens, 0), output_tokens: usage.get(output_tokens, 0), } with open(log_path, a, encodingutf-8) as f: f.write(json.dumps(log_entry, ensure_asciiFalse) \n)在每次调用结束后调用log_usage(usage)后续可以通过收集这些日志来统计缓存命中率、平均成本等指标。建议至少统计两个核心指标缓存读取 token 占总输入 token 的比例。平均每次请求的实际费用。7.3 最小权限与安全边界在使用 API Key 时务必遵循最小权限原则不要在代码仓库中明文提交 API Key使用环境变量或密钥管理服务。为不同环境配置不同的 Key例如测试环境与生产环境隔离。如果 API Key 泄露立即吊销并更换。在日志中不要打印完整的请求内容和响应内容尤其包含用户个人信息时需要进行脱敏处理。7.4 缓存策略的动态开关在生产环境中建议提供缓存策略的动态开关便于在出现问题时快速回退。例如可以在配置中心新增一个标志位cache.enabledtrue代码中判断该标志位决定是否在请求中附加cache_control参数。这样即使缓存功能出现问题也可以通过配置快速关闭而不需要重新发布版本。7.5 性能与成本的平衡缓存读取降价 75% 之后单次调用的成本确实下降了但智能体应用的整体成本还与以下因素相关任务拆分的粒度如果每次任务被拆成过多次模型调用总 token 数会上升。Prompt 设计的精简程度即使缓存读取便宜了缓存写入和动态输入仍然按较高价格计费所以 Prompt 仍然需要控制长度。工具调用的复杂度工具返回结果往往较长这部分内容无法缓存需要关注动态输入的增长。因此最理想的做法是把缓存降价的收益与 Prompt 工程优化叠加使用而不是因为缓存便宜了就在 Prompt 中堆砌无用信息。7.6 灰度发布与效果评估建议先在小范围流量中启用缓存策略对比开启前后的成本数据。具体步骤如下选择一类负载特征稳定的接口例如客服机器人或知识库问答。在测试环境验证缓存控制参数生效。取 10% 生产流量开启缓存观察日志中的缓存读取占比。对比启用缓存前后的费用和延迟。确认无异常后逐步扩大到全量流量。缓存读取降价 75% 是一个很好的契机但只有通过数据验证才能确认你的智能体负载到底能从缓存中节省多少成本。8. 总结与后续学习建议通过本文的分析和示例你应该已经理解了几个关键点智能体负载成本偏高的根源在于大量重复的固定前缀例如系统提示词、工具定义和历史上下文。缓存读取降价 75% 后长前缀、高命中率的智能体场景可以把整体成本压低约 45%但前提是要保证前缀稳定性、控制缓存写入成本、理解缓存有效期。在代码层面通过cache_control参数标记可缓存内容即可改动成本很低关键是合理的请求结构设计。接下来可以继续深入的方向包括研究不同会话策略下缓存命中率的差异例如短会话 vs 长会话。结合函数回调、多 Agent 协作等复杂智能体场景做更细粒度的成本拆解。熟悉日志监控和账单分析建立常态化的成本巡检机制。如果你的智能体应用目前还没有启用缓存建议先在测试环境按本文的示例跑一遍观察 usage 中的缓存写入和缓存读取字段再结合自己的请求量级测算成本和收益。毕竟 45% 的成本降幅对于规模化运行的 AI 应用来说是一笔相当可观的优化空间。