# Anthropic 发布 Claude Platform 降本指南：提示词缓存、清理反模式与校准 effort

- 来源：Claude：Blog（网页）
- 发布时间：2026-09-09 01:59
- AIHOT 分数：68
- AIHOT 标记：同事件
- AIHOT 链接：https://aihot.news/items/cmtsz50zn02mtro5w6ywm1xml
- 原文链接：https://claude.com/blog/reducing-cost-and-improving-performance-with-claude-platform

## AI 摘要

Anthropic 官方博客介绍用三项手段降低 Claude Platform 成本而不牺牲性能：提高提示词缓存命中率、清除旧模型遗留的提示词反模式、按任务校准 effort。

## 正文

调整提示词缓存、指令和推理投入，可以在不牺牲应用性能的前提下降低 Claude 的使用成本。

分类

智能体

产品

Claude 平台

日期

2026 年 9 月 8 日

阅读时间

5

分钟

https://claude.com/blog/reducing-cost-and-improving-performance-with-claude-platform

作者

Lance Martin

性能和成本往往被视为一种权衡取舍：要想花得更少，就得接受更差的结果。但在实践中，我们发现许多使用 Claude Platform 的应用只需三项调整，就能在不牺牲性能的前提下降低成本：最大化提示词缓存命中率、在升级到前沿 Claude 模型时移除提示词中的反模式、以及根据任务校准推理投入。我们已将这些指导建议整合到 claude-api 技能中。在本文中，我们将展示 Claude Code 配合 claude-api 技能如何常常能找到在维持或提升性能的同时降低成本的方法。

提示词缓存

在 Claude 生成回复之前，它会先将你的提示词处理为一种内部工作状态。这一步称为预填充（prefill），是处理输入中成本最高的部分。提示词缓存会保存该状态（即键值缓存，或称 KV cache）：当请求以相同前缀开头时，Claude 会直接读回该状态，而不是重新计算。缓存读取的计费价格仅为完整输入价格的一小部分。

要确保提示词缓存的有效使用，有几个实际注意事项。首先，提示词缓存绑定在特定模型上。其次，提示词缓存的读取必须在提示词前缀上做到逐字节完全一致。最后，提示词缓存有有限的生存时间（TTL）。

考虑到这些要点，这里有一些实用建议：

在对话中途更改推理投入设置时要小心。这些设置会渲染到提示词中你内容的前面，因此它们属于被缓存前缀的一部分。只有在部分精选 Claude 模型（包括 Opus 5 和 Fable 5.1）上，你才能在不破坏缓存的情况下于对话中途更新推理投入设置。

将易变的值排除在提示词前缀之外。系统提示词中的动态时间戳或 ID 可能会在模型调用之间发生变化，从而破坏缓存。

避免使用会自行重新排序的工具定义。使用 Claude Messages API 时，提示词会按固定顺序组装，工具定义渲染在顶部。工具定义的任何更改都会破坏缓存。

分叉对话时要小心。只有当分叉的前缀字节完全相同、使用相同模型且采用相同 effort 设置时，子智能体和分支才会共享父级的缓存。

如何修复

我们积累了一些关于提示词缓存管理的经验教训：

仔细监控你的提示词缓存命中率。Claude Console 和缓存诊断 API 提供提示词缓存诊断信息，包括提示词缓存未命中的原因（图 1）以及两个请求在何处发生分歧。

图 1. Claude Console 可以通过比较连续请求并精确定位提示词前缀在何处发生分歧，来诊断意外的提示词缓存未命中。

仔细监控你的提示词缓存命中率。Claude Console 和缓存诊断 API 提供提示词缓存诊断信息，包括提示词缓存未命中的原因（图 1）以及两个请求在何处发生分歧。

仔细监控你的提示词缓存命中率。Claude Console 和缓存诊断 API 提供提示词缓存诊断信息，包括提示词缓存未命中的原因（图 1）以及两个请求具体在何处发生分叉。

延迟加载不常用的工具。预先声明所有工具，但将不常用的工具标记为 defer_loading：它们不会进入缓存前缀，只有在 Claude 通过工具搜索查找它们时才会被追加到对话中，从而保持缓存不被破坏。

