07｜高级推理策略：思维树、ReAct与自动化推理

场景引入：一次技术架构迁移的决策困局

你的团队面临一个关键决策：现有的单体应用需要迁移到微服务架构。CTO要求你在下周的技术评审会上给出方案。

问题是，这不是一个有标准答案的题目。你需要同时权衡多个维度——技术可行性、团队能力、迁移成本、业务连续性、未来扩展性。每个维度下又有多个选项，每个选项都有各自的利弊。

你尝试用第5章学的思维链让AI帮忙分析，但发现CoT在这个场景下有局限性：它是线性的，一条路走到底。而真实的复杂决策需要的是同时铺开多条路径，走几步后比较哪条更优，再决定继续深入哪条。

这就像下棋。新手只能看到眼前一步棋，高手会在脑中同时推演三四步、每步又有多种走法，形成一棵”决策树”，然后选择胜率最高的那条分支。

本章介绍三种超越线性CoT的高级推理策略：思维树（Tree of Thoughts）、ReAct框架和Prompt Chaining。它们分别对应三种不同的复杂问题类型。

思维树（Tree of Thoughts）：让AI同时探索多条路径

从CoT到ToT：线性到分支

回顾第5章的思维链：AI沿着一条路径一步步推理，每一步基于上一步的结论继续前进。这在目标明确、路径单一的问题上非常有效。

但在开放性决策问题上，线性推理有一个固有缺陷：它在第一步选择的方向可能就不是最优的。一旦走上了某条路，后面的所有推理都在为这个初始方向服务，即使这条路最终是死胡同。

思维树（Tree of Thoughts，ToT） 的策略是：不要急着选一条路走到底，而是在每个关键节点同时展开多条分支，各走几步后回来比较，再决定哪条值得继续深入（原始论文：Tree of Thoughts: Deliberate Problem Solving with Large Language Models, Yao et al., NeurIPS 2023）。

用一个更日常的比方：你在一座陌生城市找餐厅吃饭。CoT的方式是选一个方向一直走，遇到第一家看着还行的就进去了。ToT的方式是先在地图上圈出三个不同方向的候选区域，每个区域快速浏览一下餐厅的类型和评价，然后再决定去哪个区域细挑。

实现ToT的prompt设计

关键在于三个步骤：生成多个分支、独立推演、评估与选择。

<task>
我们的电商系统目前是单体Java应用，日均订单量50万，团队20人。
需要制定微服务化迁移方案。

请按照以下步骤进行分析：
</task>

<step1>
【分支生成】请提出3种不同的迁移策略方向，每种用2-3句话概述核心思路。
这3种方案应该在根本思路上有差异，而不是同一思路的微调。
</step1>

<step2>
【独立推演】对每种策略，独立推演实施的前3个关键步骤，并评估：
- 技术风险（高/中/低）
- 预计耗时
- 对业务的影响程度
- 团队需要掌握的新技能
</step2>

<step3>
【比较评估】把3种方案放在一起对比，基于我们的具体情况
（20人团队、日均50万单、Java技术栈），给出你的推荐排序及理由。
指出每种方案在什么前提条件下会成为最优选择。
</step3>

AI的回复（简化展示）：

## 第1步：三种迁移策略

方案A——渐进式绞杀（Strangler Fig Pattern）
从单体边缘功能开始，逐个剥离为独立服务，新旧系统并行运行，
逐步将流量切到新服务上。

方案B——领域驱动全面重构
先做领域建模，划定服务边界，然后集中力量在一个季度内完成
核心服务的拆分和重写。

方案C——事件驱动的混合架构
保留核心单体不动，在外围搭建事件总线，新功能以事件驱动微服务
的方式开发，老功能按优先级逐步接入事件流。

## 第2步：各方案推演

### 方案A推演
步骤1：选择用户认证模块作为首个迁移目标（独立性高、变更频率低）
  → 技术风险：低；耗时：3周；业务影响：极小
步骤2：搭建API网关，实现流量在新旧服务间的动态路由
  → 技术风险：中；耗时：2周；需要学习网关配置
步骤3：迁移订单查询服务（读多写少，适合验证新架构的性能）
  → 技术风险：中；耗时：4周；需要处理数据一致性
...

### 方案B推演
步骤1：全团队停下来做2周的领域建模工作坊
  → 技术风险：低；但业务影响：高（2周无功能交付）
步骤2：...
...

### 方案C推演
...

## 第3步：对比评估

