Claude 的上下文窗口虽然可以达到 200K token，但实际请求中真正有价值的信息往往只占一小部分。不少团队在使用工具调用、多轮对话和代理任务时，会习惯性地把完整历史消息、全部工具输出和重复的格式说明一起发送给模型。结果并不是回答更准确，而是输入 token 快速膨胀，成本上升，响应速度也受到影响。要解决这个问题，不能只靠直觉截断历史，而需要同时掌握两个机制：一个是针对稳定前缀的 Cache Control，另一个是对动态会话进行语义级修剪。
上下文窗口为什么会越用越紧
每次向 Claude 发起请求，模型都需要重新处理整个输入序列。系统提示、历史对话、工具返回结果、示例说明，甚至附加的 JSON 指令都会占用 token。即使前一条消息与上轮请求完全相同，只要它出现在上下文里，这一轮仍然会被纳入计算。这意味着多轮对话的输入长度通常不是线性增长，而是在工具调用失败、重复生成、或者长文档分段处理时快速膨胀。
浪费的另一个来源是前缀缓存失效。Claude 的提示缓存机制会尝试复用与上一次请求相同的前缀，但缓存能否命中取决于前缀中的 token 是否完全一致。很多团队习惯在系统提示开头加入当前时间戳、随机 request_id，或者在保留消息时无意中改变了系统提示内容。只要前面任何一个 token 发生变化，后续即使有大量完全重复的历史消息，缓存也无法生效。这也是很多优化尝试最终看不到明显成本下降的原因之一。
因此，单纯减少消息条数不一定能解决问题，更关键的是把上下文拆成静态前缀和动态会话两个区域，分别采取不同的管理策略。静态前缀要尽量稳定，动态会话要有选择地保留，而不是整段整段地堆叠。
Cache Control 如何稳定缓存前缀
Anthropic 在 Claude API 中提供了基于内容的提示缓存，通过在内容块上添加 cache_control 字段来标记哪些部分值得缓存。可以将系统提示、工具定义、少样本示例、固定的角色设定等长期不变的内容标记为缓存对象。一个典型的请求体如下：
{
"model": "claude-3-5-sonnet-20240620",
"max_tokens": 1024,
"system": [
{
"type": "text",
"text": "你是本系统的技术支持助手，回答时先复述问题，再给出步骤。",
"cache_control": {"type": "ephemeral"}
}
],
"messages": [
{
"role": "user",
"content": "请帮我分析这份错误日志。"
}
]
}
这个标记告诉服务端，system 字段里的文本应当被缓存。下一次请求如果仍然以完全相同的前缀开始，服务端就可以直接复用已经计算好的内部状态，从而减少首 token 延迟和输入处理费用。缓存读取的价格通常低于基础输入价格，而缓存写入的价格略高，所以适合那些在多次请求中保持不变的部分。
缓存并不是万能的。它有一个较短的生存周期，通常为几分钟；同时，缓存内容需要达到一定的最小长度才会生效。更重要的是，缓存按前缀匹配原则工作。如果系统提示前面插入了变化的时间戳、随机 ID，或者工具定义的顺序每次不同，缓存就会频繁失效。因此在使用 cache_control 时，应当把最稳定、最靠前的内容标记出来，并确保每次请求都遵循同样的前缀顺序。
实际项目中，不建议对普通对话消息标记缓存。用户消息和助手回复在每一轮都可能不同，标记它们只会增加写入成本，而命中率极低。正确的做法是只在系统提示、工具 schema、稳定示例和固定的输出格式说明上使用缓存控制，让这些静态内容承担缓存收益，动态内容则不进入缓存区。
动态修剪的核心策略
动态修剪的目标不是简单删除旧消息，而是根据当前任务和 token 预算，保留与后续回答相关的关键信息。一个常见做法是从最新消息往前扫描，为每条消息估算 token 消耗，直到达到预算上限。下面的 Python 示例展示了这种滑动窗口裁剪逻辑：
def trim_messages(messages, budget_tokens, reserved_system_tokens):
available = budget_tokens - reserved_system_tokens
kept = []
total = 0
for msg in reversed(messages):
content = msg.get("content", "")
estimate = len(content) // 4
if total + estimate > available and len(kept) > 2:
break
kept.append(msg)
total += estimate
return list(reversed(kept))
这段逻辑会优先保留最近的对话，避免在预算内误删当前轮需要依赖的上下文。但它也有明显局限：如果旧消息中包含某个重要参数、用户偏好或工具调用的关键返回值，简单按时间裁剪就可能丢失信息。因此，更完善的修剪策略需要区分消息类型和重要程度。
修剪可以分为三个层次。消息级修剪只保留最近 N 条消息，适合闲聊式或短期任务。块级修剪会依据工具输出、代码块、错误堆栈等边界进行裁剪，保留关键片段，例如从长日志中提取错误码和堆栈摘要。摘要级修剪则会把较早的对话压缩成一段简短说明，替换掉原始多条消息，从而在保留历史脉络的同时大幅降低 token 占用。三种方式可以组合使用，比如先做摘要，再进行消息级裁剪。
与 Cache Control 结合时，必须注意保持稳定前缀不变。系统提示和工具定义不应进入动态修剪范围，否则缓存前缀会随修剪过程被修改，导致缓存失效。一个稳妥的划分方式是：系统提示、工具 schema、固定输出格式作为第一层静态区，永远保留并标记缓存；多轮对话和工具结果作为第二层动态区，每轮请求前执行修剪；如果某个动态内容具有长期价值，可以将其提升为第三层“摘要区”，用固定格式写入，但不要插入到缓存前缀之前。
组合方案与效果验证
将 Cache Control 与动态修剪放在一起，可以形成一套比较完整的上下文管理流程。首先准备好静态前缀，确保系统提示和工具定义稳定，并添加 cache_control 标记；其次根据当前任务设定输入 token 预算，对动态消息执行修剪；最后发送请求，并在响应中检查缓存使用情况。API 返回的 usage 字段里通常包含 cache_read_input_tokens 和 cache_creation_input_tokens，它们分别表示本次请求从缓存中读取的 token 数和为缓存写入的 token 数。持续观察这两个值，可以判断缓存前缀是否稳定。
下面是一个多轮对话测试的对照结果，假设计算环境为相同的工具调用场景：
| 轮次 | 原始输入Token | 修剪后Token | 缓存读取Token | 相对成本 |
|---|---|---|---|---|
| 5 | 12400 | 8900 | 4800 | 降低约32% |
| 10 | 25800 | 13200 | 7000 | 降低约41% |
| 20 | 48900 | 18700 | 9100 | 降低约53% |
从趋势可以看出，随着轮次增加，原始输入几乎线性增长，而修剪后 token 的增速明显放缓。缓存读取 token 也在增加，说明静态前缀的缓存命中率保持稳定。成本的下降不仅来自输入 token 减少，还因为缓存读取单价更低，两者叠加后，长任务中的总成本可以显著降低。
实际使用时还要注意几个容易忽略的点。第一，不要在缓存前缀之前插入任何变化的内容，比如时间戳、随机 ID 或每次重新生成的用户欢迎语；第二，对旧消息做摘要时，摘要文本本身不能放在系统提示前面，否则会改变前缀顺序；第三，如果工具输出中包含 Markdown 表格或 JSON 数据，可以用结构化的方式只保留与当前问题相关的字段，而不是整段原文。动态修剪并不追求绝对最短，而是要在信息完整度和 token 成本之间找到一个可复用的平衡点。
上下文窗口管理不是一次性配置，而是一个需要持续调整的工程。Cache Control 解决的是“重复计算稳定内容”的问题，动态修剪解决的是“历史消息无限膨胀”的问题。把两者配合起来，才能在保持回答质量的同时，让 Claude 的长对话任务真正可控。
Claude ContextCache Control动态修剪修改时间：2026-10-02 02:02:17