完整题目
在智能Agent系统中，规划能力是完成复杂多步任务的核心。请系统介绍当前主流的提升大语言模型规划能力的方法，如思维链（CoT）、思维树（ToT）、图思维（GoT）等，深入分析它们的原理、适用场景，并对比各自的优缺点与实际应用中的局限性。
本文目录
一、三类方法的核心原理
| 方法 | 核心思想 | 关键机制 |
|---|---|---|
| CoT (Chain-of-Thought) | 线性逐步推理 | 通过"Let's think step by step"激发模型生成中间推理步骤，形成单一路径的推理链 |
| ToT (Tree-of-Thoughts) | 树形分支探索 | 将推理建模为树搜索，每个节点是一个思维状态，支持生成多个候选→评估→选择→回溯 |
| GoT (Graph-of-Thoughts) | 图结构聚合 | 允许思维节点任意连接（合并、循环、精炼），用图结构捕捉更复杂的依赖和迭代优化 |
二、适用场景与优缺点
CoT
- 适用：数学计算、符号推理、单路径即可解决的中等复杂度任务
- 优点：零额外推理开销，实现极简，与模型原生能力结合好
- 局限：无法纠错（一步错步步错）、无探索能力、对需要试错的任务失效
ToT
- 适用：创意写作、谜题求解、决策规划（如24点游戏、Mini Crosswords）
- 优点：显式探索+评估+回溯，可自我纠正，突破局部最优
- 局限：分支爆炸导致成本指数级增长；需要设计任务特定的状态评估器（往往用LLM自身打分，可靠性存疑）
GoT
- 适用：代码优化、多文档摘要、需要迭代精炼的复杂任务
- 优点：支持思维聚合（如合并多个方案）和循环优化，表达能力最强
- 局限：图结构构建成本高，需要预定义操作符（Aggregate/Refine/Generate）；工程实现复杂，目前多为研究原型
三、实际落地的关键瓶颈
- 评估器可靠性：ToT/GoT依赖LLM自我评估，但模型对复杂状态的判断常不稳定
- 延迟与成本：ToT的多次采样+评估在实时场景（如高德导航的实时路径重规划）难以承受
- 任务适配成本：从24点游戏迁移到真实业务，状态定义、评估prompt需大量人工设计
四、选型建议
- 追求速度+成本：CoT + Self-Consistency（多次采样选多数答案）
- 需要探索+可承受延迟：ToT with 限定深度+启发式剪枝
- 复杂迭代优化：GoT，但建议先验证评估器质量，或引入外部验证（如代码执行反馈）
高德场景举例：实时路径规划更适合CoT+规则后处理或轻量ToT（限定2-3层分支）；而离线POI信息整合生成攻略可尝试GoT的聚合能力。
学习建议
建议从基础推理方法CoT入手，逐步学习ToT和GoT的结构化思想，结合论文与开源项目实践，理解不同方法在任务分解与搜索策略上的差异。
换一种问法，检查是否真正理解
场景切入
假设我们要做一个电商客服Agent，用户问“我想退货，但找不到订单了”，Agent需要先查订单、再校验资格、最后生成退货流程。这种多步任务，你会怎么设计它的推理过程？
层层追问
现在大模型做复杂任务，你觉得最关键的瓶颈是什么？……那怎么让模型一步步推理呢？……如果一步推理不够，需要探索多条路径呢？……再进一步，如果有些步骤可以合并或循环优化，又该怎么做？
直球架构
请系统介绍提升大模型规划能力的方法，比如CoT、ToT、GoT，重点讲原理、适用场景、优缺点，以及实际落地时的主要瓶颈和选型建议。
练习口述回答 · 约4分钟
- 一句话定位：规划能力本质是让LLM做多步决策
- CoT的线性推理与局限
- ToT的树搜索与开销问题
- GoT的图聚合与实现复杂度
- 选型取舍与落地风险
面试官你好，这道题问的是智能[[Agent]]里规划能力的提升方法。其实说白了，规划能力本质就是让大模型能自己做多步决策，而不是一步到位。所以主流方法都是从怎么拆解步骤、怎么探索搜索这两个角度去做的。今天我就把[[CoT]]、[[ToT]]、GoT这三类讲清楚，重点不是背原理，而是它们各自适用什么场景，以及真正落地时有哪些坑。
先说CoT，思维链。它的核心就是让模型生成中间推理步骤，一条路走到黑。好处很明显，零额外成本，写个'Let's think step by step'就能用，效果在数学题、符号推理这类单路径任务上确实好。但它的局限也很致命，一旦某一步错了，后面全错，而且没有任何纠错机制。所以它只适合那种路径明确、不需要试错的任务。
然后是ToT，思维树。它把推理建模成树搜索，每个节点是一个思维状态，模型先生成多个候选，然后评估，选好的继续，走不通就回溯。这样就有了显式的探索和自我纠正能力。适用场景很明确，比如创意写作、谜题求解，还有像24点游戏这种需要多步试错的任务。但这里有个大坑，ToT的分支爆炸导致成本指数级增长，而且评估器往往还是用LLM自己打分，可靠性存疑。我在业务里看到的失败案例，很多就是评估器不稳定，导致搜索方向飘掉。
最后是GoT，图思维。它更进一步，允许思维节点任意连接，可以合并、循环、精炼，用图结构捕捉更复杂的依赖。表达能力最强，适合代码优化、多文档摘要这种需要迭代聚合的任务。但坏处也很明显，图结构构建成本高，需要预定义Generate、Aggregate、Refine这些操作符，工程实现非常复杂，目前基本还是研究原型。
所以落地的时候，真正的挑战不是选哪个方法，而是怎么在成本、延迟和效果之间做取舍。举个例子，实时路径规划场景，比如高德导航，用户等不了几秒钟让模型做树搜索，那就只能用CoT加规则后处理，或者轻量ToT限定两三层分支，再配合启发式剪枝。而离线POI信息整合生成攻略，就可以尝试GoT的聚合能力。
这里有个关键风险：ToT和GoT依赖的评估器如果不可靠，整个搜索就白费。我在上线前一定会先做评估器的质量验证，用一批人工标注的中间状态打分，看准确率和一致性。如果评估器不过关，我宁愿退回到CoT加[[Self-Consistency]]，多采样几次选多数答案，反而更稳定。
所以我的整体取舍是：把CoT当成基线，ToT当成进阶，GoT当成探索。但有一个点我想提一下，就是这些方法在[[Multi-Agent]]系统里怎么组合。比如让一个Agent做CoT快速出方案，另一个Agent做ToT做深度验证，这种协作我最近看到一些有意思的工作。
最后总结一句，规划能力没有银弹，关键是根据任务性质、延迟要求和评估器质量来选，而且往往混合使用才是正解。