PawWork_ZhuaZhua: Chrome als programmierbarer Rechner, Agent im Side Panel

Ein Agent für den angemeldeten Browser, nicht für eine frische Sitzung

Das Problem, das die README benennt, ist der Unterschied zwischen einem leeren Automatisierungsbrowser und dem Browser, in dem man tatsächlich arbeitet. PawWork_ZhuaZhua setzt beim zweiten an: Der bereits angemeldete Chrome wird als programmierbarer Rechner behandelt, und die Erweiterung ist der Agent auf dieser Maschine. Konkret heißt das, dass Sitzungscookies, Logins und der aktuelle Tab-Zustand nicht neu aufgebaut werden müssen. Die README formuliert die Reichweite offen: Alles, was ein Tampermonkey-Userscript leisten könnte, liegt im Bereich des Möglichen. Die Zielgruppe sind damit Leute, die wiederkehrende Arbeiten in einem eingeloggten Webinterface erledigen und dafür kein eigenes Skript schreiben wollen. Der Preis für diesen Ansatz steht im selben Dokument: Es gibt keinen Userscript-Store, und ausgeliefert wird genau ein Playbook namens page-restyle.

Vom Side Panel über den Service Worker zum Offscreen-Agenten

Die README beschreibt die Kette in einer Zeile: sidepanel, service worker, offscreen SessionWorkspaceService, dann ein ToolLoopAgent aus dem AI SDK. Das Side Panel ist die Oberfläche, in der die Aufgabe eingegeben wird. Der Service Worker ist der Hintergrundkontext einer MV3-Erweiterung, und weil dort kein DOM verfügbar ist, wandert die eigentliche Arbeit in ein Offscreen-Dokument. Dort läuft der Agent, der die Werkzeuge aufruft. Die Werkzeuge sind in der README in drei Gruppen sortiert. action arbeitet auf dem Live-Tab: zuerst ein snapshot, dann Mutationen, die an die ref und rev der jeweiligen Generation gebunden sind. run führt Sandbox-JavaScript aus und stellt dem Gast ein sys-Objekt mit tabs, eval, fetch, cdp, download und screenshot bereit. sheet, doc und web halten eine Univer-Tabelle, ein Univer-Dokument und Seiten-HTML in der Sitzung. Dazu kommen inspect, acquire und clarify, um die Sitzung zu lesen, öffentliches Web hereinzuholen oder für eine Rückfrage zu pausieren. Wichtig für das Verständnis: sys ist ausdrücklich kein Modellwerkzeug. Der Agent ruft es nicht direkt auf, sondern über run.

Installation als entpackte Erweiterung, ohne npm im Alltag

Es gibt keine Chrome-Web-Store-Listung. Der Weg führt über das Release-Zip oder über einen Klon des Repositories, aus dem der Ordner extension/ verwendet wird. In Chrome dann chrome://extensions öffnen, den Entwicklermodus aktivieren, Load unpacked wählen und den Ordner auswählen, in dem manifest.json auf oberster Ebene liegt. Danach das Side Panel öffnen, einen BYOK-Schlüssel unter dem Schlüssel pagewand_providers eintragen und eine Aufgabe auf einer normalen http- oder https-Seite abschicken. Für die Aktualisierung nach Dateiänderungen nennt die README einen konkreten Schritt: auf der Erweiterungskarte die Schaltfläche 重新加载 drücken. Ein tägliches npm entfällt laut Dokumentation. Für die Tests im Repository steht der Befehl node --test tests/runtime-regression.test.mjs bereit.

Versionsgrenzen, CDP_BUSY und NEED_PAGE

Die README listet Fehlerfälle mit eigenen Bezeichnern, und das ist nützlicher als eine allgemeine Kompatibilitätsaussage. Chrome 135 oder neuer wird vorausgesetzt. Ab Chrome 138 muss in den Erweiterungsdetails Allow User Scripts gesetzt werden, wenn sys.eval oder Seitenabrufe gebraucht werden. Vor einem CDP-Zugriff muss die Entwicklerkonsole auf dem Ziel-Tab geschlossen sein, sonst bricht der Aufruf mit CDP_BUSY ab. Eingeschränkte Seiten wie chrome:// oder der Web Store liefern NEED_PAGE zurück. Diese drei Punkte entscheiden, ob die erste Aufgabe überhaupt laufen kann. Wer die Erweiterung ohne diese Voraussetzungen lädt, bekommt keinen Fehler beim Installieren, sondern erst beim Ausführen. Das ist eine bewusste Entscheidung für einen kleinen, klar abgegrenzten Funktionsumfang und gegen breite Kompatibilität.

Kein gehostetes Modell, kein Skill-Katalog

