从思维链到思维图：GoT框架如何革新大语言模型推理

1. 项目概述：从“思维链”到“思维图”的范式跃迁

如果你最近在关注大语言模型（LLM）的应用与推理能力增强，那么“思维链”（Chain-of-Thought, CoT）这个词你一定不陌生。它通过让模型“一步一步思考”，显著提升了其在复杂推理任务上的表现。然而，CoT本质上是一条线性的推理路径，就像一个人沿着一条单行道从头走到尾。当面对的问题存在多种可能的解法、需要多角度验证或者步骤间存在复杂依赖时，这种线性结构就显得力不从心了。

今天要深入探讨的spcl/graph-of-thoughts（GoT）项目，正是为了解决这一核心瓶颈而生。它不是一个简单的工具库，而是一个开创性的框架，旨在将LLM的推理过程从“链”升级为“图”。简单来说，GoT允许我们将一个复杂的任务分解成多个“思维”节点，这些节点之间可以按照非线性的关系（如聚合、循环、分支）连接起来，形成一个动态的、可塑的推理图。这个框架由苏黎世联邦理工学院（ETH Zurich）的研究团队提出，其论文和代码已经开源，为我们探索LLM更强大的推理能力打开了一扇新的大门。

这个框架的核心价值在于它极大地扩展了LLM推理的表达能力。传统的CoT或更近期的“思维树”（Tree of Thoughts, ToT）可以看作是GoT的特殊子集（线性链或树状结构）。GoT则更加通用，它允许：

1. 信息聚合：将多个推理路径的中间结果合并，提炼出更优质的结论。
2. 循环与迭代：对不满意的结果进行回溯和修正，实现自我改进。
3. 任意图拓扑：根据任务需求，灵活设计推理步骤之间的依赖关系。

无论是进行复杂的数学证明、多文档信息综合、创意写作的头脑风暴，还是代码生成的调试与优化，GoT都提供了一种结构化的方法来引导和增强LLM的推理过程。接下来，我将带你深入这个框架的内部，拆解其设计思路、核心组件，并分享如何将其应用于实际场景的实操经验。

2. 核心架构与设计哲学拆解

要理解GoT，我们不能只停留在“用图来组织思考”这个比喻层面，必须深入到其技术架构的设计哲学。整个框架的构建围绕着几个关键问题：如何形式化地表示一个“思维”？如何定义和操作思维之间的关系？如何让LLM在这个图结构中协同工作？

2.1 思维（Thought）的抽象与表示

在GoT中，一切的基础是“思维”。这不仅仅是一个文本片段，而是一个结构化的对象。一个典型的Thought对象通常包含以下核心属性：

• 内容（Content）: 思维的具体文本表述，例如一个推理步骤、一个假设、一段总结。
• 状态（State）: 表示该思维的当前状态，如生成中（generating）、已完成（completed）、已评估（evaluated）、已聚合（aggregated）。状态机机制是协调整个异步推理流程的关键。
• 分数/评估（Score）: 一个对该思维质量的量化评估值。这个分数可以来自LLM自身的评估（例如，“请为你刚才提出的方案从1到10打分”），也可以来自外部评估函数。分数是后续进行路径选择（如波束搜索）和聚合操作的核心依据。
• 元数据（Metadata）: 可包含生成该思维所使用的提示词（Prompt）、模型参数、父节点ID等，用于追溯和调试。

这种抽象将LLM的一次调用或一个推理步骤封装成了一个可编程、可观测的单元。这是实现复杂工作流编排的基础。

2.2 操作（Operation）与图拓扑构建

思维本身是静态的，思维之间的“边”则由“操作”来动态创建和定义。GoT框架预定义了几类核心操作，这也是其强大表达能力的来源：

1. 生成（Generate）: 最基本的操作。基于一个或多个父思维的内容，通过LLM生成一个新的子思维。这对应着图中“节点扩展”的过程。
2. 聚合（Aggregate）: 这是GoT区别于链和树的关键操作。它可以将多个思维（例如，探索同一问题的不同解决方案）作为输入，通过LLM进行综合、比较、提炼，生成一个质量更高的新思维。这个新思维会“吸收”多个输入思维的精华。
3. 改进/循环（Refine/Loop）: 对一个已有的思维进行修正、深化或迭代。这通过在图中创建一条从某思维指向其自身或新版本的边来实现，用于实现自我批评和迭代优化。
4. 评估（Evaluate）: 为一个或多个思维分配分数。评估操作本身可能不产生新的内容节点，但会更新节点的“分数”属性，影响图的后续演化方向。

