Vom Browser zur Codebasis: Wie terminal-native Web-Agenten die Automatisierung verändern

Die meisten denken bei Web-Automatisierung zuerst an einen Agenten, der einen Browser steuert. Klicks, Eingaben, Scrollen – alles in einer langen, fortlaufenden Sitzung. Doch genau diese Idee könnte der eigentliche Flaschenhals sein.

Der Nachteil dauerhafter Browser-Sitzungen

Klassische Agenten sind eng an ihren Browser gebunden. Jede Aktion hängt von der vorherigen ab, und wenn etwas schiefläuft, bleibt nur das mühsame Debugging einer komplexen Interaktionskette. Zwischen der Entscheidungslogik und der Ausführung gibt es keine saubere Trennung.

Das führt zu echten Problemen:

• Anschwellender Zustand: Lange Sitzungen werden unübersichtlich und voller unerwarteter Sonderfälle
• Schwieriges Debugging: Teile einer Aufgabe lassen sich kaum isoliert prüfen oder wiederholen
• Keine Wiederverwendung: Jede Aufgabe wird von Grund auf neu gelöst

Webwright: Wegwerf-Browser, bleibender Code

Webwright dreht den Ansatz komplett um. Statt eine Browser-Sitzung am Leben zu halten, startet der Agent bei Bedarf frische Browser-Instanzen, sammelt Daten und verwirft sie wieder. Was bleibt, ist kein Browser-Zustand, sondern Code, Logs, Screenshots und Ergebnisse im lokalen Workspace.

Der Browser wird zum Werkzeug, das man nutzt und wieder weglegt. Das eigentliche Ergebnis ist der Code, der dieses Werkzeug verwendet.

Drei Grundprinzipien

1. Code statt primitiver Aktionen
Statt endlosen Ketten aus „Klick → Warte → Tippe → Sende“ erstellt Webwright wiederverwendbare Funktionen. Datums-Auswahl, Formularausfüllung oder Datenextraktion werden zu Schleifen und Funktionen – nicht zu aneinandergereihten Browser-Befehlen.

2. Bleibende Artefakte
Jede Aufgabe erzeugt dauerhafte Ergebnisse: Explorationsskripte, Aktions-Logs, Screenshots und schließlich ein wiederverwendbares Programm. Dieser Workspace ist der eigentliche Wertträger – prüfbar, teilbar und als Basis für künftige Automatisierungen nutzbar.

3. Minimalistische Architektur
Das System bleibt bewusst klein: Runner, Model-Endpoint und Terminal-Umgebung. Rund 1.000 Zeilen Hilfscode. Keine komplexen Multi-Agent-Systeme, sondern eine schlanke Feedback-Schleife.

So läuft die Schleife

1. Kontext senden: Der Runner übergibt Aufgabe, Workspace-Zustand und aktuelle Beobachtungen an das Modell
2. Bash-Befehl erzeugen: Das Modell antwortet mit Überlegungen und einem Shell-Befehl – meist ein Playwright-Skript
3. Beobachtungen zurückgeben: Die Umgebung führt den Befehl aus und liefert Ausgaben, Logs, Screenshots oder Fehler
4. Verfeinern und abschließen: Die Schleife wiederholt sich, bis ein finales Skript entsteht, das in einer sauberen Umgebung erneut läuft und eigene Reflexions-Checks besteht

Keine komplizierten Routing-Mechanismen. Nur Terminal, Modell und wachsender Workspace.

Die Ergebnisse

Auf realen Web-Aufgaben erreicht Webwright starke Werte:

• 60,8 % Genauigkeit auf Odysseys Long-Horizon-Benchmark – 35,1 % besser als der bisherige Stand der Technik
• 86,7 % Genauigkeit auf Online-Mind2Web über 300 Live-Aufgaben auf 136 verschiedenen Seiten
• 66,2 % Genauigkeit selbst mit kleineren Modellen wie Qwen 3.5-9B, wenn wiederverwendbare Tools bereitstehen

Sicherheit und Struktur im Terminal

Voller Terminal-Zugriff birgt Risiken. Webwright setzt gezielte Schutzmechanismen ein:

„Premature Done“-Gate: Erfolg darf erst erklärt werden, wenn ein finales Skript erzeugt, in einer frischen Umgebung erneut ausgeführt und durch Selbstreflexion geprüft wurde.

Kontext-Komprimierung: Lange Verläufe werden regelmäßig zusammengefasst, während konkrete Artefakte im Workspace erhalten bleiben.

Wiederverwendbare Tools: Gelöste Aufgaben lassen sich als parametrisierbare CLI-Tools exportieren und von anderen Agenten nutzen.

Was das für Entwickler bedeutet

Wer Automatisierungen, Scraper oder KI-gestützte Workflows baut, kann von Webwright lernen:

• Intelligenz und Ausführungsumgebung trennen
• Wegwerfbare Sitzungen nutzen, aber dauerhafte Ergebnisse bewahren
• Funktionen und Schleifen bauen statt primitive Aktionsketten
• Agenten erst Erfolg verkünden lassen, wenn sie ihre Lösung sauber wiederholen können

Das Terminal ist hier nicht nur Schnittstelle, sondern der eigentliche Arbeitsraum. Der Browser ist temporär – das Terminal bleibt.

Der größere Kontext

Web-Automatisierung wurde lange als immer komplexere Zustandsmaschine verstanden. Webwright zeigt einen anderen Weg: Der Agent soll Code schreiben statt Zustand zu manipulieren. Der Browser wird wegwerfbar, der Workspace bleibt bestehen.

Der Ansatz ist noch jung, deutet aber darauf hin, wie sich zuverlässigere, wartbare und wiederverwendbare KI-Systeme bauen lassen – nicht nur für Web-Aufgaben, sondern überall dort, wo Agenten erkunden, iterieren und lernen müssen.

Wer an Agenten-Systemen, Web-Automatisierung oder KI-gestützter Entwicklung arbeitet, sollte sich Webwright genauer ansehen. Der Code liegt auf GitHub, die Ergebnisse sind überzeugend, und die Idee ist einfach: Ein Terminal reicht.