OSWorld 评测计算机使用 Agent：把"会不会操作电脑"量成硬指标

你的公司准备上线一个"能自己操作电脑"的智能体——自动填报销单、整理 Excel、批量改 PPT、在 CRM 里建工单。演示视频很漂亮，但你敢把它接进生产吗？ 同一款桌面 Agent，在 A 榜单 85 分、在 B 榜单 55 分，你信哪个？ 厂商说"我们 OSWorld 90%"，可这个数字里到底有多少是模型能力、多少是它自家 harness 的功劳？

这三个问题，就是计算机使用（computer-use）Agent 落地前最现实的一道坎。本文把 OSWorld 这个被几乎所有桌面 Agent 厂商当成"准考证"的评测体系讲透，并带你照着在三天内跑通一个最小评测闭环。

四要素卡（先拿结论）

读完你能做到什么：用 OSWorld-Verified 在自己的 Agent 上跑出一张跨域成功率表；读懂厂商"OSWorld 分数"里哪些是模型、哪些是 harness；用 OSWorld 2.0 的 partial-credit 思路给自家长时程任务设计 checkpoint 评分，而不是只盯一个"成/败"。

一、技术背景与问题定义

"计算机使用 Agent"是 2025–2026 年最热的一个落地方向：给模型一双"眼睛"（屏幕截图）和一双"手"（鼠标键盘），让它像人一样操作真实电脑。Claude Computer Use、OpenAI Operator、Google Project Mariner、Qwen-CUA、GPT-6 Astra 都是这个赛道的选手。但它也带来一个评测上的硬骨头：

现有做法卡在哪？

• 截图好看 ≠ 活干完。Agent 生成的步骤描述再标准，也可能点错按钮、漏存文件、改错单元格。文本层面的"像完成了"没有意义，必须确认最终状态真的变了。
• benchmark 碎片化。截至 2026 年，计算机使用 Agent 至少有 12+ 个互相不兼容的榜单（OSWorld、WebArena、ScreenSpot-Pro、Windows Agent Arena、AndroidWorld…），同一模型在不同榜单能差 30 分，84% 的组织因此"不会评、不敢买"。
• harness 优势被藏进分数。厂商报的"OSWorld 90%"通常是"模型 + 自家脚手架"的联合成绩，社区用同模型 + 开源脚手架往往低一大截。分数里有多少是模型、多少是 harness，不说清楚就是误导。

OSWorld 的核心主张：在真实操作系统（不是模拟网页、不是简化界面）里，用执行接地（execution-grounded）的验证脚本确认 Agent 是否真的到达目标状态，并给出可复现、可跨厂商比较的分数。它 2024 年由港大 XLANG Lab 等在 NeurIPS 提出，是第一个覆盖完整桌面 OS 的 Agent 评测基准；两年间从"最强 Agent 12%"涨到"通用模型 85%"，已经成为几乎所有桌面 Agent 发布稿里必引的"准考证"。2026 年 6 月推出的 OSWorld 2.0 进一步把战场拉到长时程工作流（108 个真实职业流程，中位人工 1.6 小时、平均 318 次工具调用），用 partial-credit 暴露"做一半就丢线"这个比 GUI 控制本身更致命的失败模式。

读者画像：算法/评测工程师（给自家 Agent 出分、做回归）、平台/Agent 负责人（采购选型、设发布闸门）、应用开发者（想把 RPA 升级成能看屏幕的智能体）。真实采用方：Anthropic、OpenAI、阿里 Qwen、Google、小米等所有桌面 Agent 厂商，以及把 OSWorld 当选型标尺的企业采购方——它本身就是"被全行业采用"的评测标准。

二、实现路径与步骤【重点：照着走完】

目标：三天内跑通"在自己机器上用 OSWorld 评测一个截图驱动 Agent"的最小闭环。

步骤 0：确认前置条件与选型

关键取舍：第一次跑不要碰全量 369 题（那要数百~数千美元 API + 大量 VM 运维）。先用 manual_examine.py 跑单任务验证链路通不通，再扩到单域（如 libreoffice_calc）几十题。

步骤 1：安装 OSWorld 与依赖

# 1) 克隆仓库git clone https://github.com/xlang-ai/OSWorldcd OSWorld# 2) 建环境（推荐 conda，避免污染本机）conda create -n osworld python=3.10 -yconda activate osworld# 3) 装依赖；只评测不碰任务集可只装核心包pip install -r requirements.txt# 等价的最小安装：pip install desktop-env# 4) Docker provider 前置检查（Linux 服务器）egrep -c '(vmx|svm)' /proc/cpuinfo   # 返回值 >0 即可用 KVMdocker --version

