tree-of-thoughts

tree-of-thoughts 技能概览

tree-of-thoughts 的作用

tree-of-thoughts 是一种推理工作流技能，适用于需要不止一次推演或不止一个答案的任务。它会引导 agent 探索多种方案，用 meta-judge 评分标准进行打分，剪掉薄弱分支，再综合出最佳结果，而不是直接跳到单一解法。

适合谁使用

当任务存在明显取舍时，建议使用 tree-of-thoughts 技能：比如架构选型、疑难排障、规划、分析，或任何“第一反应往往不是最佳答案”的请求。它对 Agent Orchestration 尤其有用，因为它能把模糊的多步骤工作转成“比较—选择”的过程。

它为什么不同

它的核心价值不在于抽象意义上的“想得更多”，而在于有结构地思考。tree-of-thoughts 增加了显式探索、评价标准和分支选择，因此最终输出比普通 prompt 链更容易信任。尤其是在你需要减少幻觉式跳跃、做出更可辩护的决策时，这一点非常重要。

如何使用 tree-of-thoughts 技能

安装并定位该技能

先按仓库里技能的安装流程完成安装，然后优先打开 plugins/sadd/skills/tree-of-thoughts/SKILL.md。这个技能正文就是行为规范的主要来源；它没有可展开的 helper scripts 或 reference folders，所以真正重要的指导都在这个文件本身。

先给出合适的任务输入

只有当你的任务被明确表述为“决策”或“综合”问题时，tree-of-thoughts 安装才真正有帮助。请提供清晰目标、约束条件、成功标准，以及任何固定输入。一个强提示词会像这样：“比较 X 的三种实现方案，优化可维护性和延迟，并用明确的取舍说明为什么这个方案胜出。”一个弱提示词则只是：“帮我处理 X。”

把工作流当作 prompt 结构来用

要把 tree-of-thoughts 用好，最好要求它分阶段输出：先生成候选方案，再定义评价 rubric，然后对各分支评分，最后综合出被选中的路径。若你想把 tree-of-thoughts 用在 Agent Orchestration 里，还要加入 agent 角色、投票规则，以及分数接近时该如何处理。这样可以避免模型把探索过程压缩成一个泛泛而谈的答案。

先读这几部分

先看 SKILL.md 里的任务、上下文和阶段结构。重点关注描述探索、裁决和适配的部分，因为这些内容最能改变输出质量。如果你要把这个技能改造成适配自己的技术栈，先把它的各阶段映射到你仓库里的真实决策点，再投入生产使用。

tree-of-thoughts 技能 FAQ

tree-of-thoughts 比普通 prompt 更好吗？

通常是的，前提是问题有多条合理路径，而且你关心的是如何从中选出最优方案。普通 prompt 适合直接回答；tree-of-thoughts 更适合需要比较、剪枝和理性收敛到最终选择的场景。

这个 tree-of-thoughts 技能适合新手吗？

适合，只要你能把任务讲清楚。你不必先理解研究文献也能用好这个技能，但你需要提供约束条件，并接受模型应该先探索、再决定。

什么时候不该用它？

对于简单事实查询、一步式修改，或答案本来就已知的任务，不要使用 tree-of-thoughts。它会带来额外开销，所以最适合那些“值得为更好的推理多走几步”的场景。

它适合 Agent Orchestration 工作流吗？

适合。tree-of-thoughts 很适合 orchestration，因为它支持分支提案、多 agent 评估和受控的合并步骤。这样一来，你可以更容易管理互相竞争的 agent 输出，而不必只靠直觉判断。

如何改进 tree-of-thoughts 技能

给技能更强的决策输入

最有效的升级是把问题框得更清楚。请包含目标、约束、非目标，以及你希望返回的具体格式。对于 tree-of-thoughts 来说，当模型能比较具体选项而不是从零编造选项时，表现会更好。

把评价标准说清楚

如果你希望分支剪枝做得好，就要告诉这个技能“好”到底意味着什么。比如：先保证正确性，其次是速度，再次是实现简单度。清晰的 rubric 能提升 tree-of-thoughts 的使用效果，因为 judge 阶段可以按标准机械地排序，而不是靠猜。

留意常见失败模式

最常见的问题是过度探索，却没有清晰的决策规则。如果出现这种情况，就缩小分支数量、限制深度，或者要求给出最终推荐，并同时提供一个已选路径和一个备选方案。这样可以防止 tree-of-thoughts 变成一场过度展开的头脑风暴。

通过收紧 brief 反复迭代

如果第一次输出太宽泛，就继续沿用这份 tree-of-thoughts 指南，但补上缺失上下文：目标受众、技术栈、约束条件，以及必须保留的内容。尤其是在 Agent Orchestration 场景下，要加入角色边界和冲突规则，这样最终综合结果才会真正反映你的 agent 实际工作方式。