Back to Index
智能体 (Agents) /

Computer Use Agents：让模型直接操作你的电脑

2025 末到 2026 年第一季度，Claude Computer Use、OpenAI Operator、Manus Desktop 接连进入生产可用状态。这一类 Agent 不调 API、不用 SDK，直接用截屏 + 鼠标键盘和真实软件交互。本文拆解它的工作原理、OSWorld benchmark 现状、三家产品差异，以及为什么它和传统 Tool Calling Agent 是两种不同物种。

14 min read Part of Agent · Ch. 17

Computer Use Agents：让模型直接操作你的电脑

flowchart LR
  A["Computer Use Agents"]
  A --> B["分类：智能体 (Agents)"]
  A --> C["关键词：Computer Use"]
  A --> D["关键词：GUI Agent"]
  A --> E["关键词：OSWorld"]
  A --> F["关键词：Manus"]

过去 Agent 调用工具的方式是「让 LLM 输出一个 JSON，后端按 JSON 调 API」。Computer Use Agent 把这件事掀了：它不调 API，它直接拿截屏看屏幕、用鼠标点按钮、在键盘上打字。听起来有点反人类——明明可以走 API，为什么要看像素？因为现实里，绝大多数软件根本没给 LLM 留 API。

延伸阅读：

这篇文章会讲什么

如果说 2024 年的 Agent 主战场是「让 LLM 学会调用工具」，那么 2025 末到 2026 第一季度，主战场已经悄悄换了：让 LLM 学会操作那些没给它工具的软件。

这不是一个微小的变化。三件事在这条线上同时发生：

  1. Anthropic Claude Computer Use 从 beta 走向 production-ready，并以 Cowork 形态包装成消费/企业产品；
  2. OpenAI Operator 在 2025 年初推出，2026 年成为 ChatGPT Pro 的标配能力；
  3. Manus Desktop 在 2026 年 3 月 16 日正式发布，把这条路线推向更广义的「通用代办」，并在 12 月被 Meta 收购，月活破 2200 万。

更重要的是：开源生态没有缺席。browser-use、OpenInterpreter、Anthropic's reference Computer Use 等项目让中等规模的团队也能自己做。

这篇文章想讲清楚四件事：

  • Computer Use Agent 到底是怎么工作的——不是黑魔法，是一个并不复杂但很考工程的循环
  • 为什么它和 Function Calling Agent 是两种不同物种
  • OSWorld 这类 benchmark 在测什么、最好成绩到哪了、距离人类还有多远
  • 三家旗舰产品（Manus / Claude Cowork / OpenAI Operator）各自的取舍、适用场景与坑

先说判断：Computer Use 不是 Function Calling 的升级，是另一条路

先看定义：Computer Use Agent 指的是用 多模态视觉理解 + 屏幕截图 + 鼠标键盘控制 来直接操作图形界面的 Agent，对它而言，目标软件是个「黑盒子」，唯一接口是像素和输入设备。

为什么说这是另一条路，而不是 Function Calling 的延伸？因为它们对「世界」的假设完全不同：

维度Function Calling AgentComputer Use Agent
输入结构化 JSON 接口、文档屏幕截图、像素
输出JSON 工具调用鼠标坐标 + 键盘事件
对软件的假设必须有 API/SDK任何能用人手操作的软件
失败时的反馈错误码、异常字符串屏幕变化、错误弹窗
可调用范围提前注册过的工具整台电脑
安全模型工具粒度授权几乎等于给它一台机器
速度通常 < 1s/步通常 3–10s/步（需截图 + 推理）

这是一个很不一样的世界。Function Calling Agent 像是一个外包给你写脚本的程序员；Computer Use Agent 像是你在 Zoom 上远程把鼠标交给一个实习生——他能干你能干的所有事，包括你不希望他干的。

我的观点：这条路线的爆发不是因为它技术上更优雅——它在很多方面笨拙得过分——而是因为它破解了一个长期僵局：LLM 调用工具一直被限制在「有 API 的软件」。但人类工作里大量价值在没有 API 的地方：内部 ERP、本地 PDF、Photoshop 时间线、各种私有 SaaS 后台。Computer Use 的诞生意义就在于：把 LLM 的可作用面，从有 API 的世界扩到了有界面的世界。

它是怎么工作的：一个并不神秘的循环

