UFO²: The Desktop AgentOS——桌面代理操作系统

这篇论文介绍了 UFO2，一个面向 Windows 桌面的 多智能体 AgentOS（桌面代理操作系统），旨在解决现有计算机使用代理（CUA）在真实桌面自动化中面临的系统级瓶颈。以下是对其研究内容的全面总结。

一、研究背景与核心问题

1.1 现有桌面自动化的局限

• 传统 RPA（机器人流程自动化）：依赖预定义脚本和表面 GUI 线索（像素区域、窗口标题），在动态界面变化下极其脆弱，维护成本高。

• 现有 CUA（计算机使用代理）：虽借助多模态 LLM 实现了自适应交互，但仍停留在概念原型阶段，存在三大系统级缺陷：

  1. 缺乏 OS 级集成：仅依赖截图和模拟鼠标键盘，忽略无障碍 API、应用进程状态、COM 接口等系统资源。

  2. 缺乏应用内省：将所有界面统一对待，无法利用应用原生 API 和领域知识。

  3. 破坏性执行模型：直接在用户桌面劫持鼠标键盘，导致用户无法同时操作，存在干扰和安全风险。

1.2 核心研究问题

如何构建一个稳健、深度集成的桌面自动化系统，能够灵活适应不断演进的界面，可靠地编排多样化应用，并最小化对用户工作流的干扰？

二、UFO2 的核心设计：作为系统基座的 AgentOS

UFO2 将自动化提升为 一等操作系统抽象，而非 GUI 之上的临时层。其架构由以下核心组件构成：

2.1 集中式多智能体架构

组件	角色
HostAgent	中央控制平面，负责解析用户意图、分解子任务、管理应用生命周期、调度与协调
AppAgent	应用专用执行运行时，每个绑定一个 Windows 应用（Excel、Outlook、Edge 等），封装 API 绑定、UI 检测器和知识库

• 通过 全局黑板 实现共享内存与代理间通信。

• 支持跨应用工作流（如从 Excel 提取数据填充 Web 表单）。

• 所有交互在 虚拟化 PiP 桌面 中运行，确保进程级隔离。

2.2 混合控制检测

• UIA 层：查询 Windows UI Automation API 获取结构化控件元数据（类型、标签、层次、启用状态）。

• 视觉层：集成 OmniParser-v2（YOLO-v8 + Florence-2）解析截图，识别非标准/自定义控件。

• 融合去重：基于 IoU 重叠丢弃冗余视觉检测，将仅视觉检测转为伪 UIA 对象，形成统一控制图。

2.3 统一 GUI-API 动作编排器（Puppeteer）

• 支持 GUI 动作（点击、按键）与 原生 API 调用 的动态选择。

• 优先使用语义等效 API 以提高可靠性和原子性；API 失败时优雅回退到 GUI 交互。

• 通过 Python 装饰器注册 API，自动纳入 AppAgent 动作空间。

• 示例：Excel 的 save_as API 可将五步 GUI 操作压缩为一次调用。

2.4 持续知识集成基座

• 静态知识：一键摄入用户手册、帮助文档到向量存储，运行时 RAG 检索。

• 动态经验：自动总结成功执行轨迹为 Example 记录，通过上下文学习（ICL）复用。

• 统一 RAG 流水线：支持版本化索引，随软件更新演进，无需微调模型。

2.5 推测性多动作执行

• 单次 LLM 推理预测多个连续动作，通过 Windows UIA API 在线验证每个动作的前提条件（如 is_enabled()、is_visible()）。

• 验证失败时提前退出并重新规划，保留部分结果。

• 效果：减少 LLM 调用频率，摊销规划成本，同时保持每步验证的正确性保证。

2.6 画中画（PiP）界面

• 基于 Windows RDP 回环创建隔离虚拟桌面，代理与用户可并行操作。

• 输入隔离：PiP 内鼠标键盘事件完全限定于该会话，不干扰主桌面。

• 安全 IPC：通过命名管道实现宿主与 PiP 间的加密双向通信。

• 系统级意义：将自动化执行与前台交互性解耦，引入 GUI 代理的隔离原语。

三、工程实现与专业化设计

组件	功能
多轮任务执行	基于 Session 的持久上下文记忆，支持用户细化指令、跟进任务、人工干预
安全保障机制	检测高风险动作（如删除文件），进入 PENDING 状态等待用户确认
一切皆可为 AppAgent	通过代理注册表将第三方组件（如 OpenAI Operator）包装为可插拔 AppAgent
AgentOS-as-a-Service	客户端-服务器架构，轻量客户端负责 GUI 操作，云端服务器托管编排与 LLM 查询
全面日志与调试	结构化 Markdown 执行日志，支持逐动作检查、重放和提示编辑
自动化任务评估器	基于 LLM-as-a-judge 的 CoT 推理，输出成功/部分/失败及部分分数

四、实验评估

4.1 实验设置

• 基准：Windows Agent Arena（WAA，154 任务/15 应用）、OSWorld-W（49 任务）

• 基线：UFO、NAVI、OmniAgent、Agent S、Operator

• 指标：成功率（SR）、平均完成步骤（ACS）

4.2 主要结果

配置	WAA SR	OSWorld-W SR
Operator	20.8%	14.3%
UFO²-base (GPT-4o)	23.4%	16.3%
UFO² (GPT-4o)	27.9%	28.6%
UFO² (o1)	30.5%	32.7%

• 成功率：UFO² 相比 Operator 提升约 10%（相对提升 50%），OSWorld-W 上翻倍。

• 混合控制检测：恢复高达 9.86% 的 UIA 失败案例。

• GUI + API：成功率提升 6.1%–8.2%，o1 模型步骤减少 58.5%。

• 知识集成：规划失败减少高达 17.7%。

• 推测性多动作：步骤减少高达 51.5%，成功率保持相当。

• Operator 作为 AppAgent：WAA 上从 20.8% 提升至 26.0%。

4.3 错误分析

• WAA：62% 失败为控制检测失败（UIA 覆盖不足）。

• OSWorld-W：规划错误比例更高（复杂工作流需要更深领域知识）。

4.4 效率分析

• LLM 推理主导延迟（约 10 秒/次），混合控制检测仅增加约 1 秒/步。

• 完全集成 UFO² 相比基线减少高达 50% 的步骤数。

• 整体任务完成时间约 1 分钟/任务。

五、讨论与未来工作

方向	内容
延迟优化	部署专用轻量级大动作模型（LAM）
缩小人类差距	微调视觉-语言模型 + 更紧密 OS/API 集成
跨平台泛化	设计原则可迁移至 Linux（AT-SPI）和 macOS（Accessibility API）

六、核心贡献总结

1. 深度 OS 集成：将自动化嵌入 Windows OS，通过内省、API 访问和细粒度控制实现系统级编排。

2. 统一 GUI-API 动作层：桥接传统 GUI 交互与应用原生 API，实现灵活、高效、稳健的自动化。

3. 混合控制检测：融合 UIA 元数据与视觉定位，在非标准界面中实现可靠控制定位。

4. 持续知识集成：检索增强记忆整合文档与执行日志，代理无需重新训练即可自主改进。

5. 推测性多动作执行：利用 UI 状态信号提前预测和验证动作序列，大幅降低 LLM 调用开销。

6. 非破坏性 UX：嵌套虚拟桌面环境支持自动化与用户活动并行，避免干扰。

7. 全面评估：20+ 真实 Windows 应用验证，成功率、效率和可用性均优于 SOTA CUA。

UFO2 通过将桌面自动化从“GUI 脚本”范式转变为“结构化、可编程的应用控制”，构建了一个深度集成 Windows OS 的多智能体 AgentOS，在成功率、效率和用户体验上全面超越现有计算机使用代理，为可靠、可扩展的真实世界桌面自动化开辟了 OS 原生路径。这里是自己的论文阅读记录，感兴趣的话可以参考一下，如果需要阅读原文的话可以看这里，如下所示：

项目地址在这里，如下所示：

摘要

近期由多模态大语言模型（LLM）驱动的计算机使用代理（CUA）为通过自然语言自动化复杂桌面工作流提供了有前景的方向。然而，大多数现有CUA仍停留在概念原型阶段，受限于浅层的操作系统集成、脆弱的基于截图的交互以及破坏性的执行方式。

我们提出UFO2，一种面向Windows桌面的多代理AgentOS，将CUA提升为实用的系统级自动化方案。UFO2具有一个集中式的HostAgent用于任务分解与协调，以及一组应用专用的AppAgent，配备原生API、领域特定知识和统一的GUI-API动作层。该架构在保持模块化和可扩展性的同时，实现了稳健的任务执行。混合控制检测流水线融合了Windows UI Automation（UIA）与基于视觉的解析，以支持多样化的界面风格。通过推测性多动作规划进一步提升了运行时效率，减少了每步LLM开销。最后，画中画（PiP）界面支持在隔离的虚拟桌面内进行自动化，使代理和用户可以并发操作而互不干扰。

我们在20多个真实Windows应用程序上评估了UFO2，证明其相较于先前CUA在稳健性和执行准确性方面有显著提升。结果表明，深度操作系统集成开辟了通往可靠、用户对齐的桌面自动化的可扩展路径。

关键词：计算机使用代理、大语言模型、桌面自动化、Windows系统

图1. (a) 现有CUA与(b)桌面AgentOS UFO2的对比。

1 引言

桌面应用程序自动化长期以来一直是提高工作效率的核心。商业机器人流程自动化（RPA）平台如UiPath [1]、Automation Anywhere [2]和Microsoft Power Automate [3]体现了这一趋势，它们使用预定义脚本通过图形用户界面（GUI）[4, 5]复制重复的用户交互。然而，这些基于脚本的方法在动态、持续变化的环境中往往表现脆弱[6]。微小的界面变化就可能破坏底层自动化脚本，需要人工更新和大量维护工作。随着软件生态系统日益复杂和异构，基于脚本的自动化脆弱性严重限制了可扩展性、适应性和实用性。

