ToT 之后呢Graph of Thoughts 让大模型学会「把好思路的碎片拼成一条更好的路」128 位排序错误率仅为 ToT 的 38%上一讲我们聊了 Tree of ThoughtsToT思维树它让大模型从「一根筋写一条链」进化到「想多条路、能试错、能回头」把 24 点成功率从 4% 干到 74%。那 ToT 是不是终点了不是。ToT 的树有一个结构性硬伤每个节点只能有一个父节点 → 分支一旦分开就永远不能汇合。这听起来很学术但后果极其反直觉。我用一个排序题让你秒懂。〇、一个让 ToT 当场露怯的题把[8, 3, 5, 1, 9, 2, 7, 4]从小到大排好。用 ToT 的思路先拆两半各自排分支 A 把前半[8,3,5,1]排成了[3,5,1,8]66% 已有序分支 B 把后半[9,2,7,4]排成了[2,7,4,9]66% 已有序关键来了A 的前半里藏着正确顺序的碎片B 的后半里也藏着。但 ToT 是「树」——它只能二选一保留 A 或 B 里更好的那个天花板死死卡在66%。它无法把「A 的前半 B 的后半」拼起来——因为树没有「多父节点」这种边。而真实世界里大量好答案恰恰来自「把不同分支的好片段拼成一条更好的整体」排序要 merge、集合要取交集、多份文档要合并、多源事实要汇总。Graph of ThoughtsGoT思维图Besta et al., 2023就是为这件事而生的把推理建模成任意有向图可带环从而多出树做不到的两个原语——聚合多→1 合并和细化自环改进。一句话点题三种范式CoT 是「想一条路」ToT 是「想多条路、能回头」GoT 是「想多条路、还能把好路的碎片拼成一条更好的路」。一、GoT 是什么从链到树再到图GoT 把 LLM 的推理建模成一张任意图顶点vertex 一个「thought思维」即一个中间推理产物半成品答案、草稿、子结论。边edge thought 之间的依赖关系这个想法由那个想法派生 / 聚合 / 细化而来。图被写成G (V, E, c)V 是 thought 集合E 是依赖边c 是节点类别标注c ∈ {input, intermediate, output}框架靠它识别哪个是最终答案、哪个要评估。三范式结构对比范式拓扑每个节点的父独有原语能否回溯能否聚合CoT链线性1前驱—否否ToT树1生成 / 评估 /回溯是否GoT任意图可带环可多个生成 / 评估 /聚合 / 细化是是关键结论GoT 严格泛化是超集CoT 与 ToT。“chain tree graph” 应理解为「graph 包含前两者」而非并列第三档。ToT 的 BFS/DFS 都能用「合适的图 Reduce 算子」在 GoT 框架里表达。二、GoT 不是什么先排 4 个坑❌不是模型内部能力和 ToT 一样是套在模型外面的编排框架不是权重里焊死的功能那是 o1 / Claude 思考这类「推理模型」。模型永远只是被反复调用的「子程序」图 / 聚合 / 细化全是外部代码在管。❌不是一句 prompt你不能「加一句 Let’s think in a graph」就触发它需要一段 Controller 代码维护状态图、循环调模型。❌不是 Workflow工作流二者都长「节点 边」但语义相反见第五节。❌不是银弹它调用数最多、最贵只在「能分解且子结果需合并」的任务上才值。三、核心机制GoO / GRS 两层抽象 五大算子3.1 架构总览GoT 由Controller协调包含两个核心元素元素全称性质何时构建职责GoOGraph of Operations操作蓝图静态执行前构建一次声明用哪些算子、怎么连、图长啥拓扑“图纸”GRSGraph Reasoning State推理状态动态执行中持续更新维护哪些操作已执行、所有 thought 的状态 / 有效性 / 分数外加三个模块Prompter准备提示、Parser抽取信息、Scoring验证并打分。为什么这层分离重要它让「换图结构」变成改配置GoO而不是改代码。不同任务就是不同的 GoO 图纸运行时实例化出不同的 GRS。3.2 五大算子thought transformations论文定义了作用在 thought 上的算子前四个是核心、第五个 Reduce 常被遗漏算子作用是否 GoT 独有Generate生成从一个 thought 产出多个候选否CoT/ToT 都有Score评分给 thought 打分 / 验证否ToT 有Aggregate聚合把多个 thought 融合成一个全新的内容合并是 ★Refine细化拿一个 thought 自己改进自己自环是 ★Reduce缩减把 N 个 thought压成 k 个保留不合并内容是论文常写 KeepBest(N)Aggregate vs Reduce 易混必须分清Aggregate 「合多为一内容融合」——结果是一个新 thought内容来自多个父。Reduce 「从多里挑少集合缩减」——结果还是那几个 thought 本身只是数量变少。例排序里「把 8 段各排好的分支 Reduce 成 top-2 进入下一轮合并」是Reduce「把两段已排序序列 merge 成一个更长有序序列」是Aggregate。四、实战排序案例完整走查题目把[8,3,5,1,9,2,7,4]从小到大排好。GoT 用merge-based sorting分治排序。① Generate外部代码把任务拆成「先各排一半」调模型两次A [3,5,1,8]前半66% 有序B [2,7,4,9]后半66% 有序② Score给 A、B 各打分这里用「已有序比例」66% / 66%。停在这里如果只用ToT树算法只能二选一天花板卡在66%——因为树不能汇合。③ Aggregate聚合GoT 独有★外部代码把 A 和 B合并成一个新 thoughtmerge(A, B)→[2,3,5,1,7,4,8,9]Score 升到71%关键点没有任何一条分支单独含着全部正确顺序。是「合并」把两半的好片段拼出来的——树做不到只有图能汇合。④ Refine细化GoT 独有让模型拿合并结果自己改进自己图里 Refine 框的自环箭头做一次相邻交换打磨 → 得到100% 排好的最终结果标记为output节点。⑤ 终止遇到output类别节点或达到max-depthController 停止并输出。同题对比为什么 GoT 更强论文在 128 位数字排序上GoT 错误率仅为 ToT 的38%即相对改进 62%同时成本还降了31%——因为「聚合」复用了各分支的好片段不必重复生成。代价每次聚合 / 细化都要额外调模型调用数比 ToT 还多。原则是chain tree graph用最小够用的结构。纯数学用 SC、要试错回溯用 ToT、要「拼碎片」才上 GoT。五、最容易误解的点模型根本不知道自己在「图」里很多人以为 GoT 是模型「自己画出一张图在思考」——错。和 ToT 一样模型每次只接到一段 prompt吐出一段文字然后外部代码把结果存进自己的数据结构决定下一步再喂给它什么。框架结构在哪模型被调用几次CoT在输出 token 序列里一次生成1 次ToT在外部 Python 代码的树里N 次GoT在外部 Python 代码的图里N 次更多核心澄清GoT/ToT 里模型根本不知道自己在「树」或「图」里它只是一个被反复调用的子程序。树 / 图、剪枝、回溯、聚合——全是你写的代码在管。而真正的「模型内部」是推理模型o1 / Claude 思考 / Gemini thinking权重在 RL 训练时被改过先想后答焊进模型本身——但那内部也没有显式的树或图结构只是默认多生成一串隐藏推理 token。一句话CoT 是模型「内部」最轻量的推理增强一句话提示就自己写链ToT/GoT 是「系统层面」的外部编排得写代码。三者里只有 CoT 是模型自己一次生成的。六、GoT 与 Workflow 的关系同形不同义很多人以为「GoT 是基于 Workflow 的」——错。两者是两层正交结构只是视觉上都长「节点 边」。维度GoT推理图Workflow执行图 / DAG节点一个 thought中间推理产物一个操作算子调 API、跑工具、存库边推理依赖「这想法从那想法派生 / 聚合 / 细化」控制 / 数据流「做完 A 然后做 B」拓扑谁定运行时由搜索算法发现你只写连边规则开发时由你写死DAG 骨架每次一样目的在未知推理空间里搜索好答案提升质量把已知流程可靠跑完提升可靠性确定性非确定每次结果图不同确定给定输入走法基本固定GoT 的图是「搜索出来的推理地图」Workflow 的图是「你设计的操作说明书」。真实关系正交、可嵌套。你可以在 Workflow 的某个节点内部跑 GoT[读取需求] → [规划节点(内部跑 GoT)] → [执行节点] → [检查]。外层 Workflow里层 GoT各管一层。七、思想级并行为什么 GoT「调用多却还能省」GoT 每次聚合 / 细化都额外调模型调用数比 ToT 还多——但论文说成本反而降31%。秘密是并行CoT/ToT 的 DFS 往往串行一条分支走死才换下一条。GoT 的图天然可并行不同分支的 thought 可以同时批量发给模型。延迟被摊薄整体 wall-clock 反而短。这不是「更少调用」是「并行摊薄」——ToT树很难做到的隐藏优势。论文还提出「思想的体积」Volume of a thought指标定义为「给定 thought 可以从多少个先行 thought 到达」用来刻画某个推理结果汇聚了多少信息广度。从侧面印证 GoT 的核心价值——让信息跨分支汇聚。八、任务 → 图模板映射GoO 配置表不同任务GoO 图纸不一样。论文给了四类真实用例任务图结构模板GoO关键算子Sorting排序分治 多步 Aggregatemerge-sort 式Generate → Score →Aggregate(k) → RefineSet operations集合运算单次 Aggregate拆分子集 → 各自求交 →AggregateDocument merge文档合并层级 Aggregate两两合并再合并多源抽取 → 分层AggregateKeyword counting关键词计数分治 Reduce分段处理 →Reduce聚合计数九、局限性与不适用场景必读否则 GoT 显得无敌GoT完整继承了 ToT 的弱点还更贵调用数最多每次聚合 / 细化都额外调模型比 ToT 更烧钱。聚合函数要手工设计怎么把多个 thought 拼成合法输入喂给模型是工程难点不是开箱即用。评估器同样不可靠继承 ToT 的「误判」——评估器看走眼会剪错 / 留错。并非所有任务可聚合很多任务子结果不可合并如「写一首诗」没有 halfway 可拼硬上 GoT 反而乱。小模型不行评估器 / 聚合器本身得够强。环有无限循环风险Refine 自环必须配max-depth/output 类别终止条件否则会一直「改进自己」到刷爆账单。适用边界一句话只有「能分解、且子结果需要合并成更好整体」的任务才值——排序、集合运算、文档合并、多源事实整合。其余别炫技。十、论文实测结果已核对原论文 Besta et al., 2023任务GoT 表现Sorting排序质量比 ToT高 62%同时成本降 31%128 元素时中位数误差比 ToT 减约62%规模效应改进随问题规模增大而显著32 元素微不足道64 元素约61%128 元素约69%相对 CoT / IO排序质量比 CoT 高约70%、比 IO 高约83%Set intersection集合交集错误元素数显著少于其他方法Keyword counting关键词计数错误率显著降低且成本合理Document merge文档合并得分高于基线能结合部分重叠信息、最小化冗余规律GoT 的优势随问题复杂度上升而放大——越需要「分解 聚合」的复杂任务越该用图而非链 / 树。十一、怎么用 GoT官方库GoT 也不是「换个提示词」而是用框架代码跑。官方实现是spcl/graph-of-thoughtsGitHub配置驱动你写一份 GoO 配置用哪些算子、什么拓扑它实例化跑 GoT。安装Python 3.8pipinstallgraph_of_thoughts# 或开发者从源码可编辑安装gitclone https://github.com/spcl/graph-of-thoughts.gitcdgraph-of-thoughtspipinstall-e.最小用法排序 32 个数来自官方 README真实可用fromexamples.sorting.sorting_032importSortingPrompter,SortingParser,got,utilsfromgraph_of_thoughtsimportcontroller,language_models,operations input_to_be_sorted[0, 2, 6, 3, 8, 7, 1, 1, 6, 7, 7, 7, 7, 9, 3, 0, 1, 7, 9, 1, 3, 5, 1, 3, 6, 4, 5, 4, 7, 3, 5, 7]gopgot()# 预置 GoO 图纸merge-sort 式图lmlanguage_models.ChatGPT(config.json,model_namechatgpt)ctrlcontroller.Controller(lm,gop,SortingPrompter(),SortingParser(),{original:input_to_be_sorted,current:,phase:0,method:got},)ctrl.run()ctrl.output_graph(output_got.json)# 最终 thought 的分数 排序错误数同样的库把gop换成operations.GraphOfOperations()GenerateScoreGroundTruth、method改成cot就是用 GoT 框架跑纯 CoT——这正说明 GoT 是 CoT/ToT 的超集框架可降级表达旧范式。套用到你自己的任务四步定义 thought 粒度一个 thought 该多大写评估器优先确定性 verifier能写代码判对错就别让 LLM 自评如排序直接数错误数从根上缓解评估器不可靠。选图模板要「拼碎片」用多层 Aggregate要「挑少」用 Reduce(KeepBest)。加护栏设max-depth、总 LLM 调用上限防环和树爆炸刷爆账单。十二、为什么你现在该把这条线串起来推理结构的演进主线很清楚CoT链→ SC多链投票→ ToT树 回溯→ GoT图 聚合 / 细化从「模型一次生成」到「外部树编排」再到「外部图编排」。GoT 还能接更强搜索外层不限于 BFS/DFS可上MCTS做探索-利用权衡。而它真正的价值不在「图」这个花活而在于一句话——当问题的答案来自「把不同思路的好碎片拼起来」你就该用图而不是链或树。最后我把 GoT 从「为什么 ToT 的树不够用」到「五大算子怎么搭」、排序实战走查、模型到底知不知道自己在图里、GoT 与 Workflow 的同形不同义、思想级并行、四类任务配图、适用边界再到官方库用法——整理成了一份 10 章的《Graph of Thoughts (GoT) 学习指南》完整版。里面还附了✅GoO / GRS 架构图 五大算子对照✅ 排序 / 集合 / 文档合并 / 关键词计数四类真实案例配图✅ 官方库graph_of_thoughts可运行代码 四步迁移法✅ 与 CoT / ToT 的衔接和方法版图含两篇同名 ToT 论文的命名澄清 关注看后续 顺手推荐一个开源工具deepSeekHarenss Desktop—— DeepSeekHarenss 的客户端工具用来一键安装 DeepSeekHarenss省去手动配置环境的麻烦。 下载地址https://github.com/qweqe417/dsh-desktop有兴趣的朋友可以去下一个玩玩顺便点个 ⭐Star支持作者 一张图看懂链 → 树 → 图三范式递进① CoT链—— 一根筋走到底问题 → 步骤1 → 步骤2 → 步骤3 → 答案 错了只能错到底② ToT树—— 多路并行能回头但分支一旦分开就合不拢┌─→ 候选 A ─┐ │ │ 问题 ── 生成 ──┬─→├─→ 候选 B ─┼─→ 评估 → 剪枝/保留 → 答案 │ │ │ │ └─→ 候选 C ─┘ │ └── 回溯换路分支之间不能合并③ GoT图—— 多路并行 能回头 能把好碎片拼起来聚合┌─→ 候选 A ─┐ │ ├─→ Aggregate ─→ 新 thought ─┐ 问题 ── 生成 ──┬─→├─→ 候选 B ─┤ 多→1 合并 ├─→ Refine(自环) ─→ 答案 │ │ ├─→ │ │ └─→ 候选 C ─┘ │ │ │ └──────── 回溯换路 ────────────────────────────┘一句话链「一根筋」树「多路能回头但分了就合不拢」图「多路能回头还能把好碎片拼成更好的整体」——这就是 GoT 把排序错误率压到 ToT 的38%的关键。