最近AI圈子在火热的讨论API Agents、GUI Agents，关于这两者的研究很有必要阅读下近期微软发布的这篇论文《API Agents vs. GUI Agents: Divergence and Convergence》，跟着小编一起深入研究下，以下是论文完整的译文，Enjoy。
大型语言模型 (LLM) 已从简单的文本生成发展到能够将自然语言命令直接转化为实际操作的软件代理。基于 API 的 LLM 代理最初因其强大的自动化功能以及与编程端点的无缝集成而声名鹊起，而多模态 LLM 研究的最新进展则使基于 GUI 的 LLM 代理能够以类似人类的方式与图形用户界面进行交互。尽管这两种范式都致力于实现 LLM 驱动的任务自动化，但它们在架构复杂性、开发工作流程和用户交互模型方面存在显著差异。
本文首次对基于 API 和 GUI 的 LLM 代理进行了全面的比较研究，系统地分析了它们的差异和潜在的融合点。我们探讨了关键维度，并重点介绍了混合方法能够充分发挥其互补优势的场景。通过提出清晰的决策标准并阐述实际用例，我们旨在指导实践者和研究人员选择、组合或转换这些范式。最终，我们指出，基于 LLM 的自动化领域的持续创新将模糊 API 驱动和 GUI 驱动代理之间的界限，为在广泛的实际应用中提供更灵活、更具适应性的解决方案铺平道路。
1、介绍
大型语言模型（LLM）的出现开启了人工智能的新纪元，在广泛领域实现了高级自然语言理解和生成。尽管 LLM 长期以来因其生成连贯文本的能力而受到认可，但最近的发展已催生出基于 LLM 的智能体，能够将语言输入映射到数字环境中的实际操作，这些代理可以与各种软件系统交互、执行命令并对其所在的软件生态系统产生实际影响。
最初，软件 LLM 代理主要以应用程序编程接口 (API) 为中心，通过明确定义的编程接口与外部工具、功能或服务进行交互。这种方法允许代理以自动化和高效的方式编排微服务、查询搜索引擎，甚至通过已记录的 API 控制第三方应用程序。微软的 Copilot 等产品体现了基于 API 的 LLM 代理如何成为主流。并迅速从研究原型转变为广泛采用的工业解决方案。这些代理在学术界和工业界的吸引力，凸显了它们通过自动化简化任务的能力，同时保持了强大的可扩展性和互操作性。
与此同时，随着多模态能力在法学硕士 (LLM) 研究中日益受到重视，一类新的代理应运而生：基于图形用户界面 (GUI) 的 LLM 代理 。这些代理不仅通过 API 进行交互，还通过“观察”和操作软件的图形用户界面进行交互，无论是桌面、移动还是 Web 应用程序。诸如UFO 、CogAgent和 OpenAI Operator等项目展示了基于 GUI 的代理如何带来更丰富的用户体验、更卓越的可访问性，并提供更通用的软件自动化控制。通过将视觉或基于屏幕的理解与基于文本的推理相结合，这些代理突破了人机交互的界限，展示了人工智能如何与直观、可视化的工作流程无缝融合。
尽管这两种范式都很有前景，但基于 API 和基于 GUI 的 LLM 代理在其架构、开发方法和用户交互模型方面表现出显著差异。例如，如图1所示 ，基于 API 的代理安排 Google 日历会议只需提供正确的端点和身份验证，即可进行一次调用，立即创建活动。相比之下，基于 GUI 的代理会打开 Web 界面，直观地浏览日历，填写相关字段，然后单击按钮以确定会议详细信息。虽然基于 API 的方法往往更快、更节省资源，但它依赖于明确定义的端点和可靠的基础设施。相反，基于 GUI 的代理可以与应用程序的前端交互，但通常需要多个类似用户的步骤（鼠标单击、键盘输入），这可能会更慢且更容易出错。
这些权衡凸显了基于 API 和 GUI 的代理之间的根本区别，并引发了关于它们优缺点、功能重叠甚至必要性的激烈讨论。尽管它们看似竞争，但许多人认为，彻底审视两者的差异和共同点至关重要。事实上，目前尚无统一的框架或比较分析能够提供明确的指导，说明何时一种方法可能优于另一种方法，或者混合策略是否可以兼具两者的优势。
为了弥补这一差距，本文系统地考察了软件自动化领域中基于 API 和基于 GUI 的 LLM 代理的差异和潜在的融合。我们首先阐明每种范式的概念基础，然后在关键维度上进行深入的比较分析。随后，我们探讨了基于 LLM 的交互领域的持续创新如何逐渐模糊 API 和 GUI 代理之间的界限，并讨论了一种能够充分利用各自优势、弥补各自不足的混合方法。通过概述清晰的决策标准，我们旨在指导从业者和研究人员根据项目需求、资源限制和用户体验目标选择最合适的代理类型。最终，本文将成为学术界和行业专业人士的综合资源，提供关于这些代理类型差异、融合点以及如何演进以应对新兴挑战的深刻见解。
2、背景
LLM 代理旨在接受用户的自然语言请求，并在真实或虚拟环境中执行任务。虽然它们的目标是将语言转化为可操作的命令，但根据这些代理与底层系统的交互方式，出现了两种截然不同的范式：API 优先和 GUI 优先的 LLM 代理。下文将概述这两种范式，重点介绍它们的核心原理和操作差异。
2.1基于 API 的 LLM 代理
API-first LLM 代理可以定义为：智能代理利用 LLM 作为其认知引擎来调用一个或多个预定义的 API，以自动满足用户请求。
API-first LLM 代理可以定义为：智能代理利用 LLM 作为其认知引擎来调用一个或多个预定义的 API，以自动满足用户请求。
在这个范例中，代理的功能受到一组预定义的工具、插件或函数调用的限制——统称为“API ”，如图2所示 。这组受限的函数不仅确保了可靠性和安全性，还简化了代理的决策空间。代理无需生成完整的程序代码，而是识别每个步骤需要调用的 API，并根据用户意图填充所需的参数。
LLMs 提示中包含相关的 API 信息，例如函数名称、描述、参数和模式。当用户发出自然语言请求时，LLM 代理会解读其意图并选择最合适的 API 来执行任务。这种方法已在许多最先进的模型和框架中得到广泛采用，包括 GPT-4 中的函数调用模式（function-call）以及 TaskWeaver的仅插件模式（plugin-only）。
2.2基于 GUI 的 LLM 代理
与 API 优先范式相反，基于 GUI 的 LLM 代理通过直接与 GUI 交互来运行，而不是调用预定义的函数。正如所定义的那样，这些代理可以描述为：
在 GUI 环境中运行的智能代理，利用 LLM 作为其核心推理和认知引擎，以灵活和自适应的方式生成、规划和执行操作。
基于 GUI 的代理主要依赖于视觉或多模态输入，例如应用程序屏幕截图和文本表示（例如，可访问性树或元数据）。这些代理并非调用 API 端点，而是使用类似于人类交互的操作（例如鼠标点击和键盘输入）来导航和操作屏幕元素。如图2所示 。这种“类似人类”的操作流程意味着代理必须解读视觉布局、定位相关控件，并执行一系列点击、拖动或按键操作来完成任务。
多模态法学硕士的快速发展和功能引发了人们对基于 GUI 的代理的浓厚兴趣，催生了一系列原型、框架和商业产品。用例包括自动化软件测试、工作流自动化和可访问性增强。正在进行的研究旨在解决屏幕解析、错误处理和稳健的行动规划等固有挑战，而这些领域正是基于 GUI 的 LLM 代理不断发展的领域。
这种基于 GUI 的范式与 API 优先的 LLM 代理相结合，形成了一种互补但又往往相互矛盾的方法，用于构建连接自然语言理解和实际任务执行的智能系统。正如后续章节将要说明的，理解这两种范式对于选择或设计适合特定项目目标和约束的代理架构至关重要。
3、API 和 GUI 代理之间的差异
虽然基于 API 和基于 GUI 的代理都旨在使用自然语言指令实现任务自动化，但它们在各个方面存在显著差异。本节将从几个关键维度进行比较分析：模态性、可靠性、效率、可用性、灵活性、安全性、透明性、类人交互和可维护性。通过研究这些因素，我们可以更好地理解这两种范式之间的根本区别及其对实际应用的影响。
3.1方式
最明显的区别在于每个代理感知软件和与软件交互的方式。API 代理依赖于每个可用端点的文本规范。它们解释用户的请求，将其映射到相关功能，并提供执行所需的参数。相比之下，GUI 代理处理视觉或多模态输入，例如屏幕截图或可访问性树，然后导航和操作用户界面元素。由于 GUI 代理操作的是实际的界面控件，因此准确的视觉基础和解释至关重要。虽然可访问性树可以提供一些结构化信息，但基于图像的理解仍然是代理在 GUI 环境中交互的核心。
3.2效率
效率涵盖完成任务所需的时间和计算资源。API 代理通常可以通过一次函数调用来处理复杂任务，从而最大限度地减少延迟并降低推理成本。相比之下，GUI 代理通常必须执行一系列类似用户的操作（打开菜单、输入文本、点击按钮）才能完成相同的目标。即使是常规操作，例如浏览应用程序窗格，也可能需要多个步骤。这种用户级方法虽然直观，但与设计良好的 API 相比，可能会减慢任务执行速度并增加运营开销。如果完成一项任务所花的时间比人类要长得多，那么这可能会阻碍 GUI 代理的采用并限制其实际适用性。
3.3可靠性
可靠性通常源于底层交互模型的复杂性。API 代理通常在能够访问稳定且定义明确的端点时表现出强大的性能。此类端点易于维护、版本控制和测试，从而产生可预测的结果。然而，每当应用程序布局或屏幕元素发生意外变化时，GUI 代理就会面临挑战。这是因为 GUI 主要为人机交互而设计，通常包含冗余元素和潜在的干扰因素，可能会扰乱自动化工作流程。这些变化给代理的视觉解析和规划带来了不确定性，使得基于 GUI 的方法更容易出错。此外，GUI 代理的多步骤决策过程可能会在每一步中叠加错误，最终降低整体准确性。因此，GUI 代理通常需要持续改进，并且在许多情况下仍然不如基于 API 的代理那样适合生产环境。
3.4可用性
可用性取决于代理访问满足用户请求所需功能的便捷程度。API 代理受开发人员定义和公开的端点或功能的限制。如果缺少所需的功能，代理将无法直接调用。这种情况在移动应用中尤为常见，因为开发人员通常会限制外部 API 访问，以保持对其私有生态系统的控制。
相反，GUI 代理几乎可以与任何提供图形用户界面的应用程序交互，而无需显式定义 API。基于 GUI 的交互的通用性在没有正式 API 公开的环境中可能是一个优势，但它也需要更复杂的解释和错误处理来管理多样化或不断发展的 UI。
3.5灵活性
除了可用性之外，灵活性还表示代理适应新用例或修改用例的难易程度。API 代理只能调用已预先开发、记录和集成的 API。扩展其功能取决于创建和部署其他端点。另一方面，GUI 代理理论上可以操作界面内的任何可见元素，从而提供更高的自由度。然而，这种自由需要先进的计算机视觉或多模态推理能力来一致地定位和与 UI 对象交互。
3.6安全
安全性在决定采用哪种范式时起着至关重要的作用。API 代理通常提供更细粒度的保护，因为每个端点都可以通过身份验证、访问控制或速率限制进行单独保护。GUI 代理可能会无意中访问执行特权或破坏性操作的界面部分，从而增加发生意外后果的风险。由于图形界面主要为人类用户设计，因此对自动化、类似鼠标键盘的交互实施全面的安全策略可能具有挑战性。因此，基于 GUI 的代理可能需要额外的保护措施，以避免未经授权的操作或滥用。
3.7可维护性
另一个维度与代理功能的维护和更新便捷性有关。API 代理受益于版本化的标准化接口。只要底层端点保持稳定，代理逻辑就基本保持完整。只需在提示中添加新的 API 描述，即可将其无缝集成到代理中，从而确保轻松维护。
相比之下，GUI 代理很容易受到界面重新设计、弹出窗口、布局变化以及元素重命名或重新定位的影响，如果 GUI 代理不熟悉这些变化，所有这些都可能破坏自动化。这种脆弱性会大大增加维护成本和频率，尤其是在需要频繁更新 UI 的应用程序中。
3.8透明度
从用户的角度来看，透明度指的是清晰地观察代理如何完成任务。API 代理通常在后台执行操作，对分步流程的可见性有限。用户通常只看到最终结果，而不知道调用了哪些端点。
相比之下，GUI 代理复制了用户级交互，使每次点击和文本输入在执行过程中都清晰可见。GUI 代理不像 API 调用那样在后台隐形运行，而是提供了一个可见且交互式的执行过程，允许用户根据需要观察、干预或调整工作流程。这种设计在需要逐步验证、训练模拟或需要视觉确认的任务自动化的场景中尤其有效。这提高了工作流程的可解释性，使人类观察者能够更直观地跟踪和验证代理的进度。
3.9Human-Like互动
与透明度密切相关的是模拟人类行为的概念。API代理采用纯程序化方法，直接执行函数调用，而非模拟用户交互。它们针对效率、可靠性和可扩展性进行了优化，但缺乏任务执行的任何可视化或交互表示。相比之下，GUI代理则复制了人类用户执行的精确步骤——浏览菜单、填写表单以及以自然、连续的方式与界面元素交互。这种类似人类的执行方式增强了可解释性，使用户更容易跟随和理解代理的操作，从而建立信任并获得更直观的用户体验。这通过将AI自动化与以用户为中心的工作流程相结合，引入了一种全新的人机交互范式。
3.10概括
总而言之，这些维度阐明了基于 API 和基于 GUI 的代理在实践中的根本区别。API 代理在强大的端点支持下能够提供高效、安全和可靠的服务，但受限于有限的公开功能。GUI 代理虽然适用性广，工作流程也更贴近用户，但必须克服可视化解析、界面变更和任务执行速度慢等挑战。随着软件生态系统的复杂性日益增长，理解这些不同的特性对于选择最合适的方法，或设计兼具两种范式优势的混合解决方案至关重要。
4、融合与“混合”方法
尽管基于 API 和基于 GUI 的代理传统上被视为独立的范式进行研究，但它们的概念基础并非相互排斥。在实践中，这些方法在众多场景中相互交叉或互补，从而催生出一种新兴的“混合”模型。通过借鉴 API 和 GUI 范式的优势，这种混合方法可以实现更广泛的用例覆盖、更高的效率以及更人性化的交互风格。虽然这些融合解决方案仍处于早期阶段，但它们重塑代理运作方式的潜力正日益显现。
4.1GUI 工作流上的 API 包装器
一些供应商通过引入“无头模式”或接受函数调用的脚本接口，将基于 GUI 的应用程序转换为准 API 服务。这种方法有效地将 GUI 交互抽象为结构化命令，使原本为人工导航设计的应用程序能够以更具程序化和可扩展性的方式实现自动化。例如，专门的会计应用程序传统上可能要求用户浏览多个对话框和菜单才能生成财务报告。然而，在无头模式或脚本版本中，同一个应用程序可以公开诸如GenerateReport之类的函数，从而无需手动 UI 导航即可直接执行。这在概念上类似于机器人流程自动化 (RPA) 机器人，它模仿用户操作，但也可以针对后端工作流程进行优化。
尽管这些包装器在底层仍然依赖于 GUI 工作流，但它们为开发人员提供了类似 API 的接口，从而简化了与更广泛的自动化流程的集成。这种转变代表了一种微妙而有效的融合形式：最初设计用于直接 GUI 交互的应用程序被重新解释为 API 服务，从而减少了对专用 GUI 代理的需求，同时保持了与现有软件生态系统的兼容性。通过将 GUI 自动化与结构化的类似 API 的接口连接起来，这种方法提高了效率、可扩展性和集成的便捷性，尤其是在必须将旧版应用程序集成到现代自动化框架的企业环境中。
4.2统一编排工具
企业级自动化框架和流程编排工具越来越多地提供单一、统一的环境，开发人员或运维人员无需深入底层代理机制即可构建高级工作流。例如，假设一家大型金融机构正在自动化其贷款审批流程。在编排工具中，用户可以设计一个流程图来检查客户的信用评分（使用安全的 API 端点），然后在信用评分达到特定阈值时更新客户关系管理 (CRM) 系统。如果没有相关的 API 来更新 CRM，平台可以无缝切换到基于 GUI 的代理，以类似用户的方式浏览 CRM 的 Web 界面。因此，该工具会自动确定对于每个任务，API 调用或 GUI 交互是否最合适。我们在图 4中展示了这样一个示例。通过让用户免受这些低级决策的影响，编排平台降低了复杂性并简化了复杂自动化管道的开发。
UFO（UI-Focused agentt）就是一个典型的例子，它提供了一个接口，允许每个应用程序集成其专用 API，并在可用时优先使用它们。但是，如果没有合适的 API，系统就会无缝地回退到基于 GUI 的交互。这种方法将决策委托给统一的 LLM 协调器，它会根据任务需求和系统功能动态地选择最合适的方法——API 或 GUI。
4.3低代码/无代码解决方案
低代码和无代码平台抽象了可视化界面背后的许多技术细节，使非专家（通常称为“公民开发者”）能够通过拖放组件构建应用程序或自动化程序。如图5所示 ，此订单处理工作流中的每个块都代表一项不同的任务：用户将“支付网关”块拖入设计器来处理交易，进行可视化配置，而在后台，API 代理会自动构建并向支付端点发送调用。然后，它连接到“配送服务”块以完成订单。在后台，平台通常会向支付和配送服务发出 API 调用，让用户专注于工作流的逻辑顺序，而不是低级协议。相反，如果某个步骤需要基于 GUI 的验证（例如，检查旧系统上的特定用户界面元素），平台可以无缝插入 GUI 代理，模拟人机与软件的交互。这种基于 API 和 GUI 驱动的操作相结合，可以轻松构建端到端自动化，将 API 代理的速度和可扩展性与以 GUI 代理为中心的操作的可访问性和可视化特性相结合。
4.4概括
这些策略展现了基于 API 和基于 GUI 的代理之间曾经泾渭分明的界限是如何逐渐融合的。这种混合方法充分利用了 GUI 驱动界面的灵活性和通用性，以及直接 API 调用的可靠性和性能。这种融合能够实现更全面的自动化，满足从快速数据处理到复杂的用户界面验证等各种场景的需求，无论是效率、以用户为中心的验证还是快速开发。尽管还需要进一步的研究和改进，但这些融合的范式预示着基于代理的自动化未来将更加广泛和智能，并能够无缝适应现代软件生态系统不断变化的复杂性。
5、API 与 GUI 代理：战略考虑
虽然前面几节已经在架构、可靠性、效率和潜在收敛性方面对基于 API 和 GUI 的 LLM 代理进行了对比，但许多实际部署都取决于一个更根本的问题：在各种实际条件下应该采用哪种范式？本节将提供选择最合适策略的指导，讨论一种方法明显优于另一种方法的场景，以及混合模型可能提供最大灵活性的情况。
5.1何时青睐 API 代理
当存在定义明确的编程接口时，基于 API 的代理往往是最有吸引力的选择。官方稳定的 API 通常附带严格的文档和版本控制，从而实现强大的错误处理和一致的性能。在这样的环境中，开发人员可以利用 API 调用固有的速度和可靠性来高效执行任务，从而最大限度地降低系统开销和延迟。当应用程序设计用于后端集成，或者企业级可靠性对于关键任务工作流至关重要时，这种方法尤其可取。通过利用稳定的端点，基于 API 的代理还可以减轻长期维护负担，因为系统变更通常只需要版本更新，而不是彻底的界面改造。
此外，API 代理提供对应用程序的受控访问，将功能限制在预定义且可管理的范围内。这在基于代理的系统中至关重要，因为安全性至关重要。在这种情况下，API 代理是理想的选择，因为它们的操作被限制在一组受约束的操作中，从而确保可预测且安全的交互。
5.2何时青睐 GUI 代理
在没有直接 API 或现有 API 仅能部分覆盖所需自动化任务的情况下，基于 GUI 的代理尤为重要。这在移动应用中尤为明显，因为每个应用都作为独立的环境运行，限制了外部 API 的访问。此外，移动设备上的系统级操作通常需要 root 权限，这进一步限制了 API 的可用性，因此基于 GUI 的自动化成为一种可行的替代方案。
GUI 代理的另一个关键优势是其能够执行可视化验证，这在需要在采取行动之前确认屏幕文本、UI 元素位置或界面一致性的工作流中至关重要。在这种情况下，GUI 代理能够像人类用户一样与软件交互，这比基于 API 的方法具有明显的优势。同样，缺乏可扩展后端服务的旧式或专有系统可以利用 GUI 驱动的自动化，使代理能够导航现有界面，而无需修改底层代码库或开发新的 API。这使得 GUI 代理在企业环境中尤为有价值，因为在企业环境中，实现和维护新的 API 集成不切实际或成本高昂。
此外，GUI 代理本身非常适合依赖交互式或图形操作的应用程序。诸如创建动画、在 Photoshop 中绘图或与复杂的设计工具交互等任务，最好通过直接的视觉交互而非 API 命令来执行。在这些情况下，基于 GUI 的自动化与人类与此类应用程序交互的自然方式高度相似，因此比 API 驱动的方法更受青睐。
5.3何时考虑混合方法
混合策略结合了两种范式的优势，提供统一的工作流程，以满足广泛的需求。当任务的某些方面可以无缝映射到现有 API，而其他组件仍然只能通过图形界面访问时，这种方法尤其有利。在这种情况下，使用基于 API 的代理进行数据密集型或编程简化的操作可以保持性能，而使用 GUI 代理处理专门的前端交互或可视化验证。此外，采用混合解决方案为未来的系统演进提供了灵活性；随着新 API 的推出，最初通过 GUI 管理的任务可以无缝过渡到 API 调用，从而避免大规模的架构重构。
5.4概括
总而言之，部署基于 API 还是基于 GUI 的代理的战略考量取决于目标软件的性质、所需的集成或验证级别以及长期可持续性考量。API 代理在存在稳定且记录在案的端点时表现出色，能够提供可靠且高效的自动化模式。GUI 代理在界面是唯一访问方式或必须进行可视化确认的情况下更具优势。最后，混合方法能够在这些优势之间取得平衡，使组织能够随着其软件生态系统的发展而进行调整。通过考虑这些因素，决策者可以确保选择最符合其特定需求的代理范式——API、GUI 或两者兼而有之。
6、结论与展望
计算自动化由来已久，但基于 LLM 的代理的出现代表着一次重大的飞跃。这些代理体现了两种核心范式：一种以定义明确的编程接口（API 代理）为中心，另一种则植根于与图形界面的类人交互（GUI 代理）。从设计上讲，这两种范式在操作原理上有所不同，导致架构选择、性能配置和实际适用性方面存在差异。然而，它们也展现出互补的优势——API 代理在速度、安全性和可靠性方面表现出色，而 GUI 代理则具有灵活性、广泛的适用性和透明性——这使得它们为未来的混合和融合做好了准备。
展望未来。LLM技术的不断成熟可能会强化代理开发的两个方面。一方面，功能日益强大的编码助手有望简化 API 的创建和维护，从而增强 API 代理的可扩展性。另一方面，强大的多模态模型的兴起将扩展基于 GUI 的代理的应用范围，从而实现更强大的视觉理解和更复杂的 GUI 操作。这些趋势预示着一个不断发展的生态系统，在这个生态系统中，以 API 为中心和以 GUI 为中心的方法将日益交织在一起。
展望未来，这些代理类型的无缝集成可能会催生出全新的软件形式——这些工具既能自动生成或优化 API，以实现高效的后端操作，又能动态编排用户界面元素，实现透明的前端交互。这种范式的融合有可能改变人机交互，模糊代码生成与可视化界面体验之间的界限。从长远来看，它可能会重塑我们对软件开发、用户体验以及构成数字生态系统基础的更广泛工作流程的理解。
