推理模型与思考预算

一句话理解：推理（思考）就是让模型在给出答案前先生成一段中间推理；它用更多的 Token、时间和金钱，换取复杂任务上的更高质量，所以“想多深”应该是按任务调节的产品参数。

上一课你已经看到 effort 这个参数。很多团队的第一反应是：既然思考能提升质量，那就全部开到最高。结果是客服回复慢了好几倍、账单翻了几番，而简单问题的质量几乎没变。另一些团队则相反，为了省钱关掉思考，然后在销售下滑归因这种多步骤任务上频繁出错。

这一课讲清楚三件事：思考为什么有用、它的代价在哪里、以及在 Claude 和 OpenAI 的 API 里如何控制它。

为什么“多想一会儿”会更准

回忆 LLM 如何工作：模型每生成一个 Token 都要做一次完整计算。直接回答时，模型必须在很少的 Token 里“一步到位”；如果先写出中间推理，每个中间 Token 都是一次额外的计算，也成为后续推理可以参考的“草稿纸”。

以销售分析为例，问题是“为什么上周华东区销售额下降了 18%”：

图 1 · 直接回答 vs 先打草稿：中间 Token 就是额外的“计算量”

所谓 推理模型 或 扩展思考，就是把这种“先打草稿”的能力通过训练变成模型的默认工作方式，并由 API 提供开关和深度控制。思考内容通常在单独的内容块里返回（或只返回摘要），不直接混入最终回答。

需要强调的是：思考提高的是“得出正确答案的概率”，不是正确性的保证。 思考过程本身也可能出错，所以它不能替代工具查询和程序验证。

代价：Token、延迟与成本

思考不是免费的，代价体现在三处：

维度	影响	产品含义
成本	思考 Token 按输出 Token 计费，而输出单价通常是输入的数倍	同样的任务，高思考深度可能贵好几倍
延迟	思考要先生成完才开始写答案，首字等待时间明显变长	实时对话场景要格外谨慎
长度上限	思考计入 `max_tokens` 和上下文窗口	`max_tokens` 设小了，可能思考完就没空间写答案

有两个经常被忽略的细节（以 Claude 官方文档为准）：

看到的不等于付费的。 Claude 可以设置 display: "summarized" 返回思考摘要，或 "omitted" 不返回思考文本，但无论哪种设置，计费都按模型内部实际生成的完整思考 Token 计算。可以从 usage.output_tokens_details.thinking_tokens 读取思考部分的用量。
修改思考配置会影响缓存。 同一会话中改变顶层的思考配置或 effort 等级，会让已缓存的前缀失效。官方建议每个会话选定一个等级并保持不变。

OpenAI 的推理模型同样如此：推理 Token 占用上下文、按输出 Token 计费，数量在 usage.output_tokens_details.reasoning_tokens 中；官方建议刚开始实验时为推理和输出预留至少 25,000 Token 的 max_output_tokens。

其中长度上限最容易踩坑，下图展示思考和回答如何共用 max_tokens：

图 2 · 思考预算：思考和回答共用 max_tokens，且思考按输出 Token 计费

在 API 里如何控制

Claude：自适应思考 + effort。 当前一代 Claude 模型使用“自适应思考”：模型针对每个请求自己判断要不要思考、想多深，你通过 output_config.effort 设定整体倾向。在 Claude Opus 5 上，自适应思考默认开启，不传 thinking 参数也会思考；旧的 budget_tokens 固定预算方式在新模型上已不再接受。

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,  # 硬上限：思考 + 回答合计，开启深度思考时要留足
    thinking={"type": "adaptive", "display": "summarized"},  # 返回思考摘要，便于调试
    output_config={"effort": "medium"},
    messages=[{"role": "user", "content": "根据以下周报数据，分析华东区销售下降的原因：……"}],
)

for block in response.content:
    if block.type == "thinking":
        print("[思考摘要]", block.thinking)
    elif block.type == "text":
        print(block.text)

官方对各等级的描述大致如下（不同模型支持的等级不完全相同，以文档的支持表为准）：

