基于图的计划：迈向可并行的大规模语言模型代理调度

原论文：https://arxiv.org/pdf2502.14563

摘要

大规模语言模型（LLMs）在任务规划推理方面表现出色。然而，对于并行调度的研究仍然不足。本文引入了一种新的范式—— 基于图的计划 ，其中模型首先将现实生活中的文本任务分解为可执行的子任务，并构建抽象的任务图。然后，模型将理解该任务图作为输入并生成一个并行执行的计划。为了增强对复杂、可扩展图的规划能力，我们设计了一个自动化且可控的管道来生成合成图，并提出了一种两阶段训练方案。实验结果表明，我们的 基于图的计划 方法显著提高了基于API的LLMs和开源LLMs的任务性能。通过将复杂任务规范化为图，我们的方法自然支持并行执行，展示了全局效率。代码和数据可在 https://github.com/zsq259/Plan-over-Graph 获取。

1 引言

大规模语言模型的进步促进了代理在复杂交互任务中的出色能力。最近的研究表明，在执行前生成计划可以提高代理的性能，称为 计划-执行框架 。规划整合了全局知识，确保整体连贯性，而不仅仅是局部最优。规划将复杂任务分解为单步操作的子任务，这对于需要复杂工作流和精确动作接口的任务尤为重要，如UI控制和软件工程。

我们任务的一个示例：从现实文本查询到并行计划。计划以图的形式表示。边是可用规则， 住宅区、高架区和基础设施区 是初始源节点， 核心区 是目标节点。实线边表示在时间消耗约束下的最优计划。

尽管取得了令人鼓舞的进展，但计划的并行性仍未得到充分探索。多步骤代理框架通常默认采用阻塞管道，每一步都必须等待上一步完成，无论是否依赖于其结果。链式思维（CoT）显著增强了代理的推理能力，使它们能够分而治之处理复杂任务。尽管推理结构扩展到了树和图，但子任务的操作仍然是顺序进行的。然而，如果子任务之间相互独立，则可以并行运行。虽然最近的研究探讨了异步执行的时间效率，但在实际应用中仍存在差距。

本文深入研究了考虑复杂任务图的代理并行规划问题，如图 1 所示。我们提出了一种新的范式， 基于图的计划 ，代理首先探索规则并提取图，然后根据全局消耗约束在图形结构上进行规划。为此，我们构建了一个涉及并行子任务的复杂任务数据集。每个样本以一个连通有向无环图初始化，标注了源节点和目标节点，以及可行解和最优解。这些图进一步通过提示LLM生成文本描述，最终形成自然语言中的真实任务描述。

为进一步改进我们的 基于图的计划 范式，我们设计了一个可训练的方案。随着图规模的扩大，图理解仍然是代理的挑战，导致性能瓶颈。因此，我们在抽象图上进行了两阶段训练策略。在推理过程中，代理被提示从文本查询中提取图，然后使用训练后的适配器在图上进行规划。我们通过综合指标衡量结果，包括成功率、最优准确性、可行准确性和效率。实验在基于API的LLMs和开源LLMs上均取得了显著的性能提升。我们进一步分析了图结构的可扩展性，展示了并行执行如何提高时间效率，并识别了任务规划中的常见错误。

我们的贡献可以总结如下：

2 相关工作

本节介绍了代理规划和LLMs对图理解的背景。

2.1 LLMs的代理规划

自主代理与环境互动以解决复杂任务。规划涉及在执行前开发行动序列，利用任务和环境的全局知识建议逻辑一致的轨迹。

规划将复杂任务分解并选择基于全局知识的可行轨迹。搜索策略用于探索最优计划，如深度优先搜索、广度优先搜索和蒙特卡洛树搜索。当环境反馈补充感知并更新任务知识时，规划涉及反思以逐步优化轨迹。世界模型或奖励模型整合全局知识，预测环境状态或估计奖励。

2.2 LLMs在图上的应用

由于现实中的复杂挑战可以表示为图，最近的研究探索了LLMs在图上的推理能力。Graph-of-Thought首次提出将问题思考转化为任意图，以生成、聚合和细化子任务。其他研究也从上下文中提取演绎三元组并构建图。知识图谱支持知识密集型任务的忠实性和推理透明性。一些研究结合图与自然语言提示，以推理异步计划，指导模型基于给定图或自动生成图进行推理。

