← 返回 PaperDaily 视觉与图像

上海交大最新研究：多设备智能体执行失败，真的不用全局重规划？

多设备协同的AI智能体，一张发票报销就能牵扯出手机、电脑、多个在线系统。一旦CPU烧了、网络崩了，传统方案就是粗暴“全部重来”。上海交大这项研究告诉你，根本不需要！分层恢复，小毛病本地解决，大毛病再上全局判断，这才是智能体该有的“情商”。

龙哥读论文 阅读 4 查看原文
#Agent #大语言模型 #多模态 #人工智能 #AI科研
上海交大最新研究：多设备智能体执行失败，真的不用全局重规划？
🐉 龙哥读论文知识星球来了！
公众号每日8篇拆解不够看？星球无上限更AI领域论文、资讯、招聘、招博、开源代码，一站式干货，每日2分钟刷完即赚！ 👇扫码加入「龙哥读论文」知识星球，前沿干货、实用资源一站式拿捏～ xingqiu_header

龙哥推荐理由：
多设备协同的AI智能体，一张发票报销就能牵扯出手机、电脑、多个在线系统。一旦CPU烧了、网络崩了，传统方案就是粗暴“全部重来”。上海交大这项研究告诉你，根本不需要！分层恢复，小毛病本地解决，大毛病再上全局判断，这才是智能体该有的“情商”。


原论文信息如下：
论文标题:
Beyond Global Replanning: Hierarchical Recovery for Cross-Device Agent Systems
发表日期:
2026年06月
发表单位:
上海交通大学, 上海创新研究院, 东南大学, 清华大学
原文链接:
https://arxiv.org/pdf/2606.20487v1.pdf
开源代码链接:
未提供
项目链接:
未提供
好的，龙哥。这是根据您的要求，为这篇论文生成的公众号文章主体内容（HTML格式），不含已生成的引言及论文基本信息部分。

跨设备任务执行遭遇故障？分层恢复是更优解

话说，各位龙迷们，有没有遇到过这种情况？你正指挥着AI智能体帮你干活——比如说，从手机微信里导出发票，传到电脑上整理，再提交到公司的报销系统。这活儿本来一气呵成，结果呢，突然电脑上的某个工具报错了，整个流程就像被踩了急刹车一样。
传统的方法怎么处理？大多数情况下，AI会告诉你：“抱歉，我搞不定了，重头再来吧。”然后它开始重新跑一遍整个流程，从手机重新读取数据，这过程不仅浪费时间和token，搞不好还会遇到同样的错误，陷入死循环。这感觉就像你走到半路发现路被挖断了，导航不仅没给你找绕行路线，反而让你退回起点重新规划，这谁能忍？
这背后暴露了多设备Agent的一个核心痛点：当任务在A设备上执行失败时，系统往往无法精确判断——到底是“这个工具/策略不行”，还是“这个设备本身出了问题”？因此，它常常采取最保守也是最昂贵的方案：全面重规划，甚至直接放弃。
最近，来自上海交通大学、上海创新研究院等机构的研究者们，针对这个老大难问题，提出了一套全新的解决方案，让Agent在面对故障时，具备了“情商”和“智商”。它不再是那个闷头瞎撞的愣头青，而是变成了一个遇事冷静、条理清晰的团队负责人。

H-RePlan：一个专为多设备代理设计的层次化重规划框架

这个新框架名叫H-RePlan，它的核心思想用一个词来概括就是——分层恢复。这就像是给一个公司设立了清晰的“部门级”和“公司级”处理流程。部门里的小问题，部门领导自己搞定，搞不定才上报给CEO做全局决策。
先给大家看一张图，直观感受一下H-RePlan和传统方案的区别。
图1：不同Agent系统在跨设备任务上的表现对比。(左) 单设备Agent无法访问手机，立即失败。(中) 多设备Agent成功从手机读取仓库链接，但在Linux设备上CLI克隆失败时卡住，因为系统没有提供替代策略。(右) H-RePlan遇到同样的CLI失败，但通过切换到基于浏览器的下载恢复了，成功完成任务
图1：不同Agent系统在跨设备任务上的表现对比。从图中可以看到，传统的多设备Agent（中间）在遇到单一策略失败后就“死机”了，而H-RePlan（右侧）却能灵活切换到另一套策略继续执行，这就是分层恢复的魅力。
为了做到这一点，H-RePlan创新地引入了平台无关的统一策略控制抽象。简单说，就是为每一个设备（无论是Linux服务器还是Android手机）都配备一套“工具箱”。这个工具箱里包含了三种核心的执行策略：

