OSWorld：基于真实虚拟机的多模态智能体操作系统沙盒实战指南

1. OSWorld：一个为多模态智能体打造的“真实世界”操作系统沙盒

如果你正在研究或开发能够理解并操作计算机的智能体（Agent），无论是基于大语言模型（LLM）、视觉语言模型（VLM）还是强化学习（RL），那么你肯定面临过一个核心难题：如何在一个真实、可控、可复现的环境里，系统地评估它们的“动手能力”？是让它们去操作一个高度抽象、功能有限的模拟器，还是冒着巨大风险让它们直接在你的个人电脑上“自由发挥”？这两种方案显然都不理想。前者离现实太远，评估结果缺乏说服力；后者则充满了不可控的风险和伦理问题。

这正是OSWorld项目诞生的背景。它不是一个玩具般的模拟器，而是一个基于真实虚拟机（VM）技术构建的基准测试平台。简单来说，OSWorld为你准备了一台或多台“干净”的虚拟机（支持Ubuntu和Windows），里面预装了从办公软件、浏览器到开发工具等各种真实应用程序。然后，它会向你的智能体发布一系列开放式的任务指令，比如“在LibreOffice Impress中创建一个包含三张幻灯片的演示文稿，主题是气候变化”、“在Firefox浏览器中搜索本地的意大利餐厅，并将前三家的地址保存到一个文本文件中”，或者“使用GIMP将一张图片裁剪为圆形并添加水印”。你的智能体需要通过观察屏幕截图（或DOM结构）、理解任务，并生成一系列鼠标点击、键盘输入等操作来完成任务。OSWorld会全程记录并自动评估任务的完成情况。

我第一次接触OSWorld时，最深的感触是它终于把“智能体操作计算机”这件事从纸上谈兵拉到了实战演练的层面。过去我们讨论Agent的“工具使用”能力，往往停留在调用几个预设API的层面。但真实的计算机操作是图形化、多模态、状态复杂且充满不确定性的。一个按钮可能因为加载延迟而暂时无法点击；一个文件可能因为路径问题而找不到；一个网页的布局可能随时变化。OSWorld构建的这个沙盒环境，恰恰是为了捕捉和衡量智能体应对这种复杂性的能力。它不仅是评估现有模型的标尺，更是驱动下一代“具身智能”或“数字员工”Agent发展的关键基础设施。

2. 核心设计思路：为何是虚拟机？为何如此复杂？

2.1 虚拟机 vs. 模拟器：真实性的代价与收益

在构建这样一个测试环境时，团队面临一个根本性的选择：是自研一个高度定制化的模拟器，还是基于成熟的虚拟机技术进行封装？OSWorld选择了后者，这是一个深思熟虑且在我看来非常正确的决定。

自研模拟器的好处是高度可控、轻量、可并行化程度高。你可以精确控制环境的每一个状态，渲染速度也可以做到极快。但它的致命缺点在于真实性不足。一个模拟出来的Chrome浏览器，其渲染引擎、JavaScript执行环境、网络行为都可能与真实环境有细微差别，而这些差别足以让一个在模拟器中表现优异的Agent，在真实用户电脑上漏洞百出。此外，模拟所有主流应用程序（如Office套件、专业设计软件）的交互逻辑，是一个几乎不可能完成的工程任务。

而基于虚拟机（如VMware、VirtualBox）或容器（Docker with KVM）的方案，则原生地继承了整个真实操作系统的所有复杂性。Agent在VM里面对的就是一个真正的Ubuntu或Windows系统，所有的应用程序都是真实安装的，所有的交互都是通过系统底层的输入事件驱动。这保证了评估结果的生态效度——即在这个环境里表现好的Agent，在真实用户环境中更有可能表现好。当然，这种方案带来了显著的复杂性：虚拟机笨重、启动慢、资源占用高，并且需要解决图形界面的远程访问和控制问题。

注意：OSWorld团队通过精心的架构设计，将环境控制（Provider，如VMware、Docker）与任务逻辑、评估逻辑解耦。这意味着你可以在自己的笔记本电脑上用VMware跑一个任务，也可以在云服务器集群上用Docker并行跑上百个任务，而你的Agent代码和评估脚本几乎不需要改动。这种灵活性是项目的一大亮点。

2.2 多模态观察与复杂动作空间的设计考量

