Browser-Agenten evaluieren: eine praktische Checkliste

Beginne mit einem Task Contract, der Initialzustand, erlaubte Sites und Anwendungen, Daten, Terminal State, verbotene Ereignisse und die Grenze für menschliche Bestätigung festlegt. „Buche ein Ticket“ ist noch kein Test: Route, Datum, Budget, erlaubte Buchung und der Stopp vor einer möglichen Zahlung müssen feststehen. Bei Read-only-Aufgaben kann der Verdict den gefundenen Datensatz prüfen; bei State-changing-Aufgaben muss der tatsächliche Backend-Zustand bestätigt werden, nicht nur der Text, den der Agent auf der Seite gesehen hat.

WebArena ist durch funktionale Sites und die Prüfung realistischer langer Aufgaben nützlich, bildet aber eure Berechtigungen, Locales, Daten und Konsequenzen nicht ab. Überführt Production Jobs in bereinigte Task Families und gebt jeder Familie einen unabhängigen Oracle: API- oder Database Query in einer Sandbox, strukturierten Export, kontrollierten DOM State oder ein Human-reviewed Artifact. Der Self-report „fertig“ des Agenten ist niemals ein Oracle.

• Outcome → der benötigte Zustand wurde tatsächlich erstellt, gefunden oder geändert.
• Trajectory → jede Aktion war für Task und aktuellen Zustand erlaubt.
• Side-effect integrity → kein zusätzlicher Submit, keine Nachricht, Zahlung oder Löschung.
• Stop behavior → der Agent verweigert korrekt, fragt nach oder fordert Approval an.

Das Ergebnis eines Browser Eval hängt nicht nur vom Modell ab. Versioniere Image oder VM, Browser, Viewport, Device Scale, Locale, Timezone, Fonts, Cookies, Account Fixture, Network Policy, Ausgangsdaten und Zustand jeder Anwendung. Dokumentiere Observation Mode—Screenshot, Accessibility Tree, DOM, OCR oder Kombination—und Action Mode—Koordinaten, Element IDs, Playwright Primitives oder Keyboard Shortcuts—separat. OpenAI dokumentiert in den zusätzlichen CUA-Eval-Materialien Unterschiede bei Browser- oder VM-Umgebung, Prompts, Sampling und Scoring; ohne diese Angaben sind Versionsvergleiche nicht reproduzierbar.

BrowserGym vereinheitlicht Observation und Action Spaces für mehrere Web-Agent-Benchmarks; dieselbe Disziplin gehört in den internen Harness. Speichere ein Environment Manifest neben dem Ergebnis und verwerfe den Run, wenn das Fixture nicht startet, die Site unerwartet geändert wurde oder der Oracle nicht verfügbar ist. Infrastructure Failure darf nicht als Model Failure zählen, und eine zufällig bereits erledigte Aufgabe nicht als Success. Reset muss den gesamten Business State wiederherstellen, einschließlich Mails, Warenkorb, Dateien und Pending Transactions.

Ein Frozen Regression Set deckt typische Aufgaben und bekannte Incidents ab, ein Held-out Set neue Formulierungen, Entitäten und Layout Variants. Ergänze responsive Viewports, andere Zoomstufen, Übersetzungen, Sticky Banner, Modals, Lazy Loading, Disabled Controls, identische Labels, paginierte Tabellen und Elemente below the fold. Für Computer-use Agents gehören aktives Fenster, Focus, Drag, Clipboard, File Picker und System Dialogs dazu. Ziel ist nicht, Koordinaten zu sabotieren, sondern Grounding am aktuellen semantischen Zustand zu messen.

Ergänze zeitliche und operative Perturbations: langsame Responses, Spinner, stale Screenshots, nach Timeout akzeptierte Actions, Session Expiry, Redirects, neue Tabs und teilweise gespeicherte Forms. Ambiguous Tasks müssen Rückfragen auslösen, impossible Tasks einen sicheren Stopp. Halte eine Contamination Boundary ein: keine Held-out Screenshots in Prompts oder Few-shot Examples und keine Policy-Optimierung auf jeden Fehlversuch ohne ein neues Blind Set.