近年来，计算机使用代理（CUA）[7]作为一种有前景的替代方案崭露头角。这些系统利用先进的多模态大语言模型（LLM）[8, 9]来解释多样化的用户指令、感知GUI界面并生成自适应动作（如鼠标点击、键盘输入），无需固定脚本[7]。早期原型如UFO [10]、Anthropic Claude [11]和OpenAI Operator [12]表明，此类LLM驱动的代理能够稳健地自动化传统RPA流水线难以处理的复杂或模糊任务。然而，尽管取得了这些进展，当前的CUA实现仍主要停留在概念阶段：它们主要优化视觉定位或语言推理[12-16]，却很少关注与桌面操作系统（OS）和应用程序内部的系统级集成（图1(a)）。

依赖原始GUI截图和模拟输入事件存在若干缺点。首先，纯视觉输入可能噪声大且冗余，增加LLM的认知负担并降低执行效率[17]。其次，现有CUA很少利用操作系统的原生无障碍接口、应用级API或详细的进程状态——这是显著提升决策准确性、降低延迟和实现更可靠执行的错失机会。最后，在主用户桌面上模拟鼠标和键盘事件会在自动化期间将用户锁定在外，造成糟糕的用户体验（UX）。这些限制必须在CUA从有趣的原型成熟为稳健、可扩展的真实世界桌面自动化解决方案之前得到解决，这引出了我们的核心研究问题：

如何构建一个稳健、深度集成的桌面自动化系统，能够灵活适应不断演进的界面，可靠地编排多样化的应用程序，并最大限度地减少对用户工作流的干扰？

为此，我们提出UFO²，一种新的Windows AgentOS，将桌面自动化重新构想为一等的操作系统抽象。与先前将自动化视为截图和模拟输入事件之上的一层CUA不同，UFO²被架构为一个深度集成的多代理执行环境——将操作系统能力、应用特定的内省和领域感知规划嵌入到核心自动化循环中，如图1(b)所示。

在其基础上，UFO²为自然语言驱动的自动化提供了模块化的系统级基座。一个集中式协调器HostAgent解释用户指令，将其分解为语义上有意义的子任务，并动态分派执行给专门的AppAgent——为特定Windows应用程序量身定制的专家模块。每个AppAgent配备可扩展的应用特定API工具箱、混合GUI-API动作接口以及关于应用程序能力和语义的集成知识。该架构支持跨多个并发应用程序的稳健编排，支持跨越Excel、Outlook、Edge等的工作流。

为了在全部应用UI范围内实现可靠执行，UFO²引入了混合控制检测流水线，将Windows UI Automation（UIA）API与先进的视觉定位模型[18]相结合。这允许代理内省和操作标准及自定义UI组件，弥合结构化无障碍树与像素级感知之间的差距。此外，UFO²持续将外部文档、补丁说明和过往执行轨迹整合到统一的向量化记忆层中，使每个AppAgent无需重新训练即可逐步改进其行为。

在交互层，UFO²暴露了统一的GUI-API执行模型，代理可以无缝地将传统GUI动作（如点击、按键）与原生Windows或应用特定API相结合。这种混合方法提高了执行效率，降低了对UI布局变化的脆弱性，并支持更具表现力的高级操作。为了进一步减少基于LLM的动作规划的延迟，UFO²引入了推测性多动作执行引擎，在单次推理步骤中通过轻量级控制状态检查主动推断和验证动作序列——在不影响正确性的情况下大幅减少推理开销。

最后，为了确保实用且非侵入式的用户体验，UFO²引入了新颖的画中画（PiP）界面：一个安全的嵌套桌面环境，代理可以在用户主会话之外独立执行。PiP构建在Windows原生远程桌面回环基础设施之上，实现了无缝的并排用户-代理多任务处理，不干扰用户主桌面，解决了现有CUA最持久的UX限制之一。

总之，这些设计原则使UFO²不仅仅是一个更智能的代理，而是自动化的新OS级抽象——将桌面工作流转化为可编程、可组合和稳健的实体。综上所述，本文做出以下贡献：

深度OS集成：我们设计并实现了UFO²，一个多代理AgentOS，深度嵌入Windows OS，通过内省、API访问和细粒度执行控制来编排桌面应用程序。
统一GUI-API动作层：我们提出了混合动作接口，桥接传统GUI交互与应用原生API调用，实现灵活、高效和稳健的自动化。
混合控制检测：我们引入了融合流水线，结合UIA元数据与基于视觉的检测，即使在非标准界面中也能实现可靠的控制定位。
持续知识集成：我们构建了检索增强记忆，整合文档和历史执行日志，使代理无需重新训练即可随时间自主改进。
推测性多动作执行：我们通过使用UI状态信号提前预测和验证动作序列，减少LLM调用开销。
非破坏性UX：我们开发了嵌套虚拟桌面环境，允许自动化与用户活动并行进行，避免干扰并提高可采用性。
全面评估：我们在20多个真实Windows应用程序上评估UFO2，显示在成功率、执行效率和可用性方面相较于最先进的CUA（如Operator）持续改进。

总体而言，UFO2通过将范式从GUI脚本转向结构化、可编程的应用程序控制，推进了OS原生自动化的愿景。即使与GPT-4o等通用模型配对，UFO2也以超过10%的优势超越专用CUA，突显了系统级集成和架构设计的变革性影响。

2 背景

2.1 传统桌面自动化的脆弱性

几十年来，桌面自动化一直依赖脆弱的技术来复制人类与基于GUI的应用程序的交互。商业RPA工具——如UiPath [1]、Automation Anywhere [2]和Microsoft Power Automate [3]——通过记录和回放鼠标移动、按键或基于规则的脚本来运作。这些系统严重依赖表面级GUI线索（如像素区域、窗口标题），对应用程序状态几乎没有内省能力。

虽然在企业环境中广泛部署，传统RPA系统表现出较差的稳健性和可扩展性[19]。即使是微小的UI更新——如重新排列按钮或重命名菜单——也可能悄无声息地破坏自动化脚本。维护正确性需要频繁的人工干预。此外，这些工具缺乏对应用程序工作流的语义理解，无法推理或适应新任务。因此，RPA工具仍然局限于稳定环境中的狭窄、重复性工作流，远非通用自动化。

2.2 计算机使用代理的兴起

大语言模型（LLM）和多模态感知的最新进展催生了一类新的自动化系统，称为计算机使用代理（CUA）[7-9]。CUA旨在通过利用LLM解释用户指令、感知GUI布局并合成点击和按键等动作，跨应用程序和任务进行泛化。

早期CUA如UFO [10]证明了多模态模型（如GPT-4V [20]）可以将自然语言请求映射为GUI动作序列，无需手工编写脚本。最近的行业原型，包括Claude3.5（Computer Use）[11]和OpenAI Operator [12]，进一步推进了边界，在多个应用程序上执行真实的桌面工作流。

这些CUA代表了从静态RPA脚本到自适应、通用自动化的有前景的演进。然而，尽管其精密复杂，当前CUA在很大程度上仍是研究原型，受限于阻碍实际部署的架构和系统级限制。

2.3 CUA中的系统挑战

当前CUA在三个基本方面存在不足，我们认为这源于缺失的操作系统抽象：

（1）缺乏OS级集成。 大多数CUA通过截图和低级输入仿真（鼠标和键盘事件）与系统交互。它们忽略了丰富的系统接口，如无障碍API、应用程序进程状态和原生进程间通信机制（如shell命令、COM接口[21]）。这种肤浅的交互模型限制了可靠性和效率——每个动作都必须从像素推断，而非从结构化状态推断。

（2）缺乏应用程序内省。 CUA通常作为通才运行，对应用程序特定能力的感知有限。它们统一对待所有界面，缺乏利用内置API或供应商文档的能力。因此，它们无法推理高级概念，除非这些流程被明确嵌入模型中。这种刚性限制了其泛化能力并使维护成本高昂。

（3）破坏性且不安全的执行模型。 大多数CUA直接在用户桌面会话上驱动自动化，劫持真实鼠标和键盘。这种设计阻止用户在执行期间与系统交互，引入干扰风险，并违反了安全系统设计的基本隔离原则。长时间运行的任务——尤其是涉及多次LLM查询的任务——可能垄断会话长达数分钟。

2.4 缺失的抽象：操作系统对自动化的支持

尽管对智能、语言驱动自动化的需求不断增长，现有操作系统没有提供一等抽象来将GUI应用程序控制暴露给外部代理。与系统调用、文件或套接字相比，GUI工作流仍然不透明且不可编程。因此，RPA和CUA系统都被迫作为GUI之上的临时层运行，没有统一的执行、协调或内省基座。

图2. UFO²架构概览。

本文认为自动化应被提升为系统原语。我们提出UFO²，一种新的Windows AgentOS，通过将自动化嵌入为深度集成的OS抽象——将GUI控件、应用程序API和任务编排暴露为可编程、可检查和可组合的系统服务——来解决这些限制。

3 UFO²的系统设计

受第2节强调的挑战的启发，UFO²旨在无缝解释自然语言用户请求并可靠地自动化跨多种Windows应用程序的任务。本节提供UFO²的架构概述（第3.1节），并解释每个组件如何与底层OS深度集成，以克服当前CUA的缺陷，最终实现实用的、稳健的桌面自动化AgentOS。

3.1 UFO²作为自动化的系统基座