OSWorld为Agent提供了两种主要的观察模式：屏幕截图（screenshot）和可访问性树（accessibility tree， 即DOM结构的一种近似）。这两种模式对应着智能体感知世界的两种不同“感官”。

• 屏幕截图（Screenshot）：这是最接近人类视觉的输入方式。Agent接收到的是一张当前桌面的PNG图片。要理解这张图片，Agent需要具备强大的视觉语言模型（VLM）能力，能够识别图标、按钮、文字、窗口布局等。这种方式的优势是通用性强，任何显示在屏幕上的内容都能被捕捉。劣势是对模型要求高，且信息提取可能不够精确（例如，精确的文本内容可能因字体或渲染问题而识别错误）。
• 可访问性树（Accessibility Tree）：这是操作系统为辅助功能（如屏幕阅读器）提供的一种结构化界面描述。它包含了界面元素的层级关系、类型（按钮、文本框）、名称、状态等元数据。这种方式提供的信息非常精确和结构化，便于模型理解和生成精确的操作。但它的缺点是覆盖不全，并非所有应用程序都提供了完善的可访问性支持，一些自定义绘制的UI控件可能无法被捕获。

在动作空间上，OSWorld支持通过pyautogui库模拟鼠标和键盘操作，包括移动、点击、拖拽、输入文本、快捷键等。这是一个低层级、连续的动作空间，与模拟点击某个具体的API按钮截然不同。Agent需要决定鼠标移动的精确坐标（或相对方向）和点击类型（左键、右键），这极大地增加了任务的难度，但也更贴近真实的人机交互。

为什么选择这样的设计？我认为这背后是对智能体“通用性”的终极追求。一个真正强大的计算机使用智能体，不应该依赖于某个特定应用程序的定制化接口，而应该能像人一样，通过“看”屏幕和“操作”鼠标键盘来完成任务。OSWorld正是在用最高标准来考验这一点。

3. 从零开始：环境搭建的实战与避坑指南

纸上得来终觉浅，绝知此事要躬行。下面我将结合自己的搭建经验，详细拆解OSWorld的安装与配置过程，并分享其中容易踩坑的地方。

3.1 本地开发机部署（VMware/VirtualBox方案）

这是最常用的个人开发和测试方案。假设你有一台性能尚可的台式机或笔记本电脑（建议16GB以上内存，SSD硬盘）。

步骤一：克隆代码与准备Python环境

git clone https://github.com/xlang-ai/OSWorld cd OSWorld # 强烈建议使用Conda管理环境，避免依赖冲突 conda create -n osworld python=3.10 -y conda activate osworld pip install -r requirements.txt

这一步通常很顺利。但请注意Python版本必须>=3.10，否则一些新的语法特性（如match语句）会导致报错。

步骤二：安装并配置虚拟机管理软件这是整个流程中最容易出问题的一环。OSWorld默认推荐VMware Workstation Pro（Windows/Linux）或VMware Fusion（macOS Apple Silicon）。

1. 下载与安装：从VMware官网下载试用版即可。安装过程需要重启电脑，并启用虚拟化支持（在BIOS/UEFI中确保Intel VT-x或AMD-V已开启）。
2. 关键配置：vmrun命令：安装完成后，你需要将VMware的安装目录（例如C:\Program Files (x86)\VMware\VMware Workstation\）添加到系统的PATH环境变量中。这是为了能在命令行中直接调用vmrun工具，这是OSWorld控制虚拟机的核心。
3. 验证安装：打开终端，输入vmrun -T ws list。如果配置成功，它会列出当前正在运行的虚拟机列表（初始时应该是空的）。如果提示“命令未找到”，说明环境变量设置有问题。

实操心得：在Windows上，有时即使添加了PATH，在PowerShell或VSCode的终端里仍然找不到vmrun。这是因为终端会话没有刷新环境变量。最稳妥的方法是重启终端应用，或者直接使用cmd.exe并确保以管理员身份运行。在macOS上，安装Fusion后，vmrun通常位于/Applications/VMware Fusion.app/Contents/Library，可能需要手动创建软链接或将其路径显式地添加到你的脚本中。

步骤三：首次运行与自动下载当你第一次运行quickstart.py或任何实验脚本时，OSWorld环境会自动从云端下载预配置好的虚拟机镜像（一个.vmx文件和对应的虚拟磁盘文件）。这个过程可能会比较耗时（镜像大小约几个GB），取决于你的网络速度。

