引导思考

Claude 的思考是自适应的：模型会评估每个请求，并自行决定是否思考以及思考多少。您设定意图，可选地指定努力程度，模型会在它判断推理有帮助的地方分配推理。

这使得思考非常适合混合了简单和复杂请求的工作负载，以及正确推理量因步骤而异的长周期智能体工作流。

关于如何开启思考、如何读取思考输出，以及 Claude Fable 5 和 Claude Mythos 5 上的思考输出，请参阅思考概述。本页介绍 Claude 如何决定何时思考、如何引导该决定，以及由此产生的缓存、成本和定价机制。



Claude 如何决定何时思考

对模型而言，思考是可选的。在每个请求中，Claude 会权衡输入的复杂性，并决定更深入的推理是否会改善答案。一个简单的事实性问题可能会得到完全没有思考块的直接回应；一个多步骤的数学问题或棘手的调试任务则会触发更深入的推理。

这个决定是按请求进行的。同一个对话可以包含有思考和没有思考的轮次，而 Claude 选择不思考的轮次不包含思考块。不要构建假设每个助手轮次都以思考块开头的应用程序逻辑。

对这一决定的主要控制是 effort（努力程度）参数，它作为软性指导，决定 Claude 应该多愿意思考以及思考多深；关于每个级别的作用，请参阅本页的努力程度级别。

如果您希望 Claude 减少思考频率，请先降低努力程度级别，然后再考虑基于提示的引导。

思考还会自动与工具使用交错进行：Claude 可以在工具调用之间思考，在决定下一步做什么之前反思每个工具结果（交错思考）。您不需要 beta 标头或任何额外配置即可实现这一点。

关于思考配置和 effort 参数如何交互的完整说明，请参阅思考与努力程度。



引导 Claude 思考的频率

Claude 在给定轮次是否思考是可以通过提示控制的。努力程度设定了整体姿态，但您也可以通过自然语言指导直接塑造这一决定，既可以在系统提示中全局设置，也可以在用户轮次中逐消息设置。

按以下顺序结合使用这两个杠杆：

1. 设置与您工作负载的质量和延迟默认平衡相匹配的努力程度级别。
2. 仅当 Claude 在该级别下的触发行为仍不符合您的需求时，才添加提示指导。

关于思考的更广泛提示指导，请参阅利用思考和交错思考能力。



努力程度级别

努力程度是引导思考的主要杠杆。每个级别为 Claude 思考的频率和深度设置了不同的默认值：

此表描述了每个级别如何改变思考行为。关于为给定工作负载选择哪个级别的指导（包括按模型的建议），请参阅努力程度页面上的何时调整 effort 参数。

努力程度在 output_config.effort 中设置，而不是在 thinking 对象内部；有关各语言的完整示例，请参阅 Effort。

{
  "model": "claude-opus-4-8",
  "max_tokens": 4096,
  "output_config": { "effort": "medium" },
  "messages": [{ "role": "user", "content": "..." }]
}

级别的可用性因模型而异；努力程度页面上的努力程度可用性表是每个模型支持哪些级别的权威来源。



系统提示指导

系统提示指导会改变对话中每个请求的 Claude 思考阈值。如果 Claude 思考的频率超过了您工作负载的需要，请在系统提示中添加如下指导：

Extended thinking adds latency and should only be used when it
will meaningfully improve answer quality, typically for problems
that require multistep reasoning. When in doubt, respond directly.

要鼓励思考，请使用类似这样的措辞：

This task involves multistep reasoning. Think carefully before responding.

引导的有效性可能对确切措辞很敏感。如果某种措辞没有产生您想要的行为，请尝试更直接的变体。



逐消息引导

您还可以从用户轮次逐消息地引导思考，独立于系统提示。在用户消息后附加 "Please think hard before responding." 会鼓励 Claude 在该轮次思考；"Answer directly without deliberating." 则会抑制思考。

当对话中只有部分请求需要扩展推理时，逐消息引导很有用。例如，智能体框架可以在规划步骤上附加鼓励性措辞，在常规确认上附加抑制性措辞，而无需触及系统提示或在轮次之间更改任何请求参数。



在您的工作负载上验证引导效果

