Computer-Use-Agenten: Warum eine erfolgreiche Demo dennoch ein unzuverlässiges System sein kann

Computer-Use-Agenten können mittlerweile klicken, tippen, im Web surfen, Dateien bearbeiten, Desktop-Anwendungen bedienen und beeindruckende mehrstufige Aufgaben erledigen. Das macht erfolgreiche Demos leicht verständlich – und verleitet dazu, sie überzuinterpretieren. Ein einzelner abgeschlossener Workflow zeigt lediglich, dass der Agent unter genau diesen Bedingungen erfolgreich sein kann. Er zeigt nicht, wie oft er erfolgreich ist, wie er sich bei Veränderungen der Umgebung verhält, ob er das Ergebnis überprüft oder wie sicher er agiert, wenn das Ziel mehrdeutig wird.

Warum die Demo der denkbar einfachste Zuverlässigkeitstest ist

Eine Demo zeigt normalerweise einen einzigen Pfad, der funktioniert hat. Die Umgebung ist bekannt, die Aufgabe im Voraus ausgewählt, der Operator kann nach einem Fehlschlag neu starten, und das Publikum sieht den erfolgreichen Ablauf. Produktivsysteme sind stattdessen mit einer Verteilung konfrontiert: unterschiedliche Seiten, Netzwerkbedingungen, Kontostatus, Pop-ups, Latenzen, UI-Änderungen, verborgene Zustände, Berechtigungen, Unterbrechungen und Nutzer, die Ziele unvollständig beschreiben.

Dieser Unterschied ist entscheidend, da Computer-Use-Agenten über Schnittstellen agieren, die für Menschen und nicht für deterministische APIs entwickelt wurden. Ihre Handlungsschleife hängt von Wahrnehmung, Zustandsinterpretation, Planung, dem Timing von Interaktionen und Reaktionen der Umgebung ab. Kleinste Änderungen können den Ablauf verändern, selbst wenn das Ziel des Nutzers unverändert bleibt.

Die WAREX-Forschungsarbeit von Microsoft Research verdeutlicht das Problem: Benchmark-Agenten, die in kontrollierten Umgebungen leistungsfähig wirken, büßen erheblich an Erfolgsquote ein, sobald realistische Web-Instabilitäten hinzukommen. Der Fehler liegt nicht zwingend darin, dass „das Modell weniger intelligent wurde“. Die Umgebung hat lediglich aufgehört, deterministisch zu sein.

Leistungsfähigkeit, Erfolgsquote, Zuverlässigkeit und Sicherheit sind unterschiedliche Aussagen

Die Zuverlässigkeitsleiter für Computer-Use

Ein sinnvoller Ansatz zur Evaluierung von Computer-Use-Systemen besteht darin, sich von punktueller Leistungsfähigkeit hin zu schrittweise anspruchsvolleren Zuverlässigkeitseigenschaften zu bewegen. Höhere Stufen setzen die unteren Stufen voraus, ergeben sich jedoch nicht automatisch aus ihnen.

Stufe 1 – Leistungsfähigkeit: Die Demo-Frage

Die Leistungsfähigkeit fragt, ob ein Agent die Aufgabe überhaupt ausführen kann. Das ist wertvoll. Computer-Use-Systeme haben sich rasant weiterentwickelt, und moderne Agenten können Workflows bewältigen, die ältere Systeme nicht verlässlich ausführen konnten.

Doch Leistungsfähigkeit ist ein schwaches Kriterium für den Produktiveinsatz. Ein einzelner erfolgreicher Durchlauf verrät Ihnen nicht, ob der Agent in 95 % oder in 30 % der Fälle erfolgreich ist, ob Fehlschläge harmlos oder destruktiv sind oder ob der Erfolg lediglich von einem glücklichen Seitenzustand abhing.

Stufe 2 – Wiederholbarkeit: Bleibt dieselbe Aufgabe gelöst?

