8 个能控制电脑的开源 AI Agent 项目对比

AI 控制电脑并不是让大模型“拥有操作系统权限”这么简单。真正可用的方案通常由四部分组成：任务理解、屏幕或系统状态感知、动作执行、反馈校正。

用户说一句“把文件夹里的图片转成 JPG 并按日期重命名”，智能体需要先拆任务，再决定是写脚本、点界面、调用系统接口，还是打开软件一步步操作。执行之后，它还要检查结果是否符合预期，不对就重新规划。

一个典型的电脑控制 Agent 流程可以抽象成这样：

flowchart TD
    A[自然语言任务] --> B[大模型理解任务]
    B --> C[任务规划与拆解]
    C --> D{选择控制方式}

    D --> E[终端执行代码<br/>Python / JavaScript / Shell]
    D --> F[截图识别 GUI<br/>OCR / 坐标 / 鼠标键盘]
    D --> G[调用系统接口<br/>UI Automation / Win32 / COM]
    D --> H[端到端视觉动作模型<br/>截图输入 / 动作输出]

    E --> I[执行操作]
    F --> I
    G --> I
    H --> I

    I --> J[获得新状态<br/>日志 / 文件 / 截图 / 控件树]
    J --> K[反思与记忆]
    K --> C

这些开源项目虽然都可以归到“AI 控制电脑”这一类，但技术路线差别很大。终端型项目更像会写代码的本地助理，GUI 智能体更像会看屏幕、会点鼠标的操作员，系统原生方案则会直接读取操作系统暴露出来的控件信息。

几类技术路线怎么区分

GUI（图形用户界面）控制的难点不只是“点哪里”。一个按钮在截图里可能只占几十个像素，弹窗可能挡住原来的内容，滚动条位置会改变坐标，应用版本变化也会导致布局不同。因此，更成熟的项目通常不会只做一次截图识别，而是会加入规划、反馈、记忆和失败重试机制。

1. Open Interpreter：把终端变成本地代码执行助理

Open Interpreter 是一个本地代码解释器型 AI Agent。它的核心能力不是“看屏幕点按钮”，而是让大模型在本地终端里生成并执行代码，支持 Python、JavaScript、Shell 等常见执行环境。

适合它的任务通常具有明显的“可编程”特征：

• 批量重命名文件；
• 转换图片、视频、文档格式；
• 处理 Excel、CSV、JSON 等数据文件；
• 调用命令行工具完成系统配置；
• 写脚本抓取网页或整理资料；
• 连接本地模型，例如 Ollama、Jan 等。

它的运行方式可以理解成：

sequenceDiagram
    participant U as 用户
    participant L as 大模型
    participant I as Open Interpreter
    participant OS as 本地系统

    U->>I: 输入任务
    I->>L: 请求生成执行计划和代码
    L-->>I: 返回代码或命令
    I->>U: 请求确认执行
    U-->>I: 同意或修改
    I->>OS: 执行 Python / Shell / JS
    OS-->>I: 返回输出、文件变化或错误
    I->>L: 反馈执行结果
    L-->>I: 继续修正或完成任务

例如，用户输入：

把 Downloads 目录里所有 PNG 图片转换成 JPG，并把文件名改成创建日期加序号。

Open Interpreter 可能会生成 Python 脚本，读取文件元数据、调用 Pillow 转换格式，再按规则重命名。相比让 GUI Agent 打开文件管理器逐个操作，这种任务用代码完成更快，也更容易复现。

开源地址：

https://github.com/OpenInterpreter/open-interpreter

使用时要特别注意执行权限。因为它可以运行 Shell 命令、访问文件系统和联网，最好让它在单独目录、虚拟机或受限账户里工作，并开启命令确认机制。不要直接让它在重要目录里执行批量删除、移动、覆盖文件的操作。

2. Self-Operating Computer：用截图和标记让 AI 操作桌面

Self-Operating Computer 走的是“像人一样看屏幕，再用鼠标键盘操作”的路线。它不要求目标软件提供 API（应用程序编程接口），而是通过截图理解界面，然后决定点击哪里、输入什么、按哪个快捷键。

它的关键设计有三点。

OCR 坐标映射

OCR（光学字符识别）会识别屏幕上的文字，并把文字区域映射成可点击坐标。这样模型不需要凭空猜测按钮位置，而是可以说“点击包含某段文字的区域”。

简化后的流程如下：

flowchart LR
    A[屏幕截图] --> B[OCR 识别文字]
    B --> C[生成文字与坐标映射]
    C --> D[大模型选择目标文字]
    D --> E[转换成点击坐标]
    E --> F[鼠标点击]

Set-of-Mark 标记

Set-of-Mark（标记集合）会在截图中的按钮、输入框、菜单项等 UI 元素上打数字标签。大模型只需要输出标签编号，系统再把编号转换成真实坐标。

