OSWorld: Desktop AI-Agenten bewältigen 12 % der Aufgaben, während Menschen 72 % lösen

Gestern habe ich WebArena gelesen, das autonome Web-Agenten bei einer Erfolgsquote von etwa 14 % gegenüber einem menschlichen Benchmark von 78 % einordnet. OSWorld (Xie et al., NeurIPS 2024) stellt dieselbe Frage für den gesamten Desktop: Ubuntu, Windows, macOS, reale GUI-Anwendungen. Die Antwort ist, wenn überhaupt, noch ernüchternder – und das Fehlermuster ist eigenwillig genug, um für sich genommen interessant zu sein.

Die Studie

OSWorld erstellt einen Benchmark aus 369 Aufgaben, die in realen Desktop-Anwendungen verankert sind: LibreOffice, Chrome, VS Code, GIMP, Thunderbird, VLC sowie Workflows über mehrere Anwendungen hinweg. Jede Aufgabe ist mit einem programmatischen Evaluierungsskript verknüpft, das den tatsächlichen Systemzustand nach der Ausführung prüft – keine String-Matching-Heuristiken, kein LLM-als-Richter. Das Setup nutzt virtuelle Maschinen, damit Aufgaben in einem reproduzierbaren Zustand starten, und deckt alle drei großen Betriebssysteme ab.

Die Autoren testen eine Reihe von Frontier-Modellen – GPT-4V, Gemini-Pro-Vision, Claude-3 Opus, Mixtral, CogAgent – über vier Eingabekonfigurationen hinweg: nur Screenshot, nur Accessibility-Baum, Screenshot plus Accessibility-Baum und Set-of-Marks (SoM, bei dem interaktive Elemente mit numerischen Labels überlagert werden, bevor das Modell agiert).

Kernideen

• Menschen erreichen bei ihnen unbekannten Aufgaben eine Erfolgsquote von 72,36 %. Das beste Modell zum Zeitpunkt der Einreichung erreicht 12,24 %. Die Lücke beträgt etwa 60 Prozentpunkte.
• Die Leistung bei reiner Screenshot-Eingabe liegt für Top-Modelle (GPT-4V, Gemini-Pro-Vision) bei etwa 5,26 % bis 5,80 % – was bedeutet, dass das Hinzufügen von strukturiertem Kontext den Erfolg zwar etwa verdoppelt, aber immer noch eine Fehlerrate von 87 % hinterlässt.
• Workflow-Aufgaben über mehrere Anwendungen hinweg sind die schwierigste Kategorie mit einer Obergrenze von 6,57 %, verglichen mit OS/CLI-Aufgaben, bei denen textbasierte Schnittstellen die Erdung erleichtern.
• Accessibility-Bäume und Set-of-Marks helfen, aber ihr Nutzen ist modellabhängig: Die Autoren berichten, dass sie auch Verwirrung stiften können, indem sie das Modell mit irrelevanter Struktur überfordern.
• Die Fortschritte nach der Veröffentlichung waren rasant – Agent S (GPT-4o, hierarchisches Gedächtnis) erreichte 20,58 %; das RL-basierte ARPO steigerte sich auf 29,9 %; Agent S3 (Simular AI, 2025) beansprucht 62,6 % im 100-Schritte-Szenario und nähert sich damit der menschlichen Parität an. Die meisten dieser Gewinne stammen jedoch von besseren Erdungsmodellen und RL-Feintuning, nicht von den Basis-LLMs, die OSWorld ursprünglich getestet hat.
• Fehleranalyse von 550 Fehlversuchen: Über 75 % sind Ungenauigkeiten beim Mausklick – der Agent schlussfolgert korrekt, klickt aber auf das falsche Pixel. Dies ist kein Versagen der Logik, sondern ein Versagen der visuomotorischen Erdung.

Was Bestand hat – und was nicht

Das Design des Benchmarks ist wirklich rigoros. Die ausführungsbasierte Evaluierung auf echten VMs mit 134 verschiedenen Evaluierungsskripten eliminiert die schwammigen Ermessensentscheidungen, die viele Agenten-Benchmarks plagen. Das ist ein bedeutender methodischer Beitrag und der Grund, warum die Zahl (12,24 %) glaubwürdig ist.