以消息形式应用系统提示词更新。Claude Platform 允许你在对话中途以消息形式添加系统指令，而不是编辑系统提示词，这样可以保留缓存。

合理布局请求，让稳定部分保持稳定。先添加静态上下文（工具定义和系统提示词），再将不断增长的对话内容放在它们之后（图 2）。

图 2. 组织提示词，确保动态内容被追加到稳定前缀的末尾。

在提示词缓存即将失效时再更改模型或推理力度。某些操作（如压缩）本身就会重写大部分缓存（对话内容）。此时是切换模型或推理力度的好时机，因为你无论如何都要为一次缓存未命中买单。

随着对话增长移动缓存断点。使用 Claude Platform，你可以设置自动缓存，将缓存断点应用于最后一个可缓存块。

预热缓存。为降低延迟，可发送一个带 `max_tokens: 0` 和显式缓存断点的请求。这样会处理提示词并将其写入缓存，但不会生成任何内容。如果你在会话开始时运行它（例如在用户输入期间），第一个真实请求就能命中已预热的缓存。

不要超过提示词缓存 TTL。5 分钟缓存 TTL 从请求开始时计算。如果智能体在工具调用或子智能体请求上阻塞，且运行时间超过 5 分钟，父级缓存会在结果返回前过期。在这种情况下，可考虑对前缀设置 1 小时 TTL。

指令

提示词中可能积累了大量用于修补模型弱点的指令。这些指令可能相对于最新 Claude 模型的能力发生偏移。以下是一些常见的提示词“反模式”，它们会拖累前沿 Claude 模型的表现，并可能无意中增加成本：

验证仪式。诸如“仔细检查你的工作”或“回复前验证两次”之类的指令，往往会被前沿模型按字面理解，从而浪费 token。

详尽性与强调增强语。“做到极致详尽”“关键：你必须始终……”等表述，在使用前沿模型时可能导致输出冗长和多余的调用。

强制流程与草稿本脚手架。固定步骤流程（例如“在草稿本中逐步思考”）或推理模板，是前沿模型并不需要的仪式性做法。这类脚手架会叠加在模型原生推理能力之上，消耗不必要的 token。

过时的示例。针对旧模型失败模式调优的少样本示例，可能会教前沿模型在不需要长推理链的请求上模仿冗长的推理过程。

相互矛盾的规则。前沿模型更擅长遵循指令。相互矛盾的指令（“始终在政策范围内退款”与“未经升级不得退款”）可能会被前沿模型更字面地执行，从而导致性能下降。

过时的配置。为旧版 Claude 编写的设置（例如手动思考预算）在升级到前沿模型时可能会被 Claude Platform 拒绝。

如何修复

我们更新了 claude-api 技能，新增了一个命令来监控这些反模式。在 Claude Code 中，对你的提示词、技能或工具描述运行 /claude-api prompt-audit。该审计覆盖你工作目录中的任何内容，包括调用 Claude API 的应用程序代码以及 Claude Code 自身的配置（例如 CLAUDE.md 或技能）。

例如，我们在一个客户支持基准测试上测试了从 Opus 4.8 到 Opus 5 的模型迁移。我们从一份干净的提示词开始，每次植入一个反模式（一个已停用的思考设置、一对相互矛盾的退款规则、一个手动草稿区、“验证两次”、“做到极致彻底”以及一个强制性的六步流程），从而得到六份遗留提示词。

我们在 Opus 4.8 上运行了每一份提示词，在仅更改模型 ID 的 Opus 5 上运行了每一份，以及在每份提示词运行一次 /claude-api prompt-audit 后的 Opus 5 上运行了每一份（图 3 显示了这六份的平均结果）。

图 3. 从 Opus 4.8 迁移到 Opus 5 时，提示词反模式的影响。

图 3 | 从 Opus 4.8 迁移到 Opus 5 时，提示词反模式的影响。

