从链到树
CoT 是一条路走到底。Self-Consistency 是多走几条路，最后看答案是否一致。Tree of Thoughts 更进一步：既然推理过程里会有很多中间选择，那不如把这些选择显式组织成树。
我读这篇时最关心的是，它和“多采样 CoT”到底有什么区别。我的理解是：ToT 不是简单生成很多完整答案再投票，而是在每一个中间状态生成候选 thought，评估它们，再决定保留哪些继续扩展。
也就是说，它把推理问题改造成了搜索问题。
ToT 要回答四个实现问题
论文里其实给了一个很工程化的框架。要把一个任务做成 ToT，需要回答四件事：
- 中间过程怎么分解成 thought；
- 每个状态怎么生成下一批候选 thought；
- 怎么评估某个状态有没有前途；
- 用什么搜索算法继续探索。
这四个问题比“让模型 think step by step”具体得多。比如写作任务里，一个 thought 可能是一段大纲；数学任务里，一个 thought 可能是一组方程；游戏任务里，一个 thought 可能是下一步操作。thought 太小，搜索树会爆；thought 太大，又回到普通 CoT。
状态评估是关键
ToT 的好处来自前瞻和回退，但前提是你能判断哪些分支值得继续。
论文里有两类评估方式：一种是让模型给每个状态打分；另一种是在多个状态之间投票。前者适合能量化前景的任务，后者适合很难直接打分但可以比较的任务。
这也是工程落地时最麻烦的地方。生成候选 thought 很容易，难的是评估器是否可靠。如果评估器本身也被同一个模型的偏见带歪，搜索树只会更有条理地走向错误答案。
搜索算法让它不只是 prompt
ToT 可以接 BFS、DFS，也可以继续扩展成 A* 或 MCTS。这个设计让我觉得它更像一个“LM + 搜索控制器”的系统，而不是单纯 prompt 技巧。
BFS 适合按层扩展、每层剪枝；DFS 适合深入探索某条路径。无论哪种，都需要资源预算。ToT 的计算成本通常会比 CoT 或 Self-Consistency 高不少，所以它更适合那些搜索空间小但局部选择很关键的任务。
如果问题本身可以被形式化成确定搜索，比如代码测试、规划、游戏状态，那 ToT 的思想很自然。如果只是普通问答，强行上树搜索可能就有点重。
我会避免的误解
ToT 不是“模型在脑子里真的长了一棵树”。树是外部系统组织出来的。模型负责生成候选、评价候选，搜索器负责保留和回退。
它也不一定比现代 reasoning model 更强。现在很多模型本身已经经过长推理和搜索式数据训练，简单任务上 ToT 可能只是更贵。但这篇论文仍然重要，因为它明确提出了一个控制框架：语言模型可以只负责局部判断，整体搜索交给系统。
小结
ToT 给我的启发是，推理系统可以拆成三层：生成候选、评估状态、搜索控制。
这条线后来在 LATS、LLMCompiler、各种 workflow search 里都能看到影子。区别只是搜索的对象从 thought 变成 action、tool call、workflow、甚至 agent 代码。CoT 是起点，ToT 则提醒我们：真正难的问题，往往需要可回退的探索结构。