「AI Agent」如何赋予 LLM 规划能力：CoT、ToT、GoT 与 Plan-and-Execute
0 前言
本文内容整理自公众号「小林面试笔记」的文章 14. 如何赋予 LLM 规划能力？，用于记录与总结 AI Agent 相关的核心面试知识点。
「如何赋予 LLM 规划能力？」，可以这样作答：
所谓规划能力，就是让 LLM 面对复杂、多步骤的任务时，先把隐式的推理过程显式化、再按步骤推进，而不是「一口气」直接蹦出最终答案。因为普通问答模式下 LLM 是直接生成结果，多步推导任务容易跳步出错，规划机制正是为了解决这个「隐式跳步」的问题。
具体有三条逐渐升级的「思维」路线：CoT（思维链） 最简单，在 prompt 里加一句「请一步步思考」，让 LLM 把推理过程写出来，但它只有一条路径，一开始走错就全错；ToT（思维树） 针对这个局限，同时探索多条路径、边评估边剪枝，选优继续深入，代价是典型调用量是 CoT 的 3-5 倍；GoT（思维图） 再把树换成图，让不同路径的中间结论可以合并、复用，适合多结论汇聚的复杂任务，但目前以学术研究为主。
工程上真正大量使用的其实不是这三种，而是 Plan-and-Execute（先规划再执行）：先让 LLM 制定一份完整的执行计划、把任务拆成步骤，再逐步执行、每步检查进度、必要时动态调整。它和 ReAct 是搭配关系——ReAct 负责每一步的即时思考与行动，Plan-and-Execute 负责整体的编排与动态调整。
生产级例子：Cursor 和 Claude Code 的「Plan Mode / 规划模式」，本质就是 Plan-and-Execute 的落地形态。Claude Code 的 /plan 模式会先读取项目上下文、把任务拆解成可执行的步骤清单并给出改动计划，等用户确认后再逐步实施；Cursor 的 Agent 规划模式同样先分析代码库、产出方案，获批后才动手。两者都遵循「先规划 → 确认 → 再执行 → 每步检查动态调整」的闭环——这正是「规划」机制在生产级 Agent 工具里的标准范式。
1 为什么需要规划能力：LLM 的「隐式跳步」问题
要理解为什么需要规划，先看 LLM 在没有规划机制时是怎么运作的。
普通问答模式下，LLM 接到一个问题，就直接「一口气」生成答案，中间没有任何显式的推理过程。这对简单问题没太大影响，但一遇到需要多步推导的任务就容易翻车——比如一道需要 3 步推导的逻辑题，直接让它给答案，出错概率要远高于让它把每一步都写出来。
背后的根源是 Transformer 的 next-token 预测机制：每个 token 都是基于前面所有 token 生成的，推理链越长、隐式的跳步越多，误差就越容易在中间某一步悄悄累积，最后给出一个「看起来很自信、其实是错的」答案。
所以「规划能力」要解决的核心问题，就是把 LLM 隐式的推理过程显式化——让它不再是「一步跳到答案」，而是「一步一步推到答案」，每步都有迹可循。
CoT、ToT、GoT 正是这个方向上依次演进的三种方案，每一个都在解决前一个的局限性。
2 CoT（思维链）：最朴素的激活方式
CoT 全称 Chain of Thought，核心思路极其简单：在 prompt 里加一句「请一步步思考」，LLM 就会把推理过程逐步写出来，而不是直接蹦出答案。
为什么这么简单的改动就有效？本质是因为 LLM 的输出是顺序生成的——当它先输出推理步骤，这些内容会进入上下文，成为后续生成的依据，帮助它不跳步、不乱想。这就好比在纸上演算数学题，把每一步写下来之后，下一步出错的概率远比纯心算要低。
CoT 有两种触发方式：
- Zero-shot CoT：不提供任何示例，直接在 prompt 里加「Let’s think step by step」之类的提示语，让 LLM 自己想出推理过程；
- Few-shot CoT：在 prompt 里给出几个「带完整推理过程」的示例，让 LLM 模仿示例的推理模式。
但 CoT 的局限也很明显：它只有一条推理路径。一旦一开始方向就走错了，整条链就歪了，没有任何纠偏机制——这是它最大的问题。
3 ToT（思维树）：边探索、边评估、边剪枝
ToT 全称 Tree of Thoughts，针对的正是 CoT「一旦走错就全错」的问题。
核心改变，是把「生成一条推理链」变成「同时探索多条推理路径，边探索边剪枝，最终选出最优路径」。用一个生活类比：CoT 像做题时只想了一个解法、一路做到底；ToT 像先想了三种可能的思路，评估哪个最靠谱，选最好的那条继续深入，另外两条直接放弃。
ToT 的执行流程可以拆成三步：
- 生成多个候选思路：针对同一个问题，让 LLM 给出多个不同的初步方向，而不是只走一条路；
- 评估可行性：用另一个 LLM 调用（或同一个 LLM 带上评估 prompt）给每个思路打分，判断哪个最有希望；
- 选优、剪枝、继续：只保留分数高的思路，再展开下一层推理，循环直到得出最终答案。
正是这个「生成 → 评估 → 剪枝」的循环，让 LLM 不再是「一条道走到黑」，而是有了探索多条路、走错了还能回头的能力。
代价也很直白：CoT 一次生成就完成，ToT 需要多次 LLM 调用（多条路径 × 多层深度 × 每层还要评估）。典型设置（每层 3 条路径、搜 2-3 层）下成本通常是 CoT 的 3-5 倍；极端场景（深搜、更多路径、每步都打分）可能到 10 倍以上。这个数字是面试里区分思考深度的关键考点。
4 GoT（思维图）：从「树」到「图」，结论可复用
GoT 全称 Graph of Thoughts，是在 ToT 基础上的进一步进化。
ToT 虽然引入了多路径探索，但它仍是树形结构：不同分支之间完全独立，两条路径上的中间结论无法互相借用。GoT 把推理结构换成图，允许不同路径的中间结果合并、复用——一个推理节点可以接收来自多个前置节点的输出作为输入。
举个具体例子：任务是「分别研究竞品 A 和竞品 B，再做综合对比分析」。在 ToT 里，研究 A 和研究 B 是两条独立路径、各自得出结论，但「综合对比分析」这一步需要同时用到两条路径的结论，而树的每个节点只有一个父节点，很难自然表达。GoT 的图结构则允许把「研究 A 的节点」和「研究 B 的节点」的输出，汇聚到「综合对比分析节点」——这种「多个中间结论合并输入到下一步」的操作，在图里是天然的一等公民。
GoT 能建模的推理模式比 ToT 更丰富，也更接近人脑处理复杂任务的真实方式。但落地复杂度很高，目前主要还是学术研究场景，生产环境极少见到真正用起来的。
5 三者的演进关系：显式化 → 纠偏 → 复用
把三者放在演进视角看，逻辑非常清晰，每一层都在解决上一层的遗留问题：
| 机制 | 解决的问题 | 结构 |
|---|---|---|
| CoT | 要不要把推理显式化？——要，写出来能显著减少跳步出错 | 一条链 |
| ToT | 走错方向怎么办？——多探索几条路，边走边评估边剪枝 | 一棵树 |
| GoT | 不同路径的中间结论能不能复用？——换成图，自然支持汇聚复用 | 一张图 |
工程上怎么选？CoT 几乎是所有任务的标配，加一句话、零成本，直接加进 system prompt 即可；ToT 在准确率要求高、任务复杂的场景值得考虑，但要接受调用成本增加 3-5 倍（极端更多）；GoT 目前工程落地不成熟，了解思想即可，真实项目不必强行引入。
6 工程主力：Plan-and-Execute（先规划再执行）
CoT、ToT、GoT 讨论的都是「怎么把单次推理做得更好」，但真实 Agent 项目里，还有一种更贴近工程实践的规划模式——Plan-and-Execute。
思路很直白：面对复杂任务，先让 LLM 制定一份完整的执行计划，把任务拆成若干步骤；再逐步执行，每完成一步就检查进度，必要时调整后续计划。可以理解成「先写大纲再动笔」，而不是拿到题目就一口气往下写。
为什么需要它？因为 CoT 是「边想边做」的，走到哪算哪，没有全局视角。对一个要调用多个工具、经历多个环节的任务来说，如果没有整体规划，LLM 很容易在某一步跑偏，后面的步骤全白费。Plan-and-Execute 的核心价值，就是用一次 LLM 调用先建立全局视角，再用后续调用逐步落地，把「规划」和「执行」分成两个阶段。
具体执行流程可分三步（对应三个角色）：
- Planner（规划器）：先制定完整步骤清单，明确每一步要做什么；
- Executor（执行器）：按清单逐步执行，每一步完成一个动作；
- Re-planner（重新规划器）：每走一步回顾进展，发现计划不合理就动态调整，再交给执行器继续。
它和 ReAct 是什么关系？ ReAct（Reasoning + Acting）是让 LLM 每一步都「思考 → 行动 → 观察」的循环模式，特点是每步即时决策、没有提前规划；Plan-and-Execute 则是在这之上加了一层全局规划。可以这样分：ReAct 负责每一步怎么执行，Plan-and-Execute 负责这些步骤的整体编排与动态调整。两者不是替代关系，而是经常搭配使用。
工程上的好处也很实在：规划和执行分离之后，规划阶段可以用更强的模型（如更强的旗舰模型）来保证方向正确，执行阶段可以用更快更便宜的模型提高效率，成本与质量可以分别优化。LangGraph 等框架也内置了对这种模式的支持。
7 要点回顾
回答「如何赋予 LLM 规划能力」这道题，把握好以下几个层次：
| 层次 | 要点 |
|---|---|
| 为什么需要规划 | 普通问答「一口气」生成答案，next-token 机制在多步任务上误差累积，规划本质是把隐式推理显式化 |
| CoT | 加「请一步步思考」，Zero-shot / Few-shot 两种触发；写下的推理成为后续依据；局限是单条路径、走错无法纠偏 |
| ToT | 生成 → 评估 → 剪枝 循环，多路径探索、选优深入；典型成本是 CoT 的 3-5 倍，极端 10 倍以上 |
| GoT | 树→图，中间结论可合并复用；适合多结论汇聚的复杂任务；目前学术为主 |
| 演进关系 | 显式化（CoT）→ 纠偏（ToT）→ 复用（GoT），层层解决上一层的局限 |
| 工程主力 | Plan-and-Execute：Planner 规划 → Executor 执行 → Re-planner 调整；与 ReAct 是「整体编排 + 每步决策」的分工搭配 |
答题时最容易被忽略、也最能加分的是工程取舍：CoT 几乎零成本、所有任务标配；ToT 效果更好但要明确说出「典型 3-5 倍、极端 10 倍」的调用成本；GoT 尚在学术阶段、生产不成熟。把工程成本和适用场景说清楚，比只讲原理要加分得多——再补上 Cursor / Claude Code 的 Plan Mode 这类「先规划 → 确认 → 再执行」的生产级例子，这道题就回答得很完整了。
参考
- 14. 如何赋予 LLM 规划能力？ | 小林面试笔记
- 6. ReAct、Plan-and-Execute、Reflection 三种范式有什么核心区别？ | 小林面试笔记（相关：三种推理范式）
- 15. 讲讲 Agent 的反思机制？为什么要用反思？具体怎么实现？ | 小林面试笔记（相关：反思机制）
本文图片均来源于公众号「小林面试笔记」，版权归原作者所有。