然而，研究表明，随着图规模和复杂性的增加，图推理和理解的能力下降。经验研究表明，随着图大小的增加，出现了“理解崩溃”现象。DARG评估了LLMs在图上的推理能力，并报告了随着图复杂性增加性能下降的情况。

不同于现有工作，我们的论文提供了更正式和可扩展的任务图结构定义，捕捉任务的内在复杂性和依赖关系。我们的 基于图的计划 提供了一个通用框架，独立于任务的具体性质。此外，我们通过在这些图上训练模型展示了该方法的有效性，实现了显著的性能提升。

3 初步：问题陈述

本节形式化了在任务图上的规划问题，并进行了初步分析以识别关键挑战。

3.1 规划的公式化

3.2 规划的挑战

鉴于这些局限，我们设计了一个初步研究的实验。我们构造了100个随机图，节点数分别为10、30、50，要求LLM找到最短路径作为解决方案。表 [tab:preliminary_experiment] 显示了可行路径和最优路径的准确性，随着节点数的增加，性能急剧下降。特别是，50节点图的最优率为仅6%。

这一实验证据表明，核心瓶颈在于在复杂约束下对图拓扑的规划能力。这些发现激励我们优先提高对复杂图的理解能力，以增强规划任务。

4 方法论：基于图的计划

我们提出了 基于图的计划 范式。给定文本查询，LLM被提示收集信息并构建任务图。然后，将任务图作为输入，让模型在其上进行规划。接下来，我们专注于增强 计划 阶段的图理解能力。

在以下章节 4.1 和 4.2 中，我们提出了一种数据构建方法，以自动获取大量可控的图数据。然后，我们设计了一个使用这些图数据的训练管道（第 4.3 节）。最后，我们将这两个步骤结合起来，形成用于推理的 基于图的计划 范式。我们的总体框架如图 [fig:graph_pipeline] 所示。

4.1 抽象任务公式化

首先，我们重新定义了图结构上的规划任务。不失一般性，我们考虑时间限制和成本限制，计划需要最小化总时间或总成本。

4.2 数据模拟

根据上述定义，我们设计了一种自动化、可控且可扩展的管道生成合成数据，包括以下步骤：

4.3 训练方案

在本节中，我们专注于优化模型在抽象图上的能力，提高其并行规划能力。我们的训练分为两个阶段：监督微调和直接偏好优化。

监督微调。 我们在抽象任务数据集上对LLM进行微调。这使模型能够使用问题空间的图表示来解决规划任务。我们使用低秩适应（LoRA）方法，该方法通过学习一个小尺寸的适配器，允许高效地适应大型预训练模型。对于SFT，考虑了两种设置：(i) 使用最优数据实例进行微调。(ii) 为了使模型学习最优和可行解，我们选择了次优解并与最优解混合作为训练数据。

直接偏好优化。 在微调之后，应用直接偏好优化（DPO）以区分最优解和可行解。对于每个样本，次优解作为拒绝输出，而最优解作为选择输出。这一步进一步优化模型优先选择最优解而非可行解的能力。

经过训练后，我们在推理过程中聚合提取和规划步骤。给定带有目标描述的查询，我们首先从描述中提取任务图，然后使用加载的训练适配器在图上生成计划。

5 实验

5.1 数据集

我们合成数据的统计信息见表 [tab:dataset] 。训练集包含12,000个训练实例，平均分布在三个节点规模（10、30、50节点）和随机及基于树的DAG结构中。它采用均匀分布边配置应用于10/30节点图，但限制50节点图为线性缩放。我们为每个节点规模和图结构生成1000个输入实例。每个输入对应一个最优解和一个选定的可行解。测试集包含两个部分：(i) 基准测试，节点数为10、20、30、40、50的线性边缩放图，每个节点数和图结构包含100个实例；(ii) 边变化测试，专门针对10/30节点随机图的均匀分布边，以评估模型在边数变化时对图的理解能力。由于边数变化范围较广，我们生成了1000个实例。

