跨设备AI代理的分层恢复机制：H-RePlan如何突破全局重规划的瓶颈

TL;DR

现实中的电脑操作任务经常横跨多个设备——比如你在Linux服务器上跑数据处理，同时要在Android手机上确认某个操作。现有的AI代理系统在处理这类跨设备任务时，一旦某个环节失败，通常只能粗暴地重试、换人做、或者从头重新规划整个任务。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年6月18日
分类: cs.CL（计算语言学）
arXiv ID: 2606.20487v1

研究背景与动机

跨设备场景的真实需求

我们先想象一个实际工作场景。你是一个数据分析师，需要完成以下操作链：

在Linux服务器上从数据库里拉取一批原始数据
用Python脚本做数据清洗和特征工程
把处理好的数据导出为特定格式
在手机上的某个应用里上传这份文件并触发审批流程
等审批通过后回到服务器上执行最终的模型训练

这个流程涉及两台完全不同的设备（Linux桌面环境和Android移动端），用到三种不同的交互方式：API调用、命令行操作、图形界面点击。任何一个环节出问题——脚本报错、文件格式不对、手机app卡死、网络断开——整个流水线就会中断。

如果让一个AI代理来自动化执行这个流程，它在第3步失败了怎么办？

现有方案的局限

目前已有的多设备代理系统，比如一些跨平台自动化框架，它们确实能做任务分解和跨设备分配。但在失败恢复这件事上，它们的做法相当粗糙，大致有三种：

第一种：盲目重试。执行失败了？那就再跑一遍同样的命令。运气好能过，运气不好就卡死在同一个坑里。

第二种：子任务重分配。把失败的子任务交给另一个代理或者换一种工具去做。但这只考虑了"谁来做"的问题，没考虑"在当前设备上还能不能换一种方式做"。

第三种：全局重规划。失败了就把整个任务计划推倒重来，让大模型重新生成一份完整的执行方案。这种方式的问题是代价太大——每次全局重规划都要消耗大量token，而且会丢弃当前已经积累的执行上下文。

这三种方案有一个共同的根本问题：它们没有系统性地建模"设备本地的策略空间"。

什么意思呢？就是在一台设备上完成某个子目标，通常不只有一种方法。比如要在Linux上"把文件上传到某个服务"，你可以用curl命令、可以用scp、可以用rsync、可以用图形界面拖拽上传。这些不同的执行方式就是同一个设备上的"可替换策略"。现有的系统在第一种策略失败后，往往不会去尝试同一设备上的其他策略，而是直接跳到更昂贵的恢复机制（重分配或全局重规划）。

更关键的是，现有方案缺乏一种机制来区分两种性质完全不同的故障：

设备本地可修复的故障：比如某个命令行工具没装，换个工具就行；某个API端点超时，等一会儿重试就好。这类问题完全可以在当前设备上解决，不需要改变整体任务计划。
需要跨设备协调的故障：比如当前设备根本完成不了这个子目标（硬件限制、权限不够），或者当前设备的失败导致后续其他设备上的子任务也需要调整。这类问题才需要上升到全局层面去重新规划。

把这两种故障混为一谈，要么导致本地可以修的问题被过度反应（全局重规划浪费资源），要么导致需要全局调整的问题被反复在本地重试（浪费时间还解决不了）。

研究动机的精炼

所以这篇论文的核心动机可以概括为一句话：多设备代理系统需要一种层次化的故障恢复机制，能够在正确的抽象层次上处理对应层次的故障。

这就像人类组织中的问题升级机制。客服接到投诉，先尝试标准流程解决；解决不了，升级到主管；主管搞不定，才上报到部门经理。你不会因为一个简单的退款问题就直接惊动CEO。同理，设备本地的小毛病不应该触发全局重规划。

核心发现

这篇论文的核心发现可以归纳为以下几点：

发现一：设备本地存在有意义的策略空间。在同一个设备上完成同一个子目标，往往存在多种可替换的执行策略。这些策略之间的切换成本远低于全局重规划。

