Was ist Computernutzung und warum ist sie wichtig? Computernutzung ist eine einfache Idee mit weitreichenden Folgen: Statt Modelle Fragen beantworten zu lassen, lassen wir sie Software bedienen. Sie navigieren durch Websites, füllen Formulare aus, durchlaufen Workflows und erledigen Aufgaben autonom von Anfang bis Ende.
Damit wird eine große Klasse realer Aufgaben möglich, die heute auf verschiedene Oberflächen verteilt sind, etwa vollständige Buchungen, Bezahlvorgänge im E-Commerce, mehrstufige Reiseplanungen und Backoffice-Workflows ohne passende API. Diese Probleme sind nicht neu. Neu ist, dass sie sich mit universell einsetzbaren Modellen lösen lassen.
Neuere Systeme von Anthropic und OpenAI haben Agenten gezeigt, die nicht nur handeln, sondern auch Zustände analysieren, Fehler beheben und spontan aufgabenspezifische Lösungen entwickeln. Damit wird der Browser zu einer allgemeinen Ausführungsumgebung für Agenten. Zugleich stellt sich eine unmittelbare Designfrage: Wie viel von dieser Umgebung sollten wir dem Modell zugänglich machen?
Frühe Systeme beantworteten diese Frage, indem sie den Browser mit einer festen Gruppe sicherer, vordefinierter Aktionen kapselten. Wie wir in diesem Beitrag erläutern, stößt dieser Ansatz an seine Grenzen.
Bei der Entwicklung von Browser-Agenten ist ein Reflex weitverbreitet: Vertraue dem Modell nicht zu sehr.
Also kapseln wir den Browser. Wir stellen vordefinierte Tools wie click, type, scroll, select und read_text bereit. Wir vereinfachen das Document Object Model (DOM). Wir begrenzen den Aktionsraum. Wir versuchen, das Verhalten durch selbst entwickelte Abstraktionen nachvollziehbar und steuerbar zu machen.
Das ist ein sinnvoller Ausgangspunkt. Zunehmend ist es jedoch auch die falsche langfristige Architektur.
Mit der Verbesserung von Frontier-Modellen liegt die Einschränkung nicht mehr nur darin, dass dem Modell Tools fehlen. Vielmehr zwingen wir es, über Abstraktionen zu arbeiten, die zu viel vom zugrunde liegenden System ausblenden. Wir verdichten eine komplexe, dynamische Umgebung zu einer festen Aktionsschnittstelle und erwarten dann, dass das Modell trotz dieses Informationsverlusts gute Ergebnisse erzielt.
Dieser Kompromiss wird zunehmend unattraktiv.
Der von uns untersuchte Wandel lässt sich einfach beschreiben, hat aber weitreichende Folgen. Statt den Agenten als Auswahlmechanismus für vordefinierte Aktionen zu betrachten, behandeln wir ihn als Programmsynthesizer, der in einer eingeschränkten Laufzeitumgebung arbeitet.
Die Modelle sind sehr leistungsfähig geworden und brauchen keine abstrahierten Leitplanken mehr. Sie benötigen den vollständigen Aktionsraum, um die Aufgabe zu planen, auszuführen und zu überarbeiten, bis sie ihr Ziel erreichen.
Dieser Beitrag behandelt diesen Wandel von stark abstrahierter Browserautomatisierung zu eingeschränkter Computernutzung und zeigt, was sich bei einer solchen Systemgestaltung ändert.
Das Problem ist nicht, dass feste Aktionsschnittstellen konzeptionell falsch wären. Das Web hält sich nur nicht an ihre Vorgaben.
Moderne Oberflächen basieren auf React, Vue und Angular. Sie nutzen asynchrone Statusaktualisierungen, synthetische Ereignissysteme und eingebettete Drittanbieter-Widgets, die in ursprungsübergreifenden iframes mit eigenen Lebenszyklen ausgeführt werden. Ein Wrapper mit der Anweisung „In dieses Eingabefeld schreiben“ funktioniert nur, wenn die Seite deiner Definition von Texteingabe entspricht. Bei vielen ist das nicht der Fall. Wird ein Wert direkt gesetzt, umgeht dies häufig vollständig die Änderungserkennung des Frameworks. Das Eingabefeld scheint ausgefüllt. Die Validierung wird nie ausgelöst. Das Formular funktioniert weiterhin nicht.
Du kannst das mit Patches beheben. Du kannst Sonderfälle für React-Eingabefelder hinzufügen, nach dem Fokussieren blur-Ereignisse auslösen und vor dem Lesen des Status warten, bis keine Netzwerkaktivität mehr besteht. Jeder Patch ist für sich genommen korrekt. Zusammen ergeben sie jedoch ein System, das immer schwerer zu warten und zunehmend auf bereits bekannte Websites zugeschnitten ist.
Das tiefer liegende Problem: Du bildest Annahmen darüber, wie Interaktionen funktionieren sollten, in der Abstraktionsschicht ab und stellst dann fest, dass im Web andere Annahmen gelten.
Betrachten wir ein über Stripe oder Adyen in ein ursprungsübergreifendes iframe eingebettetes Zahlungsformular. Dein Wrapper kann nicht direkt darauf zugreifen, weil es einen anderen Ursprung hat. Dein Tool read_text kann seinen internen Status nicht erfassen. Dein Tool type kann seine Eingabefelder nicht ansprechen. Ein Wrapper-basierter Agent kommt hier nicht weiter. Die Abstraktion wurde für das Hauptdokument entwickelt. Die eigentliche Aufgabe befindet sich an einer Stelle, die für die Abstraktion nicht sichtbar ist.
Eine ähnliche Diskrepanz tritt bei weniger offensichtlichen Abläufen auf. Ein vom Framework gesteuertes Auswahlmenü reagiert möglicherweise überhaupt nicht auf direkte Klicks, weil das sichtbare Element nicht das eigentliche Steuerelement ist. Möglicherweise ist eine Folge von Tastaturereignissen erforderlich, um den zugrunde liegenden Zustandsübergang auszulösen. Von außen wirkt die Benutzeroberfläche anklickbar. Die Abstraktion sagt „Klicken“. Nichts geschieht.
Oder betrachten wir einen mehrstufigen modalen Ablauf, bei dem Aktualisierungen des sichtbaren DOM internen Statusänderungen hinterherhinken. Die richtige nächste Aktion hängt von einem Zustandsübergang ab, der in den für deinen Wrapper sichtbaren Elementen noch nicht abgebildet ist. Ein Wrapper-basierter Agent handelt dann zu früh oder liest einen veralteten Status, weil er nur eine unvollständige Sicht auf das System hat.
In jedem dieser Fälle verbirgt die Abstraktion genau die Signale, die der Agent benötigt.
Ein Modell, das auf einer tieferen Ebene arbeitet, kann solche Situationen bewältigen. Es prüft das aktuelle DOM, berücksichtigt Frame-Grenzen und erzeugt die Interaktionsfolge für die jeweilige Oberfläche. Das Modell ist nicht grundsätzlich intelligenter. Es hat lediglich Zugriff auf die zuvor ausgeblendeten Informationen.
Die angestrebte Änderung lässt sich einfach beschreiben: Statt das Modell aus vordefinierten Aktionen auswählen zu lassen, geben wir ihm eine Ausführungsumgebung auf niedrigerer Ebene und schränken diese durch Laufzeitrichtlinien statt durch Abstraktionsdesign ein.
Diese Designentscheidung folgt einem breiteren Branchentrend hin zu elementaren Tools auf niedrigerer Ebene. Sie nutzen die natürliche Fähigkeit des Agenten, sich zur Laufzeit zu korrigieren und hochwertigen Code zu erzeugen. Fest programmierte Spezialtools sind zwar robust, nehmen dem Modell jedoch die Möglichkeit, sich an unterschiedliche Umgebungen anzupassen.
Das zeigt etwa der Erfolg von Claude Code als bevorzugtes Tool vieler Developer sowie der allgemeine Branchentrend zu terminalbasierten Agenten. Der größte Vorteil von Claude Code ist nicht das Modell selbst, sondern das Harness auf niedrigerer Ebene. Das Modell erhält weniger, dafür modularere Tools auf niedrigerer Ebene, also das Terminal. Dadurch funktionieren Toolaufrufe besser, vor allem weil der Agent die Aufgabe analysieren und dafür individuelle Skripte erstellen kann, statt allgemeine Tools zu verwenden, die das Kontextfenster belasten.
Für die Browserautomatisierung bedeutet das in der Praxis: Das Modell kann den aktuellen Seitenstatus direkt prüfen, Frames durchlaufen und individuellen Interaktionscode für die aktuelle Oberfläche erstellen, statt alles auf eine feste Gruppe vorgefertigter Aktionen abzubilden.
Das Modell verhält sich weniger wie ein Auswahlmechanismus und mehr wie ein Autor von Laufzeitcode. Es prüft den aktuellen Status, analysiert die Oberfläche und erzeugt die Interaktionslogik für die jeweilige Situation. Es kann mehrstufige Abläufe erstellen, sich an ungewöhnliche Prozesse anpassen und Ergebnisse vor dem Fortfahren validieren. Wenn eine Aktion fehlschlägt, sieht das Modell den zugrunde liegenden Fehler und korrigiert sich selbst. Das ist leistungsfähiger und riskanter, entspricht aber deutlich besser der tatsächlichen Problemstruktur.
Wichtig ist: Das Entfernen der Abstraktionsschicht macht das System nicht weniger kontrolliert. Die Kontrolle wird lediglich verlagert.
Arbeit, die bisher im Wrapper-Design und in der Behandlung von Sonderfällen steckte, verlagert sich an drei Stellen: in den Prompt, der zu einer Form operativer Schulung wird, in die Laufzeitumgebung, die Grenzen wie Navigationsbereich, sensible Aktionen und Wiederholungsverhalten durchsetzt, und in die Bewertungsebene, die nicht nur den Erfolg der Aufgabe, sondern auch die Korrektheit der Zwischenschritte beurteilt. Weniger fragile Abstraktionen. Stärkere umgebende Systeme.
Eine Folge dieses Wandels ist, dass der Produktcode oft einfacher wird, obwohl das Gesamtsystem leistungsfähiger wird. Statt Interaktionsmuster in wiederverwendbaren Wrappern abzubilden, erzeugt der Agent das Verhalten zur Laufzeit. Du verwaltest wenige leistungsfähige Grundbausteine und eine eingeschränkte Ausführungsumgebung statt einer wachsenden Zahl spezialisierter Tools und Sonderfalllogik.
Das verändert auch, wie das System generalisiert. Ein Wrapper-basierter Agent generalisiert gut auf Aufgaben, die den bereits entwickelten Wrappern ähneln. Ein Agent mit eingeschränkter Laufzeit generalisiert auf Aufgaben mit derselben Ausführungsgrundlage, selbst wenn sich die sichtbare Oberfläche unterscheidet.
Die Interaktion mit einem Suchformular, einem Buchungsablauf oder einer Einstellungsseite kann beispielsweise auf Ebene der Benutzeroberfläche völlig unterschiedlich aussehen. Darunter folgen sie jedoch denselben Mustern: Status lesen, Ereignisse auslösen, Ergebnisse validieren und asynchrone Aktualisierungen verarbeiten. Ein System, das auf dieser Ebene arbeitet, lässt sich natürlicher auf andere Aufgaben übertragen.
Die wiederverwendbare Komponente ist nicht die Aktionsliste. Es ist die Fähigkeit des Modells, den Status zu prüfen, sicher zu handeln und Ergebnisse zu verifizieren.
Die wichtigste Erkenntnis aus dieser Arbeit: Zuverlässigkeit entsteht nicht dadurch, dass das Modell mehr Hilfsfunktionen erhält. Oft entsteht sie durch weniger, aber leistungsfähigere Grundbausteine, die auf die richtige Weise eingeschränkt werden. Übermäßige Unterstützung schreibt Annahmen darüber fest, wie eine Aufgabe zu erledigen ist. Einschränkungen definieren sichere Betriebsgrenzen und ermöglichen dem Modell, vor Ort bessere Lösungen zu finden.
Eine leistungsfähigere Ausführungsumgebung erfordert auch ein präziseres Sicherheitsmodell. Sobald der Agent nicht mehr auf wenige vordefinierte Aktionen beschränkt ist, arbeitet er praktisch direkt mit realer Software. Dadurch ändert sich das Risikoprofil unmittelbar.
Bei der Entwicklung sind vier Aspekte zu berücksichtigen:
Offenlegung von Daten. Wenn der Agent mit realen Oberflächen interagiert, stößt er häufig auf vertrauliche Informationen. Das erfordert einen konsequenten Ansatz für Maskierung und Zugriffskontrolle. Daten sollten nur offengelegt werden, wenn sie für die Ausführung erforderlich sind. Protokolle und Ablaufdaten müssen sorgfältig behandelt werden, damit die Beobachtbarkeit nicht zum sensibelsten Teil des Systems wird.
Ausführungsbereich. Ein leistungsfähiger Agent darf nicht beliebig agieren können. In der Praxis muss eingeschränkt werden, wohin er navigieren, auf welche Domains er zugreifen und mit welchen Systemen er interagieren darf. Diese Einschränkungen sollten auf Laufzeitebene durchgesetzt und nicht nur als Konventionen im Prompt festgehalten werden.
Vertrauenswürdigkeit der Umgebung. Moderne Oberflächen können irreführende oder gezielt feindselige Anweisungen, Inhalte oder Abläufe enthalten. Prompt Injection über Seiteninhalte ist eine reale Angriffsfläche. Das System benötigt eine klare Anweisungshierarchie, Validierungsprüfungen und Abbruchbedingungen, damit der Agent nicht unbeabsichtigten Anweisungen folgt.
Autonomiespektrum. Nicht alle Aktionen sollten vollständig autonom erfolgen. In vielen Produktivumgebungen ist es wichtig, Autonomie als Spektrum zu betrachten. Das System kann bei Erkundung und Ausführung weitgehend agentisch arbeiten und für bestimmte Aktionskategorien dennoch eine Genehmigung verlangen.
Das zugrunde liegende Prinzip ist einfach: Mehr Leistung für das Modell erfordert ein stärkeres umgebendes System. Autonomie ohne Richtlinien ist nicht bereit für den Produktivbetrieb.
Wir fragten nicht mehr: Welche Browseraktionen sollten wir bereitstellen?
Stattdessen fragten wir: Wie können wir dem Modell einen vollständigen Aktionsraum bieten und zugleich Laufzeitrichtlinien festlegen, die für Sicherheit sorgen?
Diese neue Perspektive verschiebt die Prioritäten. Aktionstaxonomien und die Vollständigkeit von Wrappern werden weniger wichtig. Laufzeitrichtlinien, Beobachtbarkeit und die Bewertung einzelner Schritte werden wichtiger. Modellfähigkeiten und Systemdesign sind kein Ersatz füreinander. Je besser die Modelle werden, desto wichtiger wird die Arbeit des Systems, nicht weniger wichtig.
Browser-Agenten, die in Demos funktionieren, sind oft deshalb erfolgreich, weil die Aufgabe eng begrenzt ist und die Umgebung mitspielt. Produktivsysteme benötigen etwas anderes: eingeschränkte Ausführung, instrumentiertes Verhalten und eine Bewertung, die ein korrektes Ergebnis von einem Zufallstreffer unterscheiden kann.
Weniger Wrapper-Design. Mehr Systementwicklung.
Wir haben uns zwar auf Browser-Agenten konzentriert, doch daraus ergibt sich eine umfassendere Sicht auf Computernutzung als Systemdisziplin.