„Assist“ statt Autopilot
Konservativ starten: Der Agent navigiert, füllt aus, sammelt Infos – aber der Mensch bestätigt den letzten Schritt. Das ist oft der beste ROI‑Punkt.
Blog · Guide
Browser‑Automation ohne API: eine praktische Blaupause
Viele Prozesse hängen an Webseiten, die eigentlich nur für Menschen gebaut sind: Portale, Buchungen, Formulare, Shops. Genau dort wird OpenClaw interessant – nicht als „Bot, der alles automatisch klickt“, sondern als kontrollierbarer Assistent, der im Browser arbeitet und Ergebnisse nachvollziehbar dokumentiert.
Warum „keine API“ nicht das Ende sein muss
Im Alltag scheitern Automationen oft nicht am Willen, sondern an der Schnittstelle. Ein Service bietet keine API, oder sie ist eingeschränkt, oder die Integration wäre unverhältnismäßig teuer. Dann bleibt nur das, was Menschen auch tun: im Browser klicken.
Browser‑Automation klingt erstmal fragile – und ja: sie kann es sein. Der Unterschied liegt darin, wie man sie aufsetzt. In der OpenClaw‑Welt ist Browser‑Automation ein Werkzeug unter vielen: Du kannst Schritte nachvollziehbar machen, Sicherungen einbauen und Standards definieren (z. B. „nur Entwurf“, „nur bis zum Bestätigungs‑Screen“).
Eine echte Community‑Blaupause: „Tesco Shop Autopilot“
Im Showcase wird ein Projekt beschrieben, das einen wöchentlichen Einkauf im Browser abarbeitet: Essensplan → Standardartikel → Lieferfenster buchen → Bestellung bestätigen. Das ist kein „magischer AI‑Knopf“, sondern ein Workflow, der Schritt für Schritt durch einen Prozess navigiert, den es sonst nur als Web‑UI gibt.
Als Lernbeispiel ist das Gold wert, weil es zeigt: Automationen werden dann robust, wenn sie den Prozess so behandeln wie ein Mensch – aber mit besseren Checklisten und Logs.
Was daran für dich relevant ist (auch ohne Tesco)
Du musst keinen Einkauf automatisieren. Das Muster passt genauso auf: Portale für Rechnungen, Ticketsysteme, HR‑Tools, Lieferdienste, interne Admin‑UIs oder Banken‑Oberflächen (wo Automatisierung besonders vorsichtig sein muss).
Wichtig ist der Perspektivwechsel: Nicht „Website hacken“, sondern ein wiederholbares Bedien‑Skript bauen – mit klaren Stop‑Punkten und sinnvollen Prüfungen.
So wird Browser‑Automation zuverlässig (in der Praxis)
Wenn Browser‑Automationen scheitern, liegt es meist an kleinen UI‑Änderungen oder an unstabilen Selektoren. Das ist lösbar – aber nicht mit „einmal aufnehmen, nie wieder anfassen“. Stattdessen helfen ein paar einfache Prinzipien:
- Stabile Ziele wählen: nicht „klicke den dritten Button“, sondern „klicke den Button mit Text X“. Wo möglich: eindeutige Labels, ARIA‑Namen, Test‑IDs.
- Schritte verifizieren: nach jedem kritischen Schritt prüfen, ob der erwartete Zustand erreicht ist (z. B. „Warenkorb enthält 12 Artikel“ oder „Lieferfenster ausgewählt“).
- Stop‑Punkte definieren: bis wohin darf der Workflow automatisch laufen? Viele Setups stoppen vor „Jetzt kaufen“ und fragen nach Freigabe.
- Fehler als normal behandeln: Retries, Timeouts, alternative Pfade (z. B. Cookie‑Banner) – und im Zweifel sauber abbrechen statt „durchdrücken“.
- Protokollieren: Screenshots oder kurze Status‑Updates im Chatkanal machen einen Workflow nachvollziehbar, gerade wenn etwas schiefgeht.
In OpenClaw ist das Entscheidende: Du kannst Browser‑Schritte mit Chat‑Ausgaben kombinieren. So entsteht nicht nur ein Ergebnis, sondern auch ein auditierbarer Verlauf.
Wiederkehrende Portale
Die größten Gewinne entstehen bei Aufgaben, die regelmäßig kommen und immer ähnlich ablaufen: Buchungen, Uploads, Abfragen, Status‑Checks.
Kein API‑Projekt nötig
Browser‑Automation ist kein Ersatz für APIs – aber ein pragmatischer Weg, wenn eine API fehlt oder die Integration zu teuer wäre.
Quellen & Weiterführendes
Dieses Beispiel basiert auf dem OpenClaw‑Showcase („Tesco Shop Autopilot“) und ist hier als Inspiration verlinkt:
OpenClaw Showcase (Übersicht):
https://docs.openclaw.ai/start/showcase
Eintrag „Tesco Shop Autopilot“ (X/Twitter):
https://x.com/i/status/2009724862470689131
Wenn du das nachbauen willst
Der schnellste Einstieg ist ein Workflow, der nur einen wiederkehrenden Web‑Task abdeckt (z. B. „wöchentlich Daten aus Portal ziehen“). Wir setzen dann gemeinsam die ersten stabilen Schritte, bauen Stop‑Punkte ein und testen den Ablauf. Erst wenn das sitzt, lohnt sich der Ausbau.