发现二：故障恢复的粒度对系统性能影响巨大。实验表明，能够区分"本地可修复"和"需要全局调整"的系统，在任务完成率上比粗粒度恢复系统高出显著幅度。

发现三：分层恢复机制能降低总体token消耗。虽然分层恢复增加了架构复杂度，但由于避免了不必要的全局重规划，实际执行中的token消耗反而更低。

发现四：故障注入基准测试揭示了现有系统的真实弱点。HeraBench通过构造设备级和策略级故障场景，证明现有系统在面对非平凡故障时表现不佳。

技术方法详解

整体架构：H-RePlan的三层结构

H-RePlan的架构可以用一个"公司层级管理"的类比来理解。

想象一个跨国公司，每个国家有自己的分公司（设备），总部有一个CEO（全局编排器）。每个分公司内部有不同的部门经理（本地执行策略），每个部门经理有自己的做事方式。

公司处理问题的流程是这样的：

执行层（员工）：按照分配的任务去干活。对应H-RePlan中的具体执行器——可能是CLI命令执行器、API调用器、或者GUI操控器。
设备本地恢复层（分公司经理）：员工搞不定的问题先交给分公司经理。经理会看看分公司内部还有没有其他资源和方法可以解决这个问题。这就是H-RePlan中每个设备上的本地策略恢复模块。
全局编排层（CEO）：分公司自己解决不了的问题，才上报到总部。CEO会从全局视角重新评估——可能需要调整其他分公司的任务，可能需要重新分配资源，可能需要修改整体计划。这就是H-RePlan中的全局重规划器。

这三层之间通过一种紧凑的跨层故障抽象来通信。本地层不会把一堆原始的错误日志丢给全局层，而是把故障压缩成结构化的抽象表示——包含故障类型、影响范围、已尝试的修复策略和结果。全局层根据这些抽象信息做出决策，而不需要了解每个设备的底层执行细节。

统一执行接口：API-CLI-GUI三合一

H-RePlan的另一个技术亮点是它支持三种执行模式的统一管理：

API调用：通过程序接口与软件交互，速度快、可靠性高，但不是所有软件都暴露API。
CLI命令行：通过终端命令操作，灵活性强，适合服务器环境和脚本化操作。
GUI图形界面：通过模拟鼠标键盘操作图形界面，覆盖面最广，但速度慢、容易受界面变化影响。

这三种模式就像三个不同语言的翻译。同一个任务——比如"下载一个文件"——可以用API发HTTP请求、用CLI执行wget命令、或者用GUI在浏览器里点击下载链接。H-RePlan把这三种模式统一在一个框架下，每个子任务可以根据当前设备的能力和上下文选择最合适的执行模式。

用更具体的类比来说，这就像一个多语言的外交官团队。面对同一个谈判目标（子任务），你有一个说英语的外交官（API模式）、一个说法语的（CLI模式）、一个说德语的（GUI模式）。如果英语谈判失败了，你不一定要换一个完全不同的谈判团队（全局重规划），你可以先试试让法语外交官上（本地策略切换）。

故障抽象与分类

H-RePlan对故障做了系统性的分类，这是整个框架能够实现分层恢复的基础。

策略级故障：当前选择的执行策略不行了，但目标在本设备上仍然可达。比如用curl下载文件超时了，可以换用wget试试；用某个Python库处理数据报错了，可以用另一个库实现同样的功能。这类故障在设备本地恢复层处理。

设备级故障：当前设备根本完成不了这个子目标。比如需要运行一个只在Android上有的App，但当前设备是Linux；或者设备的硬件资源不够（内存溢出、磁盘空间不足）。这类故障需要上升到全局层处理，可能需要修改任务分配，把子目标转给其他设备。

环境级故障：外部环境出了问题，比如网络断了、目标服务宕机了。这类故障的处理策略取决于具体性质——有些可以等一等再试（本地恢复），有些需要改变整体方案（全局重规划）。