通过组合这些操作，我们可以构建出极其复杂的推理拓扑。例如，一个“生成-评估-聚合-再生成”的循环，可以模拟人类“提出想法、评判优劣、整合观点、深化思考”的完整过程。框架的“编排器”（Orchestrator）负责解析我们定义好的图结构，并按照依赖关系有序地调度这些操作。

2.3 评估与评分策略

如何评估一个“思维”的好坏，是引导整个推理图向正确方向演化的“指挥棒”。GoT框架在这方面提供了灵活性：

• LLM自评估：让LLM根据任务目标，对自己或他人的输出进行评分。例如，在写作任务中，让其评估段落的连贯性；在解题任务中，评估步骤的逻辑性。提示词工程在这里至关重要，需要设计出能让LLM进行稳定、相对客观比较的指令。
• 外部评估函数：对于有明确答案的任务（如数学计算、代码运行），可以直接编写函数来验证结果的正确性。这是最可靠但适用场景较窄的方式。
• 投票或一致性检查：生成多个候选思维，让LLM判断哪个更优，或者检查多个思维之间是否存在共识。

在实际应用中，我通常采用“混合评估”策略。先用一个快速、低成本的外部检查或简单自评估进行初筛，过滤掉明显错误的路径；再对剩余的优质候选进行更精细、更耗资源的LLM深度评估，以选出最佳路径。这能在效果和成本间取得良好平衡。

3. 实战演练：构建你的第一个GoT应用

理解了理论，我们动手实现一个具体场景：“多角度产品评测报告生成”。假设我们需要为一款新的无线耳机撰写评测，我们希望报告能涵盖音质、佩戴舒适度、续航、性价比等多个维度，并且结论要综合平衡。

3.1 环境搭建与依赖安装

项目基于Python，并高度依赖LangChain等LLM应用开发框架来管理与大模型的交互。以下是搭建环境的步骤：

# 1. 克隆仓库 git clone https://github.com/spcl/graph-of-thoughts.git cd graph-of-thoughts # 2. 创建并激活虚拟环境（推荐） python -m venv venv source venv/bin/activate # Linux/macOS # venv\Scripts\activate # Windows # 3. 安装核心依赖 pip install -r requirements.txt # 通常包括：langchain, langchain-openai, pydantic, networkx等 # 4. 设置你的LLM API密钥（以OpenAI为例） export OPENAI_API_KEY='your-api-key-here' # 或在代码中通过os.environ设置

这里有一个关键点：原项目requirements.txt可能不会直接包含langchain-openai这样的具体集成包。你需要根据自己选择的LLM提供商（OpenAI, Anthropic, 本地部署的Ollama等）额外安装对应的LangChain集成包。例如，使用OpenAI则pip install langchain-openai，使用Ollama则pip install langchain-community。

3.2 定义思维图结构与操作

我们规划一个简单的图：首先生成四个独立维度的评测（音质、舒适度、续航、性价比），然后聚合这四个维度的观点，形成一份综合报告。