python quickstart.py --provider_name vmware

如果一切正常，你会看到日志中开始下载VM，然后启动VM，进行一系列初始化设置（安装必要软件、配置网络等），最后执行一个示例动作（如右击桌面）。看到成功的日志，恭喜你，基础环境就绪了。

3.2 服务器端高性能部署（Docker with KVM方案）

如果你需要在云服务器上进行大规模并行评估，或者你的宿主机本身就是虚拟化的（例如云厂商的VPS），那么VMware可能无法正常工作（因为它需要硬件虚拟化支持，而云主机通常不嵌套虚拟化）。这时，Docker + KVM方案是首选。

前提条件：检查KVM支持在Linux服务器上执行：

egrep -c '(vmx|svm)' /proc/cpuinfo # 如果输出大于0，则支持KVM。对于云服务器，你需要确保实例类型支持嵌套虚拟化（例如AWS的某些实例类型需要额外开启）。 lsmod | grep kvm # 检查KVM内核模块是否已加载。

如果支持KVM，你需要安装docker和docker-compose，以及KVM相关的用户态工具qemu-kvm、libvirt等。

核心：理解Docker方案的原理与VMware方案直接操作.vmx文件不同，Docker方案是在Docker容器内部，利用KVM启动一个完整的虚拟机。OSWorld的Docker镜像已经包含了QEMU、KVM和一个预装好的虚拟机磁盘镜像。当你初始化DesktopEnv并指定provider_name='docker'时，它会启动一个容器，并在容器内启动这个VM。

运行示例：

# 确保你的用户有权限操作Docker和KVM设备 sudo usermod -aG docker,kvm $USER newgrp docker # 或重新登录使组权限生效 # 运行一个简单的测试 python quickstart.py --provider_name docker --os_type Ubuntu

重要注意事项：

1. 资源清理：Docker方案在异常中断时，可能会留下处于“Exited”状态的容器，占用磁盘空间。定期使用docker system prune -a进行清理是个好习惯。OSWorld文档中也提供了强制清理所有容器的命令。
2. 性能：在支持KVM的硬件上，Docker内虚拟机的性能损失很小，几乎接近原生。这比基于软件模拟的方案快得多。
3. macOS宿主机：macOS上的Docker Desktop使用HyperKit而非KVM，因此无法使用此方案。macOS用户应坚持使用VMware Fusion。

3.3 云端大规模并行评估（AWS方案）

对于需要评估数百甚至上千个任务的团队，OSWorld的AWS支持是“神器”。它采用主机-客户端架构，将任务分发到大量并行的EC2实例上执行，可以将原本需要数天的评估缩短到1小时内。

架构简述：

1. 主机（Host）：你本地或一台控制服务器。负责管理任务队列、分发任务到客户端、收集结果。
2. 客户端（Client）：多个AWS EC2实例。每个实例上运行一个OSWorld环境（Docker方案），独立执行分配到的任务。

配置流程概要：

1. AWS资源准备：创建具有EC2、S3、IAM等权限的AWS账户和密钥。
2. 配置客户端AMI：你需要创建一个亚马逊机器镜像（AMI），这个镜像已经预装了Docker、OSWorld所需的所有依赖以及虚拟机镜像。OSWorld提供了详细的脚本和CloudFormation模板来帮助完成这一步。
3. 配置主机端：在你的主机上配置AWS CLI凭证，并修改OSWorld的并行运行脚本（如run_multienv_aws.py），指定你的AMI ID、实例类型、安全组等。
4. 启动评估：运行脚本后，主机会自动启动指定数量的EC2实例，将任务分发出去，并监控执行状态。任务完成后，结果会自动上传到S3，实例也会被自动终止以节省成本。

成本考量：使用AWS会产生费用，主要来自EC2实例的运行时长和EBS存储。选择按需实例（如c5.xlarge）并设置好自动终止策略，可以有效控制成本。对于长期、大规模的评估，使用Spot实例可以节省60-70%的费用，但需要处理实例可能被中断的情况。

4. 运行你的第一个智能体：从基线模型到自定义Agent

环境搭好了，接下来就是让智能体上场了。OSWorld提供了基于GPT-4o的基线Agent，我们可以先运行它来感受一下整个流程。

