如何赋予 LLM 规划能力？

LLM 默认会"一口气"生成答案，遇到多步推理任务容易跳步出错。规划能力要做的就是把隐式推理过程显式化。本文从 CoT、ToT、GoT 到工程里真正常用的 Plan-and-Execute，把 LLM 规划能力的原理、演进、成本与选择方法讲清楚。

CoT ToT GoT Plan-and-Execute 多步推理

1. 为什么 LLM 需要规划能力

普通问答模式下，LLM 接到问题后直接"一口气"生成答案，中间没有任何显式推理过程。这对简单问题没问题，但遇到需要多步推导的任务就很容易翻车。原因是 Transformer 的 next-token 预测机制：每个 token 都基于前面所有 token 生成，推理链越长、隐式跳步越多，误差越容易在中间某一步悄悄累积，最后给出一个"看起来很自信但其实错误"的答案。

规划能力要解决的问题：把 LLM 隐式的推理过程显式化，让它不再是"一步跳到答案"，而是"一步一步推到答案"，每步都有迹可循。

图 1 · 无规划：跳步易错；有规划：每步显式推导，可校验

2. LLM 规划能力路线图

给 LLM 加规划能力主要有四条路：从最简单、零成本的 CoT，到支持多路径探索的 ToT，再到支持中间结果复用的 GoT，最后到工程里真正常用的 Plan-and-Execute。它们的复杂度和落地成熟度依次递增/递减。

图 2 · 规划能力路线图：CoT → ToT → GoT → Plan-and-Execute

3. CoT：把推理步骤写出来

Chain-of-Thought（思维链）的核心思路极其简单：在 prompt 里加一句"请一步步思考"，LLM 就会把推理过程逐步写出来，而不是直接蹦出答案。

3.1 为什么有效

LLM 的输出是顺序生成的。当它先输出推理步骤，这些推理内容会进入上下文，影响下一个 token 的生成。换句话说，"写下来的推理过程"本身就成为了后续生成的依据，帮助 LLM 不跳步、不乱想。就像你在纸上演算数学题，把每一步写出来之后，下一步出错的概率比在脑子里算要低得多。

3.2 两种触发方式

Zero-shot CoT

直接在 prompt 末尾加一句"让我们一步步思考"，LLM 自己展开推理，不需要额外例子。

Q: 小明有 10 个苹果，给了小红 3 个，又买了 5 个，还剩多少？
A: 让我们一步步思考。

Few-shot CoT

给几个带有完整推理过程的例子，让 LLM 模仿这种推理格式来回答新问题，效果通常更稳定。

示例1：问题 → 推理步骤 → 答案
示例2：问题 → 推理步骤 → 答案
新问题：…

3.3 CoT 的局限：单一路径风险

CoT 只有一条推理路径。如果一开始走错了方向，整条链就歪了，没有任何纠偏机制。

图 3 · CoT 的局限：只有一条路径，走错无法回头

4. ToT：从一条链到一棵树

Tree of Thoughts（思维树）针对的正是 CoT"一旦走错就全错"的问题。核心改变是：把"生成一条推理链"变成"同时探索多条推理路径，边探索边剪枝，最终选出最优路径"。

4.1 类比理解

CoT 像做题时只想了一个解法，一路做到底；ToT 像你先想了三种可能的解题思路，评估了一下哪种最靠谱，选了最好的那条继续深入，另外两条直接放弃。

4.2 ToT 的三步流程

🌱

生成候选思路

让 LLM 针对同一个问题给出多个不同的初步方向，而不是只走一条路。

⚖️

评估与剪枝

对每个候选方向打分或评估，保留最有希望的，舍弃明显错误的路径。

🎯

深入最优路径

沿着评估后最好的路径继续展开，直到得到最终答案。

图 4 · ToT：同时探索多条路径，评估后剪枝并深入最优路径

工程代价：ToT 效果好，但典型调用次数是 CoT 的 3~5 倍（具体看路径数和探索深度）。在面试或方案讨论中，必须明确说出这个数字。

5. GoT：从树到图，解决中间结果复用

Graph of Thoughts（思维图）是 ToT 的进一步进化。ToT 虽然引入了多路径探索，但它是树形结构：不同分支之间完全独立，两条推理路径上的中间结论无法互相借用。

GoT 把推理结构换成了图：允许不同路径的中间结果合并、复用，一个推理节点可以接收来自多个前置节点的输出作为输入。这更接近人类处理复杂任务的思考方式。

图 5 · GoT：把树升级为图，支持中间结论的汇聚与复用

