跳到正文

CoT vs ToT vs GoT 怎么选?

三种主流规划方法原理、场景与局限性对比

原题:在智能Agent系统中,规划能力是完成复杂多步任务的核心。请系统介绍当前主流的提升大语言模型规划能力的方法,如思维链(CoT)、思维树(ToT)、图思维(GoT)等,深入分析它们的原理、适用场景,并对比各自的优缺点与实际应用中的局限性。

Prompt工程 · 高德真题

回答与解析

一、三类方法的核心原理

方法 核心思想 关键机制
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);工程实现复杂,目前多为研究原型

三、实际落地的关键瓶颈

  1. 评估器可靠性:ToT/GoT依赖LLM自我评估,但模型对复杂状态的判断常不稳定
  2. 延迟与成本:ToT的多次采样+评估在实时场景(如高德导航的实时路径重规划)难以承受
  3. 任务适配成本:从24点游戏迁移到真实业务,状态定义、评估prompt需大量人工设计

四、选型建议

  • 追求速度+成本:CoT + Self-Consistency(多次采样选多数答案)
  • 需要探索+可承受延迟:ToT with 限定深度+启发式剪枝
  • 复杂迭代优化:GoT,但建议先验证评估器质量,或引入外部验证(如代码执行反馈)

高德场景举例:实时路径规划更适合CoT+规则后处理轻量ToT(限定2-3层分支);而离线POI信息整合生成攻略可尝试GoT的聚合能力。

学习建议

建议从基础推理方法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做深度验证,这种协作我最近看到一些有意思的工作。

最后总结一句,规划能力没有银弹,关键是根据任务性质、延迟要求和评估器质量来选,而且往往混合使用才是正解。

关键一句:在Multi-Agent系统里,如何组合CoT、ToT、GoT做协作规划

面试官还可能这样问

  1. 问法 1 · 场景切入

    假设我们要做一个电商客服Agent,用户问“我想退货,但找不到订单了”,Agent需要先查订单、再校验资格、最后生成退货流程。这种多步任务,你会怎么设计它的推理过程?

  2. 问法 2 · 层层追问

    现在大模型做复杂任务,你觉得最关键的瓶颈是什么?……那怎么让模型一步步推理呢?……如果一步推理不够,需要探索多条路径呢?……再进一步,如果有些步骤可以合并或循环优化,又该怎么做?

  3. 问法 3 · 直球架构

    请系统介绍提升大模型规划能力的方法,比如CoT、ToT、GoT,重点讲原理、适用场景、优缺点,以及实际落地时的主要瓶颈和选型建议。

同模块相关题目