这种分类的价值在于：它给了系统一个明确的决策树。遇到故障时，先判断类型，再决定在哪个层次处理。避免了"不管三七二十一先全局重规划"的粗暴做法。

本地策略空间的建模

H-RePlan中每个设备都维护着一个可替换策略集合。对于每个子目标，设备知道自己有哪些不同的执行方式可以完成它。

这个策略空间的建模方式很实用。它不是静态写死的，而是动态维护的。当一个策略失败时，系统会记录失败的原因和上下文，这些信息会影响后续策略选择的优先级。比如某个API端点超时了，系统知道这不是策略本身的问题（可能是网络波动），下次遇到同样的子目标时仍然可以尝试这个API。但如果某个CLI工具报了"命令未找到"的错误，系统知道这是因为工具没安装，在安装之前不会再尝试这个策略。

用一个厨房的类比来说：你有一道菜要做（子目标），可以用烤箱做、可以用平底锅做、可以用空气炸锅做（可替换策略）。烤箱今天坏了（策略级故障），你不会打电话叫外卖（全局重规划），而是先试试用平底锅来做（本地策略切换）。但如果厨房着火了（设备级故障），那你确实需要换个地方做饭（全局重规划）。

跨层通信机制

本地恢复层和全局编排层之间的通信是整个框架的关键。H-RePlan设计了一种紧凑的故障报告格式，本地层在报告故障时需要包含：

故障分类：是策略级还是设备级？
影响范围：这个故障只影响当前子任务，还是会影响后续依赖这个子任务输出的其他子任务？
已尝试的替代方案：本地层已经尝试了哪些策略？每个策略的失败原因是什么？
剩余可选策略：本地层还有哪些策略没有尝试？为什么没有尝试（是因为条件不满足，还是因为优先级太低）？

这种结构化的故障报告让全局编排层可以做出快速而准确的决策。全局层不需要去了解每个设备上curl和wget的区别（底层细节），只需要知道"这个设备在这个子目标上已经用尽了所有可行的策略"（抽象信息），就可以决定把这个子目标分配给其他设备或者修改整体计划。

实验结果分析

HeraBench：故障注入基准测试

为了评估分层恢复机制的效果，论文引入了一个专门设计的基准测试集——HeraBench。

HeraBench的设计思路很有意思。它不是简单地收集一些真实任务然后看看代理能不能完成，而是主动构造故障场景。它在跨设备工作流（覆盖Linux和Android设备）上注入两类故障：

策略级故障：让某个特定的执行策略失效，迫使系统去尝试替代策略或上报故障。
设备级故障：让某个设备整体无法完成某个子目标，迫使系统进行跨设备的任务重分配。

这种故障注入的方法比被动观察更有效，因为它能精确控制故障的类型和时机，从而系统性地测试恢复机制在各种场景下的表现。

HeraBench的工作流构建覆盖了真实的跨设备场景。不是那种简单的"在A设备上做一步，在B设备上做一步"的线性流程，而是包含设备间数据传递、条件分支、并行执行等复杂模式。

核心实验结果

实验结果非常清晰地支持了论文的核心主张。H-RePlan在以下几个维度上大幅超越基线：

任务完成率：H-RePlan的整体任务完成率显著高于所有基线方案。特别是面对设备级故障时，分层恢复的优势尤为明显——因为全局编排层能够做出跨设备的调整，而单策略基线在这个场景下几乎无能为力。

指令遵循度：分层恢复不仅完成了更多任务，而且完成的方式更符合原始指令的要求。粗粒度恢复方案有时候虽然"完成了任务"，但走了很多弯路，产出的结果与用户的原始意图有偏差。

完美通过率（Perfect-pass rate）：这是衡量代理是否"一次做对"的指标。H-RePlan在这个指标上的优势最明显，说明分层恢复机制减少了不必要的重试和迂回，让代理更倾向于一次就找到正确的执行路径。