import asyncio from graph_of_thoughts.models import OpenAIModel # 假设的导入路径，需根据实际项目调整 from graph_of_thoughts.thought import Thought, ThoughtState from graph_of_thoughts.operations import Generate, Aggregate from graph_of_thoughts.orchestrator import Orchestrator # 1. 初始化LLM模型 llm = OpenAIModel(model="gpt-4-turbo", api_key=os.getenv("OPENAI_API_KEY")) # 2. 定义初始思维（任务描述） initial_thought = Thought( id="task", content="请为‘NovaSound Pro无线耳机’生成一份全面的评测报告。", state=ThoughtState.COMPLETED ) # 3. 定义生成操作 - 创建四个维度的子思维 aspects = ["音质表现", "佩戴舒适度与设计", "电池续航与充电", "价格与性价比"] generate_ops = [] dimension_thoughts = [] for i, aspect in enumerate(aspects): op = Generate( name=f"gen_{aspect}", # 提示词：基于总任务，专门思考某一个维度 prompt=lambda parent_thought, aspect=aspect: f""" 基于以下产品评测任务：{parent_thought.content} 请你专注于‘{aspect}’这个单一维度，撰写一段详细、客观的评测分析。 分析应包含具体体验描述和优缺点。 """, llm=llm, parents=["task"], # 依赖于初始任务思维 # 结果会创建一个新的Thought对象 ) generate_ops.append(op) # 我们预先知道会生成四个新思维，这里用占位符表示，实际操作中由Orchestrator创建 dimension_thoughts.append(Thought(id=f"dim_{i}", state=ThoughtState.PENDING)) # 4. 定义聚合操作 - 将四个维度综合成最终报告 aggregate_op = Aggregate( name="agg_final_report", prompt=lambda parent_thoughts: f""" 你是一名专业的科技产品编辑。以下是关于‘NovaSound Pro无线耳机’在四个不同维度的独立评测： {chr(10).join([f'### {aspects[i]}：{t.content}' for i, t in enumerate(parent_thoughts)])} 你的任务是将以上所有维度的观点整合起来，撰写一份结构完整、逻辑连贯、结论平衡的最终评测报告。 报告应包含：概述、分维度总结、综合结论与购买建议。 确保整合时处理可能存在的观点冲突，给出一个全面而公正的整体评价。 """, llm=llm, parents=[t.id for t in dimension_thoughts], # 依赖于所有四个维度思维 ) # 5. 创建编排器并执行图 orchestrator = Orchestrator( initial_thoughts=[initial_thought], operations=generate_ops + [aggregate_op], ) # 异步执行是主流，因为LLM API调用通常是网络IO密集型 final_results = await orchestrator.run()

在这个例子中，我们清晰地定义了一个两层的图结构：第一层是四个并行的“生成”操作，第二层是一个“聚合”操作。编排器会先并发执行四个生成操作（前提是LLM API允许并发），待它们全部完成后，再执行聚合操作。

3.3 关键参数配置与调优心得

在实际运行中，有几个参数对结果质量和成本影响巨大：

• LLM模型选择：对于“生成”节点，可以使用能力稍弱但更经济的模型（如gpt-3.5-turbo）；对于关键的“聚合”或“评估”节点，建议使用能力最强的模型（如gpt-4）。这种混合模型策略能有效控制成本。
• 温度（Temperature）：在“生成”多样性观点的阶段（如头脑风暴），可以设置较高的温度（如0.8-1.0）以探索更多可能性；在“聚合”或需要稳定输出的阶段，则应使用较低的温度（如0.2-0.5）。
• 并发控制：虽然GoT框架支持并发，但需注意LLM提供商的速率限制。需要在编排器中配置最大并发数，避免触发API限制导致失败。我的经验是，对于OpenAI，初始设置并发数在5-10之间比较安全，再根据实际情况调整。
• 提示词工程：这是GoT应用的灵魂。为不同操作设计精准的提示词比模型本身更重要。例如，在“评估”操作的提示词中，必须给出清晰、可操作的评分标准（“请根据逻辑严谨性、创新性和可行性三个方面，分别以1-10分打分”）。

实操心得：在构建复杂GoT图时，我强烈建议从一个极其简单的图开始（例如，一个生成+一个聚合），确保管道畅通。然后逐步增加节点和边的复杂度。同时，为每个Thought对象记录完整的元数据（如使用的提示词、模型参数），这会在调试和优化阶段为你节省大量时间。当图执行出现意外结果时，首先检查各个节点的输入（父思维的内容）是否符合预期，这能解决大部分问题。

4. 高级模式与复杂场景应用

掌握了基础用法后，我们可以探索GoT框架更强大的能力，将其应用于更复杂的场景。

4.1 迭代优化模式：让LLM自我修正

这是GoT非常吸引人的一种应用。我们可以构建一个包含“生成 -> 评估 -> 改进”循环的子图。

假设任务是“写一首关于秋天的七言绝句”。我们可以这样设计：

1. 节点G1：生成初始诗句。
2. 节点E1：评估初始诗句，从“意境”、“平仄”、“押韵”三个方面打分。
3. 节点R1：如果分数低于阈值，则基于评估意见进行改进，生成诗句V2。
4. 节点E2：评估诗句V2。
5. 循环判断：如果分数达标或达到最大迭代次数，则终止；否则，将R1的输出再次作为R1的输入，继续改进。

