Die gezeigte Architektur für eine Chrome-Erweiterung mit Transformers.js unter Manifest V3 platziert die zentrale Orchestrierung und die Modellausführung im Background-Service-Worker, nutzt ein Side-Panel für die Chat-Oberfläche und ein Content-Script für seitenbezogene Aktionen wie DOM-Extraktion und Hervorhebungen. Die Umsetzung orientiert sich an der Erweiterung Transformers.js Gemma 4 Browser Assistant und deren Open-Source-Codebasis.
Im Manifest sind dafür drei Einstiegspunkte definiert: background.service_worker für background.js, side_panel.default_path für sidebar.html und ein Content-Script content.js für http(s)://*/* mit run_at: document_idle. Der Background-Service-Worker behandelt außerdem chrome.action.onClicked, um das Side-Panel für den aktiven Tab zu öffnen. Der Beitrag erwähnt, dass statt eines Side-Panels auch ein Popup über action.default_popup verwendet werden kann; das Orchestrierungsmuster bleibt dabei gleich.
Die zentrale Entwurfsentscheidung ist, die schwere Orchestrierung im Background zu halten und UI- sowie Seitenlogik schlank zu lassen. Der Background fungiert als Control Plane für Agent-Lebenszyklus, Modellinitialisierung, Tool-Ausführung und gemeinsame Dienste wie Feature-Extraction. Das Side-Panel übernimmt Ein- und Ausgabe des Chats, Streaming-Updates und Setup-Steuerung. Das Content-Script dient als Brücke zur Seite und führt DOM-Extraktion sowie Highlight-Aktionen aus.
Ein praktischer Effekt dieser Aufteilung ist, dass auch der Gesprächsverlauf im Background liegt, konkret in Agent.chatMessages. Die UI sendet Ereignisse wie AGENT_GENERATE_TEXT, der Background ergänzt die Nachricht, führt die Inferenz aus und sendet anschließend MESSAGES_UPDATE an das Side-Panel zurück. Laut Beitrag vermeidet diese Trennung doppelte Modell-Ladevorgänge, hält die UI reaktionsfähig und berücksichtigt die Sicherheitsgrenzen von Chrome beim DOM-Zugriff.
Die Kommunikation zwischen den Laufzeitumgebungen bildet das Rückgrat der Erweiterung. Nachrichten werden typisiert über Enums in src/shared/types.ts. Vom Side-Panel an den Background gehen unter anderem CHECK_MODELS, INITIALIZE_MODELS, AGENT_INITIALIZE, AGENT_GENERATE_TEXT, AGENT_GET_MESSAGES, AGENT_CLEAR und EXTRACT_FEATURES. Vom Background an das Side-Panel gehen DOWNLOAD_PROGRESS und MESSAGES_UPDATE. Vom Background an das Content-Script gehen EXTRACT_PAGE_DATA, HIGHLIGHT_ELEMENTS und CLEAR_HIGHLIGHTS. Die Regel dabei ist, dass der Background als einziger Koordinator arbeitet, während Side-Panel und Content-Script spezialisierte Clients bleiben.
Für die Modellrollen verwendet die Erweiterung in src/shared/constants.ts zwei Modelle: onnx-community/gemma-4-E2B-it-ONNX für text-generation mit q4f16 sowie onnx-community/all-MiniLM-L6-v2-ONNX für feature-extraction mit fp32. Gemma 4 übernimmt Reasoning und Tool-Entscheidungen, während MiniLM Vektor-Embeddings für semantische Ähnlichkeitssuche in ask_website und find_history erzeugt.
Die gesamte Inferenz läuft im Background. Für Textgenerierung wird pipeline("text-generation", …) mit aktiviertem konsistentem KV Caching über die neue Klasse DynamicCache verwendet; für Embeddings pipeline("feature-extraction", …) plus Vektor-Normalisierung. Dadurch gibt es einen zentralen Modell-Host für alle Tabs und Sitzungen, die Speichernutzung wird nicht durch doppelte Instanzen erhöht, und die Side-Panel-UI bleibt schlank. Da die Modelle im Background-Service-Worker geladen werden, werden Artefakte unter dem Erweiterungs-Ursprung chrome-extension://<extension-id> gecacht statt pro Website-Ursprung, was einen gemeinsamen Cache für die gesamte Installation ergibt.
Der Beitrag weist zugleich auf den MV3-Lebenszyklus hin: Service Worker können angehalten und neu gestartet werden. Modellzustand zur Laufzeit sollte deshalb als wiederherstellbar behandelt und bei Bedarf neu initialisiert werden. Entsprechend ist der Modelllebenszyklus explizit gestaltet: CHECK_MODELS prüft vorhandene Caches und schätzt die verbleibende Download-Größe, INITIALIZE_MODELS lädt und initialisiert die Modelle und sendet dabei DOWNLOAD_PROGRESS an die UI. Danach werden langlebige Instanzen wiederverwendet, etwa die Generation-Pipeline in src/background/agent/Agent.ts und die Embedding-Pipeline in src/background/utils/FeatureExtractor.ts.
Auch Berechtigungen und Datenschutz werden als Teil der Architektur beschrieben. Im Manifest fordert das Projekt sidePanel, storage, scripting und tabs sowie host_permissions für http(s)://*/* an. sidePanel wird für die Steuerung der Side-Panel-Oberfläche benötigt, storage für das Persistieren von Tool- und Einstellungzuständen über Sitzungen hinweg, tabs und scripting für tabbezogene Tools und Seitenaktionen sowie die Host-Berechtigungen für Extraktion und Hervorhebung auf beliebigen Websites. Der Beitrag betont, Berechtigungen eng zu halten und klar zu kommunizieren, dass die Inferenz lokal in der Laufzeitumgebung der Erweiterung erfolgt.
Für Tool Calling wird ein Schema mit name, description und parameters zusammen mit Nachrichten an das Modell übergeben. Transformers.js formatiert daraus über das jeweilige Chat-Template des Modells den eigentlichen Prompt. Da Chat-Templates modellspezifisch sind, hängt das Format von Tool Calls vom verwendeten Modell ab. Bei Gemma-4-ähnlichen Templates erzeugt das Modell einen speziellen Tool-Call-Token-Block, wenn es ein Tool aufrufen will.
Genau dafür gibt es in diesem Projekt eine Normalisierungsschicht webMcp und einen Parser extractToolCalls, damit Modellausgabe in deterministische Tool-Ausführungen überführt wird. src/background/agent/webMcp.tsx normalisiert Erweiterungs-Tools in eine modellfreundliche Form mit name, description, inputSchema und execute. Genannte Werkzeuge sind unter anderem get_open_tabs, go_to_tab, open_url, close_tab, find_history, ask_website und highlight_website_element.
Ein weiterer Entwurfspunkt ist die Trennung zwischen internem Modell-Transkript und UI-seitigem Chat-Verlauf. Das interne Transkript enthält system-, user-, tool– und assistant-Turns für die Nachrichten an generator(…). Das UI-Transkript chatMessages enthält die sichtbaren Assistentenantworten, Tool-Metadaten und Leistungsmetriken. Der Ablauf ist dabei: Nutzereingabe zu chatMessages hinzufügen, eine Platzhalter-Antwort erzeugen und Tokens streamen; gestreamte oder finale Modellausgabe mit extractToolCalls.ts in { message, toolCalls } zerlegen; die sichtbare Assistentenantwort als Klartext belassen, während Tool Calls im Background ausgeführt werden; Tool-Ergebnisse an die Tool-Metadaten anhängen und als nächsten Prompt-Turn zurückführen; den Vorgang wiederholen, bis keine Tool Calls mehr vorliegen.
Auch die Platzierung des Zustands wird nach Lebenszyklus und Zugriffsmuster aufgeteilt. Gesprächszustand liegt im Speicher des Backgrounds in Agent.chatMessages. Tool-Präferenzen werden in chrome.storage.local gespeichert, damit sie sitzungsübergreifend erhalten bleiben. Semantische Verlaufsvektoren liegen in IndexedDB über VectorHistoryDB. Extrahierte Seiteninhalte werden im Background-Cache WebsiteContentManager abgelegt und nach aktiver URL indiziert. Ziel dieser Aufteilung ist, kurzlebigen Zustand im Speicher, dauerhafte Einstellungen im Erweiterungsspeicher und größere Retrieval-Daten in einer lokalen Datenbank zu halten.
Für den Build ist laut Beitrag keine komplexe Konfiguration nötig, MV3 verlangt aber vorhersagbare Ausgaben für jede Laufzeitumgebung. In vite.config.ts wird dafür ein Multi-Entry-Build genutzt, dessen Ausgabe-Namen und -Pfade mit dem Manifest übereinstimmen müssen, etwa sidebar.html, background.js und content.js. Das Content-Script soll als in sich geschlossene Ausgabe erzeugt werden, um Probleme mit dem Nachladen von Chunks zur Laufzeit zu vermeiden.
Abschließend wird die Trennung der Zuständigkeiten als grundlegendes Architekturprinzip beschrieben: Der Background besitzt Orchestrierung und Modellausführung, UI-Oberflächen bleiben schlank, Content-Scripts übernehmen den Seitenzugriff. Das gezeigte Muster lässt sich laut Beitrag auch auf andere Setups übertragen, etwa Popup-basierte Assistenten, Side-Panel-Copiloten, tab-spezifische Agenten oder hybride Oberflächen. Die praktische Regel dabei lautet, den Zustand klar zu verorten, Inferenz und Zustand im Background zu halten und UI- sowie Content-Laufzeiten als fokussierte Clients zu behandeln.
