Playwright MCP oder CLI

Playwright MCP oder CLI

0:00 Bisher haben wir Agenten benutzt, ohne genau hinzusehen, wie sie eigentlich an den Browser kommen. Das holen wir jetzt nach — denn es gibt zwei Wege, und die Wahl hat spürbare Folgen für Kosten, Nachvollziehbarkeit und Sicherheit. Vorweg ein verbreitetes Missverständnis: Das ist kein Schalter, den man umlegt. Es sind zwei unterschiedliche Interaktionsmodelle, die beide denselben Browser steuern.

0:23 Und weil ein Agent mit Browserzugriff eine echte Angriffsfläche ist, endet dieses Modul mit dem Thema Sicherheit — dem Teil, der bei jeder Einführung im Unternehmen zuerst gefragt wird.

Playwright MCP verstehen

0:34 Beginnen wir mit dem Modell, das die meisten zuerst kennenlernen: dem MCP-Server, der dem Agenten den Browser als Werkzeugkasten hinstellt. MCP ist der Weg, den die meisten zuerst ausprobieren, und er hat gute Gründe für sich. Schauen wir uns an, wie er funktioniert und wo seine Stärken liegen. Und wir klären gleich mit, welche Optionen Sie dabei unbedingt setzen sollten.

0:57 MCP steht für Model Context Protocol — eine standardisierte Art, einem Modell Werkzeuge anzubieten. Playwright MCP macht daraus einen Browser mit Griffen: navigieren, klicken, tippen, Netzwerk ansehen. Der Agent ruft benannte Werkzeuge auf, ungefähr so, wie man in einer Werkstatt nach dem Schraubenschlüssel fragt, statt selbst im Regal zu wühlen.

1:18 Gearbeitet wird dabei auf dem Accessibility Snapshot, den wir aus Modul drei kennen — also auf Rollen, Namen und Referenzen, nicht auf Pixeln. Vier Zeilen Konfiguration, mehr braucht es nicht. Der Server wird beim Start des Coding Agent hochgefahren und hält die Browsersitzung über die gesamte Schleife. Genau das ist die Eigenschaft, die MCP auszeichnet: Der Zustand bleibt bestehen, während der Agent nachdenkt, Zwischenschritte macht und wiederkommt.

1:45 Was Sie hier außerdem sehen: Es ist eine ganz normale Konfigurationsdatei Ihres Coding Agent. Sie gehört behandelt wie jede andere Konfiguration — versioniert, überprüfbar, und mit dem Wissen, welche Fähigkeiten Sie damit freischalten. Vier Stärken, die alle aus derselben Eigenschaft folgen: dem gehaltenen Zustand. Eine Erkundung über viele Schritte hinweg profitiert davon, weil die Sitzung nicht zwischendurch verloren geht.

2:12 Strukturierte Aufrufe kann ein Modell zuverlässig zusammensetzen — es muss keine Kommandozeile raten. Spezialisierte Agentenschleifen, die den Browser lange halten, sind hier zu Hause. Und der Zugriff auf Speicherzustand und Netzwerk innerhalb derselben Sitzung erlaubt Beobachtungen, die sonst mühsam wären. Kurz: MCP ist stark, wo Kontinuität zählt.

2:34 Aus dieser Optionsliste sind zwei Zeilen für den Alltag entscheidend, und sie gehören zusammen. „Isolated" sorgt dafür, dass jede Sitzung ohne Vorgeschichte startet — keine Reste, keine Gespenster. „Storage State" liefert dazu den angemeldeten Ausgangszustand aus einer Datei. Zusammen ergeben die beiden einen reproduzierbaren Startpunkt: immer angemeldet, nie mit Altlasten. Die übrigen Optionen betreffen Browserwahl, Sichtbarkeit und Profilverzeichnis.

3:02 Nur eine Warnung vorweg: Das eigene Alltagsprofil einzuhängen, ist verlockend und eine schlechte Idee — dazu gleich mehr im Sicherheitskapitel. Vier typische Probleme. Den Server mit dem persönlichen Browserprofil zu starten mischt private Konten mit Testkonten — im besten Fall verwirrend, im schlechtesten ein Datenschutzvorfall.

3:23 Snapshots ganzer Seiten wiederholt anzufordern flutet den Kontext; das ist der Hauptgrund, warum MCP-Läufe teurer ausfallen. Sitzungen nicht zu schließen führt dazu, dass Sie mit Resten des Vorlaufs weiterarbeiten. Und die vierte Erwartung räumen wir gleich hier ab: MCP schreibt keine Tests. Es steuert einen Browser, nicht mehr und nicht weniger.

Die Playwright-CLI verstehen

3:44 Damit zum zweiten Weg — einer Kommandozeile, die ausdrücklich für Coding Agents gebaut wurde und deren wichtigste Eigenschaft ein sehr praktisches Argument ist: Sparsamkeit. Dieser zweite Weg ist jünger, unscheinbarer und in vielen Projekten der praktischere. Sein wichtigstes Argument ist eines, über das man selten spricht: Sparsamkeit im Umgang mit dem Kontext.