文本查询。 为了系统评估模型在实际任务场景中的并行规划能力并验证我们的 基于图的计划 范式，我们构建了一个评估数据集，利用DeepSeek-R1模型。该数据集合成了200个来自某些现实问题领域的任务，每个任务规范从图转换为可执行的工作流描述。查询数据统计详见附录 9 。

5.2 基准

我们评估了几种基准模型，包括基于API的LLMs GPT-4o 和Claude 3.5 Sonnet ，以及开源LLMs Llama-3.1-8B-Instruct 和Qwen2.5-7B-Instruct 。这些模型因其强大性能和广泛应用而被选中。评估指标详见第 4.1 节。详细设置请参阅附录 10 。

5.3 主要结果

表 [tab:combined_results] 展示了实验结果。我们的结果回答了以下三个关键问题。

Q1: 我们的训练方法能否教LLMs在图上规划？哪种方法能取得最佳性能？ 每个模型的整体结果见表 [tab:combined_results] 的上半部分。总体而言，可以看出 训练大大提高了规划性能，两阶段训练表现更好。 未经训练的Claude展示了较高的成功率（90.0%），但相对较低的最优率（39.2%）。GPT-4o和Llama的成功率相似（51.3%和52.3%），但GPT-4o的最优率（14.1%）高于Llama的1.8%。Qwen在成功率和最优率方面表现较弱（13.2%和0.5%）。

仅在最优解上进行训练显著提高了图理解和规划能力，Llama的成功率达到75.7%，最优率达到61.4%。混合可行解进一步提高了性能至86.1%和67.5%。两阶段训练的最佳结果（71.6%的最优率）来自混合数据的SFT和DPO，保持了83.6%的成功率。这是因为在DPO中，模型更倾向于选择最优解。我们也观察到Qwen的表现有所改善，但仍逊于Llama。

Q2: 图规模的扩展会带来什么现象？ 如图 [fig:combined_results] 上半部分所示，随着节点数量增加，图结构变大，所有模型的整体性能下降。对于时间和成本比率，这些模型对节点数量显示出类似的敏感性。然而，Llama的成本比率明显增加，表明其在更大图上倾向于选择更多子任务。对于成功率，GPT-4o和Llama敏感下降。当节点数量达到30时，GPT-4o甚至低于Llama。然而，Claude和我们训练的模型继续表现出强大的能力，下降幅度较小。Claude在最优率上仍然有10到20个百分点的损失，表明其在更大规模图上的理解存在差距。在所有节点数量下，我们训练的Llama在最优率上显著优于所有其他模型。

图 [fig:combined_results] 下半部分展示了Claude和我们训练的Llama在1000个案例中不同边数下的表现。对于10个节点，由于节点数量较少，两个模型在边缘数量变化上表现出对各项指标的稳健性。对于30个节点，随着边数增加，模型找到最优解的难度显著增加。因此，两者平均时间比率均有所上升。平均成本比率增长不明显，因为图越密集，可行解的数量也增加，允许模型通过选择更少的子任务完成任务，尽管不是最优化的时间。

Q3: 我们的基于图的计划方法能否提高文本查询的规划性能？ 表 [tab:combined_results] 下半部分展示了真实生活查询的结果， 表明我们的基于图的计划方法一致提高了不同模型的性能。 当规划不包括提取时，Claude达到了89.5%的成功率，但在最优率上仅达到14.5%，且时间比率为1.904。Llama的成功率为19%，没有任何最优计划，导致时间比率为3.433。使用我们的基于图的框架后，Claude的最优率提高到41.5%，Llama的成功率也提高到38%，时间比率均有所下降。经过训练用于规划的模型表现出极大的性能提升，在72.5%的最优率和83%的成功率上超过了Claude。

总之，这些结果表明：首先，基于图的计划方法提高了模型性能；其次，对计划进行训练显著增强了模型性能。

6 分析

本节讨论我们的数据集和实验的详细结果。

6.1 图特征

本节讨论(i)我们对图结构的考虑；(ii)图中节点和边数量的变化对模型规划能力的影响。

图结构。 基于树的结构旨在更好地反映现实世界的并行场景，提供更强的层次化组织，有助于生成更合理的具体场景。为确保清晰区分并行和非并行执行，我们实施了以下策略：(i) 控制树的深度以管理分支数量，以及(ii) 将节点分组，使每组中的节点数量不超过前置节点总数的三分之二。此外，我们还使用未定义的随机图结构验证模型的鲁棒性。

