Computer-Use-Agents: Die 30 Prozentpunkte, die Ihren Stack entscheiden

Was ComponentBench misst

ComponentBench, veröffentlicht am 18. August 2026 und akzeptiert auf der COLM 2026, bewertet Ausfälle auf Komponentenebene in Computer-Use-Agents. Die Suite umfasst 97 kanonische UI-Komponenten, die in 2.910 programmatisch verifizierten Tasks instanziiert sind.

Die technische Positionierung ist präzise. Bestehende Benchmarks teilen sich in langfristige Workflow-Tests und atomare GUI-Grounding-Tests auf.

Diese Aufteilung lässt die mittlere Schicht unabgedeckt. Komponentenzentrierte Interaktionen sind kurz zu diagnostizieren und reich genug, um die Last moderner Oberflächen abzubilden. Ein typisches Beispiel ist das Umschalten einer Schaltflächengruppe.

Jeder Task wird mit bereinigten menschlichen Referenztrajektorien geliefert, sodass Erfolg und Effizienz in derselben Ausführung gemessen werden können. Der Benchmark fügt außerdem eine Pipeline hinzu, die die strukturelle Schwierigkeit nach der Implementierung verifiziert. Das Ergebnis ist eine doppelte Metrik: Ein Task kann abgeschlossen werden, jedoch mit weit mehr Schritten als ein Mensch benötigen würde. Die Trennung von Erfolg und Effizienz verhindert, dass ein langsamer Agent fälschlicherweise als robust eingestuft wird.

Der Mechanismus: Observation- und Action-Space

Der entscheidende Befund ergibt sich aus der Harness-Konfiguration. Die Autoren halten das Modell konstant und variieren ausschließlich den Observation- und Action-Space.

Die Task-Success-Rate schwankt für dasselbe Modell um mehr als 30 Prozentpunkte. Der deutlichste Fall betrifft GPT-5 mini. Mit Accessibility-Tree-Beobachtungen erreicht es eine Erfolgsrate von 83,1 %.

Mit reiner Koordinatensteuerung im Pixel-Modus fällt dasselbe Modell auf 48,9 %, laut dem auf arXiv veröffentlichten Paper^[1]. Die Evaluation umfasst sieben Modelle und vier Observation- und Action-Spaces.

Die ingenieurtechnische Lesart ist direkt. Die Leistung eines Agents hängt von der Wahrnehmungsschicht genauso stark ab wie vom zugrunde liegenden Modell. Ein Downgrade des Inputs verwandelt ein produktionstaugliches System in ein unzuverlässiges. Der Mechanismus ist einfach: Der Accessibility-Tree liefert dem Modell eine strukturierte Beschreibung der UI-Elemente. Die Pixel-Steuerung zwingt das Modell hingegen, dieselben Elemente aus rohen Koordinaten abzuleiten. Die Wahrnehmungslast verlagert sich vollständig auf das Modell, und die Fehlerrate steigt.

Die Grundbedingung

Die strukturelle Bedingung, die diese Ergebnisse verbindet, ist klar. Die dem Modell zugeschriebene Genauigkeit ist tatsächlich die Genauigkeit des gesamten Wahrnehmungs- und Aktions-Stacks.

Viele Procurement-Teams bewerten Agents, indem sie auf den Modellnamen schauen. Dieser Ansatz ignoriert die Variable, die die Ergebnisse um 30 Punkte verschiebt. Zwei Deployments desselben Modells divergieren, wenn sich die Beobachtungsschicht unterscheidet.

Die praktische Konsequenz ist messbar. Ein Vendor-Benchmark, der eine einzige Zahl ausweist, verbirgt diese Abhängigkeit. Eine Zahl ohne deklarierten Observation-Space hat begrenzten Informationswert. Ein Vendor kann legitim 83,1 % ausweisen und sich dabei auf den Accessibility-Tree beziehen. Dasselbe Modell produziert auf Ihrem Pixel-Control-Stack 48,9 %. Keine der beiden Zahlen ist falsch. Nur eine beschreibt Ihr Deployment.

Räumliche Manipulation bleibt ein dokumentierter Schwachpunkt. Operationen, die für einen Menschen trivial sind, bereiten aktuellen Agents weiterhin Schwierigkeiten.

Die Lücke konzentriert sich dort, wo die Oberfläche eine feine Koordination zwischen Wahrnehmung und Aktion erfordert. Das Modell hält in der Abstraktion stand; seine Übersetzung in präzise Gesten versagt.

Effizienz: Die versteckten Kosten des 3,7-fachen Faktors

Die Task-Erfolgsrate erzählt die halbe Geschichte. Die andere Hälfte ist die Interaktionseffizienz.

Die schnellste Konfiguration benötigt das 3,7-Fache der menschlichen Referenztrajektorie. Dieser Multiplikator wirkt sich direkt auf die Betriebskosten aus. Jeder zusätzliche Schritt verbraucht Token, Latenz und Inferenzbudget.

