小白程序员进阶大模型：从思维链到思维图，保姆级学习指南

在 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，理论上可以解决任意可计算问题。
• 类比

角度二：信息外显 —— 把"工作记忆"变成"外部存储"

核心问题：中间结果"记不住"

多步推理需要保持中间结果。例如：

Roger有5个网球，他又买了2罐，每罐3个。他现在有多少个网球？ 步骤1：2罐 × 每罐3个 = 6个新球 步骤2：原有5个 + 新买6个 = 11个

步骤 2 需要用到步骤 1 的结果"6"。这个"6"存在哪里？

没有 CoT 时：中间结果只存在于隐层激活中

如果模型不显式输出"6"，这个值只存在于某一层的 hidden state 向量中。问题是：

1. 1. 容量有限：hidden state 是一个固定维度的向量（如 4096 维），能同时编码的信息量有上限。

2. 2. 信息衰减：随着后续层的计算，早期的中间信息会被逐步覆盖、稀释。

3. 3. 不可寻址：模型无法精确地"回去查看"某个特定的中间结果，它只能依赖 attention 机制模糊地"回忆"。

类比：纯心算。你需要在脑中同时记住多个中间结果，一旦步骤多了，前面的数就忘了。

有 CoT 时：中间结果被"写下来"成为 token

当模型输出"2×3=6"时，这个"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）。
• 导致后果：推理链看似严丝合缝，但最终答案完全错误（即“忠实地胡说八道”）。
• 解决方案：引入 ToT（Tree of Thoughts）：将单链升级为树状结构。在每一步生成多个候选分支，评估后保留最优分支（剪枝）；如果当前分支走入死胡同，允许回溯（Backtracking） 到上一个节点重新探索。

局限二：纯文本“空想”，缺乏事实依据与外部知识

• 问题描述：CoT 是一次LLM推理内完成的过程，无法获取外部知识和实时数据，只是模型在利用其训练数据在推理和回答。在长推理链中，模型极容易因为过时数据或缺乏外部知识在中间步骤“幻觉”出错误的事实或算错数字。
• 导致后果：推理逻辑是对的，但因为中间某个事实或数字是编造的，导致满盘皆输。
• 解决方案：引入 ReAct（Reasoning + 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 这么好，它有什么局限性吗？在实际 Agent 系统中你们是怎么解决的？”

候选人：“CoT 的核心局限性可以概括为三个词：单向、空想、短视。

第一是单向导致的错误累积。CoT 是一条单行道，中间一步算错，后面全错。为了解决这个问题，我们在复杂推理场景引入了 ToT（树状思维），允许模型在节点上进行多分支探索和自我评估，甚至回溯；或者在生成后引入 Reflection（反思机制） 让模型自己批改作业。

第二是空想导致的幻觉。LLM 本质是概率模型，不擅长精确计算和实时事实查询。纯文本的 CoT 很容易在中间步骤‘幻觉’出错误的数据。因此，我们将 CoT 升级为 ReAct 框架，让模型在推理链中能够调用计算器或搜索引擎，用外部的 Observation 来锚定内部的 Thought。

第三是短视导致的目标迷失。CoT 是走一步看一步的贪心策略，处理长程复杂任务容易跑偏。所以我们采用了 Plan-and-Execute 架构，先用 Planner 做全局的任务拆解，再让 Executor 在每个子任务里用 CoT 去执行，从而兼顾了全局视野和局部推理深度。

此外，在工程落地时，CoT 带来的高 Token 成本和延迟也是痛点，我们通常会通过动态路由（简单题不走 CoT） 。”

什么是 ToT？ToT 的推理过程是怎么样的？

如果说COT是线性推理，那么Tree of Thought（ToT）是一种将 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采样是每个候选 thought 都需要一次LLM调用，且由于温度较高，每个thought之间的差别会比较大；Propose提议则是一次LLM调用生成多个 thought；

组件二：State Evaluation（状态评估）

对生成的每个候选 thought（子节点），评估其"离最终目标还有多远"或"有多大可能通向正确答案"，为搜索算法提供方向信号。这个过程相当于为每个子节点进行打分。

两种评估方式

核心价值：剪枝（Pruning）

评估器的最大作用是提前砍掉没希望的分支，避免在低分分支浪费计算资源。

组件三：Search Algorithm（搜索算法）

决定以什么顺序和策略在思维树中探索节点。

三种基本策略

工程实践中，纯 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 值的影响

量化 Trade-off

假设每步生成 b=8 个候选，总共 n=5 步：

核心观察：总成本 ≈ n × k × b，beam 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（需要更多探索）

• 优化 3：Early Stopping（提前终止）

问题：如果某个分支在第 3 步就已经得到满分，还需要继续搜索吗？

解决：当 top-1 分支的评分远超 top-2 时（如差距 > 阈值），提前终止搜索，直接输出。

• 优化 4：与 DFS 回溯结合

问题：纯 Beam Search 不可回溯，一旦剪错就完了。

解决：保留被剪枝分支的"存档"，如果后续 top-k 分支全部失败，可以回溯到存档点，恢复之前被剪掉的分支。

