在 Agent 语境里模型的思考能力至关重要。本文深入探讨了思维链CoT、思维树ToT和思维图GoT等推理范式解释了它们如何让模型更清晰地思考问题。CoT 通过显式推理步骤提升推理质量ToT 引入树状搜索支持探索和回溯而 GoT 则更进一步将推理过程建模为有向无环图支持聚合和迭代精炼。文章还分析了这些范式的局限性以及解决方案并探讨了它们在 Agent 系统中的层级关系和组合应用。对于想要学习大模型推理能力的小白程序员来说本文提供了宝贵的参考。在 Agent 语境里真正决定系统上限的往往不是模型能不能给出答案而是它能不能先把问题想清楚。面对复杂任务模型如果只是“想到什么说什么”很容易在一开始就走偏后面再强的工具和记忆也只能不断补洞。CoT、ToT、GOT 以及 plan-and-execute、ReAct、Reflection本质上都在解决同一个问题如何让模型把思考过程显式化、把推理结构化再把结构化的思考稳定地转化为行动。这篇文章会沿着这个主线先解释 CoT 为什么有效再继续比较 ToT、GOT 与几种常见 Agent 执行范式之间的关系。什么是 Chain of Thought解决了什么问题它的实现原理是怎么样的它为什么能提升 LLM 在推理任务上的表现1. 什么是 Chain of Thought思维链Chain of Thought简称 CoT中文常译为“思维链”是让LLM在给出最终答案之前先生成一系列中间推理步骤然后基于中间推理继续生成最终答案的方法。普通问答中模型通常直接从问题映射到答案。而使用 Chain of Thought 后模型会先生成一段推理过程再给出答案。举个简单例子问题小明有 3 个苹果又买了 5 个苹果然后吃了 2 个苹果。他现在还有几个苹果直接回答时模型可能会输出6 个。使用 CoT 后模型可能输出小明一开始有 3 个苹果。又买了 5 个所以现在是 3 5 8 个。然后吃了 2 个所以剩下 8 - 2 6 个。因此答案是 6 个。这段包含中间推理过程的回答方式就是所谓的 Chain of Thought。这些中间推理过程和最终答案都是在一次LLM调用的内部完成的LLM思考过程中工程代码上没有任何介入和工具调用2. COT 解决了什么问题为什么 COT 有效很多人可能答到COT的原理是这样回答的LM 在多步推理任务中容易直接输出错误答案的问题。COT通过让LLM增加中间推理步骤从而提升回答的质量就完事了。但是为什么LLM直接输出答案会更容易出错为什么增加了中间推理步骤能提升回答质量这里需要从 计算路径 和 信息外显 两个角度理解 CoT角度一计算路径 —— 用更多的思考时间换更强的推理能力核心问题模型的思考时间是固定的Transformer 生成一个 token 的过程是输入序列 → [第1层 → 第2层 → ... → 第N层] → 输出1个token无论问题多复杂如果模型只输出一个 token即直接给出答案它能使用的计算量就是固定的 N 层 forward pass。这就好比不管题目多难只给你 3 秒钟作答。CoT 如何改变这一点?当模型生成中间推理时LLM输出的这些中间推理的token会作为下一个待输出的token的输入加入到上下文中。假设推理链的中间推理内容有 30 个 token模型实际多执行了 30 × N 层 的计算。模型每生成一个 token都会再进行一次完整的前向计算生成一段长的推理链相当于给模型更多“计算时间”并且为上下文增加更多信息。因此 COT 本质是 用序列长度换计算深度从计算复杂性角度看没有 CoT相当于要求一个固定深度和长度的计算N 层 Transformer解决任意复杂度的问题。这在理论上是不可能的。有 CoT相当于通过增加计算步数通过生成更多 token理论上可以解决任意可计算问题。类比场景没有 CoT有 CoT人类做数学题看一眼题目立刻喊答案在草稿纸上一步步演算程序员写代码看一眼需求直接写最终代码先写伪代码再逐步实现角度二信息外显 —— 把工作记忆变成外部存储核心问题中间结果记不住多步推理需要保持中间结果。例如Roger有5个网球他又买了2罐每罐3个。他现在有多少个网球 步骤12罐 × 每罐3个 6个新球 步骤2原有5个 新买6个 11个步骤 2 需要用到步骤 1 的结果6。这个6存在哪里没有 CoT 时中间结果只存在于隐层激活中如果模型不显式输出6这个值只存在于某一层的 hidden state 向量中。问题是1. 容量有限hidden state 是一个固定维度的向量如 4096 维能同时编码的信息量有上限。2. 信息衰减随着后续层的计算早期的中间信息会被逐步覆盖、稀释。3. 不可寻址模型无法精确地回去查看某个特定的中间结果它只能依赖 attention 机制模糊地回忆。类比纯心算。你需要在脑中同时记住多个中间结果一旦步骤多了前面的数就忘了。有 CoT 时中间结果被写下来成为 token当模型输出2×36时这个6被固化为 token 序列的一部分。后续所有 token 都可以通过 attention 机制直接回看 这个6。类比在草稿纸上写下中间结果。你随时可以回头看第 3 步算出来的那个数是多少。本质突破 Transformer 的工作记忆瓶颈没有 CoT 工作记忆 hidden state有限、易逝、不可精确寻址 有 CoT 工作记忆 已生成的 token 序列大容量、持久、可精确 attend两个角度的协同关系这两个角度不是独立的而是相互依赖、形成闭环计算路径时间维度 信息外显空间维度 ───────────────── ───────────────── 更多的计算步数 产出中间结果 │ │ ▼ ▼ 生成更多 token ──→ 中间结果被写入序列 │ ▼ 后续计算步数可以引用这些结果 │ ▼ 支撑更复杂的下一步推理 │ ▼ 产出新的中间结果...循环计算路径解决的是 “算力不够” 的问题 → 给模型更多思考时间信息外显解决的是 “记忆不够” 的问题 → 给模型一个草稿纸回到面试回答模板如果被问到CoT 为什么有效可以这样组织我会从两个角度解释。第一计算路径。 Transformer 每生成一个 token 执行一次 forward pass。CoT 让模型生成多个中间推理 token实质上增加了计算步数相当于给模型更多的’思考时间’。没有 CoT模型被要求在固定深度的计算内解决任意复杂度的问题这在理论上是有上限的。第二信息外显。 多步推理需要保持中间结果。没有 CoT 时中间结果只存在于 hidden state 中容量有限且容易衰减。CoT 把中间结果写成 token后续步骤可以通过 attention 精确引用相当于给模型提供了一张’草稿纸’突破了工作记忆的瓶颈。两者协同更多的计算步数产出中间结果中间结果被外显保存供后续步骤使用形成正向循环。3. Chain of Thought 的实现原理是什么如何实现CoT 的实现可以从2个层面理解提示词层面 和 训练层面。3.1 提示词层面让模型输出中间步骤最早的 CoT 方法很多时候是通过 prompt 实现的。Few-shot CoT给模型若干示例每个示例里不仅有问题、详细推理过程和答案。例如问题小红有 2 支笔又买了 4 支现在有几支 回答小红一开始有 2 支笔。又买了 4 支所以 2 4 6。答案是 6。 问题小明有 5 个球丢了 2 个还剩几个 回答小明一开始有 5 个球。丢了 2 个所以 5 - 2 3。答案是 3。然后模型在遇到新问题时会模仿这种“逐步推理”的回答方式。Zero-shot CoT不需要提供示例只需要加一句提示请一步一步地思考。很多模型在加入这类提示后会生成分步推理添加到上下文的token中再基于中间推理生成答案。3.2 训练层面用推理轨迹数据训练模型现代 LLM 中CoT 不只是 prompt 技巧也经常通过训练内化。常见方式包括1. 监督微调 SFT使用包含推理过程的数据训练模型例如问题... 推理过程... 答案...让模型学会在回答复杂问题时输出中间步骤。2. 蒸馏教师模型的思维链用一个更强模型生成推理过程再用这些数据训练较小模型。例如大模型生成详细解题步骤小模型学习这些步骤获得部分推理能力。CoT存在什么局限性或者缺点如何解决CoT思维链虽然极大地提升了 LLM 的推理能力但它本质上仍然是 “基于文本生成的局部贪心算法”。在实际应用和复杂 Agent 系统中CoT 暴露出了一系列致命的局限性。理解这些局限性正是我们引入 ToT、ReAct、Plan-and-Execute 和 Reflection 等高级范式的核心动机。以下是 CoT 的 5 大核心局限性及其对应的解决方案局限一单链不可回溯错误会级联放大Error Cascading问题描述CoT 是一条单向的线性链条A → B → C → D。如果在步骤 B 产生了微小的逻辑错误或计算错误模型无法“退回去”修改 B而是会基于错误的 B 继续推导 C 和 D导致 “一步错步步错”Error Cascading。导致后果推理链看似严丝合缝但最终答案完全错误即“忠实地胡说八道”。解决方案引入 ToTTree of Thoughts将单链升级为树状结构。在每一步生成多个候选分支评估后保留最优分支剪枝如果当前分支走入死胡同允许回溯Backtracking 到上一个节点重新探索。局限二纯文本“空想”缺乏事实依据与外部知识问题描述CoT 是一次LLM推理内完成的过程无法获取外部知识和实时数据只是模型在利用其训练数据在推理和回答。在长推理链中模型极容易因为过时数据或缺乏外部知识在中间步骤“幻觉”出错误的事实或算错数字。导致后果推理逻辑是对的但因为中间某个事实或数字是编造的导致满盘皆输。解决方案引入 ReActReasoning Acting打破纯文本推理允许模型在 CoT 的中间步骤调用外部工具。例如遇到计算时调用Calculator遇到未知事实时调用Search API将 Observation观察结果作为下一步推理的坚实依据。局限三缺乏全局视野推理漂移容易“迷失”在长程任务中问题描述CoT 是典型的 “走一步看一步”的贪心策略Greedy Strategy。它只关注当前步骤到下一步的局部最优缺乏对最终目标的宏观把控。导致后果在处理需要 20 步以上的复杂任务如“调研 5 家竞品并写对比报告”时CoT 很容易在中途偏离主题或者在某个无关紧要的细节上陷入死循环Rabbit Hole忘记最终目标。解决方案引入 Plan-and-Execute规划与执行将“思考”拆分为两层。上层用 Planner 生成全局的任务拆解Plan下层 Executor 在执行每一个具体子任务时再使用局部的 CoT。用全局的 Plan 来约束局部的 CoT。局限四本可避免的推理成本与延迟工程落地的痛点问题描述CoT 要求模型输出大量的中间 token。在自回归生成机制下生成的 token 越多API 调用成本越高首字响应延迟TTFT和整体延迟越长。解决方案动态路由Dynamic Routing训练一个轻量级的分类器Router或者在prompt中让LLM自行判断问题的难度是否需要生成推理过程。简单问题直接输出答案复杂问题才触发 CoT。局限五过度思考与“戏太多”问题描述有时模型为了迎合“step by step”的指令会生成大量无意义的过渡废话如 “Let me think about this…”, “Wait, that might be wrong…”, “On the other hand…”甚至陷入自我怀疑的死循环。导致后果不仅浪费 token过多的冗余信息还会稀释注意力机制Attention Dilution反而导致最终答案变差。解决方案结构化 Prompt 约束在 System Prompt 中严格规定推理的格式和字数限制例如“请用 JSON 格式输出最多包含 3 个推理步骤”。总结从 CoT 的局限性看 Agent 范式的演进路线我们可以用一张表将 CoT 的缺点与后续的高级范式完美对应起来。这也是面试时极佳的宏观串联回答CoT 的局限性本质缺陷演进出的高级范式核心解决思路单链不可回溯搜索空间受限ToT (Tree of Thought)从单链升级为树状搜索引入评估与回溯机制。纯文本空想缺乏外部接地 (Grounding)ReAct / Tool-use引入外部工具和环境交互用 Observation 纠正 Thought。缺乏全局视野局部贪心短视Plan-and-Execute分离规划与执行用全局 Plan 指导局部 CoT。无法自我纠错开环系统无反馈Reflection / Self-Refine引入 Critic 机制形成“生成-评估-修正”的闭环。推理成本高序列过长模型蒸馏 / 动态路由将推理能力内化到权重或按需触发 CoT。 面试高分回答话术模板面试官“CoT 这么好它有什么局限性吗在实际 Agent 系统中你们是怎么解决的”候选人“CoT 的核心局限性可以概括为三个词单向、空想、短视。第一是单向导致的错误累积。CoT 是一条单行道中间一步算错后面全错。为了解决这个问题我们在复杂推理场景引入了 ToT树状思维允许模型在节点上进行多分支探索和自我评估甚至回溯或者在生成后引入 Reflection反思机制 让模型自己批改作业。第二是空想导致的幻觉。LLM 本质是概率模型不擅长精确计算和实时事实查询。纯文本的 CoT 很容易在中间步骤‘幻觉’出错误的数据。因此我们将 CoT 升级为 ReAct 框架让模型在推理链中能够调用计算器或搜索引擎用外部的 Observation 来锚定内部的 Thought。第三是短视导致的目标迷失。CoT 是走一步看一步的贪心策略处理长程复杂任务容易跑偏。所以我们采用了 Plan-and-Execute 架构先用 Planner 做全局的任务拆解再让 Executor 在每个子任务里用 CoT 去执行从而兼顾了全局视野和局部推理深度。此外在工程落地时CoT 带来的高 Token 成本和延迟也是痛点我们通常会通过动态路由简单题不走 CoT 。”什么是 ToTToT 的推理过程是怎么样的如果说COT是线性推理那么Tree of ThoughtToT是一种将 LLM 的推理过程建模为树状搜索的框架。它在每一个当下推理阶段即当前节点生成下一步的多个候选推理方向即子节点通过评估器判断各方向的前景再按照搜索策略选择最优路径继续深入必要时回溯还能通过评分对低分方向进行剪枝。你可以理解为树的根节点是初始问题最底层的叶子节点是最终结果中间的节点相当于中间推理步骤。一句话概括CoT 是一条路走到黑ToT 是多条路探着走走错了还能退回来。TOT的树状推理过程是怎么样的COT的所有推理文本和中间节点都在一次LLM调用中生成的而TOT的每个节点都是至少一次LLM调用根据 Yao et al. (2023) 的论文ToT 框架由三个核心组件构成┌─────────────────────────────────────────────────┐ │ Tree of Thoughts 框架 │ │ │ │ ┌───────────────┐ │ │ │ 1. Thought │ → 在当前节点生成候选分支 │ │ │ Generation │ │ │ └───────┬───────┘ │ │ ▼ │ │ ┌───────────────┐ │ │ │ 2. State │ → 评估每个分支的前景 │ │ │ Evaluation │ │ │ └───────┬───────┘ │ │ ▼ │ │ ┌───────────────┐ │ │ │ 3. Search │ → 决定下一步探索哪个节点 │ │ │ Algorithm │ │ │ └───────────────┘ │ └─────────────────────────────────────────────────┘组件一Thought Generation思维生成在当前推理状态下生成下一步的多个候选思考作为树的子节点。两种生成策略策略方式适用场景Sample采样对同一个 prompt即当前节点用较高温度temperature独立采样 k 次得到 k 个不同的 thought创意写作、头脑风暴等多样性要求高的任务Propose提议在当前节点一次性让 LLM输出一个包含多个候选 thought 的列表如 “请给出 3 种可能的下一步”步骤明确、可枚举 的任务Sample采样是每个候选 thought 都需要一次LLM调用且由于温度较高每个thought之间的差别会比较大Propose提议则是一次LLM调用生成多个 thought组件二State Evaluation状态评估对生成的每个候选 thought子节点评估其离最终目标还有多远或有多大可能通向正确答案为搜索算法提供方向信号。这个过程相当于为每个子节点进行打分。两种评估方式方式做法优劣Value打分让 LLM 对每个状态独立打分如 1-10 分或判断这个状态离答案有多近简单直接但 LLM 的打分可能不稳定对同一个节点多次打分可能得到的分数不一样Vote投票/比较让 LLM 同时看到多个候选状态选出最好的那个或最不可能通向答案的那个进行剔除相对比较比绝对打分更可靠核心价值剪枝Pruning评估器的最大作用是提前砍掉没希望的分支避免在低分分支浪费计算资源。组件三Search Algorithm搜索算法决定以什么顺序和策略在思维树中探索节点。三种基本策略策略工作方式适用场景优缺点BFS广度优先逐层展开先生成第 1 步的所有分支 → 评估 → 保留 top-k → 再生成第 2 步的所有分支 → …步骤少≤5步但每步分支多的问题✅ 不容易漏掉最优解 ❌ 每层都要评估token 消耗大DFS深度优先一条路走到底选一个分支一直往下走 → 走不通评估为 impossible→ 回溯到上一个节点 → 换下一个分支步骤多但每步分支少的问题如创意写作、填字游戏✅ 省 token能快速得到一个完整解 ❌ 可能错过更优路径工程实践中纯 BFS 和纯 DFS 都少用更常见的是 Beam Search。Beam Search束搜索是一种受限的广度优先搜索每一步生成所有候选分支但只保留评分最高的 top-k 个k 称为 beam width其余全部剪枝。贪心搜索 (Greedy) Beam Search 穷举 BFS beam width 1 beam width k beam width ∞ │ │ │ ▼ ▼ ▼ 每步只留1个 每步留k个 每步全保留 ( CoT) (工程常用) ( 纯BFS不现实)Beam Search 本质上是贪心和穷举之间的滑动条k 越小越接近 CoT快但可能错过最优k 越大越接近纯 BFS慢但更全面。Beam Search 在 ToT 中的工作流程以 beam width 3 为例解决一个 4 步推理问题第 1 步 生成 → 产生 8 个候选 thought 评估 → 对 8 个候选打分 筛选 → 保留 top-3丢弃 5 个这是第二层节点 第 2 步 对第二层节点保留的 3 个状态节点各生成 8 个候选 → 共 24 个候选 评估 → 对 24 个候选打分 筛选 → 保留 top-3丢弃 21 个这是第三层节点 第 3 步 对第三层节点保留的 3 个状态节点各生成 8 个候选 → 共 24 个候选 评估 → 对 24 个候选打分 筛选 → 保留 top-3这是第四层节点 第 4 步 对第四层节点保留的 3 个状态节点各生成候选 → 评估 → 选出/整合最终答案关键特征特征说明每层宽度固定无论生成多少候选最终只保留 k 个层间竞争不同父节点的子节点放在一起比较全局排序后取 top-k不可回溯一旦某步被剪枝后续无法恢复与 DFS 的回溯不同逐层递进结构上是 BFS但宽度被限制为 kk 值的影响beam width (k)效果类比k 1退化为贪心搜索 CoT只看脚下一条路走到黑k 3~5工程常用平衡质量与成本同时关注 3-5 条路k 10~20接近穷举质量高但成本大几乎不遗漏k 所有分支退化为纯 BFS完全穷举不现实量化 Trade-off假设每步生成 b8 个候选总共 n5 步beam width每步评估数总评估次数相对 CoT 的成本k1 (贪心)85 × 8 40~1×k33 × 8 245 × 24 120~3×k55 × 8 405 × 40 200~5×k8 (纯BFS)8 × 8 645 × 64 320~8×核心观察总成本 ≈ n × k × bbeam width 与成本成线性关系。其中 n 是层数k是beam width剪枝后剩下的节点数b是每个节点生成的总候选节点数此外还要算上评估和打分所消耗的LLM调用次数Beam Search 的局限性与工程优化优化 1多样性约束Diverse Beam Search问题top-k 分支可能都来自同一个父节点导致搜索空间坍缩。解决强制要求保留的 k 个分支来自不同的父节点或在评分时加入多样性惩罚。标准 Beam Search 保留 top-3 → 可能 3 个都来自父节点 A Diverse Beam Search 保留 top-3 → 要求至少来自 2 个不同父节点优化 2动态 Beam Width问题固定 k 不够灵活——简单步骤不需要太多分支关键步骤需要更多探索。解决根据当前状态的评估分数动态调整 k。如果当前所有分支评分都很高0.8→ 缩小 k已经够好了 如果当前所有分支评分都很低0.3→ 扩大 k需要更多探索优化 3Early Stopping提前终止问题如果某个分支在第 3 步就已经得到满分还需要继续搜索吗解决当 top-1 分支的评分远超 top-2 时如差距 阈值提前终止搜索直接输出。优化 4与 DFS 回溯结合问题纯 Beam Search 不可回溯一旦剪错就完了。解决保留被剪枝分支的存档如果后续 top-k 分支全部失败可以回溯到存档点恢复之前被剪掉的分支。Beam Search 有限回溯 正常流程每步保留 top-k 异常处理如果 top-k 全部评估为 impossible → 回溯到上一步 → 恢复当时被剪掉的 top-(k1) 到 top-(2k) 分支 → 继续搜索ToT vs CoT 对比总结表维度CoTToT结构单条链树状图决策方式贪心每步只选一个搜索每步考虑多个能否回溯❌ 不能✅ 能有无评估❌ 无生成即接受✅ 有评估后筛选Token 消耗低1×高5-10×推理延迟低高适用问题步骤少、路径唯一步骤多、需要探索/试错面试回答模板面试官“ToT 相比 CoT 解决了什么核心问题核心组件是什么”候选人ToT 解决的核心问题是 CoT 的单链贪心和不可回溯。CoT 是一条路走到黑中间错了无法挽回ToT 把推理过程建模为一棵搜索树允许多路径探索和回溯。它有三个核心组件第一Thought Generation思维生成——在当前节点生成多个候选的下一步推理作为树的子节点。可以用多次采样或一次性提议的方式。第二State Evaluation状态评估——让 LLM 对每个中间状态打分或比较判断它’离正确答案有多远’。核心作用是剪枝避免在没希望的分支上浪费算力。第三Search Algorithm搜索算法——决定用什么策略遍历这棵树。BFS 适合步骤少分支多的问题如 24 点DFS 适合步骤多分支少的问题如创意写作。三者协同生成器负责’展开可能性’评估器负责’判断好坏’搜索算法负责’决定探索顺序’。本质上ToT 是把经典的启发式搜索思想引入了 LLM 的文本生成过程。代价是 token 消耗和延迟大幅增加所以实际使用中需要权衡增强版 Plan-and-Execute ToTPlanner 用 ToT 探索多种计划方案方案A先调研 → 再写大纲 → 再填充方案B先写大纲 → 边调研边填充方案C先收集数据 → 再分析 → 再写评估哪种方案更高效、更不容易出错选定最优计划 → Executor 执行面试回答模板面试官“ToT 有什么局限性”候选人ToT 的局限性我会从三个层面来说。第一工程层面贵且慢。 多次 LLM 调用导致 token 成本是 CoT 的 5-30 倍延迟从秒级变成分钟级。这在 C 端产品中很难接受。第二适用性层面只适合’封闭、可枚举、有明确对错’的问题。 24 点、数学证明很合适但创意写作、商业决策这类开放性问题搜索空间不可枚举评估标准不明确ToT 基本失效。第三ToT 和 CoT 一样是纯’脑内推理’不能调用外部工具。如果模型的知识本身有误搜索的分支再充分也只是在错误空间里打转。这个问题需要 ReAct 来解决。所以 ToT 的定位是在特定类型的封闭推理问题上用高成本换取高质量。 它不是通用解而是工具箱里的一把专用工具。Graph of Thoughts (GoT) 的核心思想及与 CoT、ToT 的本质区别GoT 的核心思想Graph of Thoughts (GoT) 的核心思想是将LLM的推理过程建模为一个有向无环图从而支持比线性和树状结构更复杂、更贴近人类高级认知的思维演化操作。在 GoT 中每一个“思维Thought”是图中的一个节点Node。节点之间通过边Edge 连接代表思维的依赖、演化、合并或迭代关系。GoT 的本质突破在于它打破了“思维只能向前推导或向下分支”的限制引入了 “聚合” 和 “迭代精炼” 的能力使得模型能够像人类一样进行“集思广益”和“反复打磨”。数据结构上的本质区别三者在底层数据结构上呈现出明显的维度升级范式数据结构结构特征节点关系ToT树 (Tree)层级分支每个节点有 1 个前驱但可以有多个后继向下分裂。GoT有向无环图 (DAG/Graph)网状交织每个节点可以有多个前驱信息汇聚也可以有多个后继信息分发甚至支持自环自我迭代。核心差异解析ToT 的局限树结构在树中两个平行的分支如方案 A 和方案 B是孤立的。如果你想把 A 和 B 的优点结合起来你无法直接连接它们只能退回到它们的公共祖先节点重新生成。GoT 的突破图结构在图中方案 A 和方案 B 可以直接通过一条边“流向”一个新的节点 C代表 AB 的融合。这种多对一Many-to-One 的拓扑结构是树结构无法原生表达的。思维演化方式上的本质区别数据结构的差异直接决定了思维演化即模型如何从当前状态推导下一步方式的不同1. ToT探索与回溯 (Exploration Backtracking)演化方式Split (分裂) → Evaluate (评估) → Keep/Prune (保留/剪枝) → Backtrack (回溯)特点多路试错。模型在每一步生成多个候选分支评估后保留好的走不通就退回来换一条路。缺陷只能“优胜劣汰”不能“取长补短”。平行的优秀分支只能选其一无法融合。2. GoT网络化演化 (Networked Evolution)GoT 不仅兼容 CoT 的顺序和 ToT 的分支还引入了两种人类高级认知中特有的演化方式聚合 (Aggregation / Combine)演化方式Thought A Thought B → Thought C特点集思广益。将多个不同路径产生的优秀思维片段提取出来让 LLM 分析、比较并融合成一个新的、更优的综合思维。场景头脑风暴后总结共识将三种不同的算法思路融合为一个最优解。迭代精炼 (Update / Refinement)演化方式Thought C → Critique → Thought C特点精雕细琢。对同一个思维节点进行自我审查、修改和深化而不是简单地生成下一个步骤。场景写完一段代码后让模型自己 Review 并修复 Bug生成该代码的 V2 版本。GoT 落地的核心挑战GoT 能建模的推理模式比 ToT 更丰富也更接近人类实际处理复杂任务的思考方式。但落地复杂度很高目前主要还是学术研究场景生产环境里极少见到真正用起来的。挑战一Token 成本与推理延迟的指数级膨胀GoT 的每一次图操作生成、评估、聚合、迭代都需要一次或多次 LLM 调用。随着图的深度和宽度增加总调用次数和 Token 消耗呈指数级增长远超 CoT 和 ToT。具体表现操作Token 消耗特征生成Generation每个父节点生成 b 个子节点 → b 次调用评估Scoring每个候选节点需要一次评估调用聚合Aggregation 最昂贵需要将多个节点的完整文本同时塞入 Prompt让 LLM 融合迭代Update每轮迭代都是一次完整的审查 重写调用为什么聚合操作特别贵ToT 的评估 Prompt 请评估这个中间状态的质量[单个节点内容] → 打分 输入1 个节点~200 token GoT 的聚合 Prompt 请将以下三个方案融合为一个综合方案 方案A[完整内容 ~1000 token] 方案B[完整内容 ~1000 token] 方案C[完整内容 ~1000 token] 请分析各自优缺点并整合。 输入3 个节点~3000 token 输出融合结果~1500 token聚合操作的输入 Token 是多个节点的叠加而非单个节点。当节点内容较长时如长文本生成一次聚合操作可能消耗大量token。挑战二图结构的工程编排复杂度极高CoT 只需改一句 PromptToT 需要维护一棵树而 GoT 需要维护一个有向无环图DAG 复杂的操作调度逻辑。工程实现的复杂度呈阶跃式上升。具体表现工程挑战说明DAG 状态管理需要维护节点、边、依赖关系判断哪些节点可以并行执行、哪些必须串行上下文拼接每次调用 LLM 时可能需要从图中提取当前节点的完整祖先路径拼入 Prompt并发控制图中无依赖的节点可以并行执行但需要处理竞态条件和资源竞争与 ToT 的工程复杂度对比ToT 的工程需求 - 树结构数组/链表即可 - BFS/DFS 遍历逻辑 - 简单的剪枝排序 截断 GoT 的工程需求 - DAG 数据结构邻接表/邻接矩阵 - 拓扑排序确定执行顺序 - 依赖解析判断哪些节点的前驱已全部完成 - 图操作引擎Generation / Aggregation / Update 的调度 - 并发执行器无依赖节点并行 - 状态快照与回滚机制 - 图可视化工具调试用COT/TOT 与 plan-and-execute/react/reflection的关系是什么它们不是同一维度的并列概念而是 Agent 系统中不同“抽象层级”和“正交模块”的组合。维度一架构层级关系从微观到宏观1. 微观层认知引擎CoT / ToT —— “大脑的思考方式”定位它们是 LLM 最底层的推理范式解决的是“如何把问题想清楚(LLM推理和规划)”的问题。与上层的关系它们是被嵌套的。无论是 ReAct 中的 Thought还是 Plan-and-Execute 中的 Planner底层都在调用 CoT 或 ToT 来生成内容。2. 中观层行为循环ReAct —— “手眼协调的工作流”定位它是 Agent 与外部环境交互的标准循环Loop解决的是“如何边想边做”的问题。关系解析ReAct 的经典范式是Thought - Action - Observation。这里的Thought本质上就是一个带有“行动导向”的 CoT。ReAct 并没有发明新的推理方式而是给 CoT 加上了“手Action”和“眼Observation”。3. 宏观层系统编排Plan-and-Execute —— “项目经理的统筹”定位它是处理复杂长程任务的系统架构解决的是“先干什么、后干什么”的全局调度问题。关系解析Plan-and-Execute 将任务分为“规划Planner”和“执行Executor”。Planner规划在生成计划时通常会使用 CoT 甚至 ToT 来推演步骤的可行性。Executor执行在落地每一个子任务时通常会调用 ReAct 循环去实际操作。维度二正交插件关系Reflection 的角色Reflection反思不属于上述的执行链路它是一个“正交的优化/质控插件”。它可以挂载在上述任何一个层级上形成闭环1. Reflection CoT/ToT微观反思模型生成了一条推理链然后自己或另一个 Critic 模型检查这条推理链是否有逻辑漏洞如果有则重新生成。例如Self-Consistency, 自我纠错。2. Reflection ReAct中观反思Agent 执行了一个 Action 并得到了 Observation发现结果报错或不符合预期。此时触发 Reflection分析报错原因调整下一步的 Thought 和 Action。例如Reflexion 框架。3. Reflection Plan-and-Execute宏观反思Executor 执行完整个计划后Reflector 对比“最终结果”和“初始目标”发现偏题或质量不够于是触发 Replanning重新规划让 Planner 修改后续计划。维度三场景实战串联它们如何嵌套工作为了在文章中生动说明你可以用一个 “调研并撰写《2026 AI Agent 行业报告》” 的复杂任务来展示它们是如何嵌套运行的宏观启动 (Plan-and-Execute)Planner 接到任务使用 ToT 探索不同的报告结构目录A、目录B、目录C评估后选定目录B。Planner 生成执行计划[1. 搜集头部公司数据, 2. 分析技术路线, 3. 撰写总结]。中观执行 (ReAct 循环处理子任务 1)Thought (基于 CoT)“要搜集头部公司我需要先确定哪几家是头部我可以用搜索引擎查‘2025 AI Agent 独角兽’。”Action调用 Search API。Observation返回了 10 家公司的名字和链接。质控介入 (Reflection)Reflector 检查 Observation“搜索返回的 10 家公司中有 3 家是做传统软件的不符合 AI Agent 的定义。”反馈触发 ReAct 循环的下一轮 Thought“我需要修改搜索词加上‘核心产品为自主智能体’的限制。”宏观复盘 (宏观 Reflection Replanning)所有子任务执行完毕报告生成。宏观 Reflector 审阅报告“发现缺少对‘开源社区’的分析这与初始目标不符。”反馈通知 Planner触发 Replanning新增子任务[4. 补充开源社区分析]。总结核心差异与关系对比表概念抽象层级核心解决的问题输入 / 输出在 Agent 中的角色比喻CoT / ToT微观 (认知引擎)如何突破 LLM 单步生成的智力瓶颈问题 推理轨迹大脑 (思考逻辑)ReAct中观 (行为循环)如何让纯文本模型与真实世界/工具交互状态 (思考动作) 观察手脚与感官 (边想边做)Plan-and-Execute宏观 (系统编排)如何避免长程任务中的“迷失”与“遗忘”总目标 子任务列表项目经理 (排期与调度)Reflection正交 (质控插件)如何提升回答质量执行结果 评价与修正建议质检员/复盘会 (纠错优化)如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取