Tree of Thoughts：让 LLM 学会"深思熟虑"的搜索式推理

• 关联论文：2305.10601
• 作者：spark
• 更新：2026-07-21

一句话结论

Tree of Thoughts（ToT）把 Chain-of-Thought 的一次性"线性思考"扩展成显式树结构搜索——把推理拆成"思想"（thoughts）作为中间节点、用 LM 自己评估（self-evaluation）来打分、必要时回溯或前瞻——在 Game of 24、创意写作、迷你填字三个需要非平凡规划的难题上，相对 CoT 给出大幅能力跃升，最显著一项从 4% 拉到 74%。

它要解决的真问题

Chain-of-Thought（CoT）的隐含假设是：模型只要被鼓励"一步一步想"，就能在所有任务上推理得更好。但事实是：

• 很多问题需要前瞻（我先走这步，后面的展开会失败）和回溯（前面这步走错了，要换一条）。
• 经典 LLM 推理是 token 级、从左到右、不可撤销的——天然不适合"探索多条路径"。
• 在需要全局搜索的任务（24 点、填字、规划）上，CoT 容易"卡死"在第一条看似合理的路上，犯错的早期决策无法修正。

ToT 的核心命题：把推理从"线性 CoT"升级成"显式树 + LM 自评估 + 经典搜索算法"。

核心方法

1. 思想树（Thought Tree）抽象

把问题拆成若干步"思想"——每个思想是连贯的一段文字（不是单个 token），代表向答案推进的中间状态。整棵树的节点就是 thought，边是 thought 之间的逻辑延伸。

四种基础操作：

• Thought decomposition（拆解）：定义怎样从当前状态产生 k 个候选下一步。
• Thought generation（生成）：用 LM 的 CoT 采样能力生成候选 thought（可同 prompt 内采样 k 次）。
• State evaluation（评估）：让 LM 给自己打"这个分支是否值得继续"的分数（value）/是否判定终结（is_solved）。
• Search（搜索）：BFS、DFS 或 beam search 组合以上三者。

2. 两个关键设计：候选多样性 + 自评估

• 多样性：单纯让 LM 一次性写出最终解很容易陷入同质化；ToT 要求每条候选都从 LM 独立采样，用温度、采样多样性来保持分支差异。
• 自评估：要避免"只有最终答案"的硬反馈，所以让 LM 模仿"裁判"角色，对每个 thought 给出"sure / likely / impossible"等离散打分或 1–10 数值分。这一步是 ToT 的"灵魂"——把 LM 的内部判断显式用作搜索的 value。

3. 三个任务的实例化

ToT 是框架而非单一算法，论文展示了它在不同任务上的实例化方式，并对每个任务的 thought 拆解方式、评估准则、搜索策略都做了详细描述。这种"同一个骨架、不同领域实例化"的设计后来被许多后续工作（Reasoning via Planning、LLM-MCTS、Tree Search for Agents）继承，成为"LLM + 搜索"领域的标准设计模式。

任务	thought 形态	评估方式	搜索算法
Game of 24	数字三元组 + 候选运算	LM 打分 + 求解验证	BFS
Creative Writing	段落级草稿	LM 1–10 打分	BFS
Mini Crosswords	单词填字	候选词可能性打分 + 局部状态检查	DFS + 回溯

伪代码核心逻辑：

def ToT(problem):
    root = make_thought(problem)
    frontier = [root]
    for step in range(max_depth):
        candidates = []
        for node in frontier:
            node.thoughts = LM_generate_thoughts(node, k=k)   # 采样
            for t in node.thoughts:
                value = LM_evaluate(t)                         # 自评估
                candidates.append((t, value))
        candidates.sort_by(value)
        frontier = top_beam(candidates, b=beam_size)
        # 检查是否到达终止状态（已解 / 不可解）
        solved = any(LM_is_solved(c) for c in frontier)
        if solved: return best(frontier)
    return best(frontier)

关键实验与数据

论文在三个任务上对比了四种设置：IO（标准回答）、CoT（单次链式思考）、CoT-SC（self-consistency 多采样投票）、ToT：

• Game of 24（用 4 个数字凑 24）：
• GPT-4 + CoT：4%
• GPT-4 + CoT-SC：9%
• GPT-4 + ToT：74%
• 这条 abstract 显式给出的对比是论文最具冲击力的数字。
• Creative Writing：在连贯性 / 整体性等人类评分指标上，ToT 的故事被一致偏好（具体百分点以原论文 table 为准，abstract 未给出统一数字）。
• Mini Crosswords：ToT 在字谜 / 文字游戏子任务上的单词级成功率相对 CoT 也显著上升。

