H-RePlan：当AI助手在手机和电脑之间卡住时，分层恢复比推倒重来更聪明

想象这个场景：你让 AI 助手帮你完成一个报销流程。它需要从手机上的发票 App 截图发票，传到电脑上整理成文件夹，然后上传到报销系统。

AI 助手顺利地从手机读到了发票信息。但在电脑上执行 git clone 下载一个模板的时候，网络抽风，命令行报错了。

现有的多设备智能体系统会怎么做？三种选择：重试同一个命令（大概率还是失败）、把这个子任务重新分配给另一个设备（但这个任务就必须在电脑上做）、或者推翻整个全局计划重新规划（杀鸡用牛刀）。

无论哪种，都不太聪明。因为真正的问题很简单：命令行这条路走不通了，换一条路——用浏览器下载——就行了。

上海交通大学的 Shu Yao 团队在 H-RePlan 论文里解决的就是这个问题：当多设备智能体遇到执行失败时，如何区分"这个策略不行"和"这个任务不行"，然后做出恰当的恢复。

三条腿比一条腿稳

H-RePlan 的核心设计是给每个设备配备三种可互换的执行策略：

• API Agent：通过结构化接口访问服务，最可靠，但不是所有功能都有 API
• CLI Agent：命令行操作，适合本地计算和文件系统操作，但依赖环境配置
• GUI Agent：图形界面操作，最通用（人能用的它都能用），但最慢最贵

这三种策略各有强弱。API 快但覆盖面窄；CLI 中等但依赖环境；GUI 慢但万能。关键在于：当一种策略失败时，可以切换到另一种策略，而不需要推翻整个计划。

这就像你去上班：地铁故障了换公交，公交堵了骑共享单车。你不需要因为地铁故障就重新决定"今天要不要去上班"——你只需要换一条路。

分层恢复：该局部局部，该全局全局

H-RePlan 的"分层"体现在它把失败分成两个层级：

设备层（Strategy Planner）：当一个策略执行失败时，Strategy Planner 先判断这是不是策略级别的问题。如果是 git clone 失败，可能是网络问题，换浏览器下载就行——这不需要通知全局。Strategy Planner 有权在设备内部切换策略、修改指令、重试。

系统层（Orchestrator）：如果设备层判断这个失败不是策略能解决的——比如这台设备根本缺少必要的资源——才把失败上报给 Orchestrator，由全局来决定是重新分配任务给其他设备，还是修改全局计划。

中间的桥梁是一个叫 Cross-Layer Failure Event (CLFE) 的紧凑抽象：设备层把失败信息打包成一个结构化的事件，包含失败类型、已尝试的策略、失败原因等，让 Orchestrator 能快速判断该不该升级处理。

这个设计的关键洞察是：大多数失败都是局部的，不需要全局重规划。 如果你每次遇到一个策略失败就推翻全局计划，你会在不必要的重规划上浪费大量 token，而且可能丢失已经完成的上下文。

HeraBench：故意往流水线里扔故障

为了评估分层恢复的能力，作者构建了 HeraBench——一个故障注入式的多设备基准测试。它在 Linux 和 Android 设备上构造跨设备工作流，然后故意注入两类故障：

• 策略级故障：某个执行策略失效（比如 CLI 命令不可用）
• 设备级故障：整个设备出问题（比如设备离线）

这种设计让你能精确测量：智能体在遇到策略故障时能不能局部恢复？在遇到设备故障时能不能全局调整？

数字说话

在 HeraBench 上的主实验结果：

几个关键读数：

• H-RePlan 的完成率（75.84%）比最强的基线 UFO³ API（61.05%）高近 15 个百分点
• 完美通过率（36.78%）——即完全正确且无偏差地完成任务——比 UFO³ GUI（13.79%）高近 23 个百分点
• UFO³ API 虽然完成率不低，但完美通过率是 0%——它完成了任务但经常偏离指令
• Token 效率：H-RePlan 每次完美通过需要 193 万 token，UFO³ GUI 需要 1052 万——5.4 倍的效率差距

局部恢复的价值

论文里有一组数据特别能说明分层恢复的逻辑：

• 策略级故障不升级（在设备内解决）：完成率 76.81%，遵循率 82.00%
• 策略级故障过早升级（前两次尝试就上报全局）：完成率 68.89%，遵循率 62.22%

过早升级反而更差。因为升级意味着上下文丢失——Orchestrator 不了解设备内部已经尝试了什么，重新规划时可能重复已失败的路径，或者分配给不合适的设备。

另一组数据：当策略级故障最终需要重新分配时，分配回原设备的完成率是 91.7%（55.8 万 token），分配给其他设备的完成率只有 62.7%（101 万 token）。

这反直觉吗？不。原设备已经积累了上下文——它知道这个任务是什么、之前试过什么、环境状态是什么。换一个设备，这些上下文全丢了，得从头来。所以除非确认原设备真的不行了，否则不要急着换设备。

这意味着什么

H-RePlan 的贡献不是"又一个多设备智能体框架"，而是它对"失败处理"的重新定义。

现有的智能体系统在失败处理上太粗粒度了：要么重试，要么重分配，要么重规划。H-RePlan 说：失败是有层次的，恢复也应该有层次。 一个策略失败不需要推翻一个任务，一个任务失败不需要推翻一个计划。

这个思路不只适用于多设备场景。任何复杂的 AI 智能体系统——单设备的也好，多智能体的也好——都会遇到"某条路径走不通"的情况。H-RePlan 的分层抽象（策略层 vs. 任务层 vs. 计划层）是一个通用的设计模式。

从工程角度看，H-RePlan 的 API-CLI-GUI 三策略设计也很实用。之前的多设备系统通常每个设备只暴露一种策略——要么 GUI 要么 CLI——这限制了恢复能力。H-RePlan 让每个设备都拥有三种策略的可选集，虽然实现复杂度更高，但换来了显著鲁棒性提升。

诚实的局限

H-RePlan 目前依赖 Linux 和 Android 两个平台。iOS 因为系统限制无法提供 CLI 策略，Windows 的 GUI 自动化机制和 Linux 完全不同。跨平台统一策略空间在工程上还有很长的路。

另外，H-RePlan 的 Orchestrator 和 Strategy Planner 都依赖 LLM 做决策——这意味着它的恢复能力受限于 LLM 的推理质量。如果 LLM 判断错了失败类型（把设备级故障当成策略级），整个分层恢复的逻辑就会失效。

但作为一个"分层恢复"的概念验证，H-RePlan 已经足够有说服力。下一次你设计一个多步骤的 AI 智能体系统，先问自己：我的失败处理是分层的吗？

论文链接：https://arxiv.org/abs/2606.20487