Tree of Thoughts：规划搜索与复杂推理
Tree of Thoughts 的重点不是让模型输出更长的思考过程，而是把复杂任务拆成可生成、可评估、可回退、可停止的搜索问题。它把推理从单路径生成改造成受控搜索：系统先产生多个中间状态，再用评分器、搜索策略和停止条件决定哪些路径继续扩展。
Tree of Thoughts / Planning Search 解读
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| Tree of Thoughts: Deliberate Problem Solving with Large Language Models | https://arxiv.org/abs/2305.10601 | 理解 thought decomposition、self-evaluation、BFS/DFS 等核心机制 |
| Chain-of-Thought Prompting | https://arxiv.org/abs/2201.11903 | 对比线性推理和树状搜索 |
| Self-Consistency Improves Chain of Thought Reasoning | https://arxiv.org/abs/2203.11171 | 理解多路径采样、候选答案选择和一致性投票 |
| ReAct | https://arxiv.org/abs/2210.03629 | 将 reasoning trace、action、observation 连接到 agent workflow |
核心导读
Tree of Thoughts 的重点不是让模型输出更长的思考过程，而是把复杂任务拆成可生成、可评估、可回退、可停止的搜索问题。它把推理从单路径生成改造成受控搜索：系统先产生多个中间状态，再用评分器、搜索策略和停止条件决定哪些路径继续扩展。
这类机制的系统价值在于把候选方案、证据路径、风险门禁和人工选择点显式化。架构上需要决定 thought 的粒度、搜索预算、评估信号、回退策略和审计 trace；否则树状推理只会增加 token 消耗，而不能提升复杂任务的可靠性。
1. 核心问题：复杂任务不是一次生成就能解决
很多 LLM 应用最初采用的是单轮生成范式：
Task -> Prompt -> Model -> Answer
这种模式适合信息提取、短摘要、直接问答，但不适合需要比较多个方案、处理不确定证据、遵守复杂约束的任务。
金融零售中的高价值 AI 场景往往有三个共同特征：
| 特征 | 例子 | 单路径生成的问题 |
|---|---|---|
| 多假设 | AML alert 可能是 structuring、合法现金业务、账户盗用或 mule activity | 模型容易过早押注一个解释 |
| 多证据 | 信贷审核需要收入、DTI、抵押品、政策例外和 adverse action 风险 | 早期漏看证据会污染最终建议 |
| 多约束 | 支付争议同时受客户陈述、商户证据、卡组织规则和 SLA 约束 | 答案可能局部合理但整体违规 |
Chain-of-Thought 让模型把推理写成一条链：
Problem -> step 1 -> step 2 -> step 3 -> answer
这比直接回答更好，但它仍然是一条路径。早期选择错了，后续步骤通常会沿着错误方向自洽地展开。
Tree of Thoughts 关注的正是这个问题：如果复杂任务天然存在多个中间选择，系统就不应该把推理压成一条线，而应该显式管理候选路径。
2. 论文贡献：把推理过程建模为搜索
Tree of Thoughts 将 problem solving 表述为在 thought space 中搜索。一个 thought 不是完整答案，而是一个中间状态、局部方案、候选假设或下一步行动。
结构上，它从线性链变成树：
Problem
-> thought A
-> thought A1
-> thought A2
-> thought B
-> thought B1
-> thought B2
-> thought C
-> thought C1
-> thought C2
这带来四个变化：
| 维度 | Chain-of-Thought | Tree of Thoughts |
|---|---|---|
| 推理结构 | 单路径 | 多路径树 |
| 错误恢复 | 早期错误会持续传递 | 可以比较、剪枝、回退 |
| 中间评估 | 通常只看最终答案 | 可以评估每个 thought/state |
| 系统控制 | 主要靠 prompt | 可配置搜索预算、评分器、停止条件 |
ToT 的技术贡献不是发明一个新的模型，而是把 LLM 当成搜索系统中的生成器和评估器。模型可以提出候选 thought，也可以辅助评估 thought；搜索控制器决定保留、扩展或放弃哪些路径。
这对 agent 设计很重要。真实 agent 不只是“想一步、调一个工具、答一句话”，而是反复经历：
目标理解 -> 候选计划 -> 工具/检索 -> 状态更新 -> 评估 -> 调整 -> 执行或升级
ToT 给这个循环提供了一个清晰抽象。
3. 机制原理：四个组件组成可控搜索
ToT 可以拆成四个组件：thought generator、state evaluator、search controller、stop rule。
3.1 Thought Generator
Thought generator 负责产生下一批候选。
在 AML alert 调查中，用户问：
这个客户多笔现金存入接近报告阈值，应该优先调查哪些证据？
系统可以生成多个候选方向：
| Thought | 调查含义 |
|---|---|
| A | 先检查交易是否符合 structuring typology |
| B | 先检查客户职业、业务类型和现金收入是否匹配 |
| C | 先检查交易对手、分支机构、时间分布和历史 alert |
| D | 先检查是否存在账户盗用、mule activity 或异常登录信号 |
这里的 thought 不应该是随意联想。生产系统需要限定 thought 类型，例如 hypothesis、evidence path、policy check、action candidate、missing information。
3.2 State Evaluator
State evaluator 给候选 thought 或中间状态打分。
评分可以来自多个来源：
| 评分来源 | 适合评估什么 |
|---|---|
| 规则 | 是否触发硬性政策、权限、审批要求 |
| 检索证据 | thought 是否有足够证据支持 |
| 风险模型 | 客户影响、欺诈风险、合规风险 |
| LLM judge | 语义完整性、解释质量、候选方案合理性 |
| 人工 reviewer | 高风险场景的最终校准 |
金融场景不应只靠 LLM 自评。一个候选路径写得专业，不代表证据完整、政策正确或合规安全。
3.3 Search Controller
Search controller 决定如何扩展树。
| 搜索方式 | 适合场景 | 主要风险 |
|---|---|---|
| BFS | 需要广泛比较多个候选方案 | 成本和延迟高 |
| DFS | 需要快速深挖一条路径 | 容易陷入错误假设 |
| Beam Search | 每层只保留 Top-K 候选 | 依赖评分器质量 |
| Best-first | 优先扩展当前最高分节点 | 可能过早收敛 |
| Fixed candidate set | 场景稳定、路径已知 | 覆盖新型案例较弱 |
企业落地时，很多任务不需要完全开放的树搜索。更稳妥的做法是把业务流程定义成半结构化 thought space，让模型在受控候选集中生成和排序。
3.4 Stop Rule
Stop rule 决定何时停止搜索。
停止条件通常包括：
- 最大 thought 数。
- 最大工具调用数。
- 最大 token 或成本预算。
- 最大延迟。
- 证据覆盖达到阈值。
- 分数差距足够大。
- 检索证据不足。
- 触发高风险或权限门禁。
- 必须转人工。
Stop rule 是企业 AI 的关键，不是实现细节。没有停止条件，多路径推理很容易变成昂贵、不可审计、无法复现的黑箱循环。
4. 为什么有效：搜索带来纠错、覆盖和显式控制
ToT 有效的原因可以从三个层次理解。
第一，它降低了早期错误的放大效应。单路径 CoT 一旦选错解释，后面常会构造出看似连贯的理由。ToT 通过并行保留多个候选，让系统有机会发现“另一路更有证据”。
第二，它提高了覆盖率。复杂任务常常不是缺一个答案，而是缺一组必须检查的路径。AML 不能只看交易金额，信贷不能只看收入，支付争议不能只看客户陈述。ToT 让这些路径在系统里被显式枚举和评估。
第三，它把模型推理变成系统工程对象。传统 prompt 很难管理“模型为什么选择这个方案”。ToT 把中间状态、评分、剪枝、回退、停止条件变成可记录、可评测、可调参的组件。
这也是 ToT 和 self-consistency 的差异。Self-consistency 通常采样多个完整推理链，再选择最终答案；ToT 更强调中间状态的逐步生成、评估和搜索。
5. 局限和误用
ToT 不是免费提升质量的按钮。
| 风险 | 说明 | 控制方式 |
|---|---|---|
| 成本膨胀 | 多路径生成和评估会显著增加调用次数 | 按风险分层设置预算 |
| 评分器偏差 | 错误 evaluator 会剪掉正确路径 | 使用规则、证据、SME 和 LLM 混合评估 |
| 看似合理的错误路径 | 模型会生成专业但无证据的 thought | 要求证据引用和 missing evidence 标注 |
| 自动化偏差 | 用户看到“推荐路径”后不再独立判断 | 展示候选差异、限制和人工决策入口 |
| Trace 泄露 | raw chain 可能包含敏感推理、PII 或内部策略 | 存储结构化摘要而非完整原始思维链 |
| 过度搜索 | 低风险任务也使用复杂搜索 | 只在复杂、高价值或高风险任务启用 |
一个常见误用是把 ToT 当成“展示模型思维过程”。生产系统不应该把 raw chain-of-thought 当作用户界面或审计证据。更合理的是保存和展示结构化 reasoning artifacts：候选路径、证据覆盖、评分、被拒绝原因、人工 override。
另一个误用是把 thought 当成 action。候选想法只是探索状态，不等于系统已经有权执行。特别是关闭 AML alert、提交 SAR、冻结资金、拒绝贷款、承诺退款这类动作，必须经过 policy gate 和 human approval。
6. 架构和产品价值：从一个答案到候选方案治理
ToT 的产品价值不是“让用户看见模型想了很多”，而是支持 candidate plan review。
一个适合金融零售的界面可以展示：
| UI 区域 | 内容 |
|---|---|
| Candidate paths | 2-4 个调查、处理或决策辅助路径 |
| Evidence coverage | 每条路径已有证据和缺失证据 |
| Risk flags | 合规、客户影响、操作风险和权限要求 |
| Recommendation | 推荐下一步及其理由 |
| Human action | 选择路径、要求补证、覆盖建议、升级审批 |
架构上，可以把 ToT runtime 设计成：
Task Intake
-> Thought Generator
-> Evidence Retriever / Tool Gateway
-> State Builder
-> Thought Evaluator
-> Search Controller
-> Policy Gate
-> Human Review
-> Final Draft / Action Recommendation
-> Trace Store / Eval Store
关键架构决策包括：
| 决策 | 推荐方向 |
|---|---|
| thought 是否持久化 | 高风险场景存结构化摘要、证据、评分和选择理由 |
| evaluator 类型 | rules + retrieval evidence + LLM judge + human sampling |
| 搜索预算 | 按任务风险、价值、延迟要求动态分配 |
| 工具调用权限 | 所有工具通过 gateway 和 policy gate 控制 |
| trace 用途 | 分权限支持调试、评测、审计和事故复盘 |
这套设计把 ToT 从 prompt trick 变成可运营的 planning layer。
7. 金融零售系统案例
7.1 AML Alert Investigation
问题：
一个客户出现多笔接近报告阈值的现金存入，AI 应如何协助调查？
ToT 化后，系统先生成候选假设：
| Hypothesis | 需要检查的证据 |
|---|---|
| Structuring | 金额分布、时间间隔、分支机构、阈值接近程度 |
| Legitimate cash business | KYC 职业、行业、现金收入模式、历史交易 |
| Mule activity | 新账户、快速进出、对手方网络、设备或登录异常 |
| Account takeover | 登录变化、受益人变化、异常渠道、客户反馈 |
然后 evaluator 评估每条路径：
- typology match。
- KYC consistency。
- evidence completeness。
- false positive likelihood。
- missing evidence。
- escalation requirement。
输出不应是“关闭/提交 SAR”的自动决定，而是调查计划、证据摘要、缺口清单和 reviewer recommendation。
7.2 Credit Underwriting Assistant
信贷场景中的 thought 可以是政策路径：
| Candidate path | 作用 |
|---|---|
| Income stability path | 检查收入来源、波动、雇佣状态 |
| Debt-to-income path | 检查负债、月供、压力测试 |
| Collateral / LTV path | 检查抵押品估值和风险缓冲 |
| Policy exception path | 检查是否触发例外审批 |
| Adverse action path | 检查拒绝或不利行动说明是否合规 |
系统价值在于帮助 underwriter 系统性检查，而不是让模型批准贷款。每个路径都要保留引用证据、政策条款和人工处理状态。
7.3 Payment Dispute Assistant
支付争议通常同时包含客户叙述、商户证据、网络规则、欺诈信号和时限要求。
ToT 可以把路径拆成：
- customer claim path。
- merchant evidence path。
- network rule path。
- fraud signal path。
- SLA / regulatory deadline path。
如果客户陈述强但商户证据缺失，系统应建议补证或标记风险，而不是直接承诺退款。ToT 的意义是让系统少漏路径，同时让每条路径的证据状态可见。
8. Eval 设计：不能只看最终答案
ToT 系统的评测必须覆盖中间过程。
| Eval layer | 核心问题 |
|---|---|
| Thought relevance | 候选 thought 是否覆盖合理路径 |
| Evidence grounding | 每条路径是否引用正确证据 |
| Search quality | 是否保留关键候选并剪掉低价值路径 |
| Error recovery | 初始路径错误时是否能回退 |
| Policy compliance | 是否避免禁止动作和越权工具 |
| Cost / latency | 搜索预算是否满足业务 SLA |
| Human usefulness | reviewer 是否认为候选方案减少了工作量 |
可构造的 golden set：
| Case | Expected coverage |
|---|---|
| AML structuring alert | KYC、transaction pattern、counterparty、history、missing evidence |
| KYC policy conflict | region、customer type、document exception、active policy version |
| Payment dispute | customer claim、merchant evidence、network rule、SLA |
| Credit exception | policy rationale、risk factors、adverse action、approval requirement |
高风险 release gate 应包括：
- 禁止动作触发率为 0。
- 权限泄露为 0。
- 关键证据遗漏率低于阈值。
- human override 原因可分类。
- trace completeness 达到审计要求。
9. 学习验证
学完 ToT，不应只会复述“树状思维”。要能产出三个东西。
第一，能为一个业务任务定义 thought space。以 AML 为例，写清楚哪些 thought 是 hypothesis，哪些是 evidence path，哪些是 policy check，哪些会转成 action candidate。
第二，能设计 search controller。说明为什么使用 fixed candidates、beam search、best-first 或人工选择；说明搜索预算、停止条件和高风险升级条件。
第三，能设计评测矩阵。不要只测最终摘要是否好看，要测候选路径覆盖、证据引用、错误恢复、成本、延迟、禁止动作和人工有效性。
建议练习：
- 为 AML alert triage 画一张 thought space map。
- 为 payment dispute 写一份 candidate plan review UI spec。
- 为 credit underwriting assistant 写一份 search controller ADR。
- 为任一场景构造 10 条 golden cases，标注 expected thought coverage。
- 解释为什么 raw chain-of-thought 不应直接作为审计材料。
如果能完成这些练习，就说明你已经把 ToT 从论文概念转成了可落地的 agent planning 架构语言。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。