图2展示了UFO²的高层架构，它为Windows桌面上的面向任务自动化提供了结构化运行时环境。UFO²作为本地守护进程部署，使用户能够发出自然语言请求，这些请求被转换为跨越多个GUI应用程序的协调工作流。系统为编排、内省、控制执行和代理协作提供核心抽象——将这些作为系统级服务暴露，类似于传统OS中的服务。

UFO²的核心是一个中央控制平面HostAgent，负责解析用户意图、管理系统状态并将子任务分派给一组称为APPAGENT的专用运行时模块。每个APPAGENT专用于特定应用程序（如Excel、Outlook、文件资源管理器），封装了观察和控制该应用程序所需的所有逻辑，包括API绑定、UI检测器和知识库。这些模块作为具有应用程序特定语义的隔离执行上下文运行。

在收到用户请求后，HostAgent将其分解为一系列子任务，每个子任务映射到最适合完成它的应用程序。如果相应应用程序尚未运行，HostAgent使用原生Windows API启动它并实例化相应的APPAGENT。执行通过结构化循环进行：每个APPAGENT持续观察应用程序状态（通过无障碍API和基于视觉的检测器），使用ReAct风格规划循环[22]推理下一步操作，并调用适当的动作——无论是GUI事件还是原生API调用。此循环持续到子任务终止，无论是成功还是由于不可恢复的错误。

UFO²通过全局黑板接口实现共享内存和控制流，允许HostAgent和APPAGENT交换中间结果、依赖状态和执行元数据。该架构支持跨应用程序边界的复杂工作流——例如，从电子表格提取数据并使用它填充Web表单字段——无需手工编写的脚本或协调逻辑。关键的是，所有交互都发生在虚拟化的、基于PiP的桌面环境中，确保进程级隔离和安全的多应用程序并发。

设计理念：集中式多代理运行时。 UFO²采用集中式多代理[10, 23-25]运行时以支持可靠性和可扩展性。集中式HostAgent充当控制平面，简化任务级编排、错误处理和生命周期管理。同时，每个APPAGENT被架构为松散耦合的执行器，封装深度的应用程序特定功能。

APPAGENT级别的模块化允许开发者和第三方贡献者通过编写新的应用程序接口和API绑定来增量扩展UFO²的能力。这些代理是可发现的、自包含的，并由运行时根据需要动态实例化。从安全和可演化性的角度来看，这种关注点分离确保应用程序逻辑可以独立于核心任务编排引擎演进。

总之，HostAgent-APPAGENT模型使UFO²能够作为可扩展、可插拔的GUI自动化运行时基座——抽象掉异构接口的复杂性，并为结构化应用程序行为提供统一的系统接口。

3.2 HostAgent：系统级编排与执行控制

HostAgent作为UFO²的集中式控制平面。它负责解释用户指定的目标，将其分解为结构化子任务，实例化和分派APPAGENT模块，并协调它们在系统中的进度。HostAgent为内省、规划、应用程序生命周期管理和多代理同步提供系统级服务。

图3. HostAgent的架构。

图3概述了HostAgent的架构。HostAgent运行在原生Windows基座之上，监控活动应用程序，根据需要发出shell命令生成新进程，并管理应用程序特定AppAgent实例的创建和销毁。所有协调通过持久状态机进行，该状态机管理执行阶段之间的转换。

职责与接口。 HostAgent暴露以下系统服务：

• 任务分解。 给定用户的自然语言输入，HostAgent识别底层任务目标并将其分解为依赖排序的子任务图。

• 应用程序生命周期管理。 对于每个子任务，HostAgent检查系统进程元数据（通过UIA API）以确定目标应用程序是否正在运行。如果没有，它启动程序并向运行时注册。

• AppAgent实例化。 HostAgent为每个活动应用程序生成相应的AppAgent，为其提供任务上下文、内存引用和相关工具链（如API、文档）。

• 任务调度与控制。 全局执行计划被序列化为有限状态机（FSM），允许HostAgent强制执行执行顺序、检测故障并解决代理间的依赖关系。

• 共享状态通信。 HostAgent读写全局黑板，实现代理间通信和系统级可观测性，用于调试和重放。

系统感知与内省。 为了执行其控制功能，HostAgent融合了两层系统内省：

1. 视觉层。 捕获桌面工作空间的像素级截图，实现粗粒度布局理解。

2. 语义层。 查询Windows UIA API以提取关于应用程序、窗口和控制层次的结构化元数据。

这种双重感知使HostAgent能够解决歧义、检测运行时不一致，并以上下文感知的决策指导代理。

结构化输出接口。 HostAgent产生结构化输出以驱动下游执行：

• 子任务计划：详细说明分解子任务的高层执行计划。

• Shell命令：用于管理应用程序生命周期的shell级调用序列。

• 分配应用程序：选择用于实例化AppAgent的应用程序的进程名和索引，将用于执行下一个子任务。

• 代理消息：传递给AppAgent实例以进行本地化执行的上下文特定指令。

• 用户提示：在歧义或失败情况下的交互式澄清请求。

• HostAgent状态：HostAgent内部FSM中的当前状态。

通过有限状态控制器执行。 HostAgent的核心逻辑被建模为有限状态控制器（图4），具有以下状态：

• CONTINUE：主执行循环；评估哪些子任务已准备好启动或恢复。

• ASSIGN：选择可用的应用程序进程并生成相应的AppAgent代理。

• PENDING：等待用户输入以解决歧义或收集额外任务参数。

• FINISH：所有子任务完成；清理代理实例并最终确定会话状态。

• FAIL：在不可恢复的失败时进入恢复或中止模式。

这种显式FSM结构使HostAgent能够稳健地编排动态工作流，同时保持对任务完成和故障隔离的高层保证。

图4. HostAgent管理的控制状态转换。

内存与状态管理。 HostAgent维护两类持久状态：

• 私有状态：跟踪用户意图、计划进度和当前会话的控制流。

• 共享黑板：一个并发的、仅追加的内存空间，通过记录关键观察、中间结果和执行元数据来促进透明代理通信，所有APPAGENT实例均可访问。

这种分离确保本地上下文保持封装，而全局协调在系统中可见且一致。这种分离确保每个代理保持干净、有作用域的状态，同时受益于全局一致的视图以进行协作任务执行。

总体而言，HostAgent抽象掉了在桌面环境中管理并发、有状态、跨应用程序工作流的复杂性[26]。其控制平面角色实现了模块化执行、协调进度和稳健的任务生命周期管理——这些都是将桌面自动化扩展到真实世界部署的关键特性。

3.3 APPAGENT：应用专用执行运行时

APPAGENT是UFO2中的核心执行运行时，负责在特定Windows应用程序内执行单个子任务。每个APPAGENT作为由中央HostAgent（第3.2节）启动和编排的隔离、应用专用工作进程运行。与统一对待所有GUI上下文的单体CUA不同，每个APPAGENT针对单个应用程序量身定制，并以其API表面、控制语义和领域逻辑的深度知识运行。

图5概述了APPAGENT的架构。在从HostAgent接收子任务和执行上下文后，APPAGENT初始化一个ReAct风格的控制循环[22]，在其中迭代感知当前应用程序状态、推理下一步，并执行GUI或基于API的动作。这种混合执行层——通过Puppeteer接口实现——通过优先使用结构化API（在可用时）来实现对动态复杂UI的可靠控制，同时在必要时保留对基于GUI交互的回退。

感知层。 每个APPAGENT融合多个感知流：

• 视觉输入：捕获GUI截图用于布局理解和控制定位。

• 语义元数据：从Windows UIA API提取，包括控件类型、标签、层次结构和启用状态。

• 符号标注：使用Set-of-Mark（SoM）技术[27]在截图上标注控件。

这些融合信号被转换为结构化观察对象，包含GUI截图和候选控件元素集。这种多模态表示使得对应用程序状态的理解更加全面，远超原始视觉输入。

结构化输出。 基于此状态，APPAGENT产生结构化输出：

• 目标控件（如适用）

• 动作类型（如点击、输入、调用API）

• 参数或负载

• 使用思维链（CoT）[28, 29]的推理轨迹和规划

• 本地FSM中的当前状态

这种设计将感知与执行解耦，实现确定性重放、离线调试和细粒度可观测性。

通过有限状态控制器执行。 每个APPAGENT维护一个本地有限状态机（图6），管理其在分配的应用程序上下文中的行为：

• CONTINUE：动作规划和执行的默认状态。

• PENDING：对安全关键动作（如破坏性操作）调用；需要用户确认。

• FINISH：任务完成；执行结束。

• FAIL：检测到不可恢复的失败（如应用程序崩溃、权限错误）。

这种有界执行模型将故障隔离到当前任务，并支持安全抢占、重试或委托。FSM还支持可中断工作流，可以从中间检查点恢复。

内存与状态协调。 为了实现有状态执行并保持上下文感知，每个APPAGENT维护：

• 私有状态：所有已执行动作、控制决策和CoT轨迹的本地日志。

• 共享状态：对系统级黑板的更新，包括中间输出、遇到的错误和应用程序级见解。

这种双内存设计使APPAGENT能够代表HostAgent自主行动，同时与更广泛的系统保持同步。它还支持可组合性：一个APPAGENT的输出可以成为下游子任务中另一个APPAGENT的输入。

应用感知SDK与可扩展性。 为了支持新应用程序的快速接入，UFO2暴露了一个SDK，封装了APPAGENT的开发和维护。开发者可以通过声明式接口注册应用特定API，包括函数元数据、参数模式和提示绑定。领域特定的帮助文档和补丁说明可以摄入可搜索的知识库，代理在运行时查询。

图5. APPAGENT的架构，UFO2中的每应用程序执行运行时。

图6. APPAGENT运行时的控制状态转换。

这种模块化抽象允许第三方供应商或高级用户扩展UFO2的能力而无需重新训练任何模型。新功能可以通过更新应用程序的APPAGENT模块来集成，将更改与系统其余部分隔离并最小化回归风险。

