属性引导的LLM规划程序综合

# 属性引导的大语言模型规划程序合成 来源: https://arxiv.org/html/2605.16142 André G. Pereira 巴西南里奥格兰德联邦大学 & Augusto B. Corrêa 牛津大学 英国 & Jendrik Seipp 林雪平大学 瑞典

###### 摘要

大语言模型 (LLM) 在程序合成中展现了令人瞩目的成功，发现了超越先前已知解决方案的程序。然而，这些方法依赖简单的数值分数来表示程序质量，例如解的值或通过的测试数量。由于这种分数无法说明程序*为何*失败，系统必须针对每个问题生成并评估大量候选程序，寄希望于其中一些能够成功，这既增加了 LLM 的推理成本，也增加了评估成本。我们研究了一种不同的方法：属性引导的 LLM 程序合成。我们不是在评估后对程序进行评分，而是检查候选程序是否满足一个形式化定义的属性。当属性被违反时，我们提前停止评估，并向 LLM 提供一个具体的反例，精确展示程序是如何失败的。这种反馈大幅减少了程序生成次数和评估成本，并能引导 LLM 生成更强的程序。我们在 PDDL 规划领域上评估了这种方法，要求 LLM 合成*直接*启发式函数：每个可以通过严格改进的转移达到的状态，都有一个严格改进的后继。具有此属性的启发式函数引导爬山算法直接到达目标状态。一个反例引导的修复循环会生成一个候选程序，在训练集上检查该属性，并返回第一个违反属性的情况。我们在十个规划领域上评估了我们的方法，并使用了一个分布外测试集。合成的启发式函数实际上在几乎所有测试任务上都是*直接*的，并且与最佳的前代方法相比，我们的方法每个领域平均生成的程序数量少七倍，无需搜索即可解决更多任务，并且评估候选程序所需的计算量要少几个数量级。每当一个问题具有可验证的属性时，属性引导的 LLM 程序合成可以减少合成和评估成本，同时提高程序质量。

## 1 引言