先看定义：Computer Use Agent 的核心循环是 截屏 → 看图 → 推理 → 输出动作 → 执行 → 再截屏，循环直到任务完成或超出预算。

可以画成下面这样：

                  ┌─────────────┐
                  │  目标 / 指令  │
                  └──────┬──────┘
                         ▼
                  ┌─────────────┐
       ┌─────────►│   截屏 (RGB) │
       │          └──────┬──────┘
       │                 ▼
       │          ┌─────────────┐
       │          │ 多模态 LLM   │  看图 + 任务 + 历史
       │          │  推理一下     │  → 输出动作
       │          └──────┬──────┘
       │                 ▼
       │          ┌─────────────┐
       │          │  动作执行     │  click(x,y) / type / scroll
       │          └──────┬──────┘
       │                 ▼
       │          ┌─────────────┐
       └──────────│   屏幕变化    │  (大概率)
                  └─────────────┘

听起来不复杂——确实不复杂。复杂在每一步里藏着的几个老大难问题：

问题 1：GUI Grounding（界面定位）

模型必须能从截图里准确判断「按钮在哪」「这个图标的实际坐标是 (478, 312) 还是 (482, 318)」。差几个像素就点空气。

这是 Computer Use 模型最难的部分。Anthropic 的 Computer Use 模型为此专门做了「screen coordinates」训练数据；OpenAI 的 CUA 论文里也明确把 GUI grounding 列为关键能力之一。在 OSWorld 这类 benchmark 上，多数模型挂掉的原因不是「不知道该做什么」，而是「知道但点不准」。

问题 2：界面变化的延迟与不确定性

人点一下按钮，可能立刻变化，也可能 3 秒后才出对话框，也可能压根没反应（loading 状态）。Agent 必须学会判断「再等一下」「重试」「改用另一种方式」之间的差别。这跟人和操作系统打交道的直觉很像，但写在代码里非常烦。

问题 3：历史压缩

每一步截屏都是几十 KB 到几 MB 的图。一次 30 步的任务塞进上下文就爆了。所以工程上要：

  • 定期把旧截屏压缩或丢弃；
  • 保留关键节点的截屏（比如错误对话框出现的那一帧）；
  • 用文字摘要替换大部分历史图像；
  • 必要时让模型自己决定「这一帧重要吗」。

问题 4：失败后怎么恢复

API 调用失败有错误码；GUI 操作失败往往只表现为「屏幕没变」。Agent 必须建立这种间接信号的判断能力。多数实现会维护一个轻量的「期望 vs 实际」对比，如果点了 5 步屏幕都没动，就触发 Reflection 重新规划。

问题 5：危险动作的控制

这是最严肃的问题，单独有一节。

OSWorld：现在到底能跑多准

先看定义：OSWorld 是 2024 年由香港大学等机构推出的 benchmark，包含 369 个真实电脑任务，覆盖 Ubuntu/Windows/macOS 上的浏览器、办公软件、IDE、文件管理器等多种场景，由实际可执行的脚本判定任务是否完成。

OSWorld 的设计很苦：所有任务都用真实虚拟机跑，最后通过自动化脚本检查文件状态、应用状态、屏幕状态来判定是否成功。这意味着模型不能靠「看起来像完成了」蒙混过关。

2026 年 4 月 16 日 OSWorld-Verified 站序

排名系统OSWorld-Verified说明
1Claude Mythos Preview（Anthropic, Project Glasswing, gated 50 家）79.6%4-07 发布；10T MoE，4M 上下文；首位
2Holo3-122B-A10B78.8%专门 GUI 模型
3Claude Opus 4.7（公开 API）78.0%4-16 发布；1M 上下文
5GPT-5.4（含原生 Computer Use 模式）75.0%3-05 发布；首次公开 API 超人类基线
—人类基线（普通办公文员限时）72.4%注意：这是 lower bound
—开源 baseline（browser-use / OpenInterpreter 等）30–55% 区间缩小很快但仍有距离
—Manus Desktop公开数据较少；强项在长 horizon 任务12 月被 Meta 收购后转向广告 / 工作流投放

