KI-Browser-Agenten brauchen einen eigenen Browser
Wer einem autonomen Agenten den Alltagsbrowser überlässt, gibt ihm Cookies, Anmeldungen und Gerät. Warum Agenten in ein isoliertes Profil gehören und wie Sie ihnen eines geben.
Der schnellste Weg, einem KI-Agenten echte Fähigkeiten im Web zu geben, ist, ihn einen Browser steuern zu lassen. Der schnellste Weg, das zu bereuen, ist, ihn Ihren steuern zu lassen. Ein Alltagsbrowser trägt jede Sitzung, in der Sie je angemeldet waren, und ein Agent, der klicken kann, kann alles anklicken, was diese Sitzungen erreichen.
Das Problem des Schadensradius
Ein Agent, der Lieferanten recherchieren soll, hat nicht vor, Ihren Banking-Tab zu öffnen. Aber der Browser, in dem er läuft, macht keinen Unterschied: ein Cookie-Verzeichnis, ein Satz gespeicherter Anmeldungen, eine Rechneridentität. Wohin der Agent auch navigieren kann, dort ist er bereits authentifiziert. Die Maßnahmen, zu denen man zuerst greift — ein separates Chrome-Profil, ein Inkognito-Fenster —, verschieben die Cookies, ohne sonst etwas zu verschieben.
Was Isolation tatsächlich abdecken muss
- Speicher: eigenes Cookie-Verzeichnis, eigener Local Storage und eigene IndexedDB, in einem Verzeichnis, in das nichts anderes schreibt
- Zugangsdaten: nur die Anmeldungen, die Sie bewusst in dieses Profil eingetragen haben, keine anderen
- Netzwerk: eine eigene Route, damit Agenten-Traffic und Ihr Traffic nicht dieselbe Adresse haben
- Geräteidentität: stabil für dieses Profil und keine Kopie des Rechners, an dem Sie arbeiten
- Erweiterungen: nur was der Agent braucht, nicht Ihr Passwortmanager
Diese Liste ist dieselbe, die ein isoliertes Browserprofil ohnehin erfüllt. Ein Agent ist aus Sicht des Browsers nur ein weiterer Benutzer Ihres Rechners, der den Rest Ihrer Arbeit nicht sehen können sollte.
Einem Agenten ein Profil geben
In PowerOps ist das Muster kurz. Legen Sie ein Profil für den Agenten an, geben Sie ihm die Route, auf der sein Traffic laufen soll, und melden Sie nur bei den Konten an, die diese Aufgabe braucht. Starten Sie es dann über die Local API, die den Debugging-Endpunkt des Browsers zurückgibt, und richten Sie Ihr Agenten-Framework auf diesen Endpunkt statt auf einen Browser, den es selbst gestartet hat.
# Start the agent's profile and take the endpoint it returns.
curl -s -X POST http://127.0.0.1:50326/v1/browsers/start \
-H "Authorization: Bearer $POWEROPS_KEY" \
-H "Content-Type: application/json" \
-d '{"profileId": "agent-research-01"}'Alles, was das Chrome DevTools Protocol spricht, verbindet sich mit dem, was dieser Aufruf zurückgibt — Puppeteer, Playwright oder ein Agenten-Framework, das eines von beiden umhüllt. Am Code des Agenten ändert sich nichts; es ändert sich der Browser, in dem er landet.
Ein Profil pro Aufgabe, nicht pro Agent
Der Instinkt ist, dem Agenten ein Profil zu geben. Die bessere Einheit ist die Aufgabe. Ein Profil für die Lieferantenrecherche, ein Profil für das Konto, von dem er posten darf, ein Profil für das Dashboard, das er liest. Läuft ein Durchlauf schief, ist der Schaden durch das begrenzt, was dieses eine Profil erreichen konnte, und Sie können das Verzeichnis wegwerfen und neu beginnen.
Durchläufe vergleichbar halten
Agenten sind schwer zu debuggen, weil zwei Durchläufe selten derselbe Durchlauf sind. Ein Profil, das bei jedem Start dasselbe Gerät meldet, über dieselbe Route, mit dem Zustand, in dem Sie es verlassen haben, beseitigt eine ganze Klasse von Unterschieden zwischen Versuchen. Verhält sich ein Durchlauf anders, gehört die Umgebung nicht mehr zu den Verdächtigen.
Die Grenze
Nichts davon ist ein Weg an den Nutzungsbedingungen, Ratenbegrenzungen oder der robots-Richtlinie einer Seite vorbei, und es wird auch nicht als solcher verkauft. Es gibt einem Agenten einen Browser, der der Aufgabe gehört und nicht Ihnen.
