给 Computer Use Agent 加上 CLI，准确率反而下降了

让 AI 操作电脑，正在成为越来越多 Agent 产品具备的能力。

10 月 1 日，GitHub 宣布在 Copilot CLI 和 Copilot app 中公开预览 Computer Use。Agent 可以读取桌面应用的信息，执行点击、输入、滚动和拖动等操作。对于没有 API、命令行接口或 MCP 集成的传统软件，这提供了新的自动化入口。

不过，很多软件本来就有更直接的操作方式。

比如，要批量修改一份表格中的数据，可以让 Agent 打开表格软件，逐个定位单元格、输入内容；也可以通过一段脚本完成修改。

前一种方式依赖 GUI（图形用户界面），后一种可以通过 CLI（命令行接口）实现。

如果让 Agent 同时掌握两种操作方式，是不是就能更好地完成任务？

9 月 29 日，浙江大学等机构的研究者发布了 HybridCUA 论文，专门研究 GUI 与 CLI 的协同执行。

实验发现，给四种已有的 Computer Use Agent 直接增加 CLI 能力，它们在 OSWorld 桌面操作基准上的准确率全部下降，降幅为 2.5～11.5 个百分点。

Agent 获得了更多工具，却完成了更少的任务。

研究者随后对模型进行了专门训练。最终，HybridCUA-9B 在 OSWorld 上取得 53.6% 的准确率，比基础模型提高了 14.8 个百分点。

同样是同时使用 GUI 和 CLI，为什么结果会出现这样的差异？

GUI 和 CLI 各有优势。

GUI 可以通过点击、键盘输入等动作操作图形软件。即使应用没有提供自动化接口，只要界面能够交互，Agent 就有机会完成操作。

但有些工作用 GUI 会很繁琐。例如，批量修改文件、处理结构化数据、安装软件依赖，或者读取某项系统配置，命令行通常可以减少大量重复步骤。

CLI 也有自己的限制。命令需要正确的语法、参数和执行环境。有些操作依赖界面中的视觉信息，很难单靠命令完成。

人类工程师往往会根据任务选择工具。编辑配置文件可能直接使用脚本，调整页面布局则更依赖视觉反馈。但对于 Agent，这种选择并不自然。

HybridCUA 的研究者将 CLI 暴露给四种现有 Agent 后，发现了两类问题。

有的 Agent 很少调用 CLI，即使一个命令就能完成的工作，仍然依赖多轮点击。另一些 Agent 则过于频繁地尝试命令行，在不合适的地方使用 CLI，或者生成无法正确执行的命令。

研究中的四种 Agent，对 CLI 的使用比例差异很大，从低于 1% 到超过 60% 都有。

能够调用某种工具，与知道什么时候该使用它，是两项不同的能力。

训练数据也是原因之一。现有 GUI Agent 的训练轨迹主要记录截图和界面操作；命令行与代码训练数据，则更多关注终端输入和执行结果。

模型可能分别见过大量 GUI 和 CLI 操作，却缺少在同一个任务中切换两种方式的经验。

于是，研究者开始让模型专门学习这件事。

HybridCUA 的训练分为两个阶段：先学习操作轨迹，再通过强化学习改进工具选择与命令执行。

第一步，构造包含不同操作方式的训练数据。

研究团队构建了 HybridCUA-8K 数据集，其中包含 5023 条监督训练轨迹和 3000 项带有可执行验证器的强化学习任务。

监督训练轨迹分为三类：

这些数据让模型看到不同的执行路径。

一个任务可能需要先通过 GUI 找到正确的软件和文件，再使用脚本修改内容，最后返回界面检查结果。模型需要学习在不同操作方式之间切换，并把前一步的结果交给后一步。

HybridCUA 还采用了统一的动作接口。

无论执行 GUI 还是 CLI 操作，模型都通过 bash 工具发起调用。例如，点击界面时，可以通过 Bash 执行包含 PyAutoGUI 调用的 Python 代码；需要直接操作文件时，则执行相应的 Shell 命令或 Python 脚本。

这样，两种操作可以使用相同的动作格式。统一接口简化了调用方式，但通过 Bash 执行一次鼠标点击，仍然属于 GUI 操作。

模型完成动作后，会收到当前屏幕截图；直接执行命令时，还可以获得标准输出或错误信息，用来判断后续操作。

第二步，通过强化学习改进工具选择。

这里有两个不同的问题。

首先，什么时候应该使用 CLI？

研究团队为训练任务建立标签，标明 CLI 是否具有明显的执行优势。这个判断来自不同操作模式下的多次执行结果。

只有任务完成成功，并且模型的 CLI 使用选择符合标签要求，才能获得相应奖励。

所以，训练目标是让模型有选择地使用 CLI，而非尽可能多地调用命令行。

其次，怎样减少命令执行错误？