这种方式可以减少“模型描述位置不准确”的问题。例如界面上有多个“确定”按钮时，数字标签比自然语言描述更明确。

flowchart TD
    A[原始界面截图] --> B[识别可交互元素]
    B --> C[给元素打数字标签]
    C --> D[把带标签截图发给模型]
    D --> E[模型输出标签编号]
    E --> F[执行点击或输入]

Voice Mode

Voice Mode 支持语音输入任务。它主要提升交互便利性，本质上仍然是把语音转成文本，再进入截图识别和动作执行流程。

开源地址：

https://github.com/OthersideAI/self-operating-computer

这类项目适合处理轻量桌面操作，例如打开网页、填写简单表单、切换设置项。对于复杂专业软件、连续动态画面、强依赖拖拽精度的场景，稳定性会受到屏幕分辨率、缩放比例、界面主题和应用版本影响。

3. Agent S：带记忆和规划能力的 GUI 智能体框架

Agent S 是更偏研究和框架化的 GUI Agent。它关注的不只是“下一步点哪里”，而是怎样让智能体处理长任务、积累经验，并在复杂界面里分层规划。

Agent S 的 S3 在 OSWorld 上取得过 72.60% 的得分。OSWorld 是一个面向操作系统任务的评测环境，用来衡量智能体在真实桌面环境中完成任务的能力。

它的核心设计可以拆成三部分。

经验增强的层次化规划

复杂任务不能只靠一步一步猜。例如“整理一份演示文稿并发送给某个人”，里面可能包含查资料、编辑文件、打开邮件客户端、添加附件、确认收件人等多个子任务。

Agent S 会把大任务拆成层级结构，并结合外部知识和内部记忆来规划操作：

flowchart TD
    A[复杂任务] --> B[检索外部知识<br/>教程 / 文档 / 网页]
    A --> C[检索内部记忆<br/>历史成功经验]
    B --> D[生成高层计划]
    C --> D
    D --> E[拆成子任务]
    E --> F[执行 GUI 操作]
    F --> G{是否成功}
    G -- 否 --> H[分析失败原因]
    H --> D
    G -- 是 --> I[写入经验记忆]

Agent-计算机接口

普通截图只能提供像素信息。Agent-计算机接口会在模型和电脑之间增加中间层，让模型更准确地理解 GUI 元素，例如按钮、输入框、菜单、窗口层级等。

这样做的价值在于减少纯视觉方案的不确定性。模型不再只看“某个区域像按钮”，而是可以获得更结构化的界面信息。

双重记忆机制

Agent S 使用两类记忆：

开源地址：

https://github.com/simular-ai/Agent-S

Agent S 更适合研究 GUI Agent、构建复杂任务系统，或者做操作系统智能体能力评测。它不是那种装完就只执行单一快捷任务的小工具，使用前需要理解框架结构和任务环境配置。

4. UFO：微软面向 Windows 生态的原生级智能体

UFO 是微软开源的 Windows 智能体框架。它和普通截图点击方案最大的区别是：不只看屏幕，还会利用 Windows 原生接口读取应用程序结构。

它结合了几类能力：

• 视觉识别：理解屏幕上呈现的内容；
• Windows UI Automation：读取窗口、按钮、输入框等控件信息；
• Win32：访问 Windows 底层窗口和消息机制；
• COM（组件对象模型）：和 Office 等 Windows 应用进行更深层交互。

普通视觉 Agent 看到的是一张图片，UFO 能进一步拿到控件树。控件树里包含按钮名称、控件类型、可用状态、层级关系等信息，这比单纯靠截图判断可靠得多。

flowchart LR
    A[用户任务] --> B[UFO 规划]
    B --> C[视觉理解]
    B --> D[Windows UI Automation]
    B --> E[Win32 / COM API]
    C --> F[界面状态]
    D --> F
    E --> F
    F --> G[选择应用和控件]
    G --> H[执行跨应用操作]

UFO 采用双代理架构：

它特别适合 Windows 常见软件场景，例如 Office、文件资源管理器、邮件客户端之间的协同任务。比如“从 PPT 中提取某些内容，整理后通过邮件发送”，这种任务需要跨应用读取、编辑、复制和发送，单纯截图点击会更容易出错，而原生接口能提供更稳定的控件定位。

开源地址：

https://github.com/microsoft/UFO

UFO 的边界也很清楚：它主要服务 Windows 生态。如果目标是 macOS、Linux，或者游戏、图形设计软件这类不标准暴露控件树的应用，通用截图方案或端到端视觉动作模型可能更合适。

5. Cradle：面向软件和游戏的通用控制框架

Cradle 由智源研究院 BAAI 团队开发，目标是让 AI 智能体仅通过屏幕截图和标准输入输出接口操作软件和游戏。它不要求访问后端 API，也不依赖目标程序内部代码。