Trajektorien der Computernutzung sind stochastisch. Modellausgaben variieren, Seiten laden mit unterschiedlichen Geschwindigkeiten, visuelle Zustände ändern sich und lange Workflows schaffen viele Verzweigungsmöglichkeiten. Ein Produktionstest sollte daher dieselbe Aufgabe mehrfach ausführen, anstatt einen einzelnen erfolgreichen Durchlauf als repräsentativ zu betrachten.

Messen Sie nicht nur die durchschnittliche Erfolgsquote, sondern auch die Verteilung der Fehlermuster: falscher Klick, vorzeitiger Abbruch, verpasste Bestätigung, fehlerhaftes Feld, doppelte Aktion, Navigationsschleife, Annahme veralteter Zustände und falsche Erfolgsmeldung.

Stufe 3 — Robustheit gegenüber der Umgebung: Was passiert, wenn sich das Web wie das Web verhält?

Reale Websites sind keine Benchmark-Prüfstände. Anfragen schlagen fehl, Elemente laden verzögert, Sitzungen laufen ab, Seiten verändern sich, Cookie-Banner tauchen auf, Server geben Fehler zurück und Netzwerkbedingungen schwanken.

WAREX evaluiert diese Diskrepanz, indem es realistische Web-Unzuverlässigkeiten in bestehende Benchmark-Umgebungen einstreut, und berichtet von erheblichen Einbrüchen beim Aufgabenerfolg. Dies ist eine entscheidende Erkenntnis für den Produktiveinsatz: Ein Benchmark kann die Aufgabenkompetenz messen und gleichzeitig die Fähigkeit zur Wiederherstellung nach Umgebungsinstabilitäten unterschätzen.

Stufe 4 — Langzeitorchestrierung: Erfolg verändert sich, wenn die Aufgabe zu echter Arbeit wird

Kurze Aufgaben verbergen eine Klasse von Fehlern, die erst nach Dutzenden oder Hunderten von Aktionen auftreten: vergessene Einschränkungen, doppelte Arbeit, vorzeitige Fertigstellung, verpasste Zustandsänderungen, Inkonsistenzen über Anwendungen hinweg und kumulierte kleine Fehler.

OSWorld 2.0 wurde speziell für langfristige Workflows aus der Praxis konzipiert. Menschliche Nutzer benötigen für die Aufgaben im Median etwa 1,6 Stunden, und es sind deutlich mehr Tool-Aufrufe erforderlich als bei früheren Computernutzungs-Benchmarks. Gemessen an der primären Abschlussmetrik sind selbst die stärksten evaluierten Systeme noch weit von einer lückenlosen Aufgabenzuverlässigkeit entfernt.

WeaveBench kommt aus einer anderen Perspektive zu einem ähnlichen Ergebnis. Es evaluiert hybride Workflows aus GUI, CLI und Code und berichtet, dass das am besten bewertete Modell-Runtime-Paar nur 41,2 % der Aufgaben besteht. Das wichtige Ergebnis ist nicht eine einzelne Zahl auf der Bestenliste; es ist die Tatsache, dass eine realistische schnittstellenübergreifende Orchestrierung Fehler aufdeckt, die bei einfacheren Einzel-Schnittstellen-Aufgaben verborgen bleiben.

Stufe 5 — Zustandsbewusstsein: Die Umgebung kann sich unter dem Plan verändern

Länger laufende Aufgaben hängen oft von versteckten oder sich verändernden Zuständen ab: Eine E-Mail trifft ein, ein Kalender ändert sich, ein Formular wird abgeschickt, ein Hintergrundprozess wird beendet, eine Browser-Sitzung läuft ab, ein Benutzer ändert eine Datei oder ein externes System ändert seine Verfügbarkeit.

SentinelBench von Microsoft argumentiert, dass viele länger laufende Aufgaben keineswegs durch kontinuierliches Handeln gelöst werden sollten. Das korrekte Verhalten kann darin bestehen, zu überwachen, auf ein externes Ereignis zu warten und erst bei einer Zustandsänderung zu agieren. Dies ist eine andere Fähigkeit als schneller zu klicken oder mehr Schritte zu planen.

