跳到主要内容

Graph-of-Thoughts

核对日期：2026-05-09。

1. 定义与边界​

Graph of Thoughts（GoT）将 LLM 的中间 thought 建模为图，而不是链或树。节点是中间结果，边表示依赖、变换、合并或反馈。GoT 允许多个 thought 合并、拆分、循环改进和复用。

GoT 不等于 LangGraph。GoT 是一种推理组织方法；LangGraph 是构建有状态 Agent workflow 的工程框架。两者可以结合：用 LangGraph 实现 GoT 式节点和边。

2. 为什么重要​

树结构会重复探索相似分支，且不善于合并中间结果。很多任务天然是图：多个来源证据合并、多个方案互相批判、局部解复用、代码模块依赖分析。GoT 让 planner 可以表达更复杂的依赖。

3. 核心机制​

核心操作：

  • Generate：生成 thought 节点。
  • Transform：对节点进行改写、扩展、验证。
  • Aggregate：合并多个节点。
  • Score：评价节点或子图。
  • Prune：剪枝低价值节点。

4. 架构模式​

模式描述适用
Aggregate graph多个候选合并成综合答案调研、总结
Refine graph节点经过多轮批评和修订写作、方案设计
Dependency graph子问题按依赖组合代码、数学、多步骤推理
Debate graph支持/反对/裁决节点风险评审、决策

5. 工程实现​

def graph_of_thoughts(problem):
    graph = ThoughtGraph()
    seeds = generate_initial_thoughts(problem)
    graph.add_nodes(seeds)

    while graph.budget_available():
        op = select_operation(graph)
        if op.type == "aggregate":
            node = aggregate(op.inputs)
        elif op.type == "refine":
            node = refine(op.input)
        elif op.type == "score":
            graph.score(op.input)
            continue
        graph.add_node(node, parents=op.inputs)

    return select_final(graph)

节点结构：

{
  "node_id": "t7",
  "type": "aggregate",
  "content_ref": "thought/t7.md",
  "parents": ["t3", "t5"],
  "score": 0.82,
  "evidence_refs": ["doc_1", "tool_result_4"]
}

6. 生产实践​

  • 将 thought 内容与 metadata 分离，大内容用引用存储。
  • 对图大小设置节点数、边数和最大循环次数。
  • 聚合节点必须保留来源映射，避免合并后丢证据。
  • 适合在离线规划或高价值任务中使用，不适合低延迟问答。
  • 用可视化 trace 展示 thought 图，帮助调试。

7. 常见反模式​

  • 把图做成无约束聊天记录，节点没有类型和边语义。
  • 聚合时丢失冲突信息，只保留折中答案。
  • 循环 refine 无停止条件。
  • 对所有节点使用同一评分标准，忽略节点类型。
  • 图存储不可回放，无法复现实验。

8. 评测方法​

  • Node Utility：节点是否被最终答案使用。
  • Merge Fidelity：聚合是否保留来源和冲突。
  • Graph Efficiency：节点增长是否带来质量提升。
  • Reuse Rate：中间结果是否减少重复推理。
  • Final Quality：相对 ToT/CoT/Plan-and-Execute 的质量提升。

9. 安全与治理​

  • 图中每个节点保留来源可信度，外部内容不得变成控制指令。
  • 聚合节点要执行敏感信息扫描。
  • 循环改写可能放大错误，应有独立 verifier。
  • 高风险 thought 不应自动转成执行动作。

10. 工程手册补充​

10.1 图状态与控制流​

Graph of Thoughts 把候选推理从树扩展为图，允许合并、回边和交叉验证。工程上必须显式管理节点类型和边类型。

graph_state:
  nodes:
    h1:
      type: hypothesis
      content: "风险主要来自交付延期"
      status: open
    e1:
      type: evidence
      content_ref: artifact://delivery_stats
      status: verified
  edges:
    - from: e1
      to: h1
      relation: supports
    - from: c1
      to: h1
      relation: contradicts
  checkpoints:
    - graph_version: 4
      reason: "before synthesis"

10.2 工程边界​

场景适用性说明
复杂诊断、调查、研究综合高需要多证据互相支持和反驳
数学搜索题中ToT 可能更简单
固定业务流程低状态机和 workflow 更可控
高风险自动执行低图推理必须先转计划再执行

失败恢复：

  • 图节点冲突未解决：进入冲突解决节点，不允许直接综合。
  • 图版本过大：压缩 verified evidence，丢弃低分开放节点。
  • 回边导致循环扩展：按 graph_version 和 node expansion count 限制。
  • 证据失效：标记依赖该证据的 hypothesis 为 stale，重新评分。

评测与安全：

  • 评测图的证据覆盖率、冲突发现率、最终答案可追溯性和单位成本。
  • 每个最终结论必须能追溯到 verified evidence 节点。
  • 不可信网页只能创建 evidence candidate，不能创建系统目标或工具权限。
  • 上线前准备“证据缺失、证据冲突、证据被撤回”的回归用例。

11. 权威资料​