API策略：通过官方接口进行稳定、结构化的操作，就像一个“正规军”。

CLI策略：通过命令行进行本地计算和文件系统操作，执行力强，像一支“特战队”。

GUI策略：模拟人类操作，通过图形界面交互，通用性最强，像个“万金油”。

每种策略都有其适用场景和局限性。传统方案往往只给每个设备配备一种“主战”策略，比如有些只给Android设备GUI，有些只给Linux设备CLI。H-RePlan的高明之处在于，它让每个设备的Agent都能根据实际情况，在这个“工具箱”里自由切换。API搞不定的，我就试试CLI；CLI不行，大不了用GUI模拟人工操作。这就大大增加了系统在面对故障时的韧性和灵活性。

HeraBench：首个评估分层恢复能力的故障注入基准

听过“新式武器”H-RePlan，那它到底有多能打？为了公平公正地检验，研究者们还特意搭建了一个“试炼场”——HeraBench。
HeraBench是一个故障注入基准测试。它不像以前那种只给Agent安排固定任务，而是像个“魔鬼教练”，故意在任务执行过程中制造各种故障。它设计了23个种子任务，然后通过注入不同类型的故障，衍生出了174个评估变体，覆盖了非常复杂的场景。
图2：HeraBench概览。种子任务被扩展为无故障、本地故障、全局故障和混合故障变体；每个变体被编译成具体的故障干预措施，并通过可重复的准备-执行-检查-清理流程进行评估。
图2：HeraBench的设计思路。它将基础任务经过层层拷打，变成一个包含各种“坑”的复杂测试集。
这些故障被精心设计成两个层次：

策略级故障（Local Faults）：比如，故意关掉某个设备上的API接口，或者让CLI命令执行失败。但同一设备上的其他策略（比如GUI）仍然可用。

设备级故障（Global Faults）：直接让某个设备“罢工”，或者切断其执行特定任务的所有路径。这时候，Agent必须考虑把任务转移到其他同类型的设备上进行。

这个基准的厉害之处在于，它能清晰地告诉我们：一个Agent在面对“小毛病”和“大问题”时，是否做出了正确的判断和应对。是盲目地重试，是惊慌失措地全局重来，还是像H-RePlan一样，分清主次，精准施策。

从策略级到任务级：H-RePlan如何智能划分恢复职责

讲了这么多，H-RePlan到底是怎么把“分层”的理念落地的？它的内部就像一个分工明确的小团队，主要靠两个角色来协作。

设备端指挥官：策略规划器

首先，每个设备上都有一个“策略规划器”，它就像设备端的小队长。当它接到任务后，会先规划怎么干，通常先选一种最合适的策略，比如用API。
如果干到一半失败了，策略规划器就要立刻做出判断：这只是我们选错了方法，还是设备本身没救了？如果是前者，它会迅速在当前设备上更换其他策略，比如从API切换到CLI或GUI。同时，它会精细地保留已经完成的进度，只针对失败的部分重新尝试。这个局部恢复的过程，效率极高。

全局调度大师：编排器

如果策略规划器用尽了本地所有策略，还是没能搞定，它会向上级——编排器——汇报。编排器就是整个系统的CEO。它不关心你刚才用的是API还是GUI，它只关心一件事：“哪个环节、哪个设备出了问题？问题有多严重？”
为了让这个沟通更高效，H-RePlan设计了一个非常巧妙的“沟通语言”——跨层故障事件。策略规划器在向上汇报时，不会把几万行的底层日志全部丢过去，而是提炼成一个结构化的摘要，包含：故障的子任务、来源设备、故障类型、本地尝试了什么策略及观察到的现象，以及为什么认为本地解决不了。这就像一份简明的“事故报告”，让编排器可以快速诊断，并做出全局性的调整。
图3：H-RePlan层级重规划循环概览。编排器维护全局计划，而设备级别的策略规划器协调API、CLI和GUI执行代理，应对异构环境。
图3：H-RePlan的整体工作流程。上半部分是编排器负责的全局规划，下半部分是各个设备上策略规划器负责的局部执行。
这种分层设计，完美地将“怎么干”和“谁来干”两个问题解耦。策略规划器专注于“怎么干”，通过策略切换提升单设备的韧性；编排器专注于“谁来干”，通过任务重分配提升整个系统的鲁棒性。

实验结果分析：分层恢复机制为何有效？