这个过程在GoT中可以通过让Refine操作的父节点包含其自身的前一个版本来实现。编排器会管理循环的终止条件。这种模式非常适合写作、代码调试、方案优化等需要反复打磨的任务。

4.2 基于评估的路径搜索

这类似于在推理空间中执行“波束搜索”（Beam Search）。例如，在一个复杂推理问题中：

1. 从当前状态，并行生成K个可能的下一步推理（Generatex K）。
2. 对这K个候选思维进行快速评估（Evaluate），选出得分最高的M个（M < K）。
3. 以这M个优质思维为新的起点，重复步骤1和2。
4. 最终，从多条探索路径的终端节点中，选出全局得分最高的思维作为最终答案。

GoT的图结构能很自然地表达这种“扩展-剪枝-再扩展”的搜索过程。你需要自定义一个“选择器”（Selector）模块，集成到编排逻辑中，负责在每个搜索深度根据分数选择保留哪些分支。

4.3 多智能体协作模拟

我们可以将图中的不同节点或子图赋予不同的“角色”，模拟一个专家团队。例如，在一个市场分析任务中：

• 节点A（分析师）：生成市场数据解读。
• 节点B（策略师）：基于解读，生成潜在策略。
• 节点C（风险评估师）：对策略进行风险分析。
• 节点D（CEO/聚合器）：综合数据、策略和风险，做出最终决策。

每个节点使用不同的系统提示词（System Prompt）来塑造其角色身份。GoT的图定义了这些专家之间的协作流程和信息流向，从而完成单人单次对话难以实现的复杂、多视角分析。

5. 性能、成本考量与常见问题排查

将推理过程图化虽然强大，但也引入了新的复杂性和成本。在实际部署中，以下几个问题必须谨慎处理。

5.1 延迟与异步编排优化

一个复杂的GoT图可能包含数十个节点，如果串行执行，总耗时将是所有LLM调用时间的总和，这对于交互式应用是不可接受的。因此，异步并发是必选项。

• 利用框架并发：确保你的Orchestrator充分利用了asyncio.gather等机制来并发执行无依赖关系的操作。
• 理解依赖关系：优化图的设计，最大化可并行执行的路径。减少关键路径上的节点数量。
• 缓存中间结果：对于某些可能被重复使用的、确定性的思维（例如，对固定文档的摘要），可以考虑进行缓存，避免重复调用LLM产生不必要的成本和延迟。

5.2 令牌消耗与成本控制

GoT应用通常是令牌消耗“大户”。一次运行可能涉及几十次LLM调用和数万甚至数十万令牌的吞吐。

• 成本监控：在代码中集成令牌计数功能，对每次调用进行统计。OpenAI等提供商API返回的响应中通常包含使用量信息。
• 策略性降级：如前所述，采用混合模型策略。对于要求不高的“草稿生成”节点，使用便宜模型。
• 压缩与总结：在将某个思维作为输入传递给下一个节点前，考虑是否可以先对其进行压缩或总结，以减少提示词中的令牌数。这本身也可以作为一个“压缩”操作节点加入到图中。
• 设置预算上限：在编排器中实现逻辑，当累计消耗的令牌或估算成本超过某个阈值时，提前终止图的执行或回落到更简单的备用方案。

5.3 典型错误与调试技巧

在开发GoT应用时，你可能会遇到以下典型问题：

调试心法：将GoT应用视为一个数据流管道。最有效的调试方式是“快照”每个Thought节点完成后的状态（内容、分数、元数据），并将其可视化。你可以简单地将图执行过程输出为JSON或通过networkx库生成图像，直观地看到数据是如何在图中流动和演变的，这能帮你迅速定位问题节点。

GoT框架代表了LLM推理编程的一个前沿方向。它将推理过程从黑盒的提示词工程，部分地转变为了白盒的图结构设计。这要求开发者不仅要有LLM应用的经验，还需要具备一定的计算思维和系统设计能力。虽然目前该框架在易用性和工具链成熟度上还有很长的路要走，但它所指向的“结构化、可编程、可引导的LLM推理”未来，无疑充满了潜力。开始动手构建你的第一个思维图，亲自体验这种将复杂思考“可视化”和“自动化”的力量吧。