大语言模型的能力边界，从来不止于“记住了多少知识”，更在于“能不能把知识串起来解决问题”。

从最初的直接问答，到思维链引爆推理能力，再到“思考+行动”的智能体范式，短短几年里，CoT、Self-Ask、ReAct 三个名词几乎成了所有AI从业者的必修课。但很多人对它们的认知仍停留在“提示词模板”层面：

• 以为写几句“一步步思考”就是掌握了CoT；
• 把Self-Ask当成CoT的换皮；
• 让模型一次性输出Thought+Action+Observation，就自称实现了ReAct Agent。

本文会从底层原理、范式演进、工程落地、认知误区四个维度，把这三种核心推理范式讲透，帮你厘清它们的本质差异与适用边界。

一、回到本质：为什么“分步输出”能让大模型变聪明？

在逐个拆解范式之前，我们先搞清楚一个底层问题：为什么同样的模型，只是让它“把过程说出来”，准确率就能大幅提升？

大语言模型的核心机制是自回归逐token生成，每一个输出token，都只基于前面所有的上下文。当你让模型“直接给出答案”时，它需要在极短的生成路径里，同时完成知识召回、逻辑计算、结果汇总，很容易出现跳步、记错、逻辑断裂。

而所有“分步推理”范式的核心，都是通过强制模型输出中间过程，把隐性思考显性化：

1. 每一步输出都会成为后续生成的上下文，相当于给自己“写草稿”，降低单步认知负荷；
2. 中间步骤会激活模型内部更多相关知识，减少跳步导致的事实幻觉；
3. 结构化的中间输出，让人类或程序可以介入修正，而不是只能被动接受最终结果。

CoT、Self-Ask、ReAct，本质是在“显性化思考”这条路上，走出了三条逐步深化的路径。

二、三大核心范式逐一拆解

2.1 CoT（Chain-of-Thought，思维链）：让模型学会“打草稿”

CoT 是所有推理范式的基石，也是最广为人知的提示工程方法，2022年由Google Research正式提出。

核心思想：引导大模型输出完整的中间推理步骤，再得出最终结论，而非直接给出答案。它模拟人类做数学题、逻辑题时的演绎过程，把复杂问题拆成串行的小推理步，每一步都基于前一步的结果推进。

标准Prompt模板：

请一步步思考，写出完整的推理过程，最后给出最终答案。
问题：[你的问题]

输出示例：

问题：贝多芬去世的年份，距离蒸汽机首次实用化相隔多少年？
思考：首先，贝多芬去世的年份是1827年。其次，瓦特改良蒸汽机并实现首次商业化实用的年份是1776年。最后计算两个年份的差值：1827 - 1776 = 51。
答案：相隔51年。

核心价值：
在不改动模型权重、不增加外部工具的纯Prompt层面，就能大幅提升数学推理、逻辑判断、多步常识题的准确率，是成本最低的推理增强手段。

固有局限：

• 全程是内部闭环推理，所有信息都来自模型参数知识，遇到知识盲区、时效性问题完全无解；
• 推理步骤自由无规范，难以被程序结构化解析和干预；
• 容错性差：如果第一步的前提事实就错了，后续会沿着错误路径一路推导下去，无法自我修正。

2.2 Self-Ask（自我提问）：把“自由思考”变成“结构化拆题”

Self-Ask 是与CoT同期提出的推理范式，很多人把它当成CoT的变种，但二者的核心逻辑有本质区别。

核心思想：让模型主动将主问题拆分为一系列子问题（Follow-up Question），逐个解答子问题，最终基于子问题的答案推导最终结论。如果说CoT是“步骤式推理”，Self-Ask就是“问题式拆解”——CoT的中间是“因为…所以…”，Self-Ask的中间是“先要知道A，还要知道B，最后才能算C”。

标准Prompt模板：

遇到复杂问题时，先提出后续子问题，逐一回答，直到可以给出最终答案。
严格遵循格式：
Follow-up：子问题
Answer：子问题答案
……
Final Answer：最终结果

问题：[你的问题]

输出示例：

Follow-up：贝多芬是哪一年去世的？
Answer：1827年
Follow-up：蒸汽机首次实用化是哪一年？
Answer：1776年
Follow-up：两个年份相差多少年？
Answer：1827 - 1776 = 51年
Final Answer：相隔51年。

核心价值：

