尽管这两种范式都很有前景，但基于 API 和基于 GUI 的 LLM 代理在其架构、开发方法和用户交互模型方面表现出显著差异。例如，如图1所示 ，基于 API 的代理安排 Google 日历会议只需提供正确的端点和身份验证，即可进行一次调用，立即创建活动。相比之下，基于 GUI 的代理会打开 Web 界面，直观地浏览日历，填写相关字段，然后单击按钮以确定会议详细信息。虽然基于 API 的方法往往更快、更节省资源，但它依赖于明确定义的端点和可靠的基础设施。相反，基于 GUI 的代理可以与应用程序的前端交互，但通常需要多个类似用户的步骤（鼠标单击、键盘输入），这可能会更慢且更容易出错。

这些权衡凸显了基于 API 和 GUI 的代理之间的根本区别，并引发了关于它们优缺点、功能重叠甚至必要性的激烈讨论。尽管它们看似竞争，但许多人认为，彻底审视两者的差异和共同点至关重要。事实上，目前尚无统一的框架或比较分析能够提供明确的指导，说明何时一种方法可能优于另一种方法，或者混合策略是否可以兼具两者的优势。

为了弥补这一差距，本文系统地考察了软件自动化领域中基于 API 和基于 GUI 的 LLM 代理的差异和潜在的融合。我们首先阐明每种范式的概念基础，然后在关键维度上进行深入的比较分析。随后，我们探讨了基于 LLM 的交互领域的持续创新如何逐渐模糊 API 和 GUI 代理之间的界限，并讨论了一种能够充分利用各自优势、弥补各自不足的混合方法。通过概述清晰的决策标准，我们旨在指导从业者和研究人员根据项目需求、资源限制和用户体验目标选择最合适的代理类型。最终，本文将成为学术界和行业专业人士的综合资源，提供关于这些代理类型差异、融合点以及如何演进以应对新兴挑战的深刻见解。

2、背景

在这个范例中，代理的功能受到一组预定义的工具、插件或函数调用的限制——统称为“API ”，如图2所示 。这组受限的函数不仅确保了可靠性和安全性，还简化了代理的决策空间。代理无需生成完整的程序代码，而是识别每个步骤需要调用的 API，并根据用户意图填充所需的参数。

LLMs 提示中包含相关的 API 信息，例如函数名称、描述、参数和模式。当用户发出自然语言请求时，LLM 代理会解读其意图并选择最合适的 API 来执行任务。这种方法已在许多最先进的模型和框架中得到广泛采用，包括 GPT-4 中的函数调用模式（function-call）以及 TaskWeaver的仅插件模式（plugin-only）。

2.2基于 GUI 的 LLM 代理

与 API 优先范式相反，基于 GUI 的 LLM 代理通过直接与 GUI 交互来运行，而不是调用预定义的函数。正如所定义的那样，这些代理可以描述为：

 

在 GUI 环境中运行的智能代理，利用 LLM 作为其核心推理和认知引擎，以灵活和自适应的方式生成、规划和执行操作。

 

 

 

3、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概括

4、融合与“混合”方法

尽管基于 API 和基于 GUI 的代理传统上被视为独立的范式进行研究，但它们的概念基础并非相互排斥。在实践中，这些方法在众多场景中相互交叉或互补，从而催生出一种新兴的“混合”模型。通过借鉴 API 和 GUI 范式的优势，这种混合方法可以实现更广泛的用例覆盖、更高的效率以及更人性化的交互风格。虽然这些融合解决方案仍处于早期阶段，但它们重塑代理运作方式的潜力正日益显现。

一些供应商通过引入“无头模式”或接受函数调用的脚本接口，将基于 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 与 GUI 代理：战略考虑

虽然前面几节已经在架构、可靠性、效率和潜在收敛性方面对基于 API 和 GUI 的 LLM 代理进行了对比，但许多实际部署都取决于一个更根本的问题：在各种实际条件下应该采用哪种范式？本节将提供选择最合适策略的指导，讨论一种方法明显优于另一种方法的场景，以及混合模型可能提供最大灵活性的情况。

6、结论与展望

计算自动化由来已久，但基于 LLM 的代理的出现代表着一次重大的飞跃。这些代理体现了两种核心范式：一种以定义明确的编程接口（API 代理）为中心，另一种则植根于与图形界面的类人交互（GUI 代理）。从设计上讲，这两种范式在操作原理上有所不同，导致架构选择、性能配置和实际适用性方面存在差异。然而，它们也展现出互补的优势——API 代理在速度、安全性和可靠性方面表现出色，而 GUI 代理则具有灵活性、广泛的适用性和透明性——这使得它们为未来的混合和融合做好了准备。

展望未来。LLM技术的不断成熟可能会强化代理开发的两个方面。一方面，功能日益强大的编码助手有望简化 API 的创建和维护，从而增强 API 代理的可扩展性。另一方面，强大的多模态模型的兴起将扩展基于 GUI 的代理的应用范围，从而实现更强大的视觉理解和更复杂的 GUI 操作。这些趋势预示着一个不断发展的生态系统，在这个生态系统中，以 API 为中心和以 GUI 为中心的方法将日益交织在一起。

展望未来，这些代理类型的无缝集成可能会催生出全新的软件形式——这些工具既能自动生成或优化 API，以实现高效的后端操作，又能动态编排用户界面元素，实现透明的前端交互。这种范式的融合有可能改变人机交互，模糊代码生成与可视化界面体验之间的界限。从长远来看，它可能会重塑我们对软件开发、用户体验以及构成数字生态系统基础的更广泛工作流程的理解。