这种设计很适合游戏和复杂图形软件。游戏通常没有可供智能体调用的业务 API，界面元素也不一定是标准按钮。智能体只能像玩家一样观察画面，再通过键盘鼠标行动。

Cradle 的控制流程可以拆成五个模块：

flowchart TD
    A[屏幕截图] --> B[感知模块]
    B --> C[识别 UI / 图标 / 文本 / 3D 场景]
    C --> D[决策与规划]
    D --> E[执行键盘鼠标动作]
    E --> F[新的屏幕状态]
    F --> G{任务是否推进}
    G -- 是 --> H[更新短期记忆]
    G -- 否 --> I[自我反思并修正策略]
    I --> D
    H --> J[长期记忆 / RAG 知识]
    J --> D

其中 RAG（检索增强生成）用于把工具手册、成功经验、操作说明等资料存入长期记忆。遇到类似任务时，智能体可以检索过去的经验，而不是每次都从零开始探索。

它的记忆系统分为两类：

Cradle 的应用范围不只限于游戏，也可以用于飞书、Chrome、剪映等常见软件。对于《荒野大镖客》或《城市：天际线》这类画面复杂、状态变化连续的任务，感知和反思模块比简单点击脚本更重要。

开源地址：

https://github.com/BAAI-Agents/Cradle

使用这类框架时，要接受一个现实：游戏和图形软件的状态空间很大，任务成功率会受到画面变化、镜头角度、按键延迟、帧率等因素影响。它更适合探索通用智能体能力，而不是替代稳定的业务自动化脚本。

6. OS-Copilot：强调自我学习的操作系统代理框架

OS-Copilot 的目标是构建通用操作系统代理，让智能体能处理没见过的应用，并通过自我学习逐渐改进操作能力。

它的核心 Agent 叫 FRIDAY，关注点包括：

• 学习如何操作 Excel、PPT、浏览器等常用软件；
• 在任务执行失败时分析原因；
• 把成功经验沉淀成可复用能力；
• 逐步扩展到更多未知应用。

可以把它理解成一个更注重“持续学习”的桌面 Agent 框架。一次操作失败并不只是返回错误，而是会进入自我改进流程。

flowchart TD
    A[新任务] --> B[尝试规划]
    B --> C[执行桌面操作]
    C --> D{结果是否符合目标}
    D -- 是 --> E[保存技能和经验]
    D -- 否 --> F[分析失败原因]
    F --> G[调整计划或学习新技能]
    G --> C
    E --> H[后续任务复用]

开源地址：

https://github.com/OS-Copilot/OS-Copilot

OS-Copilot 适合用来研究“个人操作系统助理”该怎么构建，尤其是自我学习、自我修正、跨应用技能沉淀这些能力。对于只想完成单次固定流程的任务，传统 RPA（机器人流程自动化）或脚本可能更直接。

7. ShowUI：轻量级端到端视觉-语言-动作模型

ShowUI 是一个面向 GUI 智能体的轻量级 VLA 模型。VLA 指 Vision-Language-Action，也就是把视觉输入、语言指令和动作输出放到一个模型流程里。

传统 GUI Agent 往往会经历多步处理：

flowchart LR
    A[截图] --> B[OCR / 元素检测]
    B --> C[生成结构化界面描述]
    C --> D[大模型推理]
    D --> E[动作解析]
    E --> F[点击或输入]

ShowUI 更强调端到端：

flowchart LR
    A[截图 + 语言指令] --> B[VLA 模型]
    B --> C[动作输出<br/>点击 / 输入 / 滚动]

这样做的目标是降低延迟和计算成本。对于本地部署场景，如果每一步都要调用大型语言模型、OCR 模型和额外的解析模块，响应会变慢；轻量级模型可以让 UI 自动化更接近实时交互。

开源地址：

https://github.com/showlab/ShowUI

ShowUI 更适合需要低延迟屏幕元素定位和操作的场景，例如本地 GUI 自动化、交互式助手、轻量桌面控制。它的能力上限取决于模型训练数据和泛化能力，遇到很复杂的长任务时，通常还需要外部规划器、记忆模块或任务管理框架配合。

8. UI-TARS Desktop：基于视觉语言模型的桌面控制应用

UI-TARS Desktop 是字节跳动开源的 GUI 智能体桌面应用，基于 UI-TARS 视觉语言模型，可以通过自然语言控制 Windows 或 macOS 电脑。

它的定位更偏“可直接使用的桌面应用”，而不是只提供底层模型或研究框架。用户输入任务后，系统会看屏幕、理解界面，再控制鼠标和键盘完成操作。

它的链路可以简化成：