注 1：top 4 都已超过人类基线（72.4），但站序从 GPT-5.4 一家独大变成 Anthropic 系两款 + Holo3 + GPT-5.4 四档并立。 注 2：不同子集（OSWorld 全集 vs Verified）、不同采样策略（pass@1 / pass@k）、是否允许多次尝试，都会让分数有较大差异。看 leaderboard 时务必读小字。 注 3：Claude Mythos 仅 50 家 enterprise 可访问，公开模型里 top 1 是 Claude Opus 4.7。

修订说明（2026-04-18）：本文一稿曾把 GPT-5.4 写成 OSWorld-Verified top 1 (~79.2%)。截至 2026-04-16 实际站序见上表。

几个值得看清的事实

  1. 「超过人类」要打折看：OSWorld-Verified 是过滤后的子集，模型在这上面超过人类 ≠ 在你日常工作上超过你。
  2. 进步是真实的：从 2024 年首发时 OSWorld 上多数模型 < 15%，到 2026 Q1 顶级模型逼近 80%，两年涨了 60+ 个点。这种斜率在 LLM benchmark 里都算快的。
  3. 失败模式集中在两类：GUI grounding 失误（点错位置）+ 长 horizon 规划（任务太长，到中段忘了目标或选错路径）。
  4. 不同操作系统差距很大：Linux 任务因为 GUI 一致性高、模型训练数据相对多，分数最好；macOS/Windows 上仍有明显落差。

实践启示

如果你要在产品里用 Computer Use Agent：

  • 别只看 OSWorld 总分。问自己「我的场景更接近哪类任务」。
  • 优先选你能复现的小型私有评测（5–20 个真实场景任务），结果比榜单数字更有指导价值。
  • 长任务 > 30 步时，别相信「单一 agent 一口气搞完」的承诺；通常需要 checkpoint + 人工介入。

三家旗舰产品对比

Manus Desktop（2026 年 3 月 16 日正式发布）

  • 定位：通用代办型 Agent，强项是长任务、多步研究、跨工具协作
  • 架构：内部用多模型组合（Claude + 微调 Qwen 等），不是单一模型
  • 特征界面：有一个 “Computer Window”，让你看到 Agent 当前屏幕，可以随时介入
  • 生态：2025 年 12 月被 Meta 收购，整合到 Meta 生态进行中；月活 > 2200 万
  • 国别背景：源自武汉创业公司 Butterfly Effect，是中国区第一个真正出圈到全球的 general agent 产品
  • 适合：竞品研究、把数据收集成报告、长流程办公自动化
  • 不适合：精度要求极高的图形操作（图像编辑像素级）、需要严格可解释性的合规场景
  • autonomy 评分：8/10（独立行动能力很强，但反过来更需要审慎托管）

Claude Cowork（基于 Anthropic Computer Use Tool）

  • 定位：工作伙伴形态，强项是本地文件操作、文档编辑、代码与文档的混合工作流
  • 底层：Claude Opus 4.6 / 4.7 + Computer Use Tool
  • 特征：跟 Anthropic 的 Projects、Artifacts 体系深度整合
  • 优点：GUI grounding 在三家里口碑最稳；长上下文能力（1M token beta）让它在「读完整个项目文档再行动」这件事上有优势
  • 缺点：跨网站操作能力相对弱于 Operator
  • easy-of-use 评分：8/10
  • 适合：本地文件夹组织、PDF 与文档批量处理、和 Claude Code 形成「写代码 + 操作机器」组合
  • 不适合：你完全不在 Anthropic 生态里、或者主战场在浏览器里跨多个 SaaS

OpenAI Operator

  • 定位：浏览器原生 Agent，强项是跨网站操作（订票、比价、表单填写）
  • 底层：基于 OpenAI 的 CUA（Computer-Using Agent）模型，深度整合 GPT-5.4
  • 公开成绩：OSWorld 38.1%（早期数字，已被超越）/ WebArena 58.1% / WebVoyager 87%
  • 特征：跑在云端隔离浏览器里（不动你本地机器），适合「让它代你去网上办事」
  • 优点：跨站点操作的稳定性是三家里最好的
  • 缺点：不操作本地机器，对本地文件、桌面应用无能为力
  • 适合：日常网页任务的自动化（订机酒、对比购物、批量信息收集）
  • 不适合：高敏感、需要本地数据的工作

一张快速对比表

