REPOT: 通过检查点修复的可恢复 Program-of-Thought

TL;DR RePoT 通过确定性验证重放定位 PoT 计划的首个失败步，仅需一次额外 LLM 调用从已验证前缀修复，以微小成本将成功率提升 3–11 个百分点。

问题

问题背景

大型语言模型 (LLM) 在任务规划中越来越多地用于生成可执行计划。Program-of-Thought (PoT) 是一种典型范式：一次性生成一个 Python 程序，运行后输出一系列原始动作；这种方法将 LLM 当作黑盒规划器，一次性输出完整动作序列，无需与环境交互。

现有方法局限

PoT 的致命缺陷是单次执行即整体失效：即便只有 1 个动作在与环境交互时无效（例如动作参数错误或状态不可执行），整个轨迹都会静默作废，且没有内置的恢复机制。已有的改进方法包括多次重试（高计算成本）或引入过程奖励模型（需要额外训练），但两者都未能以低成本、可验证的方式处理运行时错误。更关键的是，现有方法缺乏环境感知的验证闭环，无法区分“程序本身出错”与“执行过程中某一步骤出错”。

为什么这个问题难且重要

挑战在于：规划任务通常涉及长序列、组合复杂性，LLM 一次生成完全正确的序列概率有限；而逐步调用 LLM 会带来高昂的延迟和成本。如何在不显著增加 LLM 调用次数的前提下实现可靠恢复，是工程落地的关键。该问题在 AI 规划社区备受关注，因为现实场景（如机器人操控、API 编排）中，动作执行失败是常态而非例外，且失败往往只发生在序列中间某处。

行业类比

这类似于自动化测试中的断点续跑：当长流程中的某一步失败时，与其重跑整条流水线，不如从上次通过的检查点继续执行——RePoT 正是为 LLM 规划引入了类似机制。

核心洞察

• **验证重放（verified replay）将计划执行与校验绑定，精确捕获首次失效状态，为后续修复提供了最小充分上下文。** 与标准的重试（PoT-retry）或基于错误消息的修复不同，RePoT 不依赖模型从失败输出中推测错误位置，而是通过确定性环境交互一步步推进到无效转移点，再只对已验证前缀进行单次修复调用。这种“先定位、再修复”的流程将修复范围大幅压缩，使得在仅约 14% 的失败问题上最多一次额外的 LLM 调用，就能带来跨多个模型 +3 到 +11 个百分点的准确率提升，显著优于同等预算的重试基线。
• **Derail‑550 基准实验揭示：恢复性能的核心信号是交互式检查点信息，而非单纯的错误反馈。** 当只提供错误消息时，GPT‑medium 和 Gemini 的成功率均不超过 3.1%，而一旦引入已验证前缀的检查点信息，恢复率跃升至 ≥30%（GPT‑medium）和 ≥70%（Gemini）。这表明，环境交互给出的结构化“已验证前缀”比文本错误消息携带了更强的定位与规划线索，挑战了当前许多修复方法仅依赖错误代码反馈的假设，对设计鲁棒的程序型智能体具有直接工程指导意义。

方法

方法概览

RePoT (Recoverable Program-of-Thought) 针对 one-shot PoT 的脆性失效，通过确定性验证重播与单次 LLM 修复调用实现可恢复推理。整体流程为：输入自然语言问题 → LLM 生成 Python 程序（打印原始动作列表）→ 动作列表在交互式控制器中逐步执行 → 定位首个非法动作 → 提取已验证前缀 → 构造修复提示 → 再次调用 LLM 生成剩余计划。

关键模块

1. 程序生成与动作提取
   LLM 输出一个 Python 脚本，其执行结果直接打印出一系列环境动作（如 move to A, pick B）。程序本身不与环境交互，因此即使包含非法动作也不会在生成时报错。

2. 验证重播 (Verified Replay)
   在交互式控制器中，按顺序执行动作列表。控制器维护环境状态，每步检查动作合法性（前置条件是否满足）。一旦遇到非法动作，立即停止，并将所有已成功执行的动作标记为已验证前缀。若全部动作均合法，则轨迹直接成功，无额外 LLM 调用。

3. 修复提示与恢复 (Repair Prompt & Recovery)
   将已验证前缀与当前环境状态（含失败动作的上下文）拼入预定义的修复提示模板。提示要求 LLM 从该前缀继续生成后续动作。该次 单次 LLM 调用 产生的计划直接追加到已验证前缀之后，构成完整轨迹。

4. 自适应路由 (Adaptive RePoT)
   在基础 RePoT 上引入基于规则的调度器：若已验证前缀长度小于阈值（如总步数的 20%），说明失败早且前缀可能不具指导性，此时切换为全新 PoT 重试；否则采用上述后缀修复。该策略平衡了修复成功率与额外开销。

与同类方法的差异

相比朴素的 PoT-retry（直接重新生成整个程序），RePoT 仅需至多一次额外 LLM 调用，且充分利用已验证部分作为锚点，将恢复信号从错误反馈升级为带有环境状态的检查点信息；相较于需多步验证的树搜索方法，RePoT 保持了极低的推理成本。

实验

实验设计

在三个基准上评估：PuzzleZoo-775（775个规划问题）、PlanBench Blocksworld（378个积木世界问题）和Derail-550（550个受控恢复错误场景）。使用四个闭源模型配置（GPT、Gemini等）及四个开源模型。主要对比方法包括单次 PoT、匹配预算的 PoT-retry 和 RePoT。关键消融研究恢复提示与检查点信息的作用。

关键发现

