Firecrawl gibt Mastra-Agenten einen gehosteten Browser für Seiten hinter dem Login

Ein Browser als einzelnes Feld am Agenten

Firecrawl argumentiert, dass die meisten Beiträge über Agenten und das Web davon ausgehen, dass die Seite öffentlich ist. Als Beispiel für alles, was darüber hinausgeht, nennt das Unternehmen das Lieferantenportal, in das sich ein Ops-Team jeden Morgen einloggt, oder einen Bericht, der erst existiert, nachdem ein Zeitraum gewählt und auf Export geklickt wurde. Wer die Inventarseite von Swag Labs, dem Demo-Shop von Sauce Labs, ohne Login aufruft, erhält eine Fehlermeldung: "You can only access '/inventory.html' when you are logged in."

Die neue Klasse FirecrawlBrowser wird über ein Feld browser an einen Mastra-Agenten gehängt, so wie auch Tools und Memory. Sie erweitert AgentBrowser, sodass der Agent die 16 Browser-Tools erhält, die AgentBrowser standardmäßig bereitstellt, darunter browser_goto, browser_snapshot, browser_click und browser_type. Der Unterschied liegt laut Firecrawl darin, wo die Seite läuft: Mastra fordert bei der Firecrawl-API eine Session an und kommuniziert mit ihr über CDP.

Der Beispiel-Agent von Firecrawl ist mit maxSteps von 40 konfiguriert. Mastra stoppt einen Agenten standardmäßig nach fünf Schritten, und laut Firecrawl braucht ein Durchlauf vom Login bis zum Checkout rund 25 Schritte, weil jede Aktion einen eigenen Snapshot erhält.

Wie der Agent eine Seite liest und bedient

Statt rohem HTML erhält das Modell einen Snapshot der interaktiven Elemente der Seite, jeweils mit einer Referenz wie @e1. Auf der Demo-Loginseite enthält der Snapshot ein Textfeld für den Benutzernamen, ein Passwortfeld und einen Login-Button. Der Agent tippt und klickt anhand dieser Referenzen und erstellt anschließend einen neuen Snapshot.

Referenzen gelten nur innerhalb eines Snapshots, nicht über Navigationen hinweg. Firecrawl weist darauf hin, dass dieselbe Loginseite unterschiedliche Referenzen vergeben kann, etwa wenn ein Button "Dismiss error" erscheint und Login von @e3 auf @e4 verschiebt. Deshalb weisen die Anweisungen das Modell an, nie eine Referenz von einer früheren Seite zu erraten.

Standard-Snapshots listen nur interaktive Elemente auf. Um Text wie eine Bestellbestätigung zu lesen, übergibt das Modell interactiveOnly: false. In der Demo von Firecrawl meldete sich der Agent an, legte den Sauce Labs Backpack in den Warenkorb, schloss den Kauf ab und gab die Bestätigungszeile zurück, ohne handgeschriebene Selektoren oder seitenspezifischen Code.

Sessions, Threads und Profile

FirecrawlBrowser verwendet standardmäßig scope: 'thread'. Der erste Browser-Aufruf in einem Mastra-Thread erzeugt eine Firecrawl-Session, spätere Aufrufe nutzen sie weiter, solange sie aktiv ist, und die entfernte Session wird gelöscht, wenn der Browser des Threads schließt. Zwei Nutzer mit unterschiedlichen Thread-IDs erhalten isolierte Browser und getrennte Logins. Wird keine Thread-ID angegeben, teilen sich alle Aufrufer eine Standard-Session. Mit scope: 'shared' entsteht gezielt eine einzige Session, die sich alle teilen.

Sessions laufen ab. Firecrawl schließt eine Session nach ttl Sekunden Gesamtlaufzeit (Standard 600, maximal 3600) oder nach activityTtl Sekunden Inaktivität (Standard 300). Kehrt ein Thread später zurück, beginnt er ohne Cookies.

Um zwischen Durchläufen eingeloggt zu bleiben, bietet Firecrawl benannte Profile unter dem Schlüssel firecrawl an. Mit saveChanges: true werden Cookies und Login-Status beim Schließen der Session zurückgeschrieben, sodass die nächste Session bereits angemeldet startet. Firecrawl nennt zwei Einschränkungen:

• Das verschachtelte firecrawl.profile wird auf Seiten von Firecrawl gespeichert. Das Profil auf oberster Ebene stammt von AgentBrowser und verweist auf ein lokales Playwright-Benutzerdatenverzeichnis.
• Pro Profil kann immer nur eine Session speichern. Öffnet eine zweite Session das Profil mit saveChanges: true, wird sie mit einem 409 abgewiesen.

Als empfohlenes Muster gilt, sich einmal mit saveChanges: true einzuloggen und den regulären Betrieb dann mit saveChanges: false laufen zu lassen. Ein Profil entspricht einem Login, Portale mit Einzelkonten benötigen also ein Profil pro Nutzer, zum Beispiel portal-${userId}.

Was das für Entwickler bedeutet

Firecrawl zufolge beantworten Profile auch die Frage nach den Zugangsdaten. Eine Person oder ein Setup-Skript gibt das Passwort einmal in die Session ein, die das Profil speichert, und der Agent öffnet das Profil nur noch. Laut Firecrawl gelangt nichts Sensibles zum Modell, in die Traces oder ins Memory.

Der Provider wurde vom Firecrawl-Team entwickelt und liegt im Mastra-Monorepo. Zum Setup gehört die Installation von @mastra/core, @mastra/memory, @mastra/libsql, @mastra/browser-firecrawl und [email protected], anschließend werden FIRECRAWL_API_KEY und der Schlüssel eines Modellanbieters wie OPENAI_API_KEY gesetzt. Memory benötigt einen Storage-Provider an der Mastra-Instanz, den das Gerüst von create-mastra bereits mitbringt.

Für Teams, die Agenten für authentifizierte Tools bauen, entfällt mit dem Paket der Betrieb und die Pflege eines lokalen Browsers, während die Tool-Schnittstelle gleich bleibt.