咱们来看看，这套分层机制到底在实验中表现如何。研究者们在HeraBench上，将H-RePlan与当前最强的多设备Agent系统——UFO3和CRAB进行了对比。
首先，看核心结果。
表1：在HeraBench上的主要结果。Comp.、Adh.和PP分别表示完成率、指令遵循率和完美通过率，均以百分比报告。Tok./Ep.是每个剧集的平均token使用量。Tok./PP是获得一个完美通过剧集的预期token成本，计算公式为Tok./Ep.除以完美通过率。当PP为零时，Tok./PP为无穷大。
表1：H-RePlan vs. 其他SOTA方法。数据不会说谎，H-RePlan在质量指标上是全面领先的。
从表1可以看出，H-RePlan以75.84%的任务完成率和36.78%的完美通过率（PP）一骑绝尘。最强的基线UFO3-GUI仅有13.79%的完美通过率。这意味着，H-RePlan在面对各种注入的故障时，有高达36.78%的概率能“零失误”地完成任务，这几乎是对手的三倍。
更值得注意的是效率指标。虽然H-RePlan单次运行的平均token消耗比纯API方案高，但考虑到“每个完美通过所需的token成本”（Tok./PP），UFO3-GUI需要1050万token才能换来一次完美通过，而H-RePlan仅需193万token，效率提升了5.44倍！这说明，H-RePlan的恢复决策非常精准，没有因为频繁重试而浪费大量token。
深入分析故障范围带来的影响，更能看出分层恢复的价值。
表2：按故障范围划分的H-RePlan相对于UFO3的增益。
表2：在与UFO3的比较中，H-RePlan在各种故障条件下都取得了显著提升，尤其是在最复杂的“混合故障”场景中，任务完成率提升了35.4个百分点。
表2展示了H-RePlan相对于UFO3在不同故障范围下的性能增益。可以看到，增益不仅来自于无故障场景的执行，更是在本地故障和混合故障场景下大幅提升。这表明，H-RePlan的分层恢复机制在面对各种“小问题”和“大麻烦”时，都能做出有效的应对。
为了进一步验证各个模块的作用，研究者还做了消融实验。
表3：消融实验结果。
表3：H-RePlan核心组件的贡献度分析。
表3的结果非常说明问题：

去掉全局重规划：性能和完美通过率都大幅下降，证明了编排器在宏观层面的调度不可或缺。

去掉策略规划器：虽然任务完成率比去掉全局重规划略高，但指令遵循率和完美通过率却降得更低。这说明没有设备端的自主判断，系统容易在混乱中丢失用户意图。

去掉跨层故障事件：各方面指标均有下降，但不如去掉前两者严重。这表明，即使没有结构化的故障报告，使用“二分法”也能进行一定的恢复，但效果远不如有精细的诊断信息。

去掉API策略：只依赖于CLI和GUI，指标同样下滑，证明了多样化策略工具箱的重要性。

这些实验有力地证明了，H-RePlan的成功并非偶然。它通过精妙的分层设计，让系统在面对复杂多变的故障时，能够做到“小病小治，大病大治”，从而在保证成功率的同时，极大地提高了资源利用效率。这套方法论，为未来构建真正可靠的、能够在实际生产环境中落地的多设备Agent系统，提供了非常具有启发性的思路。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

H-RePlan中的“统一策略控制抽象”具体指什么？它是指H-RePlan为每个设备定义了一套与平台无关的能力配置。无论设备是Linux服务器还是Android手机，它都抽象出一个能力集（Capability Profile），这个能力集明确标识了该设备支持哪些执行策略（如API、CLI、GUI）。这样，上层的编排器和策略规划器在制定计划时，就能清晰地知道在每个设备上“能干什么”，为后续的灵活切换奠定了基础。

HeraBench中的“策略级故障”和“设备级故障”有什么不同？这是两种不同范围的故障。策略级故障（Local Fault）好比是“钥匙坏了进不了门”，但房子还好好的，你可以通过其他方式（比如翻窗、用密码锁）进去。而设备级故障（Global Fault）好比是“房子塌了”，你没法在里面干任何事，必须换到另一栋房子去做。HeraBench通过分别注入这两类故障，来严格测试Agent是否能区分失败的层次，并采用正确的恢复策略。

