OpenChrome – Paralleler Automatisierungs-MCP-Server für den Chrome-Browser
(github.com/shaun0927)Playwright ist ein nützliches Web-Automatisierungstool, wenn man irgendwie Crawling betreiben oder in einer Produktionsumgebung E2E-Tests durchführen möchte, indem es Aktionen wie Klicks im Browser steuert.
Es wurde zwar 2020 veröffentlicht,
ist aber noch immer das Tool, das die meisten Entwickler verwenden.
Allerdings verbraucht schon eine einzige Sitzung mehr als 2 GB RAM, ist schwerfällig, langsam und bricht leicht.
Im Zeitalter der KI braucht dieses Werkzeug Innovation,
vor allem wird ein Browser-Automatisierungstool benötigt, das auch bei parallelen Aufgaben stabil läuft.
Wir wollen nicht länger selbst QA machen oder durch Websites umherirren.
OpenChrome ist ein Projekt, das aus dem Willen entstanden ist, dieses Problem zu lösen.
Es ist ein MCP-Server, der schnelle und intelligente parallele Browser-Automatisierung ermöglicht.
Außerdem ist es in letzter Zeit das Tool, das ich in meiner persönlichen Arbeit am häufigsten verwende.
Es nutzt den Login des Chrome-Browsers,
und wenn mehrere Konten verwendet werden, muss man beim Auftrag nur den Namen des zu verwendenden Kontos angeben.
Standardmäßig arbeitet es auf Basis des bereits eingeloggten Chrome-Browsers.
Parallele Arbeit ist in mehr als 20 Browsern möglich, und der RAM-Verbrauch wurde auf etwa 300 MB gesenkt. Es arbeitet im eingeloggten Chrome-Zustand und setzt Bot-Erkennung damit faktisch vollständig außer Kraft. Eine Integration mit Openclaw ist ebenfalls möglich.
Ein Anwendungsbeispiel sieht wie folgt aus.
"Crawle mir mit oc die neuesten Beiträge von 20 bekannten Personen auf Twitter."
(Benchmark auf Basis von claude code: 3 Minuten 30 Sekunden – der Großteil davon ist LLM-Inferenzzeit)
Das chronische Problem von Playwright ist in Wahrheit das ziellose „LLM-Umherirren“.
Selbst wenn man Aufgaben wie das Einloggen vorgibt, durchsucht es lange die Website und probiert dies und das aus,
am Ende kommt dann oft die Meldung, dass es nach mehr als 30 Minuten fehlgeschlagen ist.
OpenChrome löst das nicht mit einem erratenden Ansatz, sondern mit einem Guided-Ansatz.
Es meldet sich direkt in Chrome an, und wenn man einen Link gibt, öffnet es sofort diesen Link.
Screenshots werden auf ein Minimum reduziert, und die Position von Buttons und Ähnlichem wird schnell erfasst.
Wenn es bei einer Aufgabe Probleme gibt, erinnert es sich daran und wiederholt denselben Fehler nicht noch einmal.
Da es ein MCP-Server ist, kann es anstelle von Playwright sofort in jeder bestehenden Umgebung verwendet werden.
Es funktioniert nicht nur bei der Entwicklung mit MAC-claude code oder auf anderen Betriebssystemen wie Windows und Linux,
sondern auch in codex cli, cursor und mehr.
Installation:
npx openchrome-mcp setup
Für sehr komplexe groß angelegte Produktionsstabilität mit hohem Ressourcenverbrauch ist zusätzliche Validierung nötig.
Wenn Sie Feedback oder Vorschläge haben, stellen Sie diese bitte in den GitHub Issues ein; ich werde sie umgehend berücksichtigen.
Vielen Dank.
13 Kommentare
Heißt das, dass KI die Test-Codes direkt selbst verwaltet und ausführt, anstatt bestehende E2E-Lösungen zu verwenden?
Wenn bestehendes
playwrightmit einer stark standardisierten Methodik auf Websites zugegriffen hat und dabei der Token-Verbrauch hoch war,kann man
openchromewohl als ein Konzept verstehen, das LLM-freundlich vorgeht, sodass das LLM schnell direkt in die Steuerung der Website-Aktionen eingreifen kann. Eine E2E-Lösung kann direkt ausgeführt werden.Zum Beispiel kann man in einer Produktion, in der ein Google-Login erforderlich ist, QA-Aufgaben ausführen lassen, während man mit einem Administrator-Konto eingeloggt ist. Man kann automatisch scrollen lassen, Edge Cases selbstständig anklicken lassen und so weiter — die meisten Aufgaben, die Sie sich vorstellen, sind alle möglich. Denn anstatt
playwrightautonom dumme Aufgaben erledigen zu lassen, greift das LLM unmittelbar ein und steuert das Verhalten direkt.Wenn man sich allein den Token-Verbrauch ansieht, ist ein standardisiertes Verfahren doch nicht noch sparsamer, weil man dabei E2E-Testfälle ohne Eingriff eines LLM ausführt?
Zur Testmethodik gehört neben den TCs auch, dass QA eigenständig testet.
Wäre es sinnvoll, diesen Teil positiv zu bewerten, wenn man ihn als effizient einschätzt?
Um auf Ihre konkrete Frage etwas technischer zu antworten:
Das bestehende Playwright-MCP arbeitet mit den folgenden drei Abstraktionsstufen:
LLM → MCP-Server → Playwright-Node.js-Server → CDP/Juggler → Browser
OpenChrome hingegen arbeitet mit der folgenden einstufigen Abstraktion:
LLM → MCP-Server → CDP → Browser
Je weniger Abstraktionsschichten es gibt, desto schneller ist es und desto präziser ist die Steuerung.
Während Playwright ein universelles Werkzeug ist, verwendet OpenChrome spezialisierte Tools.
Wenn man es mit einer Mathematikaufgabe vergleicht, fühlt es sich an, als würde man einen 20-zeiligen Lösungsweg auf 4 Zeilen komprimieren.
Playwright erhält Feedback zudem über eine textbasierte Methode namens Accessibility Tree,
(was theoretisch hervorragend ist, aber der Grund, warum es auf den meisten Websites scheitert)
weshalb die Erfassung des Kontexts stark eingeschränkt ist.
Daher ist Playwright auf Websites mit gut implementierter Barrierefreiheit (Google und andere bekannte Domains) weiterhin nützlich,
aber auf den meisten Websites oder in Production ist OpenChrome deutlich überlegen.
Außerdem entscheiden letztlich die „Dichte des Tool-Designs“ und die „Verringerung von Gelegenheiten für LLMs, Fehler zu machen“ über die praktische Leistung,
daher sollte man meiner Meinung nach nicht anhand theoretischer Leistung, sondern anhand von Real-World-Tasks messen.
Vielen Dank. Ich habe den Haupttext wohl nicht gründlich genug gelesen.
Den Teil, dass es für Produktionsumgebungen gedacht ist, habe ich übersehen.
Ich werde es auf jeden Fall auch ausprobieren.
Vielen Dank, dass Sie meine falsche Frage trotzdem so gewissenhaft beantwortet haben~
Nein, überhaupt nicht — gute Frage, danke. Beim Erklären habe ich es auch für mich selbst besser geordnet.
Definitiv schnell und gut.
Wenn ein Alert erscheint, bleibt es stehen.
Diesen Inhalt werden wir zügig verbessern.
Mich würde auch ein Vergleich mit Chrome DevTools MCP interessieren!
Als ich es ausprobiert habe, hatte ich die Erinnerung, dass Playwright sogar eher besser war als Chrome DevTools MCP; ich werde später noch Benchmarks ergänzen.
Bei
chrome devtools mcperscheint keine Warnung wegen des großen Kontexts, aber die Performance fühlte sich ungefähr ähnlich an, deshalb habe ich bisher das hier benutzt! Ich bin gespannt auf die Benchmark-Ergebnisse :DOh, sinkt damit auch der Token-Verbrauch? Vielen Dank!!
Man kann es so sehen: Je weniger Fehlversuche anfallen, desto geringer ist auch der Token-Verbrauch.