OSWorld: ein Benchmark, der Agenten auf echten Desktop-Systemen laufen lässt

Welche Lücke OSWorld schließt

Viele Agenten-Benchmarks spielen in einer Textwelt oder in einer nachgebauten API. OSWorld geht den anderen Weg: Die Aufgabe wird in einem echten Betriebssystem ausgeführt, und die Bewertung liest den Systemzustand aus, statt eine Antwortzeichenkette zu vergleichen. Das Repository beschreibt das Ziel selbst als Benchmarking multimodaler Agenten für offene Aufgaben in echten Computerumgebungen. Der Adressat ist damit klar umrissen: Forschungs- und Engineering-Teams, die einen Agenten bauen, der Maus, Tastatur und Bildschirminhalt als Schnittstelle benutzt, also GUI-Automatisierung, RPA oder ein Large Action Model. Wer eine reine Coding-Aufgabe in einem Container messen will, braucht dieses Projekt nicht. Der Aufwand liegt nicht im Modell, sondern in der Umgebung: Eine VM muss starten, ein Ausgangszustand muss hergestellt werden, und die Auswertung muss den Endzustand zuverlässig erkennen.

Aufgaben, Initialzustand, Auswertung

Die Daten liegen im Verzeichnis evaluation_examples. Jede Aufgabe besteht dem Repository zufolge aus einem Initialzustand, einer Anweisung in natürlicher Sprache und einer Auswertungsroutine. Der Ablauf ist eine Kette: Die Umgebung setzt den Ausgangszustand, der Agent erhält die Anweisung und arbeitet über die grafische Oberfläche, danach liest die Auswertung das Ergebnis aus dem System. Diese Trennung ist der eigentliche Mechanismus. Der Agent kann keinen Text abliefern, der wie eine Lösung aussieht; er muss eine Datei, ein Fenster oder eine Einstellung tatsächlich verändern. Genau darin steckt die Stärke und die Fehlerquelle. Eine Auswertung, die auf Dateipfaden oder Anwendungszuständen beruht, ist empfindlich gegen Versionen und gegen Timing. Das Projekt hat im Juli 2025 unter dem Namen OSWorld-Verified eine Überarbeitung veröffentlicht, die nach eigener Aussage mehrere von der Community gemeldete Probleme behebt und die Benchmark-Signale wirksamer macht. Wer heute Ergebnisse veröffentlicht, sollte deshalb prüfen, mit welcher Version er vergleicht.

Provider als austauschbare Schicht

Die Umgebung ist so gebaut, dass die Virtualisierung austauschbar ist. Das Repository nennt VMware, VirtualBox, Docker, AWS, Azure und Modal als Provider. Für VMware und VirtualBox gilt: Der Host ist ein Desktop, Laptop oder eine Bare-Metal-Maschine, also nicht selbst virtualisiert. Auf virtualisierten Plattformen verweist die Anleitung auf den Docker-Weg mit KVM. Die Prüfung dafür ist ein einziger Befehl auf Linux: egrep -c '(vmx|svm)' /proc/cpuinfo. Ein Rückgabewert größer null zeigt, dass die CPU KVM unterstützen sollte. Für macOS-Hosts steht ausdrücklich, dass KVM in der Regel nicht verfügbar ist und stattdessen VMware verwendet werden sollte. Diese Bedingung ist praktisch die wichtigste beim Aufsetzen, weil sie die Wahl des Providers diktiert, bevor irgendein Modell läuft.

Installation und die ersten Befehle

Der Einstieg ist konventionell. Repository klonen, hineinwechseln, Abhängigkeiten installieren, wobei Python mindestens 3.10 verlangt wird: git clone https://github.com/xlang-ai/OSWorld, dann cd OSWorld, dann pip install -r requirements.txt. Wer nur die Umgebung ohne Benchmark-Aufgaben braucht, installiert stattdessen das Paket desktop-env über pip. Für den VMware-Weg muss vmrun konfiguriert sein; die Kontrolle lautet vmrun -T ws list und sollte laufende virtuelle Maschinen auflisten. Für den Docker-Weg werden beim Erzeugen von DesktopEnv die Argumente provider_name auf docker und os_type auf Ubuntu oder Windows gesetzt. Modal ist der dritte Weg und läuft über VM Sandboxes: pip install 'modal>=1.5.0', dann modal setup, dann das Disk-Image mit python -m desktop_env.providers.modal.setup --os Ubuntu bereitstellen und schließlich python quickstart.py --provider_name modal --headless true. Diese vier Zeilen sind der kürzeste dokumentierte Pfad zu einem laufenden Versuch.

Bekannte Bruchstellen im Betrieb

