在 Claude API 的计费逻辑中，多轮对话是一个容易被低估的成本黑洞。每个新的 API 请求都需要将完整的对话历史重新发送一遍，随着对话轮次增加，输入 Token 呈线性增长，账单随之失控。根据实测数据，在多轮 Agent 场景中，工具结果(文件内容、命令输出)占据了 85% 左右的 Token 消耗，而用户真正的问题和 AI 的回复加起来不到 10%。这种“重上下文、轻回复”的对话结构，让上下文管理成为控制 Claude API Token 成本的核心战场。

　　本文将为你拆解四大核心策略，从 Prompt Caching 到上下文压缩，帮你系统性地控制 Claude API 的多轮对话 Token 成本。

　　一、Prompt Caching：用 10% 的价格复用稳定前缀

　　Prompt Caching 是控制多轮对话成本的第一道防线。它的逻辑是：在多轮对话中，System Prompt、工具定义、项目说明等稳定不变的大段内容会被持续重复发送。开启缓存后，这部分内容的命中价格仅为基础 input 价格的 10%，即折扣高达 90%。

　　实际操作：添加 cache_control 断点

　　在调用 Claude API 时，为稳定内容块添加 cache_control 标记即可开启缓存。

　　正确写法(System Prompt 必须用数组格式)：

client.messages.create(
    model="claude-opus-4-7",
    max_tokens=2048,
    system=[
        {"type": "text", "text": "你是一个专业的代码审查助手..."},
        {"type": "text", "text": LONG_SYSTEM_PROMPT},
        {"type": "text", "text": "# 项目规范\n- 使用 TypeScript\n- 遵循 ESLint 规则...", "cache_control": {"type": "ephemeral"}}
    ],
    messages=[{"role": "user", "content": user_query}]
)

　　容易踩的三个坑：

　　1. 在缓存前缀中塞入变化内容：如 Current time: 2026-08-27T14:32:15Z，每次请求都变导致缓存完全失效。应将日期截断到天，或放到缓存断点之后。

　　2. 把用户 ID、Session ID 写进 System Prompt：每个用户都是不同的 cache miss，成本反而更高。

　　3. 内容不够长不触发缓存：不同模型有最低 Token 门槛——Opus 4.7 需要 4096 Token，Sonnet 4.6 需要 2048 Token。

　　缓存的经济账

　　5 分钟缓存写入需要按 1.25 倍基础价格支付，但复用一次即可回本;1 小时缓存写入成本为 2 倍基础价格，需复用 2 次以上才划算。

　　验证缓存是否生效

　　查看 API 响应中的 usage 字段：

　　cache_creation_input_tokens > 0：表示本次请求写入了缓存(首次请求)

　　cache_read_input_tokens > 0：表示本次命中了缓存(省钱的关键指标)

　　两者均为 0：缓存未生效，检查 cache_control 放置位置是否正确

　　二、上下文压缩(Compaction)：给长对话“瘦身”

　　多轮对话越长，历史消息占用的 Token 越多。Compaction 是 Anthropic 官方提供的 API 级解决方案，它会在上下文接近窗口上限时，自动将早期消息总结成一段更短的摘要，替代原始的完整对话历史。

　　官方 Compact API 启用方式

response = client.beta.messages.create(
    betas=["compact-2026-01-12"],
    model="claude-opus-5",
    max_tokens=4096,
    messages=messages,
    context_management={"edits": [{"type": "compact_20260112"}]}
)

　　当 API 接收到压缩块后，此前的所有内容块都会被忽略，对话从压缩后的摘要处继续。

　　重要认知：Compaction 本身需要一次额外的采样步骤，计入速率限制和账单。但它能大幅减少后续每轮请求的 Input Token，属于一次性投入、长期省钱的操作。

　　手动清理：在对话层面截断

　　如果不想走 API 压缩，也可以手动在对话层面对话：

　　/clear：直接清空当前会话，开始新会话(适用于任务已完成的场景)

　　/rewind：回退到对话历史的某个节点，丢弃后续无效的探索路径，避免“失败尝试的中间过程”持续污染上下文

　　这一点在多轮 Agent 场景中尤为重要：每一次探索失败后，与其继续纠错，不如回退到尝试前的节点重新下达指令，保留有价值的文件读取、丢弃失败的尝试。

　　三、模型分级路由：让“对的人”干“对的活”

　　Claude 各模型的定价差异悬殊：

　　用 Opus 干杂活比用 Haiku 贵 5 倍。合理的做法是按任务复杂度选择模型：

　　Haiku：数据标注、批量分类、格式转换、摘要生成(成本敏感型任务)

　　Sonnet：日常编码、文档撰写、API 集成(80% 的工作)

　　Opus：复杂推理、架构设计、深度调试(仅 10% 的重任务)

　　将 80-90% 的流量路由到 Haiku，是单次决策中杠杆效应最高的省钱动作。

　　四、Batch API：给非实时任务打对折

　　对于不需要立即返回结果的批量任务，Claude 的 Message Batches API 提供固定的 50% 折扣，覆盖输入和输出 Token，模型不变、质量不变。

　　适合 Batch API 的场景：过夜数据标注、评估流水线、批量摘要生成、存量数据的分类/提取

　　大部分批处理在一小时内完成，最长 24 小时兜底。这是“白给”的省钱手段——唯一的代价是你愿意等。

　　五、常见问题问答

　　Q1：多轮对话中 Token 到底花在哪里最多?

　　A1：工具结果(文件内容、命令输出、搜索结果)。 在多轮 Agent 场景中，工具结果占总 Input Token 的 85% 左右，而用户问题和 AI 回复加起来不到 10%。很多工具结果在几轮后已经过时(比如读了旧版本文件、执行了失败的尝试)，但依然被重复发送，持续浪费成本。

　　Q2：Prompt Caching 的“稳定前缀”最小需要多少 Token?

　　A2： 不同模型门槛不同。Opus 4.7 / Haiku 4.5 需要 4096 Token，Sonnet 4.6 需要 2048 Token。如果内容不够长，缓存不会生效，cache_read_input_tokens 会显示为 0。

　　Q3：Compaction 和 /clear 有什么区别?

　　A3： Compaction 是保留摘要的压缩，模型仍然知道之前聊过什么，只是压缩了篇幅;/clear 是清空全部历史，从零开始新会话。前者适合长对话中后期，后者适合任务切换或彻底重新开始。

　　Q4：如何估算一个请求的 Input Token 数量?

　　A4： 使用 Claude 官方的 count_tokens 端点。请勿使用 tiktoken(OpenAI 的 tokenizer)，它会对 Claude 的输入低估约 15-20%，导致基于它的预算完全不准确。

　　总结：控制 Claude API 多轮对话的 Token 成本，本质上是一场“上下文精简”与“成本意识”的合谋。核心动作只有四条：用 Prompt Caching 以 10% 的价格复用稳定内容，用 Compaction 压缩长对话历史，按任务复杂度分级选模型，把非实时任务丢给 Batch API 打对折。记住：多轮对话中真正值钱的不是答案本身，而是你塞进上下文的那堆历史记录和文件内容——管理好它们，账单自然就下来了。