| 维度 | 方案A 渐进绞杀 | 方案B 全面重构 | 方案C 混合架构 |
|------|--------------|--------------|--------------|
| 技术风险 | 低 | 高 | 中 |
| 总耗时 | 6-9个月 | 3-4个月 | 4-6个月 |
| 业务连续性 | 优秀 | 差（需冻结功能） | 良好 |
| 团队学习曲线 | 平缓 | 陡峭 | 中等 |

推荐排序：A > C > B

以20人团队和日均50万单的规模来看，方案A最稳妥——可以边迁移边交付
业务需求。方案B虽然快但风险太高，如果团队能扩充到40人且有3个月的
功能冻结期，方案B才可行。方案C适合团队中有事件驱动架构经验的情况。

ToT的核心价值

注意这个分析过程和普通CoT的区别：

CoT：直接给一个方案，逐步细化。你看到的是一条路。
ToT：先铺开多条路，各走一段后比较。你看到的是一片landscape。

ToT特别适合以下场景：

技术选型（多种框架/方案的权衡）
产品策略制定（多条路线的利弊分析）
故障排查（多种可能原因的并行排查）
创意方案设计（需要发散再收敛）

ReAct框架：推理与行动的交替循环

什么是ReAct

ReAct（Reasoning + Acting） 是一种让AI在推理和行动之间交替循环的框架。简单来说，就是让AI按照”想一想 → 做一做 → 看一看 → 再想一想”的循环来工作。

为什么需要这个？因为很多现实问题不是光”想”就能解决的。你需要查资料、调接口、看数据，然后根据获取到的新信息调整下一步的行动。

打个比方：一个侦探破案，不能关在屋子里纯推理。他需要”推理出嫌疑人可能在某地”（Reasoning），然后”去那个地方调查”（Acting），根据调查结果（Observation）调整推理方向。

ReAct的三个角色

角色	含义	类比
Thought（思考）	分析当前状态，规划下一步	侦探的推理
Action（行动）	执行某个操作获取新信息	侦探的调查
Observation（观察）	获取行动的结果	调查得到的线索

在prompt中模拟ReAct

即使AI当前没有直接连接外部工具，你也可以在prompt中模拟ReAct的思维模式，让AI的分析更加严谨。

<task>
一个用户反馈说我们的订单系统在高峰期出现了超时错误。
请你模拟一个资深SRE的排查过程，按照"思考→行动→观察"的循环来分析。

在每一轮中：
- 【思考】基于已知信息，推断最可能的原因，并规划下一步要检查什么
- 【行动】描述你会执行什么操作（查看什么日志、检查什么指标、执行什么命令）
- 【观察】假设你看到了合理的结果（你来模拟这些数据），并基于观察继续下一轮

至少进行3轮循环，直到定位到根因。
</task>

<context>
已知信息：
- 错误发生在每天14:00-15:00
- 错误类型：HTTP 504 Gateway Timeout
- 涉及的API：/api/v2/orders/create
- 系统架构：Nginx → Spring Boot → MySQL + Redis
</context>

AI的回复：

=== 第1轮 ===

【思考】504错误来自Nginx，说明后端服务在规定时间内没有返回响应。
固定在14:00-15:00出现，提示可能与流量高峰或定时任务有关。
最可能的瓶颈点是：应用层处理慢、数据库查询慢、或连接池耗尽。
我应该先看这个时段的请求量和响应时间分布。

【行动】查看Nginx的access log，统计14:00-15:00时段的QPS和
平均响应时间，并与正常时段（如10:00-11:00）对比。

【观察】
- 正常时段：QPS约800，平均响应时间120ms，P99为350ms
- 异常时段：QPS约2,200，平均响应时间升至1,800ms，P99为12,000ms
- 流量是正常时段的2.75倍，但响应时间慢了15倍，不成比例

=== 第2轮 ===

【思考】流量增长2.75倍但响应时间慢了15倍，说明不是简单的线性扩展
问题。如果只是CPU不够用，响应时间应该接近线性增长。这种非线性恶化
通常指向资源竞争——连接池满了导致请求排队等待，或者数据库锁争用。
应该检查应用层的线程池和数据库连接池状态。

【行动】查看Spring Boot的Actuator端点，获取异常时段的线程池使用
情况和数据库连接池（HikariCP）的指标。

【观察】
- Tomcat线程池：最大200线程，异常时段活跃线程稳定在200（已满）
- 等待队列中积压请求数：峰值达到340
- HikariCP连接池：最大连接数50，活跃连接50（已满），
  等待获取连接的平均时间：3,200ms

=== 第3轮 ===