Die schwierigere Frage ist, was 12,24 % tatsächlich messen. Die Aufgabenverteilung ist stark auf GUI-lastige Anwendungen ausgerichtet, bei denen pixelgenaues Klicken enorm wichtig ist. Ein Beancount-Agent, der vollständig im CLI läuft oder Textdateien ausgibt, würde bei diesem Benchmark wahrscheinlich viel besser abschneiden als ein Agent, der eine Tabellenformatierung in LibreOffice vornimmt. Die Schlagzeile bündelt sehr unterschiedliche kognitive Anforderungen – räumliche Motorik, mehrstufige Planung, Domänenwissen – und die Reduzierung auf die Aussage „Agenten können keine Computer bedienen“ ist zu vereinfacht.

Die Erkenntnis, dass „Set-of-Marks einige Modelle irreführen kann“, ist interessant, aber wenig erforscht. Das Papier stellt die Varianz fest, ohne vollständig zu erklären, welche Arten von Aufgaben oder Modellen davon profitieren oder behindert werden. Dies scheint die wichtigste Frage für Praktiker zu sein, die Agenten-UIs entwerfen, wird aber nur in einem Absatz abgehandelt.

Ich bin auch skeptisch, wie gut die Stichprobe von 369 Aufgaben den „Long Tail“ realer Workflows abdeckt. Die Aufgaben wurden von Forschern kuratiert, die zwangsläufig zu Aufgaben neigen, die verifizierbar sind. Wirklich mehrdeutige Buchhaltungsaufgaben aus der Praxis – „Bereinige diese inkonsistenten Händlernamen“ – sind programmatisch schwer zu evaluieren und wahrscheinlich unterrepräsentiert.

Warum dies für Finance-KI wichtig ist

Die Erkenntnis, dass 75 % der Fehler Erdungsfehler sind, ist für Beancount-Agenten direkt relevant, obwohl Beancount auf der Textebene agiert. Das tiefere Muster – Agenten planen korrekt, führen aber fehlerhaft aus – lässt sich auf Ledger-Rückschreibe-Fehler übertragen, bei denen ein Agent die richtige Transaktion generiert, sie aber auf das falsche Konto oder mit einem Zahlendreher im Datum schreibt. In beiden Fällen ist der Engpass die präzise Ausführung, nicht das strategische Denken.

Die Performance bei Workflows über mehrere Apps hinweg (6,57 %) ist der Wert, den ich für Bean Labs am ernüchterndsten finde. Reale Buchhaltungsworkflows umfassen fast immer mehrere Anwendungen: einen Bank-CSV-Export, eine Beancount-Datei, eine Abgleich-Tabelle, einen PDF-Beleg. Wenn GUI-Agenten selbst bei kuratierten Aufgaben katastrophale Schwierigkeiten mit der Koordination zwischen Apps haben, steht ein Beancount-Agent, der Importe, Ledger-Bearbeitungen und die Berichterstellung orchestrieren muss, vor einer strukturell ähnlichen Herausforderung – selbst in einem CLI-Kontext, in dem kein Pixel-Klicken erforderlich ist.

Die gute Nachricht aus der Entwicklung nach der Veröffentlichung (Agent S3 mit 62,6 %) ist, dass dies keine fundamentalen Barrieren sind. Sie sind mit besseren Erdungsmodellen und RL-Feintuning lösbar. Dieser Fortschritt erforderte jedoch 18 Monate und erhebliche Rechenleistung für das RL-Training, was nicht die standardmäßige Fähigkeitsbasis ist, die ein Beancount-Agent von einem einfachen Prompt-basierten Frontier-Modell erwarten kann.

Was man als Nächstes lesen sollte

• AndroidWorld (Rawles et al., arXiv:2405.14573) – erweitert OSWorld auf Android-Geräte mit dynamisch parametrierten Aufgaben, relevant für mobile Beancount-Schnittstellen.
• WindowsAgentArena (Bonatti et al., arXiv:2409.08264, ICLR 2025) – passt OSWorld auf Windows mit über 150 Aufgaben an; bestätigt unabhängig, dass die Lücke über Betriebssysteme hinweg bestehen bleibt.
• Agent S2 (Agashe et al., arXiv:2504.00906) – kompositionelle Generalisten-Spezialisten-Architektur, die den Stand der Technik deutlich vorantreibt; es lohnt sich, die Architektur zu verstehen, bevor man einen mehrstufigen Beancount-Planer entwirft.