验证成功标志：pip show desktop-env 能查到版本；docker images 能看到 OSWorld 镜像（首次运行会自动拉取 Ubuntu 桌面镜像）。

步骤 2：接入你的 Agent（实现 Agent 接口）

OSWorld 的 Agent 接口很简单：给它"观察"（截图 + 可访问性树）和"指令"，它返回一个动作字典。照着 mm_agents/README.md 实现一个最小 Agent，例如一个"截图 → 调你自己的模型 → 输出坐标点击"的包装：

# mm_agents/my_agent.pyimport base64, requestsclassMyAgent:def__init__(self, model="your-model", base_url="http://127.0.0.1:8000/v1",                 api_key="dummy"):self.model, self.base_url, self.api_key = model, base_url, api_keydefpredict(self, instruction, obs, config=None):# obs 含 {'screenshot': base64_png, 'accessibility_tree': str, ...}        img = obs["screenshot"]# 把截图 + 任务发给你的模型（OpenAI 兼容 / vLLM / 厂商 API 均可）        resp = requests.post(f"{self.base_url}/chat/completions",            headers={"Authorization": f"Bearer {self.api_key}"},            json={"model": self.model, "messages": [                {"role": "system", "content": "你是电脑操作助手，输出下一次鼠标/键盘动作。"},                {"role": "user", "content": [                    {"type": "text", "text": instruction},                    {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{img}"}},                ]},            ], "max_tokens": 256},        )# 解析模型输出为 OSWorld 动作 schema（pyautogui 风格）        action = self._parse(resp.json()["choices"][0]["message"]["content"])return action   # e.g. {"action_type":"click","coords":[x,y],"action_inputs":{...}}def_parse(self, text):# 这里接你自己的动作解析（建议让模型直接吐 JSON）        ...

然后在 scripts/python/run_multienv.py 顶部把官方 agent 换成你的：

from mm_agents.my_agent import MyAgentagent = MyAgent(model="your-model", base_url=os.environ["OPENAI_BASE_URL"])

验证成功标志：manual_examine.py 对一个 libreoffice_calc 任务能跑出动作序列、Agent 在 VM 里真的动了鼠标。

步骤 3：跑评测（先单任务，再扩域）

# A) 单任务试水（最小闭环，零 GPU，几美元内）python scripts/python/manual_examine.py \    --headless \    --observation_type screenshot \    --provider_name docker \    --result_dir ./results_trial \    --domain libreoffice_calc \    --example_id a669ef01-ded5-4099-9ea9-25e99b569840 \    --max_steps 15 \    --client_password password# B) 单域并行跑（确认 API/VM 稳定后）python scripts/python/run_multienv.py \    --provider_name docker \    --headless \    --observation_type screenshot \    --model your-model \    --sleep_after_execution 3 \    --max_steps 15 \    --num_envs 10 \    --client_password password

参数取值理由：--max_steps 15 是单任务步数预算——OSWorld 1.0 任务人工几十步内可完成，15 步足够覆盖常规任务；--sleep_after_execution 3 给 GUI 留响应时间，太小会点到半路状态；--num_envs 10 并行度受 KVM/内存限制，别一上来拉满。OSWorld-Verified 官方跑用 100 步预算（2026 标杆配置）。

验证成功标志：results_trial/ 下生成每任务的 traj.html（动作回放）、截图、最终状态；--num_envs 10 时 10 个容器并行起得来且不互殴资源。

步骤 4：出分（每域成功率 + 总分）

python show_result.py \    --action_space pyautogui \    --model your-model \    --observation_type screenshot \    --result_dir ./results_trial \    --detailed          # 每个域输出 "score/total"

show_result.py 会输出：每域成功率（如 libreoffice_calc 12/26）、三大类别统计（Office / Daily / Professional）、以及 Overall success rate 和总分。

验证成功标志：看到一张"域 → score/total → 成功率"的表，且总分是各任务 evaluate() 返回浮点的均值。

步骤 5（进阶）：用 OSWorld 2.0 的 partial-credit 思路评估长时程任务

OSWorld 2.0（github.com/xlang-ai/OSWorld-V2，分支 osworld-v2.1）把 108 个长工作流切成 checkpoint，除了 binary 完成度还报 partial credit。最小复现：

