Graph of Thoughts：把提示链变成可执行的有向图

它解决的是提示链表达不了的依赖关系

CoT 把推理写成一条直线，ToT 在树的分叉上做搜索。Graph of Thoughts 的作者认为这两种结构都限制了任务的表达。它把思维过程建模成一张有向无环图，节点是操作，边是依赖。一个操作的输出可以喂给多个后续操作，多个操作的输出也可以合并进同一个操作。这种结构能表达循环、回溯和并行，例如先让多个模型各写一段排序结果，再让另一个模型合并这些片段。框架本身不限定图的样子，你可以在代码里任意拼接操作节点。它面向的是那些无法用单条 prompt 或简单树搜索解决的复杂问题，比如长文本排序、关键词计数这种需要分治或多轮验证的任务。使用者也因此需要具备一定的编程能力，因为你要自己定义操作序列和解析逻辑。

GraphOfOperations 与 Controller 的分工

框架的核心是三个模块：operations 负责定义图结构，controller 负责执行图，language_models 负责封装对不同 LLM 后端的调用。GraphOfOperations 是一个容器，你通过 append_operation 往里加操作节点。每个操作是框架预定义的类，比如 Generate 表示让 LLM 生成一次文本，Score 表示对结果打分，GroundTruth 表示与已知答案比对。这些操作之间没有显式的边，执行顺序由你追加的顺序决定，Controller 按顺序调度。Controller 接收语言模型、图操作、Prompter 和 Parser 四个参数。Prompter 负责把当前状态转成发给 LLM 的 prompt，Parser 负责把 LLM 返回的文本解析回结构化状态。状态以字典形式传递，例如排序问题里包含 original、current 和 method 三个键。这种设计让框架不关心具体任务，只负责按图执行和传递状态。README 里强调 Controller 和 Operations 的文档是理解框架的关键，也暗示了扩展点集中在这两处。

从 pip 安装到跑通排序示例

安装分两种路径。普通用户执行 pip install graph_of_thoughts，开发者克隆仓库后执行 pip install -e . 获得可编辑安装。前置要求是 Python 3.8 或更高版本。装完后需要配置 LLM，框架通过 config.json 读取 OpenAI API 密钥，语言模型对象用 language_models.ChatGPT("config.json", model_name="chatgpt") 创建。快速开始示例解决的是 32 个数字的排序问题。CoT 式做法是手动构造一个线性图操作，依次加入 Generate、Score 和 GroundTruth 操作，然后创建 Controller 并调用 run()。GoT 式做法不同，它从 examples.sorting.sorting_032 的 got 函数直接取回预定义的图操作，该图内部已经编排好分治、合并和验证的节点。两种做法最后都用 output_graph 把执行过程导出成 JSON 文件，你可以对比两个文件里最终状态的分数，分数表示排序中的错误数。命令行直接运行 python -m examples.sorting.sorting_032 也能触发示例，结果会写入示例子目录。

预定义操作之外的扩展成本

框架内置了 Generate、Score、GroundTruth 等基础操作，但真实任务很少能只用这几个操作拼出来。README 提到的 keyword_counting 示例也需要自己的 Prompter 和 Parser。这意味着每接入一个新问题，你至少要写三个类：负责构造 prompt 的 Prompter，负责解析模型输出的 Parser，以及定义图结构的函数。Controller 本身不关心任务语义，它只是机械地执行图节点并传递状态字典。这种解耦是优点也是负担。优点是框架不绑定任何具体任务，缺点是任务相关的所有智能都落在你的代码里。如果你要实现的图包含条件分支或循环，你得用 Python 逻辑在 GraphOfOperations 构建阶段动态生成不同路径，框架本身不提供运行时条件跳转。文档没有说明是否支持动态图结构，从示例看，图在运行前就固定了。因此，扩展一个新任务的时间成本可能超过直接写 prompt 脚本。

一个被 README 轻描淡写的限制：LLM 调用次数

