CVPR 2026 | 失败反馈驱动数据生成：HATS 构建更可靠的 GUI Agent 训练数据

GUI agent 任务存在一个问题模型会点按钮、会滚动、会输入可这并不代表它真懂界面任务。真正的任务往往是环环相扣的——同样的“”图标在不同页面可能是新建文件、添加联系人或创建任务同样的确认按钮只有前置步骤完成后才有意义。我们今天要介绍的论文HATS正是从这类“语义歧义动作”入手。论文发现现有轨迹合成方法收集的数据里超过 70% 是“返回”“打开菜单”这类简单动作真正暴露模型弱点的复杂样本反而稀缺。结果就是模型看似学了很多轨迹实则没真正学会处理上下文依赖和顺序判断。论文标题 HATS: Hardness-Aware Trajectory Synthesis for GUI Agents作者 Rui Shao、Ruize Gao、Bin Xie、Yixing Li、Kaiwen Zhou、Shuai Wang、Weili Guan、Gongwei Chen 等作者机构 哈尔滨工业大学深圳、新加坡国立大学 / CNRSCREATE、深圳环区研究院、华为诺亚方舟实验室会议 CVPR 2026项目链接https://github.com/JiuTian-VL/HATS推荐理由这篇论文最值得推荐的地方是它没有止步于筛掉低质量生成样本而是把样本中暴露出的对齐困难进一步转化为指导下一轮数据生成的反馈信号。很多数据合成流程遇到“不好复现”的轨迹第一反应是清洗、过滤、丢弃HATS 换了个视角不好对齐往往说明这里存在上下文缺失、顺序依赖或视觉歧义而这些恰恰是 GUI agent 最需要训练的地方。图 3 是 HATS 的架构图。它先用 Hardness-Driven Exploration 找更难、更有信息量的轨迹再用 Alignment-Guided Refinement 检查 instruction 是否能被重新执行出来。如果 instruction 和原始轨迹对不上系统会继续补充上下文和操作细节同时这种“不好对齐”的反馈还会进入 HD-MCTS影响后续探索。这条闭环怎么跑先探索再回放再修 instructionHATS 的主流程是一个“探索—生成—回放—修正—回传”的闭环。1、先把 GUI 交互建成一棵 action tree输入是一个 GUI environment。每个时刻agent 看到当前界面状态也就是 screenshot 和可选 UI tree然后执行 TAP、TYPE、SCROLL、BACK、LONG-PRESS、SWIPE 等动作。HATS 把这些状态和动作组织成 action tree节点是界面状态边是动作。探索时它用 UCB policy 选择下一条边这里的 表示当前动作边的价值估计 是这条边被访问的次数 是节点访问次数 控制探索强度。普通 MCTS 的 往往来自任务奖励HATS 的特别之处在于 后面会被 alignment-derived hardness reward 更新。对比 OS-Genesis 的 random exploration 与 HATS 的 hardness-driven exploration说明为什么 HATS 不只是随机走界面2、从 noisy exploration trace 里抽出可描述的子任务探索得到的原始轨迹通常很乱可能包含重复点击、无意义跳转或和目标无关的动作。因此 HATS 先从 rollout path 里抽取一个语义连贯的 sub-trajectory记为 Reference Sequence A。随后系统把 A 转成自然语言 instruction I。注意这一步生成的 instruction 还不能直接进入训练集它只是一个待验证版本。3、让 instruction 自己回放一遍再算对齐率接下来agent 从 A 的初始状态出发按照 instruction I 执行得到 Execution Sequence B。A 里那些应该完成的动作有多少能在 agent 实际执行出的 B 里找到语义等价匹配?于是HATS 用以下公式来衡量越高说明 instruction 越能复现原轨迹反之说明它可能漏了关键上下文、前置步骤或 UI 元素。对比 one-shot instruction generation 与 multi-round alignment-guided refinement说明 HATS 为什么要反复 replay 和修正 instruction。4、对不上就继续修把低对齐变成 hardnessrefinement 的目标是让 instruction 更可执行、更能复现 reference sequence。它会补充目标元素、UI 文本、顺序要求、滚动动作、确认按钮等细节直到通过验证或达到 refinement budget。这时 HATS 把 alignment recall 转成 hardness reward越低 越高。也就是说越难对齐的轨迹会在后续搜索里被当作更“硬”的区域。这里要注意HATS不是把所有低对齐轨迹都直接收进训练集。最终进入训练语料的仍然是通过 alignment verification 的 verified trajectory低对齐本身更多是作为探索反馈告诉系统哪里值得继续找难例。5、把 hardness 回传下一轮探索就会被它影响得到 hardness reward 后HD-MCTS 会沿搜索路径更新访问次数和 Q 值这就是闭环形成的地方探索产生轨迹轨迹生成 instructioninstruction 被 replay 验证验证得到 hardnesshardness 再回传到搜索树影响下一轮探索。展示同一任务 instruction 在三轮 refinement 中如何逐步补充 UI 元素、顺序和上下文细节。实验结果实验部分作者使用两个 GUI benchmark。AndroidWorld覆盖移动端任务共 116 个 evaluation tasks并按 Daily Life Services、Social Communication、System Utility、Productivity Work 四类划分。WebArena覆盖网页任务论文选择 Gitlab、Maps、Reddit 三个 domain分别包含 180、109、106 个任务。1、AndroidWorld 上HATS 对 OS-Genesis 是稳定提升InternVL2-4B 上HATS 比 OS-Genesis 高11.30个百分点InternVL2-8B 上高 9.54 个百分点Qwen2-VL-7B 上高12.85个百分点三组 backbone 平均下来HATS 的 overall success rate 是 23.77OS-Genesis 是 12.54平均高11.23个百分点。2、WebArena 上HATS 也能拉开 OS-GenesisWebArena 的差距更直观。InternVL2-4B 上HATS 比 OS-Genesis 高14.07个百分点InternVL2-8B 上高16.71个百分点Qwen2-VL-7B 上高10.47个百分点如果取三个 backbone 的平均值HATS 是 22.92OS-Genesis 是 9.17平均高13.75个百分点。3、消融结果Recall 比 precision 更适合抓漏步骤。Table 3 比较了不同 epsilon 和 alpha。设置 epsilon0.01、alpha1 的 success rate 最高。Table 4 进一步比较 recall-based metric 和 precision-based metric结果显示 recall-based metric 对下游 performance 更有帮助。4、HATS 确实把采样挪向更难类别作者报告相对 baselineHATS 把 AndroidWorld 中 Productivity Work 类别的采样占比从 31.2% 提升到 46.6%同时把更容易的 System Utility从 30.8% 降到 18.9%。这说明它确实在把采样预算从简单类别挪向更困难的交互类型。5、Round 3 优于 One-Shot但不是每轮都涨。Table 5 显示One-Shot 的 R_avg 是 0.26success rate 是 16.00到 Round 3R_avg 变为 0.40提升 0.14success rate 变为 23.07提升 7.07 个百分点。不过这里有一个细节值得注意Round 1 的 R_avg 和 success rate 低于 One-Shot。更严谨地说论文能支持的是“多轮 refinement 继续推进到 Round 3 后优于 One-Shot”而不是从 One-Shot 开始每一步都单调提升。总结HATS 最有特色的设计是把 instruction-execution misalignment 转成 hardness signal对不齐的地方不只是噪声也可能是上下文缺失、顺序依赖或视觉歧义集中出现的地方。HATS 用这个信号反过来指导探索再用 replay/refinement 把难轨迹洗成可训练样本。从结果看HATS 的主实验和消融都支持一个结论更有针对性的 hard trajectory synthesis确实比随机探索和 one-shot 指令生成更适合训练 GUI agent。但它的边界也很清楚方法依赖 GPT-4o 做生成、验证和审计绝对 success rate 仍然不高成本与可复现性还需要进一步说明。