值得注意的是：GPT-4 + CoT-SC 在 Game of 24 上只到 9%，意味着单纯增加采样数并不解决问题——必须给模型"看错就重选"的机制，这正是 ToT 的关键。

论文还做了一组消融实验：分别去掉"分支采样"或"自评估"或"搜索算法"，观察性能下降程度。这组消融非常关键，因为它把 ToT 的能力来源拆成三条独立贡献——"采样多样性"是底盘，"自评估"是导航，"搜索算法"是装配。三者缺一性能都会显著缩水，其中自评估的贡献在 Game of 24 上最显著——没有评估，搜索就成了纯随机扩展。这也提示后来研究者：要替换 ToT 框架时，最先要补强的就是评估器，而不是搜索算法本身。

另外在模型规模敏感性上，论文报告 ToT 增益随 LM 能力提升而扩大：GPT-4 + ToT 远好于 GPT-3.5 + ToT，这说明 ToT 的"自我评估"严重依赖模型本身具备一定判断力——这一发现对今天做小模型 + 推理增强的研究非常重要。

亮点与局限

亮点

1. 首次把"LM 当作搜索算法里的启发式函数"系统化：自评估 + 树搜索在 classical AI 里很普通，但 ToT 把它搬到了 LLM 的 prompt 层。
2. 任务无关的框架：同一套 ToT 抽象可以承载数学推理、创意写作、约束求解等差异极大的任务。
3. 可解释性：每条路径都被显式存下来，可以审计模型是怎么推出结论的，比单条 CoT 更容易回溯错误。
4. 强基线带动：论文用 GPT-4 而非 GPT-3.5 主导实验，给出"强模型 + 强结构 = 能力跃迁"的证据。

局限

1. 代价：每次产生 b 个分支 × d 层深度 × 每节点 k 个采样，对 LM 推理调用次数是 CoT 的数十到上百倍。
2. 自评估的可靠性依赖模型能力：ToT 的价值函数来自 LM 自身打分——如果 LM 不会评估（比如 GPT-3.5 在 Game of 24 上评估就不稳），ToT 收益会缩水。
3. 领域受限：在"无法拆解成 thought"或"无清晰评估信号"的任务上（比如开放聊天），ToT 没有合适的位置。
4. 手工结构：每个任务的 thought 形态、prompt 模板、评估 prompt 都要单独设计；不像 CoT 那样一句"think step by step"就能套。
5. 抽象层级问题：ToT 的"thought"是连贯文字段落，对纯数学 / 代码这类需要精确符号中间态的任务，不如显式符号搜索（AlphaZero 类）干净。

对工程落地的启发

• 不要给所有任务套同一个 CoT：复杂规划、约束满足、长链推理任务，可以显式做"分支 + 评估 + 回溯"。
• LM 自评估可作为轻量裁判：很多场景下，让 LLM 自己做"这个答案对不对"的判定比调一个外部 reward model 便宜得多。
• 代价可控地落地：用较小 beam（b=1–3）+ 浅深度（d=2–4）就能取得明显收益，不必追求论文中的极宽搜索。
• 审计与可控性：ToT 风格的中间输出适合做"可追溯 AI"产品（每一步解释、可回滚）——这一思路对 agent / tool use 同样有用。
• 不要强套到对话任务：ToT 不适合低延迟聊天场景，但在离线规划（行程、调研、长文档摘要的多个方案对比）里非常合适。
• 借鉴 Self-Refine / Reflexion：ToT 之后出现了不少"自我反思 / 自我迭代"工作，本质都是把 ToT 的自评估做成循环而不是显式树，代价更低，可作为轻量化替代。

与同方向工作的关系

• 相对 Chain-of-Thought（Wei et al., 2022）：把"线性思维链"换成"显式树 + 搜索 + 自评估"。
• 相对 Self-Consistency（Wang et al., 2022）：SC 是采样多个 CoT 然后投票，不做过程评估；ToT 是显式过程评估。
• 相对 ReAct（Yao et al., 2022）：ReAct 让 LM 与环境交互；ToT 让 LM 与自己的"思路空间"交互——但两者后来被反复结合（ToT on Tool、ReAct with Backtracking）。
• 相对 RAP（Reasoning via Planning, Hao et al., 2023）：RAP 用 MCTS 把 LLM 当世界模型 + 启发式；ToT 更偏向 BFS/DFS 的轻搜索，二者在 2023 年中后期被并行提出。
• 后续衍生：Tree of Thought 在代码生成（CodeTree）、agent planning（ToT on Tools）、搜索增强生成（Search-Augmented Reasoning）中被广泛复用。

