OSWorld：用真实操作系统给多模态 Agent 出考题
[NeurIPS 2024] OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments
秒懂
- 它是什么？
- OSWorld 是一个面向多模态 Agent 的基准测试，它让模型在真实的 Ubuntu 和 Windows 虚拟机里完成打字、拖拽、点菜单等操作。本文拆解它的评测机制、部署方式和适用边界。
- 适合谁用？
- OSWorld 适合研究团队和模型开发者，他们需要用一个贴近真实操作环境的基准来对比多模态 Agent 的 GUI 操作能力。它不适合只想快速跑通脚本的工程师，因为必须准备虚拟机或支持 KVM 的服务器，首次设置要下载预配置镜像，耗时较长。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
为什么需要一个跑在真实系统上的基准
多数 GUI Agent 基准把任务压缩成截图和鼠标坐标，模型只要学会在固定画面上点按钮就能拿高分。OSWorld 的出发点不同：它把任务放进真实的 Ubuntu 和 Windows 虚拟机，模型必须像人一样操作键盘鼠标，面对窗口遮挡、菜单层级、系统弹窗这些真实干扰。它的目标用户是研究多模态大模型和视觉语言模型（VLM）的团队，尤其是那些想评估模型在开放式任务中泛化能力的人。这里的开放式指任务没有固定操作序列，比如在 LibreOffice 里把文档另存为 PDF，模型需要自己规划步骤并处理意外状态。OSWorld 的论文发表于 NeurIPS 2024，仓库里提供了 369 个任务实例，覆盖办公、网页浏览、文件管理等场景。它不只是一个测试集，还附带了一套可重复的评测环境，这比给模型看静态截图要苛刻得多。
评测的核心机制：状态检查而非步骤匹配
OSWorld 的评测不关心模型走了哪几步，只看最终操作系统状态是否符合预期。每个任务都有一个初始状态设置脚本，把虚拟机配置到任务起点，比如打开某个文档或登录某个网站。模型运行结束后，评测脚本会检查屏幕截图、文件内容、进程列表等信号，判断任务是否完成。这种设计避免了步骤级评测的缺陷，模型可以自由探索，只要结果正确就算对。但这也带来一个代价：状态检查的编写成本高，每个任务都要设计独特的验证逻辑。仓库里的 evaluation_examples 目录存放这些任务定义，包括初始状态、目标描述和验证函数。评测时，模型通过环境接口接收屏幕像素和可访问性树，输出键盘鼠标动作，环境执行后返回新的状态。这个闭环模拟了人类操作计算机的完整过程。
部署的三种路径：VMware、Docker 与 Modal
OSWorld 的环境层被拆成独立的 desktop-env 包，你可以单独安装它而不带基准任务。最常见的部署方式是本地 VMware，先安装 VMware Workstation Pro 或 Fusion，然后运行 vmrun -T ws list 验证 vmrun 可用。仓库的 setup 脚本会自动下载预配置的虚拟机镜像，你不需要手动创建系统。如果你在云服务器或容器平台工作，物理机没有虚拟化支持，那就走 Docker 路线。前提是宿主支持 KVM，Linux 下用 egrep -c '(vmx|svm)' /proc/cpuinfo 检查，返回大于 0 才可行。Docker 模式下创建 DesktopEnv 时要指定 provider_name 为 docker，os_type 为 Ubuntu 或 Windows。第三种是 Modal 云沙箱，安装 modal 客户端后运行 modal setup 认证，再用 python -m desktop_env.providers.modal.setup --os Ubuntu 预置镜像，最后用 python quickstart.py --provider_name modal --headless true 启动。三种路径的区别在于虚拟化层：VMware 适合本机调试，Docker 适合服务器批处理，Modal 适合需要并行扩展的云端评测。
OSWorld-Verified：修复信号后的一次重要更新
2025 年 7 月，项目发布了 OSWorld-Verified，这是对原基准的一次修正。更新说明提到修复了社区报告的若干问题，并增加了对 AWS 的支持，通过并行化可以把评测时间缩短到 1 小时以内。更重要的是，它声称让基准信号更有效，意思是减少误报和漏报，让模型分数更真实地反映能力。官方还重新跑了一遍新模型的结果，并更新在官网上。这个版本提醒使用者：OSWorld 的分数不是一成不变的，环境细节和评测逻辑的改动会直接影响排名。如果你在论文里对比旧版本的结果，必须注明使用的是哪个版本，否则数字没有可比性。从仓库的 release 历史看，v0.1.0 到 v0.1.16 之间隔了不到三个月，说明环境代码在快速迭代，这本身就是一种维护成本的信号。
已知的痛点和失败模式
OSWorld 的文档明确写出几个容易翻车的地方。第一，VMware 的并行支持不完善，VirtualBox 在并行和 macOS Apple 芯片上也可能有问题，如果你的评测需要同时跑多个虚拟机，Docker 或 Modal 是更稳的选择。第二，Docker 模式在实验被异常中断时会留下残留容器，长期累积会拖慢系统，需要手动执行 docker stop $(docker ps -q) && docker rm $(docker ps -a -q) 清理。第三，macOS 宿主一般不支持 KVM，所以想在 Mac 上用 Docker 跑 OSWorld 基本不可行，只能回到 VMware Fusion。第四，任务依赖预下载的初始状态文件，仓库提供了 Google Drive 缓存，但如果你所在网络访问受限，下载会变成瓶颈。这些限制意味着 OSWorld 不是一个开箱即用的玩具，它要求使用者具备虚拟化环境的管理能力。
与合成环境类基准的路线差异
OSWorld 的对照物是那些在合成网页或模拟器里评测 Agent 的基准，比如 Mind2Web 或 MiniWoB。合成环境的优点是可控、便宜、可并行，但缺点是界面过于规整，模型容易记住模式。OSWorld 坚持使用真实操作系统，这意味着每个像素都有真实意义，字体渲染、窗口管理器行为、软件版本差异都会影响结果。代价是评测成本高，每跑一个任务都要启动虚拟机，时间和资源开销远大于合成环境。另一个差异在任务粒度：合成环境通常把任务分解成单步操作，而 OSWorld 的任务是多步的、需要长期规划，例如在表格里修改多个单元格并保存。如果你的研究目标是验证模型对 GUI 组件的理解，合成环境可能更合适；如果目标是评估模型在真实桌面环境中的实用性，OSWorld 的生态效度更高。
许可证与升级维护的现实账
OSWorld 采用 Apache-2.0 许可证，这对商业使用和二次开发都比较友好，你可以自由修改环境代码并用于内部评测。但要注意，基准数据本身可能包含第三方软件的截图和任务描述，使用前需确认是否符合原始软件的版权要求。从维护角度看，仓库的活跃度体现在 2025 年仍在更新，OSWorld-Verified 的发布说明里提到社区反馈驱动了修复，这说明项目有持续的维护意愿。然而，环境代码依赖 VMware 和 VirtualBox 这些外部软件，它们各自的许可证和版本兼容性不在 OSWorld 的控制范围内。升级 OSWorld 版本时，你需要重新下载虚拟机镜像或更新 desktop-env 包，旧版任务可能无法直接迁移到新评测逻辑。建议固定版本号来复现结果，并在论文中标注具体 commit 或 release tag，否则你的分数无法被后人验证。
编辑结论
OSWorld 适合研究团队和模型开发者，他们需要用一个贴近真实操作环境的基准来对比多模态 Agent 的 GUI 操作能力。它不适合只想快速跑通脚本的工程师，因为必须准备虚拟机或支持 KVM 的服务器，首次设置要下载预配置镜像，耗时较长。在采用前，先确认三件事：你的机器是否支持硬件虚拟化（Linux 下运行 egrep -c '(vmx|svm)' /proc/cpuinfo），你能否接受 VMware 在 Apple 芯片上仅支持 Fusion 的限制，以及你是否愿意处理异常中断后残留的 Docker 容器（需要 docker stop $(docker ps -q) && docker rm $(docker ps -a -q) 清理）。若这些条件都满足，OSWorld 能提供比传统截图问答或合成环境更可信的评测信号，但它的任务难度和覆盖范围仍受限于 369 个预置实例，超出这个范围的泛化能力需要自行验证。
社区笔记