维度Manus DesktopClaude CoworkOpenAI Operator
操作范围你的整台电脑你的整台电脑云端浏览器
强项任务长流程研究 / 多工具串联本地文件 / 文档 / 代码跨网站操作
失误风险中（autonomy 高）低（更保守）低（沙箱隔离）
本地数据访问高（直接看你的桌面）高不直接访问
适合的人重度生产力用户写作者 / 开发者频繁做线上事务的人
数据敏感场景慎用可控隔离最强

我的实践判断：这三家不是替代关系，是 场景互补。一个比较实用的组合：

  • OpenAI Operator 处理「让我别再自己订票」这类标准化网页流；
  • Claude Cowork 处理本地文件、文档、代码相关的工作；
  • Manus Desktop 留给「我有点想偷懒、给个目标让它跑」类型的开放任务，但严守审计和权限边界。

开源选项：当你不愿意把屏幕交给云

如果你在意隐私、合规、或者只是想自己玩一玩，开源选项已经能用了：

项目模式适合
browser-usePython 库，控制真实浏览器（Playwright）浏览器自动化、爬虫、表单填写
OpenInterpreter本地代码 + shell 执行偏向脚本式操作而不是 GUI
Anthropic 官方参考 Computer UseDocker 镜像 + Claude API想完全复现 Claude Cowork 的最小路径
agent-zero / OpenHands通用 Agent 框架，可挂 GUI 工具偏研究和定制化
Self-Operating ComputermacOS 桌面 GUI 自动化macOS 用户的实验场

注意：开源项目的成功率明显低于商业产品，主要差距在 GUI grounding（特别是 native macOS/Windows 应用）。如果你的目标是浏览器内任务，browser-use 已经能用得不错；如果是桌面 native 应用，落差仍很大。

安全模型：这里没有「我先试试再说」的余地

先看定义：Computer Use Agent 的最大风险，不是它「做错了一件事」，而是它「做对了一件你不想让它做的事」。

如果你只记一件事，记这个：给 Computer Use Agent 的权限，等于给一个不会承担法律后果的代理人。它可能：

  • 误删文件
  • 把敏感信息发到错误的对话窗口
  • 在错误的 SaaS 后台点了「确认付款」
  • 在你的密码管理器里复制粘贴凭据到 prompt 里
  • 触发不可逆的工作流（比如「批量发邮件」）

真实发生过的事故类型（综合社区报告）：

事故类型起因
把测试邮件发给真实客户名单Agent 没分清 staging vs prod
删除了未提交的本地代码Agent 把 git status 上的 untracked 当成了「需要清理」
把 API key 复制到对话框Agent 看到登录页要 token，从屏幕上某处复制了真实凭据
在错误的群里发了草稿内容Slack 多 workspace 切换时定位错
自动同意了一个有费用的订阅弹窗 UI 让 Agent 误判默认按钮

防御策略要分层来做：

1. 永远不要给 Agent 这些访问

  • 密码管理器主窗口
  • 银行 / 支付平台未启用二次确认的页面
  • 包含敏感配置的目录（~/.ssh, ~/.aws, .env）
  • 生产环境的 deploy 控制台
  • 公司内部任何可批量发送的群发工具

2. 用 OS / 容器层做硬隔离

  • macOS 上为 Agent 单独建一个用户账号；
  • 跑在虚拟机或专用 Docker 容器里（如 Anthropic 官方 reference 镜像）；
  • 限制网络访问范围（只允许必要的域名）；
  • 用 read-only mount 给它访问敏感目录。

3. 用人在回路的 Approval 控制不可逆操作

  • 任何写入数据库、发邮件、转账、付款类操作必须 approval；
  • 任何 rm、drop、delete 类语义的动作必须 approval；
  • 文件超过某个大小的删除必须 approval。

Hermes Agent、OpenAI Operator、Claude Cowork 都内置了不同形式的 approval 机制，别关掉它们。

4. 准备一个「回滚预案」

  • 重要文件夹定期 snapshot；
  • 邮件类账户开启 undo send；
  • 数据库类操作走有 transaction / soft delete 的接口。

5. 审计日志要留够细

  • 截屏可以保留关键节点（带 PII 的部分要 mask）；
  • 每个工具调用 + 参数 + 结果都要落日志；
  • 任何 approval 决策都要可追溯。

与 Function Calling Agent 的混合架构