sequenceDiagram
    participant U as 用户
    participant A as UI-TARS Desktop
    participant M as UI-TARS 模型
    participant PC as Windows / macOS

    U->>A: 输入自然语言任务
    A->>PC: 获取屏幕截图
    A->>M: 提交截图和任务
    M-->>A: 返回下一步动作
    A->>PC: 执行鼠标键盘操作
    PC-->>A: 返回新截图
    A->>M: 继续判断任务状态

它的特点包括：

• 支持通过自然语言直接控制桌面；
• 面向 Windows 和 macOS；
• 基于端到端视觉模型，不强依赖复杂的中间代码解析；
• 支持远程计算机控制；
• 上手门槛比纯框架型项目低。

开源地址：

https://github.com/bytedance/UI-TARS-desktop

UI-TARS Desktop 适合希望快速体验 GUI Agent 的用户。它不需要像研究框架那样先搭一整套评测环境，但因为它会真实控制鼠标键盘，仍然要避免让它操作敏感账户、生产系统或不可恢复的数据。

选型：不同任务该用哪类项目

从工程角度看，能写脚本解决的问题，不一定要交给 GUI Agent。脚本的可控性和可审计性更好。GUI Agent 的价值在于处理那些没有 API、难以脚本化、需要跨应用操作的场景。

上手前要建立安全边界

能控制电脑的 AI Agent 都有一个共同风险：它们会把模型输出转化成真实操作。错误输出不再只是回答错了，而可能变成误删文件、误发邮件、修改系统设置、泄露截图内容。

更稳妥的做法是给它们划定边界。

一个相对安全的试用流程可以这样安排：

# 1. 创建单独工作目录
mkdir ai-agent-sandbox
cd ai-agent-sandbox

# 2. 克隆需要测试的项目
git clone https://github.com/OpenInterpreter/open-interpreter
git clone https://github.com/OthersideAI/self-operating-computer
git clone https://github.com/simular-ai/Agent-S
git clone https://github.com/microsoft/UFO
git clone https://github.com/BAAI-Agents/Cradle
git clone https://github.com/OS-Copilot/OS-Copilot
git clone https://github.com/showlab/ShowUI
git clone https://github.com/bytedance/UI-TARS-desktop

真正运行之前，再按各项目的 README 配置模型、依赖、系统权限和环境变量。不要一开始就让 Agent 接管主力工作环境，可以先设计几个低风险任务：

1. 打开浏览器并搜索一个公开网页
2. 在测试目录里创建一个文本文件
3. 把几张测试图片改名
4. 打开计算器完成简单计算
5. 在空白文档里输入一段指定文字

任务越简单，越容易观察它的感知、规划和执行是否可靠。确认基础能力稳定后，再逐步增加跨应用、多步骤、带文件读写的任务。

几个常见坑

1. GUI Agent 对界面变化很敏感

截图驱动方案容易受分辨率、缩放比例、主题、语言、窗口大小影响。一个按钮在 100% 缩放下能点准，换成 150% 缩放后坐标可能就偏了。

2. OCR 不是万能的

OCR 能识别文字，但对图标按钮、低对比度文字、复杂背景、游戏画面里的装饰字体并不稳定。Set-of-Mark 标记可以缓解定位问题，但不能完全解决语义理解问题。

3. 原生接口更稳，但平台绑定更强

UFO 这类利用 Windows 原生接口的项目，在标准 Windows 应用里更可靠；代价是跨平台能力弱，遇到不暴露标准控件的应用时也可能退回视觉方案。

4. 端到端模型链路短，但调试不如模块化方案直观

ShowUI、UI-TARS 这类 VLA 路线减少了中间步骤，响应可以更快。不过模型直接输出动作时，开发者不一定能清楚看到它为什么判断要点某个位置。需要可解释性和审计时，模块化方案更容易定位问题。

5. 终端型 Agent 权限风险最高

Open Interpreter 这类工具非常适合自动写脚本，但也最容易把错误指令变成真实系统操作。让它执行命令前，最好逐条检查生成的代码，尤其是涉及 rm、mv、chmod、注册表、系统设置、网络上传的操作。

最实用的选择方式

如果目标是提高日常效率，可以按任务类型选：

• 文件、数据、脚本处理：优先 Open Interpreter。
• 普通桌面软件操作：尝试 UI-TARS Desktop 或 Self-Operating Computer。
• Windows Office 自动化：优先看 UFO。
• 游戏、复杂图形软件、无 API 环境：看 Cradle。
• GUI Agent 研究和评测：Agent S、OS-Copilot 更合适。
• 本地低延迟视觉动作模型：ShowUI 更值得测试。

AI 控制电脑的关键不在于“能不能点鼠标”，而在于能不能稳定感知当前状态、把任务拆对、在失败时修正，并且在安全边界内执行。把这些项目放在同一张技术地图里看，选型会清楚很多：可编程任务交给代码解释器，Windows 深度控制交给原生接口，通用界面和游戏场景交给视觉 GUI Agent。