#大语言模型 Adaptive Thinking：从“会思考”到“知道该想多久”

一句话核心结论： 现在所谓 Adaptive Thinking，本质上是在解决一个新瓶颈：模型不只是要“会长 CoT 推理”，还要能根据问题难度、用户预算和风险程度，决定 要不要想、想多久、在哪里停、是否需要再想一遍。目前工业界多用“训练出会深度推理的模型 + API 暴露 effort/budget/开关”；学术界则在补上更细粒度的预算控制、自适应停止、路由、蒸馏和评价体系。

这篇文章回答三个问题：

1. 现在大语言模型 Adaptive Thinking 的一般做法是什么？
2. 可以切换 think / no think 的模型到底怎么做出来？是训练出来，还是推理时控制？
3. 这个方向有哪些研究点？进展如何？

#1. 先说人话：Adaptive Thinking 到底是什么？

最早的 LLM 像一个“看到题就直接答”的学生。后来 Chain-of-Thought、o1/R1 这类 reasoning model 出现后，它开始像一个“先在草稿纸上推导再答题”的学生。

但新问题来了：

• 简单问题也写一大堆草稿，慢、贵、啰嗦；
• 难题有时草稿还不够，想得不够深；
• 有些任务需要严谨推理，有些任务只需要快速响应；
• 用户、应用、系统都有不同预算：低延迟客服、代码 agent、数学证明、医疗问答，不能用同一个思考长度。

所以 Adaptive Thinking 想做的是：

输入问题
  -> 判断难度 / 风险 / 不确定性 / 用户预算
  -> 选择推理模式：不想、少想、中等想、深想
  -> 生成内部 reasoning trace 或 latent computation
  -> 在合适时机停止、压缩、校验或继续
  -> 输出最终答案

换句话说，过去的关键是 test-time scaling：给模型更多测试时计算；现在的关键是 adaptive test-time scaling：把计算花在值得花的地方。

#2. 现在工业界的一般做法：把“思考强度”变成可调旋钮

目前主流闭源/开放模型已经把“思考”做成了产品级接口。不同厂商名字不同，但抽象非常接近：

这些接口有两个共同点：

1. 它们通常不是普通 prompt trick。 背后需要模型在训练阶段见过 reasoning trace、不同长度推理、指令遵循、模式标记或预算条件。
2. 它们也不是纯训练。 最终用户能调节预算，通常还依赖推理时的解码策略、token 上限、特殊模板、隐藏 thinking 通道、服务端路由或控制器。

可以把工业界做法概括成三层：

能力层：模型通过 RL / SFT / 蒸馏学会长推理
控制层：模型学会听懂“多想/少想/不想”的条件或特殊 token
产品层：API 把控制包装成 reasoning_effort / thinkingBudget / /think 开关

#3. think / no-think 开关到底怎么做出来？

这个问题可以拆成三个层次。

#3.1 最低配：提示词开关，但不可靠

最简单的方法是在 prompt 里写：

Think step by step.

或者：

Answer directly. Do not reason step by step.

这对普通模型也有用，但它不是严格可控：模型可能仍然过度解释，也可能在难题上不够推理。它更像“提醒学生做草稿”，而不是“给学生装了一个可调节思考引擎”。

#3.2 中配：聊天模板 / 特殊 token / 分离 reasoning 通道

更真实的 think/no-think 模式一般会在模板或输出协议里分离两类内容：

<think>
  内部推理过程……
</think>
最终答案……

或者 API 结构里分开：

{
  "reasoning_content": "内部 CoT",
  "content": "最终答案"
}

Qwen3 的做法很典型：它在 tokenizer/chat template 里提供 enable_thinking=True/False，并支持 /think 和 /no_think 这样的软开关。DeepSeek Reasoner 则把 reasoning_content 和最终 content 分开返回。

这里的关键不只是模板，而是：模型在训练数据和后训练阶段要反复见到“先 reasoning、再 answer”的格式，以及“不需要 reasoning 时直接答”的格式。否则模板只是外壳。

#3.3 高配：预算条件训练 + 推理时控制

更强的做法是让模型不仅知道“think or not”，还知道“think how much”。例如：

