一、为什么 Extended Thinking 是 Claude 独有的推理范式
不同于 OpenAI o1 把思考过程封装在模型内部、对外黑盒化的设计，Anthropic 的 Extended Thinking 选择显式思考块 方案：模型在生成最终答案前，先输出一段独立的 <thinking> 内容块，把分步推导、分支验证、自我校验的过程透明暴露出来claude.you...。
Opus 5.5 对这套机制做了重大迭代：
-
思考块不再永久占用历史上下文：上一轮的 thinking 块在新一轮对话时，API 默认自动剥离，不计入本轮输入 token；只有当前轮次的思考内容，才会占用上下文窗口配额、参与计费Anthropic。 计算公式：
有效上下文余额 = 输入token（已剔除历史thinking块） + 当前轮思考token + 最终输出token -
引入
effort档位自适应：模型根据任务难度自动分配思考预算，复杂数学、代码调试、长文档校验自动拉高思考 token 上限；简单问答自动减少思考开销，平衡推理质量与成本，这也是 Opus 5.5 相比上一代整体成本下降 40% 的核心原因之一。 -
和原生 Structured Output、Tool Calling 深度打通：思考阶段可以完成工具调用规划、Schema 校验预判，而不是等思考结束后再调用工具，大幅降低多轮 Agent 的轮次延迟。
很多开发者的第一个误区：以为打开 Extended Thinking 只是 "多花一点钱换更高准确率"。真实情况是：思考块是独立的输出 token 计费项，同时会抢占当轮可用 token 预算 。如果你设置了比较小的 max_tokens，大量预算会被思考过程吃掉，最终正式回答直接截断。
二、核心机制：思考块的生命周期与上下文边界
我们把一次带 Extended Thinking 的请求流程拆成 4 步：
- 接收用户消息 + 系统提示词，读取剩余 token 预算；
- 启动思考阶段，流式返回
<thinking>内部推理文本，这部分实时计入输出 token 费用； - 思考完成，模型基于思考结论生成正式回答文本；
- 本轮请求结束；当你把完整消息数组回传给下一轮 API 时，历史 thinking 块会被服务端自动过滤，不会持续堆积占用上下文。
重点坑点：这个自动清理是模型侧 API 行为，不是 SDK 自动处理。如果你自己在聚合平台的中转层手动全量保存、透传历史消息， thinking 块不会被剔除，上下文会持续膨胀，token 消耗会成倍上涨，也是聚合服务商最容易出现账单异常的根源。
对比两种主流推理方案的差异：
表格
| 方案 | 思考过程 | 历史思考是否占用上下文 | 可控性 | 适合场景 |
|---|---|---|---|---|
| Claude Extended Thinking | 显式返回 thinking 块 | 默认自动清理 | 高，可配置最大思考 token | 代码 Agent、科研论证、复杂 RAG 问答 |
| o1 隐式推理 | 内部不可见 | 无独立思考 token | 低 | 快速复杂推理、一次性任务 |
三、API 实战：Opus 5.5 Extended Thinking 最简调用示例
依赖：anthropic SDK >= 0.32.0，Opus 5.5 模型标识
claude-opus-5-5
from anthropic import Anthropic
client = Anthropic(api_key="YOUR_API_KEY")
resp = client.messages.create(
model="claude-opus-5-5",
max_tokens=4096,
thinking={
"type": "enabled",
"budget_tokens": 2048 # 思考阶段最大分配token，不能超过max_tokens
},
messages=[
{"role": "user", "content": "推导动态RAG的召回排序损失函数，并给出工程优化方案"}
]
)
# 遍历返回内容块，区分思考内容和最终回答
for block in resp.content:
if block.type == "thinking":
print("【模型思考过程】")
print(block.thinking)
elif block.type == "text":
print("【最终输出答案】")
print(block.text)
# 打印计费统计
print(f"输入token: {resp.usage.input_tokens}")
print(f"思考token: {resp.usage.thinking_tokens}")
print(f"输出文本token: {resp.usage.output_tokens}")关键参数约束：
budget_tokens必须小于max_tokens；思考预算设置越大，推理深度越强，成本越高；- 思考块支持流式输出，适合做实时展示推理链路的 Agent 产品；
- 当开启
tool_use工具调用时，思考块内可以生成工具调用规划，工具返回结果会送入下一轮思考，形成闭环推理链。
四、MCP 协议联动：Extended Thinking 下一代 Agent 架构
MCP（Model Context Protocol）是 Anthropic 主推的标准化 Agent 扩展协议，也是 2026 年 Claude 生态最大热点Claude。 在 MCP 架构下，Extended Thinking 不再只局限于单次请求内部思考：
- 模型在思考阶段识别需要访问私有数据库、内网服务、本地文件；
- 通过 MCP Tunnel 安全连接内网 MCP Server，不需要对公网开放端口；
- 获取外部资源返回结果后，继续在思考块内融合信息、校验结论；
- 最终输出结构化结果。
这套组合直接解决传统 RAG 的短板：RAG 是先检索再喂给模型；而 MCP+Extended Thinking 是模型在思考过程中自主决定什么时候检索、检索什么、是否需要二次校验，是真正长时序 Agent 的原生方案。
⚠️ 聚合平台接入风险提示：MCP 属于长连接双向交互协议，和普通同步 API 转发逻辑完全不同。如果你的聚合网关只做简单的请求转发，会出现思考流中断、工具回调超时、上下文状态错乱问题。
五、生产落地避坑：聚合平台与 RAG 场景高频问题
坑 1：缓存失效 ------ thinking 块会破坏 Prompt Cache
Claude 的 prompt cache 机制，依靠稳定不变的前缀系统提示词实现降价加速。一旦每次请求携带的 thinking 块内容动态变化，缓存 key 就会失效，缓存命中率暴跌，成本直接上涨。 ✅ 方案：不要把动态思考内容放入缓存前缀；缓存只放静态系统提示词、固定 Schema。
坑 2：多轮 Agent 循环上下文预算失控
很多 Agent 框架无脑循环，不监控剩余 token。虽然历史 thinking 会自动清理，但工具返回的长文本、检索文档会持续堆积。 ✅ 工程方案：实现两层预算控制：
- 每轮请求前计算剩余 token；
- 设置动态压缩策略：当余额低于阈值时，自动摘要历史工具返回结果，只保留关键结论，而不是全量继续传入。
坑 3：结构化输出和思考模式冲突
部分开发者反馈开启 thinking 之后，JSON 输出更容易出现格式错乱。 底层原因：模型在思考阶段优先做逻辑推导，结构化约束权重被降低。 ✅ 方案：优先使用原生 outputFormat JSON Schema 参数，而不是单纯靠 Prompt 约束；必要时缩小思考预算，或者把 JSON 校验放到思考完成之后。
坑 4：计费统计口径差异（聚合平台最头疼）
Anthropic 账单单独统计 thinking_tokens；很多中转计费系统早期没有单独字段，会把思考 token 混入输出 token，造成用户账单和官方账单对不上，对账纠纷。 ✅ 建议：聚合层必须单独透传、存储 thinking_tokens 字段，单独计价，或者提前在产品文档明确说明思考 token 计费规则。
六、选型边界：什么时候开 Extended Thinking，什么时候关掉
✅ 推荐开启：
- 数学证明、复杂代码重构、多文件调试；
- 长文档法律、技术材料深度审核、多方信息交叉校验；
- MCP Agent、自主规划类应用，对推理正确性优先级高于成本。
❌ 建议关闭：
- 简单摘要、翻译、固定模板生成；
- 高并发、低延迟问答接口，成本敏感；
- 短文本分类、关键词提取这类确定性任务。
Sonnet 5 同样支持 Extended Thinking，但它的思考预算上限更低、推理深度弱于 Opus 5.5，适合成本敏感的轻量 Agent 场景。
Extended Thinking 不是一个简单的 "增强推理开关"，它代表 Anthropic 一套完全不同的 Agent 设计思路：把推理过程开放出来，让开发者可以观测、拦截、校验、干预模型思考链路，而不是把推理变成黑盒。
对于大模型聚合平台而言，Opus 5.5 这套机制既是亮点也是难点：它给开发者提供了构建高阶 Agent 的能力，但同时对网关转发、token 记账、上下文管理、MCP 长连接处理提出了远高于普通模型 API 的工程要求。理解思考块的生命周期、计费规则和上下文边界，才能在保证效果的前提下，控制成本，规避线上故障。