传统的CUA重要依赖原子化GUI操作，例如点击、输入、拖拽、滚动。这类操作泛化性强，只有界面上能看到按钮，理论上模型就能点；但它也有显著短板：步骤长、误差容易累积，在复杂工作中很容易出现cascading errors。 相反，tool calls或API-based operations往往更高效、更精确。例如在LibreOffice里批量处置表格，GUI-only规划可能必要一串冗长的菜单点击和参数配置，而工具挪用可能一个API就能实现。 在hybrid GUI-Tool action space中，Agent每一步都站在一个岔路口：左边是GUI，右边是Tool。GUI泛化强但慢，Tool快但依赖覆盖与高低文前提。若是模型短缺蹊径选择能力，就会出现两类典型失败: 最后，系统不会单一地把所有GUI操作都代替成工具，而是随机采样部门工具挪用，再代替回对应GUI子序列，形成多种GUI与Tool交错的轨迹。 其中，R_fmt和R_acc别离是尺度体式嘉奖与工作成功嘉奖；R_tool和R_length则是ToolCUA专门设计的两项轨迹级嘉奖，并且它们只在成功轨迹上激活，预防模型从失败执行里学到谬误偏好。 在数据构建时，每个工作会带一个task-level的tool-beneficial象征：t_b = 1暗示这个工作适合用工具，t_b = -1暗示这个工作不适合用工具。与此同时，c暗示整条轨迹里的tool calls数。 它要解决的正是前面提到的hybrid confusion：有些模型明明该用工具却不用，有些模型则在不该用的时辰乱用。R_tool的作用，就是把工具是否相宜这件事从工作成功里单独拎出来训练。 这样设计的益处是，模型会天然偏差于索求更短的成功蹊径。而在好多场景里，更短的蹊径刚好心味着：用一个高层工具代替一长串冗余GUI操作。因而，R_length性质上是在激励模型发现更高效的GUI-Tool execution path。 所以，这一阶段的主题并不是让模型挪用更多工具，而是让它学会两件事：什么时辰工具真的相宜，什么时辰这条执行蹊径真的更短。 ToolCUA重要在OSWorld-MCP上评测。这个benchmark在传统OSWorld的基础上引入了hybrid GUI-Tool action space，覆盖典型GUI actions、150+ tools和主流桌面利用，适合衡量模型在真实混合作为空间中的执行能力。 同样在rl_dynamics里能够看到，去掉R_tool和R_length后，只保留尺度的R_acc与R_fmt，accuracy曲线会显著更不不变，在训练step8-11左右出现降落，最终与齐全ToolCUA之间有约莫7个点的差距。 这个案例展示的不是工具始终比GUI好，而是: 当工作主题是结构化表格操作时，Tool能够绕过脆弱的逐步GUI导航，用更确定的方式实现工作。 接下来，更值得持续和推动的方向，是构建更大规模的CUA工具，训练更大规模的CUA基座模型，让CUA原生拥有hybrid actions的能力，更好地解决人类复杂问题。