git clone --branch osworld-v2.1 https://github.com/xlang-ai/OSWorld-V2cd OSWorld-V2uv sync --frozenuv run scripts/tools/download_osworld_v2_tasks.py --benchmark-release osworld-v2.1uv run scripts/tools/download_osworld_v2_assets.py \  --benchmark-release osworld-v2.1 --target-dir cache/osworld_v2_assets --cleanexport OSWORLD_FILE_BASE_URL="$(pwd)/cache/osworld_v2_assets"export WEBSITE_HOST_SUFFIX="<你的 v2.1 host 后缀>"# 用自带 Claude / Qwen 脚本，或改写 run_multienv_qwen.py 接入你的模型uv run python scripts/python/run_multienv_qwen.py --smoke_only \  --model your-served-model --base_url http://127.0.0.1:8000/v1

关键超参表

常见报错与规避

• KVM 不可用 / Docker 起不来：无虚拟化支持的云机跑不了桌面 VM。规避：换 aws provider（官方 AMI），或本机 VMware/VirtualBox。
• 部分任务卡在 OAuth / 代理 / Google 账号：OSWorld 有需登录的外部任务。规避：先跑不需要外部账号的域（如 os/libreoffice_*），需要的话按 SETUP_GUIDELINE.md 配代理和 SA 密钥（--vm_secret_mount 注入）。
• client_password 不对导致 VM 登录失败：Ubuntu 默认 user/password，AWS 默认 osworld-public-evaluation，务必用 --client_password 传对。
• 分数虚低是因为步数预算太小：先用 --max_steps 15 试水，正式对标必须 100 步（Verified）或 500 步（2.0），否则和官方数字不可比。

跑起来要花多少

• 最小闭环（单任务 docker 试水）：零 GPU，几分钟，API 费几美分~几角。
• 单域几十题（docker 10 并行）：几十分钟，API 费几美元。
• 全量 OSWorld-Verified（369 题）：数百~数千美元 API（按模型单价），需 VM 运维；云端 50× 并行可压到数小时。
• OSWorld 2.0 全量（108 长时程，500 步）：官方实测单次 3.87K（Opus 4.8）——这是"长时程 + 高步数"的真实代价，也是为什么大多数团队只跑子集或 smoke。

三、原理讲解

OSWorld 真正值钱的地方，是把"Agent 干没干完"从语义判读降维成状态验证。

为什么执行接地比 LLM-judge 更可信？ 长时程 GUI 任务里，中间步骤对不对、状态变没变，LLM 看轨迹容易"假合规"（看起来每一步都合理，最后文件没存）。OSWorld 的做法是：每个任务配一个 evaluate(final_state) 函数，它直接检查真实文件系统 / 应用状态 / 数据库是否到达目标——例如"报销单 PDF 是否生成在指定目录且金额字段正确"。返回的是一个 [0,1] 浮点：完全达成 1.0，部分达成给中间值，没达成 0.0。这把评分从"主观读轨迹"变成了"客观查状态"，和 SWE-bench 用 FAIL_TO_PASS 测代码执行是一个哲学。

OSWorld 2.0 的部分信用解决了什么？ 在 1.0 里，一个要 300+ 步的工作流只要最后一步没成，binary 就是 0——你完全不知道 Agent 是"第一步就崩"还是"走完 90% 才丢线"。2.0 把工作流切成有序 checkpoint，每个带权重，partial credit = 已通过的 checkpoint 权重之和 / 总权重。这暴露了一个反直觉事实：OSWorld 2.0 最强系统 binary 只有 20.6%，但 partial 高达 54.8%——Agent 不是不会操作 GUI，而是在长流程里"丢线"：忘掉开头定的约束、漏掉中途到达的新信息、该问用户时瞎猜、宣布完成前不验证。

为什么分数会"随 harness 漂移"？ 同一模型 + 不同脚手架（action 解析、重试、规划模块）在 OSWorld 上能差 30 分。因为评测分数 = 模型能力 × harness 落实能力，两者绑在一起；这也正是为什么引用 OSWorld 数字时必须写清"模型 + harness + 步数 + 运行次数"。

最小示意（≤15 行）：

# OSWorld 1.0：每任务 evaluate() 返回 [0,1] 浮点score_i   = evaluate(task_i, final_state)          # 程序确认目标状态SR_strict = mean(1for s in scores if s == 1.0)    # 严格成功率(全达成)SR_partial= mean(scores)                           # 含部分分的总分# OSWorld 2.0：长时程任务拆 checkpointpartial_i = sum(w_j * passed(c_j) for c_j in checkpoints_i) / sum(w_j)binary_i  = 1.0ifall(passed(c_j) for c_j in checkpoints_i) else0.0# 工程取舍：binary 看"能不能收尾"，partial 看"走了多远"，#           长流程里 partial 远比 binary 有信息量