• 给模型输入一个预算条件：low / medium / high；
• 训练不同预算下的 reasoning trace；
• 或用 RL 让模型在准确率和 token 成本之间优化；
• 推理时通过 decoding、停止规则或控制器让它尽量贴合预算。

这就是 OpenAI / Claude / Gemini 暴露 effort、budget_tokens、thinkingBudget 的直觉来源。具体内部配方闭源，但从开放研究看，常见构件包括：

长推理能力：RL on verifiable tasks / SFT reasoning traces / distillation
预算可控性：budget tags / mode tokens / preference data / budget-aware RL
推理约束：max tokens / stop token / forced continue / controller / router
输出封装：隐藏或显示 thinking trace，最终只给 answer

所以，“能切换 think/no-think”通常是 训练出来的能力 + 推理时协议控制 的组合，而不是二选一。

#4. Adaptive Thinking 的方法谱系

#4.1 第一类：固定档位控制 —— low / medium / high

这是产品上最容易用的形态。用户或上层系统选择一个档位：

简单问答 -> low / no thinking
复杂数学 -> high
代码重构 -> medium/high
安全敏感 -> high + verify

优点是工程简单、可预期、容易计费。缺点是它还不是真正的“自适应”：选择档位的人可能是用户或应用开发者，而不是模型自己。

代表趋势：OpenAI 的 reasoning_effort、Gemini 的 thinkingLevel、Claude 的 effort，以及 ThinkDial 这类开放配方都在做离散 reasoning regimes。

#4.2 第二类：数值预算控制 —— 给模型 N 个 thinking tokens

这类方法把思考看成一种 token 预算：

thinkingBudget = 0      -> 尽量不想
thinkingBudget = 1024   -> 想一小段
thinkingBudget = 8192   -> 深度推理
thinkingBudget = -1     -> 动态自适应

Gemini 2.5 的 thinkingBudget、Claude manual extended thinking 的 budget_tokens 属于这种产品形态。学术上也有一批工作研究如何让 reasoning trace 贴近给定预算，而不是一味越长越好。

难点是：预算不是越长越好。 太短会 underthinking，太长会 overthinking、跑偏、重复、成本爆炸。真正有价值的是“在预算内尽量把关键不确定性想清楚”。

#4.3 第三类：Budget Forcing —— 模型想停时强迫它再想一会儿

s1: Simple test-time scaling 是一个很有代表性的开放工作。它做了两件简单但有启发的事：

1. 用 1000 条高质量 reasoning trace 微调 Qwen2.5-32B-Instruct；
2. 在推理时做 budget forcing：

- 如果模型太早结束思考，就把结束标记替换成 Wait，让它继续检查；

- 如果超过预算，就强行截断 reasoning。

这个方法说明一个重要事实：reasoning model 的一部分能力可以通过很简单的测试时干预被“挤出来”。

但它也有明显局限：Wait 是硬插入，不知道哪里该继续、哪里该停；继续想有时会修正错误，有时会制造新错误。

后续工作如 “Learning a Continue-Thinking Token” 进一步问：能不能学一个专门的 <|continue-thinking|> token，比手写 Wait 更自然？他们冻结模型主体，只训练一个 token embedding，并用 RL 让这个 token 更会触发有效继续推理。

#4.4 第四类：软预算引导 —— 在每一步解码时把长度拉向目标

“Steering LLM Thinking with Budget Guidance” 这类工作不直接改大模型，而是引入轻量 predictor，在生成过程中估计“剩余 thinking length”的分布，并用这个信号软性引导 next-token generation。

它解决的是 budget forcing 太粗暴的问题：

硬控制：到点截断 / 不够就 Wait
软控制：每一步都让模型朝目标长度自然收束

这类方法适合已有 reasoning model，不需要重新训练大模型主体，但需要额外控制器和更复杂的解码。

#4.5 第五类：自适应结构搜索 —— Chain / Tree / Graph of Thoughts

另一条路线不是控制单条 CoT 多长，而是控制推理结构：

• Chain-of-Thought：一条链；
• Tree-of-Thought：多条候选分支；
• Graph-of-Thought：子问题之间形成图；
• Adaptive Graph of Thoughts：只扩展值得扩展的节点。

这类方法更像“推理时 planner / search controller”，适合复杂任务、agent、代码调试、多步骤决策。它的 Adaptive 不一定体现在 token 数，而体现在：哪些子问题需要展开、哪些分支应该剪枝、什么时候停止搜索。

