跳到主要内容

Tree-of-Thoughts

Tree of Thoughts（ToT）把复杂问题求解表示为对中间思维状态的搜索。

它不是简单地让模型“多想几步”。

它把问题求解拆成：

  • 生成多个候选中间状态。
  • 评估这些候选状态。
  • 保留更有希望的分支。
  • 继续扩展。
  • 必要时回溯或剪枝。

对 Agent 工程来说，ToT 的价值在于把规划器拆成 Generator、Evaluator 和 Search Controller。

它适合高价值、低频、可评估的复杂任务。

它不适合所有场景，尤其不适合低延迟、低成本或评估器不可靠的请求。

1. 背景问题​

传统输入输出提示让模型直接给答案。

Chain-of-Thought 让模型沿着一条推理路径展开。

但很多复杂问题的难点不是“推一步”，而是：

  • 需要比较多个候选方案。
  • 早期错误会导致整条路径失败。
  • 需要回溯。
  • 需要中间评估。
  • 需要在有限预算内探索。

例如：

  • 数字游戏需要组合搜索。
  • 代码修复可能有多个候选方向。
  • 项目计划需要比较风险和收益。
  • 检索任务需要尝试不同查询路径。

Tree of Thoughts 的思想是：不要只采样一条思维链，而是把中间解看成树节点，对节点进行搜索。

2. 一句话结论​

ToT 是一种搜索式推理框架，适合“候选方案可生成、可评估、值得花预算搜索”的任务；如果没有可靠评估器，它只会把单次错误变成更昂贵的多分支错误。

3. 方法结构​

工程化组件：

组件职责关键设计
State表示当前中间解必须可序列化、可比较、可回放
Generator产生候选下一步控制候选数量和多样性
Evaluator评估候选质量优先使用测试、规则、工具或人工标注
Search Controller决定扩展、剪枝、终止控制深度、宽度、预算和回溯
Trace Store保存搜索过程支持调试和离线分析

4. 搜索策略​

ToT 论文讨论了不同搜索方式。

工程上常见的选择包括：

策略适用场景优点缺点
Breadth-First Search浅层候选比较不容易错过同层好方案成本随宽度快速增长
Depth-First Search深层探索内存和并发压力较低早期选错会浪费深度预算
Beam Search每层保留 top-k成本可控评估器偏差会剪掉好分支
Best-First Search总是扩展当前高分节点更聚焦高价值分支分数不准时会陷入局部最优
MCTS-like Search需要探索和利用平衡适合复杂决策实现和调参成本高

选择策略前要先回答：

  • 单个状态能否被客观评估。
  • 候选数量是否可控。
  • 搜索失败能否回放。
  • 延迟预算是否允许多次模型调用。
  • 是否存在工具或测试作为验证器。

5. 实验设置与证据边界​

Tree of Thoughts 论文在几个任务上展示效果。

代表任务包括：

  • Game of 24。
  • 创意写作。
  • 迷你填字游戏。

这些任务的共同特点是：

  • 单一路径容易失败。
  • 候选中间步骤可以生成。
  • 中间状态可以被评分或投票。
  • 最终答案可以判断质量。

论文证据支持：

  • 搜索式推理在需要探索和回溯的任务上可能优于单路径推理。
  • 显式候选生成和评估能改善部分复杂问题表现。
  • 模型既可以做 generator，也可以做 evaluator。

证据不支持：

  • 所有任务都应该使用 ToT。
  • 模型自评始终可靠。
  • 增加分支一定提升质量。
  • 中间 thought 的自然语言解释一定忠实。

6. 核心贡献​

ToT 的贡献主要有三点。

第一，把语言模型推理抽象成搜索问题。

这让工程师可以使用已有搜索概念：宽度、深度、剪枝、回溯、预算。

第二，把中间状态显式化。

这使规划器可以在最终答案前比较多个方案。

第三，把评估器从生成器中拆出来。

虽然评估器仍可由模型实现，但工程上可以替换成测试、规则、模拟器或人工审核。

7. 局限表​