Ein zuverlässiger Agent zur Computernutzung muss daher zwischen „jetzt ausführbar“, „wartet auf Zustand“, „Zustand geändert“ und „Annahme ungültig“ unterscheiden können.

Stufe 6 — Ergebnisüberprüfung: Hat die Aktion tatsächlich funktioniert?

Ein Agent kann eine scheinbar korrekte Abfolge ausführen und dennoch an der Aufgabe scheitern. Ein Klick auf eine Schaltfläche wird möglicherweise nicht registriert. Ein Formular lehnt eine unsichtbare Validierung ab. Eine Datei wird im falschen Verzeichnis gespeichert. Ein Kauf bleibt unbestätigt. Eine Website zeigt möglicherweise eine nach Erfolg aussehende Ansicht, während der zugrunde liegende Vorgang fehlgeschlagen ist.

OpenAIs aktuelle Leitlinien zur Computernutzung empfehlen ausdrücklich, den Ablauf einzugrenzen und zu verifizieren, anstatt sich ausschließlich auf die finale Antwort des Modells zu verlassen. Die Forschung von Microsoft Research zu Verifizierern für die Computernutzung kommt bei Evaluationen zum selben Schluss: Prozess und Ergebnis müssen getrennt voneinander bewertet werden.

Die Forschung zum Universal Verifier berichtet, dass frühere Verifizierer-Setups hohe Falsch-Positiv-Raten erzeugen können, während ein fundierteres Bewertungsraster und eine explizite Trennung von Prozess, Ergebnis, kontrollierbaren Fehlern und unkontrollierbaren Fehlern die Übereinstimmung mit menschlichen Bewertungen erheblich verbessern.

Stufe 7 — Sicherer Umgang mit Zielen: Der Agent muss wissen, wann er nicht weitermachen darf

Computer-Use-Agenten sind darauf optimiert, Ziele zu erreichen, aber Zielbeharrlichkeit kann selbst zu einer Fehlerursache werden. Eine mehrdeutige Anfrage, eine unmögliche Bedingung, eine widersprüchliche Anweisung, eine verdächtige Webseite oder eine veränderte Umgebung erfordern möglicherweise eine Klarstellung oder das Abbrechen statt weiteren Handelns.

Der BLIND-ACT-Benchmark untersucht dieses Problem als blinde Zielgerichtetheit (Blind Goal-Directedness). Bei den in dieser Arbeit evaluierten Systemen verfolgten Agenten Aufgaben häufig weiter, trotz Mehrdeutigkeit, Undurchführbarkeit, widersprüchlichem Kontext oder anderen Gründen zum Innehalten. Die Autoren identifizieren Muster wie den Execution-First-Bias und den Vorrang von Benutzeranfragen (Request Primacy).

Diese Fehlerklasse ist von Bedeutung, da ein hochgradig fähiger Agent eine schlechte Situation schneller noch verschlimmern kann. Zuverlässigkeit beinhaltet daher auch Richtlinien dafür, wann nicht gehandelt werden darf.

Der Stresstest vom Prototyp zur Produktion

Bevor Sie einen Computer-Use-Workflow bereitstellen, nehmen Sie die erfolgreiche Demo und entfernen Sie systematisch die Annahmen, die sie einfach gemacht haben.

Benchmark-Erfolg hat eine Gültigkeitsgrenze

Ein Benchmark-Ergebnis ist eine bedingte Aussage. Es gilt für ein bestimmtes Modell, einen bestimmten Harness, eine bestimmte Umgebung, ein bestimmtes Aufgabenset, einen Beurteiler, eine Toolschnittstelle, ein Schrittbudget, eine Retry-Richtlinie, ein Datum und eine Evaluierungsmethode.

