一句话解释

Reasoning Model，推理模型，是一种在回答前投入更多计算来进行多步推理、规划、检查和修正的模型，特别适合数学、代码、科学分析、复杂问答和长程任务。

更通俗地说，普通聊天模型更像“快速回答”，推理模型更像“先想一会儿，再回答”。不过这里的“想”是工程意义上的推理过程，不等同于人类意识或真正理解。

为什么最近变火

大语言模型早期给人的惊喜主要来自流畅生成、知识问答、摘要、翻译和代码补全。但用户很快发现：模型在复杂问题上经常“一步错，步步错”。它可能把数学题做错，把代码逻辑想漏，把多约束任务处理乱，或者生成一个看似合理但没有验证的结论。

这让研究者和产品团队开始重视一个问题：能不能让模型在回答前多做一些内部计算？

早期方法包括 Chain-of-Thought prompting、自一致性采样、Tree of Thoughts、verifier、过程监督等。它们共同指向一个方向：不要让模型直接给最终答案，而是让它分解问题、搜索可能路径、验证中间步骤，再输出更可靠结果。

2024 年以后，“推理模型”作为产品类别快速变热。OpenAI 在 2024 年发布 o1，并强调它会在回答前花更多时间进行推理，适合复杂数学、代码和科学问题。2025 年，OpenAI 又发布 o3、o4-mini 等 reasoning model；DeepSeek-R1 通过强化学习和开放权重引发广泛关注；Anthropic Claude 3.7 Sonnet 引入 extended thinking；Google Gemini 2.5 也把“thinking model”作为核心叙事之一。

截至 2026 年 5 月，推理模型已经不只是研究概念，而是前沿模型产品的重要方向。它代表了大模型能力竞争中的一个变化：不只是训练时更大，也是在推理时更会分配计算。

它解决了什么问题

• 多步推理容易出错：推理模型更强调分解问题、逐步求解和检查结果。
• 复杂代码任务需要验证：模型需要读代码、定位问题、修改、运行测试，再根据结果调整。
• 数学和科学问题需要严谨性：直接生成答案容易错，推理模型会投入更多计算。
• 长程任务需要规划：复杂任务不是一次回答，而是需要计划、执行、观察和修正。
• 普通模型容易过早下结论：推理模型更倾向于在不确定时多探索几条路径。
• 工具调用需要决策：什么时候检索、什么时候运行代码、什么时候请求用户确认，都需要推理。
• 答案需要可验证：推理模型更适合和 verifier、测试、评估器结合。

但推理模型不是万能的。它能提高复杂任务成功率，却不能保证永远正确，也不能替代事实来源、工具验证和人类审查。

核心概念

1. Chain-of-Thought

Chain-of-Thought，思维链，是让模型在回答复杂问题时生成中间推理步骤，而不是直接给答案。

例如，普通模型可能直接回答：

答案是 42。

CoT 方式会鼓励模型先写：

先计算 A，再根据条件 B 排除一种情况，最后得到答案。

CoT 的重要性在于，它发现大模型在某些任务上通过显式中间步骤可以表现更好。它不是推理模型本身，但为后来的推理模型提供了重要思想：复杂问题需要中间过程。

2. Test-time Compute

Test-time compute 指模型在推理阶段投入的计算量。传统上，我们更关注训练阶段的算力和数据；推理模型则强调回答时也可以花更多计算。

普通模型可能一次前向生成一个答案。推理模型可能会：

• 生成多个候选解；
• 对中间步骤进行检查；
• 搜索不同思路；
• 调用工具验证；
• 在输出前进行自我纠错；
• 用更多内部 token 完成推理。

这意味着同一个问题，推理模型可能更慢、更贵，但更可靠。

3. Hidden Reasoning Tokens

许多现代推理模型会在内部使用推理 token，但不一定把完整推理过程展示给用户。用户看到的是最终答案、摘要式解释或可公开的解题步骤。

这样设计有几个原因：

• 完整推理过程可能很长，不适合直接展示。
• 内部推理可能包含不稳定草稿。
• 展示完整链路可能带来安全和误导风险。
• 产品上用户更需要结论、关键理由和可验证证据。

因此，不要把“看不到完整思维链”理解为模型没有推理；也不要把模型展示出来的解释完全等同于内部实际计算过程。

4. Verifier

Verifier 是验证器，用来判断答案或中间步骤是否正确。它可以是另一个模型，也可以是规则、测试、编译器、数学检查器、数据库查询或人工审查。

例如代码任务中，最好的 verifier 往往不是另一个模型，而是测试：

