Claude上下文窗口与提示缓存：成本优化实战指南

假设一个团队为助手开启了提示缓存，提示词又大又稳定。财务审核预期账单下降90%，结果账单反而涨了约四分之一。系统没坏，缓存也完全按文档工作——流量每六分钟到达一次，而默认缓存只存活五分钟，于是每个请求都付了写入缓存的溢价，却没有任何请求命中缓存。

这个案例揭示的核心问题不是"知不知道缓存存在"，而是"能否针对具体工作负载算出缓存的实际效果"。上下文窗口的优化远不止缓存一个开关，它是一整套工具箱：什么计入窗口、什么该清除、什么该压缩、什么只在需要时加载、什么打包一次到处复用。本文基于Claude官方平台文档与工程博客的公开资料，拆解这些机制背后的成本逻辑。

上下文窗口：缓存改变的是价格，不是容量

一个常见误解是开启缓存能缓解窗口溢出。事实相反：缓存只改变你付多少钱，不改变多少内容能塞进去。系统提示、全部历史消息（含工具结果、图片、文档）、工具定义，以及本轮生成的输出（包括思考token）都计入窗口。三个用量计数器——input_tokens、cache_read_input_tokens、cache_creation_input_tokens——全部计数。

还有一个容易忽略的细节：思考token属于你设置的max_tokens上限，按输出计费；在当前模型上，先前的思考块默认保留在后续请求中，按普通输入计数。

更大的窗口也不等于可以填满它。随着token数增长，准确率和召回率会下降，文档称之为"context rot"（上下文腐化）。Anthropic工程博客将其框定为"注意力预算"——上下文是有限资源，边际收益递减。目标不是不惜代价最小化token，而是找到让模型完成任务的最小高信号token集合。

前缀缓存（Prefix Caching） 是理解全文的基础机制。它把提示词按固定顺序（工具定义 → 系统提示 → 消息历史）切成连续前缀，对相同前缀的计算结果做复用：命中时只需为新增的尾部 token 付费。正因如此，命中要求前缀逐字节相同，任何位置插入易变内容（时间戳、用户 ID）都会让该位置之后的所有缓存失效。这也是为什么文章反复强调“稳定内容排前面、易变内容排最后”——缓存优化本质上是提示词布局问题，而非单纯的成本开关。

度量工具：token计数与用量对象

无法度量就无法优化。平台提供两个工具。

第一个是token计数端点，在发送前统计消息（含工具、图片、文档）的token数，免费使用，有独立于消息创建的每分钟请求限额。两点注意：结果是估算值，可能与实际用量有小幅偏差；计数不触发缓存，缓存只在真实的 message creation 中发生。另外，从Claude Opus 4.7起模型使用不同的分词器，跨模型迁移时不要复用旧的计数。

第二个是每个响应上的usage对象。如果creation和read都是零，说明提示完全没有被缓存——这本身就是诊断信号，例如前缀短于最低可缓存长度。专业习惯是：按请求、按路由记录这三个数字，计算缓存命中率（reads除以总输入），并对其变化设置告警。

上下文管理工具箱：杠杆要对准token来源

没有单一的上下文修复方案，关键在于把杠杆匹配到token实际所在的位置。

• 工具定义占用窗口 → 工具搜索与延迟加载。发送一小部分常驻工具加一个搜索工具，让Claude按需发现其余工具。建议在工具集超过约20个时启用，代价是首次需要某工具时多一轮交互。
• 工具调用链产生中间结果 → 程序化工具调用。Claude写一个脚本在沙箱内调用函数，只有最终输出进入对话。
• 旧工具结果堆积 → 上下文编辑（context editing），按规则清除最近几条之外的工具结果，可预测、无摘要。
• 整个对话接近上限 → 压缩（compaction），由服务端把较早的轮次总结成压缩块。
• 跨会话或跨压缩的记忆 → 记忆工具或自建笔记文件。
• 子任务产生大量无关输出 → 子代理，在干净窗口中工作，只返回浓缩摘要。代价是多代理系统整体消耗数倍token。
• 数据大且大部分静态、只需切片 → 检索，按需加载相关片段。
• 任务本身不需要最强模型 → 模型选择与effort设置。

还有一条先于所有杠杆的规则：少写。简洁的系统提示、只返回标识符和摘要的工具结果、在Claude看到之前就把万行日志过滤成错误行的钩子——Claude Code Costs页面直接给出了这个例子，数万token被压缩到数百。

决策规则可以简化为三句话：token在定义里，就延迟加载；token在过期的工具结果里，就清除；token在仍有意义的对话历史里，就总结，并把必须精确保留的内容写入记忆。考试中的错误选项，通常是把正确的杠杆用在了错误的token来源上。