适合谁读

• LLM 推理 / planning 研究者；
• 做 agent / tool use 系统的工程团队（ToT 的搜索骨架几乎是 agent 决策树的雏形）；
• 关注 LLM 推理可解释性、安全性、审计需求的产品负责人；
• 对"经典 AI 搜索 + 现代 LLM 启发式"交叉方向感兴趣的学生与从业者。

一句话给老板

ToT 把 LLM 的"思考"从一次性线性 CoT 升级成"显式树搜索 + 自评估 + 回溯"，在 24 点等需要规划的任务上把 GPT-4 的成功率从 4% 拉到 74%——代价是推理调用数十倍增加，但思路是后续几乎所有 LLM agent 与决策搜索系统的祖先。

关键参考资料

• Chain-of-Thought Prompting Elicits Reasoning in Large Language Models (Wei et al., 2022)
• Self-Consistency Improves Chain of Thought Reasoning in Large Language Models (Wang et al., 2022)
• ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022)
• Reasoning via Planning (RAP, Hao et al., 2023)
• Self-Refine: Iterative Refinement with Self-Feedback (Madaan et al., 2023)
• 官方代码仓库：princeton-nlp/tree-of-thought-llm

几个常被问到的工程细节

• beam size 取多少？ Game of 24 用了 b=5；Creative Writing 用 b=1（仅分支 + 选优）；Mini Crosswords 用 b=1 + DFS。说明 b 不是越大越好，应随任务"宽度"调整。
• 评估 prompt 的稳定性：论文报告对 Game of 24 来说，"impossible"的评估必须靠 GPT-4 才能可靠，GPT-3.5 的评估准确度明显低。这是 ToT 在小模型上跑不动的主因。
• 搜索深度：Game of 24 的 thought 链长度被刻意压到 4 步（24 = 三个二元运算），过深的 thought 反而会让 LM 写更多噪声。
• 是否一定要显式树？ 后续工作（Self-Refine、Reflexion）证明"循环式自评估"可以部分替代 ToT 的显式树——代价更低，结构更简单，但收益也略小。

复现与上手提示

• prompt 工程是核心：所有 prompt（thought 生成、value 评估、状态判断）都直接决定 ToT 效果。论文开源了所有 prompt 模板，可以直接复用，但换成新任务必须重写。
• API 成本估算：单次 Game of 24 任务，ToT 设置下大约需要 50–100 次 GPT-4 API 调用，而 CoT 仅需 1–5 次——成本是 10×–50×。
• 小模型替代：在小模型上 ToT 经常退化成纯采样浪费，因为 value 评估不稳；可用"外部 solver + LM 自评"的混合结构做折中。
• 与 ReAct 的混合用法：在 agent 框架里，可以先用 ToT 选 top-1 thought，再交给 ReAct 执行具体工具调用——这是后续 agent 设计里很常见的组合方式。

一段总结

ToT 的真正贡献是把"LLM 推理"从"生成更多 token"升级为"在思考空间里搜索"。这一思想直接影响后续所有"LLM + 搜索"方向：ReAct 把搜索空间换成工具调用、Reflexion 把树换成自我反思循环、AlphaCode 类工作把搜索空间换成代码生成与执行——它们都能在 ToT 的设计哲学里找到起点。

今天再回头看，ToT 几乎已经成为 LLM 推理增强的"必修一课"：即使不使用它的搜索骨架，理解它把"推理当搜索问题"重新建模的视角，也能帮助你更好地理解后续的 Reasoning via Planning、Tree Search for Agents、AlphaCode 类工作。

工程落地与核查（Jay）

⚠️ 事实核查存疑处

