一项由多所高校联合开展的研究，以预印本论文形式在arXiv平台发布，编号为arXiv:2606.24551。该研究聚焦AI操控电脑的方式，通过构建公平评测平台，对比了图形界面代理（GUI agent）与命令行技能代理（CLI agent）在完成桌面任务时的表现差异，为AI自动化方案的设计与选择提供了重要参考。
在日常生活中，人类操作电脑完成调整音频、编辑幻灯片、绘制流程图等任务时，通常通过眼睛观察屏幕，手控制鼠标和键盘。然而，当AI承担这些任务时，面临两种截然不同的操作路径选择：一是像人类一样“看屏幕操作”，即GUI代理模式；二是通过预先编写的程序命令直接驱动软件，即命令行代理模式。这两种方式在研究者实验中展现出不同结果，也暴露出各自的短板。
GUI代理的工作方式与普通人类用户相似，它接收屏幕截图后，通过点击、拖拽、打字、滚动、按快捷键等动作完成任务。例如，在音频处理软件Audacity中为三段音轨命名，它会像实习生一样，盯着软件界面，逐步找到菜单、点击按钮、输入名称。而命令行代理不看屏幕，依赖为各种软件预先编写好的“技能程序”。每个技能程序明确规定了要调用软件的哪个功能、传入什么参数、得到什么结果。AI只需找到合适技能并按规程调用，即可完成任务。
此前学界已有针对GUI代理和命令行代理的评测基准，如WebArena、AndroidWorld、OSWorld等，但研究团队发现这些评测存在根本问题。它们在比较两类代理时，往往同时改变多个条件，如测试任务、软件初始状态、验收标准、允许执行的动作等。这就如同比较跑鞋性能时，让一双鞋在平路跑，另一双在山路跑，且跑的距离和终点线位置都不同，导致无法判断成绩差异是由鞋子、赛道还是规则引起。因此，研究团队构建了全新公平评测平台，为两类代理布置完全相同的任务、提供相同初始状态、使用相同验收标准，唯一区别是操作方式，GUI代理只能通过屏幕交互，命令行代理只能通过技能接口。
该评测基准涵盖440个桌面任务，涉及18款真实软件，覆盖12大工作流类别，包括视觉设计、音频处理、知识管理、工程建模、文档表格演示文稿、视频流媒体、通讯、游戏开发以及网页浏览等。任务构建分三个阶段：第一阶段是应用与任务筛选，从现有桌面任务库选取同时有命令行技能支持的软件；第二阶段是任务改写与整理，将原始为GUI操作量身定制的任务改写成“结果导向”的中性描述，去掉只适合某一种操作方式的任务，必要时补充新任务以平衡两类方式在工作流中的分布；第三阶段是人工验证，确保每道题在两种操作方式下都能完成，任务描述无暗示特定操作路径，验证标准一致，评测核心是“最终状态验证”。
在公平评测平台上，研究团队评测了多款主流AI模型。GUI代理阵营包括GPT - 5.4、Claude - Sonnet - 4.6等，命令行代理阵营有Codex GPT - 5.4、Codex GPT - 5.5等。总体成绩显示，GUI代理阵营最强选手GPT - 5.4完全通过率为59.1%，Claude Opus 4.7为55.9%；命令行代理阵营最强选手Codex GPT - 5.5使用原始技能库时完全通过率为48.2%。这表明操作方式本身可“弥补”甚至“逆转”底层模型能力差距。拆解各类工作流成绩发现，GUI代理在音频处理、演示文稿、通讯和网页浏览类任务上表现更好，这些任务需与可见控件、菜单等交互，图形界面是“母语”；命令行代理在视觉设计、工程建模、文档处理、视频流媒体和游戏开发类任务上更有竞争力，如draw.io绘图任务要求创建特定数量图形节点、标签和连接关系，命令行技能可直接操作，比用鼠标在屏幕摆放更高效准确。不过，命令行代理成绩波动剧烈，Codex GPT - 5.5在不同工作流通过率从9.8%到100%不等，而GUI代理GPT - 5.4区间是42.9%到88.2%，相对稳定，这说明GUI代理借助了应用程序界面内嵌的工作流引导，命令行代理表现高度依赖技能库覆盖情况。
研究团队对命令行代理失败案例深入分析，从80个随机抽取的失败任务中归纳出三种主要失败模式。一是“技能覆盖与契约缺口”，命令行代理行动边界由技能库决定，若软件功能无对应技能则无法下手，且有时技能文档与代码实现不符，导致代理执行流程但验收失败，如FreeCAD任务中技能误解析文件格式。二是“隐性默认值重建错误”，人类通过图形界面操作时，很多默认设置等由软件界面自动提供，命令行代理需显式处理，稍有偏差就失败，如FreeCAD添加球体任务中代理错误处理内部名称和用户标签区别。三是“不可观测的应用语义”，命令行代理只能看到技能接口暴露的信息，关键软件内部逻辑未呈现时，代理靠猜测填补空白，常出错，如Audacity修改默认采样格式任务中代理猜错字段。统计显示，命令行代理失败93.8%集中在技能覆盖与契约缺口，说明其核心瓶颈是技能库不完善。
相比之下，GUI代理失败模式集中在工作流执行失败和界面导航和控件发现失败。界面导航和控件发现失败指代理无法可靠找到正确操作路径，如Zoom配置任务中代理未找到正确操作入口。工作流执行失败指代理找到大致正确方向，但无法完成特定顺序操作序列，如Zotero的PDF附件任务中代理到达正确上下文但未完成“附加文件”工作流。还有“自我检查与验证缺口”，代理完成交互操作就宣告任务完成，未验证最终产出是否符合要求，如Audacity标签导出任务中代理未确认文件是否写入磁盘。统计表明，GUI代理核心瓶颈是长序列界面操作易中途出错、复杂菜单层级难可靠导航以及缺乏对最终状态的主动验证。
针对命令行代理主要失败原因是技能库不完善的问题，研究团队设计了“验收引导的技能修补”诊断性实验。他们对每款软件的CLI - Anything技能库进行系统性审查，先检查每个验收检查点现有技能能否满足要求，标记为“通过”“部分”或“失败”，原始技能库仅覆盖37.6%验收检查点。然后对标记为“部分”或“失败”的检查点修复技能实现，修复后覆盖率达100%。使用修补后的技能库，Codex GPT - 5.5整体通过率从48.2%跃升至69.3%，某些工作流类别提升幅度惊人，如知识管理类从22.4%升至81.6%。同时，修补后执行平均时间从188.1秒降至162.6秒，说明技能完善后代理执行效率提高。不过，研究团队指出这是诊断性上界估计，不能当作命令行代理在现实中的真实表现，它说明技能库完善后命令行代理潜力可观，且即便技能完全修补，表格处理和网页浏览类任务命令行代理表现仍落后于GUI代理。
研究团队还做了另一个诊断实验，给GUI代理提供更详细操作步骤提示，看有多大帮助。他们从440个任务中筛选出176个主要依赖GUI工作流操作的任务，对比原始模态中性描述和程序化引导描述下的表现，保持其他条件不变。结果显示，程序化引导使完全通过率从59.7%小幅升至60.2%，平均验收得分从0.7401升至0.7576，平均执行时间从397秒降至314.8秒，降幅达20.7%。这表明程序化引导主要帮助代理找到更直接操作路径，减少不必要探索，降低时间成本，但任务完成率提升有限，说明GUI代理瓶颈不仅是“不知道怎么操作”，更在于即便知道正确步骤，也难以稳定定位界面元素、追踪应用状态和完整执行长序列操作。
