1. 项目概述：从“链式思考”到“思维之树”的跃迁
如果你最近在折腾大语言模型，尤其是想让它们解决一些需要多步骤推理的复杂问题，那你肯定对“链式思考”不陌生。简单来说，就是让模型在给出最终答案前，先一步步写下自己的推理过程。这招确实管用，让模型的逻辑能力提升了不少。但不知道你有没有遇到过这种情况：面对一个开放性问题，模型沿着一条思路走到黑，结果却是个死胡同，或者给出的答案虽然合理，但远非最优。这感觉就像让一个顶尖棋手只准想一条进攻路线，不许考虑其他走法，显然限制了他的真实水平。
今天要聊的kyegomez/tree-of-thoughts项目，就是为了解决这个痛点。它不是一个新模型，而是一个算法框架，你可以把它理解为一个“思维管理大师”。它的核心思想是，不让AI只走一条“思维链”，而是同时探索多条可能的推理路径，形成一个“思维树”。在探索过程中，它会评估每条路径的潜力，放弃差的，深入挖掘好的，最终找到最优解。根据论文数据，这种方法能将大语言模型的复杂推理能力提升高达70%。这个开源实现最吸引人的地方在于它的“即插即用”特性——你不需要改动底层模型，只需要接入你自己的模型（比如 OpenAI 的 API 或者本地部署的模型），就能让模型瞬间获得这种“多线程思考”的超能力。
无论你是正在构建需要复杂决策的AI智能体，还是想优化你的提示工程流程，亦或是单纯对前沿的AI推理技术感到好奇，这个项目都值得你花时间深入了解。接下来，我会带你拆解它的设计思路、手把手教你如何上手，并分享一些实战中积累的配置心得和避坑指南。
2. 核心设计思路：为什么“树”比“链”更强大？
要理解 Tree of Thoughts 的精髓，我们得先看看它要替代的“前辈”们有什么局限。传统的提示方法，比如直接提问或链式思考，本质上是一种“贪婪的”单一路径搜索。模型接到问题后，基于当前上下文生成下一个词或下一句话，一路向前，没有回头路。这种方式对于有明确步骤、答案唯一的问题（比如数学计算）效果不错，但对于需要规划、创意或策略的问题（比如写一个商业计划、设计一个游戏关卡、解决一个逻辑谜题），就显得力不从心了。因为最优解往往藏在模型第一次没想到的分支里。
2.1 ToT 框架的四步拆解
Tree of Thoughts 框架将问题解决过程形式化为在树结构上的搜索。这棵树上的每个节点都是一个“思维”状态，代表了对问题的一种部分解决方案或思考方向。整个框架可以分解为四个可自定义的模块：
1. 思维分解器：将问题拆分成可管理的思考步骤这是构建思维树的基础。对于“用数字 3, 4, 7, 8 通过加减乘除得到 24”这样的游戏，一个自然的分解可能是：先考虑哪两个数字组合，再考虑用什么运算符，最后如何与剩下的数字结合。而对于“写一篇关于可再生能源的博客大纲”这样的任务，分解可能是：确定核心论点、寻找支持论据、组织文章结构、润色开头结尾。关键在于，分解的粒度要合适。太粗（如“解决这个问题”）会让模型无从下手；太细（如“写下第一个数字”）则会生成过于庞大和琐碎的树，拖慢搜索速度。在实践中，我通常让模型自己提出几种可能的“下一步”思考方向，这本身也是探索的一部分。
2. 思维生成器：为当前思维节点提出后续可能给定一个当前状态（例如“已尝试 3*8=24，还剩 4 和 7”），思维生成器的工作是提出几个合理的后续思考。在 ToT 实现中，这通常通过提示语言模型来完成，例如：“基于当前情况，请给出 3 种不同的后续计算策略。” 这里数量的选择是个权衡。生成太多选项（比如10个）会急剧增加计算成本；生成太少（比如1个）又失去了“树”的意义，退化成“链”。根据我的经验，对于大多数任务，生成 3 到 5 个候选思维是一个比较实用的范围。
3. 状态评估器：给当前思维路径打分这是 ToT 的“智能”所在。我们需要一个函数来判断当前思维状态的好坏，以及它是否有潜力导向最终答案。评估可以是标量分数（比如 0 到 1），也可以是分类（比如“肯定可行”、“可能可行”、“不可行”）。在项目中，threshold和prune_threshold参数就是基于这个评估来工作的。评估可以基于：
- 程序化规则：对于 24 点游戏，可以检查当前表达式是否有效、是否使用了所有数字。
- 语言模型自我评估：直接问模型“这个方案成功的可能性有多大？”。这种方法非常灵活，但成本较高且可能不稳定。
- 价值模型：训练一个单独的、更小的模型来专门进行评估，这在需要大量搜索的场景下更经济。
4. 搜索算法：决定如何遍历这棵思维树有了树的结构和评估方法，还需要一个策略来决定下一步探索哪里。项目目前主要实现了深度优先搜索，并计划加入广度优先和蒙特卡洛树搜索。
- 深度优先搜索：沿着一条路径深入到底，直到找到解或达到深度限制，然后回溯。
ToTDFSAgent就采用了这种策略，配合剪枝（prune_threshold）。它适合解空间很深，但可行解可能藏在某条路径尽头的问题。 - 广度优先搜索（待实现）：先探索当前层的所有可能，再进入下一层。适合需要全面评估短期选择的问题。
- 蒙特卡洛树搜索（待实现）：通过随机模拟来平衡“探索”（尝试新分支）和“利用”（深入看好分支），在围棋等游戏中取得了巨大成功，也非常适合复杂的规划任务。
提示：选择哪种搜索算法，很大程度上取决于你的问题特性。DFS 更节省内存，适合寻找“唯一解”；BFS 能避免“错过近在眼前的解”；而 MCTS 在解空间巨大、需要智能探索时优势明显。目前项目以 DFS 为主，你可以根据
max_loops参数控制其搜索深度。
2.2 与 Chain-of-Thought 和 Self-Consistency 的对比
为了更直观地理解 ToT 的优势，我们把它放在当前主流推理增强技术的坐标系中来看：
| 方法 | 核心思想 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 标准提示 | 输入问题，直接输出答案。 | 简单、快速。 | 缺乏透明度，复杂任务容易出错。 | 简单的事实问答、分类。 |
| Chain-of-Thought | 强制模型逐步展示推理过程。 | 提升逻辑性，可解释性强。 | 单一路径，可能陷入局部最优或错误方向。 | 有明确步骤的数学、逻辑问题。 |
| Self-Consistency | 生成多条 CoT 路径，通过投票选择最一致的答案。 | 通过集成减少随机误差，提高准确性。 | 仍然是多条独立的“链”，路径间无交互和中期评估。 | 答案明确、可通过一致性判断的封闭性问题。 |
| Tree of Thoughts | 构建动态推理树，在搜索过程中进行中期评估和规划。 | 具备前瞻性和回溯能力，能发现非直觉的解决方案，解决更开放、复杂的任务。 | 计算和 API 调用成本显著增加，实现更复杂。 | 需要规划、策略、创意生成的开放性问题（如游戏、写作、设计）。 |
简单来说，CoT 是让模型“把思考过程说出来”，Self-Consistency 是“找一群人各自思考然后投票”，而 ToT 是“组织一个团队进行头脑风暴，过程中不断讨论、评估、调整方向”。显然，对于最复杂的那类问题，ToT 提供了更强大的框架。
3. 环境配置与核心 API 详解
理论说得再多，不如动手跑一遍。我们来看看如何把这个强大的框架用起来。项目通过 PyPI 分发，安装非常简单，但环境配置有几个关键点需要注意。
3.1 安装与基础环境搭建
首先，通过 pip 安装最新版：
pip3 install -U tree-of-thoughts安装完成后，最关键的一步是配置环境变量。项目要求你在项目根目录下创建一个.env文件，内容如下：
WORKSPACE_DIR="artifacts" OPENAI_API_KEY="sk-你的真实OpenAI API密钥"WORKSPACE_DIR：这个目录用于存储思维树搜索过程中生成的中间文件，比如思维状态、评估结果等。方便你事后复盘或调试。你可以把它改成任何你喜欢的路径，比如./tot_logs。OPENAI_API_KEY：这是驱动思维生成和评估的引擎燃料。确保你的密钥有足够的余额和权限。
重要提示：
.env文件包含敏感信息，务必将它添加到你的.gitignore文件中，避免将 API 密钥意外提交到公开仓库。我习惯在项目中创建一个.env.example文件，里面只写键名不写真实值（如OPENAI_API_KEY=），作为给其他协作者的模板。
3.2 核心类与方法解析
项目提供了两个主要的代理类：TotAgent和ToTDFSAgent。我们来拆解它们各自的职责和参数。
TotAgent：思维生成与评估的执行者这个类是真正与语言模型交互的“工人”。初始化时，最重要的参数是use_openai_caller。
from tree_of_thoughts import TotAgent from dotenv import load_dotenv load_dotenv() # 加载 .env 文件 # 使用默认的 OpenAI 调用器（推荐） agent = TotAgent(use_openai_caller=True) # 如果你想使用自定义的模型调用器（例如本地部署的 Llama 或 Claude API） # agent = TotAgent(use_openai_caller=False, custom_caller=my_custom_function)当use_openai_caller=True时，它会使用项目内置的封装来调用 OpenAI 的 API（默认是gpt-3.5-turbo，你可以在源码中查找并修改模型配置）。如果你有自己的模型 API 封装，可以将其设为False并传入一个custom_caller。这个caller函数需要接收提示文本并返回模型的响应字符串。
ToTDFSAgent：深度优先搜索的调度器这个类负责管理整个思维树的搜索流程。它本身不生成思维，而是指挥TotAgent去工作。
from tree_of_thoughts import ToTDFSAgent dfs_agent = ToTDFSAgent( agent=agent, # 传入上面创建的 TotAgent 实例 threshold=0.8, # 解决方案的接受阈值 max_loops=3, # 最大搜索深度（循环次数） prune_threshold=0.5, # 剪枝阈值 number_of_agents=4, # 并行工作的“专家”数量 )agent：干活的工人，必须是TotAgent实例。threshold：当某个思维状态的评估分数达到此阈值时，搜索立即成功终止，并返回该状态作为最终答案。设为 1.0 表示要求“完美解”，0.8 则表示“足够好的解”就可以接受。max_loops：限制搜索的最大深度，防止在无限或过大的空间中陷入过久。每个“loop”可以理解为思维树向下生长一层。prune_threshold：这是 DFS 高效的关键。在搜索过程中，会对每个新生成的思维节点进行评估。如果评分低于此阈值，则该节点及其所有潜在子节点都会被“剪掉”，不再继续探索。这能大幅节省计算资源。number_of_agents：这是一个非常巧妙的设计。它并不是启动多个进程或线程，而是在单个提示中，模拟多个专家共同工作。例如，将其设为 4，那么生成后续思维的提示就会变成“请想象 4 位专家，各自提出一种可能的下一步...”。这利用了语言模型内部的多角色模拟能力，在一次 API 调用中批量生成多个候选思维，既提高了多样性，又控制了成本。
3.3 第一个实战示例：24点游戏
让我们用项目自带的例子来感受一下。这个例子完美展示了 ToT 如何解决一个经典的组合搜索问题。
# 定义初始问题 initial_state = """ 你的任务：使用数字 4, 5, 6, 7 和基本算术运算 (+ - * /) 得到一个结果为 24 的表达式。只需返回最终的数学表达式。 """ # 运行 DFS 搜索 final_thought = dfs_agent.run(initial_state) print(final_thought)当你运行这段代码时，背后发生了什么呢？
- 启动：
dfs_agent.run()被调用，将initial_state作为树的根节点。 - 生成候选：
TotAgent收到指令，模拟 4 位专家（number_of_agents=4），每位提出一个可能的“第一步”。例如，专家A可能建议(4+5)，专家B建议(7-6)，专家C建议(6*4)，专家D建议(7/?)。 - 评估与剪枝：对这四个候选进行初步评估。假设
(7/?)因为不完整且难以导向24，得分只有0.3，低于prune_threshold=0.5，它就被剪掉了。 - 深度搜索：对剩下的三个候选（
(4+5),(7-6),(6*4)），分别将它们作为新的当前状态，重复步骤2和3，继续生成和评估后续步骤（例如，(4+5)=9，然后9如何与6, 7组合得到24？）。 - 终止：当某条路径生成表达式
(6*4)*(7-5) = 24时，评估器给出高分（比如0.95），超过了threshold=0.8，搜索成功结束，返回该表达式。
你会发现，这个过程比人脑暴力枚举要智能得多，因为它有中期评估引导方向。你可以尝试更换一组数字，或者调整threshold和prune_threshold，观察搜索行为和结果的变化。
4. 高级应用与自定义提示工程
掌握了基础用法后，我们可以挑战更复杂的任务，并深入定制提示词，这是发挥 ToT 威力的关键。
4.1 解决复杂问题：创意写作与逻辑规划
ToT 的真正优势在于开放性问题。假设我们的任务是：“为一个面向青少年的环保科技产品，想一句朗朗上口的宣传标语。” 如果直接用 GPT，它可能会给出一句不错的标语。但用 ToT，我们可以系统化地探索创意空间。
initial_state = """ 任务：为一款新型可降解手机壳（主要材料为玉米淀粉）构思一句宣传标语。要求：面向青少年，突出环保、酷、科技感，不超过15个字。 请逐步思考，先生成几个不同的核心创意方向。 """ # 我们可以调整代理参数，更适合创意任务 creative_agent = ToTDFSAgent( agent=tot_agent, threshold=0.85, # 创意任务，标准可以稍高 max_loops=2, # 创意发散不需要太深，2层可能就够了 prune_threshold=0.4, # 创意评估主观性强，剪枝阈值放低，避免误杀 number_of_agents=5, # 生成更多创意方向 )在这个任务中，思维树的第一层可能是不同的“情感切入点”：1) 拯救地球的英雄感，2) 引领潮流的时尚感，3) 黑科技的神秘感，4) 简单直白的行动号召。第二层则是在每个切入点下构思具体的文案。评估器需要判断哪个方向更贴合“青少年”、“酷”、“科技感”这些关键词。最终，我们可能得到像“给地球的礼物，也是给你的酷”、“下一站，可降解未来”这样经过多轮比较和筛选的成果。
4.2 深度定制提示模板
项目示例中提供了多个精彩的“多专家协作”提示模板。这些模板是 ToT 的灵魂，它们定义了思维生成的质量和风格。理解并修改它们至关重要。
以其中一个模板为例，我们拆解其结构：
想象三位专家正在回答这个问题。所有专家都会写下他们思考的1个步骤，然后与小组成员分享。然后所有专家继续进行下一步，依此类推。如果任何专家在任何时候意识到自己错了，他们就会离开。问题是...- 角色设定：“三位专家”创造了多元视角。你可以根据任务调整为“资深营销人、环保科学家、青少年代表”。
- 流程控制：“写下1个步骤...然后分享”强制了逐步、结构化的思考，避免了信息倾泻。
- 自我修正机制：“意识到自己错了就离开”让模型能够动态修剪无效路径，这是实现“剪枝”在提示层面的体现。
- 协作模式：“分享”、“基于他人的解释”促进了思维的交叉融合，能产生更优的集体智慧。
如何自定义？假设我们要优化代码，可以设计更专业的提示：
你是一位资深算法工程师、一位系统架构师和一位测试专家。你们需要共同评审下面这段 [Python/数据库] 代码，找出潜在的性能瓶颈、可读性问题和边界情况。 评审规则： 1. 每位专家每次只提出一个最关键的发现。 2. 架构师先发言，指出模块设计问题；工程师接着分析具体实现；测试专家最后补充边界用例。 3. 如果同意前一位的观点，可以深化它；如果反对，请给出理由。 4. 循环进行，直到没有新的重大问题提出。 代码是：[你的代码片段]将这样的提示作为initial_state，ToT 框架就能组织起一次结构化的代码评审会议。number_of_agents参数就对应这里的专家数量（3位）。
4.3 评估函数的选择与设计
评估函数是搜索的导航系统。除了使用语言模型自我评估，对于有明确规则的任务，自定义评估函数能极大提升效率和准确性。
以“24点游戏”为例，我们可以写一个简单的程序化评估器：
def evaluate_24(state, numbers=[4,5,6,7]): """ 评估当前状态字符串，看它是否构成一个有效的、使用了所有数字且结果为24的表达式。 返回一个分数 (0.0 到 1.0)。 """ try: # 1. 提取状态中的数学表达式（这里需要根据实际状态字符串格式进行解析，这是一个简化示例） # 假设状态字符串最后一行是候选表达式，如 "尝试: (6*4)*(7-5)" import re # 这是一个非常简单的匹配，实际中需要更健壮的解析 match = re.search(r'\([\d\+\-\*\/\s]+\)', state) if not match: return 0.2 # 连表达式都没有，分数很低 expr = match.group(0) # 2. 安全计算表达式结果 # 警告：直接使用 eval 有安全风险，仅用于示例。生产环境应使用安全计算库如 `ast.literal_eval` 或自定义解析器。 result = eval(expr) # 3. 检查是否使用了所有数字 used_numbers = [int(n) for n in re.findall(r'\b[4567]\b', expr)] # 查找独立的数字 if sorted(used_numbers) != sorted(numbers): return 0.5 # 数字没用全，给中等分数，可能还在构造中 # 4. 检查结果是否为24 if abs(result - 24) < 0.001: # 考虑浮点误差 return 1.0 # 完美解！ else: # 可以根据离24的“距离”给出梯度分数，例如： distance = abs(result - 24) if distance > 10: return 0.3 elif distance > 5: return 0.5 else: return 0.7 # 接近解，分数较高 except Exception as e: # 表达式无效 return 0.1 # 然后，你需要将这个评估函数集成到代理中。 # 遗憾的是，当前开源版本的 ToT 主要依赖提示词进行LM评估，程序化评估需要修改其内部 `_evaluate_state` 方法。 # 这通常是项目进阶使用的方向：将LM的灵活性和程序的精确性结合起来。在实际项目中，评估函数往往是混合的：先用快速、低成本的规则过滤掉明显无效的状态，再用语言模型对剩下的候选进行精细评估。这需要在效果和成本之间取得平衡。
5. 实战配置心得与常见问题排查
经过一段时间的实际项目应用，我积累了一些参数调优和问题解决的经验，这些在官方文档里通常不会细说。
5.1 参数调优指南：平衡速度、成本与效果
ToT 的强大伴随着更高的 API 调用成本。以下是一份根据任务类型调整参数的实用指南：
| 参数 | 调高 (↑) | 调低 (↓) | 典型值参考 |
|---|---|---|---|
number_of_agents | 需要更多样化的创意探索；问题分支多。 | 控制成本；问题解空间相对线性。 | 创意生成：4-5，逻辑解谜：3-4，代码/规划：2-3。 |
max_loops | 问题解决步骤多，需要深度规划（如写长文大纲、多步推理）。 | 问题简单或只需浅层发散（如想标语、简单分类）。 | 标语生成：2，24点游戏：3-4，商业计划：5+。 |
threshold | 对答案质量要求极高，必须找到最优解。 | 接受“足够好”的近似解，优先保证搜索能结束。 | 数学问题：0.95-1.0，创意写作：0.8-0.9，头脑风暴：0.7。 |
prune_threshold | 希望快速收敛，对次优路径容忍度低。 | 避免过早剪掉有潜力的“黑马”路径；评估函数不确定度高。 | 规则明确（如游戏）：0.6-0.7，主观评估（如文案）：0.3-0.5。 |
一个黄金法则：从紧开始，逐步放松。初次尝试一个新任务时，可以先设置较严格的prune_threshold(如0.6) 和适中的max_loops(如3)，快速看下搜索能否找到可行路径。如果发现总是过早剪枝导致失败，再逐步调低prune_threshold。同时，密切监控 API 调用次数和总耗时。
5.2 常见错误与解决方案
在集成和使用 ToT 时，你可能会遇到下面这些问题：
1. 错误：ModuleNotFoundError: No module named 'tree_of_thoughts'
- 原因：最常见的原因是虚拟环境未激活或包未正确安装。
- 解决：
# 确认在正确的 Python 环境中 python --version pip --version # 重新安装，并确保使用 pip3 如果你的系统默认是 python2 pip3 install -U tree-of-thoughts --force-reinstall
2. 错误：OpenAI API调用失败，提示认证错误或额度不足
- 原因：
.env文件配置错误、API_KEY 无效或过期、或者代码没有正确加载环境变量。 - 解决：
- 检查
.env文件是否在项目根目录，且文件名前面有点号。 - 使用
print(os.getenv(‘OPENAI_API_KEY’))在代码中测试是否能读取到密钥（测试后记得删除这行）。 - 登录 OpenAI 平台，检查 API 密钥是否有效，以及用量和余额。
- 确保代码中在初始化代理前调用了
load_dotenv()。
- 检查
3. 问题：搜索过程非常慢，或者很快结束但没找到解
- 原因：API 调用有延迟；
prune_threshold设得过高，路径被过早剪光；max_loops太小，搜索深度不够。 - 解决：
- 监控：在代码中添加简单的日志，打印每个循环的状态和评估分数，观察搜索过程。
- 调整剪枝：将
prune_threshold从 0.8 逐步降至 0.4，观察是否能有更多路径被探索。 - 增加深度：适当增加
max_loops。 - 简化任务：检查你的
initial_state提示是否过于复杂模糊？尝试用更清晰、步骤更明确的语言重新描述问题。
4. 问题：最终输出的final_thought杂乱，包含大量中间过程文本
- 原因：
final_thought返回的是达到threshold的那个思维节点对应的完整状态字符串。这个字符串可能包含了模型在整个路径上的所有思考记录。 - 解决：这是正常现象。你需要在打印或使用结果前，对其进行后处理。通常可以写一个简单的解析函数，从状态字符串中提取最后、最完整的答案部分。例如，用正则匹配“最终答案：”后面的内容，或者取状态文本的最后一段。
5. 性能与成本优化技巧
- 缓存结果：对于确定性较高的评估（例如规则检查），可以本地缓存
(状态, 评估分)对，避免相同状态的重复评估和 API 调用。 - 使用更便宜的模型进行评估：思维生成需要创造力，可以用
gpt-4；而中期评估更多是判断和比较，可以尝试用gpt-3.5-turbo，甚至微调过的小模型，能显著降低成本。这需要你修改TotAgent的内部调用逻辑，使用不同的模型配置。 - 设置预算和超时：在代理外层包裹一个逻辑，监控累计的 Token 消耗或 API 调用次数，达到上限后自动终止搜索，返回当前最优解。
5.3 思维树的可视化与调试（进阶）
项目 TODO 列表中提到了可视化，这确实是理解和调试 ToT 行为的利器。虽然官方功能尚未完成，但我们可以手动实现一个简单的版本。
核心思路是：修改ToTDFSAgent的run方法或相关内部方法，在每次生成和评估思维节点时，将节点信息（状态内容、评估分数、父节点ID）记录到一个列表中。搜索结束后，使用graphviz或networkx库将这些节点和边画出来。
一个极简的示例框架：
import networkx as nx import matplotlib.pyplot as plt class DebuggableToTDFSAgent(ToTDFSAgent): def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self.thought_tree = nx.DiGraph() self.node_counter = 0 self.node_data = {} # 记录节点ID到状态和分数的映射 def _record_thought(self, state, parent_id=None, score=0.0): """记录一个思维节点到图中""" node_id = self.node_counter self.node_counter += 1 self.thought_tree.add_node(node_id, state=state[:50], score=score) # 存摘要 self.node_data[node_id] = {'state': state, 'score': score} if parent_id is not None: self.thought_tree.add_edge(parent_id, node_id) return node_id # 你需要重写 _generate_thoughts, _evaluate_state 等方法，在其中调用 _record_thought # ... (此处省略具体重写细节，需参考源码) ... def visualize_tree(self): """可视化思维树""" pos = nx.spring_layout(self.thought_tree) plt.figure(figsize=(12, 8)) # 根据分数给节点上色 node_colors = [self.thought_tree.nodes[n].get('score', 0) for n in self.thought_tree.nodes()] labels = {n: f"{n}: {self.thought_tree.nodes[n].get('state', '')}" for n in self.thought_tree.nodes()} nx.draw(self.thought_tree, pos, with_labels=True, labels=labels, node_color=node_colors, cmap=plt.cm.YlOrRd, font_size=8) plt.title("Tree of Thoughts Search Graph") plt.show() # 使用自定义的代理 debug_agent = DebuggableToTDFSAgent(...) result = debug_agent.run(initial_state) debug_agent.visualize_tree()通过可视化，你可以清晰地看到哪些分支被探索了，在哪里被剪枝了，最终是哪条路径胜出。这对于调参和优化提示词有不可估量的价值。
Tree of Thoughts 框架为大语言模型的应用打开了一扇新的大门，从线性的链式推理升级到了立体的、可规划的搜索。它把提示工程从“艺术”更多地转向了“工程”，让我们能够以更系统、更可靠的方式去解决那些真正复杂的问题。当然，它的使用成本更高，对提示设计的要求也更精细。我的建议是，先从 24 点这类有明确规则的问题开始，熟悉整个流程和参数的感觉，然后再逐步挑战创意写作、代码生成、商业分析等更开放的任务。记住，关键不在于让模型一次想出答案，而在于设计一个能让模型有效“思考”的过程。这个开源项目提供了一个强大的起点，剩下的，就靠你的想象力去填充了。