实际工程里，很少有人会用纯 Computer Use Agent 跑所有事。更现实的架构是混合：

                ┌────────────────┐
                │   规划层 LLM    │
                └──────┬─────────┘
                       │
         ┌─────────────┼─────────────┐
         ▼             ▼             ▼
   ┌─────────┐   ┌─────────┐   ┌────────────┐
   │ Function│   │  MCP    │   │ Computer   │
   │ Calling │   │  Tool   │   │   Use      │
   └────┬────┘   └────┬────┘   └─────┬──────┘
        │             │              │
   有 API 的事     有标准化     最后才动到
   优先走这条        协议的       「用界面」
                                这条路

设计原则：

  1. 能用 API 的事别走截屏：API 又快又准，省钱省事
  2. MCP 能解决的别自己写 GUI 自动化：MCP 在 2025 后已经有大量现成 server
  3. 只有当目标系统真的没接口时，才上 Computer Use：这条路是兜底，不是首选

这种分层会带来明显的成本和稳定性收益：

  • Function Call 一次几毫秒到几百毫秒；
  • MCP 调用通常一次几百毫秒；
  • 截屏 + 多模态推理 + 鼠标动作一步通常 3–10 秒。

差距是 10–100 倍。能不走 GUI 就别走。

它会让哪些岗位先有变化

我尽量克制地说几个比较有把握的判断：

  • 重复的网页操作工作（比如 ops、客服 backoffice）：1–2 年内显著被替代
  • 数据收集与简单整理（实习生级别）：已经在被替代
  • 跨多个 SaaS 后台的运营事务：替代速度最快
  • 本地文件管理 / 整理工作：会被显著加速，但人类仍是最后审核
  • 创意性桌面工作（Photoshop / 视频剪辑）：短期内 Agent 还做不好，主要卡在精细操作和审美判断

不会被替代但会被改写的部分：

  • 审核 / 决策：你不会消失，但你的输入会从「自己点鼠标」变成「审 Agent 已经做的事」
  • 架构设计：Agent 越普及，规则、权限、流程编排反而越重要
  • 危机处理：当 Agent 出事，能从屏幕日志里复盘问题的人，价值会上升

一个常见误解的纠正

误解：Computer Use 出来后，Function Calling 和 MCP 就过时了。

真相：恰恰相反。Computer Use 的存在让「应该被 API 化的工作」反而更值得 API 化——因为现在你能客观比较「我让模型用 API 做」vs「我让模型用屏幕做」的成本和准确率，差距通常巨大。

更具体的说法是：

  • Computer Use 扩大了 Agent 的可作用面
  • 但只要你能给一个动作开发出可靠 API/MCP server，就应该这么做
  • Computer Use 更像兜底层，不是默认层

这种关系类似 RAG 和 fine-tuning：不是替代，是分工。

给不同角色的建议

个人用户

  • 从 OpenAI Operator 或 Claude Cowork 的成熟功能开始，先建立信任
  • 第一个月只用它做「你能轻松回滚」的事（比如整理文件、做研究、订机酒）
  • 不要在第一周就让它操作生产环境

创业团队

  • 别全栈自研 Computer Use 模型——这是 OpenAI / Anthropic / Google 在烧钱的赛道
  • 优先用现成 API（Anthropic Computer Use Tool / OpenAI CUA）做产品差异化
  • 你的护城河在领域 prompt + workflow 编排 + 审计，不在底层模型

企业平台

  • 不要把 Computer Use 直接开给业务部门——治理 / 审计跟不上
  • 用作内部「flow 自动化中台」的能力，包装成有 approval、有审计、有权限边界的服务
  • 优先在隔离 VM 中跑，不要跑在员工的真实工作机上

研究方向

  • GUI Grounding 仍是 bottleneck，专门做小模型 + 高 grounding 准确率有空间
  • 跨平台 generalization（Win/macOS/Linux）距离工业级还有差距
  • Long-horizon planning + memory + reflection 在 GUI 任务上是新的研究坐标
  • 评测：OSWorld 是好起点但已经有过拟合趋势，需要新一代 benchmark

一句话收束

Function Calling 让 LLM 能调用工具，Computer Use 让 LLM 能使用任何软件。前者扩大了能力，后者扩大了边界——而边界扩大带来的，是同样规模的能力红利和同样规模的安全责任。