【思考】线程池和数据库连接池同时打满。线程在等待数据库连接释放，
数据库连接迟迟不释放说明有慢查询。重点排查14:00-15:00是否有
特别慢的SQL。另外需要确认这个时段是否有定时任务在抢占数据库连接。

【行动】检查MySQL的slow query log，筛选14:00-15:00时段执行
时间超过1秒的查询。同时检查是否有cron job在该时段运行。

【观察】
- 发现大量慢查询来自 SELECT ... FROM orders WHERE status='pending'
  ORDER BY created_at，平均执行时间4.5秒，该查询无索引
- 发现14:00有一个定时任务在执行"待支付订单超时取消"，会全表扫描
  pending状态的订单
- 定时任务与正常业务共用同一个数据库连接池

=== 根因定位 ===

根本原因：14:00触发的定时任务执行了全表扫描的慢查询，
占用了大量数据库连接和MySQL资源。与此同时正常业务流量也在高峰期，
两者叠加导致连接池耗尽、请求排队、最终触发Nginx的504超时。

修复建议：
1. 为orders表的status + created_at添加复合索引（即时修复）
2. 将定时任务迁移到只读从库执行（短期方案）
3. 为定时任务配置独立的数据库连接池（长期方案）

这种”思考→行动→观察”的循环，让AI的分析过程像一个真正的工程师在排查问题，而不是凭空给一个结论。

ReAct在AI Agent中的应用

在更高级的应用中，ReAct不只是一种prompt技巧，而是AI Agent（智能体）与外部工具交互的核心框架。AI在”Action”步骤中可以真正执行操作——搜索网页、查询数据库、调用API——然后将结果反馈到下一轮推理中。

值得特别说明的是：当前主流 AI 产品已经原生实现了 ReAct 模式的工具调用。 ChatGPT 的 Plugins/Actions、Claude 的 Tool Use、以及各类 AI 编程助手，都内置了”推理→调用工具→获取结果→继续推理”的循环。你在上面学到的”手动模拟 ReAct”技巧，适用于模型没有工具调用能力的场景，或者你想在 prompt 中训练 AI 的结构化排查思维。但在实际的 Agent 开发中，你更多会使用平台提供的原生工具调用 API，而非手动在 prompt 中模拟。

如果你对 ReAct 的学术背景感兴趣，可以参阅原始论文：ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., ICLR 2023)。

Prompt Chaining：任务拆解与串联

为什么要拆分prompt

前面两种策略——ToT和ReAct——都是在一个prompt内部实现复杂推理。但有些任务实在太复杂，一个prompt根本装不下，或者不同步骤需要完全不同的处理逻辑。

这时候就需要Prompt Chaining（提示词串联）：把一个大任务拆分成多个子任务，每个子任务用一个独立的prompt处理，上一步的输出作为下一步的输入。

这就像工厂流水线。一辆汽车不可能在一个工位上从零件变成成品，而是要经过冲压、焊接、涂装、总装等多个环节，每个环节专注做好自己的事。

实战：从需求文档到技术方案

假设你要把一份产品需求文档转化为技术实施方案。这个任务至少涉及：理解需求、分析技术可行性、设计方案、评估风险。用一个prompt搞定很困难，拆成链路就清晰多了。

第1环：需求提取

<task>
请阅读以下产品需求文档，提取出所有功能需求，并用结构化格式输出。
每个功能需求包含：功能名称、功能描述、优先级、涉及的数据实体、
与其他功能的依赖关系。
</task>

<document>
（粘贴产品需求文档）
</document>

<output_format>
请输出JSON格式，方便后续处理。
</output_format>

第2环：技术可行性分析

<task>
你是一位后端架构师。基于以下结构化需求列表，对每个功能进行
技术可行性评估。
</task>

<input>
（将第1环的输出粘贴在此）
</input>

<requirements>
对每个功能评估：
1. 技术实现难度（1-5分）
2. 推荐的技术方案（1-2句话概述）
3. 预估开发工时（人天）
4. 潜在的技术风险
5. 与现有系统的集成点
</requirements>

第3环：方案设计

<task>
基于以下功能列表和技术评估结果，设计一个完整的技术实施方案。
</task>

<input>
（将第1环和第2环的输出粘贴在此）
</input>

<requirements>
方案应包含：
1. 系统架构图描述（用文字描述，标注服务间的调用关系）
2. 数据库设计（核心表结构）
3. 接口设计（核心API列表）
4. 实施排期（按迭代划分，考虑依赖关系）
5. 团队分工建议
</requirements>

