GUI vs. CLI: 纯屏幕与技能中介的计算机使用代理中的执行瓶颈

TL;DR 在首个匹配控制基准上对比 GUI 与 CLI agent，发现 GUI 瓶颈在长程可靠交互，CLI 瓶颈在技能覆盖，验证器引导技能增强可将 CLI 成功率从 48.2% 提升至 69.3%。

问题

问题背景

让 AI 代理自主操作桌面软件是迈向通用智能助手的关键一步。当前主流方案分为两类：GUI 代理（screen-only）通过解析屏幕像素直接操控图形界面；CLI 代理（skill-mediated）则调用预定义的命令或 API 函数来完成任务。然而，两种模态的评测长期缺乏公平对比，难以判断性能差异究竟源于交互方式本身，还是来自任务设置、验证逻辑的偏差。

现有方法局限

以往基准将模态与任务、初始状态、验证器混淆，导致结论不可靠。例如，某个基准可能给 CLI 代理 直接提供文件路径或数据库查询结果，而 GUI 代理 必须在屏幕上逐步导航；或者两者的可行动作集（action space）不等价——CLI 拥有高层次的 open_app 原子操作，GUI 却要从鼠标点击开始。这种不对称使研究者无法分离模型能力与接口覆盖度的影响，也无法定位真正的执行瓶颈。此外，多数评测的 pass/fail 标准粗糙，忽略局部执行正确性，难以指导工程优化。

技术挑战与重要性

构建真正对齐的评测环境面临两大难题：

1. 等价初始状态与验证 —— 两个代理必须面对一致的桌面环境、文件状态，并接受完全相同的结果校验器，仅允许各自模态原生的操作方式。
2. 动作空间约束 —— 必须严格限制 CLI 代理只能使用预设技能列表，而 GUI 代理只能发出鼠标键盘事件，不能给任何一方额外 oracle 信息。

这项研究的重要性在于：工业界正在将计算机使用代理落地到自动化客服、RPA（Robotic Process Automation）升级、软件测试等场景，理解模态瓶颈直接影响架构选型。如果 CLI 的失败主要来自技能覆盖不全（incomplete skill coverage）而非模型推理能力，那么扩大 API 集合就能快速提升成功率，无需盲目堆大模型。反之，若 GUI 因视觉 ground 不稳定而在长程工作流中频繁出错，则应加强交互式闭环感知。

行业类比

这类似于自动化测试领域“UI 脚本 vs. API 测试”的经典分歧：GUI 代理 像 Selenium 脚本，贴近真实用户行为但脆弱；CLI 代理 像直接调用后端接口，速度快但容易忽略前端状态隐式依赖。理解两者的执行瓶颈边界，是构建高可靠混合代理的必要前提。

核心洞察

• CLI 代理的性能短板主要源于**技能覆盖不足**，而非模型推理能力。在匹配的任务、初始状态和验证条件下，原生的 skill-mediated CLI 代理仅达到 48.2% 通过率，远低于 GUI 代理的 59.1%；然而，引入**验证器引导的技能增强**后 CLI 通过率跃升至 69.3%，说明通过扩展技能库或自动生成技能，CLI 模态的潜力可被充分释放。以往工作常将 CLI 的低成功率归因于模型本身，该研究首次在控制变量下揭示瓶颈在于接口层，为优化 CLI 代理提供了明确方向。
• GUI 代理的长期工作流执行受限于**可靠的空间定位与操作接地**。即便最强的 GUI 代理也仅有 59.1% 通过率，错误分析表明大量失败源于 UI 元素的发现失败、工作流步骤遗漏以及缺乏有效的自我验证。这一发现与 CLI 模式形成清晰对比：GUI 代理需要每一步都精准理解视觉界面并执行低层操作，而 CLI 通过高层技能抽象能规避部分接地难题，但受限于技能的可组合性。该区分帮助工程师根据任务特征选择代理架构，并为混合模态设计提供依据。
• 该研究构建的**首个模态匹配执行层基准**（440 个桌面任务，18 个应用，12 种工作流类别）消除了以往评测中任务、初始状态和验证方式的混杂因素，首次公平对比纯屏幕 GUI 与纯技能 CLI 的代理能力。这一定量的控制实验揭示出交互模态对鲁棒性和工作流适应性的结构性影响，例如 GUI 在简单线性流程中表现较好，而 CLI 在复杂依赖型任务中优势明显。该基准与方法论为社区提供了可复现的分析框架，推动代理研究从‘模型更强’转向‘接口适配’。