4:05 Die Playwright-CLI ist eine Kommandozeile für Browsersteuerung. Statt großer Werkzeugschemata und langer Accessibility-Bäume im Kontext arbeitet der Agent mit kurzen Befehlen und mit Referenzen aus einem Snapshot. Der Unterschied ist der zwischen einem ausführlichen Handbuch und einem Zettel mit fünf Kommandos — beides führt zum Ziel, nur belegt das eine deutlich weniger Platz im Kopf.

4:27 Und da Coding Agents ohnehin in einer Shell zu Hause sind, fügt sich dieser Weg nahtlos in ihre übrige Arbeit im Repository ein. Fünf Zeilen, und die zweite ist die interessante: Sie installiert sogenannte Skills — Beschreibungen, die dem Coding Agent die Befehle bekannt machen. Ohne sie müsste er die Kommandozeile erraten, und Raten ist bei Werkzeugen eine schlechte Strategie.

4:49 Die dritte Zeile öffnet eine benannte Sitzung; der Name ist später Ihr Griff, um dieselbe Sitzung wiederzufinden. Danach ein Snapshot, der die Element-Referenzen liefert, und eine Übersicht der laufenden Sitzungen. Das ist der komplette Einstieg — mehr braucht es tatsächlich nicht. Fünf Gruppen, und die Logik dahinter ist die Arbeitsteilung einer Erkundung: bedienen, beobachten, Zustand verwalten, Sitzungen führen, diagnostizieren.

5:14 Besonders praktisch sind die beiden Zustandsbefehle in der dritten Zeile: Sie sichern und laden denselben Storage State, den auch Ihre Testkonfiguration benutzt. Das heißt, Sie melden sich einmal an und arbeiten danach überall angemeldet weiter — im Test wie in der Erkundung, ohne dass ein Passwort durch den Kontext des Modells wandert.

5:33 Diese Brücke zwischen beiden Welten ist der unterschätzte Teil dieses Werkzeugs. Token-Effizienz klingt nach Erbsenzählerei, ist aber sehr konkret. Kurze Befehle verdrängen die Anweisungen nicht aus dem Kontext — der Agent behält also im Kopf, was er eigentlich tun sollte. In großen Repositories bleibt Platz für Code statt für Seitenbäume.

5:54 Läufe werden billiger und damit häufiger wiederholbar; das verändert die Arbeitsweise mehr als jede einzelne Funktion. Und das Protokoll bleibt lesbar: Sie sehen hinterher als Zeilenfolge, was der Agent getan hat. Nachvollziehbarkeit ist bei Agenten kein Nebenprodukt, sondern ein Auswahlkriterium. Fünf Schritte für den Alltag. Sitzung mit sprechendem Namen und persistent starten. Die Anmeldung einmal durchführen und den Zustand sichern — danach brauchen Sie sie nie wieder.

6:23 Den Sitzungsnamen an den Coding Agent übergeben, der arbeitet dann in derselben Sitzung weiter. Laufende Sitzungen im Dashboard beobachten; das ist überraschend nützlich, weil man dem Agenten buchstäblich bei der Arbeit zusieht. Und am Ende schließen und die Daten löschen. Der letzte Schritt gehört zur Hygiene, nicht zur Ordnungsliebe — es sind Anmeldedaten.

Die passende Integration wählen

6:45 Jetzt die Entscheidung. Und vorweg noch einmal: Es geht nicht darum, welches Werkzeug besser ist, sondern welches zu Ihrem Anwendungsfall passt. Beide Wege sind fertig und gut dokumentiert — die Frage ist also nicht, welcher taugt, sondern welcher zu Ihrem Alltag passt. Dafür braucht es nur vier Fragen. Danach können Sie die Entscheidung im Team begründen, statt sie zu verteidigen.

7:08 MCP und die Kommandozeile sind unterschiedliche Interaktionsmodelle, kein Umschalter. Das ist mehr als eine Formulierungsfrage: Wer glaubt, man könne zwischen beiden hin- und herschalten, wundert sich, warum die Agentendefinitionen plötzlich nicht mehr passen. MCP eignet sich besonders für zustandsbehaftete, explorative Schleifen. Die Kommandozeile für token-effiziente Arbeit eines Coding Agent im Repository.

7:33 Beide steuern denselben Browser mit derselben Bibliothek darunter — der Unterschied liegt darin, wie der Agent mit ihm spricht. Statt die Zeilen vorzulesen, die Kurzfassung: Die offizielle Dokumentation empfiehlt die Kommandozeile für Coding-Agent-Workflows und MCP für explorative, länger laufende Schleifen. Das deckt sich mit der Erfahrung. Wenn Sie hauptsächlich im Repository arbeiten und der Agent nebenbei mal etwas im Browser nachsieht, nehmen Sie die Kommandozeile.