修改代码 -> 运行测试 -> 查看失败日志 -> 再修改

推理模型和 verifier 结合，会比单纯生成答案更可靠。

5. Search

复杂推理常常不是直线，而是搜索。模型可能尝试多条路径，再选择更合理的一条。Tree of Thoughts 就是把语言模型的推理过程组织成树状搜索的一类方法。

这和早期 AI 的搜索思想有明显连续性。区别在于，今天的搜索节点可以由大语言模型生成和评估。

6. Reinforcement Learning for Reasoning

推理模型常和强化学习有关。DeepSeek-R1 的重要性之一，就是展示了用强化学习激发模型推理能力的路线，并通过开放权重模型让更多开发者研究和复现。

强化学习可以奖励模型做出正确答案，也可以在某些设置中奖励更好的推理过程。这里的难点是奖励设计：只奖励最终答案可能让模型学会"碰巧答对"；奖励过程则需要可靠判断每一步是否合理。

PRM vs ORM：奖励"过程"还是奖励"结果"

推理模型训练中最关键的设计选择之一，是奖励模型（reward model）的颗粒度。这里有两条主线：

维度	ORM（Outcome Reward Model）	PRM（Process Reward Model）
评分对象	整条推理的最终答案	推理过程的每一步
训练数据	"题目 + 答案是否正确"的标签	"题目 + 每一步是否正确"的标签
数据成本	低，自动校验答案即可	高，每一步都要标注
训练信号	稀疏（一题一个信号）	密集（一题多个信号）
容易出现的问题	模型学会"碰巧答对"，过程混乱	需要可靠的步骤标注，否则会奖错
代表工作	RLHF 标准做法、OpenAI WebGPT、早期推理模型	OpenAI Let’s verify step by step（2023）

ORM 简单粗暴：只看最终答案对不对。但纯 ORM 训练的模型经常表现出奖励作弊（reward hacking）——比如数学题靠猜或者跳步答对、代码题输出错误但凑巧通过简单测试。模型学到的不是"推理"，而是"在分布上更可能撞对答案的方式"。

PRM 试图修正这一点：让模型每一步都被打分，错误一步就受到惩罚。OpenAI 2023 年的 Let’s verify step by step 论文是 PRM 的代表，他们在 MATH 数据集上证明 PRM 比 ORM 显著提升推理质量，尤其是在多步问题上。它能告诉模型"前两步对，第三步错"，让训练信号更精细。

PRM 的难点是步骤标注：

• 让人逐步打标签太贵，OpenAI 这篇论文动用了大量众包标注员；
• 用 LLM 当"自动标注员"又会引入打分偏差；
• 不同任务（数学、代码、推理逻辑）对"什么算正确的中间步骤"定义不同。

DeepSeek-R1 给出了第三条路：用规则化的可验证奖励 + 大规模强化学习。在数学和代码这种"答案可自动判定"的领域，他们绕开了 PRM 的标注难题，直接用 ORM 风格但极大规模的 RL，让模型自己涌现出长 CoT。后续 R1-Zero、R1 的成功让"规则可验证 + RL"成为开源推理模型的主流路线。

理解 PRM vs ORM 的意义：

• 数据成本决定了能跑多大规模——这是 DeepSeek 选 ORM + 规则验证的原因；
• 任务可验证性决定了 ORM 是否可行——数学/代码可验证，开放写作就不行；
• 前沿模型通常混合使用：先用 ORM/规则奖励做主训练，再用 PRM 或人类偏好做精细对齐。

工作原理

推理模型的具体实现各家不同，通常不会完全公开。但从系统层面，可以把它理解为以下流程：

这个流程并不意味着每个模型都显式按这些步骤运行。它是一种理解方式：推理模型会在输出前做更多内部探索、检查或验证。

普通模型和推理模型的差别

维度	普通聊天模型	推理模型
回答速度	通常更快	通常更慢
成本	通常更低	通常更高
擅长任务	问答、写作、摘要、常规代码	数学、代码、科学、复杂规划
推理方式	倾向快速生成	倾向投入更多 test-time compute
错误模式	可能过早下结论	仍会错，但更常尝试检查
输出体验	直接、流畅	可能等待更久，答案更结构化

一个重要边界：推理不等于事实

推理模型更会处理复杂逻辑，但事实知识仍然可能过时或错误。问“某公司今天股价是多少”时，推理模型不如实时金融 API；问“这份合同第 7 条和第 12 条是否冲突”时，模型需要看到合同原文；问“这个实验结论是否成立”时，模型需要数据和方法。

所以推理模型常常要和 RAG、Tool Use、Workflow 结合。推理负责组织思路，工具负责提供事实和验证。