GoT 示例：任务"分别研究竞品 A 和竞品 B，然后做综合对比分析"。在 ToT 中研究 A 和研究 B 是两条独立路径；在 GoT 中，研究 A 和研究 B 的输出可以自然汇聚到"综合对比分析"节点，这种"多输入合并"在图里是一等公民。

落地现状：GoT 能建模的推理模式比 ToT 更丰富，但实现复杂度高、工程落地不成熟，目前主要还是学术研究场景，真实项目里极少真正用起来。

6. 三种机制演进关系

把 CoT、ToT、GoT 放在演进视角看，逻辑非常清晰。每一步都在解决前一个机制的局限性：

🔗

CoT

解决"要不要把推理显式化"：把过程写出来，显著减少跳步出错。

🌳

ToT

解决"走错方向怎么办"：先多探索几条路，边走边评估边剪枝。

🕸️

GoT

解决"不同路径的中间结论能不能复用"：把结构从树换成图，自然支持汇聚。

机制	结构	核心能力	成本	落地成熟度
CoT	线性链	把推理步骤显式写出来	★ 几乎零成本	生产标配
ToT	树	多路径探索、评估、剪枝	★★★ 3~5× CoT	复杂高准确场景可用
GoT	图	中间结果合并、复用	★★★★ 更高	学术研究为主

图 6 · CoT → ToT → GoT：能力增强，但成本和复杂度同步上升

7. 工程里真正常用的：Plan-and-Execute

CoT、ToT、GoT 说的都是"怎么让 LLM 把推理过程做得更好"，但在真实的 Agent 项目里，还有一种更贴近工程实践的规划模式：Plan-and-Execute（先规划再执行）。

7.1 核心思路

面对一个复杂任务，先让 LLM 制定一份完整的执行计划，把任务拆成若干步骤，然后一步一步执行，每完成一步就检查一下进度，必要时调整后续计划。可以理解为"先写大纲再动笔"，而不是拿到题目就开始一口气往下写。

7.2 为什么需要 Plan-and-Execute

CoT 虽然是逐步推理，但它是"边想边做"的，走到哪算哪，没有全局视角。对于一个需要调用多个工具、经历多个环节的复杂任务，如果没有整体规划，LLM 很容易在某一步跑偏，后面的步骤全都白费。

图 7 · Plan-and-Execute：规划与执行分离，执行反馈驱动动态重规划

7.3 与 ReAct 的关系

ReAct 是"每步都先思考再行动再观察"的循环模式，特点是即时决策、没有提前规划。Plan-and-Execute 则是在 ReAct 基础上加了一层全局规划：ReAct 负责每一步怎么执行，Plan-and-Execute 负责这些步骤的整体编排和动态调整。两者不是替代关系，而是经常搭配使用。

工程优势：规划和执行分离后，规划阶段可以用更强的模型（如 GPT-4）保证方向正确，执行阶段可以用更快更便宜的模型提高效率，成本和质量可以分别优化。LangGraph 等框架已内置对这种模式的支持。

8. 工程上怎么选

选择规划机制时，不能只讲原理，必须把工程成本和适用场景说清楚。这是面试和方案设计里最加分的部分。

场景	推荐机制	理由
绝大多数推理任务	CoT	零成本，加一句 prompt 就行，直接加到 system prompt 里作为标配。
准确率要求高、任务较复杂、可能走错方向	ToT	效果好，但调用成本是 CoT 的 3~5 倍，需要做好心理准备和预算。
复杂任务需要多工具/多环节协同	Plan-and-Execute	工程主流，先全局规划再执行，支持动态调整。
需要复用不同路径的中间结论	GoT	思想先进，但工程落地不成熟，真实项目不必强行引入。

面试加分回答模板：
"给 LLM 加规划能力，首选 CoT，因为零成本且效果显著；如果任务复杂且对准确率要求高，考虑 ToT，但要接受 3~5 倍的调用成本；在 Agent 工程里更常用 Plan-and-Execute，先规划再执行并动态重规划；GoT 目前偏学术，了解思想即可，生产环境不建议强上。"

常见误区：把"CoT 就是规划能力"画等号。实际上规划能力是一个方向，CoT 只是最基础的一种实现手段。ToT、GoT、Plan-and-Execute 都是在 CoT 基础上针对不同局限性的改进。

9. 一句话总结

🎯 LLM 的规划能力 = 把隐式推理显式化。
CoT 解决"要不要把推理写出来"；
ToT 解决"走错方向怎么纠偏"；
GoT 解决"不同路径的中间结论能不能复用"；
Plan-and-Execute 是工程里真正常用的"先规划、再执行、动态调整"模式。

工程上：CoT 标配，ToT 按需，GoT 了解即可，Plan-and-Execute 做复杂任务。