Token消耗：这是实验结果中最反直觉的部分。很多人可能会认为，增加一个分层恢复机制会增加系统的复杂度和通信开销，从而增加token消耗。但实际结果恰好相反——H-RePlan的token消耗低于粗粒度恢复基线。原因很直接：避免了不必要的全局重规划。全局重规划是最昂贵的操作，每次都要重新生成完整的任务计划。分层恢复通过在本地层解决大部分问题，大幅减少了全局重规划的触发次数，从而降低了总体token消耗。

基线对比

实验对比了以下几种基线方案：

单策略基线：每个子任务只有一种执行方式，失败了就重试或放弃。
粗粒度重分配：失败的子任务可以重新分配给其他代理，但没有本地策略切换。
全局重规划：失败后触发全局重规划，重新生成完整的执行计划。

H-RePlan在所有这些基线之上都表现更好，而且改进幅度不是微不足道的——是实质性的、有统计显著性的提升。

与现有工作对比

与传统任务规划系统的区别

传统的任务规划系统（比如经典的AI规划器STRIPS、PDDL系列）通常假设执行环境是确定性的——给定一个动作，结果是可预测的。一旦执行偏离预期，它们会重新计算全局计划。H-RePlan的核心创新在于认识到在多设备场景中，执行空间是分层的，恢复也应该分层进行。

与单设备代理系统的区别

像AutoGPT、SWE-Agent这类单设备代理系统，它们的故障恢复机制局限在一个设备的视角内。当问题出在"当前设备做不了这件事"时，它们没有能力做跨设备的调整。H-RePlan通过全局编排层弥补了这个盲区。

与现有多设备代理系统的区别

现有多设备代理系统（如OSWorld、AndroidWorld等框架中支持跨设备的部分）虽然能做任务分解和跨设备分配，但它们的恢复策略要么是简单的重试，要么是昂贵的全局重规划。H-RePlan的关键差异化在于设备本地策略恢复这一层——它在全局重规划之前插入了一个轻量级的恢复步骤，只有当设备本地确实无法解决问题时才上升到全局层。

这种差异化不是简单的工程优化，而是一种认知上的提升——它认识到不同层次的故障需要不同层次的响应机制。就像软件工程中的异常处理，你不会把所有的异常都冒泡到最顶层，而是在合适的层次捕获和处理。

统一执行接口的价值

现有系统通常只支持一两种执行模式（比如只支持CLI，或者只支持GUI）。H-RePlan的API-CLI-GUI统一接口意味着同一个子任务可以在三种模式之间灵活切换。这不仅扩大了策略空间（提高了找到可行策略的概率），也为故障恢复提供了更多选项。一个GUI操作失败了（比如按钮位置变了），系统可以尝试用CLI命令实现同样的功能，而不需要上升到全局重规划。

潜在应用与影响

企业IT自动化

在企业环境中，IT运维人员经常需要跨多个系统和设备执行复杂的操作流程。比如部署一个微服务应用，可能需要在开发机上构建镜像、在CI/CD服务器上运行流水线、在Kubernetes集群上部署服务、在监控系统上设置告警。任何一步失败都会中断整个流程。H-RePlan的分层恢复机制可以直接应用于这类场景，提高自动化运维的可靠性。

跨平台数据工作流

数据科学和机器学习工作流经常涉及多个平台：在Jupyter Notebook上做探索性分析、在Spark集群上跑大规模数据处理、在GPU服务器上训练模型、在移动设备上做推理部署。H-RePlan的框架可以为这类工作流提供更智能的故障恢复能力。

数字助理的进化

当前的AI数字助理（如Siri、Google Assistant）主要在单一设备上工作。未来的数字助理需要跨设备协作——帮你在电脑上查找资料的同时在手机上设置提醒、在智能家居设备上执行操作。H-RePlan的分层恢复框架为这类跨设备数字助理提供了可靠的执行保障。

对代理系统设计范式的影响