总结。 作为每应用程序执行运行时，每个APPAGENT提供模块化、领域感知的控制，在效率和稳健性方面超越通用GUI代理。其混合感知-动作循环、基于插件的可扩展性和本地故障遏制使UFO2能够以最小的系统级中断扩展到大型应用程序生态系统。

3.4 混合控制检测

GUI元素的可靠感知是使APPAGENT能够以确定性和安全的方式与应用程序界面交互的基础。然而，真实世界的GUI环境表现出显著的异构性：一些应用程序通过Windows UI Automation（UIA）API暴露结构良好的无障碍数据，而其他应用程序——尤其是遗留或自定义应用程序——使用完全绕过UIA的非标准工具包渲染关键控件。

为了解决这种差异，UFO2引入了混合控制检测子系统，融合基于UIA的元数据与基于视觉的定位[18, 30, 31]，为每个应用程序窗口构建统一且全面的控制图（图7）。这种设计确保了覆盖范围和可靠性，为下游动作规划和执行形成了弹性感知基础。

UIA层检测。 在可用时，UIA提供了语义丰富且高精度的接口来枚举屏幕控件。检测流水线首先查询无障碍树以提取满足一组运行时谓词（如is_visible()、is_enabled()）的控件。这些控件被标注其属性（类型、标签、边界框）并分配稳定标识符，形成初始控制图。

视觉层增强。 为了增强对UI不可见或自定义渲染控件的感知流水线，我们集成了OmniParser-v2 [18]，一种为快速准确GUI解析设计的基于视觉的定位模型。OmniParser-v2结合轻量级YOLO-v8 [32]检测器和微调的Florence-2（0.23B）[33]编码器来处理原始应用程序截图并识别额外的交互元素。每个检测包括控件类型、置信度分数和空间边界框。

融合与去重。 我们通过基于边界框重叠执行去重来统一这两个流。与任何UIA派生控件交并比（IoU）大于10%的视觉检测被丢弃。剩余的仅视觉检测使用轻量级UIAWrapper抽象转换为伪UIA对象，允许它们无缝集成到APPAGENT流水线的其余部分。这个融合控制集被传递到下游的基于SoM的标注模块[27]。图7展示了涉及混合渲染GUI的典型场景。黄色边界框表示标准UIA检测元素，蓝色边界框表示仅视觉检测。两者都被集成到APPAGENT消费的单个可操作控制图中。

图7. UFO2中采用的混合控制检测方法。

图8. Puppeteer作为统一执行引擎，协调GUI动作和原生API调用。

3.5 统一GUI-API动作编排器

APPAGENT可以与暴露两类不同接口的应用程序环境交互：GUI前端，普遍可观察但往往脆弱；以及原生API，高保真但需要显式集成[17]。为了在单一运行时抽象下统一这些异构执行后端，UFO2引入了Puppeteer，一个模块化执行编排器，为每个动作步骤动态选择GUI级自动化和应用特定API（图8）。这种设计显著提高了任务稳健性、延迟和可维护性。否则需要长时间GUI交互序列的任务（如迭代选择和格式化Excel单元格）通常可以折叠为单个API调用，减少执行时间和故障表面积[17, 34]。

图9. Excel的API注册示例。

Puppeteer支持轻量级API注册机制，使开发者能够在目标应用程序中暴露高级操作。API使用简单的Python装饰器接口注册，如图9所示。每个函数被包装元数据——名称、参数模式和应用绑定——并自动纳入APPAGENT的运行时动作空间。

在运行时，UFO2提示APPAGENT采用决策策略为每个操作选择最合适的执行路径。如果语义等效的API可用，Puppeteer优先使用它而非GUI自动化，以提高可靠性和原子性。如果API失败或不可用（如缺少绑定或运行时权限错误），系统通过模拟点击或按键优雅地回退到基于GUI的控制。这种运行时灵活性允许APPAGENT在异构环境中保持稳健性而不牺牲通用性。

Puppeteer将UFO2中的动作执行从单体GUI中心模型转变为灵活的、OS集成的控制层，混合了感知敏捷性和语义精度。这种混合执行模型不仅提高了系统性能和稳定性，还为未来桌面代理中应用特定能力的可持续集成奠定了基础。

图10. UFO2中知识基座的概览，结合静态文档与动态执行历史。

3.6 持续知识集成基座

与传统CUA严重依赖静态训练语料库不同，UFO2引入了持久且可扩展的知识基座，支持应用特定理解的运行时增强。如图10所示，该基座使每个APPAGENT能够检索、解释和应用外部文档和先前执行轨迹，而无需重新训练底层模型。这种混合记忆设计功能类似于OS级元数据管理器，抽象了两种关键知识流：静态参考（如用户手册）和动态经验（如执行日志）。

从文档引导。 大多数真实世界桌面应用程序通过用户指南、帮助菜单或在线教程暴露大量任务级文档。UFO2通过提供一键式接口来解析和摄入此类文档到应用特定向量存储中，从而利用这一资源。文档被结构化为JSON记录，在request字段中具有自然语言描述，在guidance字段中具有详细执行指导。

在运行时，当APPAGENT收到子任务时，它查询此索引存储以检索相关指导，然后注入代理的提示中。这种机制有效缓解冷启动问题——特别是在处理新应用程序或不常见操作时——通过用领域基础的程序性知识丰富代理的推理上下文。

从经验中强化。 除了静态知识，UFO2持续从其自身执行历史中学习。每次自动化运行产生结构化日志——包括自然语言任务描述、执行的动作序列、应用程序截图和最终结果。定期地，这些日志由摘要模块离线挖掘，将成功轨迹提炼为可重用的Example记录。

每条记录包含任务签名和关联的分步计划，存储在应用特定的示例数据库中。当未来遇到类似任务时，APPAGENT使用上下文学习（ICL）[35-38]检索相关演示并提高执行保真度。这种动态强化流水线将系统转变为随着使用而改进的长期代理，而不引入微调的脆弱性或运营成本[39]。

运行时RAG集成。 在系统层面，知识基座充当检索增强生成（RAG）层[40-43]，弥合预训练语言模型与应用特定需求之间的差距。由于帮助文档和示例都用语义嵌入索引，检索流水线快速、可解释且缓存友好。此外，版本化索引确保知识制品可以与软件更新一起演进，防止模型过时并支持长部署周期中的稳健执行。

通过将静态和经验知识集成到统一的RAG流水线中，UFO2将CUA从脆弱的、训练时构造转变为动态、演化的代理。该基座在实现复杂、异构应用生态系统的可持续自动化方面发挥着基础性作用。

3.7 推测性多动作执行

传统CUA遭受根本性的执行瓶颈：每个自动化步骤孤立执行，需要为每个GUI动作进行完整的LLM推理。这种逐步推理循环引入过度延迟，增加系统资源使用，并增加累积错误率——特别是在与复杂或多阶段工作流交互时[17]。根本原因是GUI环境的动态和不确定性质，其中任何单个动作都可能改变界面并使未来计划失效。

为了克服这些限制，UFO2引入了称为推测性多动作执行的系统级优化，受处理器设计中推测执行和指令流水线的经典思想启发。UFO2不是每次LLM调用发出一个动作，而是使用单次推理传递推测性地生成一批可能的下一步骤，并通过紧密OS集成在运行时验证其适用性。我们在算法1中给出了算法。

推测性执行器分三个阶段运作：

1. 动作预测：APPAGENT发出单个LLM查询以在其当前上下文中预测多个可能的动作。每个预测步骤包括目标控件、预期操作和理由。

2. 运行时验证：对于每个动作，系统咨询Windows UIA API以验证动作的前提条件（如is_enabled()、is_visible()）。此检查确保每个目标控件仍然有效和可交互。

3. 顺序执行与提前退出：动作按顺序执行，如果任何验证因界面变化（如控件不再存在或被禁用）而失败，则立即停止。执行器然后报告部分结果集并提示代理重新规划。

图11. UFO2中的推测性多动作执行：带在线验证的批量推理。

算法1 UFO2中的推测性多动作执行

我们在图11中展示了推测性多动作执行的说明性示例。在这种情况下，APPAGENT最初计划在单一步骤中执行三个动作：点击Paste，然后Quick Style，最后Grid Filled。然而，在第二个动作之后，控件验证器检测到第三个动作（Grid Filled）所需的控件不再存在——可能是因为GUI布局因前一步骤而改变。Puppeteer然后在该点终止执行并返回部分结果。此示例突出了UFO2如何通过在执行前验证每个控件来安全处理推测性执行，确保即使在动态界面变化面前也保持稳健。

总体而言，这种策略大幅减少了LLM调用频率，并将动作规划的成本摊销到多个步骤，同时保持每步验证的正确性保证。关键的是，验证由可信的OS级API而非视觉模型执行，确保高可靠性并消除虚假交互。

4 画中画界面

UFO2的一个关键设计目标是在保持主桌面环境的响应性和可用性的同时提供高吞吐量自动化。现有CUA通常垄断用户工作空间，长时间夺取鼠标和键盘控制权，使系统在执行任务期间实际上不可用。为了克服这一点，UFO2引入了画中画（PiP）界面：一个由远程桌面回环驱动的轻量级虚拟化桌面窗口，实现完全隔离的代理执行，与活动用户工作流并行，如图12所示。

图12. 画中画界面：用于非破坏性自动化的虚拟桌面窗口。

4.1 最小干扰的虚拟化用户环境

与传统CUA在主桌面会话中运行不同，PiP界面呈现一个可调整大小、可移动的窗口，包含用户桌面的全功能副本。内部通过Windows原生远程桌面协议（RDP）回环[44]实现，创建托管在同一机器上的独立虚拟会话。在PiP会话中启动的应用程序继承用户的身份、凭据、设置和网络上下文，确保与前台操作的一致性。