存疑点	位置	说明
74% Game of 24 准确率	§关键实验	abstract 原文为 "74%"，与 arXiv OG meta 一致；数字本身可信
"50–100 次 GPT-4 API 调用"	§复现与上手	⚠️ 此数字为解读估算，非原文数据；GPT-4 当时 context 窗口更大，此数字未标注采样策略；生产部署前需实测
ToT 是"后续所有 LLM agent 祖先"	§一句话给老板	⚠️ 偏强；AlphaCode（2022/12）早于 ToT（2023/5），其搜索骨架为代码执行+测试反馈，并非 ToT 直系后代；ReAct（2022/11）与 ToT 同期独立提出；表述宜改为"核心思想源头之一"
GPT-3.5 评估不稳定	§局限	原文实验数据支持；但 2024 年后 GPT-3.5 已大幅升级，此局限需按模型版本重新评估
GitHub repo princeton-nlp/tree-of-thought-llm	§关键参考资料	arXiv abstract 明确链接；repo 真实存在且开源

实际系统怎么用

ToT 工程化最小实现（Python）：

from openai import OpenAI
client = OpenAI()

def tot_solve(game_problem, max_depth=4, beam_size=5, k=3):
    """Game of 24 最小 ToT 实现"""
    frontier = [{"state": game_problem, "path": [], "value": None}]

    for step in range(max_depth):
        candidates = []
        for node in frontier:
            # 生成 k 个候选 thought
            thoughts = generate_thoughts(node["state"], k=k)
            for t in thoughts:
                # LM 自评估
                value = evaluate_state(t, prompt_type="game24")
                candidates.append({"state": t, "path": node["path"] + [t], "value": value})

        # beam select
        candidates.sort(key=lambda x: x["value"], reverse=True)
        frontier = candidates[:beam_size]

        if any(is_solved(c["state"]) for c in frontier):
            return best(frontier)

    return best(frontier)

def evaluate_state(state, prompt_type="game24"):
    """value prompt 由论文提供，需替换为实际模型调用"""
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": GAME24_EVAL_PROMPT.format(state=state)}]
    )
    # 解析 sure/likely/impossible → 数值
    text = response.choices[0].message.content
    if "sure" in text.lower(): return 3
    elif "likely" in text.lower(): return 2
    else: return 1

轻量化替代（Self-Refine 循环）：

def self_refine_loop(problem, max_iters=5):
    """ToT 的低代价替代：线性循环而非显式树"""
    solution = generate_initial(problem)
    for _ in range(max_iters):
        feedback = get_llm_feedback(solution)
        if feedback.accept:
            return solution
        solution = refine(solution, feedback)
    return solution

坑与失败案例

1. beam=5 × depth=4 × k=3 = 60 个分支：每分支一次生成 + 一次评估 = 120 次 API 调用/任务；GPT-4o 成本约 $0.01–0.02/任务；生产大规模部署前必须做成本收益分析，任务成功率提升是否值得 50× cost。
2. 自评估器是 ToT 的核心单点故障：Game of 24 上"impossible"判断必须 GPT-4；用 GPT-3.5 做 judge 会把可解问题错误剪枝到 0%；选 judge 模型比选生成模型更关键。
3. Prompt 迁移灾难：论文 prompt 对 Game of 24 精心设计，换任务（如数学规划）需要重新设计 thought 分解 + 评估 prompt；ToT 的"通用性"实际上需要大量领域特定工程。
4. 小模型上 ToT 比 CoT 更差：GPT-3.5 + ToT 在 Game of 24 上甚至不如 GPT-3.5 + CoT-SC，因为自评估不稳定导致错误搜索方向比盲目采样更糟；7B/13B 模型不要用完整 ToT，用 Self-Refine 替代。
5. Thought 粒度无通用标准：对于"写一首诗"，一个段落作为 thought 合理；但对于"解一道数学题"，应该每步等式变换还是一个完整解题思路？论文未给出通用设计原则，工程上需要大量 trial & error。
6. 与 ReAct 混用时的状态管理：ToT 选择 top-1 thought 后交给 ReAct 执行工具，结果再喂回 ToT——这个跨框架状态同步在工程上容易出错，工具执行失败后 ToT 的回溯机制与 ReAct 的错误处理需要协调设计。

ToT vs 竞品工程对照（2026 年）

方案	适用场景	API 调用倍数	工程成本	小模型可用性
CoT	低延迟、简单推理	1×	极低	良好
CoT-SC (k=40)	代码、数学、推理	~10×	低	中等
ToT (b=5, d=4)	复杂规划、约束满足	~50–100×	高	差
Self-Refine	中等复杂、迭代改进	~5–10×	中	良好
RAP (MCTS)	开放世界规划	~50–200×	极高	差
ReAct + ToT 混合	Agent 工具调用	~20–80×	高	中