Der Wert wird irreführend, wenn diese Bedingungen aus der Aussage verschwinden. „Agent X erzielt 80 %“ ist schwächer als „Agent X hat auf Benchmark Y in Umgebung Z mit Beurteiler J und Schrittbudget N 80 % erzielt“. Der zweite Satz wahrt die Grenze, die Ihnen verrät, ob die Zahl auf Ihre Anwendung übertragbar ist.

Prozess- und Ergebnis-Erfolg müssen getrennt bewertet werden

WeaveBench berichtet, dass eine reine Ergebnisbewertung die Computer-Use-Leistung erheblich überschätzen kann, da ein Agent ein scheinbar erfolgreiches Artefakt über eine Abkürzung oder fabrizierte Beweise erzeugen kann. Der Prüfer muss die Trajektorie und die Zwischenergebnisse inspizieren, nicht bloß die finale Behauptung.

Produktionszuverlässigkeit ist eine Verteilung, keine einzelne Erfolgsquote

Eine aussagekräftige Produktionsevaluierung erfasst die Dimensionen, die in Ihrer Umgebung tatsächlich variieren. Bei einem Browser-Workflow können dies Kontoalter, Sprache/Region, Viewport, Seitenversion, Netzwerkqualität, Authentifizierungsstatus, bestehender Warenkorbinhalt, Cookies, Pop-ups, Benutzerberechtigungen und die Frage sein, ob ein Mensch den Durchlauf unterbricht.

Zuverlässigkeit erfordert ein Fehlerbudget, keine Perfektion

Kein Produktivsystem ist vollkommen zuverlässig. Die entscheidende technische Frage ist, welche Fehler akzeptabel, erkennbar und behebbar sind. Ein fehlgeschlagener Versuch, einen lokalen Ordner zu sortieren, ist nicht gleichbedeutend damit, die falsche E-Mail zu senden, das falsche Produkt zu kaufen oder eine Kontoeinstellung zu ändern.

Klassifizieren Sie Aktionen nach Tragweite und Reversibilität. Reversible Aktionen mit geringer Auswirkung vertragen mehr Autonomie. Weitreichende, extern sichtbare oder schwer rückgängig zu machende Aktionen erfordern eine stärkere Bestätigung, Zustandsüberprüfung, Autorisierung und Kontrollen nach der Ausführung.

Eine praktische Zuverlässigkeitsmatrix für die Computernutzung

Was bei einem Fehler bei der Computernutzung protokolliert werden sollte

• Ziel des Benutzers und explizite Einschränkungen.
• Modell- und Testumgebungs-Version (Harness).
• Umgebungs- und Anwendungsversionen.
• Für den Fehler relevante Screenshots oder strukturierte Beobachtungen.
• Durchgeführte Aktionen mit Zeitstempeln.
• Tool-, Klick-, Tastatur- und Navigationsergebnisse.
• Zustandsübergänge und Wartezeiten.
• Genehmigungs-, Verweigerungs- oder Übergabe-Ereignisse (Handoffs).
• Externe Fehler und Netzwerkausfälle.
• Abschließender beobachtbarer Umgebungszustand.
• Das vom Agenten gemeldete Ergebnis.
• Prüfergebnis (Verifier) und ob der Fehler durch den Agenten kontrollierbar war.

Der entscheidende Vergleich findet zwischen dem gemeldeten Erfolg und dem beobachtbaren Erfolg statt. Ein System, das diese beiden nicht unterscheiden kann, wird in der Produktion unweigerlich falsch-positive Ergebnisse anhäufen.

Sicherheit ist ein Teil der Zuverlässigkeit für computergestützte Agenten

Computer-Use-Agenten lesen nicht nur nicht vertrauenswürdige Inhalte; sie können nach dem Lesen auch handeln. Dadurch werden Prompt Injections, bösartige Seiteninhalte und Phishing zu Risiken im Ausführungspfad.