基于提示的引导会改变模型行为，因此请像对待任何其他提示更改一样对待它：在发布之前进行测量。使用和不使用该指导运行您流量的代表性样本，并比较思考触发的频率（响应中思考块的存在）、输出令牌使用量、延迟以及对您重要的案例的答案质量。



机制

Claude 自行管理思考会带来三个机制：轮次验证、提示缓存以及如何限制成本。



轮次验证

助手轮次不需要以思考块开头。（使用传统手动思考预算的模型会强制要求启用思考的请求的最后一个助手轮次以思考块开头；请参阅手动模式下的轮次结构。）

对于多轮应用程序，这意味着您可以按现有的任何形式传回对话历史：

• Claude 选择不思考的助手轮次本身就是有效的历史记录。
• 您可以恢复一个开始时没有思考、或使用了不同思考配置的对话，而无需重写其历史记录。
• 从混合来源组装的历史记录不需要在每个助手轮次的开头重新插入思考块即可通过验证。

这种放宽是关于验证的，而不是关于您应该发送什么。当您有思考块时，请原封不动地传回它们，特别是在工具使用期间，因为它们承载着 Claude 工具调用背后的推理。完整规则请参阅思考概述。



提示缓存

保持相同思考配置和努力程度级别的连续请求会保留提示缓存；完整规则请参阅思考与提示缓存。解析后的努力程度值会被渲染到提示中，因此在请求之间更改它会使缓存断点失效，就像在使用传统 budget_tokens 参数的模型上更改该参数一样。将 effort 显式设置为模型的默认值等同于省略它，不会破坏缓存。

实际的结论是：为每个对话选择一个思考配置和一个努力程度级别并保持不变。如果某些轮次需要更多或更少的思考，请使用逐消息提示进行引导：附加到最新用户消息的指导会保持较早的缓存断点完好无损，而配置或努力程度的更改则不会。

以下示例通过一个您可以自己运行的多轮脚本演示了这种失效：



成本控制

您不需要设置思考令牌预算。有两个控制手段来限制成本：

• max_tokens 是对请求总输出（思考和响应文本的总和）的硬性上限。Claude 永远不会生成超过它的内容。在工具使用循环中，该轮次中的每个请求都有自己的 max_tokens，因此它不会限制整个轮次的开销。
• effort 是关于 Claude 将多少输出分配给思考的软性指导。它塑造行为，但不保证令牌数量。

由于思考计入 max_tokens，请将其设置得足够高，以便为推理和答案都留出空间。为没有思考的响应设定的 max_tokens 大小，在 Claude 开始对困难请求进行思考后往往会太小。

在 high 及以上的努力程度下，Claude 可能会进行大量思考，更有可能耗尽预算。如果您在响应中看到 stop_reason: "max_tokens"，您有两种补救措施：

• 提高 max_tokens，为模型的思考和答案提供更多空间。
• 降低努力程度级别，使 Claude 减少思考，为响应文本留出更多预算。

哪种方式合适取决于被截断的响应是否需要那些推理。如果这些请求的质量很重要，请提高上限；如果它们是过度思考，请降低努力程度。



定价

思考会产生以下费用：

• Claude 思考时使用的令牌（按输出令牌计费）
• 根据保留默认值，保留在上下文中的先前助手轮次的思考块：在保留全部的模型上默认为所有轮次，在其他模型上仅为最后一个轮次（按输入令牌计费）
• 标准文本输出令牌

无论 display 设置如何，您的计费内容都是相同的；只有您看到的内容会发生变化：

要查看有多少计费输出令牌用于内部推理，请读取响应中的 usage.output_tokens_details.thinking_tokens。此值反映模型生成的原始推理（而不是正文中返回的摘要文本），并且始终小于或等于 output_tokens。从 output_tokens 中减去它可以近似得出输出中非推理的部分。在流式传输时，此细分仅出现在最后的 message_delta 事件中。

{
  "usage": {
    "input_tokens": 25,
    "output_tokens": 348,
    "output_tokens_details": {
      "thinking_tokens": 312
    }
  }
}

output_tokens 仍然是用于计费的包含性、权威性总数。output_tokens_details 是用于可观测性的只读细分。有关包括基础费率、缓存写入、缓存命中和输出令牌在内的完整定价信息，请参阅定价。



后续步骤