GoT 的论文方法依赖多次 LLM 调用，每次生成、打分、合并都要消耗一次或多次 API 请求。排序 32 个数字的 GoT 图，从 got() 函数的实现看，包含多个生成和合并阶段，实际调用次数远多于 CoT 的单次生成加一次打分。README 没有给出具体数值，但你可以从图结构推断。Controller 按顺序执行每个操作，每个 Generate 操作都会调用一次语言模型。如果某个操作失败，比如模型返回格式无法被 Parser 解析，框架的默认行为是什么，README 没有说明。这意味着错误处理需要你自己在 Parser 里做防御。延迟也是实际问题，串行执行多个 LLM 调用会让总耗时线性叠加，不适合对响应时间敏感的应用。框架的定位是离线研究工具，不是生产级推理服务。文档中也没有提到缓存或并发执行机制，所有操作似乎都是同步阻塞的。

与 CoT 和 ToT 的关系：不是替代而是封装

Graph of Thoughts 的论文标题强调它是新方法，但框架本身并不排斥旧方法。README 明确说，你可以用这个框架实现类似 CoT 或 ToT 的图操作。快速开始里的第一个示例就是用 GoT 框架跑 CoT 式流程，第二个示例才是完整的 GoT 图。这种设计让框架成为一个统一的实验平台。与之相比，LangChain 这类通用编排框架也提供链和代理，但它的抽象更偏向顺序执行和工具调用，没有把思维过程当作图来显式建模。GoT 的差异在于它把图结构当作一等公民，Controller 的输出就是一张完整的执行图，包含每个节点的输入输出和状态变化，你可以导出 JSON 做可视化或复现。这个特点是 LangChain 没有的。但代价是 GoT 的图操作需要你预先定义好所有可能的操作类型，而 LangChain 允许你在运行时动态决定下一步调用什么工具。前者是静态图，后者是动态决策，这是两者最本质的区别。

维护状态与许可证的模糊地带

仓库最后推送时间是 2026 年 3 月，但最近一次版本发布停留在 2023 年 9 月的 v0.0.2。版本号停留在 0.0.x 说明项目仍处于早期阶段，API 可能随时变化。README 中给出的代码示例用的是 graph_of_thoughts 包名，但实际导入路径是 graph_of_thoughts.controller，安装包名与模块名不一致，这在小版本迭代中容易造成混淆。许可证字段是 NOASSERTION，意味着仓库没有声明明确的开源许可证。这对企业采用是硬伤，你不能确定是否可以商用、修改或分发代码。虽然论文本身发表在 AAAI 上，但代码的许可证状态不明，法律风险需要你自己评估。文档质量是亮点，README 提到对每个模块都做了完整注释，Controller 和 Operations 各有独立 README，examples 目录下每个示例也带说明。但如果你要基于它做二次开发，最好先克隆源码阅读注释，因为 PyPI 上的包可能滞后于主分支。

编辑结论

Graph of Thoughts 适合两类人：一是做提示工程研究、需要复现 CoT/ToT/GoT 对比实验的学者；二是任务本身可以拆成多个独立或半独立子问题、且愿意为每个子问题写解析器的工程师。不适合只想快速调用 LLM 完成单次问答的人，因为图编排的抽象层和解析器开发成本远高于直接写 prompt。也不适合需要实时低延迟推理的场景，多次 LLM 调用串行执行会放大延迟。采用前先验证三件事：你的 LLM 后端是否支持框架内置的 API 封装；你的问题是否能被拆成具有明确评分函数的子步骤；你是否有时间维护自定义的 Prompter 和 Parser。若答案都是否，直接写 prompt 或使用 LangChain 这类通用编排工具更务实。Graph of Thoughts 的价值在于把推理结构显式化，但这份显式化需要你用代码去兑现。

官方来源

1. Issues
2. Project website
3. README
4. Releases
5. spcl/graph-of-thoughts on GitHub