工程上的关键取舍（效果 vs 成本 vs 稳定性）：截图模态（screenshot）最通用（能吃任意界面、含 canvas/游戏/老软件），但每张图上万 token、延迟高、对 Tiny UI 不敏感；可访问性树（accessibility_tree）省 token、定位准，但覆盖不了无语义标记的界面。步数预算直接决定成本和上限——预算不够低估能力，预算太高长任务会"绕圈"且 API 费失控。parallel 度受 KVM/内存硬约束，不是想拉多高就多高。

四、效果验证与适用边界

量化结果表

注：OSWorld-Verified 是经审计的版本（修 300+ 评测缺陷、AWS 50× 并行），也是当前所有发布稿引用的标准。2.0 的 20.6% 不是"退化"，而是任务从"几十步单任务"换成"318 次工具调用的长工作流"后的真实天花板。

业务收益单列（哪个环节省了什么）

• 采购选型环节：把"看演示视频"变成"看执行接地分数"，跨厂商可比，直接砍掉 84% 组织"不会评、不敢买"的焦虑。
• 发布闸门环节：用 partial-credit 识别"做一半就丢线"的 Agent，避免把只会操作短任务的产品当成能跑长工作流的方案上线。
• 回归/迭代环节：每域 score/total 表让"模型升级到底哪类任务涨了、哪类退了"一目了然，不用等线上事故。
• 口径防坑：强制披露"模型 + harness + 步数 + 运行次数"，让厂商的"90%"里模型贡献多少、harness 贡献多少暴露出来。

决策清单（什么条件下成立 / 失效）

成立条件：

• 你要评的是"真实桌面/跨应用操作"能力（不是纯 API/工具调用——那是 τ²-bench/BFCL 的事）。
• 你愿意承担真实 OS 环境运维（VM/Docker/KVM 或云 VM）+ 一定 API 成本。
• 你的 Agent 能输出 GUI 动作（截图驱动或无障碍树驱动都行）。

失效 / 退化条件：

• 你的业务是纯工具调用 Agent（订票、查库）→ OSWorld 不对症，去看 BFCL / τ²-bench。
• 没有 KVM、又不想上云 → 本地只能 VMware/VirtualBox，并行度受限、跑全量不现实。
• 只跑 --max_steps 15 就拿去和官方 100 步数字比 → 必然不可比，别这么干。
• 不看 harness 配置就信厂商分 → 会被脚手架优势误导。

换业务/模型要重新验证的前提：步数预算（长任务必须 500 步 2.0 / 100 步 Verified）、观察模态（截图 vs 无障碍树影响成本与上限）、harness 版本（官方 evaluate 脚本有修复补丁，跨版本分数不可比）。

已知局限与合规风险：部分任务依赖外部账号/OAuth/代理，企业内网环境可能跑不了；全量评测成本高（2.0 单次近 $4K），中小企业建议只跑子集 + smoke；评测过程会操作真实软件，需在隔离 VM 里跑，别挂生产账号。

复现清单

① 上手三步走

1. conda create -n osworld python=3.10 && pip install -r requirements.txt
2. 实现 mm_agents/my_agent.py（截图→模型→pyautogui 动作），在 run_multienv.py 里换成你的 Agent
3. 先 manual_examine.py 跑单任务验证链路，再 run_multienv.py --num_envs 10 扩域，show_result.py --detailed 出分

② 踩坑记录

• 无 KVM 的云机跑不了桌面 VM → 换 aws provider 或本机 VMware/VirtualBox
• 外部账号任务卡住 → 先跑 os/libreoffice_* 等无需登录的域
• client_password 错 → Ubuntu 默认 user/password，AWS 默认 osworld-public-evaluation
• 分数虚低 → 步数预算不够，正式对标必须 100 步（Verified）/500 步（2.0）

③ 实用评分卡

④ 关键源码 / 论文链接

• 仓库：https://github.com/xlang-ai/OSWorld^[1] （1.0 / Verified）
• 2.0 仓库：https://github.com/xlang-ai/OSWorld-V2^[2] （分支 osworld-v2.1）
• 论文：OSWorld (arXiv:2404.07972, NeurIPS 2024)；OSWorld 2.0 (arXiv:2606.29537, 2026-06)
• 榜单：https://os-world.github.io/^[3] ｜ https://leaderboard.steel.dev/leaderboards/osworld/^[4]
• Agent 接口：仓库内 mm_agents/README.md

今日反问

当 OSWorld 2.0 里一个 Agent 的"完成度"只有 20.6%、"部分信用分"却有 54.8% 时——我们到底该把那 34 分的落差，归因于它"不会操作界面"，还是归因于它"走到一半就忘了自己要干什么"？

引用链接