研究者增加了针对 CLI 命令失败的惩罚。如果某个命令执行失败，训练会将负面反馈定位到产生错误的具体动作。

这两类奖励分别影响工具选择和命令可靠性。

消融实验提供了对应证据：去掉工具选择奖励后，模型使用 CLI 的比例有所下降，执行步数的改善幅度也变小；去掉命令失败惩罚后，CLI 执行错误率上升，而整体准确率并没有出现同等幅度的变化。

任务最终成功，不代表每一步都执行得合理。

有的 Agent 可能通过很多次试错才完成任务，有的则在正确的位置使用命令，以更少的步骤得到结果。

HybridCUA 将工具选择和命令执行分别纳入训练，为这两类问题提供了不同的反馈。

论文展示了一个文档格式调整的案例。

任务要求修改一份 Writer 文档的排版：统一字号，并分别设置引言、正文和结论的行距。

如果完全依赖 GUI，Agent 需要反复选择段落、定位菜单、调整格式。

HybridCUA 则先通过 GUI 定位 Writer 窗口并打开相关菜单，再通过 python-docx 修改文档中的字号和行距，保存文件。之后，模型重新读取保存后的文档，检查最终格式是否符合要求。

其中一次操作甚至在同一个 bash 调用中，先通过 PyAutoGUI 关闭菜单，再通过脚本重新读取文件检查结果。

这展示了两种层次的配合：一是不同步骤使用不同操作方式；二是在同一步中组合界面操作和程序调用。

研究团队还展示了一个 VS Code 主题修改任务。

Agent 先通过 CLI 安装主题扩展，再通过 GUI 打开主题选择界面，预览并确认目标主题。最后，它通过命令读取已保存的 workbench.colorTheme 配置，确认修改结果。

这两组案例有一个共同特点：

GUI 负责需要界面定位和视觉判断的操作，CLI 处理适合程序化执行的修改与状态检查。

研究中的行为统计也支持这种分工。例如，在 HybridCUA-9B 的测试轨迹中，内容编辑类动作有 85.8% 使用 CLI，结果验证类动作有 98.4% 使用 CLI；涉及空间位置调整时，GUI 动作占 58.4%。

这些比例来自特定模型和测试任务，不能当作通用工具选择规则。不同任务的操作要求有所差异，Agent 需要根据当前工作决定使用哪种方式。

CLI 也没有取代 GUI。论文中的 Thunderbird 任务就出现了性能下降，说明混合训练并非对所有软件和任务都有效。

工具选择解决了一部分问题，但 Agent 即使选对了操作方式，也可能因为缺少专业知识而无法完成任务。

同期另一篇论文 MatToolBench，研究了 Agent 使用专业材料科学软件的能力。

研究团队在 Windows 11 虚拟机中构建了 204 项任务，覆盖十种工具，包括 GUI 操作、OriginPro 脚本和材料数据库查询。

结果显示，即使是表现最好的模型，GUI 类任务的成功率也只有 25%，代码类任务中的最高成功率为 45%。

问题包括专业操作知识不足、跨软件产物交接失败，以及某些关键状态只能从界面观察。

例如，材料分析可能需要先在 JADE 中处理 XRD 数据，再将结果交给 OriginPro 绘图。两个软件各自能够操作，还不够。

前一个软件输出的文件位置、格式和数据必须满足后一个软件的要求。否则，即使每一步操作看起来正确，完整任务仍可能失败。

MatToolBench 与 HybridCUA 使用不同的任务和评测环境，两者的成功率不能直接比较。

不过，它们共同暴露了一类工程问题：Agent 操作软件时，需要同时处理操作接口、专业规则、跨工具交接和结果检查。

工具能执行某个动作，只是完成任务的一个条件。

回过头看，GitHub 扩展桌面 Computer Use，与 HybridCUA 的研究关注的是两个相互关联的问题。

前者增加了 Agent 能够操作的软件范围，后者研究的是，当 GUI 和 CLI 都可以使用时，Agent 怎样选择更合适的方式。

对实际工程系统来说，还需要把这两项能力连接到结果验证。

例如：

同时，CLI 往往可以直接操作文件和系统环境。使用更高效的命令，需要配套明确的执行权限、沙箱约束和操作记录。

GitHub 的 Computer Use 公开预览也保留了用户授权环节，控制桌面应用前需要获得批准。

HybridCUA 的实验主要在可重置的隔离环境中进行，尚不能证明这种训练方式已经能够可靠地处理企业生产任务。

但它回答了一个明确的研究问题：直接给 Agent 增加命令行接口，无法保证任务成功率；通过混合轨迹和有针对性的训练，模型可以改善工具选择与执行表现。

Computer Use 已经能够进入越来越多的应用。

接下来，Agent 还需要学会根据任务选对工具、在不同软件之间交接结果，并确认操作真正完成。

这些能力会决定 Computer Use 能承担多复杂的真实工作。