最近我在搭一套智能文档分析流程时做了一组对比测试同一个问题分别发给普通模式的模型和开启了Extended Thinking的模型。结果有点出乎意料——普通模式不仅解题过程简略还在中间一步漏掉了关键条件开了Extended Thinking后模型先复述了一遍问题约束写下两种可能的解法把其中一条明显错误的方向排除掉才给出最终答案。这就是Extended Thinking最直观的价值让Claude在输出最终回答之前先进行一次可控长度、可观测的深度思考。它把过去只能靠提示词暗示的思维链变成了API里一个显式的配置项开发者可以给思考过程分配专门的token预算模型会在预算内展开草稿、做自我检查、尝试备选路径然后再生成精炼的正式回答。对做AI应用开发、Prompt工程、复杂任务自动化的朋友来说这个功能几乎属于必装项值得花点时间搞明白。1. Extended Thinking到底解决了什么问题1.1 一句话理解这个功能把模型的最终回答想象成一份答卷。普通模式是拿到题提笔就写写到一半发现思路不对只能硬着头皮改Extended Thinking则要求模型先打草稿——在草稿纸上列条件、做演算、试错、检查确认逻辑闭环了再工整地把答案誊到答题区。草稿不会被直接展示给用户但它消耗纸张和时间对应到API里就是token预算和响应延迟。这正是Extended Thinking的核心设计把推理过程和最终输出彻底拆开让推理成为独立的、有预算约束的、可以被程序读取的中间产物。1.2 普通思维链提示的问题在哪很多人之前会在系统提示里写Lets think step by step试图让模型逐步推理。这个土办法确实有效但它有几个绕不过去的短板第一推理和最终回答混在同一段文本里。模型一边推理一边组织语言它的注意力要在想和写之间来回切换一旦最终答案需要非常精炼推理过程很容易被压缩成几句口号式的分析。第二思考长度完全不可控。你没法告诉模型这道题最多想2000个token想完就停。结果就是简单的题目它也可能长篇大论复杂的题它可能两三句就跳到结论。第三也是最隐蔽的问题模型可能在输出时才临时编造一套推理来合理化答案它并不真的在回答前进行推理。这种先有结论再补解释的现象会让用户误以为结论已经经过了逻辑验证实际上没有。Extended Thinking用工程手段解决这三个问题推理有独立的位置承载有明确的token预算并且在响应结构上保证它先于最终答案产生。它至少让思考过程这件事变得可以观测、可以控制、可以审查。2. Extended Thinking的核心机制推理Token、预算与签名2.1 从边写边想到先想后写开启Extended Thinking后请求会多一组配置。模型先生成一段内部推理内容这段内容对应API响应里的推理块然后基于这段推理再生成最终文本。你拿到响应时能同时看到草稿和正式答案两部分。从工程角度看这相当于把原来一次性的自回归解码拆成了两个阶段推理阶段和答案阶段。推理阶段的token全部计入输出token也按输出价格计费。这就是为什么开启这个功能后账单会明显变贵——它不是免费的魔法而是模型真的多写了一段内容。响应的大致结构长这样不同版本字段名会有差异请以官方最新文档为准{ content: [ { type: thinking, thinking: 复述问题条件……先假设……这里有个陷阱……改用贝叶斯公式……, signature: 一段用于续接的签名 }, { type: text, text: 根据计算最终答案是…… } ] }额外补充一点如果推理内容触发了隐私保护规则API可能会返回一个占位块而不是完整草稿。这属于合规设计不是Bug不能当作模型出故障。2.2 budget_tokens模型能想多久budget_tokens大概是Extended Thinking里最需要理解透的参数。它决定了模型可以生成多少推理token类似草稿纸的张数。预算太小时模型还没把问题想透就得强行收尾效果与普通模式差距不大预算太大模型确实会绕更多的路、做更多的自我检查但代价是响应变慢、成本上升。我的习惯是先给一个保守值跑通再逐步往上加观察答案质量的变化曲线。当预算增加到一定程度后答案质量往往不再提升甚至因为想得太多而出现过度修正——那个拐点就是性价比最高的配置。下面是我常用的预算参考档位任务类型建议预算说明简单问答、分类、提取不使用杀鸡不用牛刀中等数学题、常规代码调试2048-4096足够走完假设-验证-修正复杂代码重构、多步骤推理8192左右需要试错空间长文档综合分析接近上限模型需要先摘录再组织2.3 签名机制与多轮续接一个容易被忽略的细节推理内容不是普通的文本它带有一个签名。签名存在的意义是保证推理链的完整性和连续性类似给一份草稿加了个防伪标记。当你做多轮对话时如果上一轮产生了推理内容下一轮请求必须把上一轮的签名回传否则API会拒绝续接或报签名无效。这其实是一种安全设计——防止有人篡改中间的推理环节来操纵最终输出。实操中常见的报错signature invalid八成就是你在续接时没有正确传递签名。3. 实操在API中开启Extended Thinking的完整步骤3.1 请求配置与最小示例下面是一个最小化的Python示例使用官方SDK开启Extended Thinking字段名以你实际使用的API版本为准import anthropic client anthropic.Anthropic() response client.messages.create( modelclaude-sonnet-4-20250514, max_tokens8192, temperature1.0, thinking{ type: enabled, budget_tokens: 4096 }, messages[ {role: user, content: 你的问题放在这里} ] )注意两个细节第一开启thinking后官方建议把temperature设为1。这个模式下的推理本身已经带有探索性过低的温度会让思考路径变窄过高的温度又容易跑偏。第二max_tokens要同时覆盖推理token和最终答案token。如果你把总输出限制设得太小模型可能推理到一半就被截断最终回答都没生成出来。我见过太多人只把max_tokens设成几百然后来问为什么开了思考模式反而没输出——就是这个原因。3.2 从响应中读取推理内容拿到响应的方式很简单signature None for block in response.content: if block.type thinking: signature block.signature print(推理草稿:, block.thinking) elif block.type text: print(最终回答:, block.text)如果你想拿推理内容做二次分析比如提取关键步骤、做后续任务输入直接存这个块就行。如果遇到的是隐私遮蔽类型的推理块API会在响应中保留占位但你拿不到原始文本这也是为什么产品设计时不要把推理内容当成可依赖的公开数据。3.3 多轮对话时的签名回传续接对话时把上一轮拿到的signature传给下一次请求client.messages.create( modelclaude-sonnet-4-20250514, max_tokens8192, temperature1.0, thinking{ type: enabled, budget_tokens: 4096 }, thinking_signaturesignature, messages[ {role: user, content: 第一轮问题}, {role: assistant, content: 第一轮回答摘要}, {role: user, content: 顺着刚才的思路继续追问} ] )不同版本的SDK对签名参数的位置叫法不一样有的放在thinking配置里有的是顶级参数但逻辑是一致的推理产生了签名就必须跟着走。我不建议你在续接时丢弃上一轮推理内容只在messages里塞一个assistant文本那样会切断推理链模型等于重新开始想。3.4 预算怎么定才合适我推荐一个三分法来定预算先做端到端实测。从一个较低的预算开始跑比如2048。如果答案质量不达标翻倍到4096再跑一次。如果翻倍之后质量提升明显继续加如果提升微弱就停在上一个档位。这种方法比一上来就给大预算更省成本也能帮你找到够用的最小值。另外对延迟敏感的应用预算要往下压。推理token是一步步生成的预算越大首个响应token出现的时间越晚。用户体验要求首字快出的场景该妥协就妥协不要为了追求完美答案牺牲交互等待。4. 实战效果我实测过的三类任务4.1 数学推理一道贝叶斯概率题我用一道经典的贝叶斯题做对比测试有两个盒子A盒中有3枚金币和1枚银币B盒中有1枚金币和3枚银币。随机选一个盒子再从其中随机摸出一枚硬币发现是金币问这枚硬币来自A盒的概率是多少。普通模式下模型直接写出了贝叶斯公式但中间漏掉了先验概率P(A)1/2的显式计算最终给了一个含混的结论。开了Extended Thinking后模型的推理流程明显不同。它先在草稿里复述了问题条件写下了P(A)1/2、P(G|A)3/4、P(G|B)1/4然后分别计算两条路径的联合概率P(A且G) 1/2 × 3/4 3/8 P(B且G) 1/2 × 1/4 1/8归一化之后得到P(A|G) (3/8) / (3/8 1/8) 3/4。关键在于推理块里能看到模型自己写了一句等一下这里需要把两个分支的贡献做归一化不能只看其中一条路径。这种自我纠错的痕迹在普通模式里几乎见不到因为它根本没有空间做这一步。这题比较基础但道理是通用的需要精确公式、多步骤推导、边界条件判断的任务Extended Thinking的收益最明显。4.2 代码排查偶发超时问题的定位我让某开发者用这个功能排查一个偶发的接口超时问题那次的对比让我印象很深。普通模式下模型给出的建议是增加客户端超时时间并加入重试机制。这个建议不算错但完全没有触及问题的核心。开启思考模式后模型的诊断逻辑完全不同。它先列出了一张候选清单网络抖动、客户端重试逻辑缺陷、服务端线程池耗尽、数据库慢查询、网关限流。然后根据给出的日志特征逐项排除——日志里没有数据库慢查询的迹象所以数据库这条先划掉超时发生在固定时间窗口不是随机网络抖动最终锁定了客户端在短窗口内的重复请求触发了服务端限流。这个案例给我的启发是思考模式在诊断类任务里的价值不只在于给出结论更在于输出一条可验证的排除路径。哪怕它最后锁定的原因不够准确这种结构化的推理过程本身对工程师做二次判断也是极有帮助的。4.3 长文档分析收益最大但别指望它消灭幻觉我在多文档综合分析任务上也做了测试。普通模式会快速给出一个概括性的回答但经常把不同文档里的数据混在一起开启Extended Thinking后模型会在推理阶段先摘录各文档的关键信息再判断哪些信息互相矛盾最后才组织答案。整体上看引用准确性和信息归因都上了一个台阶。但有一件事必须泼冷水思考模式不能解决幻觉问题。它能让模型多想一会儿但不能让它想到的全是真的。如果模型本身没有见过相关事实或者文档里根本没有对应信息它照样会在推理里编造一个合理的解释。因此涉及事实性、时效性的场景还是得靠外部检索和验证兜底思考模式只是让错误出现得更少、也更容易被追踪。5. 常见问题与排查技巧实录症状可能原因解决方向推理很长但答案依然是错的推理方向从一开始就跑偏了在系统提示里要求先列出问题约束再做假设最后验证响应延迟明显上升预算过大推理token量太大降低预算或者把任务拆成多个小步骤分别思考响应里根本没有thinking字段版本不支持、参数未生效、字段名有变化确认模型版本检查请求参数查看官方文档的响应格式推理块被截断没有最终答案max_tokens不够推理吃光了全部预算调大max_tokens或调小budget_tokens多轮对话时报告签名无效没有回传上一轮的signature或签名被改动正确传递签名不要修改推理块内容账单明显变贵推理token也按输出token计费简单任务不开启用路由把复杂任务分配进来这里单独讲一个被问得最多的坑模型推理方向跑偏。当你发现它想了一大堆却给出错误答案时不要盲目加大预算那只会让它在错误方向上走得更远。正确做法是在系统提示里加入结构约束例如要求模型推理过程中必须依次完成1. 列出所有已知条件和未知量2. 写出可能的解法并标记最可疑的一个3. 对最终结论做一次反向验证4. 如果发现矛盾回到第2步修正。这种约束能把思考过程拧到正确的轨道上而且它提取出来的结果也更规整方便程序做后续处理。6. 几点实测经验与避坑总结最后分享几个我在实际项目中积累的操作经验。第一个经验是把Extended Thinking当作先遣分析器来用而不是单纯的答题开关。我会先让模型开启思考模式产出一份结构化推理报告把这个报告存下来之后再做总结、问答、生成文档时普通模式直接引用这份报告就够了。这样既拿到了深度的中间产物又不用每次都付出思考模式的成本。第二个经验是关于隐私设计的。推理内容可能包含用户原始输入、模型自身的推测、甚至一些不该展示的中间结论。如果做面向终端用户的产品千万不能把完整推理草稿直接放在界面上。官方API用占位块做隐私遮蔽这个设计本身就是给开发者提个醒思考过程是内部数据不是展示素材。第三个经验是控制预期。Extended Thinking是个好东西但它本质上只改变思考过程的结构不改变模型知识的边界。它不会让模型突然变聪明只是让它更充分地调用已有的能力。你该做检索还是做检索该搭知识库还是搭知识库别指望一个参数解决所有问题。我个人的习惯是在做任何涉及复杂推理的任务时先以普通模式跑一遍拿基线答案再开启Extended Thinking对比一次。如果两次结论一致说明任务足够简单后续就不开思考模式如果两次结论不一致我会重点检查模型的推理链条判断哪一次更靠谱。这个流程虽然多花一次请求但对判断你的任务到底适不适合开思考模式非常有效长期用下来反而省了不少钱。