节点和边数量的影响 我们计算了四个标准化指标与节点和边数量变化之间的绝对相关系数和斜率。总体而言，边数量的影响小于节点数量。对于节点数量，几乎所有模型的指标都显示出强相关系数，介于0.8到1.0之间。对于10个节点的边变化，两个模型的相关系数较低，均小于0.5，表明对边数量变化具有鲁棒性。然而，在30个节点上，Claude在所有四个指标上的相关系数高于我们训练的Llama，超过0.7，表明其稳定性较低。详情请参阅附录 13 。

6.2 时间效率

我们的任务本质上支持子任务的并行执行，但大多数现有方法在规划过程中未考虑并行性，导致不必要的等待时间。

我们计算了并行执行与顺序执行（即所有子任务持续时间之和）的时间比率。表 [tab:parallel_sequential_ratio] 显示了最优标签和我们训练的Llama及Qwen输出的结果。结果显示，规划并行解决方案的能力可以显著减少时间，尤其在图规模较大时更为明显。具体来说，Llama和Qwen的计划显示了较高的成本比率，表明存在许多冗余子任务。当这些计划按顺序执行时，低效性将进一步放大，导致并行执行时间与顺序执行时间的比率较低。

6.3 错误案例研究

任务图。 抽象图上的错误案例分为两类。(i) 无效子任务 ，即计划包含没有对应转换规则的子任务，以及(ii) 不可用源 ，即子任务所需源在执行期间未实现。后者表明在规划时未能考虑源可用性或依赖关系处理不当。表 1 显示了两种错误类型的比例。经过训练后，源依赖几乎得到了解决，但无效子任务的幻觉目前是性能瓶颈。

文本查询。 子任务基本规则提取失败会损害模型的整体性能。然而，有趣的是，即使有提取错误，如果后续规划未遇到不正确的规则，模型仍然可以正确完成任务。Llama的结果显示，提取步骤显著提高了基线成功率，而训练后的模型成功率略低于Claude，但最优率更高。仔细观察发现，只有15%完全匹配原始图。然而，不匹配情况的平均相似度为82%，表明影响最小。这支持了我们专注于提高模型在抽象图上的规划能力。

7 结论

我们提出了基于图的计划，这是一种增强LLM代理并行规划的新范式。我们的方法将任务依赖关系提取为结构化图，然后通过图感知推理优化并行规划。我们开发了一个带有有向无环图注释的合成数据集，并提出了一种两阶段训练方案。实验结果表明该方法显著改进了性能。我们的分析进一步揭示了图结构对模型性能的反作用以及并行性带来的时间减少。这项工作建立了一个并行代理系统的框架，弥合了抽象图与实际应用之间的差距。

局限性

我们承认本工作的局限性。(i) 虽然我们认为并在验证中证明了图上规划能力比提取更重要，开源模型在提取方面也表现出一定的缺陷。(ii) 在现实中，模型的计划可能是一个与环境交互的动态过程，其中模型可以通过感知细化先前给出的计划。未来的工作将集中在这两个方向。

8 提示模板

以下是提示模板的示例。

您获得了一系列转换规则，每个规则包括源节点（材料或子任务）、目标节点（结果材料或任务）、完成转换所需的时间和与转换相关的成本。您的目标是从初始节点到目标节点制定一条路径，支持并行转换，以尽可能短的时间获取目标节点，同时最小化总成本。

输入格式：

- 转换规则：一个字典列表，每个字典代表一条转换规则，包含：

- source：源节点列表（转换的前提条件）。

- target：目标节点列表（转换的结果）。

- time：完成转换所需的时间（整数）。

- cost：与转换相关的成本（整数）。

- 初始节点：表示起始可用节点的字符串列表。

- 目标节点：需要获取的目标节点的字符串。

输出格式：

- 计划：子任务列表，每个子任务是一个JSON对象，包含以下字段：

- name：子任务或节点完成的名称，默认名称格式为“Subtask”后跟序列号。

- source：参与此子任务的源节点列表。这些源必须是你已经拥有或可以通过前几步获得的产品。

- target：此子任务产生的目标节点。源和目标必须符合给定规则，不能假设或自创。