4.1 配置与运行基线评估

首先，你需要一个OpenAI的API密钥。

export OPENAI_API_KEY='你的API密钥' # 如果你使用Azure OpenAI或其它兼容接口，可以设置BASE_URL # export OPENAI_BASE_URL='https://your-endpoint.openai.azure.com/'

然后，运行一个单任务评估。这里我们使用screenshot作为观察类型，让GPT-4o“看”图操作。

python run.py \ --provider_name vmware \ # 使用VMware提供商 --path_to_vm Ubuntu/Ubuntu.vmx \ # VM路径，首次运行后会自动定位 --headless \ # 无头模式，不显示VM的GUI窗口，节省资源 --observation_type screenshot \ # 使用屏幕截图作为观察 --model gpt-4o \ # 使用的模型 --sleep_after_execution 3 \ # 每个动作执行后等待3秒，让系统状态稳定 --max_steps 15 \ # 一个任务最多尝试15步 --result_dir ./results_gpt4o \ # 结果保存目录 --client_password password # VM内用户密码

执行这个命令后，你会看到日志滚动。OSWorld会随机选择一个基准测试任务（例如，一个关于LibreOffice Writer的任务）加载到VM中，然后开始循环：将当前屏幕截图传给GPT-4o，GPT-4o返回一个动作描述（如click(‘File’)），OSWorld将其转化为pyautogui指令执行，等待，再截图，如此往复，直到任务完成或达到最大步数。

结果分析： 任务结束后，所有记录（每一步的截图、动作、最终状态视频）会保存在./results_gpt4o目录下。运行评分脚本：

python show_result.py --result_dir ./results_gpt4o --detailed

你会看到类似下面的输出，显示了在各个领域（如libreoffice_writer,web_shopping）的成功率。

Domain Score ---------------------- ------- libreoffice_writer 3/5 web_shopping 4/5 ... Overall Success Rate: 58.33%

这个基线分数为你提供了一个标杆。接下来，你就可以思考如何超越它了。

4.2 深入Agent接口：如何打造你自己的智能体

要评估你自己的模型，你需要实现OSWorld定义的Agent接口。核心文件在mm_agents/目录下。让我们看一个简化版的接口理解：

一个Agent本质上是一个接收observation（观察）和task_instruction（任务指令），并返回action（动作）的类。OSWorld的BaseAgent类定义了框架。

关键方法：

• reset(self, task_instruction): 在每个新任务开始时被调用，传入任务描述。
• step(self, observation): 这是核心。接收当前的观察（一个字典，可能包含screenshot图像、accessibility_tree文本等），返回一个动作字符串。

动作字符串的格式： 动作需要遵循特定的文本格式，以便OSWorld的ActionExecutor进行解析。例如：

• click('File')- 点击屏幕上文本为“File”的元素。
• type('Hello World')- 输入文本“Hello World”。
• press('enter')- 按下回车键。
• hotkey('ctrl', 's')- 按下Ctrl+S保存。

实现你自己的Agent：

1. 继承BaseAgent：在mm_agents/下创建一个新文件，例如my_awesome_agent.py。
2. 实现模型调用逻辑：在step方法中，你需要将observation和task_instruction组织成你的模型能理解的提示词（Prompt）。这可能涉及复杂的多模态信息融合。例如，你可以将截图用VLM描述成文本，再和任务指令一起送给LLM做决策；或者直接将截图和指令送给一个端到端的VLM。
3. 解析模型输出：你的模型需要输出符合上述格式的动作字符串。你可能需要在提示词中严格要求模型以此格式输出，并在代码中添加后处理来确保格式正确。
4. 集成到运行脚本：修改run.py或run_multienv.py，将--model参数指向你的Agent类，或者直接修改代码导入你的Agent。

避坑技巧：动作空间的探索与利用让模型直接输出精确的click(‘File’)或坐标click((100,200))是非常困难的。一个常见的策略是分层决策：

1. 高层规划：模型先输出一个高层目标，如“打开文件菜单”。
2. 元素定位：环境或一个辅助模块根据这个目标，结合可访问性树或截图分析，找到最匹配的UI元素及其坐标或标识符。
3. 底层执行：生成最终的动作字符串，如click(element_id=‘menu_file’)。 许多研究团队会为Agent配备一个“视觉定位模块”或利用Grounding DINO、SAM等模型来辅助元素定位，这能显著提升动作的准确率。

