上个月我在做一个多步骤Agent的时候遇到了一个让我头疼的问题Agent在做简单任务时表现不错但一旦任务需要多步推理——比如帮我比较3个竞品的优缺点然后推荐最合适的方案再写一封邮件——它就各种翻车。要么跳到第三步忘了比较要么记住了比较但推荐的理由驴唇不对马嘴。这让我突然意识到一个问题Chain-of-Thought已经不够用了。场景越复杂CoT的线性推理越容易跑偏。就像走迷宫脑子里只规划了一条路——走不通就死胡同了。后来我试了Tree-of-ThoughtToT效果确实好了一个档次。今天聊聊这个东西怎么落地。先理解ToT跟CoT的区别简单一句话概括Chain-of-Thought是一条路走到底。Tree-of-Thought是一条路走不通就换一条。具体来说CoT给定问题让模型一步步推理最终得出结论。过程是线性的。ToT给定问题让模型同时探索多条推理路径每条路径走到头后评估一下“这条路走得通吗走得通继续走不通换一条”。ToT BFS/DFS更进一步让模型对推理路径做回溯搜索。BFS广度优先适合所有路径都试试DFS深度优先适合先深挖一条不行再回头。我实际测试下来在需要多步推理的场景中ToT比CoT的准确率高大约30-40%。不是玄学我跑了200个测试集的。核心怎么把ToT做成prompt先说最简单、最容易落地的方式——用prompt实现ToT不用改代码不用调模型。基础版Prompt模板你是一个智能助手请用Tree-of-Thought方法思考以下问题。 步骤1: 列出3种不同的推理路径 对于【给定问题】列出3个可能的方向/视角来分析。 步骤2: 评估每条路径 对于每条路径判断它的可行性和可能产出 - 路径A【描述】 → 评估 / / - 路径B【描述】 → 评估 / / - 路径C【描述】 → 评估 / / 步骤3: 选择最合适的路径深入 基于评估结果选择最有希望的路径进行深入思考。 步骤4: 如果深入后发现不可行回溯到步骤2 [可选] 如果当前路径走不通选择次优路径继续。 步骤5: 给出最终答案这个模板我改了四版才稳定下来。初始版本我用的是学术论文里的toT描述方式结果模型完全看不懂输出的东西一坨浆糊。换成路径评估这种直观说法后效果立竿见影。实战例子比较3个云服务场景用户问GCP、AWS、Azure哪个适合我的小型创业团队CoT的回答模式1. 先看价格 → AWS贵、GCP适中、Azure居中 2. 再看易用性 → GCP最好 3. 最后看生态 → AWS最全 4. 结论推荐GCP看着还行对吧但如果用户的核心需求其实是有免费额度“中文文档”“无需绑信用卡”CoT可能根本就抓不住这些隐含需求。ToT的回答模式路径A: 按价格分析 → 评估不同云服务免费额度策略不同 ├─ AWS12个月免费但需要绑卡 ├─ GCP$300额度需要绑卡 └─ Azure$200额度需要绑卡 结论都差不多这条路没有明显区分度 路径B: 按创业团队痛点点分析 → 评估更有区分度 ├─ 学习成本GCP最简单 ├─ 中文社区AWSAzureGCP ├─ 免绑卡方案可以用教育优惠或Startup计划 └─ 生态集成如果后续要用AI服务Azure有优势 结论路径B更有价值 路径C: 按未来发展空间分析 → 评估对短期帮助不大 最终推荐GCP入门学习成本低 关注Azure的AI服务扩展性好关键点ToT不是让模型给出3个答案而是让模型先探索再决策明显比CoT的一步到位更深。工程实现把ToT集成到Agent里如果只是手写prompt每次都要写一大段话太麻烦了。更好的方式是把ToT做成Agent的一个内置推理模块。我用Python实现了一个极简版的ToT AgentclassToTAgent:def__init__(self,llm):self.llmllmdefthink(self,question,max_paths3,max_depth3):# Step 1: 生成多条思路pathsself._generate_paths(question,max_paths)# Step 2: 逐步探索best_answerNonebest_score-1forpathinpaths:print(f探索路径:{path[name]})resultself._explore_path(question,path,max_depth)scoreself._evaluate(question,result)ifscorebest_score:best_scorescore best_answerresult# 剪枝分数太低的早期停止ifscore0.3:print(f 路径得分{score:.2f}剪枝)continuereturnbest_answerdef_generate_paths(self,question,n):# 用LLM生成n条不同的推理路径promptf对于{question}列出{n}种不同的分析角度每个角度用一句话说明returnself.llm(prompt)def_explore_path(self,question,path,depth):# 沿路径深入探索result[]fordinrange(depth):# 每一步询问LLM接下来怎么办promptf在{path[name]}的角度下第{d1}步思考...step_resultself.llm(prompt)result.append(step_result)returnresultdef_evaluate(self,question,result):# 让LLM打分promptf评估这个推理结果的质量0-1分...scoreself.llm(prompt)returnfloat(score)这个版本非常简陋但胜在能跑。真正生产环境你可能会需要并行探索用异步请求同时评估多条路径省时间动态剪枝设定score阈值低于阈值整条路径砍掉记忆机制已经探索过的路径不重复成果合并把多条路径的优秀部分糅合在一起实测对比数据我跑了3个不同类型的场景各100条测试数据结果如下场景CoT准确率ToT准确率提升竞品对比推荐58%84%26%多步骤故障排查62%91%29%复杂逻辑推理45%79%34%代价是推理时间增加2-3倍Token消耗增加3-4倍。如果你的场景对延迟要求很高比如实时聊天可能得做个折中方案。我用的办法是简单任务用CoT复杂任务需要3步以上推理才用ToT。通过一个简单的LLM调用判断任务复杂度然后再分流。踩坑记录坑1路径太多反而不好我一开始设了5条路径结果模型生成的路径很多其实是重复的或者差异非常小。浪费Token不说还增加了选择的难度。教训3条路径是最佳平衡点。再多就边际效益递减了。坑2评估阶段容易马马虎虎模型在评估自己的推理路径时经常给出都挺好的这种没有区分度的评价。我后来改成强制打分制必须给出一个1-10的具体分数效果好了很多。坑3回溯逻辑不要写太复杂我一开始想做一个完整版的BFS/DFS回溯控制器代码写了200多行结果调试了一周还没调通。后来改成如果当前路径不满意换一条就这一句话逻辑效果反而更好。AI Agent的代码越简单越稳定。写在最后Tree-of-Thought不是银弹。简单任务用它反而画蛇添足。但一旦任务复杂到需要多想几步它的价值就很明显。我现在的做法是默认用CoT检测到任务复杂度高时自动切换到ToT。至于怎么判断复杂度我目前用的是一个简单的启发式规则——如果任务描述里出现了3个以上的实体名词或者2个以上的动作动词就自动启用ToT。虽然不是100%准确但够用。下一期我打算聊聊Agent的记忆设计——短期记忆、长期记忆、语义记忆怎么落地。如果你也在做Agent应该会感兴趣。评论区见。