从用户的角度来看，PiP窗口表现得像沙盒工作空间：自动化在后台执行，可见但不引人注目。用户保留对主桌面的完全控制，可以随意最小化或重新定位PiP窗口。这使UFO²能够执行长时间运行或重复性工作流（如数据输入、批量文件处理），而不会阻塞用户交互或降低响应性。

4.2 稳健的输入和状态隔离

为了确保代理动作和用户活动之间的稳健分离，UFO²利用RDP子系统在会话之间维护不同的输入队列和设备上下文。在PiP桌面内生成的鼠标和键盘事件完全限定在该会话中，不能干扰主桌面。类似地，GUI变化和焦点转换被限制在虚拟环境中。

这种级别的输入隔离对于防止意外干扰——无论是用户还是代理——至关重要，并确保自动化序列保持稳定，即使在同时进行前台活动时也是如此。该架构还支持受控错误恢复：PiP会话内的故障或意外UI状态不会传播到主桌面，保持用户环境的完整性。

4.3 安全的跨会话协调

尽管在视觉和操作上不同，PiP会话必须在逻辑上保持与宿主环境的连接。为了实现这一点，UFO²在PiP代理运行时和宿主侧协调器之间建立安全的进程间通信（IPC）通道。我们使用Windows命名管道实现，使用每会话凭据进行身份验证和加密[45]。

该IPC层支持双向消息传递：

• 从宿主到PiP：任务分配、进度轮询、取消和用户澄清。

• 从PiP到宿主：状态更新、完成报告和异常通知。

用户通过宿主桌面上的轻量级前端面板与自动化流水线交互，实现实时可见性和部分控制，而无需直接访问PiP窗口。这种透明而安全的通信通道确保了信任和可用性，特别是在长时间运行或部分监督的工作流中。

4.4 系统级影响

PiP界面不仅仅是UX改进——它是一种系统级抽象，协调了并发性、可用性和安全性。它将自动化执行与前台交互性解耦，为基于GUI的代理引入了新的隔离原语，并通过沙盒化副作用简化了故障恢复。通过以最小的系统开销利用现有RDP能力，PiP界面为可扩展桌面自动化提供了一种实用且向后兼容的方法。

图13. UFO中支持多轮细化的交互式会话模型。

5 实现与专业工程设计

我们将UFO实现为一个全栈桌面自动化框架，跨越超过30,000行Python和C#代码。Python作为代理编排、控制逻辑和API集成的核心运行时环境，而C#支持GUI开发、调试界面和Windows特定操作（如画中画桌面）。为了支持检索增强推理，UFO利用Sentence Transformers [46]进行基于嵌入的文档和经验检索。

除了核心功能外，UFO还整合了多个专业工程组件，针对关键系统目标：可组合性、交互性、可调试性和可扩展部署。我们在下面重点介绍几个关键机制。

图14. UFO2中采用的安全保障机制。

5.1 多轮任务执行

与无状态的一次性代理不同，UFO采用基于会话的执行模型来支持迭代、交互式工作流（图13）。每个Session在多个执行Round中维护持久上下文记忆——包括中间结果、任务进度和应用程序状态。用户可以细化先前指令、启动后续任务，或在代理遇到模糊或不安全操作时进行干预。

这种多轮交互范式促进复杂任务的渐进收敛，同时保持透明性和人工监督。它使UFO2能够支持人在环中的细化策略，将静态LLM工作流与动态用户指导桥接。

5.2 安全保障机制

虽然自动化大幅提高生产力，但任何CUA都带有执行不安全操作的固有风险，可能对用户数据或系统稳定性产生不利影响[10, 47]。示例包括删除关键文件、过早终止应用程序（导致未保存数据丢失）或未经明确同意激活敏感设备（如网络摄像头）。这些操作构成严重风险，可能造成不可恢复的损害或安全漏洞。

为了缓解此类风险，UFO2整合了显式安全保障机制，旨在主动检测潜在危险动作，如图14所示。具体而言，每当APPAGENT识别到匹配预定义风险标准的动作时，它转换到专用的PENDING状态，暂停执行并主动提示用户确认。只有在收到明确用户同意后，代理才继续；否则，动作被中止以防止伤害。什么构成风险动作的定义和范围可通过简单的基于提示的界面完全自定义，使用户和系统管理员能够根据其组织的特定风险策略精确调整安全保障行为。这种灵活性允许安全保障系统随着自动化需求的发展而动态适应。

通过这种主动安全检查框架，UFO2显著降低了执行有害操作的可能性，从而增强了整体系统安全性、用户信任和真实世界部署中的稳健性。

图15. 代理注册表支持将第三方组件无缝包装到APPAGENT框架中。图16. AgentOS即服务中使用的客户端-服务器部署模型。

5.3 一切皆可为APPAGENT

为了支持生态系统可扩展性，UFO2引入了代理注册表机制，将任意第三方组件封装为可插拔的APPAGENT（图15）。通过简单的注册API，外部自动化解决方案——如领域特定副驾驶或专有工具——可以用轻量级兼容垫片包装，向HostAgent暴露统一接口。

这种设计使HostAgent能够同等对待原生和外部APPAGENT，根据能力和专长分派子任务。我们发现，即使是最小的包装器（如OpenAI Operator [12]）也能带来可观的性能提升，突显了系统的模块化及其以最小工程开销整合多样化执行后端的能力。

5.4 代理操作系统即服务

UFO2采用客户端-服务器架构以支持大规模实际部署（图16）。轻量级客户端驻留在用户机器上，负责GUI操作和应用程序侧感知。同时，集中式服务器（运行在本地或云端）托管HostAgent/APPAGENT逻辑、编排工作流并处理LLM查询。

这种控制与执行的分离提供了若干系统级优势：

• 安全性：敏感编排和模型执行与用户设备隔离。

• 可维护性：服务器端更新无需修改客户端即可传播。

• 可扩展性：系统可以通过集中式调度和负载管理支持多个并发客户端。

客户端-服务器边界强制清晰的服务抽象，促进模块化并简化企业环境中的部署。

5.5 全面日志与调试基础设施

稳健的可观测性对于诊断故障和支持持续系统改进至关重要。为此，UFO2实现了全面的日志和调试框架。每个会话捕获执行的细粒度轨迹：提示、LLM输出、控件元数据、UI状态快照和错误事件。

在每次会话结束时，UFO2将这些制品编译为结构化的Markdown格式执行日志。开发者可以检查逐动作的代理决策、可视化界面状态转换并重放行为以进行调试。该框架还支持提示编辑和选择性重放以进行有针对性的假设测试，显著加速调试周期。我们在图17中展示了这些工具的示例。

这种可观测性层作为代理行为的轻量级溯源系统，促进透明度、问责制和部署期间的快速迭代。

图17. UFO²中Markdown格式日志查看器和调试工具的图示。

5.6 自动化任务评估器

为了提供结构化反馈并促进持续改进，UFO2包含基于LLM-as-a-judge [48]的自动化任务评估引擎。如图18所示，评估器解析会话轨迹——包括动作、理由和截图——并应用CoT推理将任务分解为评估标准。

它分配部分分数并综合总体结果：成功、部分成功或失败。这种结构化结果馈入下游仪表板和调试工具。它还支持自我监控和失败案例的离线分析，闭合执行、诊断和改进之间的循环。

总结。 这些工程组件展示了UFO2对操作稳健性和可扩展性的承诺。从基于会话的执行和可插拔代理到面向服务的部署和可观测性基础设施，每个模块都反映了专注于将概念性LLM代理架构与大规模部署的系统现实桥接的设计。

图18. 基于LLM的任务评估器将CoT推理应用于结构化会话日志。

6 评估

我们在20多个Windows应用程序上严格测试了UFO²，包括办公套件、文件资源管理器和自定义企业工具，以评估性能、效率和稳健性。我们的实验表明：

1. UFO²实现了高出10%的任务完成率——相对于当前最佳CUA Operator提升50%——这得益于更深的OS级集成。

2. 混合UIA-视觉方法识别了UIA单独遗漏的自定义或非标准GUI元素，提升了具有专有控件界面的成功率。

3. 允许AppAgent调用原生API或GUI交互将完成率提高超过8%，降低延迟并减少纯点击工作流的脆弱性。

4. 利用外部文档和执行日志提高了UFO²处理不熟悉功能的能力，无需重新训练。

5. 推测性多动作执行将多个步骤合并为单个LLM调用，将推理成本降低高达51.5%，而不影响可靠性。

6. 通过启用一切皆可为AppAgent（如Operator），UFO²既提升了整体性能，也发掘了每个单独代理的全部潜力。

总体而言，这些结果证实了UFO²与Windows和应用程序级API的更深集成产生了更高的性能和更低的开销，为OS原生桌面自动化方法提供了令人信服的案例。

6.1 实验设置

部署环境。 基准环境托管在隔离的虚拟机上，配备8个AMD Ryzen 7 CPU核心和8 GB内存，匹配典型部署条件。所有GPT系列模型（GPT-4V、GPT-4o、o1和Operator）通过Azure OpenAI服务访问，而OmniParser-v2视觉模型在配备NVIDIA A100 80GB GPU的单独虚拟机上运行，以支持高效和高吞吐量的视觉定位。

基准。 我们使用两个已建立的以Windows为中心的自动化基准评估UFO²：

• Windows Agent Arena (WAA) [49]：包含跨15个常用Windows应用程序的154个实时自动化任务，包括办公生产力工具、Web浏览器、系统实用程序、开发环境和多媒体应用。每个任务包括用于自动正确性检查的自定义验证脚本。

