14. 如何赋予 LLM 规划能力面试官说说你是怎么给 LLM 加规划能力的♂️我规划能力主要靠 CoT就是在 prompt 里加一句「请一步步思考」让 LLM 把推理过程写出来就有规划能力了。面试官CoT 就是规划能力的全部你有没有想过 CoT 最大的问题是什么♂️我CoT 的问题……就是有时候推理链比较长token 消耗多一些面试官不对。CoT 是单条推理链一旦一开始方向走错后面全错没有任何纠偏机制。ToT 就是为了解决这个问题才出来的你知道 ToT 怎么做的吗♂️我ToT 是同时生成多条推理链然后选最好的那个类似于 beam search 的思路面试官方向对但不够准确。ToT 不是最后才选而是边探索边评估边剪枝是一个循环的过程。那 GoT 又比 ToT 多解决了什么问题你说说看被问到这里才发现「加个 CoT 就是规划能力」这个认知太浅了。三种机制是层层递进的搞清楚每一步在解决什么问题才是真正理解了规划能力。-简要回答给 LLM 加规划能力主要靠这几种思路。CoT 是让 LLM 把推理步骤写出来线性地一步步推导到答案ToT 是让它同时探索多条推理路径选最优的继续深入GoT 是图结构推理推理节点可以复用和合并适合更复杂的任务。工程上我用 CoT 最多因为实现成本最低就是改个 promptToT 效果更好但调用次数多成本大概是 3 到 5 倍GoT 目前还比较学术生产环境我没见过有人真正落地用的。-详细解析要理解为什么需要规划能力先看 LLM 在没有任何规划机制时是怎么运作的。普通的问答模式下LLM 接到一个问题就直接「一口气」生成答案中间没有任何推理过程。这对简单问题没啥大问题但遇到需要多步推导的任务就很容易翻车。比如让它做一道需要 3 步推导的逻辑题如果直接让它给答案出错概率会远高于让它把每步都写出来。背后的原因是 Transformer 的 next-token 预测机制每个 token 是基于前面所有 token 生成的推理链越长、隐式的跳步越多误差就越容易在中间某一步悄悄累积最后给出一个看起来很自信但其实是错的答案。「规划能力」要解决的就是这个问题把 LLM 隐式的推理过程显式化让它不再是「一步跳到答案」而是「一步一步推到答案」每步都有迹可循。CoT、ToT、GoT 是这个方向上依次演进的三种方案每一个都在解决前一个的局限性。cot-最简单的激活方式-加一句话就够了CoT 的全称是 Chain of Thought思维链核心思路极其简单在 prompt 里加一句「请一步步思考」LLM 就会把推理过程逐步写出来而不是直接蹦出答案。为什么这么简单的改变就有效本质是因为 LLM 的输出是顺序生成的当它先输出推理步骤这些推理内容会进入上下文影响下一个 token 的生成。换句话说「写下来的推理过程」本身就成为了后续生成的依据帮助 LLM 不跳步、不乱想。就好比你在纸上演算数学题把每一步写出来之后下一步出错的概率会比在脑子里算要低得多原理是一样的。CoT 有两种触发方式。第一种叫 Zero-shot CoT就是直接在 prompt 末尾加「让我们一步步思考」LLM 自己展开推理不需要额外例子第二种叫 Few-shot CoT给几个带有完整推理过程的例子让 LLM 模仿这种推理格式来回答新问题效果通常更稳定。CoT 的局限很明显它只有「一条推理路径」。如果一开始走错了方向整条链就歪了没有任何纠偏机制。tot-从「一条链」到「一棵树」-解决走错方向的问题ToT 的全称是 Tree of Thoughts思维树针对的正是 CoT「一旦走错就全错」的问题。核心改变是把「生成一条推理链」变成「同时探索多条推理路径边探索边剪枝最终选出最优路径」。用一个生活类比来理解CoT 像你做题时只想了一个解法一路做到底ToT 像你先想了三种可能的解题思路评估了一下哪种最靠谱选了最好的那条继续深入另外两条直接放弃。ToT 的执行流程可以分三步来理解。首先是生成多个候选思路让 LLM 针对同一个问题给出 3 个不同的初步方向而不是只走一条路。然后是评估每个思路的可行性用另一个 LLM 调用或同一个 LLM 带上评估 prompt给每个思路打分判断哪个最有希望。最后是选优继续深入、剪掉差的只保留分数高的思路再展开下一层推理反复循环直到得出最终答案。这个「生成 - 评估 - 剪枝」的循环让 LLM 不再是「一条道走到黑」而是有了探索多条路、选好的走、发现走错了还能回头的能力。代价也很明显原来 CoT 一次生成就搞定ToT 需要多次 LLM 调用多条路径 × 多层深度 × 每层还要评估。具体多几倍要看路径数和搜索深度典型设置每层 3 条路径、搜 2-3 层下成本通常是 CoT 的 3-5 倍极端场景深搜、更多路径、每步都打分可能到 10 倍以上。GoT从「树」到「图」解决推理结果不能复用的问题GoT 的全称是 Graph of Thoughts思维图是在 ToT 基础上再进一步的进化。ToT 虽然引入了多路径探索但它是树形结构不同分支之间完全独立两条推理路径上的中间结论无法互相借用。GoT 把推理结构换成了图允许不同路径的中间结果合并、复用也就是说一个推理节点可以接收来自多个前置节点的输出作为输入。举个具体例子如果任务是「分别研究竞品 A 和竞品 B然后做综合对比分析」。ToT 里研究 A 和研究 B 是两条独立的路径各自得出结论但「综合对比分析」这一步需要同时用到两条路径的结论在树形结构里很难自然表达因为树的每个节点只有一个父节点。GoT 的图结构允许把「研究 A 的节点」和「研究 B 的节点」的输出汇聚到「综合对比分析节点」这种「多个中间结论合并输入到下一步」的操作在图里是一等公民表达起来非常自然。GoT 能建模的推理模式比 ToT 更丰富也更接近人类实际处理复杂任务的思考方式。但落地复杂度很高目前主要还是学术研究场景生产环境里极少见到真正用起来的。三者的演进关系把这三者放在演进视角里看逻辑非常清晰。CoT 解决了「要不要把推理显式化」的问题答案是要把过程写出来就能显著减少跳步出错。ToT 解决了「走错方向怎么办」的问题答案是先多探索几条路边走边评估边剪枝。GoT 解决了「不同推理路径的中间结论能不能复用」的问题答案是把结构从树换成图自然支持结论汇聚与复用。每一步都是在前一步的基础上发现局限、针对性改进。工程上怎么选CoT 几乎是所有任务的标配加一句话、零成本直接加到 system prompt 里就行。ToT 在准确率要求很高、任务比较复杂的场景值得考虑但要做好调用成本增加 3-5 倍极端情况更多的心理准备。GoT 目前工程落地不成熟主要了解它的思想即可真实项目里不必强行引入。工程里真正常用的规划模式Plan-and-ExecuteCoT、ToT、GoT 说的都是「怎么让 LLM 把推理过程做得更好」但在真实的 Agent 项目里还有一种更贴近工程实践的规划模式叫做 Plan-and-Execute先规划再执行。这个模式的思路很直白面对一个复杂任务先让 LLM 制定一份完整的执行计划把任务拆成若干步骤然后一步一步执行每完成一步就检查一下进度必要时调整后续计划。你可以把它理解成「先写大纲再动笔」的写作方式而不是拿到题目就开始一口气往下写。为什么需要这种模式因为 CoT 虽然能让 LLM 逐步推理但它是「边想边做」的走到哪算哪没有全局视角。对于一个需要调用多个工具、经历多个环节的复杂任务来说如果没有一个整体规划LLM 很容易在某一步跑偏后面的步骤全都白费。Plan-and-Execute 的核心价值就是先用一次 LLM 调用建立全局视角再用后续调用逐步落地把「规划」和「执行」分成两个阶段来做。具体执行流程分三步。第一步Planner规划器接收用户任务生成一份步骤清单比如「第一步搜索相关资料第二步整理关键信息第三步撰写总结报告」。第二步Executor执行器按照清单一步步执行每步可能涉及工具调用或 LLM 推理。第三步也是容易被忽略的关键每执行完一步会有一个 Re-planner重新规划器回顾当前进展判断原来的计划还适不适用如果中间发现了新的信息或者某步执行结果不符合预期就动态调整后续步骤。这个模式和 ReAct 是什么关系ReActReasoning Acting是一种让 LLM 在每一步都先「思考」再「行动」再「观察」的循环模式它的特点是每步都是即时决策没有提前规划。Plan-and-Execute 则是在 ReAct 的基础上加了一层全局规划你可以理解成 ReAct 负责每一步怎么执行Plan-and-Execute 负责这些步骤的整体编排和动态调整。两者不是替代关系而是经常搭配使用的。工程上 Plan-and-Execute 的好处很明显规划和执行分离之后规划阶段可以用更强的模型比如 GPT-4来保证方向正确执行阶段可以用更快更便宜的模型来提高效率成本和质量都能分别优化。LangGraph 里就内置了这种模式的支持用起来相当方便。-面试总结回顾开头踩的雷第一个最典型把「CoT 就是规划能力」画等号这是这道题最常见的误区。规划能力是个方向CoT 只是最基础的一种实现手段。答好这道题有几个层次。首先要说清楚为什么需要规划能力LLM 默认「一口气」生成答案没有显式推理过程多步推理任务容易跳步出错规划机制就是把隐式推理过程显式化。然后要说三种机制的演进逻辑CoT 解决「要不要把推理写出来」ToT 解决「走错了方向怎么纠偏」GoT 解决「不同路径的中间结论能不能复用」每一个都是针对上一个的局限性改进。最容易被忽略的考点是工程取舍CoT 几乎零成本ToT 效果更好但典型调用次数是 CoT 的 3-5 倍具体看路径数和深度要明确说出这个数字GoT 目前学术阶段生产环境没有成熟落地。面试里如果能把工程成本和适用场景说清楚比只讲原理要加分得多。