在 Opus 5 上，验证仪式（“verify twice”）会在每次退款时重复查询订单，从而浪费不必要的 token。强调增强词（“be maximally thorough”）则变成了数十次无谓的知识库搜索。

运行 /claude-api prompt-audit 消除了这些反模式，平均成本降低了 14.6%，准确率提升了 5.3%。成本下降是因为多余的工具调用和重复推理被消除。准确率提升有三个原因。已停用的思考设置导致 API 直接拒绝所有路由请求。相互矛盾的退款规则导致 Opus 5 在要求客户确认的同时，扣下了四笔本应退还的款项。而手动草稿板与 Opus 5 的内置思考发生冲突：在三张工单上，模型把工具调用写进了推理过程，却从未执行。

努力程度

努力程度告诉 Claude“该多努力地工作”。在低努力程度下，Claude 通常能更快得出结论。在高努力程度下，Claude 会在回答前进行深思、验证并探索替代方案。

在单一模型上，不同思考强度下的成本与性能之比可能差异很大。例如，Claude Fable 5 在 FrontierCode Diamond（最难的 50 道任务）上，低思考强度下得分为 11.5%，每任务成本为 $5.35。在最高思考强度下，Fable 5 得分为 30.9%，每任务成本为 $19.00；调整思考强度可使得分提升约 2.7 倍（+19 个百分点），而成本约为原来的 3.5 倍（图 4）。

在 Claude Fable 5.1 上，Humanity's Last Exam（无工具）呈现出陡峭的曲线，最后一步的提升幅度递减。低思考强度下得分约为 53%，每道题成本约 $0.30；最高思考强度下得分约为 61%，成本约 $2.23；提升到最高强度的最后一步仅增加约半个百分点的得分，却要多付出 46% 的成本。这一增益落在该基准测试多次运行之间的正常波动范围内，因此你多付了钱却得不到可衡量的收益。

图 4. Fable 5 在 FrontierCode Diamond 上不同思考强度下的性能与成本对比。

思考强度可能在两个方向上出现校准偏差：

认为越高一定越好。高思考强度可能导致过度思考。Claude 花在斟酌上的时间超过了任务本身所需，这会增加成本和延迟，还可能降低答案质量。只有在仍有证据可挖掘时，深入思考才有帮助。

偏向低思考强度。设置得过低时，Claude 会在掌握足够证据之前就停下来。它发起的工具调用更少，因此可能只依据第一条搜索结果作答，而不是第三条。它在困难步骤上思考得更少，并跳过了它通常会自行运行的检查。答案看起来是完整的，但建立在部分信息之上。

如何修复

有一些实用的方法来校准投入程度（effort）：

用更低的投入程度测试更强的模型。一个低投入的更强模型，可能比一个高投入（高强度思考）的较弱模型更便宜。例如，在 CursorBench 3.2 上，Claude Fable 5.1 在低投入下的表现与 Fable 5 在高投入下的表现相当，但成本仅为后者的三分之一（图 5）。有两个因素使得新模型更便宜：在低投入下，它每个任务所做的工作更少；此外，Fable 5.1 的提示词缓存读取定价为每百万 token $0.25，而 Fable 5 为 $1.00。即使按照 Fable 5 的价格计算，低投入的 Fable 5.1 成本也会低约 40%。

图 5. Fable 5 与 Fable 5.1 在 CursorBench 3.2 上不同投入程度下的表现对比。

了解你的任务形态。在一系列投入程度上衡量应用性能，是理解特定任务成本-性能权衡的有效方法。在一个尚未饱和的评测中，如果不同投入程度下的成本-性能曲线较为平缓，则表明该任务不受思考算力限制；增加投入并不会带来收益。

这种校准通常涉及跨模型和投入程度运行评测。在 Claude Code 中，/claude-api hillclimb 命令可为你执行此搜索：它会将你的评测拆分为训练集和测试集，提出配置更改建议，并读取失败的训练示例以修复其发现的问题。