#4.6 第六类：隐式/潜空间思考 —— 不一定把草稿写成文字

显式 CoT 的问题是慢，而且会把内部过程暴露成大量 token。于是有一类工作研究：能不能用 latent token、continuous thought、compressed CoT 来做额外计算。

例如 Compressed Chain-of-Thought、token-level adaptive latent CoT 等方向，想把“草稿纸”从自然语言转成更压缩的内部表示：

显式 CoT：一大段自然语言推理，慢但可读
潜空间推理：若干 latent / dense thought token，快但不透明

这和你关心的 latent-space reasoning 很接近：未来的 Adaptive Thinking 不一定是“输出多少文字”，而可能是“在内部状态空间里迭代多少步”。

#5. 训练出来，还是推理时做出来？一个更准确的分解

可以用下面这张表理解：

所以，最准确的回答是：

Adaptive Thinking 不是一个单独技巧，而是一套“后训练 + 条件控制 + 推理时预算分配 + 输出协议”的系统工程。

#6. 代表工作如何串起来？

#6.1 o1 / DeepSeek-R1：先证明“长推理 + RL”能显著提升能力

OpenAI o1 让大家看到：在测试时投入更多内部 reasoning compute，数学、代码、复杂推理会显著变强。DeepSeek-R1/R1-Zero 则进一步公开了一个重要路径：

base model
  -> 大规模 RL 激发 reasoning 行为
  -> cold-start data 改善可读性/稳定性
  -> 继续 RL / SFT 对齐
  -> distill 到小模型

R1-Zero 说明 reasoning 行为可以从 RL 中自然涌现；R1 说明纯 RL 容易出现重复、语言混杂、可读性差，需要 cold-start 和后续对齐。

它推动的问题： 如果模型都会长推理了，下一步就是如何让它不要每次都长推理。

#6.2 s1：用很小数据 + budget forcing 复现 test-time scaling 的一部分

s1 的启发在于它把问题拆得很干净：

• 不一定一开始就要训练巨大模型；
• 只要模型学到高质量 reasoning trace，再用简单推理时控制，就能看到 test-time scaling；
• “继续想”本身是一个可以被干预的动作。

它暴露的问题： 继续想不等于有效想。模型需要知道“为什么继续、继续检查哪里”。

#6.3 Budget Guidance / Continue-Thinking Token：从粗暴控制走向可学习控制

这类工作在回答：

• 不想让模型只靠 Wait 继续；
• 不想靠硬截断破坏 reasoning；
• 能否让预算控制变成更自然的生成动力学？

于是出现了轻量 predictor、learned continue token、budget-conditioned decoding 等方法。

它推动的问题： 预算控制不应只是长度控制，而应是“信息增益控制”。

#6.4 Reasoning on a Budget：从单点技巧走向统一分类

2025 年的 “Reasoning on a Budget: A Survey of Adaptive and Controllable Test-Time Compute in LLMs” 把这个方向概括为 efficient test-time compute，并区分：

• L1 controllability：在固定预算下可控；
• L2 adaptiveness：根据输入难度或模型置信度动态调整预算。

这个区分很重要。很多产品现在其实还停在 L1：用户给档位，模型按档位想。真正更难的是 L2：模型自己知道这题值不值得多想。

#7. 当前研究点：哪些问题还没解决？

#7.1 难度估计：模型怎么知道“这题难不难”？

Adaptive Thinking 的第一步是判断难度。但 LLM 的自我置信度并不可靠：

• 简单题可能过度谨慎；
• 难题可能自信胡说；
• agent 任务的难度要执行后才暴露；
• 代码任务可能前面看似简单，后面依赖环境细节。

研究机会：构造更好的 difficulty predictor、uncertainty estimator、process verifier，让模型在生成前/生成中估计“是否值得多想”。

#7.2 停止规则：什么时候应该停？

现在很多模型的问题不是不会想，而是：

• 想到正确答案后继续想，反而改错；
• 重复检查同一个点；
• 在无关分支上消耗 token；
• 被长 CoT 的惯性拖走。

真正的停止规则应该像这样：

继续思考的期望收益 > 继续思考的成本 + 跑偏风险

