ClaudeMap

·提示词库

2026 年 Claude 深度推理调参实战——budget_tokens 三条硬规则与摘要式思考计费口径、adaptive thinking 模型支持矩阵（Fable/Mythos 仅 adaptive、5 系默认开启）、effort 五档选型、output_config 位置陷阱、与 prompt caching 的交互，以及迁移决策框架。

Claude Extended Thinking 调参实战：从 budget_tokens 到 adaptive thinking 的迁移（2026）

Extended thinking（扩展思考）是 Claude API 的深度推理机制：模型在给出最终答案前先生成内部思考块，用 token 换正确率。2026 年的关键变化是 adaptive thinking 的引入——在 Claude Sonnet 5 / Opus 5 等新一代模型上，固定 budget_tokens 的手动挡被「模型自己决定想多少」的自适应挡取代，迁移窗口期的兼容性陷阱相当密集。本文基于 2026 年 9 月的 AWS Bedrock 官方文档（Anthropic API 行为一致）整理机制、迁移对照与调参决策。

TL;DR

  • 旧写法：thinking: { type: "enabled", budget_tokens: N }，最低 1024、必须小于 max_tokens
  • 新写法：thinking: { type: "adaptive" } + output_config.effort（low / medium / high / xhigh / max）
  • Fable 5 / Mythos 5 系只支持 adaptive——旧写法直接 400；Opus 4.6 / Sonnet 4.6 上旧写法已标弃用
  • 最大的迁移陷阱：Sonnet 5 / Opus 5 省略 thinking 参数 = 默认开启 adaptive，不改动请求体的应用会多出一笔按输出 token 计费的思考账单
  • effort 必须放在 output_config 里——放进 thinking 对象会直接 ValidationException

机制与账单口径：budget_tokens 到底怎么算

手动挡的开启方式是在请求里加 thinking 对象：

{
  "thinking": {
    "type": "enabled",
    "budget_tokens": 8000
  },
  "max_tokens": 16000
}

三条硬规则：budget_tokens 最低 1,024；它必须小于 max_tokens（thinking 算进输出预算）；唯一例外是 Interleaved thinking（beta）配合工具时，上限放宽到整个上下文窗口（200K）。

账单口径有一个容易踩的细节——摘要式思考（summarized thinking）：Claude 4 系模型的 API 返回的是完整思考过程的摘要，但你按完整思考 token 计费，而不是按摘要的 token 数。所以「响应里 thinking 块看起来不大」和「账单不高」是两回事。

其他必须知道的口径：

  • 流式要求：max_tokens 大于 21,333 时必须用流式响应。
  • 参数互斥：thinking 与 temperature / top_p / top_k 修改、强制工具调用（forced tool use）不兼容；thinking 开启时也不能 prefill 助手回复。
  • 历史思考块不用你清理：API 自动忽略上一轮的 thinking 块，且不计入上下文用量。

2026 转向：adaptive thinking 是什么

Adaptive thinking 让模型按每个请求的复杂度自己决定是否思考、思考多少，不再需要固定预算。官方的表述很直接：adaptive 的表现稳定优于固定 budget_tokens 的手动挡，且不需要 beta header。

模型支持矩阵（Bedrock 文档口径，2026-09）：

| 模型 | adaptive | 手动 extended thinking（budget_tokens） | 说明 | |---|---|---|---| | Fable 5.1 / Mythos 5.1 / Mythos 5 / Fable 5 / Mythos Preview | ✅ 唯一选项 | ❌ 400 | 只支持 adaptive，连 disabled 都不行 | | Opus 5 / Sonnet 5 | ✅（默认开启） | ❌ ValidationException | disabled 需显式声明；Opus 5 的 disabled 下 effort 上限 high | | Opus 4.7 | ✅ | ❌ 400 | 支持 adaptive + disabled | | Opus 4.6 / Sonnet 4.6 | ✅ | ⚠️ 已弃用 | 旧写法可用但将在未来模型版本移除 | | Sonnet 4.5 / Opus 4.5 及更早 | ❌ | ✅ | 只支持手动挡 |

迁移对照：三种写法一张表

// 旧：手动 extended thinking（Sonnet 4.5 及更早）
{ "thinking": { "type": "enabled", "budget_tokens": 8000 } }

// 新：adaptive + effort（5 系 / 4.6+）
{ "thinking": { "type": "adaptive" }, "output_config": { "effort": "high" } }

// 新：彻底关掉思考（仅 5 系 / Opus 4.7）
{ "thinking": { "type": "disabled" } }

三个迁移陷阱，按踩坑概率排序：

陷阱 1：Sonnet 5 / Opus 5 上「什么都不传」= 思考默认开启。 这是官方文档专门加粗的行为变更：4.6 时代省略 thinking 字段跑的是「无思考」，5 系同样的请求体会跑 adaptive 并把思考 token 按输出计费。直接换模型 ID 的应用，账单与延迟会无预警上涨。反过来，「用预算表达不思考」（budget_tokens 设很小）在 Sonnet 5 上直接 ValidationException——想关思考只有显式 disabled 一条路。max_tokens 也要重新校准：它是「思考 + 回答」的总硬顶。