Beam Search + 有限回溯： 正常流程：每步保留 top-k 异常处理：如果 top-k 全部评估为 impossible → 回溯到上一步 → 恢复当时被剪掉的 top-(k+1) 到 top-(2k) 分支 → 继续搜索

ToT vs CoT 对比总结表

• 面试回答模板

面试官：“ToT 相比 CoT 解决了什么核心问题？核心组件是什么？”

候选人："ToT 解决的核心问题是 CoT 的单链贪心和不可回溯。CoT 是一条路走到黑，中间错了无法挽回；ToT 把推理过程建模为一棵搜索树，允许多路径探索和回溯。

它有三个核心组件：

第一，Thought Generation（思维生成）——在当前节点生成多个候选的下一步推理，作为树的子节点。可以用多次采样或一次性提议的方式。

第二，State Evaluation（状态评估）——让 LLM 对每个中间状态打分或比较，判断它’离正确答案有多远’。核心作用是剪枝，避免在没希望的分支上浪费算力。

第三，Search Algorithm（搜索算法）——决定用什么策略遍历这棵树。BFS 适合步骤少分支多的问题（如 24 点），DFS 适合步骤多分支少的问题（如创意写作）。

三者协同：生成器负责’展开可能性’，评估器负责’判断好坏’，搜索算法负责’决定探索顺序’。本质上，ToT 是把经典的启发式搜索思想引入了 LLM 的文本生成过程。

代价是 token 消耗和延迟大幅增加，所以实际使用中需要权衡：
增强版 Plan-and-Execute + ToT：
Planner 用 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 的局限（树结构）：在树中，两个平行的分支（如方案 A 和方案 B）是孤立的。如果你想把 A 和 B 的优点结合起来，你无法直接连接它们，只能退回到它们的公共祖先节点重新生成。
• GoT 的突破（图结构）：在图中，方案 A 和方案 B 可以直接通过一条边“流向”一个新的节点 C（代表 A+B 的融合）。这种多对一（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。

• 具体表现

• 为什么聚合操作特别贵？

ToT 的评估 Prompt： "请评估这个中间状态的质量：[单个节点内容] → 打分" 输入：1 个节点（~200 token） GoT 的聚合 Prompt： "请将以下三个方案融合为一个综合方案： 方案A：[完整内容 ~1000 token] 方案B：[完整内容 ~1000 token] 方案C：[完整内容 ~1000 token] 请分析各自优缺点并整合。" 输入：3 个节点（~3000 token）+ 输出：融合结果（~1500 token）

聚合操作的输入 Token 是多个节点的叠加，而非单个节点。当节点内容较长时（如长文本生成），一次聚合操作可能消耗大量token。

挑战二：图结构的工程编排复杂度极高

CoT 只需改一句 Prompt，ToT 需要维护一棵树，而 GoT 需要维护一个有向无环图（DAG）+ 复杂的操作调度逻辑。工程实现的复杂度呈阶跃式上升。

• 具体表现

与 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. 1. Reflection + CoT/ToT（微观反思）：模型生成了一条推理链，然后自己（或另一个 Critic 模型）检查这条推理链是否有逻辑漏洞，如果有则重新生成。（例如：Self-Consistency, 自我纠错）。

2. 2. Reflection + ReAct（中观反思）：Agent 执行了一个 Action 并得到了 Observation，发现结果报错或不符合预期。此时触发 Reflection，分析报错原因，调整下一步的 Thought 和 Action。（例如：Reflexion 框架）。

3. 3. Reflection + Plan-and-Execute（宏观反思）：Executor 执行完整个计划后，Reflector 对比“最终结果”和“初始目标”，发现偏题或质量不够，于是触发 Replanning（重新规划），让 Planner 修改后续计划。

维度三：场景实战串联（它们如何嵌套工作？）

为了在文章中生动说明，你可以用一个 “调研并撰写《2026 AI Agent 行业报告》” 的复杂任务，来展示它们是如何嵌套运行的：

1. 宏观启动 (Plan-and-Execute)

• Planner 接到任务，使用 ToT 探索不同的报告结构（目录A、目录B、目录C），评估后选定目录B。
• Planner 生成执行计划：[1. 搜集头部公司数据, 2. 分析技术路线, 3. 撰写总结]。

2. 中观执行 (ReAct 循环处理子任务 1)

• Thought (基于 CoT)：“要搜集头部公司，我需要先确定哪几家是头部，我可以用搜索引擎查‘2025 AI Agent 独角兽’。”
• Action：调用 Search API。
• Observation：返回了 10 家公司的名字和链接。

3. 质控介入 (Reflection)

• Reflector 检查 Observation：“搜索返回的 10 家公司中，有 3 家是做传统软件的，不符合 AI Agent 的定义。”
• 反馈：触发 ReAct 循环的下一轮 Thought：“我需要修改搜索词，加上‘核心产品为自主智能体’的限制。”

4. 宏观复盘 (宏观 Reflection + Replanning)

• 所有子任务执行完毕，报告生成。
• 宏观 Reflector 审阅报告：“发现缺少对‘开源社区’的分析，这与初始目标不符。”
• 反馈：通知 Planner，触发 Replanning，新增子任务[4. 补充开源社区分析]。

总结：核心差异与关系对比表

如何学习大模型 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大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

以上全套大模型资料如何领取？