- dependencies：需要在执行此子任务之前完成的其他子任务名称列表。这确保了子任务之间的执行顺序，并且依赖项必须提供此子任务所需的源。

重要：

- 生成的JSON必须严格遵循JSON格式。以下规则必须严格遵守：

- 所有键和值必须用双引号括起来。

- 数组中的所有元素必须用逗号分隔。

- JSON中的所有字段必须完整且正确格式化，不得缺少或错误的元素。

- 所有计划步骤必须符合给定规则。

- 所有涉及的物质必须符合给定规则。

您的任务是按照指定的JSON格式生成最终计划，最小化完成时间和总成本。不要提供任何实现代码。

以下是一个示例，以便更好地理解任务：

{graph_planning_example}

现在，基于以下转换规则、初始节点和目标节点，请提供一个最优计划，允许目标节点在最短时间内以最小总成本获得，支持并行转换。

仅包括必要的步骤，以最快的速度和最少的成本完成。不要添加任何额外或冗余的转换步骤。

任务：

“‘json

{task}

“‘

您的任务是按照指定的JSON格式生成最终计划。不要提供任何实现代码。

对于输入任务，请提供一个允许目标获得的最优计划。在最短时间内最小化成本。

没有依赖关系的项目可以并行完成以提高整体效率。

请以JSON格式提供最终解决方案：

- Plan：子任务列表，每个子任务是一个JSON对象，包含以下字段：

- name：子任务或节点完成的名称。默认名称格式为“Subtask”后跟序列号。

- source：与此子任务相关的源节点列表。源必须是你已经拥有或可以通过前几步获得的产品。

- target：此子任务产生的目标节点。源和目标必须符合给定规则，不能假设或自创。

- dependencies：需要在此子任务执行之前完成的其他子任务名称列表。这确保了子任务之间的执行顺序，并且依赖项必须提供此子任务所需的源。以下是一个示例：

输入：

{query_example}

输出：

“‘json

{query_example_plan}

“‘

输入：

{task}

输出：

“‘

任务：从非结构化的流程叙述中提取结构化的转换规则。目标：识别文本中所有节点之间的转换。对于每个转换，提取：

- 源节点（前提条件）

- 目标节点（结果）

- 时间（持续时间）

- 成本（数值资源单位）

另外，确定初始源（起始节点）和目标（最终节点）。

输入：描述工作流过程的故事。示例短语可能包括：

- “从[NodeA]，在X天内以Y单位成本到达[NodeB]”

- “当[NodeA]和[NodeB]都准备好时，可以在X天内以Y单位成本完成[NodeC]”

- 快捷方式：“直接从[NodeA]到[NodeC]，在X天内以Y单位成本”

输出：

一个JSON对象，包含：

1. "rules": 转换规则列表，每个规则包含：
   - "id"（从0开始的连续整数）
   - "source"（节点ID列表，例如["N1"]）
   - "target"（节点ID列表，例如["N2"]）
   - "time"（数值）
   - "cost"（数值）
2. "initial_source"：起始节点ID列表（例如["N1"]）
3. "target"：最终节点ID（例如"N8"）

您的任务：将以下故事转换为上述JSON格式。确保：

1. 捕获所有转换，包括多源依赖和快捷方式
2. 节点ID（如N1、N2）保持原样
3. 时间和成本值严格为数值
4. 严格遵循JSON模式

示例输入故事：

{query_example}

示例输出：

“‘json

{query_example_plan}

“‘

输入故事：

{task}

输出：

将这个抽象任务转化为现实生活中的具体任务，注意以下几点：

1. 没有依赖关系的任务可以并行执行。
2. 请用完整的自然语言表达指令，不要显式列出规则。
3. 只要有一条路径能达到最终目标，即视为成功。
4. 必须在完成规则的所有前提条件后才能进行规则并获得其目标。
5. 必须严格遵循我提供的规则，确保你的故事中的规则与我提供的规则一一对应，且你故事中的规则总和等于任务中的规则总和。
6. 明确提到每个规则所关联的时间和成本。
7. 只需写规则作为故事，无需提供任何附加评价或介绍。

以下是一个参考示例：

输入： “‘json

{query_example_plan}

“‘

输出：

{query_example}

