这项由纽约大学上海校区、耶鲁大学NLP实验室与南洋理工大学联合开展的研究，以预印本论文的形式发表于2026年6月22日，论文编号为arXiv:2606.24551。感兴趣的读者可以通过这个编号在arXiv平台查阅完整原文。
每天，我们都在用电脑完成各种任务：调整音频文件、编辑幻灯片、绘制流程图。对于人类来说，这些操作再熟悉不过——眼睛盯着屏幕，手控制鼠标和键盘。但当AI来干这件事时，它面临一个根本性的选择：到底是像人类一样"看着屏幕操作"，还是通过专门编写的程序命令来直接驱动软件？这两条路，在研究者的实验中，撞出了截然不同的结果，也各自暴露出了令人意想不到的短板。
一、 两种"操控电脑"的方式，差别到底有多大
要理解这篇论文在研究什么，得先弄清楚AI操控电脑的两种基本方式。
第一种叫做"图形界面代理"（GUI agent），这类AI的工作方式和普通人类用户几乎一模一样——它接收一张屏幕截图，然后通过点击、拖拽、打字、滚动、按快捷键等动作来完成任务。你让它在Audacity里给三段音轨命名，它就像一个坐在电脑前的实习生，盯着软件界面，一步一步地找到菜单、点击按钮、输入名称。
第二种叫做"命令行技能代理"（CLI agent），这类AI不看屏幕，而是依赖一套专门为各种软件预先编写好的"技能程序"。每个技能就像一张工序单，写明了要调用哪个软件的哪个功能、传入什么参数、得到什么结果。AI只需要找到合适的技能，按照规程调用，就能完成任务，完全不需要盯着图形界面。
这两种方式的差异，不仅仅是"看不看屏幕"这么简单。它们代表的是两种截然不同的"理解软件"的逻辑：一种是通过视觉感知和交互来完成任务，另一种是通过结构化的操作接口来驱动软件。就像一位经验丰富的厨师和一台全自动料理机——前者靠眼睛和双手，后者靠预设程序，各有各的擅长领域，也各有各的局限。
二、 为什么过去的比较都不可信
在这项研究之前，学界其实已经有不少针对GUI代理和命令行代理的评测基准，比如WebArena、AndroidWorld、OSWorld等。但研究团队发现，这些评测存在一个根本性的问题：它们在比较两类代理时，往往同时改变了好几个条件——测试的任务不同、软件初始状态不同、验收标准不同、允许执行的动作也不同。
这就好比你想比较两种跑鞋的性能，结果一双鞋在平路上跑，另一双鞋在山路上跑，跑的距离也不一样，终点线的位置也不同。比赛结束后，你根本无法判断成绩差异是鞋子的问题、还是赛道的问题、还是规则的问题。
正因如此，研究团队决定构建一个全新的、真正公平的评测平台：给GUI代理和命令行代理布置完全相同的任务、提供完全相同的初始状态、使用完全相同的验收标准——唯一的区别，就是各自必须使用自己"本职"的操作方式。GUI代理只能通过屏幕交互，命令行代理只能通过技能接口。这样一来，最终的成绩差距，才能真正归因于"操作方式"本身，而不是任务难度或规则差异。
三、 这场"公平竞技"是如何搭建的
研究团队花了大量精力构建这个评测基准，最终涵盖了440个桌面任务，横跨18款真实软件，覆盖12大工作流类别。这些软件包括GIMP、Krita、draw.io（视觉设计）、Audacity、MuseScore（音频处理）、Obsidian、Zotero（知识管理）、FreeCAD、CloudCompare（工程建模）、LibreOffice Writer/Calc/Impress（文档表格演示文稿）、Shotcut、OBS（视频流媒体）、Zoom（通讯）、Godot 4（游戏开发）以及Chrome（网页浏览）。
任务的构建过程分三个阶段进行。第一阶段是应用与任务筛选，研究团队从OpenComputer这个现有的桌面任务库出发，专门选取那些同时有命令行技能支持的软件，确保每一款软件既能通过图形界面操作，也能通过程序化命令驱动。
第二阶段是任务改写与整理。原始任务往往是为GUI操作量身定制的，充满了"点击这个按钮""打开那个菜单"之类的步骤描述。研究团队将这些任务全部改写成"结果导向"的中性描述——只说要达到什么最终状态，不规定用什么方式去做。例如，不再说"点击Tracks菜单，选择Add New，再选Mono Track"，而是直接说"在项目中创建三条单声道音轨，分别命名为Drums、Bass、Synth，按照从上到下的顺序排列"。这样的任务描述，给GUI代理和命令行代理都是公平的起点。同时，研究团队还去掉了那些只适合某一种操作方式的任务，并在必要时补充了新任务，以平衡两种方式在各类工作流中的分布。
第三阶段是人工验证。每一道题都经过人工审查，确认它在两种操作方式下都能完成，且任务描述没有暗示某种特定的操作路径，验证标准也完全一致。评测的核心逻辑是"最终状态验证"：不管你用什么方式完成任务，只要最终的软件状态或文件内容符合要求，就算通过。
四、 正式比赛开始：GUI代理领先，但命令行代理也有亮点
在这个公平的擂台上，研究团队评测了多款主流AI模型。GUI代理阵营包括GPT-5.4、Claude-Sonnet-4.6、Claude-Opus-4.7、EvoCUA-32B、Qwen3.5-27B和Kimi-K2.6；命令行代理阵营则包括Codex GPT-5.4、Codex GPT-5.5、Claude Code Sonnet 4.6和Claude Code Opus 4.7。
从总体成绩来看，GUI代理阵营的最强选手GPT-5.4拿到了59.1%的完全通过率，其次是Claude Opus 4.7的55.9%。命令行代理阵营的最强选手Codex GPT-5.5在使用原始技能库的情况下，拿到了48.2%的完全通过率。这意味着，即便Codex GPT-5.5背后的底层模型能力实际上比GPT-5.4更强，但通过命令行操作，它的表现反而不如通过图形界面操作的GPT-5.4。
这个结果很有意思：操作方式本身，竟然可以"弥补"甚至"逆转"底层模型能力的差距。换句话说，就算你开的是一辆马力更强的车，如果路况更差，你的速度未必更快。
不过，如果仔细拆解各类工作流的成绩，就会发现两种方式各有擅长的"主场"。GUI代理在音频处理、演示文稿、通讯和网页浏览类任务上表现更好，这些任务往往需要与可见的控件、菜单、时间轴、幻灯片或浏览器状态进行交互，图形界面天然就是这些任务的"母语"。
命令行代理则在视觉设计、工程建模、文档处理、视频流媒体和游戏开发类任务上更有竞争力，甚至反超GUI代理。以视觉设计类任务为例，表面上看这类任务很"视觉化"，应该是GUI的强项，但实际上，draw.io的绘图任务要求创建特定数量的图形节点、特定标签、特定连接关系——这些都是结构化的属性，命令行技能可以直接操作，反而比用鼠标在屏幕上一个一个摆放图形更加高效和准确。
此外，命令行代理的成绩波动非常剧烈：Codex GPT-5.5在不同工作流中的通过率从9.8%到100%不等，而GUI代理GPT-5.4的区间是42.9%到88.2%，相对稳定得多。这说明GUI代理借助了应用程序界面内嵌的工作流引导，而命令行代理的表现高度依赖于技能库是否覆盖了对应的功能。
五、 命令行代理为什么会失败：三道"技能之墙"
研究团队对命令行代理的失败案例进行了深入分析，从80个随机抽取的失败任务中归纳出三种主要的失败模式。
第一种是"技能覆盖与契约缺口"。命令行代理的行动边界，完全由技能库决定。如果某个软件功能没有对应的技能，代理就无从下手。更糟糕的是，有时候技能的文档说它能做某件事，但实际的代码实现却达不到要求——代理按照文档规范执行了完整的流程，但最终验收时还是失败了。举个具体的例子：在FreeCAD的一项任务中，代理找到了cli-anything-freecad这个技能，但调用时，该技能把原生的.FCStd文件格式误当成自己的JSON格式来解析，触发了UnicodeDecodeError（编码错误），最终找不到任何稳定的技能路径来修改文件标签，只好宣告任务不可行。
第二种是"隐性默认值重建错误"。当人类用户通过图形界面操作时，很多默认设置、命名规则和标识符会自动由软件界面提供，用户根本不需要考虑。但命令行代理必须显式地处理这些信息，稍有偏差就会导致失败。在FreeCAD的另一个任务中，代理被要求添加一个球体，设置半径为15毫米，并将用户可见的标签改为"Planet"，同时内部名称应保持软件默认的"Sphere"。代理成功创建了一个球体对象，验收时也看到了名为"Box"和"Planet"的对象，但问题是内部名称"Sphere"消失了。代理错误地处理了"内部名称"和"用户标签"之间的区别，导致所有相关验收项全部失败。
第三种是"不可观测的应用语义"。命令行代理只能看到技能接口暴露出来的信息。当关键的软件内部逻辑没有被技能接口呈现时，代理往往只能靠猜测来填补空白，而猜测通常是错的。在Audacity的一项任务中，代理被要求修改"默认采样格式"为32位浮点，并让这个设置持久保存到配置文件中。Audacity的命令行技能接口没有暴露全局偏好设置，代理于是从已有的状态信息中推断，认为`DefaultProjectSampleFormatChoice=Format32BitFloat`就是目标设置。但实际上，这个设置被存储为`Quality/DefaultSampleFormat=524293`，代理猜错了字段，任务自然失败。
从统计上看，命令行代理的失败有93.8%集中在技能覆盖与契约缺口这个大类中（其中包含了不可观测应用语义的情况），只有6.2%属于隐性默认值重建错误。这意味着，命令行代理的核心瓶颈不是"模型不够聪明"，而是"技能库不够完善"。
六、 GUI代理为什么会失败：三道"界面之墙"
相比之下，GUI代理的失败模式则呈现出截然不同的特点，主要集中在两大类：61.3%是工作流执行失败，38.7%是界面导航和控件发现失败。
界面导航和控件发现失败，指的是代理无法可靠地找到正确的操作路径。应用程序的界面设计有时相当复杂——菜单层层嵌套、设置项藏在不起眼的角落、某些功能只有在特定状态下才会出现。在Zoom配置任务的一个案例中，代理只执行了11个屏幕操作，在设置界面附近东点西点，搜索了"硬件加速"和"模糊强度"等关键词，最终宣告完成。但验收显示，所有目标设置项（包括虚拟背景开关、背景类型、模糊强度和硬件加速）全部没有被修改，仍然保持原始值。代理从始至终没有找到正确的操作入口。
工作流执行失败，则发生在代理找到了大致正确的方向，但无法完成一整套有特定顺序要求的操作序列。应用程序往往要求按照特定顺序点击、确认对话框、等待状态切换，任何一个环节出错或被跳过，任务就会失败。在Zotero的PDF附件任务中，代理执行了34步操作，包括在文献库中右键点击、输入PDF路径、反复进行文件和菜单选择。验收确认目标文献条目是存在的，但附件检查失败了：has_attachment显示为false，附件数量为0。代理到达了正确的上下文，但没有完成"附加文件"这个有状态的工作流。
还有一类叫做"自我检查与验证缺口"：代理完成了看起来合理的交互操作，就直接宣告任务完成，却没有验证最终产出是否真的符合要求。在Audacity标签导出的任务中，代理成功创建了标签音轨和三个正确时间戳的标签，但导出文本文件的步骤没有真正完成——/home/user/Music/podcast_labels.txt这个文件根本不存在。代理与导出对话框进行了交互，然后宣告DONE，但没有确认文件是否真的被写入磁盘。
这三种GUI失败模式统计上可以看出，GUI代理的核心瓶颈在于：长序列的界面操作容易中途出错，复杂的菜单层级难以可靠导航，以及缺乏对最终状态的主动验证。
七、 技能库"打补丁"：命令行代理的真正天花板在哪里
既然命令行代理的主要失败原因是技能库不完善，那么一个自然而然的问题就是：如果把技能库补全了，会发生什么？
研究团队为此设计了一个诊断性实验，称为"验收引导的技能修补"。他们对每一款软件的CLI-Anything技能库进行了系统性审查，步骤如下：
首先，逐一检查每个验收检查点，判断现有技能是否能可靠地满足该检查点的要求。每个检查点被标记为"通过"（技能可以稳定产生验收所需的最终状态）、"部分"（技能只能覆盖一部分，或者产生的中间状态无法被验收读取）或"失败"（根本没有对应的技能路径）。在这个标准下，原始CLI-Anything技能库只覆盖了37.6%的验收检查点——也就是说，超过六成的验收要求，现有技能根本无法满足。
然后，对标记为"部分"或"失败"的检查点，研究团队对技能实现进行修复，并用涵盖所有验收检查点的综合测试套件来验证修复后的技能。修复完成后，针对每款软件的覆盖率达到100%。
使用修补后的技能库，Codex GPT-5.5的整体通过率从48.2%跃升到了69.3%。在某些工作流类别中，提升幅度极为惊人：知识管理类从22.4%升至81.6%，图形调试类从9.8%升至48.8%，通讯类从50%升至95%，音频类从42.9%升至81.6%，这些提升幅度分别高达264%、398%、90%和90%。
在修补后的技能库条件下，命令行代理的整体成绩（69.3%）超过了最强GUI代理（59.1%），在多个工作流类别中也领先于GUI代理。同时，修补后的执行平均时间也从188.1秒降低到了162.6秒，说明技能更完善之后，代理不再需要花大量时间做无效的探索，执行效率也提高了。
不过，研究团队非常谨慎地指出：这个"技能修补"实验是一个诊断性的上界估计，不是一个可以直接部署的新基准。修补过程使用了验收检查点的信息，相当于"开卷考试"，所以不能把这个结果当作命令行代理在现实中的真实表现。它真正说明的是：如果技能库能够达到足够的覆盖率，命令行代理的潜力是非常可观的，而当前技能库的不完善确实解释了大部分的性能差距。
此外，即便在技能完全修补的情况下，表格处理和网页浏览类任务的命令行代理表现仍然落后于GUI代理，说明操作方式的差异在某些场景下有着超越技能覆盖率的深层影响。
八、 给GUI代理"加操作手册"：程序化引导的效果
研究团队还做了另一个诊断实验：如果给GUI代理提供更详细的操作步骤提示，会有多大帮助？
这个实验的出发点是，GUI代理的很多失败并不是因为它不理解任务目标，而是不知道该怎么一步一步去做。以在Audacity里添加标签轨道为例，原始任务描述只说"添加一个标签音轨并放置四个章节标签"，没有说怎么做。改写后的"程序化引导"版本则会详细说明：使用Tracks菜单，选Add New，再选Label Track；双击标签轨道的特定位置来创建标签；输入标签名称后按回车；用Ctrl+S保存项目。
研究团队从440个任务中筛选出176个主要依赖GUI工作流操作的任务，对比了原始模态中性描述和程序化引导描述下的表现，保持所有其他条件（环境、验收标准、动作空间、模型）不变。
结果显示，程序化引导带来了一定改善：完全通过率从59.7%小幅升至60.2%，平均验收得分从0.7401升至0.7576，平均执行时间从397秒降至314.8秒，降幅达20.7%。
这组数据揭示了一个微妙但重要的现象：程序化引导主要帮助代理找到了更直接的操作路径，减少了不必要的探索，所以时间成本下降明显。但任务完成率的提升却非常有限，说明GUI代理的瓶颈不仅仅是"不知道怎么操作"，更在于即便知道了正确步骤，仍然需要可靠地定位界面元素、跨多个步骤追踪状态、准确执行一长串的操作序列。知道菜单在哪里，和能稳定点击到正确菜单项，是两件不同的事。
说到底，这场实验揭示的不只是哪种方式更好，而是两种方式各自把"执行难度"藏在了不同的地方。
GUI代理面对的是一个"工作流内嵌于界面"的世界：软件设计者已经把操作逻辑编织进了菜单、对话框和交互流程中，代理只需要可靠地感知和操作这套视觉语言。但这种可靠性本身就很难保证——界面元素的位置可能随状态变化，长序列操作中的任何一步失误都会导致任务失败，而且代理往往不会主动去验证自己的操作是否真的产生了预期效果。
命令行代理面对的则是一个"工作流内嵌于技能库"的世界：它不需要看屏幕，只需要找到合适的技能并正确调用。但这种结构性的清晰，是以大量的前期工程投入为代价换来的——有人必须为每款软件的每个功能编写、测试和维护对应的技能，而这个任务目前完成得远远不够充分。
归根结底，GUI还是命令行的问题，与其说是在比较两套工具的高下，不如说是在问：你愿意把构建"执行能力"的工程投入放在哪里——放在培训AI感知和操作图形界面的能力上，还是放在构建和维护覆盖全面的技能接口上？两条路都有各自的代价，也都有各自的极限。
而这篇论文最有价值的贡献，正是第一次在完全公平的条件下，把这两个极限清晰地摆在了我们面前。对于任何正在设计或选择AI自动化方案的人来说，这份来自纽约大学上海校区、耶鲁大学和南洋理工大学的研究都值得认真对待。完整内容可通过arXiv:2606.24551查阅原论文。
Q&A
Q1：GUI代理和命令行代理完成电脑任务的主要区别是什么？
A：GUI代理像普通人一样看着屏幕，通过点击、拖拽、打字等方式操作软件界面。命令行代理则不看屏幕，而是调用预先编写好的"技能程序"，直接驱动软件执行特定操作。两者的核心区别在于，GUI代理依赖视觉感知和界面交互，命令行代理依赖结构化的程序化接口。
Q2：命令行代理的技能库覆盖率只有37.6%意味着什么？
A：这意味着在原始的CLI-Anything技能库中，超过六成的验收要求根本无法被现有技能满足。也就是说，命令行代理即便努力执行，也有超过一半以上的任务检查点在技术上就无法通过，因为根本没有对应的技能路径存在。这是命令行代理表现不稳定的核心原因。
Q3：程序化引导对GUI代理的帮助为什么这么有限？
A：给GUI代理提供详细的操作步骤后，执行时间下降了约21%，但任务通过率几乎没变。这说明GUI代理的瓶颈不只是"不知道怎么操作"，更在于即便知道正确步骤，也难以稳定地在屏幕上定位正确的界面元素、跨多个步骤追踪应用状态，以及完整执行长序列操作而不出错。知道流程和能可靠执行流程，是两件不同的事。
专业配资开户提示：文章来自网络，不代表本站观点。
