外观
第 9 章 思维链与推理增强
直接向模型要答案，它可能连一道小学数学题都做错；让它把思考过程一步步写出来，同一道题往往就做对了。这个反差背后的一整套推理增强技术，就是这一章的主题。这一章从思维链的本质讲起，再讲思维树、思维图、先规划后执行这些进阶模式，最后聊到把手写示例也自动化掉的演进方向，每个方法都会讲清适用场景、代价与失效边界。读完这一章，再拿到一个需要推理的任务，就能判断该不该用推理增强、该用哪一种、成本上划不划算。
9.1 思维链（CoT）的本质与起源
这一章的核心对象是思维链（Chain of Thought, CoT）。它要解决的问题一句话就能说清：让模型在给出最终答案之前，先把中间的推导过程一步步写成文字。只看答案，无法判断模型是算出来的还是碰巧蒙对的；有了过程，每一步推导都摆在明处，可检查、可复现。这个要求在工程上的价值，这一章会反复看到。
在 2022 年之前，人和 AI 打交道的方式，基本上都还停留在“问答”模式。问一个问题，AI 给一个答案。比如问它：“一个农夫有 35 个头，94 只脚，请问他有多少只鸡和多少只兔子？”旧时代的模型张口就答：“12 只鸡，23 只兔子。”（一个错误的答案，后面会看到，正确的组合恰好是反过来的）
看到这个错误答案，只会觉得：“嗨，这 AI 也不行啊，连小学数学题都不会做。”旧模式的根本问题就在这里，模型只给结果，人完全看不到它是怎么得出这个结果的。
直到 2022 年，情况改变了，一年之内接连出现了两篇关键论文。
年初，Google 的 Jason Wei 等人发表了一篇论文《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》（arXiv:2201.11903，后来入选 NeurIPS 2022）。他们的技巧是，在少样本示例里，把中间推理步骤也一并写出来。就这么一个改动，效果显著：仅用 8 个带推理过程的示例去提示一个 540B 参数的模型，就在 GSM8K 数学应用题基准上拿到了当时的最优成绩，甚至超过了带验证器的微调 GPT-3。
几个月后，东京大学的 Kojima 等人又往前推了一步（arXiv:2205.11916，NeurIPS 2022）。连示例都不用给，只要在问题后面加一句触发语，也就是“Let's think step by step.（让我们一步步思考。）”，模型就会展开分步推理。效果有多明显？在 MultiArith 算术基准上，text-davinci-002 的准确率从 17.7% 直接跳到 78.7%；GSM8K 上也从 10.4% 涨到了 40.7%。
前后差异非常大。
把同一个问题再问一遍：“一个农夫有 35 个头，94 只脚，请问他有多少只鸡和多少只兔子？请一步步思考。”
新时代的模型会这样回答： “好的，我们来一步步解决这个问题。 第一步：定义变量。 假设鸡的数量是 c，兔子的数量是 r。 第二步：根据头的数量列出方程。 每只鸡和每只兔子都只有一个头，所以我们得到方程 (1): c + r = 35。 第三步：根据脚的数量列出方程。 每只鸡有 2 只脚，每只兔子有 4 只脚，所以我们得到方程 (2): 2c + 4r = 94。 第四步：解方程组。 我们可以将方程 (1) 变形为 c = 35 - r。然后将它代入方程 (2): 2(35 - r) + 4r = 94 70 - 2r + 4r = 94 70 + 2r = 94 2r = 24 r = 12 第五步：求出 c 的值。 将 r = 12 代入 c = 35 - r，得到 c = 35 - 12 = 23。 第六步：得出结论。 所以，农夫有 23 只鸡和 12 只兔子。”
这个过程里，最重要的变化不是答案变对了。
模型不仅给出了正确的答案，更重要的是，它展示了它的思考过程！它把自己的解题步骤、每一步的逻辑都写得清清楚楚。
这两篇论文，就是思维链（Chain of Thought, CoT）技术的起源。它揭示了大语言模型一个极其深刻的内在机制。
LLM 本质上是一个“续写”引擎，而不是一个“计算”引擎。当直接问它答案时，它是在庞大的概率空间里，直接去“猜”那个最可能跟在问题后面的答案序列。对于需要多步推理的复杂问题，这种“一步到位”的猜测，命中率极低。
但是，当引导它“一步步思考”时，生成方式就变了。不再是让它直接输出最终的那个 Token，而是让它先生成中间的、作为思考过程的 Token。
每生成一个中间步骤的 Token（比如“第一步：定义变量”），这个 Token 就会加到新的上下文（Context）中，成为下一步生成的基础。这就把任务压力分摊开了。它在生成第二步时，只需要关注“如何根据第一步的变量来列方程”，而不需要同时考虑整个问题的全部复杂性。
这相当于把一次高难度的整体计算，换成了一连串低难度的局部计算。每一步都很简单，但把这些简单的步骤串联起来，就能解决一个非常复杂的问题。
思维链的本质，就是通过在 Prompt 中显式地要求模型输出思考过程，来将一个复杂的、隐式的、一步到位的推理任务，分解成一个简单的、显式的、多步的文本生成任务。这个发现的革命性在于，它让人第一次有能力直接观察黑盒子的输出过程，去理解、甚至引导模型的“思考”过程，不再只能被动地接受结果，而是可以主动地参与和塑造它的推理路径。
这就是 Prompt Engineering 从“指令工程”迈向“推理工程”的开端。
9.2 Zero-shot CoT 与 Manual CoT
好了，理解了 CoT 的本质，工程师最关心的问题来了。在实际项目中该怎么用它？是不是所有问题都在后面加一句“请一步步思考”就行了？
不一定。这句触发语虽然有用，但也不是万能的。在工程实践中，通常有两种实现 CoT 的方式：Zero-shot CoT（零样本思维链） 和 Manual CoT（手动/少样本思维链）。
Zero-shot CoT：加一句触发语
Zero-shot CoT，就是刚才看到的那个例子。不需要给模型任何示例，只需要在指令后面，加上一句引导它思考的触发语。
最经典的触发语就是： “Let's think step by step.”（让我们一步步思考。）
为什么是这句英文？最早的研究是在英文语料上做的。一个合理的解释（注意，目前也还只是猜想）是，这句短语在训练数据里，恰好和大量高质量的、分步骤的讲解文本“绑定”在一起，所以能直接唤起模型的“解题模式”。说实话，它为什么有效，学界至今也没能完全说清。
当然，在中文语境下，也可以用一些类似的说法： “请一步步思考。”“请展示你的推理过程。”“请把你的解题步骤写出来。”
Zero-shot CoT 不需要构造任何复杂的示例，成本也低，有三类场景特别合适。
刚接触一个需要推理的任务、想做快速原型验证时，可以先用 Zero-shot CoT 快速测试一下模型的基本推理能力。如果能给出一个大致靠谱的思考路径，那就说明这个方向可行。
通用领域的推理问题也在其中。对于那些不涉及特定领域知识的、普适性的逻辑题、数学题、推理题，Zero-shot CoT 通常就能表现得不错，因为模型在训练时，已经见过大量类似的“解题范文”了。
它还特别适合与强大模型结合。目前最顶尖的闭源旗舰（OpenAI 的 GPT-5 系列、Anthropic 的 Claude 4.5 系列）推理能力很强，很多时候只需加一句“一步步思考”，就能展开完整的推理过程。不过要注意，OpenAI 从 2024 年 9 月起陆续推出的 o1、o3 等“推理系列”模型，已经把推理内置到了模型内部，即便不写这种引导，模型也会在生成最终答案前先生成内部推理。在这种模型上，强行加 Zero-shot CoT 反而可能让提示词变冗余、拖慢响应，甚至与模型的内部思考流程冲突。Zero-shot CoT 最稳的应用场景，是那些没有内置“系统 2”思考的通用对话模型。推理模型上的提示词该怎么写，9.8 节会专门展开。
但是，Zero-shot CoT 也有一个主要弱点，不可控。
只是告诉它“要思考”，但没告诉它“该怎么思考”。它的思考路径、思考的风格、思考的深度，完全取决于它自己的“自由发挥”。
有时候，它的思考过程可能是啰嗦的、重复的；有时候，它可能会在一个错误的方向上进行“完美”的推理；更糟糕的是，对于某些特定领域的、有固定范式的问题，它的“自由思考”可能完全不符合专业要求。
这相当于只提要求、不给方法。模型可能会去思考，但思考的方式往往低效、不规范，不符合工程要求。
这时候，就需要更可控的方式了。
Manual CoT：用示例规定思考过程
Manual CoT，也叫 Few-shot CoT，顾名思义，就是不再满足于简单地“要求”模型思考，而是要亲自给它示范应该如何思考。
它的实现方式，就是在 Prompt 里，提供一个或多个完整的、高质量的 “问题 + 思考过程 + 答案” 的示例。
来看一个例子。假设要让模型解决一些简单的物理应用题。
一个 Manual CoT 的 Prompt 长这样：
markdown
### 任务：解决物理应用题
#### 示例 1
**问题：** 一个小球从 19.6 米的高度自由下落，不计空气阻力，g 取 9.8 m/s²。请问小球落地需要多长时间？
**思考过程：**
1. **识别问题类型**：这是一个自由落体运动问题。
2. **选择合适的公式**：根据自由落体位移公式 h = (1/2)gt²。
3. **代入已知数值**：已知 h = 19.6 米，g = 9.8 m/s²。
4. **进行计算**：
19.6 = (1/2) * 9.8 * t²
19.6 = 4.9 * t²
t² = 19.6 / 4.9
t² = 4
t = 2
5. **得出结论**：小球落地需要 2 秒。
**答案：** 2 秒
---
#### 输入数据
**问题：** 一辆汽车以 10 m/s 的速度匀速行驶，然后以 2 m/s² 的加速度开始刹车。请问刹车后 3 秒，汽车行驶了多远？
**思考过程：**把这个 Prompt 发给模型时，注意看，最后只给出了 **思考过程：** 这个开头。模型看到这个，就会“激活”模仿模式。
它会仔细地研究示例 1： “哦，原来解决这种问题，要先‘识别问题类型’，然后‘选择公式’，然后‘代入数值’…… 格式还要这么清晰。”
然后，它就会在处理新问题时，模仿给出的这个“思考范式”，一步步地去生成自己的思考过程。它很可能会输出：
1. **识别问题类型**：这是一个匀减速直线运动问题。2. **选择合适的公式**：根据匀变速直线运动位移公式 x = v₀t + (1/2)at²。3. **代入已知数值**：已知初速度 v₀ = 10 m/s，加速度 a = -2 m/s²（因为是刹车），时间 t = 3 s。4. **进行计算**：...
看到这里，Manual CoT 的作用就清楚了。
通过 Manual CoT，不再是对模型“自由思考”放手不管，而是给它规定一套定制的思考流程，可以精确地控制它思考的步骤、使用的术语，甚至是输出的格式。
Manual CoT 的优势是巨大的。它的可控性和稳定性极高，对于那些有固定解题范式、固定分析流程的专业领域任务（比如财务分析、法律文书审查、代码 Bug 诊断），Manual CoT 是非常合适的选择，可以把行业内的“标准作业程序（SOP）”直接编码到示例里，让模型的思考过程完全符合专业要求。
它也能显著提升复杂任务的准确率。对于那些 Zero-shot CoT 搞不定的、特别棘手的难题，一个高质量的 Manual CoT 示例，往往能明显提升模型的准确率。
还有可解释性与可调试性。因为思考过程是自定义的，当模型出错时，很容易定位到它是在第几步上出了问题，Debug 的过程变得清晰可见。
当然，天下没有免费的午餐。Manual CoT 的强大，是以高昂的构建成本为代价的。
编写那些高质量的、带有完整思考过程的示例得靠手工，这个过程非常耗时耗力，需要对业务领域有极深的理解。
挑选和设计这些示例本身，就需要专门的方法。得看示例的典型性，它是否能代表这类问题的主流解法；得看示例的覆盖度，它是否覆盖了一些容易出错的边界情况；还得看示例的简洁性，它的思考过程是不是足够清晰、没有废话。
构建一个高质量的 Manual CoT 示例库，本身就是一个非常有价值的工程项目。
那么，在 Zero-shot CoT 和 Manual CoT 之间该如何选择呢？建议遵循一个渐进增强的策略。
拿到一个新任务，先用 Zero-shot CoT 探路，拿一句“请一步步思考”来快速摸底。如果效果够用，就不要过度设计，Zero-shot CoT 的结果已经够用了，那就没必要非得去构建复杂的 Manual CoT。记住，工程师的美德是“懒惰”。
而一旦发现 Zero-shot CoT 不稳定或不专业，比如模型的思考过程很混乱，或者完全不符合业务范式，这才是 Manual CoT 登场的时机。这时候投入时间和精力去打造一两个“黄金示例”，回报会非常巨大。
9.3 思维树与思维图的分支搜索与合并
思维链（CoT）已经非常强大了，它把模型的输出从一个最终答案，变成了一串依次生成的推理步骤。
但是，现实世界中的很多问题，它的解决路径并不是一条简单的直线。它的解法空间有多个分支，有些分支走不通，需要在分支之间选择和回退。
举个例子，解一道组合问题时，第一步就可能有好几种可行的切入点，每一种选择都会导向完全不同的后续推导。如果只沿着其中一条路径推到底，很可能就会错过最优的解法。
传统的 CoT 就有这个局限。它一旦选定了第一步的推理方向，就会沿着这个方向一直生成下去，即使中间发现方向不对，也很难回退或换一条路径。
为了解决这个问题，研究者们在 CoT 的基础上，提出了更高级的推理策略，其中最著名的就是思维树（Tree of Thoughts, ToT） 和 思维图（Graph of Thoughts, GoT）。
思维树（ToT）：生成多候选、评估、回溯
思维树（ToT） 的核心思想，是让模型在推理的每一个关键节点上，主动地探索多种可能性，然后对这些可能性进行评估，最后选择最有希望的那条路，继续往下走。
这听起来是不是很像 AlphaGo 下棋的原理？没错。ToT 的提出者、Princeton 的 Yao 等人在论文里（arXiv:2305.10601，NeurIPS 2023）就是这个思路，让模型在推理时“往前多看几步”，生成多条候选路径，给它们打分评估，挑最有希望的往下走，发现不对还能回溯。效果提升有多大？同样是玩“24 点”游戏，GPT-4 配普通思维链只能解开 4% 的题目，换上 ToT 框架后成功率直接飙到 74%。
来看一个具体的例子。假设要让模型解一道简单的“24 点”题，用 3, 4, 6, 8 这四个数字，通过加减乘除，得到 24。
一个普通的 CoT 可能会这么做： “我试试 8 - 4 = 4，然后 4 + 6 = 10，然后 10 + 3 = 13。不对。那我再试试 3 * 4 = 12，然后 12 + 6 = 18，然后 18 + 8 = 26。还是不对……” 它在一条路上失败了，可能会尝试另一条，但它的探索是线性的、随机的。
而一个使用了 ToT 策略的 Agent，它的执行过程会是这样的：
第一步是生成多个初始想法（Generate）。Agent 会对自己说：“我先看看第一步有哪些搞法？”于是有了想法 A，先算 3 + 4 = 7；想法 B，先算 6 * 4 = 24；还有想法 C，先算 6 - 4 = 2。
第二步是评估这些想法（Evaluate）。Agent 会快速地评估一下这几个开局。对想法 A，它的判断是“7, 6, 8 这三个数要凑出 24，好像有点难，先放一放。”对想法 B，判断是“24, 3, 8，已经有 24 了，但剩下的 3 和 8 没法处理成 0 或者 1，此路不通。”
至于想法 C，它觉得“2, 3, 8，这三个数要凑 24，好像有戏！”于是顺着 C 往下探：3 * 8 = 24？不对，2 还没用上；2 * 3 * 8 = 48，太大；8 - 2 = 6，再乘 3 是 18，也不对……接连试了几轮都没凑出 24。没关系，回溯，换个组合重新来：8 - 6 = 2，剩下 2, 3, 4 三个数，2 * 3 * 4 正好是 24。找到了！
（这个例子为了演示简化了过程，实际的 ToT 会更复杂，但核心思想就是这样）
可以看到，ToT 的关键，就在于 “生成多种可能” 和 “评估各种可能” 这两个动作。它把一个单线程的思考，变成了一个多线程的、带剪枝的搜索过程。
那在工程中如何实现 ToT？搭建一个完整的 ToT Agent 是一个复杂的工程，通常需要写不少代码，但可以通过 Prompt 来实现一个“手动 ToT”。
可以这样设计 Prompt 工作流。第一轮 Prompt 是生成器，内容是“针对[问题]，请提出三种不同的、可能的解题思路或第一步方案。不要深入计算，只需要给出思路框架。”
第二轮 Prompt 是评估器，把第一轮生成的三个思路，再喂给模型，让它自己评估：“你是一个逻辑评估专家。这里有三个解决[问题]的思路，请分析每一个思路的优缺点，并判断哪一个最有希望成功。请给出你的理由。”
第三轮 Prompt 是执行器，根据第二轮的评估结果，选择最优的那个思路，让模型深入执行：“我们已经确定思路 A 是最优的。现在，请严格按照思路 A，一步步地完成计算，并给出最终答案。”
这个“生成-评估-执行”的三步流程，就是 ToT 思想在 Prompt Engineering 中的一个简化实现。它虽然比简单的 CoT 复杂，但在处理那些解法不唯一的、需要创造性探索的问题时，效果会好得多。
思维图（GoT）：允许聚合、细化与跨分支生成
思维树（ToT）已经很厉害了，但它还有一个小小的“缺陷”，它是一棵“树”，分支之间相互独立，不会交叉。
但在人类真正的思考过程中，经常会发现，从思路 A 出发和从思路 C 出发，走到第三步时得出了同样的中间结果。这时候，就会把这两条路径合并起来，继续往下走。
还可能发现，思路 B 走到第五步就走不通了，但它的第三步得到的中间结果，正好可以用到思路 A 的下一步里。于是，就回过头去，把不同分支的成果组合起来。
这种更灵活、更接近人类网状思维的模式，就是思维图（Graph of Thoughts, GoT）。
GoT 的提出者是 ETH Zürich 的 Besta 等人（arXiv:2308.09687）。它把 LLM 生成的每一条信息（论文里就叫“thought”）看成图上的一个节点，节点之间的依赖关系是边。既然允许任意的图结构，能做的操作就比一棵树丰富多了，最核心的有三类，把多条思路汇成一个结论的聚合（Aggregation），比如四段分别写好的摘要，合并成一段总摘要；对同一条思路用反馈回路反复打磨的细化（Refinement），一遍遍改，越改越好；还有在这些成果之间自由派生新连接的生成（Generation）。
论文的实验数据也够硬，在排序任务上，GoT 的输出质量比 ToT 又提高了 62%，成本反倒降了三成以上。
GoT 对于解决那些各个子问题之间有紧密关联的复杂任务，特别有效。比如程序设计，可能先设计了数据库模块，又设计了 API 模块，然后发现 API 模块的一个设计，可以简化数据库模块的某个表结构，于是“回溯”去修改数据库的设计。又比如项目规划，规划了开发、测试、上线三个阶段，然后发现，如果把某个测试环节提前到开发阶段，可以大大缩短整个项目的周期，于是去“聚合”这两个阶段的工作。
那在工程中如何实现 GoT？这事比 ToT 还要复杂，实现一个全自动的 GoT Agent，需要一个能够维护图结构状态的系统。
但在 Prompt 的层面，同样可以借鉴它的思想。可以在多轮对话 Agent 中，设计一种机制，允许模型在推理过程中，主动地去“回顾”和“利用”之前的对话历史。
比如，可以设计一个带有“记忆”功能的 Prompt：
“你正在解决一个复杂的问题。这是你之前的思考步骤：[插入之前的 CoT 输出]。现在，请继续你的下一步思考。在思考时，你可以自由地引用、修改、甚至推翻你之前的任何一步结论。如果发现更好的路径，随时可以掉头。”
通过这种方式，模型获得了一种“反思”和“自我修正”的能力，可以对已有结论进行回顾和修正。
总结一下 CoT、ToT、GoT 三者的关系。CoT 只生成一条推理路径；ToT 会在关键节点生成多条候选路径并做选择，但路径之间不交叉；GoT 则允许任意路径之间建立依赖，可以随时回溯、合并、传递中间结果。
在实际应用中，绝大多数问题，一个精心设计的 Manual CoT 就足够解决了。只有面对那些极度复杂、开放、需要创造性搜索的问题时，才有必要考虑实现更复杂的 ToT 或 GoT 架构。
9.4 Plan-and-Solve 模式
前面讲的 CoT、ToT、GoT，都有一个共同的特点，思考（Thinking）和执行（Solving）是交织在一起的。模型一边生成思考步骤，一边就在进行计算和推导。
这在很多情况下是没问题的。但有时候，这种“边想边干”的模式，会导致缺乏全局规划的问题。
模型可能在第一步就陷入了细节的计算，而没有从全局去规划一个最优的解题路径。推导到一半才发现整体思路有问题，只好从头再来。
有经验的做法是先把方案设计清楚，确定整体方案、模块拆分、接口定义，把计划定完整了，再开始具体的执行。
这种“先规划，后执行”的思想，在 Prompt Engineering 里，就对应着 Plan-and-Solve (PS) Prompting 模式（Wang 等人，ACL 2023，arXiv:2305.04091）。顺带一提，这篇论文的出发点非常实在。作者观察到 Zero-shot CoT 常犯三类错，计算出错、漏掉步骤、语义理解跑偏，而 PS 模式就是冲着“漏步”这个毛病来的，先列计划把任务拆成子任务，再照着计划逐个执行，步骤自然就不容易丢。
PS 模式的核心，是把一个任务强制拆分成两个独立的阶段。
第一阶段是规划（Plan）。在这一阶段，要求模型只输出一个解决问题的计划（Plan），这个计划应该是一个高层次的、分步骤的行动纲领。在这一步，绝对不能进行任何具体的计算或执行。
第二阶段是执行（Solve）。在拿到第一阶段生成的计划后，再把它作为输入，交给第二个 Prompt，要求模型严格地、一步步地执行这个计划。
来看一个例子。假设问题是：“如果我有 5 个苹果，我吃了 2 个，然后我又买了 3 个，请问我现在有多少个苹果？”
一个普通的 CoT 可能会直接输出： “好的。5 - 2 = 3。3 + 3 = 6。所以你有 6 个苹果。”
而一个PS 模式的 Agent，会分两步走。
第一步，调用“规划 Prompt”，输入是“请为以下问题制定一个解决步骤计划。不要计算最终答案，只输出计划。”模型输出的 Plan 长这样：
1. 计算吃掉苹果后剩下的数量。2. 将剩下的数量与新买的数量相加。3. 得出最终的苹果总数。
第二步，调用“执行 Prompt”，输入是“请严格按照以下计划，一步步地解决问题：[这里插入上一步生成的 Plan]”模型输出（Solve）是这样的：
好的，我们来执行计划。步骤 1：计算吃掉苹果后剩下的数量。5 - 2 = 3 个。步骤 2：将剩下的数量与新买的数量相加。3 + 3 = 6 个。步骤 3：得出最终的苹果总数。最终答案是 6 个苹果。
有人可能会问：“这不就是多此一举吗？一个简单的 CoT 就能搞定的事，非要拆成两步，不是增加了延迟和成本吗？”
问得好！对于上面这个“苹果问题”，PS 模式确实是过度设计了。
但是，当问题变得极其复杂时，PS 模式的优势就体现出来了。
PS 模式的优势在哪里？最直接的好处是提升全局规划能力。它强制模型先从宏观视角去思考整个解题路径，避免了过早陷入局部细节而偏离整体路径。这对于需要多步、且步骤之间有依赖关系的复杂任务（比如写一个完整的程序、规划一次旅行）至关重要。
可控性与可调试性也增强了。把规划和执行分开，提供了一个宝贵的“审查点”。在执行之前，可以先审查模型生成的“计划”是否靠谱。如果计划本身就是错的，根本不用浪费算力去执行，可以直接打回让它重新规划。这相当于在代码运行前，先做一次设计审查。
还有模块化与可组合性。可以把“规划器”和“执行器”设计成两个独立的、可复用的模块，甚至用一个更强大、更昂贵的旗舰模型来做“规划”，再用一个更便宜、更快的小模型来做“执行”。这种组合，能在成本和性能之间找到一个绝佳的平衡点。
研究者们在 PS 的基础上，还提出了一个增强版，叫 PS+。这里要澄清一个容易想当然的误会，PS+ 并不是在执行之后加一个“反思”环节，而是把触发指令本身写得更细。对比一下论文里的两段原文就一目了然。PS 的触发语是“先理解问题、制定计划，然后按计划一步步执行”；PS+ 则在中间插进了具体动作：“理解问题，提取相关的变量和对应的数字，制定完整计划；然后执行计划，计算中间变量（注意数字计算和常识的正确性），一步步解决问题并给出答案”。
说白了，流程结构没变，PS+ 只是把计划写得更细，专门针对“算错数”的问题。LangChain 后来也相中了这个思路，做成了官方的 Plan-and-Execute Agent 模式，算得上学术思想反哺工程实践的又一例。
Plan-and-Solve 模式，是 CoT 思想在工程实践中的一次重要演进。它把架构设计里的“关注点分离”思想引入到了 Prompt Engineering 中，让推理过程变得更加稳健、可控，也更符合人类解决复杂问题的思维习惯。
9.5 何时不该用 CoT
思维链这么强大，那以后写所有 Prompt，是不是都应该在后面加上一句“请一步步思考”呢？
千万不要！任何技术都有它的适用边界和副作用。滥用 CoT，不仅不会提升效果，反而可能拖累结果。
必须清醒地认识到 CoT 的失效模式和反作用。
先看失效模式一，对于简单任务，CoT 是多余的。CoT 的核心价值在于分解复杂性。如果一个任务本身就足够简单，一步就能搞定，偏要让它“一步步思考”，会发生什么？
最直接的是增加不必要的延迟和成本，模型为了“思考”，会生成大量额外的 Token，这直接导致了更高的费用和更长的等待时间。还可能引入错误，有时候，模型为了凑够“步骤”，会把简单问题复杂化，反而在这个过程中引入了错误。
那么，哪些任务属于“简单任务”？简单的事实检索算一类，像“中国的首都是哪里？”这种问题，让它一步步思考，它可能会输出一长串不必要的推理步骤，这就很没必要。简单的分类或判断也算，比如“这句话是正面的还是负面的？”模型通常可以直接“凭直觉”一步给出答案。还有简单的文本转换，比如格式转换、简单的翻译。
对于这些任务，一个清晰的 Zero-shot 或 Few-shot Prompt，效果通常比 CoT 更好、更快、也更便宜。
再看失效模式二，对于创造性任务，CoT 可能起反作用。CoT 的本质是一种逻辑驱动的、收敛性的思维模式。它擅长在有固定路径的问题上，进行严谨的推导。
但是，对于那些需要发散性思维的创造性任务，CoT 可能会起到反作用。
比如，让模型“写一首关于月亮的诗”。 如果加上“请一步步思考”，它可能会这么做： “第一步：确定诗歌的主题，月亮。第二步：选择意象，如玉盘、嫦娥、桂树。第三步：构建诗歌的结构，如起承转合……”
可以看到，它把写诗变成了按模板组装文字。这样写出来的诗，技术上可能没问题，但大概率格式雷同，缺乏真正的“诗意”。
真正的诗歌创作，往往是非线性的、跳跃的、充满直觉的。强行用 CoT 的线性步骤去约束它，反而会限制模型的创造力。
最后是失效模式三，对于模型“知识盲区”的问题，CoT 会导致“一本正经地胡说八道”。这是 CoT 最危险的一个陷阱。
CoT 只能帮助模型更好地利用它已有的知识进行推理，但它不能创造出模型本身就不知道的知识。
如果一个问题超出了模型的知识范围，或者模型对某个知识点的记忆是错误的，那么 CoT 不仅不会有帮助，反而会让它的“幻觉”看起来更具说服力。
比如，问一个没怎么学过最新医学知识的模型：“请一步步分析一下，用’量子纠缠疗法’治疗癌症的可行性。”（注意，这是一个虚构的概念）
模型可能会煞有介事地开始它的“思维链”： “第一步：理解‘量子纠缠疗法’的原理。它利用了量子纠缠的超距作用，来靶向性地破坏癌细胞的 DNA 结构……第二步：分析其优势。相比于传统化疗，它没有副作用，且效率极高……第三步：结论。因此，‘量子纠缠疗法’是一种极具前景的癌症治疗方案。”
它的每一步“推理”看起来都头头是道，逻辑自洽。但因为出发点（“量子纠缠疗法”的原理）就是它自己瞎编的，所以整个推理过程，就是一场“一本正经地胡说八道”。
这种带有“思考过程”的幻觉，比直接给一个错误答案，要危险得多，因为它极具迷惑性。
所以请务必记住，在不确定模型是否拥有某个领域准确知识的情况下，要对它的 CoT 输出保持高度的警惕和怀疑。
归结起来，简单、直观、一步可达的任务，需要发散性、创造性、直觉性思维的任务，以及涉及模型可能存在知识盲区或错误记忆的专业领域问题，这三类都不该用 CoT。
CoT 适合解决有明确推导路径的问题，不适合简单任务，也不适合创造性任务。学会判断什么时候该用、什么时候不该用，是一个高级工程师的必备素养。
9.6 准确率与 Token 成本的取舍
再来聊一个非常现实、也非常“功利”的话题，成本。
推理增强，无论是 CoT、ToT 还是 PS，之所以能提升效果，根本原因之一就是增加了计算量，也就是消耗了更多的 Token。
模型每生成一个思考步骤的 Token，都对应实际的费用和延迟。
这就带来了一个经典的工程权衡（Trade-off），愿意为了提升多少准确率，而付出多大的成本（Token 消耗和延迟增加）？
不妨搭一个简化的成本模型。假设一个任务，用 Zero-shot Prompt 需要 100 个 Token，准确率是 60%。引入 Zero-shot CoT，模型的输出变成了“思考过程 + 答案”，总共消耗 500 个 Token，准确率提升到 80%。再引入 Manual CoT，因为示例很长，总消耗变成 1500 个 Token，准确率提升到 90%。还不满足，上了 ToT，需要进行 3 次 LLM 调用，总消耗达到 3000 个 Token，准确率终于达到 95%。
那么，该选择哪个方案？
这个问题没有标准答案，完全取决于业务场景和商业模式。
先看场景一，高价值、低容错的领域。如果在做一个医疗诊断辅助系统，或者一个法律合同审查工具，在这种一旦出错就可能危及生命，或者要赔大钱的领域，准确率是压倒一切的。哪怕成本增加十倍，只要能把准确率从 90% 提升到 95%，都应该毫不犹豫地上最复杂的 ToT 架构。因为一次误判带来的损失，可能远远超过一年付给 OpenAI 的 API 费用。
再看场景二，高并发、低客单价的领域。如果在做一个免费的、面向大众的聊天机器人，每天有上亿次的调用，在这种场景下，成本就是第一约束。哪怕 CoT 能带来 10% 的效果提升，但如果它让单次请求成本翻了五倍，这个方案在商业上就是不可行的。更合理的选择是一个效果稍差、但成本极低的 Zero-shot 方案，然后通过其他方式（比如更好的产品设计）来弥补体验上的不足。
场景三是人类在环（Human-in-the-loop）。如果应用是一个代码助手，或者一个文案润色工具，在这种场景下，最终的决策者是人，AI 犯点小错没关系，用户可以自己修正。那么，目标就不是追求 100% 的准确，而是最大化地提升用户的“工作效率”，可能会选择一个延迟最低、响应最快的方案（比如简单的 CoT），哪怕它偶尔会出错。因为对于用户来说，一个秒回但需要微调的建议，可能比一个思考半天但完美的建议，体验更好。
作为工程师，职责不仅仅是追求技术上的“最好”，更要追求在约束条件下的“最优”。在推理成本方面，有一些常用的优化策略。
头一条是模型级联（Model Cascade）。不要用一个旗舰级的模型去解决所有问题，可以设计一个分层级联的结构，先用一个极快、极便宜的小模型（比如各家闭源厂商的 mini/Haiku 档位，或者本地部署的开源小模型）把大量简单请求先接住；如果小模型判断自己“搞不定”，再把这个请求“升级”给更强大、更昂贵的旗舰模型来处理，并开启 CoT。这个分层思路到 2026 年中依然是工程界的标配，只不过具体的“小模型”和“旗舰”档位每隔几个月就会刷新一次，建议按当下的各家官方模型表重新选型。
另一条是结果缓存（Result Caching）。对于那些重复性高的问题，把第一次用 CoT 计算出的高质量答案缓存起来。下次再遇到同样的问题，直接从缓存里返回，零成本，零延迟。
还可以压缩思考过程的长度。在设计 Manual CoT 的示例时，尽量让“思考过程”言简意赅，删除所有不必要的冗余内容。示例里的每一个 Token，都会在未来的每一次调用中反复产生成本。
最后是异步执行与流式输出（Async & Streaming）。对于需要长时推理的任务，不要让用户傻等。先把任务扔到后台异步执行，同时通过 WebSocket 或 SSE，把模型的“思考过程”流式地输出到前端。这样，用户就能实时地看到 AI“正在思考”，体验会好很多。
最终，成本和效果的权衡没有统一答案，需要在技术目标和商业现实之间找到平衡点。
9.7 CoT 示例的自动化生产
读到这儿，可能会有点疑问。Manual CoT 效果是好，但“手写示例”这事儿，听起来就是个体力活啊。要是手头有几百个不同领域的问题，难道每个领域都要手搓一份高质量的示例集吗？
这种“懒人式”的合理怀疑，研究者们当然也想到了。CoT 这条技术线，在 2022 到 2024 年之间，又陆续出现了几个新的分支。它们的核心目标基本都是同一件事，让 CoT 的高质量示例，不再依赖纯人工。
先看 Auto-CoT，它让模型自己造示例。最早让这条思路流行起来的，就是 Zhang 等人的这项工作（2022 年提出、ICLR 2023 发表，arXiv:2210.03493，上海交通大学与 Amazon 的合作团队）。它的做法分两步，干净利落。
第一步叫“问题聚类”。把手里这批待解决的问题用 Sentence-BERT 编码成向量，再交给 K-Means 聚类，让相似的问题自动分到一组。
第二步叫“示范采样”。在每个聚类里，从离聚类中心最近的问题挑起，用 Zero-shot CoT 让模型自己生成一份推理链和答案；挑样时靠两条简单的启发式把关，问题不超过 60 个 token、推理链不超过 5 步，因为又长又绕的示例更容易出错，不合格就换下一个。这条流水线并不依赖标准答案，个别混进来的错误示例也无伤大雅，论文的实验显示 8 个示例里错上一两个并不拖累整体效果。
最后把这些“自造”的 (问题, 推理链, 答案) 三元组拼成 Prompt，去推真正的测试问题。论文里有个挺关键的实验发现，示例的多样性比示例的相似度更重要，与其按相似度扎堆挑一堆相近的问题，不如从不同的聚类里各挑 1 个。
这套思路的好处是显而易见的，不再需要请人一条条地“手写”CoT 示例，也不依赖任何标注答案，只需要准备一批问题，剩下的事交给流水线。代价是它的效果通常略逊于精心手写的 Few-shot CoT，但在多任务、大批量场景下，绝对是性价比之选。
另一条值得一提的分支，是 Zhou 等人 2022 年提出的 Least-to-Most Prompting（arXiv:2205.10625，Google Research），思路是从“易到难”拆解。它解决的是另一类问题，当一个任务需要“层层递进”的推理时，怎么才能保证第一步的小错误不带歪模型？
它的核心思想特别朴素，先拆，再做。先让模型把原问题拆解成一个“子问题列表”，从最简单的开始排起；再让模型先解决最简单的那个子问题；然后把上一个子问题的答案，作为下一个子问题的已知条件，接着去解下一个；到了最后一步，把所有子问题的答案串起来，给出最终答案。
这套思路在那些需要“组合推理”的任务上效果尤其突出，比如在 SCAN 这类组合泛化（compositional generalization）基准上，Least-to-Most 只用 14 个示例，就能让 GPT-3 code-davinci-002 在包括 length split 在内的所有切分上拿到至少 99% 的准确率，而普通思维链提示在同一个模型上只有 16% 左右。它也给“复杂任务分解”提供了一种特别优雅的 Prompt 模板，前面 Plan-and-Solve 里看到的“先列计划再执行”的思路，其实和 Least-to-Most 是同根同源的。
还有一条值得提的，是 Madaan 等人 2023 年的 Self-Refine（arXiv:2303.17651，CMU 与 Allen Institute for AI 等机构），它让模型对自己的输出给出反馈并修订。Self-Refine 自动化的是另一个环节，不是造示例，而是让模型把自己生成的答案打回重做。
先生成一个初始答案，再让模型针对这个答案写一段“批评意见”（feedback），然后把“原始答案 + 批评意见”一起喂回去，让模型“修订”出一个新答案。论文报告在 7 个任务上，经过最多 4 轮这样的“生成-批评-修订”循环，模型效果平均能有约 20 个百分点的绝对提升。
Self-Refine 和第 11 章要讲的 Self-Critique（自我批评）、Reflexion（反思框架）这一脉属于同一类“自检自修正”方法。区别在于 Self-Refine 更轻，不需要外部记忆模块，论文的分析显示大部分提升来自最初几轮迭代，再往后边际收益递减；而 Reflexion 走的是“长时记忆 + 多轮演化”的路子，更适合 Agent 这种多步骤场景。
这条演进线可以用一句话来总结。从 Manual CoT 到 Zero-shot CoT，解决的是“示例的必要性”问题；从 Manual CoT 到 Auto-CoT，解决的是“示例的生产成本”问题；Least-to-Most 解决的是“子问题的依赖性”问题；Self-Refine 解决的是“模型自己发现错误”的问题。这几个方向，本质上都在回答同一个问题，怎么让模型在不需要人工编写示例的情况下，自己变得更强。
到 2026 年回头看，CoT 早已不是“一个技巧”那么简单，它已经演化成了一个技术家族。但万变不离其宗，所有这些 CoT 变体的核心，依然是“让模型把思考过程外化成文本，再交给模型自己（或另一个 LLM）去审视和迭代”。理解了这一点，也就抓住了这一系列技术的共同基础。
9.8 推理模型时代的提示工程
前面七节的所有技巧，都建立在同一个前提上，模型的思考过程要靠 Prompt 引出来。2024 年 9 月之后，这个前提开始动摇。OpenAI 发布 o1，把推理做进了模型内部；DeepSeek 在 2025 年 1 月开源 R1，把这条路线带进开源世界；Claude、Gemini 与各家国产旗舰随后陆续提供深度思考能力。业界把这类模型统称为推理模型（Reasoning Model）。拿到问题后，模型先生成一段内部推理，再给出最终答案，这段推理不依赖 Prompt 里的任何触发语。
这一变化没有让提示工程失效，但改写了规则。这一节讲清四件事，推理模型上提示词该怎么写，思考的深度怎么调，Agent 场景里推理怎么跟着工具调用走，最后讲一条反方向的路线，把推理写短。
提示词要变简单，而不是更精巧
9.2 节那句“请一步步思考”，在推理模型上从必需变成了多余。OpenAI 在官方最佳实践里写得很直白，“这类模型配合直截了当的提示效果最好。让模型‘一步一步思考’这类提示工程技巧，可能不会提升表现，有时反而有害。”原因不难理解。思维链本来就是模型内部正在做的事，再在 Prompt 里要求一遍，轻则冗余，重则干扰模型自己的推理节奏。
OpenAI 的建议归纳起来是四条。提示保持简短直接，把目标、约束和参考材料用 markdown 标题或 XML 标签分段呈现；先写零样本版本，效果不够再考虑少样本，而且示例必须与指令完全一致，两处稍有出入就会拉低效果；把最终目标写得非常具体，越具体越好；不要再用“请展示推理过程”去要求模型交代内部思考。另外从 o1-2024-12-17 版本起，系统消息改叫开发者消息（developer message），行为对齐模型规范里的指令链。
DeepSeek 的建议同向而更具体。R1 的模型论文明确说，调用 R1 最好不设系统提示，把全部指令放进用户消息；少样本示例会一致性地降低它的表现；采样温度建议设在 0.5 到 0.7 之间（论文推荐 0.6），取值过低可能导致重复循环。两家的口径合在一起，指向同一个判断，Prompt 里那些为了引导思考而设计的复杂结构，在推理模型上大部分可以拆掉。
Prompt 的价值转移到了别处。OpenAI 官方把多步 Agent 规划列为推理模型的核心用法之一，让推理模型当规划者，把复杂任务拆成多步方案，再按“要高智能还是要低延迟”把每一步指派给合适的通用模型去执行。这正好接上 9.6 节的模型级联，级联的两端不再只是“大模型与小模型”，还可以是“推理模型与通用模型”。
还有一条边界要划清。9.5 节讲的三类失效场景，推理模型只解决了第一类。简单任务不值得深想，这个问题厂商用参数解决了（下一小节展开）；但知识盲区依然无解，内部推理再长，也造不出模型本身不具备的知识。“一本正经地胡说八道”在推理模型上同样存在，只是推理过程看不见了，迷惑性反而更强。
思考预算：把推理深度变成参数
思考预算指允许模型在给出答案前消耗多少推理 token 的控制量。在通用模型上，推理深度只能靠 Prompt 间接影响，示例写多长、要不要触发语，都是间接手段；推理模型把它变成了 API 里的显式参数，深度第一次可以精确设定。
OpenAI 用 reasoning.effort 参数控制，取值随模型而异，从 none、minimal、low、medium、high 到 max 分挡，GPT-5.5 默认 medium。挡位低响应快、token 少，挡位高推理更充分，而且模型会自适应，简单问题即使挡位设高也不会空转。
Anthropic 的路线是 2025 年 2 月随 Claude 3.7 Sonnet 引入扩展思考（Extended Thinking）。官方称之为市场上第一个混合推理模型，同一个模型既能秒回也能深思，API 用户可以用 budget_tokens 给思考设上限。到最新一代模型，思考默认开启，控制手段演进为 effort 挡位（从 low 到 max，默认 high），一次设定同时影响思考深度、正文长度和工具调用次数。
学术研究把这个方向推到了极端。斯坦福团队 2025 年 1 月发布 s1 论文（arXiv:2501.19393），标题就是 Simple test-time scaling。团队按难度、多样性、质量三条标准筛出 1000 道题，配上推理轨迹构成数据集 s1K，用它微调 Qwen2.5-32B-Instruct 得到 s1-32B。这个 320 亿参数的模型，在 MATH 和 AIME24 两项竞赛数学基准上超过 o1-preview 最多 27%。论文更重要的贡献是一种新手段，称为预算强制（Budget Forcing）。
具体做法分两个方向。模型想提前结束时，拦截它的结束令牌，让它继续推理；反过来，模型打算收尾而预算还没用完时，就在输出末尾追加一个“Wait”，模型会回头检查已有的推理，经常在这一步发现并改正错误。加大测试时的预算，s1-32B 在 AIME24 上的准确率从 50% 提升到 57%。这项研究确立了一个正式的研究方向，即测试时扩展（Test-time Scaling），准确率可以拿测试阶段的算力来换。
这对工程的意义，是直接改写了 9.6 节的成本模型。过去在“写不写 CoT”之间二选一，现在多了一个可以连续调节的参数。线上服务可以把简单请求的预算调低、疑难请求调高，9.6 节的模型级联策略天然升级成按预算分级。各家厂商普遍把推理 token 按输出计价，预算调多少，账单就乘多少，这是一挡必须盯着监控数据来调的参数。
交错思考：推理跟着工具调用走
一个典型的检索 Agent 会连续调用工具。查知识库、查订单系统、查物流接口，每拿到一批结果，就要决定下一步是补查、换关键词，还是直接作答。
传统的工具循环在这里有个弱点。模型开场思考一次，之后连续发起调用，中间拿到的结果不再触发新的推理，流程容易变成照着开场计划机械执行。工具返回的数据一旦和预期对不上，比如订单接口报错、检索结果没覆盖问题的主干，模型还是按原计划往下走，错误就这样积累起来。
解决这个问题的是交错思考（Interleaved Thinking）。它让模型在两次工具调用之间插入推理，先消化刚拿到的结果，再决定下一步动作。Anthropic 从 2025 年 5 月的 Claude 4 系列开始提供交错思考，在后续模型的自适应思考模式下默认生效，不需要额外的 beta 头；在手动扩展思考模式下，则要带专门的 beta 头。官方文档同时强调一个工程细节，工具调用回合里要把模型生成的思考块原样传回 API，思考过程才能跨调用延续。
OpenAI 用另一套机制回答同一个问题。从 o3 与 o4-mini 起，推理模型把部分推理项随函数调用保留进上下文（配合 Responses API 的 store 参数），官方建议把上一次函数调用到上一条用户消息之间的推理项全部传回，这样模型不必每次都从头重启推理。两家做法殊途同归，都在保证一件事，思考过程要跟着工具调用链留存。
提示工程的写法也跟着变了。系统提示里“请一步步分析”这类引导语的用处变小，真正起作用的是那些规定核验时机的句子，比如“每次拿到检索结果，先判断它是否覆盖了问题的全部要点，缺什么补查什么，覆盖够了再作答”。推理的深度交给了模型，什么时候该停下来核验、什么时候该再想，交给了 Prompt。
Chain of Draft：把推理写短
前三小节讲的都是想得更多，2025 年还出现了一条反方向的路线，把推理写短。
它的代表是 Chain of Draft（CoD）。这一方法由 Xu 等人 2025 年 2 月提出（arXiv:2502.18600），论文标题直译过来是“想得更快，写得更少”。它针对的是思维链的一个副作用，思考过程写得越像文章，冗余就越多，而计费和延迟算的是每一个 token。CoD 让模型把中间推理压缩成极简草稿，每一步只保留推进所必需的关键信息。论文在 GSM8K 数学应用题、体育常识、日期理解、掷硬币四类基准上做了实验，CoD 的准确率与标准 CoT 持平或更高，token 消耗最少只用到后者的 7.6%，成本和延迟随之大幅下降。
照这个思路可以搭一版中文模板，约束写在头部，示例居中，新问题收尾。
markdown
### 任务：解答数学应用题
请用草稿链方式解题。每步草稿控制在 15 个字符以内，只记关键中间量，
不要写完整句子。所有草稿写完后，另起一行给出最终答案。
#### 示例
问题：商店进了 12 箱苹果，每箱 24 个，卖出 150 个后还剩多少个？
草稿：12×24=288；288-150=138
答案：138 个
#### 新问题
问题：{question}
草稿：CoD 的收益在三类场景最明显。高并发的线上服务，token 直接换算成账单，草稿省下的每一个字都是钱；延迟敏感的实时应用，中间输出短一截，用户等待就短一截；还有没有内置推理的通用模型，CoD 用一条指令给它们补上轻量的推理环节，又不用付出完整思维链的成本。
它与思考预算解决的是同一个问题，方向相反。思考预算管想多久，CoD 管想出来的东西写多细。对推理模型，厂商已经用参数控制内部思考的长度；CoD 最适合的场景在通用模型，以及需要把推理过程展示出来的地方。比如教育类应用要把解题步骤呈现给学生，步骤写得短，学生才跟得上。9.6 节讲过的“压缩思考过程的长度”这条老策略，到这里有了一个有论文、有数据、有模板的具体方法。
到这里，第 9 章的技术线从 2022 年的两篇 CoT 论文，一路延伸到思考预算、交错思考和草稿链。四年里规则一直在变，主线始终没变，推理的深度、位置和长度，都是工程师可以设计的对象。
本章总结 从会用到善用
这一章讲的是大语言模型的“推理能力”，这是 Prompt Engineering 中变化最显著的部分之一。
起点是 2022 年那两篇论文（Wei 等人的少样本 CoT、Kojima 等人的零样本触发语），它们让全行业第一次看到：思维链（CoT） 让模型输出思考过程，把复杂的推理任务转化为它擅长的、一步步的文本生成。落到工程里，有两条路：简单直接的 Zero-shot CoT，一句触发语就能启动推理；强大可控的 Manual CoT，用示例教会模型按专业范式思考。
当单条推理路径不够用时，ToT 和 GoT 把思考扩展成可以探索、评估、回溯甚至合并的多路径结构；Plan-and-Solve 模式则用“先规划后执行”的两步换来对复杂任务的全局把控。但工具多了更要清醒，简单任务、创造性任务、模型的知识盲区，这三类场景里滥用 CoT 只会起反作用。最后别忘了成本，Token 是要花钱的，模型级联、结果缓存、压缩思考长度这些策略，和推理技术本身同样重要。
2024 年 9 月之后，这条线又往前走了一大步。推理模型把思维链搬进了模型内部，提示词要做的是变简单而不是更精巧；思考预算、交错思考、草稿链，则接管了思考的深度、位置和长度的控制权。
学完这一章，对 Prompt 的理解应该已经超越了“如何清晰地表达指令”的层面，开始掌握一种更强大的能力，如何设计和引导模型的思考过程。
换句话说，Prompt 的角色变了，它不再只是传达要求的文本，而是变成了规定模型推理方式的输入。
当然，推理的世界远比这一章所能涵盖的要广阔得多。但掌握了 CoT 这个核心思想，后续的高级推理技术就都有了一个共同的基础。
参考资料
- Wei, J. et al. (2022). Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. NeurIPS 2022. arXiv:2201.11903. https://arxiv.org/abs/2201.11903
- Cobbe, K. et al. (2021). Training Verifiers to Solve Math Word Problems. arXiv:2110.14168. https://arxiv.org/abs/2110.14168
- Kojima, T. et al. (2022). Large Language Models are Zero-Shot Reasoners. NeurIPS 2022. arXiv:2205.11916. https://arxiv.org/abs/2205.11916
- OpenAI (2024). Introducing OpenAI o1-preview. 2024-09-12. https://openai.com/index/introducing-openai-o1-preview/
- Yao, S. et al. (2023). Tree of Thoughts: Deliberate Problem Solving with Large Language Models. NeurIPS 2023. arXiv:2305.10601. https://arxiv.org/abs/2305.10601
- Besta, M. et al. (2023). Graph of Thoughts: Solving Elaborate Problems with Large Language Models. AAAI 2024. arXiv:2308.09687. https://arxiv.org/abs/2308.09687
- Wang, L. et al. (2023). Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models. ACL 2023. arXiv:2305.04091. https://arxiv.org/abs/2305.04091
- LangChain Blog. Plan-and-Execute Agents. https://www.langchain.com/blog/planning-agents
- Zhang, Z. et al. (2022). Automatic Chain of Thought Prompting in Large Language Models. ICLR 2023. arXiv:2210.03493. https://arxiv.org/abs/2210.03493
- Zhou, D. et al. (2022). Least-to-Most Prompting Enables Complex Reasoning in Large Language Models. ICLR 2023. arXiv:2205.10625. https://arxiv.org/abs/2205.10625
- Madaan, A. et al. (2023). Self-Refine: Iterative Refinement with Self-Feedback. NeurIPS 2023. arXiv:2303.17651. https://arxiv.org/abs/2303.17651
- OpenAI. Reasoning: Best Practices（o 系列推理模型的官方提示指南）. https://developers.openai.com/api/docs/guides/reasoning-best-practices
- DeepSeek-AI (2025). DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. arXiv:2501.12948. https://arxiv.org/abs/2501.12948
- Muennighoff, M. et al. (2025). s1: Simple test-time scaling. arXiv:2501.19393. https://arxiv.org/abs/2501.19393 ；开源代码 https://github.com/simplescaling/s1
- Anthropic (2025). Claude 3.7 Sonnet: Frontier reasoning made practical（扩展思考与思考预算控制）. https://www.anthropic.com/news/claude-3-7-sonnet
- Anthropic. Thinking（Claude Platform Docs，自适应思考、effort 挡位与交错思考）. https://platform.claude.com/docs/en/build-with-claude/thinking
- Xu, S., Xie, W., Zhao, L., & He, P. (2025). Chain of Draft: Thinking Faster by Writing Less. arXiv:2502.18600. https://arxiv.org/abs/2502.18600 ；开源代码 https://github.com/sileix/chain-of-draft