跳到主要内容

Tree-of-Thoughts

核对日期：2026-05-09。

1. 定义与边界​

Tree of Thoughts（ToT）是一种让语言模型显式生成多个中间 thought，并通过搜索、评估、回溯选择更优路径的推理方法。论文将其视为对 Chain-of-Thought 的扩展：不只沿一条链往下推，而是在树结构中探索多个候选。

ToT 不是通用提速方法。它通常会增加模型调用次数，适合高价值、需要探索的难题。

2. 为什么重要​

单一路径推理一旦早期方向错误，后续很难恢复。ToT 通过生成多个候选 thought，并用自评或外部评估选择路径，提升复杂推理、规划、谜题和搜索问题的成功率。

3. 核心机制​

ToT 的三个关键函数：

  • propose(state) -> thoughts：生成候选下一步。
  • evaluate(thought) -> score：评估候选价值。
  • search(tree) -> path：选择 BFS、DFS、beam search 等策略。

4. 架构模式​

模式描述适用
BFS ToT每层扩展多个候选需要全局比较
DFS ToT深入一个候选，失败回退搜索空间大但可早停
Beam ToT每层保留 top-k成本受控
Tool-augmented ToTthought 扩展可调用工具数学、代码、搜索

5. 工程实现​

def tree_of_thoughts(problem, depth=4, width=3, beam=2):
    frontier = [Node(state=problem, score=0)]
    for _ in range(depth):
        candidates = []
        for node in frontier:
            for thought in propose(node.state, n=width):
                new_state = apply_thought(node.state, thought)
                score = evaluate(new_state)
                candidates.append(Node(new_state, score, parent=node))
        frontier = sorted(candidates, key=lambda x: x.score, reverse=True)[:beam]
    return verify_and_select(frontier)

工程约束：

  • thought 要有结构，例如假设、下一步、预期证据。
  • evaluator 不应只看语言流畅度，应看目标进展。
  • 对每层扩展设置预算，避免指数爆炸。
  • 对最终候选使用独立 verifier 或工具验证。

6. 生产实践​

  • 只对高价值复杂步骤启用 ToT，不要全链路启用。
  • 缓存重复 thought 和工具结果。
  • 对候选路径保留证据，便于解释为什么选择该路径。
  • 将 ToT 包装为 Planner 内部策略，而不是暴露给所有执行步骤。
  • 对评分 prompt 做对抗测试，防止模型偏好自信但错误的候选。

7. 常见反模式​

  • 宽度和深度无上限，成本不可控。
  • 用同一个模型生成、评估、最终回答，且无外部验证。
  • thought 只是重复改写，没有状态变化。
  • 对简单任务使用 ToT，增加时延但无收益。
  • 评分标准空泛，例如“哪个更好”。

8. 评测方法​

  • Success Lift：相对单路径 CoT/ReAct 的成功率提升。
  • Cost per Success：每个成功任务的平均成本。
  • Search Efficiency：有效候选占比。
  • Evaluator Accuracy：评分是否能预测最终正确性。
  • Diversity：候选 thought 是否真正覆盖不同策略。

9. 安全与治理​

  • ToT 会放大 prompt injection，因为多个候选可能探索危险路径。
  • 对工具增强 ToT，必须限制每个 thought 可调用的工具范围。
  • 不保留含敏感数据的完整 thought 树，或做加密和脱敏。
  • 对高风险任务，候选路径不能绕过审批。

10. 工程手册补充​

10.1 搜索状态与控制流​

Tree of Thoughts 适合做候选方案搜索，不适合直接当生产执行计划。工程实现要把“想法节点”和“执行步骤”分开。

{
  "node_id": "n7",
  "parent_id": "n3",
  "depth": 2,
  "thought": "先按供应商类别聚类，再分别评估违约风险",
  "score": 0.78,
  "score_reason": "覆盖多类供应商，但需要额外数据",
  "constraints_satisfied": ["no_external_send"],
  "expanded": false
}

10.2 失败模式与上线限制​

失败模式表现修复
搜索爆炸分支数和 token 成本快速上升限制 beam width、depth、预算
自评偏差模型给自己生成的想法打高分加入规则评分、外部 verifier 或测试
想法不可执行最佳路径无法映射到工具步骤输出前做 executable plan conversion
约束遗忘深层节点丢失原始限制每个节点保存 constraints_satisfied

上线清单：

  • ToT 只用于高价值复杂推理，不用于普通 FAQ 或低风险固定流程。
  • 搜索预算显式配置：最大深度、最大节点数、最大成本、最大延迟。
  • 最佳 thought path 必须转成 Plan 再执行，不能直接拿自然语言驱动工具。
  • 评测同时看成功率提升和成本放大，不只展示单个样例。
  • 安全上禁止未验证 thought 直接触发写工具或外部发送。

10.3 工程化评测样例​

ToT 的评测样本应同时保存搜索轨迹和最终产物，便于判断收益是否来自真实搜索。

{
  "case_id": "tot_case_001",
  "problem": "选择一套低风险的数据迁移方案",
  "baseline_answer": "直接全量迁移",
  "expected_properties": [
    "包含回滚策略",
    "包含灰度验证",
    "不绕过审批"
  ],
  "search_assertions": {
    "max_depth": 3,
    "min_alternative_branches": 2,
    "requires_pruning_reason": true
  },
  "success_criteria": {
    "final_plan_executable": true,
    "cost_multiplier_lte": 2.0
  }
}

上线前至少比较三组：

方案用途通过条件
Direct answer判断普通回答上限作为最低成本 baseline
Plan-only判断显式计划收益成功率明显高于 direct
ToT + plan conversion判断搜索收益成功率或风险识别提升能覆盖成本

11. 权威资料​