提示缓存：机制、失效与成本算术

缓存是这一部分最可考的主题，需要精确掌握。

如何开启与断点行为

自动缓存：在请求顶层加一个cache_control字段，系统在最后一个可缓存块上放置断点，并随对话增长前移。显式断点：在单个内容块上放置cache_control，每个请求最多四个断点（自动缓存占用其中一个）。

断点只决定写入发生的位置，系统从每个断点向前回看最多20个位置寻找匹配的早期条目。长代理循环中，如果前缀自上次写入后增长了超过20个块，就会错过——这正是长循环需要增加中间断点的原因。

断点（cache breakpoint） 是显式写入缓存的锚点，最多四个。理解它的关键是“回看窗口”：系统从每个断点向前最多回看 20 个内容块寻找可匹配的已缓存条目，而不是无限回溯。在长代理循环中，每轮都会追加若干工具调用与结果块，当前缀自上次写入后累计增长超过 20 个块时，原断点就“够不着”旧条目，只能重新写入。解决办法是在循环中途补加中间断点，把长前缀切成若干段分别锚定，这也是长会话缓存命中率骤降的常见原因。

什么会让缓存失效

缓存是前缀缓存，顺序为工具 → 系统 → 消息。命中要求100%相同的片段，某一层的改动会让该层及其后所有层失效。修改工具定义，全部失效；切换web搜索或引用，系统和消息缓存失效；改变tool_choice、并行工具设置或图片是否存在，消息缓存失效。这就是为什么把时间戳、请求ID或按用户的问候语放在系统提示顶部，会悄无声息地毁掉每个请求的缓存。

生命周期、最低长度与并发

默认条目存活5分钟，每次使用免费刷新。5分钟从写入或读取的请求开始计，而非响应结束。另有1小时选项，混用时1小时条目必须排在5分钟条目之前。

前缀短于模型最低长度时会被静默地按无缓存处理，不报错。各模型的最低值不同，从512到4096 token不等。症状是两个计数器都是0。

并发方面：缓存条目只有在首个响应开始后才可用。如果同时发出100个相同前缀的并行请求，可能全部写入并各付写入价。正确做法是先发一个，等响应开始，再发其余。预热请求（max_tokens设为0）也能写入缓存并返回空内容，但不能与流式、思考、结构化输出、强制工具选择或批处理API组合使用。

成本公式与盈亏平衡

5分钟写入成本是基础输入的1.25倍，1小时写入是2倍。读取成本在多数模型上是基础的十分之一，部分新模型更低。以Sonnet 5.5为例：一次无缓存请求成本为1个单位，缓存后写入1.25加一次读取0.05等于1.3，所以生命周期内的第二次请求就已经回本。1小时缓存写入2个单位，需要小时窗口内至少三次请求才能胜出，它的真正用途是跨越超过5分钟的空隙。

这里回到开头的案例：100个请求，每6分钟一次。5分钟条目在下一次请求前总是过期，每次调用都重新写入。结果是5分钟缓存比不缓存还贵约四分之一，而1小时缓存存活于每个间隙，实现大幅节省。教训很清晰：TTL必须对照真实的请求间隙分布来选择，而不是平均值；命中率接近零且每次调用都有creation，就是过期、前缀变化或前缀过短的典型特征。

上下文编辑与压缩：规则与摘要的分工

上下文编辑的策略名为clear_tool_uses，需要beta头部。参数值得逐字记住：trigger（何时开始清除，默认10万输入token）、keep（保留最近几对工具调用与结果，默认3）、clear_at_least（至少要释放的token数，否则策略完全不应用）、exclude_tools（永不清理的工具名单）、clear_tool_inputs（默认false，只移除结果，模型仍能看到自己发起过哪些调用）。

clear_at_least为什么存在？因为清除会编辑提示中部，从编辑点之后让缓存前缀失效。清500 token却毁掉10万token的缓存，账单只会更糟。合理设置是一次释放一大块，然后让缓存重建并承载后续轮次。

压缩则是Claude写的摘要。可以按需压缩（自己控制时机，可逐字保留近期轮次），也可以在普通请求上设一个token阈值触发（默认15万输入token，最低5万）。若设置pause_after_compaction为true，API写完摘要后以compaction停止原因暂停，便于你重新插入近期轮次。自定义摘要指令会完全替换默认提示，而不是追加，所以必须说清所有需要保留的内容。计费上，压缩需要额外的采样步骤，顶层usage字段不包含它，必须累加usage_iterations数组才能得到真实总量——只读顶层字段的成本模型会低估压缩密集型工作负载。