局限表现工程后果缓解方式
成本高多分支多深度带来大量调用延迟和费用上升限制宽度、深度、总 token 和并发
评估器不可靠模型评分可能偏好流畅但错误方案错误分支被保留优先使用可验证信号
状态难定义开放任务中 thought 粒度不清搜索树不可比较设计结构化 state schema
分支爆炸候选过多预算耗尽仍无解剪枝、去重、启发式排序
不适合事实缺口缺少外部事实时只靠搜索无用编造更多推理结合检索和工具验证
Trace 复杂搜索过程比线性轨迹难调试失败归因困难保存完整搜索树和评分理由

8. 今天工程系统如何借鉴​

ToT 最适合借鉴到复杂规划和候选方案比较。

例如：

  • 代码修复方案选择。
  • 数据分析路径选择。
  • 多步骤检索策略。
  • 架构方案权衡。
  • 低频高价值决策支持。

一个工程化 state schema 示例：

{
  "node_id": "n_003",
  "parent_id": "n_001",
  "depth": 2,
  "candidate_plan": [
    "先读取错误日志",
    "定位失败测试",
    "修改 parser 边界条件"
  ],
  "evidence": ["trace_12", "test_failure_8"],
  "score": {
    "correctness": 0.72,
    "risk": 0.2,
    "cost": 0.35
  },
  "status": "expand"
}

这比保存一段自然语言 thought 更容易评测和回放。

9. 不能直接照搬的地方​

不要把 ToT 用在所有请求上。

很多任务只需要一次工具调用或简单问答。

ToT 会显著增加成本和延迟。

不要只让模型自己评价模型。

在代码、数学、数据库查询、配置生成等任务中，应优先接入：

  • 单元测试。
  • 类型检查。
  • SQL dry run。
  • 规则校验。
  • 静态分析。
  • 沙箱执行。

不要让搜索分支执行真实副作用。

分支探索应该在模拟、草稿或只读环境中进行。

真正执行前需要选择单一路径并通过权限检查。

10. 评测方法​

评测 ToT 类系统要看搜索是否带来净收益。

指标说明评测方式
Success Lift相比单路径方法的成功率提升固定任务集 A/B
Cost Multiplier成本相对基线增加倍数token 和工具日志
Latency Multiplier延迟相对基线增加倍数请求追踪
Evaluator Accuracy评估器是否选中好分支人工或测试对比
Prune Error Rate正确分支被剪掉的比例搜索树复盘
Duplicate Branch Rate重复候选比例节点相似度统计
Safety Violation分支是否触发越权动作安全评测

评测流程：

1. 选择需要规划和回溯的任务集。
2. 建立单路径 CoT 或 ReAct 基线。
3. 固定模型和工具版本运行 ToT。
4. 分别记录成功率、成本、延迟和搜索树。
5. 抽样分析被剪掉的分支是否可能更好。
6. 只在收益超过成本的任务类型上启用 ToT。

11. 安全与治理​

ToT 的安全风险来自多分支探索。

如果每个分支都可以调用工具，风险会被放大。

风险包括：

  • 多个分支重复访问敏感数据。
  • 候选方案中包含危险操作。
  • 评估器偏好绕过约束的方案。
  • 搜索过程泄漏用户数据到外部工具。
  • 分支执行造成不可逆副作用。

治理要求：

  • 分支默认只读或模拟执行。
  • 高风险工具在搜索阶段禁用。
  • 搜索节点保存权限上下文。
  • 评估器不能只看完成度，也要看风险。
  • 最终执行路径必须单独审批。

12. 适用与不适用场景​

适用场景：

  • 有明确评估器的复杂问题。
  • 候选方案数量适中。
  • 任务价值足以覆盖额外成本。
  • 允许几秒到几十秒延迟。
  • 需要比较多个规划方案。

不适用场景：

  • 简单事实问答。
  • 实时低延迟交互。
  • 没有评估器的主观开放任务。
  • 每个分支都可能产生真实副作用的任务。
  • 成本预算很紧的批量请求。

13. 与其他方法的关系​

ReAct 是线性执行循环。

ToT 是树状候选搜索。

Reflexion 是尝试之间的失败学习。

Toolformer 关注工具调用能力如何通过数据学习。

在复杂 Agent 中，这些方法可以组合：

  • 用 ToT 生成候选计划。
  • 用 evaluator 选出计划。
  • 用 ReAct 执行计划。
  • 用 Reflexion 复盘失败。

14. 权威资料​