我们在一个客户支持基准测试上运行了它，从 Opus 4.8 的默认（高）努力程度开始。爬山算法首先尝试了低努力程度的 Opus 5，并应用提示词审计来移除强制性的工具调用惯例、草稿本步骤和相互矛盾的规则。这使 Opus 4.8 的基线在 98.9% 的训练准确率上被超越，并将成本降至每张工单 2.6 美分。

图 6. 爬山算法通过更新模型选择、努力程度和提示词来改善成本与性能。

随后，它降级到低努力程度的 Sonnet 5，成本更低，每张工单仅 1 美分，但准确率降至 88.9%。通过阅读失败的训练工单，Claude 在提示词中添加了路由规则和退款上限交叉引用，使 Sonnet 5 在相同成本下回升至 98.9% 的准确率。

在搜索从未见过的 14 张保留工单上，最终配置的得分为 90.5%，而原始配置为 78.6%，成本约为原来的五分之一。

自动化成本削减

提示词缓存、指令和努力程度是降低成本的常见手段。我们的文档涵盖了更多内容。为了对使用 Claude API 的应用程序代码进行全面的成本审计，我们新增了 /claude-api cost-optimize：它会分析你的支出去向，应用成本削减措施，并且如果你提供了评估，它还会展示节省与性能之间的权衡关系。

成本优化首先从定位你的 token 去向开始：如果你有 Claude Admin API 密钥，就从你组织的用量和成本报告中获取；如果你的应用记录了日志，就从每个 API 响应的 usage 对象中获取；如果两者都不可行，就通过阅读你构建请求的代码并进行估算。

然后，它会按优先级排列可用的节省方案，从提示词缓存开始，再到精简每个请求携带的内容（包括提示词审计）、限制输出长度，以及对无人值守的工作进行批处理。如果你提供了评估，它还会更进一步，计算不同投入水平和模型选择下的成本与性能。

我们在四个公开基准上运行了该功能，以 Sonnet 5 作为基线（图 7）：

LegalBench（成本降低约 58%）：cost-optimize 建议跨任务缓存共享前缀、设置低投入水平，并通过 Batch API 处理任务。思考 token 从 102,779 降至 8,284，但通过率保持在噪声范围内，成本下降了约 58%。

tau2-bench retail（成本降低约 73%）：通过实施带有显式断点放置的提示词缓存，cost-optimize 在保持通过率持平的同时，将支出降低了 73%。

OfficeQA Pro（成本降低约 52%）：cost-optimize 增加了批处理和文档缓存，使成本从 136.20 美元降至 64.87 美元。

SWE-bench Verified（成本降低约 55%）：cost-optimize 发现默认配置已经正确进行了缓存。节省主要来自将投入水平设置为中等，并将智能体的输出限制为仅几句简洁的句子。每个任务的中位步骤数从 29 降至 17，提示词 token 从 75.2M 降至 33.7M。

图 7：使用 /claude-api cost-optimize 后，各基准测试上的成本与性能变化。

快速上手

当你已迁移到前沿 Claude 模型，并希望用其检查现有提示词时，可以从 /claude-api prompt-audit 开始。它会扫描你工作目录中的提示词、技能和工具描述。这些可以是调用 Claude API 的应用程序代码，也可以是 Claude Code 的配置（CLAUDE.md、skills）。它会移除那些会拖累前沿模型的常见反模式。

当你的应用程序使用 Claude API 并希望进行成本审计时，可以使用 /claude-api cost-optimize。它会分析 token 支出，然后测试不同的优化手段：它会应用 prompt-audit，同时也会检查是否可以通过提示词缓存、批量处理无人值守任务或限制输出来降低成本。如果你提供了评估集，它还会衡量工作量和模型选择之间的权衡。

最后，使用 /claude-api hillclimb 在成本与性能之间进行迭代搜索。给定一个评估集，Claude 会将其拆分为训练集和测试集，然后针对你的应用程序提出旨在降低成本同时维持基线性能的更新建议。Claude 会阅读训练集中失败的案例来引导搜索，最终配置会在留出的测试集上进行评分。

了解更多：

查看我们的文档，点击此处

查看我们的示例库，点击此处

‍

视频 · 前往原文观看

用 Claude 变革你组织的运作方式