Zwei Einschränkungen sollte man vor dem Laden kennen. Erstens: Es gibt kein gehostetes Modell. Der Zugang läuft über BYOK, der Schlüssel wird laut README unter pagewand_providers hinterlegt. Wer keinen eigenen Modellzugang hat, kann die Erweiterung nicht sinnvoll nutzen. Zweitens: Es gibt keinen Katalog. Ausgeliefert wird ein einziges Skill namens page-restyle. Alles andere muss über run und sys selbst gebaut werden. Das ist die eigentliche Grenze des Projekts. Die README nennt plausible Anwendungsfälle, darunter das Umgestalten einer Seite, das Auslesen einer angemeldeten Ansicht über sys.fetch als Seite in eine Tabelle, das Ausfüllen von Formularen über action mit snapshot und fill_form, Downloads mit Seitenidentität über sys.download, Tab-Batches oder das Verweilen auf einer SPA nach navigate sowie ein Lesehilfe-Overlay im selben Tab. Diese Liste ist ausdrücklich keine Benchmark-Angabe und kein Store. Wer für einen dieser Fälle eine fertige Lösung sucht, wird sie hier nicht finden.

Wo eine klassische Userscript-Umgebung die einfachere Wahl bleibt

Der naheliegende Vergleich ist eine Userscript-Umgebung wie Tampermonkey. Der Unterschied liegt im Ansatz, nicht im Funktionsumfang. Ein Userscript ist ein festes Programm: Man schreibt es einmal, es läuft bei jedem Seitenaufruf nach denselben Regeln. PawWork_ZhuaZhua geht den umgekehrten Weg. Die Aufgabe wird pro Sitzung in natürlicher Sprache beschrieben, der Agent entscheidet, welche Werkzeuge er aufruft, und das Ergebnis ist eine editierbare Office-Datei oder eine Sitzungsansicht. Das ist flexibler bei einmaligen oder wechselnden Aufgaben und schwächer bei Wiederholbarkeit. Ein Userscript verhält sich deterministisch, kostet keine Modellaufrufe und braucht keinen Schlüssel. Der Agent kostet pro Ausführung Modellaufrufe und kann bei unklarer Beschreibung den falschen Weg wählen. Für eine Aufgabe, die täglich identisch abläuft, ist das Userscript die günstigere und stabilere Wahl. Für eine Aufgabe, die man einmal beschreibt und dann anders wiederholt, spricht mehr für den Agenten.

Wartung, Aktualisierung und MIT-Lizenz

Die Wartungslast ist gering, solange man die Erweiterung nicht selbst verändert. Nach Änderungen im Ladordner genügt ein Klick auf 重新加载 auf der Erweiterungskarte, ein tägliches npm entfällt laut README. Wer das Repository klont statt das Release-Zip zu verwenden, muss den Ordner extension/ selbst aktualisieren, wenn neue Commits erscheinen. Die letzten veröffentlichten Stände sind v1.0.0-unpacked vom 9. September 2026 sowie zwei frühere unpacked-Stände vom 1. September 2026; die Versionsbezeichnung unpacked macht bereits deutlich, dass es keinen stabilen Veröffentlichungszyklus gibt. Das Projekt steht unter der MIT-Lizenz. Das erlaubt Weitergabe und Änderung unter Beibehaltung des Lizenzhinweises, und es enthält keine Klauseln zu Patenten oder Marken. Für die Nutzung eines eigenen Modellschlüssels ist die Lizenz des Projekts ohnehin nicht der relevante Punkt; dort gelten die Bedingungen des jeweiligen Anbieters. Eine rechtliche Bewertung ist damit nicht verbunden, und die README gibt dazu auch nichts weiter her.

Redaktionelles Fazit

Wer einen BYOK-Agenten auf einem bereits angemeldeten Chrome-Tab braucht und mit einer entpackten Erweiterung leben kann, findet hier einen klar abgegrenzten Werkzeugkasten: action für DOM-Mutationen, run plus sys für Gast-JavaScript, sheet/doc/web für die Sitzung. Wer eine Installation aus dem Chrome Web Store, einen gehosteten Modellzugang oder einen Katalog fertiger Skripte erwartet, ist hier falsch. Prüfen sollte man zuerst, ob Chrome 135 oder neuer läuft, ob für sys.eval und Seitenabrufe unter Chrome 138 und neuer Allow User Scripts gesetzt ist, und ob auf dem Ziel-Tab die Entwicklerkonsole geschlossen ist, weil CDP sonst mit CDP_BUSY abbricht.

Offizielle Quellen

1. Issues
2. License: MIT
3. Player-YN/PawWork_ZhuaZhua on GitHub
4. README
5. Releases