• OSWorld-W [50]：专门为Windows定制的OSWorld基准的针对性子集，包含跨办公应用程序、浏览器交互和文件系统操作的49个实时任务。任务同样配备手工编写的验证脚本以进行可靠的结果验证。

每个任务独立运行，验证严格遵循每个基准提供的原始脚本。

基线。 我们将UFO²与五个代表性的最先进CUA进行比较，每个都利用GPT-4o作为推理引擎：

• UFO [10]：一个开创性的多代理、以GUI为中心的自动化系统，专为Windows设计，集成UIA和视觉感知。

• NAVI [49]：来自WAA的单代理基线，利用截图和无障碍数据进行GUI理解。

• OmniAgent [18]：采用OmniParser进行视觉定位，结合基于GPT的动作规划。

• Agent S [51]：具有经验驱动分层规划的多代理架构，针对复杂多步骤任务优化。

• Operator [12]：来自OpenAI的近期高性能CUA，通过截图模拟类人鼠标和键盘交互。

这些基线因其代表不同架构和设计范式（如单代理与多代理、纯GUI与混合方法）而被选中。为确保公平性，每个代理限制为每个任务最多30个执行步骤，反映实际用户期望并防止过长的任务执行。此外，我们评估了UFO²的基础版本（称为UFO²-base），仅使用UIA检测、基于GUI的交互，不含动态知识集成，以及UFO²的完整实现，具有混合控制检测、组合GUI-API交互和持续知识增强。API集成选择性地在OSWorld-W内的三个办公应用程序中实现作为说明性示例；WAA任务未引入API。更多实现细节见第6.4节。

评估指标。 我们使用两个主要性能评估指标：

• 成功率（SR）：定义为成功完成的任务百分比，通过基准自身的验证脚本验证。

• 平均完成步骤（ACS）：测量每个任务所需的LLM参与动作推理步骤的平均数。更少的步骤对应更高的效率，直接关联更低的推理延迟和减少的计算开销。

表1. 各代理在WAA和OSWorld-W基准上的成功率（SR）比较。

代理	模型	WAA	OSWorld-W
UFO	GPT-4o	19.5%	12.2%
NAVI	GPT-4o	13.3%	10.2%
OmniAgent	GPT-4o	19.5%	8.2%
Agent S	GPT-4o	18.2%	12.2%
Operator	computer-use	20.8%	14.3%
UFO²-base	GPT-4o	23.4%	16.3%
UFO²-base	o1	25.3%	16.3%
UFO²	GPT-4o	27.9%	28.6%
UFO²	o1	30.5%	32.7%

这些指标有效反映了功能有效性和实际效率，提供了真实世界自动化性能的清晰指标。

6.2 成功率比较

表1. 各代理在WAA和OSWorld-W基准上的成功率（SR）比较。

此外，UFO²的完整版本，结合混合GUI-API动作执行、高级视觉定位和持续知识集成，进一步放大了这些性能增益。使用GPT-4o，UFO²在WAA上达到27.9%的SR，大幅超过Operator 7.1%。性能差距在OSWorld-W上更加明显，UFO²达到28.6%的SR，而Operator为14.3%，有效翻倍其成功率。利用更强的o1模型进一步将UFO²的性能提升至30.5%（WAA）和32.7%（OSWorld-W），巩固其领先地位。

这些显著的性能改进清楚地强调了UFO²与OS级机制深度集成及其统一系统架构的优势。虽然先前CUA主要强调模型级优化或单纯依赖视觉界面，但我们的结果表明，稳健的系统级编排——结合结构化OS API、专门的应用知识和混合GUI-API交互——对于实现更高的任务可靠性和更广泛的自动化覆盖至关重要。关键的是，即使是通用、不太专门的模型如GPT-4o，当集成在全面的UFO²框架内时，也能超越高度专门的CUA（如Operator）。这一见解强化了架构设计和OS集成作为实用、可部署桌面自动化解决方案关键驱动力的价值。

性能细分。 表2呈现了WAA和OSWorld-W基准上按应用程序类型的成功率（SR）详细细分，使更深入理解UFO²在哪些方面取得特别强的结果，并识别进一步系统级改进的领域。在多个类别中，UFO²始终表现出优于基线CUA的性能，特别是在需要更深OS集成或复杂多步骤任务执行的应用程序场景中。

值得注意的是，UFO²在涉及Web浏览器和编码环境的任务中表现出色。例如，最强配置（UFO² with o1）在Web浏览器任务中达到令人印象深刻的40.0% SR——显著超过次优基线（OmniAgent）超过12%。类似地，在编码相关工作流中，UFO²（GPT-4o）达到最高SR 58.3%，显著超过所有竞争CUA。这些结果强调了UFO²混合GUI-API方法和持续知识集成的有效性，它们实现了更精确的动作推理，减少了GUI变化导致的脆弱性，并显著提升了多步骤工作流的可靠性。

细分进一步揭示了应用程序复杂性、流行度和系统级支持之间的明确关联。涉及LibreOffice（WAA的Office类别）的任务在所有评估的CUA中一致产生较低的SR，主要是由于对无障碍标准的遵守不足和不完整的UIA支持。相反，OSWorld-W任务主要使用Microsoft 365 Office应用程序，提供更丰富的OS原生API和结构化无障碍数据，导致更高的SR（UFO²-o1高达51.9%）。这种差异突出了稳健OS级集成和API可用性在实现高质量桌面自动化中的关键作用。

跨应用程序任务，尤其是在OSWorld-W中突出的，提出了更大的挑战。此类任务本质上需要复杂的任务分解和稳健的代理间协调，将CUA——甚至人类用户——推向极限。在这里，UFO²的多代理架构，由集中式HostAgent和专门AppAgent领导，展现出显著的前景，以9.1%的SR超过其他基线。尽管性能仍然相对温和，但它清楚地说明了系统化多代理协作和集中式编排在解决跨越传统应用程序边界的复杂场景中的力量。

总体而言，这些详细细分结果验证了UFO²的系统级设计原则，特别是其对深度OS和应用程序特定集成、多代理协调和灵活动作编排的强调。虽然在利基或支持较少的应用领域（如API可用性有限的自定义或遗留软件）仍有显著改进潜力，但UFO²的当前架构已经在实际、真实世界桌面自动化任务中提供了实质性、可测量的改进。

图19. UFO²-base（GPT-4o）在两个基准上的错误分析。

错误分析。 为了系统理解UFO²的局限性并识别进一步改进的机会，我们对UFO²-base（GPT-4o）在两个基准上的所有失败案例进行了详细人工审查。遵循类似于Agashe等人[51]的分类框架，每个失败被分类为三个不同的系统级类别之一：

• 规划错误：由不充分的高层任务理解引起的失败，通常反映为不完整或不正确的动作计划。这些错误表明代理的任务理解存在差距或对应用特定工作流的基础不足。

• 执行错误：高层计划合理但执行有缺陷的情况（如选择错误的控件、执行意外动作）。执行错误通常源于不准确的视觉推理、GUI元素与动作之间的错误关联或LLM的错误推理。

• 控制检测失败：代理未能检测或识别完成任务所需关键GUI控件的情况，通常由于非标准或自定义渲染的UI元素无法通过标准OS API完全访问。

图19总结了我们对UFO²-base的发现。在WAA基准上，超过62%的失败归因于控制检测失败，突出了标准UIA API覆盖的重大差距——特别是对于不严格遵守无障碍标准的第三方应用程序（如LibreOffice）。相反，OSWorld-W基准表现出更高的规划错误发生率，强调该集合中的任务通常涉及更复杂的工作流，需要超越简单视觉识别的更深领域知识或高级上下文推理能力。

这些观察提供了具体证据，证明特定系统级缺陷直接推动了UFO²完整版本中纳入的增强。控制检测失败的高频率验证了我们选择采用混合GUI检测流水线，用高级视觉定位技术补充标准UIA数据。类似地，规划错误的普遍性强调了整合更丰富外部文档、领域特定知识库和应用程序级API以加强任务理解和动作推理的关键作用。在后续章节中，我们明确展示了这些增量系统级改进如何逐步缓解每个已识别的错误类别，从而大幅提升UFO²的整体任务完成有效性。

表2. WAA和OSWorld-W上按应用程序类型的SR细分。

代理	模型	WAA Office	Web Browser	Windows System	Coding	Media & Video	Windows Utils	OSWorld-W Office	Cross-App
UFO	GPT-4o	0.0%	23.3%	33.3%	29.2%	33.3%	8.3%	18.5%	4.5%
NAVI	GPT-4o	0.0%	20.0%	29.2%	9.1%	25.3%	0.0%	18.5%	0.0%
OmniAgent	GPT-4o	0.0%	27.3%	33.3%	27.3%	30.3%	8.3%	14.8%	0.0%
Agent S	GPT-4o	0.0%	13.3%	45.8%	29.2%	19.1%	22.2%	22.2%	0.0%
Operator	computer-use	7%	26.7%	29.2%	29.2%	28.6%	8.3%	22.2%	4.5%
UFO²-base	GPT-4o	2.3%	36.7%	29.2%	41.7%	33.3%	0.0%	22.2%	9.1%
UFO²-base	o1	2.3%	30.0%	37.5%	50.0%	33.3%	8.3%	22.2%	9.1%
UFO²	GPT-4o	4.7%	30.0%	41.7%	58.3%	33.3%	8.3%	44.4%	9.1%
UFO²	o1	4.7%	40.0%	45.8%	50.0%	38.1%	16.7%	51.9%	9.1%

6.3 混合控制检测评估

如图19所示，相当大比例的失败源于控制检测失败，其中非标准UI元素不符合UIA指南。为了量化不同检测策略的有效性，我们比较了仅UIA、仅OmniParser-v2和我们的混合方法（第3.4节）。我们引入控制恢复率（CRR）来衡量在OmniParser或混合方法下有多少仅UIA失败被“恢复”（即变为成功完成）。