选择原则：旧工具输出是大头且不再需要，用清除；对话本身（目标、决策、进展）太长，用压缩，并接受摘要有损；两者都应配合记忆保存必须精确的内容——标识符、决策、未完成任务、文件路径。最后一条架构师级别的提醒：压缩不是安全或合规边界，受监管的数据不应依赖摘要来丢弃，而应从一开始就不进入上下文。

compaction 的停止原因（stop_reason: compaction） 是压缩机制中的一个控制点。默认情况下，服务端写完摘要后继续生成回答；当设置 pause_after_compaction 为 true 时，API 在摘要完成后立即暂停并返回该停止原因，把控制权交回调用方。这让你能在压缩块与新一轮输入之间手工插入近期原始轮次、关键标识符或工具状态，避免有损摘要吞掉必须精确保留的内容。代价是每轮多一次往返，适合对连续性要求高的长任务。

模块化提示与技能：一次打包，处处复用

模块化提示是由命名、版本化的部分拼装的：身份与角色、策略、工具使用规则、输出格式契约、示例、任务槽。这不是某个产品特性，而是通用架构实践，官方文档给出的理由包括：稳定模块按固定顺序拼接形成稳定前缀，利于缓存；便于从最小提示开始、根据观察到的失败逐步添加；用XML标签分隔模块避免模糊；每个模块有负责人、版本和测试，回归可归因。反面模式则是人人都改的巨型提示、粘贴到十几个应用中逐渐漂移的片段、与工具描述重复的系统提示指令。

技能（Skills）是平台对"如何给Claude大量可复用的程序性知识而不必每次付费"的回答，核心设计原则是渐进式披露，分三层。第一层是元数据：front matter中的名称和描述在启动时载入系统提示，每个技能约100 token，装很多技能也不会有上下文负担。第二层是主文件正文，请求匹配描述时才加载，文档建议低于5000 token。第三层是技能捆绑的其他文件——额外的markdown、参考数据、模板和脚本，在Claude打开之前零成本。脚本更优：Claude运行它，只有输出进入上下文，代码本身不进入。

作者规范值得逐条执行：只添加Claude不知道的内容；主文件正文控制在500行以内；引用文件只放一层深，因为Claude可能只预览嵌套文件；较长的参考文件加目录；确定性工作优先用脚本；避免时间敏感表述；在大量写文档之前先建至少三个评估。

运行位置上有几个关键考点：API上自定义技能在工作区内共享；Claude AI上自定义技能属于个人，以zip上传，没有组织级分发；自定义技能不会跨服务同步——上传到一处，不会自动出现在另一处。安全上应像安装软件一样对待技能，只使用可信来源，审计每个捆绑文件，查找与用途不符的网络调用和数据访问。

渐进式披露（progressive disclosure） 源自人机交互设计，指按需、分层地暴露信息，避免一次性倾泻。在技能中它被落地为三层：元数据常驻（约 100 token/技能）、正文按描述匹配加载（建议 <5000 token）、捆绑文件打开时才计入上下文。其成本含义是“闲置知识零成本”：技能库可以很大，但只要描述写得好、匹配精准，只有真正被用到的技能才消耗窗口。前提是描述必须准确反映触发场景，否则要么误加载、要么永不触发。

决策框架与常见反模式

把机制落到架构决策上，可以归纳为几条判断线：始终需要且简短的全局规则放在项目配置文件；部分任务需要的程序性知识做成技能，按需加载；大量互不相关文档的事实语料走检索；实时数据和操作通过工具；每次请求都需要的固定知识放进缓存前缀。区分维度是"多久需要一次"和"有多大"。

Claude Code本身是个好案例，它自动应用了这些原则：请求按稳定优先排序——系统提示与工具定义、项目上下文、对话。对话变化不影响前两层缓存；系统提示变化则使其后全部失效。切换模型、修改effort、切换fast模式、连接或移除未延迟加载的MCP服务器、压缩对话、积累大量图片、升级Claude Code都会失效缓存；编辑文件、切换权限模式、调用技能和命令、派生subagent、回退则保持缓存有效。一个常见陷阱：会话中途编辑Claude.md保持缓存有效，但直到清除、压缩或重启才生效，因为文件在会话开始时就被缓存了。

应当摒弃的反模式清单：开启缓存却不度量命中率；在提示顶部放易变值；对间隙超过5分钟的流量使用默认生命周期；在首个请求填充缓存前就发并行请求；在生产环境随意编辑工具描述；用最大窗口替代内容治理；不带clear_at_least的清除（用微小节省换毁掉整个缓存）；依赖摘要保留精确标识符；把同一份程序复制到多个提示而不是做成一个受评估的技能。

上下文优化的本质是架构决策，而非配置开关。最便宜的token，是根本没有产生的token。