但这个量很难估计。它需要 verifier、reward model、self-consistency、工具反馈、甚至环境交互结果。

#7.3 预算分配：不是总预算，而是每一步怎么分

复杂任务不是只有一个“总 thinking budget”。例如代码 agent：

读需求 -> 理解仓库 -> 定位文件 -> 写补丁 -> 跑测试 -> debug -> 总结

每一步都可能需要不同程度的 thinking。一个好的 adaptive system 应该把预算分到最不确定、最影响结果的环节。

这和 model-based RL / agent 长轨迹非常相关：长轨迹里的关键不是“总共思考多少 token”，而是“在哪些决策点值得展开 world model / imagined rollout”。

#7.4 评价指标：只看准确率不够

Adaptive Thinking 的评价至少要同时看：

• accuracy / pass@k；
• token cost；
• latency；
• overthinking rate；
• underthinking rate；
• budget adherence；
• anytime performance：给任意预算都能尽量好；
• calibration：模型说需要深想时是否真的需要；
• robustness：预算变小时是否优雅退化。

现在很多 benchmark 仍然偏数学题和短任务，对 agent 长轨迹、代码仓库级任务、工具调用任务的 adaptive compute 评价还不成熟。

#7.5 隐藏 CoT 与可解释性的矛盾

工业界越来越倾向于隐藏内部 CoT，只返回 summary 或 final answer。一方面这是出于安全、隐私、产品和可控性考虑；另一方面研究者又需要观察 reasoning 过程来诊断模型。

这带来一个张力：

可解释性需要看过程
安全与产品希望隐藏过程
训练和评价又需要知道过程是否真的有效

未来可能会出现更多 process monitor、verifier trace、compressed rationale，而不是完整暴露自然语言 CoT。

#7.6 从文本 CoT 走向 latent reasoning

显式思考的成本太高，尤其对长轨迹 agent。一个自然方向是：把 thinking 从文字 token 转移到 latent state / recurrent computation / memory state。

研究问题包括：

• latent thought 如何训练？
• 如何控制 latent thinking 的步数？
• 如何验证 latent thinking 真的在推理，而不是无效计算？
• latent reasoning 如何和工具调用、外部环境反馈结合？
• 能否把显式 CoT 蒸馏成更短的 latent computation？

这可能是 Adaptive Thinking 与 latent-space reasoning 的交汇点。

#8. 对 LLM Agent 的启发：Adaptive Thinking 不应只发生在单轮问答

如果把 Adaptive Thinking 放到 agent 里，它不只是“回答前想多久”，而是整个控制系统：

任务输入
  -> 是否需要规划？
  -> 是否需要读更多上下文？
  -> 是否需要调用工具？
  -> 是否需要模拟后果？
  -> 是否需要验证？
  -> 是否需要回滚？
  -> 是否可以停止？

这和当前 reasoning model 的 token budget 控制相比，复杂得多。因为 agent 的 compute 不只是 token：还有搜索网页、读文件、跑测试、调用环境、等待外部反馈。

所以对 agent 来说，Adaptive Thinking 应该升级成 Adaptive Deliberation / Adaptive Computation Allocation：

这也是一个很值得研究的方向：长轨迹 agent 的 test-time compute 应该如何分配？

#9. 一个实用分类：当前做法可以分成 7 种

#10. 现在进展如何？

我的判断是：这个方向已经从“能不能让模型长推理”进入了“如何经济地推理”的阶段。

#已经比较成熟的部分

1. 长推理能力本身已经成立。 o1、R1、Claude/Gemini/Qwen 等都证明复杂推理能从额外 test-time compute 中获益。
2. 产品级预算接口已经出现。 reasoning_effort、thinkingBudget、budget_tokens、enable_thinking 等已经成为事实标准。
3. 简单推理时控制有效。 s1 的 budget forcing、continue token 等说明不改大模型主体也能调节 reasoning 行为。
4. 开放模型开始支持 thinking/non-thinking 双模式。 Qwen3 这类模型让研究者能直接实验模式切换。

#仍然不成熟的部分