方法

核心思路：控制变量分离交互模态

本文构建了一个执行层对齐的桌面操作基准，系统比较 GUI（屏幕视觉） 与 CLI（技能调用） 两种交互模式对计算机使用代理的性能影响。核心设计原则是控制任务、初始状态、验证器完全相同，仅动作空间不同，从而消除以往评测中混杂因素的干扰。

基准构建：三阶段严格筛选

• 应用与任务选择：覆盖 18 款应用、12 类工作流（如文件管理、数据录入、系统配置），筛选出 440 个可明确验证终止状态的任务。
• 任务重写与归约：将原始任务重写为同一目标、相同起始桌面快照，并定义统一的状态验证脚本（如检查文件是否存在、文本是否修改）。
• 人工校验：确保每个任务在给定动作空间下均可由人类完成，消除不现实或跨模态作弊路径。

代理设定与动作空间

• GUI 代理：仅通过屏幕截图感知，输出像素级操作（点击、拖拽、键入），使用视觉语言模型（VLM）进行接地推理。
• CLI 代理：仅通过预定义的技能库（如 open_file、click_button）交互，技能由自然语言描述和参数签名抽象，代理需从任务目标推断所需技能序列。初始技能库为手工编写的原始技能集，覆盖常见操作但不完备。 两者均基于同一主干 LLM，通过 ReAct 式提示循环进行决策。

评估与增强机制

• 评估指标：Full Pass Rate，要求终端状态严格通过验证。
• CLI 增强：引入验证器引导的技能增强——当 CLI 代理执行失败或遇到未覆盖操作时，利用验证器返回的预期状态回溯缺失技能，自动扩充技能库。该方法使 CLI 成功率从 48.2% 跃升至 69.3%。
• GUI 分析：探索程序性接地——将任务分解为可验证的子目标，让代理在执行过程中自我检查中间状态，以缓解长周期导航中的迷失。

与同类方法的差异

以往工作通常在异构任务集与动作空间下比较 GUI/CLI，本工作通过严格状态-目标-验证器匹配，首次隔离出模态本身带来的执行瓶颈，揭示出 GUI 受限于可靠接地交互的长周期工作流，而 CLI 受限于技能覆盖而非模型能力。

实验

实验设计

该工作构建了GUI-vs-CLI Benchmark，包含440个桌面任务，覆盖18个应用、12种工作流类别（如文件管理、文档编辑、数据录入等）。每个任务同时提供给屏幕专用GUI代理和技能中介CLI代理，两者共享相同的初始状态、任务目标和最终状态验证器，但动作空间严格限定在各自模态内——GUI代理只能通过像素级UI交互（点击、输入、滚动），CLI代理只能调用预定义的技能函数（如打开文件、写入文本）。这种匹配的execution-layer setting消除了过往评估中因任务/状态/验证器不同导致的混淆。

关键发现

• 在完全公平的条件下，最强GUI代理（59.1%）仍显著优于原始技能CLI代理（48.2%），表明视觉交互的灵活性在某些场景下具有固有优势。
• CLIs的短板并非模型推理能力不足，而是技能覆盖率有限：一旦通过验证器反馈自动扩充技能库，CLI成功率跃升至69.3%，反超GUI。
• 不同模态暴露了完全不同的执行瓶颈：GUI代理的瓶颈在于长程工作流中的可靠接地交互（UI元素定位偏差、控制序列错误累积），而CLI代理的瓶颈在于技能接口的覆盖与可扩展性（技能描述与实际效果之间的契约缺口、隐式默认值重构错误）。
• 工作流结构也影响模态适用性：GUI在多步骤、依赖视觉反馈的操作中更稳健；CLI在确定性高、可参数化的任务中一旦技能完备则效率极高。

与基线对比解读

原始CLI代理的48.2% vs. GUI的59.1%常被误读为“GUI全面优于CLI”，但技能增强实验结果揭示了真实原因：CLI的模型能力足以执行任务，只是缺乏将自身知识转换为可用技能的桥梁。这意味着，当前CLI代理的竞争瓶颈在于技能接口工程（如何扩展技能库、如何精确描述技能语义），而非模型智能。对于工程团队，若能在特定垂直领域构建高覆盖率的CLI技能库，其可靠性将大幅超越依赖像素理解的GUI方案；而GUI方案在开放域、多样性任务中仍更具通用性。

行业影响

落地场景

该研究揭示了 GUI Agent 与 CLI Agent 在执行桌面任务时的互补瓶颈，直接指向两类高价值产品形态：