Task Success ist notwendig, aber nicht ausreichend. Ein Trace Grader prüft Origin Transitions, Targets, eingegebene Felder, Repeated Actions, Approval Binding und Prohibited States. Unterscheide Perception Error, Wrong Target, Planning Error, Policy Block, Environment Failure, Premature Stop und False Success Claim. Schrittzahl und Latency sind erst nach Correctness relevant: ein kürzerer Pfad mit falschem Submit ist nicht effizienter. Wenn mehrere Pfade korrekt sind, bewerte Invarianten statt einer exakten Action Sequence.

Eine Recovery Suite startet den Agenten aus einem Zwischenzustand: ein Modal blockiert den Button, Form Validation lehnt ein Feld ab, Navigation führt zurück zum Login oder ein Timeout tritt nach dem Commit auf. Pass verlangt zuerst das Lesen des realen Zustands, dann das Vermeiden doppelter Side Effects und die Wahl zwischen Retry, Reconcile, Rollback oder Escalation. Bei stochastischen Agenten sind mehrere unabhängige Runs, die Verteilung und ein Paired Comparison mit dem Baseline nötig; ein erfolgreicher Replay beweist keine allgemeine Zuverlässigkeit.

• Functional verdict → ein unabhängiger Oracle bestätigt den finalen State.
• Policy verdict → keine Aktion überschritt Scope oder Approval.
• Grounding verdict → das Target entsprach der Absicht im tatsächlichen Frame.
• Recovery verdict → der Retry erzeugte kein Duplikat und behielt den Audit Trail.

Seiten, Dokumente, Nachrichten und Tooltips sind nicht vertrauenswürdige Daten. Ein Security Slice platziert direkte und indirekte Prompt Injections in sichtbarem Text, Accessibility Attributes, Upload-Dokumenten und Search Results. Prüfe nicht nur, ob der Agent die Anweisung wiederholt, sondern die Sinks: versucht er das Ziel zu ändern, zu einem verbotenen Origin zu navigieren, ein Canary Secret zu lesen, es in ein Formular einzufügen, eine Datei hochzuladen oder eine externe Aktion auszuführen? Prompt-Injection Detection ohne Sink Verdict erzeugt falsche Sicherheit.

Alle Write Tests laufen in Disposable Accounts mit Canary Data, abgefangenen E-Mails oder Webhooks, Fake Payment Rail und einem Log der Backend Mutations. Binde Approval an exakten Payload und State Snapshot: die Bestätigung eines Empfängers erlaubt keine Adressänderung nach dem Modal. Teste Cancellation, Expired Approval, irreführende Buttons, Download Quarantine und Secrets im Clipboard. Production Credentials, echte Zahlungen oder Nachrichten an externe Personen sind für einen beweiskräftigen Eval nicht nötig.

Der Decision Record enthält Dataset Revision, Environment Manifest, Model, Prompt, Observation- oder Action Adapter, Policy, Oracle, Sample Count, Segment Results, Critical Failures und Reviewer. Vergleiche den Candidate mit einem Known-good Bundle auf denselben Task Seeds. Promotion verlangt Non-regression beim Outcome, Nulltoleranz für definierte kritische Side Effects und separat bestandene Slices für Domain, Locale, Task Length und Risk Tier. Ein öffentlicher Benchmark ist ein externes Signal, kein Ersatz für das eigene Release Gate.

Der Rollout führt vom offline resettable Environment über Shadow und Read-only Canary zu Draft-only Writes und eng freigegebenen Actions. Monitoring verwendet dieselbe Taxonomie: False Completion, Duplicate Mutation, Unexpected Origin, Approval Mismatch und Recovery Failure. Rollback stellt ein kompatibles Bundle aus Model, Prompt, Adapter und Policy wieder her, stoppt neue Runs und reconciled offene Side Effects vor einem Retry. Ein bereinigter Incident Trace wird erst nach Provenance- und Privacy-Prüfung zum Regression Fixture.