effort	思考行为	典型场景
`low`	尽量少想，简单任务直接回答	分类、抽取、子 Agent、高并发低延迟
`medium`	适度思考，简单问题可能跳过	兼顾速度、成本与质量的一般任务
`high`（默认）	几乎总会思考，复杂任务深入推理	复杂推理、困难代码、Agent 任务
`xhigh`	总是深入思考并充分探索	长时间运行的编码与 Agent 任务
`max`	不限制思考深度	最难的问题，且质量比成本更重要

effort 影响的不只是思考：官方说明它作用于全部输出 Token。等级较低时，模型倾向于更少、更合并的工具调用，说明也更简短；等级较高时，会调用更多工具、先解释计划再行动。这对 Agent 的行为风格影响很大。

OpenAI：reasoning.effort。 Responses API 通过 reasoning 参数控制，可选值依模型而定（文档中列出过 none、minimal、low、medium、high、xhigh、max 等），还可以用 summary 请求推理摘要：

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6-astra",  # 模型名与支持的 effort 取值以官方文档为准
    reasoning={"effort": "low", "summary": "auto"},
    input=[{"role": "user", "content": "判断这条客户留言属于哪类工单：……"}],
)
print(response.output_text)

什么时候值得多想

把任务按“是否需要多步推导”和“出错代价”两个维度分类：

任务	例子	建议
简单转换	翻译、改写、格式化、从邮件里抽取字段	`low`，配合结构化输出
简单判断	工单分类、情绪识别、是否属于退款请求	`low` 或 `medium`
多步分析	订单异常根因、销售下滑归因、SEO 流量下跌诊断	`high` 起步
规划与编码	Coding Agent 修复跨文件 Bug、制定多步执行计划	`high` 或 `xhigh`
实时交互	语音客服、输入联想	优先低延迟，必要时拆成异步任务

在 Agent 里，更好的做法往往是 按步骤路由思考深度：规划和最终诊断用高等级，读取数据、格式化输出这类步骤用低等级或交给更小的模型（见模型选型与路由）。以「订单售后诊断 Agent」为例：

图 3 · 按步骤路由思考深度：只在真正需要推理的步骤用高等级

怎么定等级？不要凭感觉，用评测集做一次“effort 扫描”：同一批用例分别在 low、medium、high 下跑，比较正确率、平均耗时和单任务成本，选“质量不再明显提升”的那一档。方法见 Evals 评估体系。

常见误区

“思考开到最高，质量一定最好。” 对很多简单或结构化任务，高等级带来的是更慢、更贵，甚至“想太多”，质量提升很小。
“看到了思考过程，就能确认结论可靠。” 思考文本是摘要或模型生成的推理，不是可审计的证据。可靠性要靠工具数据与外部验证。
“关掉思考、把 max_tokens 调小就能控制成本。” 在复杂任务上这往往导致错误和重试，总成本反而上升。先降 effort，再用评测确认质量。

产品经理检查清单

这个功能里，哪些步骤真正需要多步推理？哪些只是抽取、分类或格式化？
每个步骤的思考深度是怎么定的？有没有评测数据支撑？
用户能接受的首字延迟和总耗时是多少？高等级思考是否需要配合进度展示或改为异步？
max_tokens 是否为思考留出了足够空间？被截断时如何处理？
是否向用户展示思考摘要？展示的目的是什么（透明、等待体验，还是调试）？

练习

做一次小型 effort 对比实验（约 60 分钟）：

准备 6 个任务：2 个简单抽取（从订单邮件中提取收件人和地址）、2 个分类（判断客服留言类型）、2 个多步分析（根据给定的订单与发货记录判断问题原因）。
每个任务分别用 low 和 high 各跑 2 次，记录答案是否正确、输出 Token（含思考 Token）和耗时。
整理成表格，写出结论：哪类任务值得用高等级，成本和延迟分别增加了多少。

下一步

模型想清楚之后，还得把结论交给下游系统。下一课「结构化输出」讲如何让模型稳定地输出可被程序直接使用的 JSON。

推理模型与思考预算