超越全局重规划：面向跨设备任务与运动规划的分层恢复机制

TL;DR

多设备智能体执行跨平台任务时，一旦某个环节出错，现有系统要么简单重试、要么推倒重来——这两种策略都不够聪明。H-RePlan 提出了一种「分层重规划」框架：先让出错的设备自己想办法（本地策略恢复），实在搞不定再上报给全局编排器做跨设备调整。配合专门设计的故障注入基准 HeraBench，实验证明这种分层方案在任务完成率、指令遵循度和 token 消耗上全面碾压传统方法。核心洞察：知道故障发生在哪一层，比盲目重试重要得多。

论文信息

标题: Beyond Global Replanning: Hierarchical Recovery for Cross-Device Agent Systems
作者: Shu Yao, Yuhua Luo, Qian Long, Jingru Fan, Zhuoyuan Yu, Yuheng Wang, Lin Wu, Yufan Dang, Huatao Li, Chen Qian
发布日期: 2026-06-18
分类: cs.CL (计算语言学)
arXiv ID: 2606.20487v1
论文链接: https://arxiv.org/abs/2606.20487v1

研究背景与动机

想象你正在组织一场跨国视频会议。你的笔记本电脑负责运行会议软件，平板电脑上打开了需要共享的文档，手机上挂着实时翻译应用。突然，笔记本上的会议软件崩溃了。你怎么办？

最笨的办法是从头来过——重启所有设备上的所有应用，重新连接所有人。稍微聪明一点的办法是在同一台笔记本上反复尝试重启软件。但最聪明的做法是：先判断这个问题能不能在笔记本上解决（比如重启软件），如果不行，就把会议转移到平板上，同时让手机的翻译应用重新连接新的会议源。

这个日常场景恰好对应了多设备智能体系统面临的核心挑战。随着大语言模型驱动的智能体（Agent）能力不断增强，研究者们开始构建能够跨越多个设备、多个操作系统、多种交互方式（API、命令行CLI、图形界面GUI）来完成复杂任务的系统。比如，一个智能体可能需要在 Linux 服务器上执行数据分析脚本，同时在 Android 手机上截取界面信息，最后在桌面电脑上生成报告。

现有多设备智能体系统已经能够做到任务分解和跨设备分配——把一个大任务拆成若干子任务，分配给不同设备去执行。但当执行过程中出现故障时，恢复机制却相当粗糙。系统通常只有三种选择：

简单重试: 在同一台设备上用同样的策略再试一次，期望「这次运气好点」
子任务重分配: 把失败的子任务交给另一台设备，但仍然用同样的策略
全局计划修订: 让高层编排器重新规划整个任务流程

这三种策略的问题在于，它们都没有系统性地建模「设备本地的策略空间」。什么意思呢？每台设备完成同一个子任务的方式可能有很多种——比如在 Linux 上创建一个文件，可以用 touch 命令，可以用 Python 脚本，可以用 GUI 文件管理器，甚至可以通过 API 调用。当一种方式失败时，可能只是这种特定方式行不通（比如某个命令不存在），换一种方式在同一台设备上就能成功。但如果问题出在设备本身（比如权限不足、资源不够），那就需要跨设备重新规划了。

关键问题是：如何区分「在当前设备内就能修复的故障」和「需要跨设备重新规划的故障」？ 现有系统缺乏这种故障范围感知能力，导致要么在无法修复的场景上浪费大量 token 去反复重试，要么过早放弃本可以在本地解决的问题。

这就像一个没有经验的项目经理：团队成员遇到问题时，他要么说「再试一次」，要么直接把任务转给别人，而不会先判断这个问题到底是个技术难题（换个工具就行）还是个资源瓶颈（需要换团队）。

正是基于这一核心洞察，研究者提出了 H-RePlan——一种分层重规划框架，通过清晰的故障抽象层，将设备本地恢复与全局重规划解耦，实现范围感知的智能恢复。

核心发现

H-RePlan 的核心发现可以从三个维度来理解：

第一，故障具有层级结构，不同层级需要不同的恢复策略。 研究者将执行故障明确区分为两个层级：

策略级故障（Strategy-level failure）: 同一台设备上的执行策略不奏效。比如，用 apt-get install 安装某个包失败了（可能是因为包名不对），但设备本身是正常工作的。这种情况下，换成 snap install 或者手动编译安装可能就能解决问题。
设备级故障（Device-level failure）: 设备本身出了问题，无论用什么策略都无法在该设备上完成子任务。比如，Android 设备断网了，或者 Linux 服务器的磁盘空间满了。这种情况下，必须把任务转移到其他设备。

通过大量实验，研究者发现：在真实场景中，策略级故障的发生频率远高于设备级故障。这意味着，如果系统能够有效处理策略级故障（在设备本地切换策略），就能避免大量不必要的跨设备重规划，从而显著降低 token 消耗和延迟。