表3呈现了两个基准上多个模型配置的结果。混合方法始终优于仅UIA或仅OmniParser设置，提高了整体成功率，并将高达9.86%的先前不可恢复案例转化为完成。这一增益突出了两个检测流水线的互补优势，因为混合方法弥合了UIA的覆盖差距，同时避免了OmniParser在更标准化GUI中的局限性。

在图20中，我们报告了混合方法下从每个来源（UIA、OmniParser-v2和合并集）检测到的平均控件数量。由于应用程序覆盖的差异，检测到的控件总数在OSWorld-W中通常高于WAA。值得注意的是，UIA和OmniParser-v2都识别出大量控件子集，合并后，27.9%和56.7%的OmniParser-v2检测因与UIA重叠而被丢弃。这些观察表明，OmniParser-v2通过恢复非标准或自定义元素为UIA提供了有价值的补充。同时，合并步骤消除了冗余并防止重复计数，最终减少了混合方案中的控制检测失败。

表3. 不同控制检测机制下SR和CRR的比较。

控制检测器	模型	WAA SR	WAA CRR	OSWorld-W SR	OSWorld-W CRR
UIA	GPT-4o	23.4%	-	22.4%	-
OmniParser-v2	GPT-4o	26.6%	7.0%	14.3%	0%
Hybrid	GPT-4o	26.6%	9.9%	22.4%	12.5%
UIA	o1	25.3%	-	24.5%	-
OmniParser-v2	o1	20.8%	7.0%	14.3%	0%
Hybrid	o1	27.9%	9.9%	28.6%	25.0%

图20. 不同方法检测到的控件数量。

6.4 GUI + API集成有效性

我们现在评估在Puppeteer中统一基于API的动作与标准GUI交互如何影响性能（第3.5节）。为此，我们聚焦于OSWorld中27个办公相关任务，并手动为Word、Excel和PowerPoint开发了12个API。这些应用程序提供COM接口，便于创建自定义函数，使其成为更深OS和应用程序级集成的理想范例。重要的是，许多这些操作需要繁琐的多步骤GUI程序，但通过这些API变成简单的单次调用（如选择段落）。表4详细列出了实现的API。

表4. Office应用程序支持的API。

API	应用程序	描述
select_text	Word	选择文档中匹配的文本
select_paragraph	Word	选择文档中的段落
set_font	Word	设置所选文本的字体大小和样式
save_as	Word	将当前文档保存为所需格式
insert_excel_table	Excel	在所需位置插入表格
select_table_range	Excel	选择表格内的范围
reorder_column	Excel	重新排列表格列
save_as	Excel	将当前工作表保存为所需格式
set_background_color	PowerPoint	设置幻灯片的背景颜色
save_as	PowerPoint	将当前演示文稿保存为所需格式

表5比较了两种配置的（i）整体成功率（SR）、（ii）规划错误恢复率（PRR）、（iii）执行错误恢复率（ERR）、（iv）控制检测失败恢复率（CRR）和（v）平均完成步骤（ACS）：仅GUI与GUI + API。我们在两种配置都成功完成的子集上计算ACS，确保公平比较。

结果表明，集成API动作提升了两者的SR（GPT-4o +6.1%，o1 +8.2%），强调了混合GUI和API交互的有效性。值得注意的是，GPT-4o从API中获益最多的是从控制检测失败中恢复，通过绕过未标注的GUI元素。相反，o1更频繁地通过API“捷径”解决规划错误，反映了该模型更强的推理能力和对简洁解决方案的偏好。

表5. 仅GUI与GUI + API动作的性能比较。

动作	模型	SR	PRR	ERR	CRR	ACS
GUI-only	GPT-4o	16.3%	-	-	-	13.8
GUI+API	GPT-4o	22.4%	5.9%	14.3%	25.0%	12.9
GUI-only	o1	16.3%	-	-	-	16.0
GUI+API	o1	24.5%	17.7%	0.0%	12.5%	6.6

除了更高的成功率，GUI + API还减少了完成任务所需的努力。UFO²在相同任务上使用GPT-4o实现了6.5%的步骤节省，o1则实现了令人印象深刻的58.5%减少。后者的改进源于o1战略性调用API函数的能力，绕过了多个基于GUI的步骤。总体而言，这些发现证实了混合GUI自动化和API调用的优势，无论是在稳健性还是效率方面，并展示了深度系统集成对桌面自动化的重要性。

案例研究。 为了说明GUI + API方法如何简化任务执行，图21展示了在OSWorld-W案例中将Excel文件导出为CSV格式的完成轨迹，使用仅GUI或GUI + API交互。虽然两种配置最终都成功，但仅GUI设置需要五个步骤来打开保存对话框、选择文件格式并确认操作。相反，对save_as API的单次调用立即完成任务。除了提高效率，这种单步解决方案还减少了多个GUI交互中复合错误的风险——清楚地展示了更深OS和应用程序级集成的优势。

6.5 持续知识集成评估

接下来我们评估持续知识集成（第3.6节）对UFO²性能的影响。具体而言，我们用外部文档和执行衍生见解增强UFO²，以动态改进其领域理解而无需重新训练。我们创建了34个针对基准任务定制的帮助文档，每个包含精确的分步说明，使UFO²能够在运行时检索最相关的指导（每个任务最多一个）。此外，我们实现了一个自动化流水线，总结成功的执行轨迹——由我们的任务评估器验证——并归档到可检索的知识数据库中。对于后续任务，UFO²动态检索最多三个相关过去执行日志以指导任务规划和执行。鉴于知识集成主要解决由规划不足引起的失败（规划错误），我们采用规划恢复率（PRR）来衡量通过集成新知识成功解决的先前失败规划案例的比例。

表6. 有和没有知识集成的性能比较。

知识增强	模型	WAA SR	WAA PRR	OSWorld-W SR	OSWorld-W PRR
None	GPT-4o	23.4%	-	22.4%	-
Help Document	GPT-4o	26.6%	10.34%	26.5%	11.8%
Self-Experience	GPT-4o	26.6%	13.79%	24.5%	11.8%
None	o1	25.3%	-	24.5%	-
Help Document	o1	27.9%	3.5%	28.5%	17.7%
Self-Experience	o1	20.8%	13.79%	26.5%	17.7%

表6比较了两个基准上的整体SR和PRR，突出了归因于知识集成的显著性能改进。实时帮助文档检索和自我经验总结都产生了明显的增益，将规划失败减少高达17.7%。值得注意的是，使用更强模型（o1）的自我经验增强在两个基准上实现了持续改进，强调了利用先前成功进行自适应改进的有效性。虽然帮助文档偶尔产生适度增益，但其有效性取决于任务复杂性和文档特异性。

这些发现强调了系统化知识集成的价值，证明代理知识库的持续增强可以显著提高其在真实世界部署中的稳健性、可扩展性和适应性。此外，随着UFO²随时间继续积累执行经验和文档，它本质上朝着更高可靠性和改进的自主性演进，为桌面自动化的持续增强指明了清晰路径。

6.6 推测性多动作执行有效性

接下来我们评估推测性多动作执行（第3.7节）如何影响任务完成率和效率。表7比较了UFO²的两种模式：每次推理生成和执行一个动作（单动作）与在一步中推断多个连续动作（推测性多动作）。为确保公平比较，我们仅在两种模式都成功完成的子集上计算平均完成步骤（ACS）。

结果表明，推测性多动作执行保持与单动作模式相当的成功率（SR），同时显著减少平均步骤——在WAA上高达10%，在OSWorld-W上令人印象深刻地减少51.5%。由于每个步骤需要LLM调用，减少步骤数量显著降低了延迟和成本。这一发现证实了推测性多动作规划在不影响可靠性的情况下提高了效率，进一步突显了UFO²在实际桌面自动化中优化资源利用的能力。

表7. 单动作与推测性多动作模式的SR和ACS比较。

动作执行	模型	WAA SR	WAA ACS	OSWorld-W SR	OSWorld-W ACS	OSWorld-W Success Subset
Single	GPT-4o	23.4%	10.00	30.22%	22.4%	13.30
Speculative	GPT-4o	23.4%	8.78	24.5%	7.40	-
Single	o1	25.3%	9.95	32.24%	24.5%	6.80
Speculative	o1	24.7%	8.85	26.5%	3.30	-

案例研究。 图22说明了推测性多动作执行在实践中的运作方式。当用户请求UFO²在Word文档中居中对齐标题时，步骤序列通常需要选择标题文本然后点击居中图标。这些动作顺序依赖但互不干扰。UFO²不是将每个动作视为单独的LLM推理，而是在单一步骤中预测两个动作，利用推测性多动作规划。因此，它仅用一次LLM调用就完成任务，显著提高了效率同时保持准确性。

图22. 成功的推测性多动作执行的案例研究。图23. Operator vs. UFO² + Operator在WAA和OSWorld-W上的比较。

6.7 Operator作为APPAGENT

为了展示“一切皆可为APPAGENT”能力（第5.3节），我们进行了一项实验，其中UFO²的HostAgent编排器仅使用Operator作为APPAGENT。换句话说，所有原生APPAGENT被禁用，让Operator通过标准UFO²消息协议接受子任务并通信。对Operator感知层的唯一调整是将其限制为所选应用程序窗口的截图，而非整个桌面。

图23显示UFO² + Operator比单独运行Operator获得更高的成功率，特别是在WAA上（26.0% vs. 20.8%）。我们将这些增益归因于三个关键因素。首先，HostAgent将复杂用户指令分解为更清晰的单应用程序子任务，减少歧义。其次，HostAgent消息包含额外的提示，改善Operator的决策。最后，将Operator的视图限制为单个活动应用程序窗口减少视觉噪声并简化控制检测。总之，这些结果强调了UFO²多代理设计的优势，同时展示了“一切皆可为APPAGENT”如何提升现有CUA的性能。