Abgebrochene Experimente hinterlassen bei Docker Restcontainer, die laut Dokumentation die Systemleistung mit der Zeit beeinträchtigen können; als Aufräumbefehl ist docker stop $(docker ps -q) && docker rm $(docker ps -a -q) angegeben. Das ist kein Schönheitsfehler, sondern ein Hinweis darauf, dass die Umgebung Zustand außerhalb des Prozesses hält. VirtualBox wird unterstützt, aber die Einschränkung steht offen im Text: Parallelität und macOS auf Apple-Chips sind dort nicht gut abgedeckt. Wer viele Aufgaben gleichzeitig fahren will, landet faktisch bei Docker mit KVM, bei AWS oder bei Modal. Ein zweiter Kostenpunkt ist der Initialzustand. Viele Aufgaben brauchen vorab geladene Dateien; dafür verlinkt das Projekt einen Cache zum Herunterladen. Ohne diesen Cache ist ein Teil der Aufgaben nicht reproduzierbar, und das ist ein Kriterium, das man vor dem Start klären sollte.

Wann OSWorld das falsche Werkzeug ist

Der Benchmark misst in einem vollen Betriebssystem, und dieser Umfang ist zugleich seine Grenze. Wer eine schnelle Regressionsprüfung in der CI sucht, wird mit VM-Start, Initialzustand und Auswertung nicht glücklich; die Laufzeit pro Aufgabe liegt in einer anderen Größenordnung als bei textbasierten Tests. Ebenso ungeeignet ist OSWorld für Teams, die eine fertige Agenten-Bibliothek suchen. Das Repository liefert Aufgaben, Umgebung und Auswertung, kein Produktionsframework für den eigenen Anwendungsfall. Und wer auf einem macOS-Host ohne KVM arbeitet, muss den VMware-Pfad nehmen, mit den genannten Abstrichen bei Parallelität. In diesen Fällen ist der Aufwand höher als der Erkenntnisgewinn, den die Aufgabe liefert.

Was andere anders machen

Die naheliegende Alternative sind textbasierte Agenten-Benchmarks, in denen der Agent in einer simulierten Umgebung über eine API handelt und die Bewertung den finalen Text oder einen Funktionsaufruf prüft. Der Unterschied liegt nicht im Schwierigkeitsgrad, sondern in der Beweislast. Ein textbasierter Benchmark kann korrekt aussehen, ohne dass die Aktion in einem echten Fenster funktioniert hätte. OSWorld verschiebt die Prüfung in das System selbst, was Fehler wie falsche Menüpfade, fehlende Berechtigungen oder unerwartete Dialoge sichtbar macht. Der Preis dafür ist Reproduzierbarkeit: Eine VM mit Anwendungen ist ein bewegliches Ziel, ein Textprotokoll nicht. Wer beide Ansätze kombiniert, sollte die Rollen trennen. Textbasierte Tests für schnelle Iteration, OSWorld für die Frage, ob der Agent die Oberfläche tatsächlich bedienen kann.

Lizenz, Wartung und was zu prüfen ist

Der Code steht unter Apache-2.0. Das erlaubt kommerzielle Nutzung und Änderungen, verlangt aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben und geänderte Dateien als geändert gekennzeichnet werden. Ob das für die mitgelieferten Aufgaben und den verlinkten Cache gesondert gilt, lässt sich aus dem vorliegenden Material nicht klären; das ist eine Frage für die eigene Rechtsabteilung, nicht für dieses Repository. Zur Wartung: Die letzten veröffentlichten Releases tragen die Nummern v0.1.0 und v0.1.16 aus dem Jahr 2024, während der letzte Push in den Repository-Metadaten mit 2026-08-30 angegeben ist. Zwischen Release und laufender Entwicklung liegt also eine Lücke, und die Überarbeitung zu OSWorld-Verified vom Juli 2025 wurde im Text angekündigt, ohne dass dafür ein neues Release-Tag sichtbar wäre. Wer die Ergebnisse reproduzieren will, sollte deshalb den Commit festhalten, mit dem er gearbeitet hat, und vor dem Vergleich mit veröffentlichten Zahlen klären, ob diese aus der ursprünglichen oder der überarbeiteten Fassung stammen.

Redaktionelles Fazit

Sinnvoll ist OSWorld für Teams, die einen Agenten gegen Desktop-Aufgaben mit überprüfbarem Endzustand messen wollen und dafür Rechenkapazität sowie VM-Betrieb stellen können. Wer nur schnell einen Modellvergleich braucht oder keinen KVM-fähigen Host hat, sollte zuerst die Modal-Variante mit python -m desktop_env.providers.modal.setup --os Ubuntu prüfen, bevor er VMware oder VirtualBox aufsetzt. Vor jeder Veröffentlichung von Zahlen gehört ein Blick in den Abschnitt zu OSWorld-Verified, weil sich die Benchmark-Signale geändert haben und ältere Werte nicht mehr vergleichbar sind.

Offizielle Quellen

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. xlang-ai/OSWorld on GitHub