5. 任务、评估与排错：深入OSWorld核心机制

5.1 理解任务结构与评估标准

OSWorld的基准测试任务定义在evaluation_examples/目录下，以JSON格式存储。每个任务文件包含了丰富的元数据：

{ "id": "a669ef01-ded5-4099-9ea9-25e99b569840", "domain": "libreoffice_impress", "instruction": "Create a presentation with 3 slides. The title slide should have the title 'Climate Change' and subtitle 'Impacts and Solutions'. The second slide should have a bullet list with points: 'Rising sea levels', 'Extreme weather events', 'Loss of biodiversity'. The third slide should have a title 'Call to Action' and an image from the internet about renewable energy.", "initial_state": "vm_snapshot_path", "eval": { "type": "file_content", "criteria": "The generated .odp file should contain exactly 3 slides with the specified content...", "reference_file": "expected_output.odp" } }

• initial_state: 指向一个虚拟机快照。每个任务都从一个干净、确定性的初始状态开始，确保评估的公平性。
• eval: 定义了如何评估任务成功。类型多样，包括：
  • file_content: 检查生成的文件内容是否匹配。
  • ui_state: 检查特定的UI元素是否出现（如某个对话框）。
  • program_output: 运行一个检查脚本。
  • human: 需要人工判断。

自动评估流程：任务结束后，OSWorld会根据eval配置自动执行评估。例如，对于file_content类型，它会将VM中生成的文件与参考文件进行对比（可能是文本对比、图像相似度计算等）。最终的成功与否是一个布尔值。

5.2 常见问题与排查实录

在实际运行中，你肯定会遇到各种问题。以下是我和社区遇到的一些典型问题及解决方案：

问题一：VM启动失败，提示“无法连接到虚拟机”或“vmrun命令执行错误”。

• 可能原因1：VMware服务未启动。在Windows服务中检查VMware Authorization Service和VMware Workstation Server是否正在运行。
• 可能原因2：路径包含中文或特殊字符。确保OSWorld项目路径和虚拟机存放路径全是英文。
• 可能原因3：权限不足。尝试以管理员身份运行你的命令行或脚本。
• 排查命令：手动执行vmrun -T ws list，看是否能正常列出虚拟机。如果不能，说明VMware环境本身有问题。

问题二：任务执行失败，Agent一直卡在某个步骤，或者点击位置不对。

• 可能原因1：观察信息不足。在screenshot模式下，模型可能看不清小图标或文字。可以尝试提高截图分辨率（如果支持），或者在Prompt中引导模型更仔细地描述屏幕。
• 可能原因2：系统响应延迟。--sleep_after_execution参数设置得太短，上一步操作的效果还没完全显现，模型就基于旧状态做出了决策。适当增加这个等待时间（例如从3秒增加到5秒）。
• 可能原因3：动作解析错误。检查Agent输出的动作字符串是否完全符合OSWorld的语法规范。一个多余的空格或大小写错误都可能导致解析失败。在开发阶段，可以打开调试日志，查看ActionExecutor解析到的具体动作是什么。
• 调试建议：使用--headless false参数运行，这样VM的GUI窗口会显示出来。你可以亲眼看到Agent在做什么，鼠标在哪里点击，这对于理解模型的行为至关重要。

问题三：涉及网络的任务（如网页搜索、下载图片）失败。

• 可能原因：虚拟机内的网络配置问题，或者目标网站有反爬机制。
• 解决方案：
  1. 检查VM网络：确保虚拟机使用的是NAT或桥接模式，能够访问互联网。可以在VM内部打开终端，尝试ping google.com。
  2. 配置代理：如果需要，参考OSWorld的SETUP_GUIDELINE.md文档，在虚拟机内设置HTTP代理。这通常需要你拥有一个可用的代理服务器。
  3. Google账户任务：一些任务需要登录Google账户。你必须按照指南，在VM中预先登录一个测试用的Google账号，并配置好OAuth 2.0凭证。这是一个比较繁琐但必要的步骤。

问题四：并行运行（Docker/AWS）时，任务随机失败或超时。