8:01 Wenn ein spezialisierter Agent eine halbe Stunde lang eine Anwendung durchkämmt und dabei Zustand mitschleppt, ist MCP im Vorteil. Und ja, man kann beides im Team haben — nur nicht gleichzeitig auf derselben Sitzung. Vier Fragen, die schneller zur Antwort führen als jede Feature-Liste. Wie lange soll ein Browserzustand über Schritte hinweg halten?

8:22 Wie viel Kontext braucht der Agent noch für den eigentlichen Code? Welche Werkzeuge darf er in dieser Umgebung überhaupt aufrufen — das ist oft eine Governance-Frage, keine technische. Und: Wie gut lässt sich nachvollziehen, was er getan hat? Die letzte Frage wird regelmäßig vergessen und ist die, nach der Sie im Zweifelsfall gefragt werden.

8:42 Vier Punkte. Beide Wege parallel zu aktivieren und dieselbe Sitzung doppelt zu greifen, führt zu Verhalten, das niemand mehr erklärt. Die Wahl an Vorlieben festzumachen statt an Kontext und Nachvollziehbarkeit ist bequem und rächt sich im Betrieb. Zu erwarten, dass ein Wechsel bestehende Agentendefinitionen unverändert lässt, führt zu einer verwirrenden Fehlersuche.

9:03 Und Erkundungssitzungen mit der Testausführung zu vermischen, macht aus reproduzierbaren Tests plötzlich zustandsabhängige — das ist der Klassiker.

Sicherheit und Betriebsregeln

9:13 Und damit zum Teil, den man nicht überspringen darf. Ein Agent, der einen Browser steuert, handelt mit echten Rechten — und liest Inhalte, die ihm jemand untergeschoben haben könnte. Dieses Kapitel ist kein Pflichtprogramm für Sicherheitsbeauftragte. Es ist der Teil, der darüber entscheidet, ob Sie Agenten im Unternehmen überhaupt einsetzen dürfen — und er ist schnell abgearbeitet.

9:35 Zwei Dinge kommen hier zusammen. Erstens: Der Agent handelt mit den Rechten der geladenen Sitzung. Ist er in Ihrem Konto angemeldet, kann er alles, was Sie können. Zweitens: Er liest Inhalte fremder Seiten und nimmt sie in seinen Kontext auf. Diese Inhalte sind nicht vertrauenswürdig — sie können Anweisungen enthalten, die sich an den Agenten richten. Man nennt das Prompt-Injektion, und es ist keine theoretische Sorge.

10:01 Für den Alltag heißt das: bekannte Umgebungen, minimale Rechte, und Ausgaben lesen, bevor man sie übernimmt. Diese vier Regeln kosten fast nichts und verhindern das meiste. Browserzugriff auf vertrauenswürdige Testumgebungen begrenzen — kein Agent auf Produktion, auch nicht lesend. Keine produktiven Zugangsdaten, keine echten Kundendaten; Testkonten sind schnell angelegt.

10:24 Dateien mit Storage State wie Geheimnisse behandeln und nie committen — das sind Anmeldedaten in Dateiform, auch wenn sie harmlos aussehen. Und die Rechte des Agenten auf das Nötige beschränken. Wenn Sie morgen nur eine Sache umsetzen, nehmen Sie die dritte; sie wird am häufigsten übersehen. Die erste Zeile ist die wichtigste, deshalb im Wortlaut: Playwright bezeichnet die MCP-Funktion zur Ausführung beliebigen JavaScripts ausdrücklich als RCE-äquivalent — also gleichbedeutend mit dem Ausführen fremden Codes auf Ihrem Rechner — und empfiehlt sie nur für vertrauenswürdige Clients.

10:58 Lassen Sie sie aus. Die übrigen Zeilen sind das übliche Handwerk: bekannte Umgebungen gegen Injektion, Testkonten gegen Datenabfluss, Pull Requests gegen unbemerkte Änderungen, erlaubte Ursprünge gegen Ausflüge auf fremde Hosts. Nichts davon ist aufwendig — es muss nur einmal entschieden werden. Die Aufgabe ist bewusst keine Programmieraufgabe: Formulieren Sie für Ihr Team begründete Leitplanken.

11:21 Eine Seite genügt — erlaubte Umgebungen, verbotene Werkzeuge, Umgang mit Zustandsdateien. Ein Hinweis, der den Unterschied macht: Legen Sie diese Seite dorthin, wo auch die Agentendefinitionen ihre Anweisungen herziehen. Regeln, die nur im Wiki stehen, gelten für Menschen; Regeln, die im Kontext des Agenten stehen, gelten auch für ihn.

11:42 Im nächsten Modul geht es wieder um Code — um die Frage, wie die erzeugten Tests wartbar bleiben.