1. 真正的 L2 自适应还早。 许多系统是用户选档，不是模型自己可靠判断。
2. 预算控制多停留在长度层面。 还没有真正做到按信息增益分配计算。
3. agent 场景严重不足。 大多数工作还是数学/问答，离长轨迹真实任务远。
4. 评价体系不稳定。 token 少但错了、token 多但稳了、延迟增加但 pass@k 提升，怎么综合评价还没有统一答案。
5. CoT 隐藏化让研究诊断变难。 工业模型越来越难观察真实 reasoning process。

#11. 我觉得值得做的研究问题

结合 LLM Agent、model-based RL、latent reasoning，我会优先看这些问题：

#11.1 Agent Adaptive Thinking Benchmark

构造一个 benchmark，不只测单题数学，而测 agent 在多步任务中如何分配思考：

• 哪些步骤需要 planning？
• 哪些步骤需要工具调用？
• 哪些步骤需要 verification？
• 预算有限时应该牺牲哪部分？

可以做代码仓库级任务、网页任务、长上下文 QA、环境交互任务。

#11.2 Decision-Sufficient Thinking

不是问“推理链是否完整”，而是问：

对当前决策来说，哪些思考是 sufficient 的？哪些只是解释性冗余？

这可以连接 context compression：压缩的目标不是保留所有 reasoning，而是保留对后续决策有用的 state。

#11.3 Model-Based Agent Deliberation

把 Adaptive Thinking 和 model-based RL 结合：

当前状态 s
  -> 是否需要 imagined rollout？
  -> rollout 多深？
  -> 哪些分支值得模拟？
  -> 何时用真实工具验证？

这比“多生成一些 CoT token”更接近 agent 的真实智能。

#11.4 Latent Budget Controller

研究如何控制 latent reasoning 的步数和质量：

• 给 latent thought 设置 budget；
• 让模型学会 early stop；
• 用 verifier 判断 latent computation 是否足够；
• 从显式 CoT 蒸馏到 latent trace。

这条线可能比继续堆自然语言 CoT 更有长期价值。

#11.5 Overthinking / Underthinking Diagnostics

系统性诊断什么时候模型过想、什么时候欠想：

• 过想：正确答案被后续推翻、重复检查、跑偏；
• 欠想：关键约束没检查、简单模式匹配、跳步；
• 目标：训练一个 controller 预测“继续想是否有正收益”。

#12. 总结

Adaptive Thinking 的本质不是“让模型多写点 CoT”，而是让模型具备一种元能力：

它要知道自己什么时候该快、什么时候该慢，什么时候该停，什么时候该换一种方式继续。

当前最常见的实现是：

RL/SFT/蒸馏训练出 reasoning model
  + 模式 token / chat template / budget tags 学会 think/no-think
  + 推理时 effort/budget/stop/continue/controller 控制成本
  + API 把它包装成 reasoning_effort、thinkingBudget、enable_thinking 等接口

短期看，研究会集中在 budget-aware reasoning、overthinking 抑制、anytime reasoning、模式可控蒸馏和开放模型复现。长期看，更有基础性的问题是：推理计算应该如何作为一种资源，在长轨迹 agent、潜空间世界模型和持续学习系统中被动态分配。

这也是为什么 Adaptive Thinking 不只是产品功能，而可能是下一阶段 LLM Agent 训练与推理范式的核心问题之一。

#参考线索

• OpenAI API docs: Reasoning models / reasoning_effort。
• Anthropic Claude docs: Extended / Adaptive Thinking, budget_tokens, effort。
• Google Gemini docs: Thinking, thinkingBudget, thinkingLevel。
• DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning；DeepSeek Reasoner API reasoning_content。
• Qwen3: Think Deeper, Act Faster；enable_thinking、/think、/no_think。
• Muennighoff et al., 2025, s1: Simple test-time scaling。
• Alomrani et al., 2025, Reasoning on a Budget: A Survey of Adaptive and Controllable Test-Time Compute in LLMs。
• Li et al., 2025, Steering LLM Thinking with Budget Guidance。
• Ringel et al., 2025, Learning a Continue-Thinking Token for Enhanced Test-Time Scaling。
• He et al., 2025, ThinkDial: An Open Recipe for Controlling Reasoning Effort in Large Language Models。
• Lin et al., 2025, Plan and Budget: Effective and Efficient Test-Time Scaling on Reasoning Large Language Models。
• Cheng & Van Durme, 2024, Compressed Chain of Thought: Efficient Reasoning Through Dense Representations。