典型应用场景

1. 数学和逻辑题

推理模型适合处理多步骤数学题、逻辑推断、组合问题和证明草稿。

但在高要求场景中，最终仍应使用形式化验证、计算器或人工审查。模型推理过程看起来合理，不代表每一步都严格正确。

2. 复杂代码任务

编程是推理模型最重要的落地场景之一。它需要理解代码库、跟踪调用关系、推断 bug 原因、修改代码并运行测试。

推理模型比普通模型更适合这类任务，因为它需要在多个约束之间权衡：

• 不破坏已有功能；
• 最小化修改范围；
• 保持代码风格；
• 补充测试；
• 根据报错继续修复。

3. 科学和工程分析

科学问题常常需要理解假设、变量、实验条件、数据和结论之间的关系。推理模型可以帮助做文献梳理、实验设计、公式推导、工程方案比较。

它适合做辅助分析，不适合作为最终科学结论来源。科学结论仍需要数据、实验和同行审查。

4. 复杂决策支持

例如产品路线选择、架构方案比较、投资研究、供应链风险分析等，需要同时考虑多个因素。

推理模型可以帮助列出约束、比较方案、识别风险、生成决策矩阵。但最终决策应由人类结合现实背景和责任边界完成。

5. Agent 和 Workflow

Agent 要决定下一步做什么，Workflow 要判断是否通过检查点，这些都需要推理。

例如一个研究 Agent 可能需要判断：

• 资料是否足够；
• 来源是否可信；
• 是否需要换关键词；
• 是否应该调用代码工具；
• 是否需要向用户澄清。

推理模型在这类任务中可以作为 planner、evaluator 或 controller。

和其他概念的区别

概念	解决的问题	和推理模型的关系
LLM	语言理解和生成	推理模型通常也是 LLM 的一种特殊训练/推理形态
Chain-of-Thought	让模型显式写中间步骤	推理模型可能内部使用类似思想，但不一定展示完整过程
RAG	给模型补充外部知识	推理模型仍需要 RAG 获取事实和私有资料
Tool Use	调用外部工具	推理模型更擅长判断何时调用工具
Agent	多步行动系统	推理模型可作为 Agent 的规划和评估核心
Workflow	可控流程编排	推理模型可用于复杂步骤、评估和分支判断
Fine-tuning	调整模型行为或任务能力	推理能力可能通过后训练、强化学习和偏好优化增强
Scaling Law	描述规模和性能关系	推理模型强调不仅训练规模重要，推理时计算也重要

推理模型和“更大模型”有什么区别

更大模型通常指参数更多、训练数据更多、训练计算更多。推理模型强调的是回答时如何使用计算。

当然，两者可以同时存在。一个模型既可以很大，也可以在推理时投入更多计算。但概念重点不同：

• 大模型：训练阶段规模大。
• 推理模型：推理阶段更会思考、搜索和验证。

一个简单例子

假设用户问：

一个项目有 3 个方案：A 成本低但风险高，B 成本中等且交付快，C 成本高但长期维护最好。团队预算有限，且 2 个月内必须上线。应该怎么选？

普通模型可能直接回答：

建议选择 B，因为它平衡了成本和交付速度。

推理模型更理想的处理方式是：

最终回答可能是：

在“预算有限”和“2 个月内必须上线”是硬约束的前提下，B 可能是默认推荐，因为它在交付速度和成本之间较平衡。A 虽然成本低，但高风险可能威胁上线时间；C 长期维护最好，但成本高且可能不适合当前预算。更稳妥的策略是选择 B，同时借鉴 C 的关键维护设计，避免未来返工。如果风险承受能力极低，还需要补充各方案的具体成本、团队经验和失败代价。

这个例子里，推理模型的价值不是给出一个神秘答案，而是更系统地识别约束、权衡因素和说明不确定性。

常见误解

误解 1：推理模型一定不会出错

推理模型仍然会出错。它可能推理路径错误、使用错误事实、忽略约束，或者在复杂问题上产生看似严谨的错误答案。

推理模型提高的是复杂任务成功概率，不是提供绝对正确性。

误解 2：推理越长越好

不一定。简单问题不需要长推理。问“Python 如何取列表长度”，直接回答 len(list) 就够了。

过度推理会增加延迟和成本，也可能让模型把简单问题复杂化。

误解 3：显示出来的解释就是模型真实思考过程

不一定。很多模型会输出解释，但这可能是面向用户的摘要，而不是内部完整推理轨迹。

因此，用户应该关注答案是否可验证，而不是迷信一段看似详细的推理文字。