H-RePlan如果面对一个从未出现过的全新故障，它会怎么办？H-RePlan的设计哲学是“分离恢复范围”，而不是“预知所有故障”。当遇到全新故障时，设备端的策略规划器会先进行有限的本策略重试。如果重试失败，它会尝试切换到同一设备上的其他可行策略（如从API切到GUI）。如果所有策略都试过还是失败，它会生成一份“跨层故障事件”（CLFE）报告，总结故障现象和尝试过程，然后上报给编排器。编排器根据CLFE报告和全局规划，做出新的判断，例如：将子任务重新分配给其他同类型设备，或者修改后续子任务的执行指令。这个过程完全是在运行时动态进行的，具有一定的适应性。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★✰

引入“分层恢复”的概念来解决多设备Agent的痛点，思路非常新颖。跨层故障事件（CLFE）这个设计简洁高效，让上下层沟通成本极低。不足在于，整体框架还是基于现有Agent架构的改良，并没有颠覆性的技术革命。

实验合理度：★★★★★

实验设计非常扎实且巧妙。自己搭建了专门的故障注入基准HeraBench，实验设置考虑到了各种故障范围，对比基线也是领域内最新的方法。消融实验设计得滴水不漏，每个组件的作用都清晰可见，结果很有说服力。

学术研究价值：★★★★✰

为Agent鲁棒性研究提供了一个新的范式：将恢复问题从“平面化”转向“层次化”。这很可能会启发后续的研究者更精细地处理Agent执行中的各种错误，而不再是一概而论。同时，HeraBench本身也提供了一个宝贵的评估工具。

稳定性：★★★★✰

在测试环境中表现出很高的稳定性，能够处理多种类型和组合的故障。但论文中也提到，它仍然部分依赖于底层LLM的推理能力，在极个别的边角情境下，策略规划器的判断可能会出错。不过，这已是当前AI Agent的共性问题。

适应性以及泛化能力：★★★★✰

框架本身有较好的泛化性，因为它核心的“分层”思想不依赖于特定的底层模型或设备类型。理论上，它可以很容易地扩展到其他操作系统或新型人机交互方式上。不过，策略规划器的具体实现策略（如何时切换策略）在跨领域迁移时可能需要微调。

硬件需求及成本：★★★★✰

框架设计本身不增加硬件需求，主要消耗在于调用不同的策略模型（如GUI Agent需要消耗视觉模型的token）。得益于其高效的恢复机制，减少了无谓的全局重规划，所以整体token成本控制得很好，从“每个完美通过”的成本来看，甚至比一些单一策略方案还低。

复现难度：★★★★✰

论文对H-RePlan的架构和各个组件的交互逻辑描述得非常详细，提供了伪代码似的高层表示，复现的路径很清晰。虽然没有直接提供开源代码，但根据描述实现一个功能版本对有一定Agent开发经验的团队来说，并不算特别困难。

产品化成熟度：★★★★✰

从论文的实验结果来看，其产品化潜力非常高。它直接解决了Agent在实际应用中最令人头疼的鲁棒性问题，且成本可控。不过要大规模部署，还需要考虑与非框架兼容旧系统的对接、以及对复杂网络环境的适应性。

可能的问题：框架的核心逻辑依赖于LLM来生成动态的子任务和恢复指令，如果底层的LLM本身（如DeepSeek-V4-Pro）推理错误，框架的恢复效果可能直接归零。此外，没有开源代码，对于社区快速验证和推广是个不小的障碍。


主要参考文献

[1] Yao, S., Luo, Y., Long, Q., et al. Beyond Global Replanning: Hierarchical Recovery for Cross-Device Agent Systems. arXiv:2606.20487, 2026.
[2] Xu, T., et al. CRAB: Cross-environment agent benchmark for multi-device task completion. 2025.
[3] Zhang, C., et al. UFO3: A multi-device agent system for task decomposition and execution. 2025b.

*本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～ 想了解更多原文细节的小伙伴，可以点击"阅读原文"，查看更多原论文细节哦！       

end
智能体干活，最怕遇到"死机"和"报错"。H-RePlan这套"分层急救术"，AI行业的小伙伴们不赶紧学起来？
欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称（如 图像处理+上海+清华+龙哥），根据格式备注，可更快被通过且邀请进群。
『龙哥读论文』微信群目前包含：图像处理、大模型及智能体、自动驾驶及机器人、AI医疗及AI金融5个群
wechat_helper dianzan
转发文章 微博 X LinkedIn Facebook
龙哥读论文 · PaperDaily

本文基于龙哥读论文 PaperDaily 数据库整理，结合论文原文与工程视角进行解读。