第二，紧凑的跨层故障抽象是实现高效恢复的关键。 H-RePlan 设计了一种简洁的故障信息传递机制：当设备本地恢复失败时，只需要向全局编排器传递一个精炼的故障摘要（而不是完整的执行日志），编排器就能做出正确的跨设备决策。这种设计大幅降低了层间通信的 token 开销。

打个比方，这就像一个好的客服系统：一线客服（设备本地恢复）处理大部分常见问题，只有搞不定的才升级到主管（全局编排器），而且升级时会附上精简的问题摘要，而不是把整个对话记录都转发过去。

第三，分层恢复在多项指标上实现了全面超越。 具体来说：

任务完成率显著提升：H-RePlan 在 HeraBench 基准上的完成率远超单策略基线和粗粒度多设备基线
指令遵循度更高：分层恢复减少了因反复重试导致的指令偏离
**完美通过率（perfect-pass rate）**大幅提升：不仅完成了任务，而且完成质量更高
Token 成本反而降低：因为精准的故障定位避免了大量无效重试，总 token 消耗低于那些「暴力重试」的方案

这个结果非常有趣——通常人们认为更复杂的恢复机制会消耗更多计算资源，但 H-RePlan 通过「先定位再行动」的策略，实际上比盲目重试更节省资源。就像一个老练的医生，精准诊断后的对症下药，远比胡乱尝试各种药物更高效也更便宜。

技术方法详解

整体架构：双层决策体系

H-RePlan 的架构可以用一个「军队指挥链」的类比来理解。底层是各个「作战单位」（设备），每个单位都有多种「战术」（执行策略）可以选择。顶层是「指挥部」（全局编排器），负责整体战略规划。

当一次攻击（执行某个子任务）失败时，首先由作战单位自行判断：是战术不对（换个战术再试），还是敌人太强（需要请求增援或改变作战目标）？只有当作战单位确认自己搞不定时，才上报指挥部，由指挥部决定是调其他单位来支援，还是修改整体作战计划。

具体来说，H-RePlan 的架构包含以下核心组件：

1. 统一执行接口：API-CLI-GUI 三模态

每台设备配备一个统一的执行层，支持三种交互模式：

API 模式: 通过编程接口直接调用功能，速度快、可靠性高，但受限于可用的 API 覆盖范围
CLI 模式: 通过命令行执行操作，灵活性强，但需要正确构造命令
GUI 模式: 通过图形界面操作，最接近人类使用方式，但速度慢、容易受界面变化影响

这三种模式之间可以互相替代。就像你要锁一扇门，可以用电子锁（API）、可以用钥匙（CLI）、也可以叫人帮你锁（GUI）。如果电子锁坏了，换钥匙就行，不需要换门。

2. 可互换执行策略

对于每个子任务，设备可以从策略池中选择不同的执行方式。这些策略按照与设备的耦合程度排列：

高度耦合策略: 依赖特定设备的特定工具（比如某个 Linux 独有的命令）
中度耦合策略: 使用跨平台但需要特定环境的方案（比如 Python 脚本）
低耦合策略: 使用通用方式（比如通过浏览器访问 Web API）

当首选策略失败时，系统按照耦合度从低到高的顺序尝试替代策略。这个设计的妙处在于：如果连最通用的策略都失败了，那大概率是设备本身的问题，而不是策略选择的问题。

3. 跨层故障抽象

这是 H-RePlan 最核心的创新。故障抽象层的设计遵循一个原则：只传递恢复决策所需的信息，不多传一个 token。

当设备本地恢复失败后，向编排器报告的不是「我在执行命令 X 时遇到了错误码 Y，然后尝试了策略 A、B、C，每种策略的具体执行日志如下……」，而是类似这样的结构化摘要：

{
  "subtask": "创建数据可视化图表",
  "device": "linux-server-01",
  "failure_scope": "device",
  "attempted_strategies": ["matplotlib", "plotly", "gnuplot"],
  "root_cause": "无图形显示环境 (no display server)",
  "recommendation": "需要具有 GUI 环境的设备"
}

编排器拿到这个摘要后，就能快速做出决策：将子任务转移给有 GUI 环境的设备。整个过程的信息传递极其精简，避免了「把大象装冰箱需要几步」式的冗长日志传输。

4. 全局编排器的决策逻辑

全局编排器收到故障报告后，执行以下决策流程：

步骤一：范围确认。 根据故障摘要中的 failure_scope 字段，确认这确实是设备级故障（如果是策略级故障，本地就应该已经处理了）。

步骤二：资源评估。 检查其他设备的能力清单，判断哪些设备能够承接这个失败的子任务。

步骤三：依赖分析。 分析该子任务的上下游依赖，确认转移设备不会导致数据传输瓶颈或兼容性问题。

