GUI vs. CLI: 屏幕代理与技能中介计算机使用代理的执行瓶颈 GUI vs. CLI: Execution Bottlenecks in Screen-Only and Skill-Mediated Computer-Use Agents
通过440任务基准测试揭示GUI与CLI代理在不同交互模式下的执行瓶颈与互补优势
前置知识
计算机使用代理
计算机使用代理是指能够通过图形界面或程序化命令界面与软件应用程序交互并执行任务的AI系统。GUI代理通过观察屏幕截图并执行点击、拖拽、输入、滚动等屏幕级操作来完成任务，类似人类操作方式。CLI代理则通过调用程序化技能或命令来操作应用程序状态，这些技能将应用程序能力封装为可组合的操作。本文研究的计算机使用代理专注于桌面环境中的任务执行，需要在沙箱环境中完成从简单的音频编辑到复杂的多页图表构建等各类工作流程。
理解计算机使用代理是读懂本文的基础，因为整篇论文的核心就是比较两种不同交互模式下的代理执行能力。如果不清楚GUI和CLI代理各自的工作方式和限制，就无法理解实验设计和结果分析的意义。
技能中介CLI
技能中介CLI是一种受限的命令行交互模式，代理只能通过预定义的技能层来操作应用程序，而不能使用不受限制的shell命令或直接编辑文件。CLI-Anything等框架将各种应用程序打包为可重用的命令行工具，代理通过调用这些工具提供的特定命令来完成操作。与传统的无限制编程访问不同，技能中介CLI要求代理依赖精心设计的技能接口，这些接口决定了代理能够执行哪些操作以及如何影响应用程序状态。
本文的CLI设置严格遵循技能中介范式，这是与无限制编码能力的关键区别。理解这一概念有助于明白为什么CLI代理的性能如此依赖于技能覆盖范围，以及为什么验证器引导的技能补丁能够显著提升CLI成功率。
执行层验证
执行层验证是一种基于最终状态的任务成功评估方法，与基于轨迹匹配的评估形成对比。每个任务包含可执行的验证器检查点，这些检查点直接检查任务相关的应用状态和工件，而不是验证代理是否遵循了预定义的操作序列。例如，对于创建命名音轨的任务，验证器会检查最终保存的项目文件中是否确实包含了正确名称的音轨，而不关心代理是如何创建它们的。
执行层验证是本文实验设计的核心，它使得相同任务能够在GUI和CLI两种不同模式下用相同标准进行评估。理解这一概念有助于明白为什么论文能够分离交互模式的影响，而不是让任务差异混淆比较结果。
研究动机
现有的计算机使用代理评估存在严重的混淆问题，它们同时改变了多个因素：目标应用程序、初始状态和最终状态验证器、以及允许的操作空间。当所有这三个因素同时变化时，观察到的成功或失败无法揭示性能差异是来自模型能力、任务设置，还是交互模式本身。例如，GUI导向的基准测试如OSWorld和AndroidWorld与程序化代理基准测试如AppWorld和TerminalBench在任务设计、验证机制和操作限制上都存在本质差异，这使得跨模式的比较变得不可靠。这种混淆阻碍了研究者理解GUI和CLI交互各自的优势和限制，也难以确定性能瓶颈的真正来源。
本文的目标是本文的目标是创建一个受控的执行层基准测试，用于在保持任务目标、初始状态和最终状态验证器完全相同的前提下，系统性地比较GUI和技能中介CLI代理的执行能力。具体而言，作者构建了一个包含440个桌面任务的基准测试，涵盖18个真实应用程序和12个工作流程类别，其中两种模式接收相同的用户目标、初始状态和可执行的最终状态验证器。每个任务被重写为模式中立的指令，仅描述期望的结果，而每个代理被限制在其模式原生的操作空间内，从而控制任务内容、初始状态和验证，同时系统性地改变原生操作接口。
与已有工作不同的是，本文的独特切入角度在于意识到现有的GUI与CLI比较本质上是在比较不同的系统设计，而不仅仅是不同的交互模式。作者提出的问题不是哪种界面更好，而是任务结构应该被工程化到哪里：是到应用程序的可见界面中，还是到定义代理可用操作的构建技能层中。通过识别出原始CLI技能只满足37.6%的验证器检查点，并通过验证器引导的补丁将CLI成功率从48.2%提升到69.3%，论文揭示了CLI差距的主要来源是技能覆盖不足而非模型能力。这一视角将GUI与CLI的比较从界面排名问题重新构建为计算机使用系统的设计问题。
核心方法
本文的方法采用三阶段基准测试构建流程，旨在创建一个受控的GUI-CLI评估套件。首先，从OpenComputer中选择具有CLI-Anything技能支持的应用程序，确保每个选中的应用程序都可以通过视觉交互和程序化执行两种方式操作。其次，将原始的逐步GUI导向指令重写为模式中立的任务描述，指定目标状态而非GUI特定程序，并策展任务集以减少界面偏差。最后，手动验证策展后的任务，确保每个任务都针对执行层能力，并且可以相同方式给两种模式。通过这种严格的设计，论文能够分离交互模式的影响，同时控制任务内容、初始状态和验证。
本文的核心创新点在于设计了一个匹配的执行层协议，该协议保持任务目标、初始状态和最终状态验证器在GUI和技能中介CLI代理之间固定，同时强制执行模式原生的操作空间。与现有评估混淆多个因素不同，本文确保两种代理接收相同的用户目标、初始状态和可执行的最终状态验证器，但被限制在不同的操作空间内：GUI代理只能通过屏幕级操作完成任务，而CLI代理必须通过技能层工作流或应用级命令完成任务，不能依赖直接编辑输出文件等快捷方式。这种设计使得性能差异能够被归因于交互模式本身，而非任务设置或模型能力。
方法步骤详情
基准测试构建分为三个阶段：第一阶段是应用和任务选择，从OpenComputer开始选择应用程序，为这些应用程序寻找对应的CLI-Anything技能，确保每个选中的应用程序都可以通过视觉交互和程序化执行两种方式操作。第二阶段是任务重写和策展，将原始的逐步GUI导向指令重写为模式中立的任务描述，指定目标状态而非GUI特定程序，删除那些结果依赖于一种界面或在另一种界面中没有对应任务的任务，并在需要时添加任务以偏移任务集不平衡。第三阶段是手动验证，手动检查策展后的任务，确保每个任务都针对执行层能力，可以通过两种模式在基准测试约束下解决，并且指令避免模式特定的程序提示，同时指定可由两种设置中相同验证器评估的精确目标状态。
技术新颖性
本文的技术新颖性体现在多个方面。首先，论文创建了首个真正匹配的GUI-CLI执行层基准测试，通过系统性变异原生操作接口同时控制其他因素，解决了现有评估的混淆问题。其次，作者开发了验证器覆盖管道来诊断CLI技能覆盖不足问题，发现原始CLI-Anything技能只满足37.6%的验证器检查点，这一诊断方法量化了技能不完整性对性能的影响。第三，论文提出了程序引导的任务重写方法，通过在指令中添加菜单路径、对话框确认、操作顺序和精确对象名称等工作流程提示，测试GUI执行错误是否可以被减少。最后，研究识别了两种模式的互补失败模式：GUI受限于视觉定位和长工作流程执行，而CLI受限于技能接口的覆盖范围和可扩展性，这一错误分类为理解不同交互模式的瓶颈提供了新视角。
实验结果
实验结果表明交互模式可以补偿模型限制。最强的GUI代理GPT-5.4达到了59.1%的全通过率，紧随其后的是Claude Opus 4.7的55.9%，而最强的原始技能中介CLI代理Codex GPT-5.5达到48.2%。由于任务、初始状态和验证器在模式间保持不变，这些差异反映了模型能力和交互设计的综合效应，而非任务变化。值得注意的是，通过GUI接口操作的GPT-5.4大幅优于通过技能中介CLI操作的Codex GPT-5.5，尽管后者使用了更强的底层模型。这表明交互设计可以缩小甚至反转底层模型之间的性能差距。不同模式在不同的工作流程中表现出优势：GUI在应用程序界面直接暴露预期工作流程的领域表现更好，如音频、演示、通信和Web任务；CLI在目标状态可以表示为结构化工件或应用级操作的领域具有竞争力或更强，如视觉设计、CAD和3D、文档、视频和流媒体以及游戏任务。验证器引导的技能补丁实验显示，从原始技能设置移动到补丁技能设置将整体成功率从48.2%提升到69.3%，特别是在知识、图形调试和通信等结构化工作流程类别中获得巨大提升。这表明许多CLI失败是由不完整或表达不足的技能接口而非模型限制引起的。程序引导的任务描述对GUI性能的提升相对温和，全通过率从59.7%变为60.2%，平均奖励从0.7401变为0.7576，平均运行时间从397.0秒减少到314.8秒，这表明程序提示主要帮助代理识别更直接的操作路径并减少不必要的探索，而不是消除失败。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| GUI vs CLI overall performance | Full Pass Rate | GPT-5.4 GUI: 59.1% | Codex GPT-5.5 CLI (original skill): 48.2% | +10.9 percentage points |
| CLI skill coverage diagnostic | Full Pass Rate | Codex GPT-5.5 CLI (patched skill): 69.3% | Codex GPT-5.5 CLI (original skill): 48.2% | +21.1 percentage points |
| Procedural grounding for GUI | Full Pass Rate / Avg Reward / Time | 60.2% / 0.7576 / 314.8s | 59.7% / 0.7401 / 397.0s | +0.5% / +2.4% / -20.7% time |
| Audio workflow (Audacity, MuseScore) | Full Pass Rate | GPT-5.4 GUI: 73.5% | Codex GPT-5.5 CLI: 42.9% | GUI advantage +30.6 pp |
| Visual Design workflow (GIMP, Krita, draw.io) | Full Pass Rate | Codex GPT-5.5 CLI: 54.9% | GPT-5.4 GUI: 47.1% | CLI advantage +7.8 pp |
局限与改进
本文的评估存在几个局限性。首先，评估旨在分离交互模式，而非估算完全不受限制的生产代理的上限。实际部署的系统可能自由组合屏幕截图、终端、脚本、直接文件编辑、数据库访问和应用API，这些混合策略可能非常有效，但也使得难以确定成功来自GUI交互、程序化控制还是完全绕过应用接口。其次，补丁技能设置是诊断性的而非可部署的基线。在修复过程中，作者使用验证器观察到的需求来识别缺失或非序列化的技能功能，然后针对那些相同的验证器检查点验证修复后的技能。这种覆盖度量反映的是补丁技能接口是否可以生成验证器可读的检查点状态，但不保证自主代理在全任务执行期间会选择和组合正确的技能调用。第三，失败分类法旨在揭示重复模式，而非强加完美可分离的根本原因。GUI失败特别地经常混合控制发现与工作流程执行：代理可能因为不知道工作流程而找不到正确的菜单，也可能因为从未发现必要的控制而无法完成工作流程。最后，基准测试集中在桌面应用程序任务，可能无法推广到移动环境、Web专用环境或企业系统集成等不同领域。
独立分析的弱点
本文的一个主要弱点是基准测试的范围有限，仅集中在桌面应用程序任务，这可能限制了对其他计算环境的泛化能力。移动环境和Web环境有不同的交互模式和约束，本文的发现可能不完全适用于这些环境。其次，验证器引导的技能补丁依赖于验证器特定信息，这表明该方法的实用性有限，因为实际部署的系统不太可能在构建技能时访问验证器内部。未来的工作应该研究如何在不依赖验证器信息的情况下自动构建具有高覆盖率的技能接口。第三，错误分类法将每个失败分配给单个主要类别，但现实中的失败往往是多个因素交互的结果，这种简化可能掩盖了更复杂的失败机制。改进方向包括开发更细粒度的错误分析方法，捕获多个并发失败因素之间的交互。第四，程序引导的任务重写对GUI性能的提升相对较小，这可能是因为工作流程知识只是GUI交互的一个组件，即使菜单路径和对话框操作被显式化，代理仍必须正确定位界面元素、跟踪跨交互的状态并执行长操作序列。
未来方向
作者建议自然地评估不受限制的代理并测量它们的跨模式行为，这将是理解混合策略如何工作的下一步。另一个重要方向是研究技能是否可以在不依赖验证器特定信息的情况下以这种覆盖率自动构建，这仍然是一个开放问题。基于本文的成果，可以延伸的研究方向包括：开发自动技能发现和构建方法，能够从应用程序文档、用户界面或使用示例中学习技能接口；研究混合界面代理，能够动态选择和组合GUI和CLI操作以最大化任务成功率；扩展基准测试到更多应用程序类别和计算环境，包括移动设备、Web应用和企业系统集成；开发更细粒度的错误分析和诊断工具，能够捕获并发失败因素之间的交互；研究技能接口的可扩展性问题，特别是如何为复杂应用程序设计和管理大规模技能库；探索自适应技能选择和组合机制，使代理能够根据任务特征和上下文动态选择最有效的操作模式。
复现评估
本文的复现性情况较好，作者承诺数据、模型和代码将公开发布。基准测试包含440个精心策策的任务，每个任务都有明确的初始状态、目标描述和可执行的验证器检查点，这为复现提供了坚实的基础。然而，完全复现实验需要访问18个桌面应用程序的特定版本，以及确保这些应用程序在沙箱Ubuntu桌面环境中正确配置。CLI-Anything技能的可用性是另一个关键因素，虽然CLI-Anything是开源的，但某些技能可能需要额外的依赖或配置。计算资源需求方面，评估6个GUI代理和4个CLI代理在440个任务上的性能需要大量的计算时间和资源，特别是考虑到某些任务需要长达1421.8秒的执行时间。代码和配置的详细程度将影响复现的难度，特别是代理提示和环境设置的细节。总体而言，虽然复现需要一定的技术努力和资源投入，但论文提供的详细描述和承诺的开源资源使得复现是可行的。
论文图表