• 拆解过程高度标准化，输出格式可控，方便程序做结构化解析和二次处理；
• 更适合“多事实组合类问题”，比如需要多个知识点拼接的常识题、跨领域计算题；
• 天然具备“子问题可替换”的潜力——子问题的答案可以不用模型自己答，换成外部工具、知识库返回的结果，这正是后续工具调用范式的雏形。

固有局限：

• 原生版本依然是纯内部推理，子问题答案还是来自模型记忆，知识错则全错；
• 容易出现无效子问题、冗余拆解，增加推理长度和token成本。

2.3 ReAct（Reason + Act）：从“闭门思考”到“出门查证”

ReAct 由普林斯顿大学与Google Research在2022年10月联合提出，它的出现，正式把大模型的推理从“内部闭环”推向了“内外交互”，也是今天所有Agent智能体的核心基础框架。

核心思想：将推理（Reason）与行动（Act）深度融合，让模型在思考过程中主动判断信息缺口，调用外部工具获取真实反馈，再基于反馈继续推理，形成“思考-行动-观测-再思考”的闭环。

它解决了CoT和Self-Ask的根本痛点：模型内部知识有限、过时、有错时，无法自我修正。ReAct让大模型拥有了“动手查证”的能力。

但ReAct也是被误解最多的范式——绝大多数人接触到的“ReAct”，其实都是“伪ReAct”。

三、ReAct的认知重灾区：你看到的大部分ReAct都是假的

这是工程落地中最容易踩的坑，也是区分“懂行”和“入门”的核心判断点。

3.1 什么是“伪ReAct”

很多教程、Demo甚至部分所谓的Agent框架，都会让模型一次性输出完整的轨迹：

Thought: 我需要先查贝多芬的去世年份
Action: Search["贝多芬去世年份"]
Observation: 贝多芬1827年逝世
Thought: 接下来查蒸汽机实用化年份
Action: Search["瓦特蒸汽机年份"]
Observation: 1776年投入商用
Thought: 计算差值是51年
Final Answer: 相隔51年

这种单轮生成、模型自己编造Observation的形式，就是典型的伪ReAct（Mock ReAct）。

它本质上只是“模仿ReAct格式的CoT”，所有观测结果都是模型脑补出来的，既没有真实调用工具，也没有外部信息输入，和纯CoT没有本质区别，依然摆脱不了幻觉。它唯一的用途，就是教学演示格式，完全不具备工程落地价值。

3.2 真正的ReAct，必须满足三个硬性条件

ReAct 不是一段提示词，而是一套“Prompt规范 + 调度系统 + 工具集”的系统工程。完整的ReAct闭环，三个条件缺一不可：

1. Action必须由外部执行器真实执行
   模型只负责输出“要做什么”，不负责“做的过程和结果”。搜索、计算、API调用、数据库查询，必须由外部代码/运行环境完成，模型本身不执行任何动作。

2. Observation必须是真实的外部反馈
   观测结果不能由模型生成，必须是工具执行后的真实返回值，再由调度器注入到对话上下文中。模型自己编出来的Observation，没有任何实际意义。

3. 必须是多轮LLM调用循环
   每执行一次行动，就要把结果塞回上下文，再调用一次大模型继续思考，直到得出最终答案。一次调用走完所有流程的，都不是真ReAct。

3.3 标准ReAct的完整运行流程

我们用同一个问题，还原真实ReAct的多轮交互过程：

初始上下文：系统Prompt + 用户问题

你严格按照格式输出：
Thought: 你的推理分析，确定下一步需要做什么
Action: Search[查询内容]
当信息足够时输出 Final Answer: 答案
禁止自己生成Observation！Observation由系统自动填入。
问题：贝多芬去世的年份，距离蒸汽机首次实用化相隔多少年？

第1轮：调用LLM
输出：

Thought：我需要确认两个关键年份，首先查证贝多芬的去世年份
Action：Search[“贝多芬去世年份”]

调度器执行动作：解析Action，调用搜索工具，拿到真实结果

Observation：路德维希·凡·贝多芬于1827年3月26日在维也纳逝世。

将Thought、Action、Observation追加到上下文，第2轮：调用LLM
输出：

Thought：已确认贝多芬1827年去世，还需要查证瓦特蒸汽机首次实用化的年份
Action：Search[“瓦特改良蒸汽机首次商业化年份”]

调度器再次执行搜索

Observation：1776年，瓦特改良的蒸汽机首次投入商业使用，标志着蒸汽机进入实用化阶段。

将新结果追加到上下文，第3轮：调用LLM
输出：