第4环：风险评估与应对

<task>
请对以下技术方案进行风险评估。你的角色是一个专门"挑刺"的
风险评审员——你的职责是找出方案中的薄弱环节。
</task>

<input>
（将第3环的输出粘贴在此）
</input>

<requirements>
对每个识别出的风险：
1. 风险描述
2. 发生概率（高/中/低）
3. 影响程度（高/中/低）
4. 应对措施
5. 备选方案（plan B）
</requirements>

Chaining的设计原则

原则	说明
单一职责	每个环节只做一件事
清晰的输入输出	每个环节的输入和输出格式明确定义
可独立测试	每个环节可以单独运行和验证
容错处理	如果某一环结果不佳，可以只重跑该环节

在手动操作中，你需要自己将每一步的输出复制到下一步的输入中。如果你想把这个过程自动化，可以使用编排框架（如 LangGraph、CrewAI、LlamaIndex Workflows 等），它们提供了开箱即用的链式调用能力，能自动完成”上一步输出→下一步输入”的串联。

什么时候用Chaining而不是一个大prompt

用Chaining	用单个prompt
任务步骤超过3步	任务步骤少于3步
不同步骤需要不同”角色”	整个任务的角色一致
中间结果需要人工审核	全自动执行即可
总文本量超过模型上下文窗口	所有信息放得下
需要在中间步骤调用不同工具	纯文本处理

自动推理与工具使用（ART）

ART（Automatic Reasoning and Tool-use） 是比ReAct更进一步的概念（参见 Paranjape et al., 2023）。在ReAct中，需要你在prompt里明确设计”何时思考、何时行动”的流程。而ART的目标是：给AI一个工具箱和一个任务，让它自主决定什么时候用什么工具、怎么组合推理和行动。

目前主流的AI产品已经在不同程度上实现了ART：

AI编码助手可以自主决定何时搜索代码库、何时运行测试
AI搜索工具可以自主决定搜索什么关键词、是否需要二次搜索
AI数据分析工具可以自主决定执行什么查询、怎么可视化

作为prompt工程师，你不需要自己实现ART的底层机制，但理解这个概念有助于你更好地与AI工具协作——当你给AI更多的自主权（比如”你可以搜索网页来验证你的分析”），AI往往能给出更可靠的结果。

各策略适用场景对比

策略	核心思想	最适合的问题类型	复杂度	示例场景
CoT（第5章）	线性分步推理	有明确路径的推理题	低	数学计算、逻辑推导
ToT	多分支并行探索	开放性决策问题	中	技术选型、方案评估
ReAct	推理-行动-观察循环	需要动态获取信息的问题	中	故障排查、信息核实
Chaining	大任务拆成子任务串联	多步骤复杂流程	高	文档分析、方案生成
ART	AI自主选择工具和推理方式	需要灵活组合多种能力的问题	最高	全自动研究、复杂Agent任务

选择策略的简单决策流程：

问题有标准答案吗？ 有 → CoT就够了
需要比较多个方案？ 是 → 用ToT
需要查资料或验证信息？ 是 → 用ReAct
步骤超过3步且需要不同能力？ 是 → 用Chaining
以上都需要且需要灵活组合？ 是 → 考虑ART/Agent方案

本章回顾

概念	说明	关键prompt设计要素
思维树（ToT）	多条推理路径并行探索后比较	”提出N种方案，分别推演，对比选优”
ReAct	思考-行动-观察的交替循环	”描述你会检查什么，模拟观察结果，再推理”
Prompt Chaining	大任务拆成多个子prompt串联	上一步输出→下一步输入，每步单一职责
ART	AI自主决定推理方式和工具使用	提供工具选项，赋予AI选择权

核心原则： 当线性思维链无法胜任时，根据问题的特征选择合适的高级策略——需要发散用ToT、需要探索用ReAct、需要分工用Chaining。复杂问题没有银弹，但有合适的工具组合。

思考题

回忆你最近做过的一个需要多方案比较的决策（技术选型、工具选择等）。如果用思维树的方式让AI辅助分析，你会怎么设计prompt？试着写一个并执行。
选择一个你熟悉领域的排查类问题（如线上故障排查、数据异常分析），用ReAct模式设计一个prompt，让AI模拟完整的排查过程。观察AI模拟的排查路径是否合理。
思考以下任务适合用哪种策略，并说明理由：
- 为一个开源项目选择CI/CD工具
- 分析一份100页的审计报告并提取关键风险
- 帮用户诊断为什么他们的代码运行结果不符合预期