输入：

“‘json

{task}

“‘

输出：

任务：

“‘json

{ "rules": [ { "source": ["N1"], "target": ["N2"], "time": 3, "cost": 1 }, { "source": ["N6"], "target": ["N3"], "time": 4, "cost": 1 }, { "source": ["N2", "N3"], "target": ["N4"], "time": 2, "cost": 1 }, { "source": ["N4"], "target": ["N5"], "time": 1, "cost": 1 }, { "source": ["N2"], "target": ["N5"], "time": 5, "cost": 1 } ], "initial_source": ["N1", "N6"], "target": "N5" }

“‘

预期输出：

“‘json

[ { "name": "Subtask1", "source": ["N1"], "target": ["N2"], "dependencies": [] }, { "name": "Subtask2", "source": ["N6"], "target": ["N3"], "dependencies": [] }, { "name": "Subtask3", "source": ["N2", "N3"], "target": ["N4"], "dependencies": ["Subtask1", "Subtask2"] }, { "name": "Subtask4", "source": ["N4"], "target": ["N5"], "dependencies": ["Subtask3"] } ]

在一个繁忙的城市建设项目中，多个站点必须协调以尽快且经济地建造“核心区(N9)”。项目从三个站点开始：“基础设施(N1)”、“高架区(N3)”和“住宅区(N7)”，每个站点有不同的任务。“基础设施区(N1)”需要3天和1个单位成本才能进入“桥区(N2)”，而“高架区(N3)”则需要3天和1个单位成本进入“建筑区(N4)”。桥区(N2)连接到“道路区(N5)”需要4天和1个单位成本，可以直接连接到“设施区(N6)”需要8天和1个单位成本。“建筑区(N4)”与“道路区(N5)”合作，在2天和1个单位成本内建造“设施区(N6)”。“住宅区(N7)”需要5天和1个单位成本才能到达“市中心区(N8)”，而“建筑区(N4)”可以直接在1天和1个单位成本内到达它。一旦“设施区(N6)”和“市中心区(N8)”准备就绪，它们结合在一起，在2天和1个单位成本内完成“核心区(N9)”。“基础设施区(N1)”有一个捷径，可以直接绕过其他区域，在15天和1个单位成本内到达“核心区(N9)”。项目团队可以根据资源和进度选择最有效的路线。

{"rules": [{ ’id’: 0, "source": ["N1"], "target": ["N2"], "time": 3, "cost": 1 }, { ’id’: 1, "source": ["N3"], "target": ["N4"], "time": 3, "cost": 1 }, { ’id’: 2, "source": ["N2"], "target": ["N5"], "time": 4, "cost": 1 }, { ’id’: 3, "source": ["N4", "N5"], "target": ["N6"], "time": 2, "cost": 1 }, { ’id’: 4, "source": ["N2"], "target": ["N6"], "time": 8, "cost": 1 }, { ’id’: 5, "source": ["N7"], "target": ["N8"], "time": 5, "cost": 1 }, { ’id’: 6, "source": ["N4"], "target": ["N8"], "time": 1, "cost": 1 }, { ’id’: 7, "source": ["N6", "N8"], "target": ["N9"], "time": 2, "cost": 1 }, { ’id’: 8, "source": ["N1"], "target": ["N9"], "time": 15, "cost": 1 }, ], "initial_source": ["N1", "N3", "N7"], "target": "N9"}

“‘

9 文本查询统计

图 2 展示了我们合成查询数据的统计信息。

我们合成查询的统计信息。左侧柱状图显示了标记分布。右侧饼图显示了主题分布。

10 训练设置

训练使用LLaMa Factory框架。

SFT的训练损失函数定义如下：

DPO的训练损失函数定义如下：

详细的超参数设置见表

11 边变化状态

Claude和我们训练的Llama在不同边数下的表现。纵轴表示每个状态（失败、可行、最优）的相应案例数。横轴表示在一定区间分割的边数。

12 查询示例

一个现实生活场景中的查询及其对应的计划见 [sec:examples] 。

13 实验补充

表 [tab:model_metrics_node] 和 [tab:model_metrics_edge] 展示了节点和边数量变化时四个标准化指标的绝对相关系数和斜率。

所有结果保留两位小数进行最终报告。