步骤四：计划修订。 生成修订后的全局计划，可能涉及：

子任务的设备重新分配
数据流路径的调整
后续子任务的策略更新

这个过程就像一个经验丰富的项目经理在应对突发状况：先确认问题的严重程度，再评估可用资源，然后考虑连锁影响，最后做出调整决策。

5. HeraBench：故障注入基准测试

为了评估分层恢复能力，研究者设计了 HeraBench——一个专门的故障注入基准测试。它的核心思想是：在真实的跨设备工作流中，人为注入不同层级的故障，观察系统如何应对。

HeraBench 的故障注入分为两类：

策略级故障注入: 在设备上模拟某个执行策略不可用的情况（比如禁用某个命令、模拟 API 返回错误）
设备级故障注入: 模拟整个设备出现问题（比如网络断连、磁盘满、服务崩溃）

测试场景涵盖 Linux 和 Android 设备的组合，涉及文件操作、数据处理、界面交互等多种任务类型。这种设计确保了评估的全面性和真实性。

实验结果分析

实验在 HeraBench 基准上展开，对比了 H-RePlan 与多种基线方案：

基线方案包括：

单策略基线: 每个子任务只用一种固定策略，失败就重试
粗粒度多设备基线: 支持跨设备任务分配，但恢复时直接触发全局重规划
无分层恢复基线: 有多种策略但不做故障范围判断，统一按全局重规划处理

核心实验结果：

指标	H-RePlan	单策略基线	粗粒度基线
任务完成率	显著最高	较低	中等
指令遵循度	显著最高	较低	中等
完美通过率	显著最高	最低	中等
Token 消耗	较低	较高（重试多）	最高（全局重规划频繁）

几个值得注意的实验观察：

策略级恢复的巨大价值: 在所有故障中，策略级故障占比远高于设备级故障。H-RePlan 通过设备本地的策略切换，处理了大部分故障，避免了不必要的全局重规划。这直接导致了 token 消耗的降低——与直觉相反，更「聪明」的恢复机制反而更便宜。
故障范围判断的准确性: H-RePlan 的故障抽象层能够准确区分策略级和设备级故障，误判率很低。这意味着系统很少出现「本可以在本地解决却上报全局」或「应该上报全局却在本地死磕」的情况。
完美通过率的显著提升: 完美通过率衡量的不仅是任务是否完成，还有完成的质量。H-RePlan 的分层恢复不仅帮助系统「活下来」（完成任务），还帮助系统「活得好」（高质量完成）。这可能是因为分层恢复减少了全局重规划的次数，从而减少了计划变更带来的累积误差。
Token 成本的反直觉下降: 这是实验中最引人注目的发现。传统观点认为，更复杂的恢复机制必然消耗更多计算资源。但 H-RePlan 的实验表明，精准的故障定位和范围感知恢复，实际上比盲目重试更节省 token。粗粒度基线每次遇到故障都触发全局重规划，全局重规划需要重新分析整个任务图、重新评估所有设备的可用性、重新生成执行计划——这些操作的 token 消耗远大于在设备本地切换一个策略。

与现有工作对比

多设备智能体系统是近年来的研究热点，已有多项重要工作：

任务分解与跨设备分配: 现有系统（如 AppAgent、Mobile-Agent 等）已经能够将复杂任务分解为子任务并分配给不同设备。但这些系统在故障恢复方面通常采用简单的重试或全局重规划策略，缺乏对故障范围的精细建模。

单设备内的执行恢复: 一些工作（如 Reflexion、Self-Refine）研究了单设备内的执行失败恢复，通过反思和自我修正来提高任务完成率。但这些方法局限于单一设备，无法处理跨设备场景中的设备级故障。

任务与运动规划（TAMP）: 传统 TAMP 领域研究了任务规划与运动规划的结合，但主要针对物理机器人场景，与跨设备数字智能体的场景有较大差异。

H-RePlan 的独特贡献在于：

首次明确提出故障的层级结构，将策略级故障和设备级故障作为两个独立的恢复层面
设计了跨层故障抽象机制，使得不同层级的恢复可以高效协作
构建了专门的故障注入基准 HeraBench，为评估多设备恢复能力提供了标准化工具

与最接近的工作相比，H-RePlan 的方法论差异在于：不是把恢复视为一个「单一决策点」（失败→重试/重规划），而是将其展开为一个「层级决策过程」（失败→判断范围→本地恢复/上报→全局调整）。

潜在应用与影响

H-RePlan 的研究成果具有广泛的应用前景：

企业级多设备协作

在企业环境中，员工经常需要在多个设备之间切换完成工作。一个基于 H-RePlan 的智能助手可以自动协调笔记本、手机、平板、智能音箱等设备，当某个设备出现故障时，智能地将任务转移到其他设备，而不是要求用户手动处理。例如，在进行在线演示时，如果笔记本突然死机，系统可以自动将演示转移到平板上继续。