误解 4：推理模型可以替代工具

不能。推理模型不能替代数据库、搜索、计算器、编译器、测试框架和专业软件。

复杂计算应该调用计算工具；事实问题应该查来源；代码修改应该跑测试。

误解 5：推理模型只适合数学

数学是典型场景，但不是唯一场景。推理模型也适合代码、科学分析、法律条款比较、商业决策、复杂写作规划、Agent 任务控制等。

未来趋势

1. Test-time Scaling

未来模型竞争会越来越重视推理阶段的计算分配。系统可能根据问题难度动态决定用多少计算：简单问题快速回答，复杂问题慢思考。

这会带来新的产品设计问题：用户是否愿意等？什么时候值得花更多成本？如何让用户知道模型正在做更深入分析？

2. 推理模型和工具深度结合

推理模型最可靠的形态，不是闭门思考，而是边推理边验证。它会更频繁地调用：

• 搜索；
• 代码执行；
• 数学求解器；
• 数据库；
• 单元测试；
• 形式化验证器；
• RAG 知识库。

未来强系统可能是“推理模型 + 工具 + verifier + workflow”的组合。

3. 可控推理深度

不同任务需要不同推理深度。未来 API 和产品可能会更精细地提供推理预算控制，例如 low、medium、high，或者按任务自动选择。

这有助于平衡成本、延迟和质量。

4. 可验证推理

很多领域不满足于“模型觉得对”。未来会更重视可验证推理：

• 数学证明可由形式系统检查；
• 代码可由测试和静态分析检查；
• 数据分析可由 SQL 和图表复现；
• 法律结论可链接到条款原文；
• 科学推断可链接到实验数据和论文。

推理模型会越来越像一个会组织验证过程的助手，而不是单独给结论的黑箱。

5. 从推理模型到推理型 Agent

Agent 需要持续做决策。推理模型会成为 Agent 的核心组件，用于规划、工具选择、失败诊断、结果评估和下一步行动。

但越推理型的 Agent，越需要 workflow 和权限边界。否则它可能在长任务中积累错误。

小结

• 推理模型是在回答前投入更多计算进行分解、搜索、检查和修正的模型。
• 它解决的是普通 LLM 在复杂数学、代码、科学分析和长程任务中容易过早下结论的问题。
• Chain-of-Thought、自一致性、Tree of Thoughts、verifier、过程监督和强化学习都推动了推理模型发展。
• 2024 年 OpenAI o1 让 reasoning model 作为产品类别进入主流视野。
• DeepSeek-R1、Claude extended thinking、Gemini 2.5 等让推理模型生态进一步扩展。
• 推理模型通常更慢、更贵，但在复杂任务上可能更可靠。
• 推理不等于事实，推理模型仍需要 RAG、工具调用、测试和外部验证。
• 不要迷信完整思维链，更应该关注答案是否可验证、来源是否可靠、工具结果是否支持结论。
• 未来趋势包括 test-time scaling、工具结合、可控推理深度、可验证推理和推理型 Agent。

参考资料

• Jason Wei et al., Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, 2022: https://arxiv.org/abs/2201.11903
• Xuezhi Wang et al., Self-Consistency Improves Chain of Thought Reasoning in Language Models, 2022: https://arxiv.org/abs/2203.11171
• Shunyu Yao et al., Tree of Thoughts: Deliberate Problem Solving with Large Language Models, 2023: https://arxiv.org/abs/2305.10601
• OpenAI, Let’s verify step by step, 2023: https://openai.com/index/lets-verify-step-by-step/
• OpenAI, Learning to reason with LLMs, 2024: https://openai.com/index/learning-to-reason-with-llms/
• OpenAI, Introducing OpenAI o1-preview, 2024: https://openai.com/index/introducing-openai-o1-preview/
• DeepSeek-AI, DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning, 2025: https://arxiv.org/abs/2501.12948
• DeepSeek-AI, DeepSeek-R1 GitHub Repository, 2025: https://github.com/deepseek-ai/DeepSeek-R1
• Anthropic, Claude 3.7 Sonnet and Claude Code, 2025: https://www.anthropic.com/news/claude-3-7-sonnet
• Anthropic Docs, Extended thinking: https://docs.anthropic.com/en/docs/build-with-claude/extended-thinking
• Google, Gemini 2.5: Our most intelligent AI model, 2025: https://blog.google/technology/google-deepmind/gemini-model-thinking-updates-march-2025/
• OpenAI, Introducing OpenAI o3 and o4-mini, 2025: https://openai.com/index/introducing-o3-and-o4-mini/