Die aktuellen Computer-Use-Richtlinien von OpenAI empfehlen, die Umgebung zu isolieren, Websites und Aktionen per Positivliste (Allowlist) freizugeben, Bildschirminhalte als nicht vertrauenswürdig zu behandeln, folgenreiche Aktionen zu bestätigen, den Ausführungsrahmen einzugrenzen und das tatsächliche Ergebnis zu überprüfen. Der ChatGPT-Agent verwendet für sensible Kontexte gleichermaßen Bestätigungen, Prompt-Injection-Überwachung und überwachte Modi.

Das Architekturprinzip geht über einen einzelnen Anbieter hinaus: Von dem Agenten beobachtete Inhalte dürfen die Berechtigungen des Benutzers nicht neu definieren. Eine Webseite kann Daten bereitstellen. Sie kann jedoch keine Erlaubnis erteilen, Daten an anderer Stelle zu senden, etwas zu kaufen, Zugangsdaten zu ändern oder Aufgabengrenzen zu überschreiten.

Was würde diese Einschätzung ändern?

Die Zuverlässigkeitslücke würde sich verringern, wenn Computer-Use-Modelle über repräsentative Produktionsverteilungen hinweg robust gegenüber langen Zeithorizonten, dynamischen Zuständen, UI-Variationen, Umgebungsfehlern und mehrdeutigen Zielen würden. Bessere native Zustands-APIs, standardisierte maschinenlesbare Schnittstellen und eine stärkere Verifier-Infrastruktur könnten zudem das Ausmaß der erforderlichen fehleranfälligen GUI-Interaktionen reduzieren.

Der Bereitstellungsschwellenwert verschiebt sich ebenfalls mit den Konsequenzen einer Aufgabe. Eine Erfolgsquote von 70 % kann für eine überwachte Rechercheaufgabe mit geringem Risiko nützlich und für einen autonomen finanziellen oder destruktiven Workflow inakzeptabel sein. Zuverlässigkeit muss daher an den Kosten der jeweiligen Fehlerklasse gemessen werden und nicht an einem universellen Schwellenwert für die Erfolgsquote.

Grenzen und Einschränkungen

Die zitierten Benchmarks evaluieren unterschiedliche Umgebungen und sollten nicht miteinander verglichen werden, als würden sie dasselbe messen. WAREX testet die Unzuverlässigkeit im Web; WeaveBench zielt auf hybride, langfristige Workflows ab; OSWorld 2.0 konzentriert sich auf realistische lange Workflows; BLIND-ACT legt den Schwerpunkt auf den Umgang mit Zielen bei Mehrdeutigkeit und Nicht-Machbarkeit.

Benchmark-Ergebnisse altern zudem schnell. Verbesserungen an Modellen, Testumgebungen und Verifiern können die Bewertungen innerhalb weniger Monate erheblich verändern. Die bleibende Erkenntnis liegt daher in der Evaluierungsmethode: Bedingungen variieren, Prozess vom Ergebnis trennen, externen Zustand überprüfen und den Rahmen jeder Leistungsbehauptung wahren.

Fazit

Computer-Use-Agenten sind bereits leistungsfähig genug, um nützlich zu sein. Genau deshalb hat sich die Frage der Evaluierung geändert. Die Herausforderung besteht nicht mehr nur darin, ob ein Agent einen Workflow durchklicken kann. Sie besteht darin, ob das System verlässlich bleibt, wenn die sauberen Demobedingungen wegfallen.

Betrachten Sie einen erfolgreichen Durchlauf als Beleg für die prinzipielle Fähigkeit. Testen Sie anschließend Wiederholbarkeit, Robustheit gegenüber Umgebungsbedingungen, Long-Horizon-Steuerung, Zustandserkennung, Ergebnisüberprüfung und den sicheren Umgang mit Zielen. Ein produktionsreifer Computer-Use-Agent ist nicht derjenige, der die Demo abschließen kann. Es ist derjenige, dessen Fehlergrenzen bekannt, gemessen und beherrscht sind.

FAQ

Glossar

Primärquellen und weiterführende Literatur