6.8 效率分析

为了全面理解UFO²的性能特征，我们进行了任务执行效率的详细分析，特别关注步骤数和延迟。

步骤数分析。 表8总结了HostAgent和APPAGENT在两个基准套件上执行的平均执行步骤数。报告的步骤是在所有模型配置中成功完成的任务上计算的，确保公平比较。出现了两个关键见解：

首先，完全集成的UFO²配置始终减少所需的平均步骤数，相比基线（UFO²-base），减少高达50%。这种实质性的效率增益展示了深度OS集成，特别是混合GUI-API动作编排和高级控制检测策略，如何显著简化执行路径。

其次，利用更强大的推理模型（如o1 vs GPT-4o）进一步减少步骤数，表明增强的推理能力使代理能够识别和利用更高效的动作序列。例如，更强的模型可以更好地利用直接API交互或避免不必要的中间GUI交互。这强调了稳健系统集成和高级LLM推理在最小化执行开销方面的互补作用。

表8. UFO2的步骤数统计。

代理	模型	WAA HostAgent	WAA AppAgent	WAA Total	WAA Success Subset	OSWorld-W HostAgent	OSWorld-W AppAgent	OSWorld-W Total	OSWorld-W Success Subset
UFO2-base	GPT-4o	2.21	8.11	10.32	31	1.80	10.80	12.60	7
UFO2	GPT-4o	2.32	7.89	10.21	2.80	7.20	10.00	-	-
UFO2-base	o1	2.14	7.00	9.14	34	2.50	8.83	11.33	8
UFO2	o1	2.00	4.05	6.05	2.00	3.50	5.50	-	-

延迟分解。 图24提供了UFO2中每执行步骤平均延迟的详细分解，分为五个关键阶段：（i）截图捕获，（ii）通过UIA API（和OmniParser-v2）的控制检测，（iii）提示准备，包括检索相关帮助文档和历史执行经验，（iv）LLM推理，以及（v）在目标应用程序上的动作执行。

在所有配置中，LLM推理阶段主导总延迟，平均每次推理约10秒。这一瓶颈突出了通过部署更小的专用模型或使用更强大的推理硬件来优化的明确机会——这些策略仍然可行但超出我们当前评估范围。

排除LLM推理开销，基线系统（UFO2-base）实现了高效的执行，平均每步约10秒。相反，完全集成的UFO2仅为其混合控制检测流水线增加约1秒每步，主要由于OmniParser-v2视觉解析。这种额外开销是有意的权衡，以适度的延迟成本显著增强GUI控制检测的稳健性和准确性。

总之，这些结果表明每个任务所需总步骤的大幅减少确保整体任务完成时间保持实用（约每分钟一个任务）。这些分析见解强化了UFO2的全面系统级集成平衡了延迟、准确性和效率，为真实世界桌面自动化提供了可扩展且高性能的解决方案。

图24. 单个执行步骤每阶段的平均时间成本。

6.9 模型消融

图25比较了UFO2和UFO2-base在四个大语言模型上的性能。GPT-4V和GPT-4o生成直接答案而不暴露显式CoT，而Gemini 2.0（Flash Thinking）和o1在产生最终输出之前内部嵌入推理步骤。总体而言，具有内置推理的模型通常实现更高的成功率（SR），突出了更具深思熟虑或CoT驱动过程在桌面自动化中的价值[52]。

图25. UFO2和UFO2-base在WAA和OSWorld-W上使用不同LLM的比较。

这一结果为CUA指明了一个有前景的方向：为桌面自动化任务微调高级推理模型。通过允许代理制定和细化多步骤计划——特别是与更深的OS级信号集成时——UFO2可以更可靠地处理复杂或模糊情况。随着基于LLM的推理继续成熟，我们期望从UFO2的模型无关设计中获得准确性和通用性的进一步增益。

7 讨论与未来工作

延迟与响应性。 UFO2目前在每个决策步骤调用LLM推理，产生通常从几秒到几十秒每动作的延迟。尽管有各种工程优化，包含多个顺序动作的复杂任务可能累积到1-2分钟的执行时间，这仍然可接受但仍不如熟练的人类表现。为了缓解用户感知的延迟，我们引入了画中画（PiP）界面，使UFO2能够在隔离的虚拟桌面中不引人注目地执行任务，从而在长时间自动化期间大幅减少用户不便。在未来工作中，我们旨在通过研究部署专门的轻量级大动作模型（LAM）[13]来进一步降低延迟，针对任务特定推理优化以提高响应性和可扩展性。

缩小与人类级性能的差距。 我们的全面评估表明，UFO2虽然稳健有效，但尚未在所有Windows应用程序中持续达到人类级性能。弥合这一差距将主要需要在两个关键维度上取得进展。首先，通过在广泛、多样化的GUI交互数据集上微调来增强基础视觉-语言模型，将显著提高代理在各种应用程序中的能力和泛化。其次，与OS级API、原生应用程序接口和全面、结构化文档来源的更紧密集成将深化上下文理解并增强执行可靠性。鉴于UFO2的模块化架构，这些增强可以增量采用，持续改进性能，朝着在多样化应用场景中达到人类等效熟练度迈进。

跨操作系统泛化。 虽然UFO²针对Windows OS，由于其广泛的市场采用（超过70%市场份额²），模块化、分层系统设计便于适配其他桌面平台，如Linux和macOS。核心方法——利用Windows UI Automation（UIA）等无障碍框架——在Linux（AT-SPI [53]）和macOS（Accessibility API [54]）上有直接对应物。因此，现有设计原则、代理分解策略和统一GUI-API编排模型自然泛化，实现快速的平台特定定制。探索跨平台部署将是未来工作的重要领域，可能为跨越多样操作环境的统一桌面自动化解决方案生态系统奠定基础。

8 相关工作

将LLM集成到OS中代表了一个增长但仍处于初期阶段的研究领域。在本节中，我们讨论与我们在基于多模态LLM的桌面自动化代理的系统级集成研究相交的先前工作。

8.1 计算机使用代理（CUA）

多模态LLM的最新进展显著加速了计算机使用代理（CUA）的发展，这些代理通过在OS级模拟GUI交互来自动化桌面工作流。早期开创性系统，如UFO [10]，利用多模态模型（如GPT-4V [20]）结合UIA API来解释图形界面并通过自然语言指令执行复杂任务。UFO特别引入了多代理架构，增强了CUA处理跨应用程序和长期工作流的可靠性和能力。

后续努力主要集中在改进底层多模态模型和扩展平台能力。例如，CogAgent [55]建立在视觉语言模型CogVLM [56]之上，专注于跨多个平台（PC、Web、Android）的GUI理解，代表了最早的专用多模态CUA之一。行业兴趣同样加速，Anthropic的Claude-3.5（Computer Use）[11]是一个完全依赖基于截图GUI交互的代理，OpenAI的Operator [12]通过先进的多模态推理显著提高了桌面自动化性能。

然而，这些现有CUA在很大程度上仍是原型演示，通常缺乏与OS和原生应用程序能力的深度集成。相反，我们在UFO²中的工作通过模块化AgentOS架构、深度OS和API集成、混合GUI检测和非破坏性执行模型直接解决了这些根本性系统级限制，弥合了概念性CUA和实用桌面自动化之间的差距。

8.2 用于操作系统的LLM

另一个有前景的研究方向涉及将LLM直接嵌入OS架构，旨在大幅增强自动化、适应性和可用性。Ge等人首先提出了概念框架AIOS [57]，将LLM置于OS设计的中心，以编排高层用户交互和自动化决策。在他们的愿景中，代理类似于OS应用程序，每个都暴露可通过自然语言访问的专门能力，有效地使用户能够直观地“编程”其OS。

在这一概念基础上，Mei等人[58]将AIOS实现为具体原型，将LLM交互和工具API封装在特权OS内核中。这种设计提供核心OS功能，如进程调度、内存管理、I/O处理和访问控制，利用LLM通过专用SDK简化代理开发。Rama等人[59]扩展了这一范式，通过基于AIOS的代理在传统OS环境中直接引入语义文件管理能力，进一步展示了实际系统级集成。

补充这些高层OS集成，AutoOS [60]应用LLM自动调整Linux中的内核级参数，通过自主探索和优化实现显著效率增益。这突出了LLM集成可以直接增强核心系统性能和管理的另一个维度。

总体而言，这些研究工作说明了新兴的范式转变，其中LLM成为操作系统的组成部分，实现强大的自动化、增强的用户交互和自适应系统行为。我们在UFO²中的工作将这一研究方向专门扩展到桌面自动化，提供深度集成、可扩展且实用的AgentOS，利用多模态LLM与稳健的OS级机制相结合。

9 结论

我们介绍了UFO²，一种实用的、OS集成的Windows桌面自动化AgentOS，将CUA从概念原型转变为稳健、面向用户的解决方案。与先前CUA不同，UFO2通过模块化、多代理架构利用深度系统级集成，该架构由集中式HostAgent和应用程序专用AppAgent组成。每个AppAgent无缝结合GUI交互与原生API，并持续集成应用程序特定知识，大幅提高可靠性和执行效率。UFO2可以在PiP虚拟桌面界面上运行，进一步增强可用性，实现并发用户-代理工作流而互不干扰。

我们在20多个真实Windows应用程序上的全面评估表明，UFO2在稳健性、准确性和可扩展性方面相比最先进的CUA取得了显著改进。值得注意的是，通过将我们的集成框架与稳健的OS级特性耦合，即使是较少专门化的基础模型（如GPT-4o）也超越了专门化的CUA如Operator。