GUI-HARVEST：让GUI智能体从执行证据中自我改进

导语

GUI智能体通常被理解为“能看懂屏幕并点击操作”的视觉模型，但真正决定任务能否完成的，往往是模型周围的执行框架（harness）：它如何组织观察信息、把模型输出转换成动作、判断任务是否成功，以及在失败后是否重试或恢复。GUI-HARVEST提出了一条不同于微调模型的路线：冻结模型权重，持续改进包裹模型的执行框架。

核心方法

GUI环境比文本工具调用更难诊断。模型可能提出了合理意图，但点击位置偏移、界面响应延迟或应用状态变化，都会让最终结果与计划不一致。GUI-HARVEST试图把“模型想做什么”和“屏幕实际上发生了什么”对应起来，主要包含三步：

• 用视觉变化支撑诊断。 系统将模型输出和实际执行动作，与动作前后的截图对齐，分析具体界面转移，而不是只根据任务成功或失败这一最终标签判断问题。
• 把重复运行视为联合证据。 同一任务可能因执行时机、界面状态或动作结果不同而产生不同结局。通过比较多次运行，系统寻找真正与结果相关的行为差异，降低偶然性的影响。
• 从个案提炼可复用修复。 来自不同任务的已验证发现会被汇总为重复出现的失败模式，再映射为受约束的源代码修改。系统在评估前记录修改将产生的行为预测，并同时检查预测效果与任务性能。

这种设计使框架演化不再只是让语言模型“猜一个更好的提示词”或随意改代码，而是形成“观察—归因—修改—验证”的闭环。

实验结果与意义

在OSWorld-Verified上，GUI-HARVEST覆盖六个通用、GUI专用和商业模型，并在展示的模型与步数预算组合中都取得最高成绩。实验还在15步预算下进行优化，再以15、50和100步评估，优化后的框架保持不变。素材显示，Qwen3-VL-32B-Instruct相较初始框架提升12.33个百分点；Gemini 3.1 Pro在100步设置下达到79.14%。

这项工作的价值在于重新界定了GUI智能体的改进对象。模型能力固然重要，但观察压缩、动作执行、验证器、恢复策略和终止条件同样可能成为瓶颈。通过冻结骨干模型并优化运行时框架，研究者可以更清楚地评估系统工程改动带来的收益，也更容易把一个任务中的修复迁移到其他任务。

不过，这种方法的上限仍取决于截图和轨迹提供的证据质量、失败归因是否准确，以及代码修改能否避免破坏已有能力。未来，如何控制跨任务迁移风险，并在更复杂、更开放的桌面环境中保持稳定，仍是GUI智能体走向可靠部署时需要解决的问题。

来源：Hugging Face Daily Papers