• 可能原因1：资源竞争。多个容器/实例同时运行，宿主机CPU、内存或磁盘I/O达到瓶颈。确保你的宿主机有足够的资源。在AWS上，选择计算优化型实例（如C系列）。
• 可能原因2：网络波动。云端实例之间的通信或下载VM镜像时出现网络问题。为任务设置合理的超时时间，并实现重试机制。
• 可能原因3：状态污染。虽然每个任务从快照开始，但如果在任务执行过程中有全局状态改变（如下载文件到用户目录），且快照未包含此变化，可能会影响后续任务。确保你的快照是绝对干净的，并且任务不会修改共享的全局状态。

5.3 手动审查与调试工具

当自动评估结果不理想，或者你想深入了解某个任务为什么失败时，OSWorld提供的manual_examine.py工具非常有用。

python scripts/python/manual_examine.py \ --headless false \ # 显示GUI，方便观察 --observation_type screenshot \ --result_dir ./debug \ --test_all_meta_path evaluation_examples/test_all.json \ --domain web_shopping \ --example_id a669ef01-ded5-4099-9ea9-25e99b569840 \ --max_steps 30

运行这个脚本，它会加载指定的任务，但将控制权交给你。你可以在终端里输入动作命令（如click('Search')），一步一步地手动执行任务，同时观察VM窗口的变化。所有步骤也会被记录。这就像是一个“单步调试器”，让你能精确复现Agent的行为，或者找出任务设计本身可能存在的问题。

6. 进阶应用与未来展望

OSWorld不仅仅是一个评测基准，它更是一个强大的研究平台。基于它，你可以开展多方面的探索：

1. 训练而不仅仅是评估： OSWorld的环境可以产生大量的(state, action, reward)轨迹。理论上，你可以利用这些轨迹进行强化学习（RL）训练，让Agent通过与环境的交互来学习操作策略。这需要设计合理的奖励函数（例如，基于任务完成度的稀疏奖励，或基于向目标状态靠近的稠密奖励）。OSWorld的确定性初始状态和可重复性，为RL训练提供了理想的条件。

2. 探索不同的观察与动作表示： 目前的screenshot和accessibility_tree只是开始。你可以尝试融合更多模态的输入，比如：

• 屏幕视频流：提供连续帧，让Agent感知动态变化（如加载动画）。
• 底层系统事件：监听文件系统变化、网络请求等。
• 更丰富的动作空间：除了pyautogui，是否可以引入更高级的API调用？例如，对于已知的应用程序，能否直接调用其COM接口（Windows）或DBus接口（Linux）来执行更可靠的操作？这需要在通用性和可靠性之间做权衡。

3. 构建分层或模块化Agent： 如前所述，让一个端到端模型完成从像素到精确坐标的映射非常困难。一个更可行的架构是分层Agent：

• 规划层（LLM）：理解任务，拆解为子目标序列（“打开浏览器” -> “访问搜索引擎” -> “输入关键词” -> “点击第一个结果”）。
• 技能层（VLM + 定位模块）：对于每个子目标，识别当前屏幕上的相关元素，并生成操作指令。
• 执行层：将指令转化为OSWorld可执行的动作。 OSWorld是测试这种分层架构的绝佳平台。

4. 领域扩展与任务生成： OSWorld现有的任务主要集中在办公、网页浏览和系统管理。社区可以贡献更多领域的任务，如：

• 创意设计：使用GIMP或Inkscape完成特定设计任务。
• 软件开发：在VSCode中编写、运行并调试一段简单的代码。
• 数据分析：使用电子表格软件处理数据并生成图表。 更激动人心的是，利用大模型自动生成新的任务和初始状态。例如，给定一个应用程序，让GPT-4生成一系列合理的操作任务及其评估标准，然后自动在干净的VM中设置初始状态并验证任务的可行性。这将使基准测试的规模和多样性得到指数级增长。

在我自己的实验过程中，最大的体会是：OSWorld将智能体研究从“对话”和“文本推理”真正推进到了“具身交互”和“环境感知”的层面。它暴露出现有模型的诸多短板——空间理解能力弱、操作序列规划能力差、对不确定性的容忍度低。但同时，它也指明了清晰的前进方向。每一次调试Agent、分析失败轨迹的过程，都让我对“让AI使用计算机”这个目标的复杂性与魅力有了更深的认识。这个领域才刚刚拉开序幕，而OSWorld无疑是为所有参赛者搭建起的第一条坚实跑道。