4.2 CoT 与 ToT：为不同任务选推理结构

4.2 CoT 与 ToT：为不同任务选推理结构

本节摘要：同样是"让模型多想几步"，思维链（CoT）走一条线，思维树（ToT）分叉探索再回溯，两者成本差一个数量级。本节讲清两种结构的机理与适用边界，给出一个 ToT 搜索骨架，并用一次方案选型任务演示树状探索怎么避免"第一条路走到黑"。

上一节的分解解决"步骤清单"，本节解决"每一步内部怎么想"。模型的推理结构可以分成两族：**CoT（Chain of Thought，思维链）**要求模型把推理过程写成连续的中间步骤再给答案；**ToT（Tree of Thoughts，思维树）**则让模型在关键节点生成多个候选分支，逐支评估，坏的剪掉、好的深入。CoT 是"想好再说"，ToT 是"多想几条路，挑一条走"。

两种结构的机理对照

CoT 的价值在于中间步骤外化。让模型"一步步写"而不是直接给答案，等于强制它把工作记忆摊在纸面上——每写一步，下一步就能读到上一步的结论，长推理的准确率因此明显提升。代价是输出变长（计费变多），以及推理文本可能泄漏给终端用户（需要在展示层截掉）。

ToT 的价值在于避免局部最优。CoT 的隐患是首因锚定：开头选定的思路会一路走到底，哪怕中途信号已经显示不对。ToT 在关键分叉点强制生成多候选（比如三个），让模型按明确标准打分比较，淘汰差支、展开优支，必要时回头。这是把人类的"先出几个方案比一比"制度化给模型。

选型口诀：步骤知道怎么走，用 CoT；路线需要挑，用 ToT。把 ToT 用在执行类任务上是烧钱——执行不需要候选，需要照单干活。

ToT 搜索骨架

def tot_solve(problem: str, branches: int = 3, max_depth: int = 3) -> str:
    """极简思维树：广度优先生成候选，逐层评估剪枝，返回最优路径的展开。"""
    frontier = [generate_candidates(problem, n=branches)]      # 第一层候选

    for depth in range(max_depth):
        scored = []
        for cand in frontier:
            verdict = llm.judge(cand, criteria=[
                "可行性：现有工具与信息能否支撑",
                "成本：时间与调用次数是否可接受",
                "风险：失败后的可回退性"])
            scored.append((cand, verdict.score))
        scored.sort(key=lambda x: -x[1])
        kept = scored[:2]                       # 剪枝：只留前两名继续深入
        if depth == max_depth - 1:
            break
        frontier = [expand(c) for c, _ in kept] # 展开下一层子方案

    best = scored[0][0]
    return to_plan(best)                        # 最优分支转成 4.1 节的步骤计划
​

三处实现要点。评估标准要提前写死——可行性、成本、风险三条标准在生成候选前就定好，否则评估轮会变成"都挺好"的客套现场。剪枝要狠——每层只留前两名，候选数是指数生长的，不剪枝的 ToT 在第四层就是三次方的调用账单。展开收敛于计划——树搜索的终点不是一段感想，而是可执行的步骤结构，与 4.1 节的计划格式无缝衔接。

案例：一次部署方案选型的完整过程

背景：团队要给一个内部工具加智能体能力，目标"两周内上线，预算有限，运维只有半个人"。

CoT 走法与结果：模型顺着"用最流行的框架"一口气推下去——选框架、写代码、部署——逻辑自洽，但全程没考虑过"运维半个人"是否撑得住框架的复杂度，方案在评审会上被一次质疑击穿。

ToT 走法与结果：第一层生成三条候选：自建循环（第 2 章的代码）、引入编排框架、托管平台方案。按三条标准打分：自建循环可行性高、成本低、风险低（代码全在自己手里）得分最高；框架方案功能全但运维成本一栏直接出局；托管方案省人力但预算超限出局。深入自建分支细化成五步计划，评审一次通过。

解读：注意 ToT 在这里的价值不是"想得更深"，而是强迫比较——CoT 版本不是不会考虑托管方案，是根本没被要求把候选摆上台面。分叉的价值在"摆出来"这个动作本身。

变式：排障类任务是 ToT 的另一个主场：故障假设当候选（网络、配置、代码三类），按"最可能且最易验证"排序，验证一条剪一条——这正是运维老师傅"先易后难排查法"的模型化。

⚠️ 常见坑：推理文本直出给用户。CoT/ToT 的中间步骤是工程内部物料，包含犹豫、试错甚至错误倾向，直接展示会同时伤害体验与信任。展示层只呈现结论与依据，推理过程留在轨迹日志里。

本节要点回顾

• CoT 外化推理：中间步骤摊在纸面上，长链推理更稳；代价是输出变长与过程泄露风险。
• ToT 强迫比较：分叉、评估、剪枝、回溯四件套对抗首因锚定；成本高一个数量级，只用于"路线要挑"的任务。
• 评估标准前置：可行性、成本、风险三条标准先于生成写死，比较才不会空转。
• 终点是计划：树搜索收敛为可执行步骤结构，与任务分解（4.1）首尾相接。

分解与推理结构都定了，最后一环是执行：计划跑起来之后，怎么盯着它不跑偏、失败了怎么有章法地重排——下一节的 Plan-and-Execute 收本章的口。