陷阱 2：effort 放错了对象。 effort 必须放在独立的 output_config 对象里，塞进 thinking 对象会 ValidationException——两个对象长得太像，这是迁移代码里最高频的手滑。

陷阱 3：对 4.6 继续写 budget_tokens。 不报错（弃用期兼容），但技术债：未来模型版本移除时就是一次线上事故。4.6 的迁移没有成本，建议随本次一起改。

effort 五档怎么选

| 档位 | 行为 | 可用模型 | |---|---|---| | max | 总是思考，不设深度上限 | 仅 Opus 4.6 / Sonnet 4.6 / Opus 5 | | xhigh | 总是思考 + 加深 | 仅 Opus 5 / Opus 4.6 | | high（默认） | 总是思考，复杂任务深度推理 | 全部 adaptive 模型 | | medium | 适度思考，极简问题可能跳过 | 全部 | | low | 最小化思考，简单任务直接跳过 | 全部 |

选型的经验法则：默认 high，按成本与延迟降档。low / medium 的价值在于「模型可以跳过」——对客服分类这类简单任务，跳过思考本身就是收益。max / xhigh 是稀缺能力，留给数学证明、复杂调试、深度分析这类真的需要的地方；注意 Opus 5 在 disabled 状态下 effort 会被强制压到 high。

另一个隐性收益：adaptive 模式自动启用 Interleaved thinking（beta）——模型可以在多次工具调用之间穿插思考，这对 agent 工作流是实打实的增强（不再是一次性预算被工具调用切碎）。

与 prompt caching 的交互

思考参数与缓存的关系在缓存深度指南里讲过一版，这里按 adaptive 语境更新：

  • 改 thinking 参数会击穿 messages 前缀缓存——缓存键包含 thinking 配置。同一会话内保持 thinking 配置稳定，或把缓存断点设计在 system / 工具定义层。
  • system prompt 与工具定义的缓存不受 thinking 参数变化影响，可放心独立缓存。
  • 省钱的正确组合拳依旧是：稳定前缀 + cache_control + 按任务档位选 effort，而不是反复横跳 thinking 配置。

决策框架：何时开、开多大

按官方使用建议 + 实践归纳：

  • 值得开：多步数学、代码架构决策、复杂 debug、长链路分析——凡是「中间步骤错了答案必错」的任务。
  • 不值得开：格式转换、分类打标、简单改写——思考只会加延迟加钱，low 档让它自己跳过。
  • agent 场景默认开：interleaved thinking 让工具调用之间的推理免费升级，除非你的任务是纯机械操作。
  • 不确定就从 high 起步，观察任务成功率与单位成本后再降档——降档的收益立竿见影，升档的收益取决于任务难度分布。

相关指南

常见问题

budget_tokens 的最小值是多少？和 max_tokens 什么关系？

最低 1,024，且必须小于 max_tokens——thinking 计入输出预算。唯一例外是 Interleaved thinking（beta）配合工具时，上限放宽到整个 200K 上下文窗口。预算在 32K 以上时收益递减，模型经常用不满。

哪些模型只支持 adaptive thinking？用旧写法会怎样？

Claude Fable 5.1、Mythos 5.1、Mythos 5、Fable 5、Mythos Preview 只支持 adaptive——thinking.type: "enabled" 或 "disabled" 都返回 400。Opus 4.7 支持 adaptive + disabled（手动挡 400）；Opus 4.6 / Sonnet 4.6 的手动挡已弃用；Sonnet 4.5 及更早只支持手动挡。

为什么迁移到 Claude Sonnet 5 之后账单变高了？

Sonnet 5 / Opus 5 上省略 thinking 参数等于默认开启 adaptive thinking——这与 Sonnet 4.6「省略即不思考」的行为相反，迁移应用会在请求体不变的情况下多出按输出 token 计费的思考成本。要关掉必须显式传 thinking: { type: "disabled" }，同时重新校准 max_tokens。

effort 参数应该放在请求的哪个字段里？

放在独立的 output_config 对象里（如 output_config: { effort: "high" }），不能放进 thinking 对象——放错位置会返回 ValidationException。这是迁移代码里最常见的错误。

改 thinking 参数会让 prompt cache 失效吗？

会击穿包含 messages 的前缀缓存（缓存键含 thinking 配置），但 system prompt 与工具定义的缓存不受影响。工程上的对策：同一会话保持 thinking 配置稳定，缓存断点尽量设计在 system / 工具层。

extended thinking 能和 temperature 或强制工具调用一起用吗？

不能。thinking 与 temperature / top_p / top_k 修改及强制工具调用不兼容，thinking 开启时也不能 prefill 助手回复。Agent 场景的补偿是 adaptive 模式自动启用 Interleaved thinking（beta）——模型可在多次工具调用之间穿插思考。

官方参考资料

本文基于截至 2026 年 9 月 3 日的 AWS Bedrock 官方文档整理（Anthropic API 行为一致）；adaptive thinking 仍在快速演进，以官方文档为准。