使用大语言模型 (LLM) 进行*程序合成*所产生的程序超过了先前已知的解决方案，涉及的问题范围从竞赛编程[36 (https://arxiv.org/html/2605.16142#bib.bib36)]、开放数学问题[50 (https://arxiv.org/html/2605.16142#bib.bib50)]，到算法发现[42 (https://arxiv.org/html/2605.16142#bib.bib42),39 (https://arxiv.org/html/2605.16142#bib.bib39),62 (https://arxiv.org/html/2605.16142#bib.bib62),16 (https://arxiv.org/html/2605.16142#bib.bib16),12 (https://arxiv.org/html/2605.16142#bib.bib12)]。这些方法使用简单的数值分数来对候选程序进行排序，例如解的平均值或通过的测试数量。由于这种分数无法说明程序*为何*失败，系统必须针对每个问题生成并评估大量候选程序，寄希望于其中一些能够成功，这既增加了 LLM 的推理成本，也增加了评估成本。形式化方法中有一个思想，用更具信息量的东西来替代这个适应度分数：*反例引导的归纳合成* (CEGIS)[57 (https://arxiv.org/html/2605.16142#bib.bib57),35 (https://arxiv.org/html/2605.16142#bib.bib35),1 (https://arxiv.org/html/2605.16142#bib.bib1)]。一个验证器检查每个候选程序是否满足形式化规约，如果失败，则返回一个候选程序出错的具象输入；然后合成器可以利用该证据来修复或丢弃该候选程序，而不是使用一个简单的数字。CEGIS 支撑了许多经典的编程范式合成，但在 LLM 中却鲜有使用。我们在一个 CEGIS 风格的循环中使用 LLM 作为合成器，并使用属性检查器作为验证器。对于每个失败的候选程序，我们向 LLM 提供一个具体的反例，说明程序出错的位置和原因，这使我们能够在属性被违反时立即停止评估。这减少了 LLM 需要生成的候选程序数量，并引导其生成更强的程序。

我们在*经典规划*[26 (https://arxiv.org/html/2605.16142#bib.bib26)]上评估了这个想法，这是一个已知对 LLM 具有挑战性的问题[64 (https://arxiv.org/html/2605.16142#bib.bib64),63 (https://arxiv.org/html/2605.16142#bib.bib63),59 (https://arxiv.org/html/2605.16142#bib.bib59)]。给定一个规划领域，我们要求 LLM 以 Python 代码形式合成一个*启发式函数*，然后自动将其注入到规划器中。理想情况下，这样的启发式函数能够引导爬山算法从初始状态出发，永不停滞地到达目标，无需任何组合搜索即可解决问题。为了形式化地捕捉这一要求，我们的目标是*直接*属性[19 (https://arxiv.org/html/2605.16142#bib.bib19)]：如果一个启发式函数满足，从初始状态出发，任何通过严格改进转移可达的状态，都具有一个严格改进的后继，则该启发式函数是直接的。这个属性非常适合属性引导的合成，因为任何违反都会立即产生一个具体的反例。合成一个直接启发式函数在理论上[32 (https://arxiv.org/html/2605.16142#bib.bib32),19 (https://arxiv.org/html/2605.16142#bib.bib19)]和实践中[例如，24 (https://arxiv.org/html/2605.16142#bib.bib24)]都具有挑战性：它需要对每条严格改进路径上的每个状态进行推理，而单个没有改进后继的状态就足以破坏该属性。事实上，为给定任务合成一个直接启发式函数与解决该任务本身一样困难。

我们的反例驱动修复循环以 PDDL（规划领域定义语言）领域以及来自该领域的一组训练 PDDL 任务作为输入，并在训练集上验证直接属性。验证一旦发现反例便终止。在这种情况下，我们向 LLM 提供失败的任务和反例：属性失败的状态、其启发式值，以及具有其启发式值的后继状态。要求 LLM 提供一个对该任务来说是直接的新启发式函数。这个循环重复进行，直到启发式函数通过整个训练集。尽管验证仅限于训练任务，但我们希望合成的启发式函数能够泛化，在更难的、分布外的测试任务上仍然保持直接性。图1 (https://arxiv.org/html/2605.16142#S1.F1) 展示了这一过程。据我们所知，我们的工作首次使用 LLM 通过属性引导修复来合成启发式函数。在来自 IPC 2023[60 (https://arxiv.org/html/2605.16142#bib.bib60)] 学习轨道 (Learning Track) 的十个规划领域上，使用分布外测试集进行评估，我们的方法每个领域平均生成的程序数量比最佳的前代方法[16 (https://arxiv.org/html/2605.16142#bib.bib16)] 少七倍，评估候选程序所需的计算量显著减少，并且通过爬山算法在不进行任何组合搜索的情况下解决了更多任务。我们的修复循环总是在迭代预算内找到一个对每个训练任务都是直接的启发式函数，并且合成的启发式函数在几乎所有分布外的测试任务上仍然保持直接性，证实了该属性可以泛化到训练集之外。

![图1](https://arxiv.org/html/2605.16142/x1.png)
图 1: 反例驱动的属性引导启发式函数合成修复循环。给定一个规划域和一个来自训练集的任务，LLM 用 Python 提出一个候选启发式函数。验证器在训练集上评估该启发式函数，验证*直接*属性。如果满足该属性，则输出有效的启发式函数。如果违反该属性，评估提前停止，并返回一个具体的反例。

## 2 背景

![图2a](https://arxiv.org/html/2605.16142/x2.png)
图 2a: 下降启发式函数：每一个活跃状态至少有一个严格改进的后继，包括状态 a，该状态永远不会被 GBFS 或 HC 扩展。

![图2b](https://arxiv.org/html/2605.16142/x3.png)
图 2b: 直接启发式函数：同一个状态空间使用不同的启发式函数，允许一条严格改进路径 (s0 → b → d → g)，但状态 a 是一个平台 (h(a) = h(s0))。

*经典规划*要求在一个完全可观测、离散、单一智能体的环境中，找到一个确定性动作序列，即一个*规划*，将给定的初始状态转变为满足目标的状态。规划任务通常用规划领域定义语言 (PDDL)[40 (https://arxiv.org/html/2605.16142#bib.bib40),30 (https://arxiv.org/html/2605.16142#bib.bib30)] 来描述，我们的工作直接使用这种表示法。一个 PDDL 任务由一组*对象*和*谓词*定义。它们共同构成*ground atoms*，即用具体对象实例化的谓词，用于描述当前状态。*动作*具有前提条件，必须满足才能执行该动作，并具有效果，可以添加或删除状态中的 ground atoms。任务还指定了一个*初始状态* s0 和一个*目标*。PDDL 将*领域*（共享的动作和谓词）与*任务*（特定的对象、初始状态和目标）分开，通常存储在两个不同的文件中。我们考虑*满足式规划*，即任何规划都是可接受的，无论其长度如何，并且我们假设所有动作都具有单位成本。

大多数满足式规划器基于*贪婪最佳优先搜索* (GBFS)[47 (https://arxiv.org/html/2605.16142#bib.bib47),8 (https://arxiv.org/html/2605.16142#bib.bib8),33 (https://arxiv.org/html/2605.16142#bib.bib33),31 (https://arxiv.org/html/2605.16142#bib.bib31),49 (https://arxiv.org/html/2605.16142#bib.bib49),37 (https://arxiv.org/html/2605.16142#bib.bib37)]，这是一种状态空间搜索算法，由*启发式函数* h 引导，该函数将每个状态 s 映射到一个值 h(s) ∈ ℝ ∪ {∞}，估计从 s 到达目标的成本[46 (https://arxiv.org/html/2605.16142#bib.bib46)]。无限值表示从 s 无法到达目标。GBFS 从 s0 开始，维护一个已生成状态的优先队列，按启发式值排序。每一步，它*扩展*最有希望的状态 s，即具有最小启发式值 h(s) 的状态，生成其后继 succ(s) 并将其加入开放列表。此过程一直持续，直到达到目标状态。GBFS 是完备的：只要所有生成的状态最终都会被扩展，则如果解存在，无论启发式函数如何，它最终都会找到解。

与 GBFS 的全局特性相反，*爬山算法* (HC) 是一种简单的局部搜索算法：从初始状态开始，它贪婪地移动到具有严格较小启发式值的后继，并在达到目标状态时终止。由于 HC 不维护开放列表，因此非常节省内存。然而，HC 是不完备的：它可能失败于*平台*（没有后继能严格改进启发式值）或*局部最小值*（每个后继都有更大的启发式值），即使目标是可达的。因此，HC 的完备性取决于启发式函数。

一个*下降且避免死胡同*的启发式函数[54 (https://arxiv.org/html/2605.16142#bib.bib54)]通过构造消除了这两种失败模式。遵循 Seipp 等人 [54 (https://arxiv.org/html/2605.16142#bib.bib54)] 的说法，如果一个状态是可达的、可解的、且不是目标状态，我们称之为*活跃*状态。

###### 定义 1 (下降且避免死胡同的启发式函数[54 (https://arxiv.org/html/2605.16142#bib.bib54),32 (https://arxiv.org/html/2605.16142#bib.bib32)])。对于规划任务 Π，如果每个活跃状态 s 至少有一个后继 s' ∈ succ(s) 满足 h(s') < h(s)，则启发式函数 h 是*下降*的（Definition2）。此外，如果对于每个活跃状态 s，都有 h(s) < ∞，则它也是*避免死胡同*的（Definition3）。如果同时满足这两个条件，则 h 是*下降且避免死胡同*的。

下降且避免死胡同的启发式函数保证了 HC 的完备性：从任何活跃状态，总是存在一个严格改进的后继，因此 HC 永远不会停滞，最终到达目标。然而，这个条件可能比保证 HC 成功所需的更强。一个更弱、但仍然充分的属性是*直接*属性[19 (https://arxiv.org/html/2605.16142#bib.bib19)]。与需要每个活跃状态都有一个改进后继的下降属性不同，直接属性只要求每个从初始状态通过严格改进转移可达的状态都有一个改进后继。这允许在仅通过非严格改进转移可达的状态上存在平台或局部最小值。

###### 定义 2 (直接启发式函数[19 (https://arxiv.org/html/2605.16142#bib.bib19)])。令 H = {s | s 可以通过严格改进转移序列从 s0 到达}，即通过严格改进转移从初始状态可达的状态集合。如果每个状态 s ∈ H 都有一个严格改进的后继 s' ∈ succ(s)（即 h(s') < h(s)），则启发式函数 h 是*直接*的。目标状态被视为空满足。

图 2 展示了同一状态空间的下降和直接启发式函数。注意，对于直接启发式函数，状态 a 不会违反该属性，因为它不在 H 中：从 s0 出发，没有严格改进的路径到达 a——s0 的改进后继只有 b 和 c。下降启发式函数也要求 a 有一个改进后继。因此，直接属性弱于下降属性。

## 3 方法：反例驱动的启发式函数修复

我们的方法，反例驱动的启发式函数修复 (CDHR)，由两个主要的 LLM 提示阶段组成：*初始生成*和*修复*。这些提示采用三个组件的元组：PDDL 领域文件的内容、修改后的 Python 骨架导入，以及特定于提示的组件（例如，先前的启发式函数、反例）。初始生成提示提供了领域和修改后的 Python 骨架导入。该提示还包含基于用户的引导，描述启发式函数的目标。我们将完整的提示模板包含在附录 A 中。

### 3.1 验证循环

验证循环在训练任务集合上迭代评估候选启发式函数。对于每个训练任务，它执行深度受限的深度优先搜索 (DFS)，以检查直接属性。DFS 从初始状态 s0 开始，仅通过严格改进转移（即 h(s') < h(s)）进行探索（*严格改进扩展*）。深度限制防止验证在具有循环路径的任务中无限制地探索。如果搜索遇到任何没有严格改进后继的状态（除了目标状态），则该状态是一个反例，验证立即停止。如果对于所有训练任务，没有发现这样的反例，则启发式函数被认为是直接的，并被确认。如果发现反例，一个特殊的修复提示将被组装。

### 3.2 修复提示

修复提示包括：
*   当前候选启发式函数的代码。
*   失败的特定任务。
*   引导 LLM 进行正确修复的反例。该反例包含：(1) 违反属性的状态（*失败状态*），(2) 该状态的启发式值，(3) 失败状态的所有后继，以及 (4) 每个后继的相应启发式值。
*   一个基于用户的消息，明确指出属性的要求，并强调所有由严格改进扩展可达的状态必须有一个严格改进的后继。

这个详细的反馈旨在精确地指导 LLM 确定其启发式函数中需要修改的内容。

*[fix: action sequence]*

### 3.3 与先验工作的比较：避免死循环的启发式函数

我们与先前的 LLM 引导启发式函数合成工作[16, 12, 18] 进行比较，这些工作使用*避免死循环*属性[54]。避免死循环的启发式函数要求对所有生成的状态 h(s) ≠ ∞。这与我们的直接属性不同，避免死循环的启发式函数不保证改进的后继，可能导致爬山算法在非目标状态停滞。将这一先验方法与 CDHR 进行比较，可以评估专门针对直接属性的反馈是否能够比单纯要求避免死循环产生更有效的搜索指导。

## 4 实验设置

### 4.1 领域和数据集

我们在 IPC 2023 学习轨道的十个规划领域上评估 CDHR[60]。这些领域跨越不同的规划范例，包括经典谜题（如 blocksworld）、机器人路径规划（如 visitall）和物流（如 delivery）。对于每个领域，IPC 提供了一个由 1000 个随机生成的训练实例和一个由 100 个更难实例组成的保留测试集（*分布外*/分层任务）。我们从训练集中采样一小部分（10 或 20 个任务）用于我们的验证循环。为了衡量泛化能力，我们报告在全部 100 个测试任务上的性能。我们选择这些领域是因为它们的标准基准性质和与[16] 的直接可比性。

### 4.2 基线和变体

我们将 CDHR 与几个基线进行比较，以隔离我们方法中不同组件的贡献：
1.  **避免死循环 (DEADFREE)** [16]：这种方法合成一个避免死循环的启发式函数。它使用一个基于搜索的评估器，为每个生成的候选程序计算一个质量分数。在最终输出之前，每个领域生成和评估多个候选程序。
2.  **无反馈**: 仅使用初始提示，不进行修复循环。
3.  **无属性**: 修复循环不提供具体的反例反馈；它仅使用标准修复提示，指示启发式函数在训练任务上失败。
4.  **Orphan**: 修复循环提供反例，但仅报告失败状态及其启发式值，略去后继和目标的启发式值。

### 4.3 指标

我们通过以下方式评估生成的启发式函数的性能：(a) 被直接属性验证的训练任务比例；(b) 使用爬山算法 (HC) 解决测试任务的覆盖率，允许最多 100,000 次扩展；(c) 如果 HC 失败，使用并行贪婪最佳优先搜索 (GBFS) 作为后备，允许总共 10,000 次扩展；(d) 生成满足直接属性的程序所需的*候选项数量*；(e) 验证所需的计算成本（状态扩展次数）。对于 DEADFREE，我们报告其文献中的覆盖率。[16] 在文献中仅报告 HC 的覆盖率。

## 5 结果

### 5.1 CDHR 在所有领域中实现了有效的直接性

结果显示在表 1 中。在测试集上，CDHR 对几乎所有的任务实现了直接属性。在 9 个领域上，CDHR 在 100% 的测试任务上是直接的。唯一的例外是 *floortile*，覆盖率下降到 95%。分析表明，这些失败源于泛化差距：测试任务包含训练集中未见的结构模式（例如，更复杂的目标配置）。尽管存在这个差距，95% 的覆盖率仍然很高。总体而言，这表明 CDHR 成功地在训练任务上验证了直接性，并且该属性很好地泛化到更难的、分布外的实例。

### 5.2 CDHR 在没有搜索的情况下解决了更多的任务

图 4 展示了 CDHR 在减少对组合搜索的依赖方面的优势。在 8 个领域中，CDHR 通过单纯的 HC 解决了 100% 的测试任务；对于 *floortile* 和 *pipesworld*，HC 分别解决了 82% 和 97%。这与 DEADFREE [16] 对比明显，DEADFREE 仅通过 HC 解决了 60-95% 的任务。直接属性确保了 HC 永远不会停滞，从而提高了无需任何搜索的规划效率。

### 5.3 CDHR 所需的候选项和评估显著更少

该方法是高效的。在生成满足该属性的最终程序之前，CDHR 在每个领域平均需要 *3.4* 次 LLM 调用（包括初始生成和平均 2.4 次修复迭代），即 *3.4* 个程序。相比之下，DEADFREE [16] 平均生成 *23.7* 个程序。这代表生成减少了 7 倍。此外，由于验证在遇到反例时提前停止，CDHR 的评估成本（状态扩展）比 DEADFREE 低几个数量级。

### 5.4 反例反馈的必要性

“无反馈”基线经常无法满足直接属性（在几个领域上低至 0%）。虽然它有时能管理*避免死循环*，但*直接*是更严格的要求。“无属性”基线也挣扎，因为“程序失败”的模糊反馈不足以引导 LLM 进行有针对性的修复。最后，“孤儿”变体（仅失败状态，无后继信息）性能显著下降，表明*为什么*失败以及如何改进的后继上下文细节对于有效修复至关重要。

### 5.5 领域特定分析

在 *blocksworld* 上，我们的循环平均需要 3.3 个程序才能达到验证标准。典型的修复迭代涉及 LLM 逐渐调整启发式函数，以避免早期迭代中基于距离的度量所产生的平台。在 *delivery* 上，由于需要复杂的距离推理，早期迭代产生高失败率，但 LLM 通过调整对包裹和位置的目标距离相对权重的理解来适应。*gripper* 等较简单的领域更快收敛，往往在一次迭代内实现直接性。

## 6 相关工作

我们的工作处于规划、形式化方法与 LLM 程序合成的交叉点。使用 LLM 进行程序合成是一个活跃的领域[36, 50, 39, 62, 5, 20]。最近的工作探索了 LLM 用于代码修复和改进[14, 15, 4]，但通常没有利用正式的反例。从失败中学习一直是 LLM 基于规划工作的主题[64, 63, 59, 44]，但通常侧重于给定规划器中的动作顺序，而不是合成规划知识。我们使用 PDDL 实例进行启发式函数合成，源于先前的尝试，这些尝试使用 LLM 生成领域特定的启发式函数，使用诸如避免死循环之类的属性[16, 12]。我们的工作通过直接属性在属性引导修复和更好的搜索指导方面扩展了这些方法。

CEGIS 是经典程序合成中的核心思想，从示例（CEGIS）[57] 或更强的规约（例如，SyGuS[1, 35]）中学习。虽然 CEGIS 传统上用于搜索逻辑程序，但我们证明了其在 LLM 引导的 Python 代码生成中的潜力，当问题具有可验证的属性时。我们的工作补充了最近使用 LLM 进行形式化验证的工作，这些工作将 LLM 专门用于优化相关但不同的任务[51, 11, 10, 9]。使用反例进行 LLM 修复在竞争性编程等应用程序中被探索[38, 7, 61, 58]；我们的工作将其扩展到规划，其中属性是状态空间搜索的动态属性，而不仅仅是测试通过。

## 7 结论

我们提出了属性引导的 LLM 程序合成，这是一类方法，其中 LLM 生成候选程序，并进行检查是否符合形式化规约。当违反属性时，提供一个具体的反例，实现早期终止。我们通过将其实例化为反例驱动的启发式函数修复 (CDHR) 来展示其有效性，其中 LLM 合成*直接*规划启发式函数。CDHR 在 10 个规划领域上始终生成几乎对所有分布外任务都保持有效的直接启发式函数。与之前最好的方法相比，它每领域使用的程序生成减少 7 倍，评估成本低几个数量级，并且解决了更多无搜索的任务。
*******
*[以下部分似乎包含示例 LLM 反馈日志，因为它们是评论/提示风格。需要根据源文本决定是否保留其确切文本块。它们看起来是结构化日志，可以使用与用于代码相同的格式保留，但应完全翻译成中文，因为它们是文本日志消息。注意保留变量、占位符（如 h=3）的英文。]*

### A. 解决 blocksworld 领域

*我们注意到 blocksworld 领域特别适合说明反例驱动修复的方法。我们提供合作者获得的此日志，以说明循环的性质。这演示了迭代修复过程，该过程需要少量程序才能达到直接属性。*

**用户提示:**

> 你是一名非常熟练的 AI 规划研究员和熟练的 Python 程序员，正在为 PDDL 领域 blocksworld 创建领域相关的启发式函数。生成一个修订后的启发式函数，其中，通过深度优先搜索可达的每个非目标状态（该搜索仅扩展严格改进的后继），无论操作符的应用顺序如何，都至少具有一个改进的后继。该启发式函数使用深度优先搜索 (DFS) 进行验证，该 DFS 在每个步骤强制执行直接属性：
> - 仅探索后继 h(s') < h(s)。
> - 如果任何状态没有严格改进的后继，则失败。
>
> 属性检查条件:
> 1. 活跃状态：从初始状态可达、可解且非目标。
> 2. 改进的后继：后继 s' 满足 h(s') < h(s)。
>
> **迭代 0:**
> - 提示类型: 初始
> - 已解决 5 个实例 (平均扩展节点数: 2.4)
> - 直接性在 5 个任务上验证 (最后一个索引: 4)
> - 失败分析:
>   失败类型: 属性
>   失败任务: p06.pddl
>   属性失败类型: 直接
>   状态: ['(clearb1)', '(clearb2)', '(holdingb3)', '(on-tableb1)', '(on-tableb2)']
>   启发式值: 3
>   原因: 状态 h=3，但没有任何后继的 h<3。
>   后继:
>     1. 动作 = (stack b3 b2), h=6, 添加 = ['(clearb3)', '(on b3 b2)', '(arm-empty)'], 删除 = ['(holdingb3)', '(clearb2)']
>     2. 动作 = (stack b3 b1), h=6, 添加 = ['(clearb3)', '(on b3 b1)', '(arm-empty)'], 删除 = ['(holdingb3)', '(clearb1)']
>     3. 动作 = (putdown b3), h=4, 添加 = ['(clearb3)', '(on-table b3)', '(arm-empty)'], 删除 = ['(holdingb3)']
>     ...
>
> **迭代 1:**
> - 提示类型: 属性
> - 主要思路: ...
> - 已解决 16 个实例 (平均扩展节点数: 7.0)
> - 直接性在 16 个任务上验证 (最后一个索引: 15)
> - 失败分析:
>   失败类型: 属性
>   失败任务: p17.pddl
>   属性失败类型: 直接
>   状态: ['(arm-empty)', '(clearb1)', '(clearb3)', '(clearb4)', '(on b2 b5)', '(on b3 b2)', '(on-table b1)', '(on-table b4)', '(on-table b5)']
>   启发式值: 10
>   原因: 状态 h=10，但没有任何后继的 h<10。
>   后继:
>     1. 动作 = (unstack b3 b2), h=11, 添加 = ['(holdingb3)', '(clearb2)'], 删除 = ['(clearb3)', '(on b3 b2)', '(arm-empty)']
>     2. 动作 = (pickup b4), h=11, 添加 = ['(holdingb4)'], 删除 = ['(on-table b4)', '(clearb4)', '(arm-empty)']
>     3. 动作 = (pickup b1), h=11, 添加 = ['(holdingb1)'], 删除 = ['(clearb1)', '(on-table b1)', '(arm-empty)']
>     ...
>
> **迭代 2:**
> - 提示类型: 属性
> - 主要思路: ...
> - 已解决 17 个实例 (平均扩展节点数: 7.8)
> - 直接性在 17 个任务上验证 (最后一个索引: 16)
> - 失败分析:
>   失败类型: 属性
>   失败任务: p18.pddl
>   属性失败类型: 直接
>   状态: ['(arm-empty)', '(clearb1)', '(clearb3)', '(clearb5)', '(on b2 b4)', '(on b5 b2)', '(on-table b1)', '(on-table b3)', '(on-table b4)']
>   启发式值: 8
>   原因: 状态 h=8，但没有任何后继的 h<8。
>   后继:
>     1. 动作 = (unstack b5 b2), h=9, 添加 = ['(holdingb5)', '(clearb2)'], 删除 = ['(on b5 b2)', '(clearb5)', '(arm-empty)']
>     2. 动作 = (pickup b1), h=9, 添加 = ['(holdingb1)'], 删除 = ['(clearb1)', '(on-table b1)', '(arm-empty)']
>     3. 动作 = (pickup b3), h=9, 添加 = ['(holdingb3)'], 删除 = ['(clearb3)', '(on-table b3)', '(arm-empty)']
>     ...
>
> **领域进度**: 解决 99 个难度递增的实例。验证时间限制：每任务 30 秒。当前结果：启发式函数在 73 个实例上是直接的，但在 p74.pddl 上失败。
> 失败类型: 属性   属性失败类型: 直接
> 状态: ['(arm-empty)', '(clearb10)', '(clearb11)', '(clearb15)', '(clearb17)', '(clearb2)', '(clearb21)', ...]