OS-Helix：统一 GUI 交互与代码执行的桌面
来自 arXiv · 期号 2026-10-16
摘要
桌面自动化既不能只靠视觉，也不能只靠代码。Agent 既要理解用户界面，又要高效操作文件、脚本和系统状态。 现有方案把 GUI 工具和代码工具简单拼在一起，效果反而下降。OS-Helix 的做法是：在训练阶段就把两种能力融合进同一个动作空间。 为此，作者设计了一套数据构造流程——把桌面应用和真实文件打包成可执行的 Ubuntu 环境，再通过解耦的指令/评估器生成可验证的任务。先用 SFT 冷启动，再用在线 RL 进一步优化。RL 阶段提出了 Step-balanced GSPO，按动作步数而非 token 数聚合权重，防止长代码动作主导优化。 在 OSWorld-Verified 上，OS-Helix-27B 和 OS-Helix-35B-A3B 分别比对应的 Qwen3.5 混合基线提升 35.0% 和 33.7%；27B 版经 RL 后进一步提升 42.9%，达到 66.44% 成功率。消融实验证实了 GUI/代码协调学习、可验证监督和步平衡优化的贡献，并在 WindowsAgentArena 上验证了跨平台迁移能力。
深读
导读 桌面自动化 Agent 长期面临一个两难：纯视觉方案无法操作文件系统，纯代码方案看不懂界面。OS-Helix 在训练阶段就把 GUI 操作和代码执行融合进同一个动作空间，而非简单拼装工具。读完能带走一套可验证的混合数据构造方法和一种按动作步数平衡优化的在线 RL 策略。 关键信息 - 作者来自 Cornell University，论文发布于 arXiv。 - 在 OSWorld-Verified 上，OS-Helix-27B 和 OS-Helix-35B-A3B 分别比对应的 Qwen3.5 混合基线提升 35.0% 和 33.7%；27B 版经 RL 后进一步提升 42.9%，达到 66.44% 成功率。 - 初步实验显示，简单给 GUI Agent 添加一个代码工具反而导致性能下降，说明 GUI/代码的路由必须通过训练内化。 - 提出了 Step-balanced GSPO，按动作步数而非 token 数聚合重要性权重，防止长代码动作主导异构动作空间的优化。 - 在 WindowsAgentArena 上验证了跨平台迁移能力。 逐节讲解 问题：GUI 与代码的协调无法通过提示工程解决 现有桌面自动化方案要么只依赖视觉（截图+点击），要么只依赖代码（脚本、命令行），但真实任务往往需要两者配合。作者在初步实验中发现，给一个纯 GUI Agent 简单加上一个代码工具后，整体性能反而下降。这说明 GUI 操作和代码执行之间的路由选择不能靠 prompt 层面的工具组合来实现，必须通过高质量混合数据的训练内化到模型参数中。 方法：数据构造与训练流程 OS-Helix 的核心贡献在于一套完整的数据和训练方案。首先，应用-工件组合（application-artifact composition）将桌面应用与真实的文件工件配对，打包成可执行的 Ubuntu 系统状态。然后，解耦的指令/评估器生成流水线（decoupled instruction/evaluator generation pipeline）产生环境可验证的任务，无论 Agent 用 GUI 还是代码完成，最终状态都能被自动判定。 训练分两步：先用监督微调（SFT）在过滤后的混合数据上冷启动策略，再通过在线强化学习（RL）在真实桌面环境中进一步优化。RL 阶段提出的 Step-balanced GSPO 是关键改进：它按动作步数（action step）而非原始 assistant token 数来聚合重要性权重，从而防止长代码动作在异构动作优化中占据主导。 结果与消融 在 OSWorld-Verified 基准上，OS-Helix-27B 和 OS-Helix-35B-A3B 相比对应的 Qwen3.5 混合基线分别提升 35.0% 和 33.7%。27B 版本经 RL 后进一步提升 42.9…