Für einen CFO ändert sich die Art der Rechnung. Ein Agent, der einen Task zum 3,7-fachen Kostenaufwand eines menschlichen Operators abschließt, verschiebt die Break-even-Schwelle.

Automatisierung wird erst ab einem bestimmten Volumen wirtschaftlich. Dieses Volumen ist vor dem Deployment messbar. Ein Pilotprojekt, das diesen Multiplikator ignoriert, produziert ein fragiles Business-Case. Und das 3,7-Fache ist die beste Konfiguration, nicht der Durchschnitt. Ärmere Observation-Spaces verbrauchen noch mehr Schritte. Die Betriebskosten skalieren mit der Eingabewahl – genau wie die Genauigkeit.

Was sich für den Enterprise-Stack ändert

Die Ergebnisse schreiben die Evaluierungs-Checkliste neu. Die Modellwahl tritt in den Hintergrund gegenüber der Wahl des Observation-Space.

Ein Team, das aus Portabilitätsgründen auf reine Koordinatensteuerung setzt, zahlt einen Genauigkeitspreis. Ein Team, das den Accessibility-Tree exponiert, erzielt bessere Ergebnisse – auf Kosten einer Abhängigkeit von der Rendering-Infrastruktur.

Dies ist ein klassischer architektonischer Lock-in-Trade-off. Die Entscheidung sollte als explizite technische Schuld dokumentiert werden.

Wer den einfacheren Input für Flexibilität wählt, muss den Zuverlässigkeitsrückgang einplanen. Wer den reicheren Input wählt, muss Fault-Tolerance gegenüber Interface-Änderungen planen.

Der Zusammenhang mit Multi-Agent-Systemen

Die Erkenntnisse von ComponentBench gehen über einen einzelnen Agent hinaus. In einer Multi-Agent-Pipeline wird der Output einer Komponente zum Input der nächsten.

Eine Erfolgsrate von 49 % auf Komponentenebene pflanzt sich entlang der Kette fort. Drei aufeinanderfolgende Schritte mit unvollkommener Zuverlässigkeit erzeugen ein zusammengesetztes Ergebnis, das weit fragiler ist als jeder einzelne Schritt.

Die Rechnung ist einfach zu überprüfen. Bei einer Zuverlässigkeit von 0,49 pro Schritt sinken drei unabhängige Schritte unter 12 % Gesamterfolg. Das erklärt, warum Demos funktionieren und Deployments scheitern. Eine Demo zeigt einen isolierten Schritt unter günstigen Bedingungen. Ein Deployment verkettet mehrere Schritte und multipliziert deren Fehlerquoten.

Das ist die Mathematik des Kaskadenausfalls. Die Verteidigung bleibt architektonisch. Jeder Schritt erfordert eine unabhängige Validierung und einen expliziten Circuit-Breaker.

Drei Fragen für das Enterprise-AI-Team

Die operative Bewertung reduziert sich auf drei Fragen für Ihr Enterprise-AI-Team.

1. Welcher Observation-Space versorgt den Agent in der Produktion, und welche gemessene Erfolgsrate erzielt er in Ihrer Domäne?
2. Wie hoch ist der Zeitfaktor im Vergleich zum menschlichen Operator, und ab welchem Volumen erreicht die Automatisierung den Break-even?
3. Wie reagiert der Agent auf einen Wechsel der Komponentenbibliothek, und welche Testabdeckung schützt die Pipeline?

Die Antwort auf die erste Frage bestimmt die gesamte Strategie. Eine Erfolgsrate von 83 % mit Accessibility-Tree und eine von 49 % mit Pixel-Control beschreiben zwei verschiedene Produkte, die auf demselben Modell aufgebaut sind.

Diese Fragen verlagern den Fokus vom Vendor-Benchmark zur internen Messung. Die Zahl, die zählt, ist jene, die auf Ihrem Stack mit Ihrer Oberfläche erhoben wird.

Build/Buy-Entscheidungen für den nächsten Planungszyklus

Die Schlussfolgerung für CTOs und Heads of Engineering ist operativ. ComponentBench ist eine diagnostische Methodik zum Übernehmen, kein Vendor-Produkt zum Evaluieren.

Code und Daten sind öffentlich zugänglich. Ein Engineering-Team kann die Pipeline auf dem eigenen Komponentenbestand replizieren.

Das verwandelt die Agent-Evaluierung von einer Marketing-Übung in eine wiederholbare Messung. Für das Technology Procurement Committee ist das Signal eindeutig.

Jeder Vertrag, der Agenten-Genauigkeit zusichert, muss an den getesteten Observation-Space gebunden werden. Eine Klausel, die den Erfolg auf Basis des Accessibility-Tree festschreibt, verliert an Wert, wenn die Produktion auf Pixel-Control läuft.

Der nächste Planungszyklus erfordert eine explizite Entscheidung über die Wahrnehmungsschicht. Sie aufzuschieben bedeutet, eine Lücke von 30 Prozentpunkten als latentes Risiko im Automatisierungsbudget zu akzeptieren.