• 通用屏幕操控助手（如 Anthropic Computer Use、Microsoft Copilot Vision）适合处理遗留系统、跨应用流程，尤其在人机协同的客服、销售、合规审核等场景，通过视觉交互完成信息录入、状态查询与多步提交。
• 基于技能的自动化管线（如 LangChain Tool-calling、内部脚本平台）适合高频、结构化任务，如数据 ETL、批量文件处理、IT 运维脚本执行，可通过 验证器引导的技能增强（verifier-guided skill augmentation）实现高可靠闭环。

两者的混合架构能覆盖更广泛的企业自动化需求：高频确定性任务走 CLI 路径，长尾界面操作走 GUI 路径，并由统一的任务规划器调度。

商业价值

效益主要落在降本增效与服务稳定性提升：

• 降本：CLI Agent 在技能覆盖充分时（文中增强后 69.3% 通过率）可大规模替代重复人工操作，减少外包或专职支持成本。
• 体验与增收：GUI Agent 让 AI 助手能直接操作 SaaS 工具（如 CRM、ERP）完成端到端服务，缩短客户等待时间，提高转化率；同时降低对 API 集成的依赖，快速接入任意软件。
• 新收入流：提供 “Agent-as-a-Service” 平台，按任务量或成功率计费，或输出技能库与验证工具，形成生态订阅。

与现有产品 / 工作流的接口

集成方式灵活，与现有 AI 栈兼容：

• CLI 技能库 可通过工具调用协议（如 OpenAI function calling、MCP）直接嵌入对话式 Agent 或编排框架（如 AutoGen、CrewAI），由大模型根据意图动态选择技能；缺失技能可由开发者按约定规范（contract）扩展，并通过文中提出的 verifier 进行自动回归验证。
• GUI Agent 通过屏幕截图 + 语义坐标输出的标准接口，可封装为 LangChain agent 工具，或结合专用工具（如 Playwright、PyAutoGUI）在容器化桌面环境中执行，输出可校验的系统状态。
• 混合决策层 可为现有 RPA 平台（如 UiPath、Automation Anywhere）提供智能调度，根据任务特征路由到 GUI 或 CLI 执行器，同时利用 verifier pipeline 提升可观测性。

具体落地 Use Case

1. 电商大促自动化
   大促期间需批量上架商品、修改价格、同步库存。CLI Agent 通过技能库直接调用电商平台 API 完成批量更新（确定性高）；当平台仅提供网页后台时，GUI Agent 自动执行点击、填表、上传图片等操作，弥补 API 缺失。两者由统一调度器根据接口可用性自动切换，实现零人工干预。
2. 金融合规报告生成
   从 Bloomberg 终端抓取市场数据（GUI 操控），通过 CLI 技能对数据进行清洗、聚合与格式化，再驱动 Excel 模板生成合规报表。Verifier 自动校验数值一致性与格式规范，若发现偏差回退重试，确保交付件零错误，可节省分析师每周数十小时的手工制作时间。

局限

• **任务与技能覆盖的受限性**：基准仅包含 440 个桌面任务，横跨 18 个应用与 12 个工作流类别。CLI 代理的性能高度依赖预定义的技能集，即便通过验证器引导的技能增强（verifier-guided skill augmentation）能提升成功率，该方法仍要求为每类任务预先设计验证逻辑，不适用于开放域或未见任务。此外，实验采用的 GUI 与 CLI 代理各为特定实现（如具体模型与训练配置），结论未必能直接迁移至其他代理架构或更大规模的基础模型。
• **交互模态的硬性分离**：实验设计将 GUI（仅屏幕操作）与 CLI（仅命令）强制割裂，严格限制各自的原子动作空间，但在真实计算场景中，混合模态（例如在 CLI 中嵌入截图理解或 GUI 中调用脚本）可能更具实用优势。本研究未探讨模态融合的可能性，使得“GUI vs CLI”的结论局限于单一模态的优劣比较，未能揭示两种模态协同时的执行瓶颈是否会发生变化。
• **评估生态的单一性**：基准强调初始状态与终态验证器的匹配，但终态验证器（如文件内容比对）忽略了执行过程的可解释性与鲁棒性。对于长周期工作流，GUI 代理的故障往往源于 UI 定位与操作序列的累积误差，而 CLI 代理的错误则多由技能契约隐式假设被打破所致。当前指标（pass rate）未能区分这两类错误的严重性，也未给出部分完成度的度量，限制了细粒度诊断与改进方向的分析。