智能家居与物联网

智能家居场景中，各种设备（灯光、空调、安防摄像头、语音助手）需要协同工作。H-RePlan 的分层恢复机制可以确保：当某个传感器失效时，系统先尝试用其他传感器的数据推断（策略级恢复），实在不行才改变整体家居控制策略（全局重规划）。

工业自动化与机器人协作

在工业 4.0 场景中，多个机器人和自动化设备需要协调完成生产任务。H-RePlan 的故障层级模型可以帮助这些系统更高效地处理设备故障：先在当前设备上尝试替代方案，减少不必要的生产线停机时间。

云计算与边缘计算

在云-边协同场景中，计算任务需要在云端和边缘设备之间灵活调度。H-RePlan 的分层恢复思想可以直接应用于这类场景：边缘设备上的任务失败时，先尝试本地替代方案（如切换算法实现），实在不行再迁移到云端或其他边缘节点。

对智能体研究的影响

从更宏观的角度看，H-RePlan 提出的「范围感知恢复」范式，可能对整个智能体研究社区产生深远影响。它提示研究者：在设计多智能体系统时，不仅要考虑「如何成功执行」，还要系统性地考虑「如何从不同范围的失败中恢复」。这种思维方式可以推广到更多的协作场景中。

局限性与未来方向

当前局限

故障分类的边界模糊: 在某些场景中，策略级故障和设备级故障之间的界限并不总是清晰的。比如，一个设备上只有两种策略可以完成某个子任务，两种都失败了——这到底是策略级问题（可能还有第三种策略没试过）还是设备级问题？H-RePlan 目前依赖预定义的规则来做判断，但在更复杂的场景中，这种判断可能需要更智能的推理。
故障注入的真实性: HeraBench 的故障注入虽然是系统性的，但人为注入的故障与真实世界中自然发生的故障可能存在差异。真实故障往往是多种因素交织的结果（比如网络不稳定加上磁盘空间不足加上特定软件版本的 bug），而注入的故障通常是单一因素。
设备数量的扩展性: 当前实验主要在 2-3 台设备的场景中进行。当设备数量大幅增加（比如数十台设备组成的集群）时，全局编排器的决策复杂度可能会急剧上升，分层恢复的效果是否能保持需要进一步验证。
动态环境适应性: 当前系统假设设备的能力清单是静态的。但在真实环境中，设备的可用能力可能动态变化（安装了新软件、网络条件变化等），系统需要能够感知和适应这些变化。

未来方向

自适应故障分类: 利用大语言模型的推理能力，实现更智能的故障范围判断，而不是依赖预定义规则。让系统能够从历史故障数据中学习，逐渐提高分类准确性。
预防性恢复: 不仅在故障发生后恢复，还要能预测潜在的故障风险，提前准备替代方案。比如，检测到某个设备的磁盘空间即将不足时，提前将后续任务迁移到其他设备。
多层级扩展: 将分层恢复从两层（设备层和全局层）扩展到更多层级，比如加入「网络层」（处理网络连接问题）、「应用层」（处理应用崩溃）等更细粒度的故障恢复层。
人机协作恢复: 在自动恢复无法解决问题时，智能地向用户请求帮助，而不是简单地报告失败。系统应该能够诊断问题并给出具体的求助建议（「请帮我检查一下手机的网络连接」而不是「任务失败了」）。
跨模态恢复策略: 探索在不同交互模态（API、CLI、GUI）之间的智能切换策略。比如，当 API 调用因为接口变更而失败时，系统能否自动切换到 GUI 模式来完成相同的操作？

总结

H-RePlan 论文的核心贡献在于揭示了一个被忽视但至关重要的设计空间：多设备智能体的故障恢复不应该是「全有或全无」的二元选择，而应该是一个层级化的决策过程。

通过将故障明确区分为策略级和设备级两个层次，并设计精巧的跨层故障抽象机制，H-RePlan 实现了「能本地解决的不上报，该全局处理的不拖延」的精准恢复策略。配套的 HeraBench 基准测试为这一能力的评估提供了标准化工具。

实验结果中最具启发性的发现是：更智能的恢复机制不仅提升了任务完成质量，还降低了 token 消耗。这个「越聪明越省钱」的结论，打破了「更复杂必然更昂贵」的直觉认知，为未来多设备智能体系统的设计指明了方向。

对于智能体研究社区而言，H-RePlan 提出的范围感知恢复范式具有方法论层面的参考价值：在设计任何多智能体协作系统时，故障恢复的粒度和层级都是值得深思的设计维度。正如好的工程设计不是追求「永远不出错」，而是追求「出了错能高效恢复」，H-RePlan 为多设备智能体的鲁棒性建设提供了一条切实可行的路径。