Thought：已有两个准确年份，1827减去1776等于51，信息充足，可以给出答案
Final Answer：相隔51年。

整个过程中，LLM永远只负责“思考和下指令”，执行和结果完全来自外部系统，这才是ReAct“推理+行动”的真正含义。

四、全景横向对比：三者的核心差异与适用边界

维度	CoT（思维链）	Self-Ask（自我提问）	标准ReAct
核心机制	串行分步推理，显性化思考过程	结构化拆分子问题，逐个子问题求解	思考与外部行动交替循环，用真实反馈补充推理
推理闭环	纯内部闭环	纯内部闭环	内外交互闭环
是否需要外部Agent	不需要	不需要	必须有调度执行器
LLM调用次数	单次	单次	多轮循环
信息来源	模型内部参数知识	模型内部参数知识	模型推理 + 外部工具真实信息
幻觉抑制能力	弱，仅减少逻辑跳步幻觉	弱，仅优化拆解逻辑	较强，可修正事实类错误
落地成本	极低，仅需Prompt	极低，仅需Prompt	高，需配套工具、调度器、异常处理
典型适用场景	数学计算、逻辑推理、静态知识问答	多事实组合题、问题拆解、简单规划	实时信息查询、事实查证、工具型智能体
典型缺陷	事实错误无法修正，步骤不可控	子问题易冗余，事实错误无法修正	延迟高、成本高，易出现循环调用、解析失败

两个关键结论

1. 三者不是互斥关系，是递进与包含关系：ReAct的思考过程里，本身就可以包含CoT式的分步推理；Self-Ask的子问题对接工具后，本质就是ReAct的简化形态。成熟的Agent系统，往往是三者的混合使用。
2. 不是越复杂的范式越好：简单问题直接回答，中等推理用CoT，需要外部信息才上ReAct。为了范式而范式，强行给简单问题套ReAct框架，是典型的技术自嗨。

五、工程落地中的4个常见误区

误区一：ReAct = 写个ReAct格式的Prompt

Prompt 只是ReAct的三分之一。完整的ReAct工程落地，还需要解决Action格式解析、工具路由、超时重试、循环次数限制、异常兜底等一系列工程问题。没有调度器的ReAct Prompt，只是一段文本模板。

误区二：Self-Ask没什么用，不如直接上ReAct

Self-Ask 是非常轻量的“问题拆解器”，价值被严重低估。在很多不需要复杂工具的场景里，“Self-Ask拆题 + 知识库检索”的组合，比完整ReAct成本低、延迟低，效果完全够用。绝大多数Agent的规划模块，本质都是Self-Ask的变种。

误区三：ReAct能解决所有幻觉问题

ReAct 只能解决“信息不足/过时导致的事实幻觉”，解决不了“推理逻辑错误导致的幻觉”。如果模型拿到了正确的观测结果，但推理步骤错了，依然会给出错误答案。想要进一步降低幻觉，需要在ReAct基础上叠加反思（Reflexion）、多路径投票等机制。

误区四：推理步骤越详细，效果越好

分步推理会线性增加token消耗和推理延迟，工程上必须做效果与成本的平衡。工业级应用中，通常会根据问题复杂度动态选择范式：简单问题直接答，常规问题用CoT，只有检测到需要外部信息时，才触发ReAct流程。

六、从三大范式看Agent推理的演进方向

CoT、Self-Ask、ReAct 是大模型推理的三块基石，在此之上，推理范式还在持续进化：

• 从“走一步看一步”到“先规划再执行”：Plan-and-Solve、Plan-Act 等范式，先做全局规划再分步执行，比ReAct的即兴式推理效率更高、更可控；
• 从“单轮推理”到“带反思的迭代”：Reflexion 等框架在ReAct闭环里加入复盘环节，执行完后自我纠错，大幅提升复杂任务的成功率；
• 从“单一范式”到“混合架构”：成熟的Agent系统，通常是“规划层用Self-Ask/Plan，推理层用CoT，执行层用ReAct”的分层架构，而非单一范式走到底。

写在最后

CoT 教会了大模型“好好思考”，Self-Ask 教会了大模型“拆解问题”，ReAct 教会了大模型“动手查证”。

这三个范式不是三个孤立的提示词技巧，而是大模型从“被动问答”走向“主动解决问题”这条演进路上的三个里程碑。理解它们的本质，不是为了背诵名词和模板，而是能在不同的业务场景里，选择成本最低、效果最合适的方案——毕竟对技术落地而言，从来没有最好的范式，只有最适合场景的范式。