• PuzzleZoo-775：RePoT 较 PoT 提升 3–11 个百分点，在 gpt-5.4-mini-medium 上达 96.9%（基线 86.3%）。
• PlanBench Blocksworld：提升 1.1–11.4 个百分点。
• 对比匹配预算的 PoT-retry，RePoT 在 Gemini 上显著胜出（+3.8pp，95% CI [2.2,5.4]），但在 GPT-mini 上较弱，呈现模型能力依赖的缩放模式。
• Derail-550：拥有检查点信息的条件在 GPT-medium 上成功率 ≥30%，Gemini 上 ≥70%，而仅错误反馈的条件成功率 ≤3.1%，表明检查点信息而非特定前缀尾部是关键恢复信号。

基线对比解读

RePoT 通过确定性验证重放定位第一个无效动作，仅需一次额外 LLM 调用从已验证前缀恢复。相比朴素重试，这种“校验点修复”减少了重复无效计算，尤其在模型能力较强时，前缀条件化能有效引导模型生成可行后缀。但当模型能力不足（如 GPT-mini）时，修复可能因前缀过短而失效，此时重新生成完整计划更优，这启发了自适应的路由策略（根据已验证前缀长度选择修复或重试）。总体看，RePoT 以极低的推理开销显著提升了单次 PoT 的鲁棒性，为 LLM 规划的可恢复性提供了新范式。

行业影响

落地场景

RePoT 使 LLM 生成的多步可执行计划具备可恢复的验证重放能力，适用于任何依赖程序化思维 (PoT) 生成动作序列的场景，且环境能够提供状态转移验证。典型落地包括：

• 智能助理与自动化工作流：让 LLM 代理生成一系列 API 调用或 UI 操作，例如在 RPA、浏览器自动化、企业服务集成中，一旦某步动作非法（参数错误、依赖缺失），无需废弃整条轨迹，可直接从最后一个有效状态恢复。
• 物流调度与机器人任务规划：LLM 输出分拣、搬运或装配的指令序列，通过仿真或数字孪生验证，利用 RePoT 的检查点信息局部修复故障，避免从头推理带来的延迟和额外 token 成本。
• 教育科技与编程辅助：在交互式编程练习中，学生或模型生成的代码片段可逐步执行验证，当某行产生运行时错误时，利用已验证前缀重新提示模型修复，提供更有针对性的反馈。

商业价值

• 降本：仅在约 14% 的失败案例上多消耗一次 LLM 调用，而传统的重试或从头生成会浪费大量 token 和推理时间。在批量任务中，可以显著降低 API 开销。
• 增收与体验提升：在面向终端用户的产品中（例如智能客服、自动化报告生成），更高的任务成功率意味着更好的用户体验和客户留存。对于内部流程自动化，减少人工干预需求，提高干系人效率。
• 可靠性飞轮：通过验证重放将环境反馈注入修复过程，模型可以持续学习纠正常见错误，未来可从修复对中微调，进一步提升基座能力。

与现有产品 / 工作流的接口

RePoT 以非侵入方式包裹现有 PoT 流程：

1. 在 LLM 输出计划（例如 Python 程序或 JSON 动作列表）后，增加一个确定性重放控制器，顺序与环境交互，直至首次非法转移。
2. 控制器记录已通过验证的前缀（plan prefix），并捕获转换错误信息，形成一次性的修复提示。
3. 该修复提示被发送给同一 LLM（或多模型路由），模型直接续写剩余计划，无需重新生成完整输出。

集成时只需实现一个与环境通信的 Verifier 接口，可适配已有仿真器、API 沙箱或业务规则引擎。对于不满足“一次调用即修复”预算的极端情况，可使用Adaptive RePoT 策略，根据已验证前缀长度决定是修复还是全部重试。

具体行业场景

• 物流履约：在仓储机器人调度中，LLM 生成装箱与搬运序列，若某步骤指定的货架编号在库存系统中不存在，RePoT 截取到该步之前的有效操作，将错误信息与上下文回传至 LLM，快速修订后续路径，避免导致整批订单延误。
• 内容审核自动化：在 UGC 平台，LLM 输出多步审核规则链（先图像审核、再文本审核、最后人工复核）。若某规则因配置错误无法执行，PoT 轨迹全部作废；RePoT 可以从上一个成功的审核节点继续，仅修复出错环节，确保流程的持续可用性，提升审核效率与合规性。

局限

• **依赖模型能力与问题类型**：RePoT 的提升高度依赖模型本身的能力和问题结构。在 GPT-mini 上，RePoT 甚至不及等预算的 PoT-retry 基线（损失 -2.1pp），而在 Gemini 上却大幅领先（+3.8pp）。作者指出修复信号的有效性取决于模型能否利用校验前缀信息，低能力模型可能无法从中获益。此外，在 Blocksworld 的某些复杂度级别（c=8, c=11）上，RePoT 对 GPT-mini 出现负增益，提示方法存在不稳定区间。这限制了它作为通用增强的普适性，实际部署时需要针对模型和任务进行选择。
• **对环境交互的强假设**：RePoT 的核心是确定性验证回放（verified replay），要求环境在每一步都能准确判断动作是否无效并返回校验点信息。对于连续控制、随机环境或无法低成本获取准确过渡校验的任务，该方法难以直接应用。而且修复仅基于第一个无效过渡之前的前缀，忽略了后续动作可能隐含的修正机会，当失败原因深藏于计划初期错误时，单次后缀修复的容量可能不足。
• **过于简化的恢复策略**：RePoT 仅使用一次额外 LLM 调用来生成后缀修复，没有考虑多轮迭代、反思或搜索。实验表明，仅靠校验点信息而非特定前缀结尾是主要恢复信号，但该方法并未尝试融合错误类型或其他上下文（如回退多步）。与采用过程奖励模型或树搜索的更强验证框架相比，这种简单修复可能在更复杂的规划任务中达到瓶颈。未来工作也提到需要探索自适应路由和更丰富的修复提示。