H-RePlan最重要的影响可能是它提出的设计原则：故障恢复应该与故障发生的层次匹配。这个原则不仅适用于多设备代理系统，也适用于其他需要处理层次化执行的AI系统。比如在多代理协作系统中，一个代理的内部故障应该由该代理自己处理，只有代理间协作层面的故障才需要上升到全局协调层。

降低代理系统的运营成本

由于分层恢复机制减少了全局重规划的频率，它直接降低了代理系统的token消耗。在大规模部署场景下（比如一个公司有成百上千个自动化工作流在运行），这种token节约可以转化为显著的成本节约。

局限性与未来方向

当前局限

策略空间需要人工定义：H-RePlan的本地策略恢复依赖于预先定义的可替换策略集合。对于一个新的设备或新的应用场景，需要人工梳理每个子目标有哪些替代执行方式。这个过程不仅耗时，还可能遗漏一些微妙的替代策略。

故障分类的边界模糊：实际场景中，故障的分类并不总是那么清晰。有些故障介于策略级和设备级之间——比如设备当前的资源不足，但如果等一会儿（释放一些内存），也许就能在本设备上完成。这种"边界故障"的处理需要更精细的判断机制。

缺乏长期学习能力：当前的H-RePlan不会从历史故障中学习。每次遇到同样的故障类型，系统都会按照预设的决策树处理，不会因为"上次这种方式修复成功了"而调整策略优先级。

基准测试的覆盖面：HeraBench虽然设计了两类故障场景，但现实中的故障远比这两类复杂。网络分区、部分失败、级联故障等更复杂的场景还没有被系统性地覆盖。

计算开销：虽然分层恢复在token消耗上优于全局重规划，但多层架构本身引入了额外的协调开销。在简单场景下（故障很少发生），这种开销可能是不必要的。

未来方向

自动策略发现：通过观察人类在设备上的操作或者分析软件的文档，自动发现同一子目标的替代执行方式。这可以大幅降低策略空间的人工维护成本。

自适应故障分类：利用机器学习模型，根据故障的上下文特征自动判断它属于哪个层次，而不是依赖硬编码的规则。这可以处理更复杂的边界情况。

经验学习与策略记忆：引入记忆机制，让系统能够积累故障处理的经验，随着时间推移变得更加高效。这与当前强化学习在代理系统中的应用方向一致。

更大规模的设备协作：当前的实验覆盖了Linux和Android两种设备。将框架扩展到更多设备类型（iOS、Windows、嵌入式设备、IoT设备）是一个自然的下一步。

与人类协作的故障恢复：在某些关键场景下，系统可能需要人类的介入来处理无法自动解决的故障。如何设计平滑的人机协作故障恢复机制是一个值得探索的方向。

形式化保证：当前的实验结果是经验性的。能否为分层恢复机制提供形式化的可靠性保证（比如"在什么条件下，分层恢复一定不会比全局重规划更差"）是一个有趣的理论问题。

总结

H-RePlan这篇论文解决了一个在多设备AI代理系统中被严重忽视的问题：故障恢复的粒度问题。现有的系统要么在本地盲目重试，要么动辄全局重规划，缺乏一种中间层的恢复机制。H-RePlan通过引入设备本地策略恢复层，构建了一个三层的分层恢复框架，在故障发生的适当层次进行处理。

这个工作的核心洞察并不复杂——"小问题小处理，大问题大处理"——但将这个洞察落地为一个可工作的系统框架，并通过精心设计的故障注入基准测试验证其有效性，是有实际价值的工程贡献。实验结果表明，分层恢复不仅提升了任务完成率和指令遵循度，还通过减少不必要的全局重规划降低了总体成本。

在AI代理系统日益走向多设备、多环境部署的大趋势下，H-RePlan提出的设计原则——恢复机制应与故障层次匹配——可能会成为未来多设备代理系统架构设计的重要参考。这不是一个惊天动地的突破，但它是一个扎实的、解决真实问题的工作，而这正是当前AI代理领域最需要的。