🌳 Tree of Thoughts
Agent 设计模式浅析系列(18)
把推理变成搜索——同时探索多条思路，评估后择优展开
为什么需要 Tree of Thoughts
很多任务不是"按步骤推下去"就能解决的。
规划路线、解谜题、做策略、写复杂方案——你走错第一步，后面写得再流畅也没用。
❌ Chain of Thought（线性）
一条路走到底，走错就全错
✅ Tree of Thoughts（树状）
├── 思路 A
│ ├── A1
│ └── A2
├── 思路 B
│ ├── B1
│ └── B2
└── 思路 C
├── C1
└── C2
评估 → 剪枝 → 继续展开 → 得到答案
多路并行，评估后择优
它把推理变成一个搜索问题。每一个 thought 都不是最终答案，而是一个中间状态。系统可以对这些状态打分，判断哪条路径更有希望，然后决定继续展开哪几条。
区别是：这里的节点不是棋盘状态或数字状态，而是模型生成的自然语言中间想法。
一个策略问题的例子
假设你问："一个面向程序员的 AI 写作工具，第一版应该做什么功能？"
❌ 线性 Agent 的回答
直接拍一个功能列表：
但这只是其中一条路，未必是最对的。
🌲 Tree of Thoughts 的做法
第 1 步：展开多条方向
第 2 步：评估
第 3 步：保留优胜路径继续展开
最终结论：
搜索不是越宽越好
Tree of Thoughts 最大的问题是贵。
如果每一步都生成 5 条路径，每条路径再展开 5 条，几层之后成本就爆了。
每轮最多生成几条候选
最多展开几层
每轮给候选打分
剪掉低分路径
什么时候停止搜索
不是所有任务都值得用 ToT。它适合那些"前期路径选择很重要"的任务：
🧩 复杂规划 🔢 数学和逻辑题 🎮 游戏决策 📊 产品策略 🏗️ 架构方案比较 🔧 多步骤排错
评估器（Evaluator）是关键
产品策略问题的评估维度
代码排错问题的评估维度
它和多 Agent 辩论有什么区别？
Tree of Thoughts 和 Multi-Agent Debate 都会生成多个观点，但它们不一样。
💬 Multi-Agent Debate
更像多人讨论：
观点碰撞，互相批判
🌳 Tree of Thoughts
更像一个人的深度思考：
单主体内部分支探索
最容易翻车的地方
1. 评估器不准
ToT 依赖评估器来知道哪些路径值得展开。如果评估器本身的判断力不够，搜了半天可能都是在垃圾路径上浪费资源。
2. 路径之间不够独立
如果多条路径本质上差不多，"多条思路"就变成了"同一个思路的多种说法"。分支之间应该有足够差异，搜索才有意义。
3. 搜索策略没选对
用 BFS 还是 DFS，深度设多少，剪枝阈值设多少——这些工程参数对最终效果影响很大。用错了等于白搜。
4. 成本失控
ToT 的 token 消耗远高于普通 Chain of Thought。如果任务本身不需要搜索，开 ToT 就是烧钱。
工程上怎么实现
1. 定义 Thought 节点
每个 thought 是一次 LLM 调用生成的中间结果。核心字段：
2. 实现搜索循环
3. 两种搜索策略
- BFS（广度优先）：逐层展开，适合"需要先广泛探索再深入"的任务
- DFS（深度优先）：优先深入某条路径，适合"深度优于广度"的任务
4. 关键控制参数
每层保留几条路径
最多展开多少层
低于几分就不展开
结果是否足够好
对 Tree of Thoughts 的理解
ToT 不是一个通用模型，而是一种推理调度策略。
它解决的不是模型"想得不够深"，而是"走得不够广"的问题。
用搜索对抗线性推理的盲区——这是它核心的洞察。
本质
ToT 本质上是把搜索算法和语言模型结合。语言模型负责生成节点（thoughts）和评估节点（evaluator），搜索算法负责调度。
适用场景
- 路径多、选择至关重要
- 走错一步成本很高
- 短 CoT 不够用
- 评估标准可以清晰定义
局限
- 贵（token 消耗远高于 CoT）
- 评估器决定了效果上限
- 搜索策略和参数需要精细调优
- 不适合路径明确或事实性问题
搜索 + LLM
把自然语言推理变成树搜索问题
评估→剪枝
不是所有路径都值得继续走
BFS/DFS
按任务选择搜索策略
非通用方案
选对场景才是关键