Amazon Nova Act kann über eine Webseite nachdenken und auf ihr agieren. Im Jahr 2026 ist der schwierige Teil eines produktiven Web-Agenten nicht das Modell. Es ist der Webzugang: das zuverlässige Erreichen des Live-Webs, mit dem richtigen Geo-Targeting und unter Einhaltung der Compliance. Dieser Artikel kombiniert Nova Act mit Bright Datas Web-Zugangsschicht für KI-Agenten, und die hier vorgestellten Messungen stammen aus Live-Ausführungen.
TL;DR
Der Engpass für einen produktiven KI-Web-Agenten ist der Webzugang, nicht das Modell. Die Lösung ist eine Aufteilung: Amazon Nova Act trifft die mehrstufigen Browser-Entscheidungen, und Bright Datas Web-Zugangsschicht übernimmt Zugang, Compliance und Skalierung. Bright Datas Daten für KI 2026-Bericht zeigt, dass 97 % der KI-Organisationen auf Echtzeit-Webdaten angewiesen sind und 90 % angeben, dass Zugangseinschränkungen ihre KI-Initiativen begrenzen.
Das vollständige, ausführbare Skript mit allen Importen, Schemata und Hilfsfunktionen befindet sich im Begleit-Repo. Klone es, wenn du es ausführen möchtest, anstatt es von hier zu kopieren.
Um mitzumachen, benötigst du Python 3.10+, pip install nova-act und einen Nova Act API-Schlüssel von nova.amazon.com/act. Du brauchst außerdem ein Bright Data-Konto mit einer Browser-API-Zone sowie einen API-Schlüssel für die Datenschicht-Aufrufe. Node.js wird nur für den Web-MCP-Abschnitt benötigt.
Warum der Browser-Agent-Standard nicht ausreicht
Der naheliegende Ansatz mit einem Browser-Agenten ist es, ihn alles erledigen zu lassen. Eine Seite öffnen, das Cookie-Banner schließen, scrollen, extrahieren. Das sieht in einer Demo gut aus, ist aber für die meisten Datenarbeiten der falsche Standard.
- Er ist schwerfällig. Eine einzelne echte Verbraucherseite (eine eBay-Suche) übertrug etwa 3,4 MB durch den Browser. Multipliziert mit Millionen von Seiten zahlst du dafür, das gesamte gerenderte Web, einschließlich jedes Bildes, zu übertragen, nur um drei Felder zu extrahieren.
- Er ist fragil beim Agieren. Auf booking.com warf Nova Act einen
ActActuationErrorbeim Kampf mit Popups und lazy-geladenen Inhalten, obwohl die Seite einwandfrei geladen wurde. Einfache Lesevorgänge sind meist zuverlässig. Die schwere mehrstufige Ausführung bricht dort zusammen. - Er ist nicht-deterministisch. Die Zuverlässigkeit sinkt schnell. Zehn zu 90 % zuverlässige Schritte ergeben etwa
0,9¹⁰ ≈ 35 %, wenn man nicht plant.
Das macht Browser-Agenten nicht nutzlos. Nutze sie also für das, was nur sie können (die mehrstufigen Aktionen und Entscheidungen), und verlagere alles andere in die Infrastruktur.
Was Amazon Nova Act ist und was nicht
Nova Act ist ein AWS-SDK, Version 3.4.x Mitte 2026, das sich von der Forschungsvorschau in Richtung Produktion bewegt, um Browser-Agenten in Python zu erstellen. Sein Designprinzip ist das Gegenteil eines riesigen Prompts. Du zerlegst einen Workflow in kleine, atomare, zuverlässige Befehle und verbindest sie mit normalem Python. Die zwei Befehle sind eine Aktion und ein typisierter Lesevorgang:
from nova_act import NovaAct
from pydantic import BaseModel
class Product(BaseModel):
title: str | None = None
price: str | None = None
availability: str | None = None
with NovaAct(starting_page="https://example.com/product/123") as nova:
nova.act("search for wireless headphones") # an action
data = nova.act_get( # a typed read
"Return the product title, price, and availability.",
schema=Product.model_json_schema(),
)Mit einem Pydantic-Schema kann act_get eine Seite ohne fragile Selektoren in typisierte Daten umwandeln. Nova Act steuert ein echtes Chromium durch Playwright darunter, ein Detail, das für die Verbindung wichtig ist. Nova Act gibt dir Reasoning, Navigation und strukturierte Extraktion. Es gibt dir keine Antwort auf die Feindseligkeit des offenen Webs. Es hat keine geografische Reichweite, kein Unblocking im großen Maßstab, keine eingebaute Compliance. Das ist nicht seine Aufgabe. Das ist die Aufgabe der Infrastrukturschicht.
Bright Data, die Web-Zugangsschicht
Die Schicht basiert auf einer Idee: das Web für deine KI zu erschließen. Web MCP, ein Model Context Protocol Server, gibt einem Agenten strukturierte Web-Tools, die er direkt aufruft. Web Unlocker und die SERP-API liefern saubere Seiten und Suchergebnisse. Die Web Scraper APIs und Datensätze erledigen den strukturierten Massenabruf. Die Browser API ist ein Cloud-Chrome, den du fernsteuerst, für die Fälle, in denen ein Agent handeln muss. Darunter liegt ein Netzwerk von 400 Mio.+ Residential-IPs in 195 Ländern, mit automatischer Handhabung von CAPTCHA-Herausforderungen, Fingerprint-Management und Geo-Targeting.
In Bright Datas Umfrage Daten für KI 2026 stimmen 87 % der Organisationen zu, dass ein ‘zweistufiges Internet’ entsteht, ein agentisches Web aus automatisiertem Traffic neben dem menschlichen. Und 65 % verlassen sich bereits auf einen dedizierten Web-Daten-Infrastrukturanbieter, anstatt den Zugang intern aufzubauen.
Das ist eine Schicht, kein Tool. Dein Agenten-Stack ändert sich. Die darunter liegende Web-Zugangsschicht nicht. Die technische Frage ist also nie Browser versus API im Abstrakten. Du teilst die Aufgabe in zwei: Der Agent übernimmt die Entscheidungen, die Infrastruktur den Zugang.
Die Architektur, Gehirn oben und Infrastruktur darunter
Nova Act sendet Aktionen nach unten, und strukturierte Daten kommen zurück.
Nova Act trifft die Entscheidungen und Aktionen. Bright Datas Web-Zugangsschicht übernimmt Zugang, Compliance, Geografie und Skalierung und erreicht dann das Live-Web.
Für den Aktionsmodus verbindet sich Nova Act mit Bright Datas Browser API über das Chrome DevTools Protocol (CDP), dasselbe Protokoll, das Playwright (und damit Nova Act) bereits spricht. Du tauschst den Browser aus und behältst den Agenten.
Die Verbindung herstellen und die zu erwartenden Setup-Fehler
Erstelle eine Browser-API-Zone (ihr CAPTCHA-Löser ist standardmäßig aktiviert) und das Dashboard gibt dir eine URL:
wss://brd-customer-<id>-zone-<name>:<password>@brd.superproxy.io:9222Dieser String kommt vom Tab ‘Übersicht’ der Zone unter ‘Zugriffsdetails’.
Die Zugriffsdetails der Browser-API-Zone. Das Dashboard gibt dir den wss://-String mit eingebetteten Anmeldedaten, die auth+@host-Form oben im Panel. Modernes Playwright lehnt diese eingebettete Form ab, daher verschiebt split_cdp() die Anmeldedaten in einen Authorization: Basic-Header. Die IP-Allowlist auf der linken Seite ist die andere Falle. Wenn deine IP dort nicht aufgeführt ist, gibt der Aufruf einen leeren Body zurück und der Grund steht in den Antwort-Headern statt im Statuscode.
Der Invalid URL-Fehler: Playwright lehnt eingebettete wss://-Anmeldedaten ab
Direkt in Nova Act eingefügt, schlägt es fehl:
playwright._impl._errors.Error: BrowserType.connect_over_cdp:
Invalid URL: wss://brd-customer-...:[email protected]:9222Das ist ein häufiger Fehler beim ersten Start. Modernes Playwright, Version 1.56, mit Nova Act 3.4 gebündelt, lehnt Anmeldedaten ab, die in eine WebSocket-URL eingebettet sind. Das Dashboard zeigt die eingebettete Form, weil sie mit älteren Clients funktioniert, nicht mit dem Playwright innerhalb von Nova Act. Die Lösung besteht darin, die Anmeldedaten herauszulösen und sie als Authorization: Basic-Header über cdp_headers zu übergeben.
import os
import base64
def split_cdp(raw_url: str) -> tuple[str, dict | None]:
"""Bright Data gives an inline-credential wss URL; Playwright rejects that.
Move credentials into a Basic auth header. (Parsed manually because
Python 3.14's urlsplit also rejects the multi-colon netloc.)"""
scheme, sep, rest = raw_url.partition("://")
if not sep or "@" not in rest:
return raw_url, None
creds, _, hostport = rest.rpartition("@")
user, _, pwd = creds.partition(":")
token = base64.b64encode(f"{user}:{pwd}".encode()).decode()
return f"{scheme}://{hostport}", {"Authorization": f"Basic {token}"}
endpoint, headers = split_cdp(os.environ["BRIGHTDATA_CDP_URL"])
with NovaAct(starting_page=URL, cdp_endpoint_url=endpoint, cdp_headers=headers,
logs_directory="runs/demo") as nova: # NOTE: logs dir must already exist
...Die intermittierende InvalidScreenResolution-Falle
Die andere große Falle ist der Viewport. Bright Datas Remote-Browser gibt Nova Act ein Fenster von etwa 1280×585, was kleiner ist als die von Nova Act erwarteten rund 1600×900. Nova Act degradiert nicht sanft. Es wirft einen intermittierenden harten InvalidScreenResolution-ActError. Er ist intermittierend, weil jede Cloud-Sitzung eine etwas andere Größe erhält. Das macht ihn schwer zu diagnostizieren und leicht als flüchtigen Agenten zu missdeuten, der einen Neuversuch benötigt. Erzwinge eine unterstützte Größe auf der verbundenen Seite:
with NovaAct(starting_page=URL, cdp_endpoint_url=endpoint, cdp_headers=headers,
screen_width=1600, screen_height=900, logs_directory="runs/demo") as nova:
nova.page.set_viewport_size({"width": 1600, "height": 900}) # force a supported size to stop InvalidScreenResolution
...Zwei kleinere Fallen: StartFailed und ein fehlendes logs_directory
Übergib nicht headless=True zusammen mit cdp_endpoint_url, da der Remote-Browser bereits headless ist und du StartFailed erhältst. Und logs_directory muss vor dem Start existieren, da Nova Act den Pfad validiert und ihn nicht erstellt.
Wofür der Agent gedacht ist
Mit der hergestellten Verbindung stellt sich die Frage, was der Agent tun soll. Ein einfacher Lesevorgang ist das Uncharakteristischste, was er bietet, und Bright Datas Web Scraper APIs machen das besser und günstiger. Ein Agent ist mehr wert als ein Scraper, weil er handeln kann.
Seine nützlichste Aktion ist das Erreichen von Daten hinter einem Formular. Es gibt keine statische URL, die man im Voraus kennen müsste, und keine API, also hat ein Scraper nichts, worauf er zugreifen könnte. Ein Agent kann das Formular ausfüllen und das Ergebnis lesen. Deshalb haben wir Nova Act auf Drugs@FDA gerichtet, die maßgebliche US-Arzneimittelzulassungsdatenbank, und ihn gebeten, einen Arzneimitteleintrag abzurufen:
nova.act("Search for the drug named ibuprofen") # fill the form, submit
drug = nova.act_get("Return the brand name, active ingredient, application number, "
"and marketing status of the first result.", schema=Drug.model_json_schema())Sein eigenes Trace zeigt einen vierstufigen Ablauf, den keine URL erfasst. Er tippte in das Suchfeld und drückte Enter, fand das erste Ergebnis zugeklappt und klickte, um es aufzuklappen, navigierte zur Detailseite und las dann die Felder:
{'drug_name': 'ACETAMINOPHEN AND IBUPROFEN', 'active_ingredient': 'ACETAMINOPHEN; IBUPROFEN',
'application_number': '214836', 'marketing_status': 'Over-the-counter'} # all 4 DOM-groundedDiese vier Schritte im Browser:
Eine echte Aufnahme des Durchlaufs, Bild für Bild. Nova Act sucht ‘ibuprofen’ auf Drugs@FDA, öffnet das erste Ergebnis und liest ANDA #214836, dieselbe Antragsnummer, die der Durchlauf zurückgab.
Wir führten es mit verschiedenen Arzneimitteln durch, um die Konsistenz zu bestätigen: Aspirin ergab 8-HOUR BAYER (#016030) und Metformin ergab ACTOPLUS MET (#021842). Mit Ibuprofen sind das 3/3, jedes Feld verankert. Hier rechtfertigt der Agent seine Kosten. Der Agent füllt das Formular aus und navigiert zu maßgeblichen, formulargeschützten öffentlichen Daten, die ein Scraper nicht erreichen kann. KI in tiefen öffentlichen Web-Daten zu verankern ist ein echtes Problem. Auf einer kooperativen, gut strukturierten Seite ist es zuverlässig.
Der lange Schwanz
Derselbe Ansatz deckt den langen Schwanz ab, die Nischenseiten ohne vorgefertigten Scraper. Bright Datas Web Scraper APIs decken bereits über 100 der wertvollsten ab. Auf BoardGameGeek gerichtet, gab Nova Act einen sauberen sechsfeldigen Datensatz zurück, Catan / 1995 / 3,4 Spieler / 60,120 Min / Bewertung 7,1 / günstigster Preis. Du verifizierst es gegen das Live-DOM über nova.page, das Playwright-Handle, in derselben Sitzung:
assert game.parsed_response["bgg_rating"] in nova.page.inner_text("body") # 7.1 -> presentZwei Verankerungslektionen kamen hervor. Normalisiere vor dem Vergleich, denn der Gedankenstrich der Seite 3,4 gegen den Bindestrich des Agenten 3-4 ist eine falsche Nichtübereinstimmung, keine Halluzination. Und verifiziere in der Sitzung, niemals später, denn ein Live-Marktplatzpreis war zum Extraktionszeitpunkt verankert und bei einem Neuladen verschwunden, sodass eine zweite Prüfung flüchtiger Daten falsch sein kann. Mit diesen Maßnahmen waren alle sechs Felder verankert. Es hielt auch unter einem fünffachen parallelen Durchlauf stand.
Die Grenze liegt am Terrain, nicht an der Aufgabe. Nova Act kämpft auf feindseligen Verbraucherseiten wie eBay und booking.com: bot-verteidigter eCommerce mit Cookie-Walls, benutzerdefinierten Variations-Widgets und lazy-geladenen Inhalten. Auf diesen Seiten verlangsamen sich die mehrstufigen Aktionen und werden unzuverlässig, und schwere Ketten laufen in Timeouts. Es ist zuverlässig auf kooperativen, strukturierten Seiten: öffentliche Datenbanken, interne Apps und gut gebaute Formulare. Es ist fragil auf feindseligen Verbraucherseiten. Halte Aktionen gering, verifiziere jedes Feld mit nova.page, wiederhole und lass Bright Datas Datenschicht die feindseligen, hochvolumigen Fälle handhaben.
Was Geo-Routing tatsächlich verändert
Kein lokaler Browser kann das ohne dieselbe Routing-Infrastruktur darunter. Wir führten dieselbe Hotelsuche auf einer großen Buchungsseite durch, durch drei Länder geleitet, indem wir -country-XX zum Bright Data-Benutzernamen hinzufügten:
| Geleitet über | Währung | Beispiel-Nachtpreise |
|---|---|---|
| Vereinigte Staaten | US$ | US$30, US$128, US$171 |
| Vereinigtes Königreich | £ | £30, £167, £194 |
| Deutschland | € | €40, €194, €225 |
Die Währung wechselt sauber und die Preise spiegeln echte Marktunterschiede wider, keine Umrechnung. Wir lasen diese drei mit einem rohen Browser, weil Geografie die Aufgabe der Infrastruktur ist, nicht des Agenten. Der Agent extrahiert, auf welchen Markt er gerichtet ist, genauso wie beim US-gerouteten eBay-Durchlauf. Das ist wichtig für die Wettbewerbsanalyse von Preisen, die Tarifaggregation oder jeden Fall, in dem du es so sehen musst, wie es ein lokaler Kunde sieht.
Was für einen Durchlauf wichtig ist, ist die IP, von der du ausgehst, also prüften wir jede geroutete Sitzung. Die Ausgangs-IPs kamen als echte Verbraucher-ISPs zurück, keine Datacenter-Bereiche: ein großer US-Kabelanbieter, ein britischer Breitbandanbieter, ein deutsches Mobilfunknetz, ein japanischer Carrier und ein brasilianischer regionaler ISP.
Das ist der Unterschied zwischen lokal aussehen und lokal sein. Die Anfrage kommt als echter Residential-Nutzer in diesem Land an. Daher sind Preise, Inventar und Anti-Bot-Behandlung viel näher an dem, was ein lokaler Kunde sieht, als an dem, was ein markierter Datacenter-Bereich erhält.
Compliance, das 90-%-Problem
Hier sind Zugangseinschränkungen wichtig, das 90-%-Problem selbst: Die meisten KI-Organisationen sagen, dass diese Einschränkungen ihre KI-Initiativen begrenzen. Hier fungiert Bright Data als Leitplanke. Auf eine Flug-Metasuchseite gerichtet, wurde dem Agenten der Zugang verweigert:
Page.navigate: Requested URL (kayak.com/flights/...) is restricted in accordance
with robots.txt. Ask your account manager to get full access (brob)Ein roher lokaler Browser hat dieselbe Seite kurz zuvor problemlos gescrapt. Bright Data verweigerte. Das Verweigern ist das fähigere Verhalten, nicht das schwächere. Bright Data setzt robots.txt durch und schützt sensible Ziele standardmäßig hinter KYC-Überprüfungen, ein Ansatz, den ein Unternehmensjurist genehmigen kann.
Für die meisten Unternehmensziele bist du in Ordnung. Bei unseren Prüfungen waren booking.com, Expedia, Hotels.com, Airbnb, eBay, Best Buy und Tripadvisor alle freigegeben. Eingeschränkte Ziele sind ein Gespräch mit dem Account Manager, kein Workaround. Die Infrastruktur übernimmt die zugangseitige Compliance, damit dein Code es nicht muss.
Das Kosten- und Zuverlässigkeitsbudget
Ein Beschaffungsprüfer stellt zwei Fragen: Wie zuverlässig ist es und was kostet es?
Zuverlässigkeit
Zuverlässigkeit hat einen Haupthebel und eine harte Obergrenze. Der Hebel ist die Viewport-Korrektur. Bevor wir sie gesetzt haben, scheiterte etwa die Hälfte aller Durchläufe an InvalidScreenResolution, und dieser eine Fehler war das meiste von dem, was wie ein flüchtiger Agent aussah.
Nach der Korrektur maßen wir es auf einer echten Seite, nicht in einer Sandbox. Ein fünffacher paralleler eBay-Lesevorgang gab 5/5 zurück, jeder Wert im Live-DOM über nova.page bestätigt, in 47s gegenüber etwa 198s sequenziell, 4,2×. Jede Sitzung lief auf einer frischen Bright Data-IP, was die Konzentration von Anfragen auf einer einzelnen IP vermeidet.
Das ist keine freie lineare Skalierung. Wir haben es auf 12 parallele Sitzungen hochgedrückt und 8 von 12 kamen sauber zurück. Das ist die Parallelitätsobergrenze des kostenlosen und Pay-as-you-go-Tiers, nicht der brechende Agent. Echtes Unternehmensvolumen bedeutet, das Parallelitätslimit der Zone zu erhöhen und Wiederholungen einzuplanen, nicht davon auszugehen, dass fünf Sitzungen kostenlos auf fünftausend skalieren.
Der Gewinn durch Parallelität ist real, aber nicht linear. Jenseits der Parallelitätsobergrenze des Plans kamen 8 von 12 parallelen Lesevorgängen sauber zurück.
Eine einzelne leichte Aktion (sortieren, dann lesen) benötigte gelegentliche Wiederholungen, und die verbleibenden Fehler waren transiente StartFaileds beim Sitzungsstart. Zerlege die Arbeit also in kleine idempotente Schritte, wickle sie in Wiederholungen ein, plane etwa 1,2 bis 1,5× ein und verifiziere jede Ausgabe mit nova.page.
Die verbleibende Grenze ist das Terrain. Auf der strukturierten Seite bleibt es zuverlässig. Drei Drugs@FDA-Abfragen liefen jeweils denselben Ablauf: ausfüllen, absenden, aufklappen, navigieren, extrahieren. Alle drei kamen 3/3, jedes Feld verankert zurück, wenn auch langsam mit etwa 50 bis 90 Sekunden pro Stück. Auf der Verbraucherseite verlangsamen und laufen die mehrstufigen Ketten immer noch in Timeouts.
Die Zuverlässigkeitszahlen in einer Übersicht:
| Szenario | Ergebnis | Was es bedeutet |
|---|---|---|
| Vor der Viewport-Korrektur | ~die Hälfte der Durchläufe scheiterte | InvalidScreenResolution, der dominante Fehler |
| 5-facher paralleler Lesevorgang, nach Korrektur (eBay) | 5/5 verankert | 47s vs. ~198s sequenziell, 4,2×, frische IP pro Sitzung |
| Auf 12 parallel hochgedrückt (roh) | 8/12 | die Pay-as-you-go-Parallelitätsobergrenze, nicht der Agent |
| Einzelne leichte Aktion (sortieren, dann lesen) | gelegentliche Wiederholung | die Fehler sind wiederholbare StartFaileds |
| Mehrstufiges FDA-Formular, 3 Arzneimittel | 3/3 verankert | kooperative Seite, aber langsam mit ~50,90s pro Stück |
Kosten
Bandbreitenkosten sind messbar, und Modellkosten sind die offene Frage. Die Browser API rechnet pro GB ab, etwa 8 $/GB im Pay-as-you-go-Modell (alle Preise hier sind Stand Mitte 2026). Wir haben das echte Seitengewicht durch sie gemessen:
| Seitentyp | Gewicht | Browser API @ 8 $/GB |
|---|---|---|
| Schwere Verbraucherseite (eBay-Suche) | ~3,4 MB | ~0,027 $/Seite → ~27 $ / 1.000 Seiten |
| Leichte Seite (Sandbox-Produkt) | ~0,2 MB | ~0,0016 $/Seite → ~1,60 $ / 1.000 Seiten |
Addiere den Wiederholungsmultiplikator, dann addiere Nova Acts Inferenzkosten, die heute nicht öffentlich bepreist sind. Der kostenlose Tier misst, wie viel du sammelst, und Produktionsdurchläufe laufen über AWS ohne veröffentlichten Preis. Das Budget läuft also auf zwei Zeilen hinaus. Die Browser-API-Bandbreite ist ein bekannter, vorhersehbarer Posten. Die Inferenz des Agenten ist die Kosten, die du vor der Skalierung mit AWS bestätigen musst.
3,4 MB zu bewegen, um drei Felder zu extrahieren, ist auch der Grund, warum du bei Massenarbeit überhaupt keinen Browser verwendest. Die Datenschicht rechnet pro Anfrage statt pro Gigabyte ab. Die SERP-API und Web Unlocker kosten etwa 1,50 $ pro 1.000, gegenüber ~27 $ pro 1.000 schwerer Seiten durch den Browser.
Wann der Agent verwendet werden sollte und wann die Datenschicht
Bright Data liefert Web MCP und Web Scraper APIs, damit du nicht für alles einen Browser verwendest. Die Trennlinie ist die Entscheidungskomplexität:
- Fester, bekanntes Schema-Abruf, wie Preis und Bestand für 100.000 SKUs. Verwende keinen Agenten. Eine Web Scraper API gibt nur den Datensatz zurück, ohne 3,4-MB-Seite, ohne Inferenzkosten und mit weit weniger transienten Fehlern. Es ist günstiger und zuverlässiger.
- Reasoning, das ein Scraper nicht erfassen kann: mehrstufige Navigation, bedingte Logik (zum Beispiel der günstigste erstattungsfähige Tarif, der deinen Anforderungen entspricht), Formularübermittlung, Web-App-QA oder ein unbekanntes Portal ohne vorgefertigten Scraper. Das ist, wo Nova Act und die Browser API ihre Kosten rechtfertigen.
Die Regel: Wenn du es als festen Scrape oder API-Aufruf ausdrücken kannst, tue das. In echten Systemen ergänzen sich die beiden. Nova Act steuert den Entscheidungsfluss und übergibt den Massenabruf an Bright Datas strukturierte APIs.
Die Datenschicht in der Praxis
‘Nutze die Datenschicht für Massenarbeit’ ist der übliche Rat. Hier ist sie, gegen dasselbe Bright Data-Konto ausgeführt, drei Aufrufe, kein Browser, kein Agent.
Strukturierte Suche in einem Aufruf (SERP-API), frische geparste Suchergebnisse zur Verankerung einer KI, als JSON zurückgegeben:
requests.post("https://api.brightdata.com/request",
headers={"Authorization": f"Bearer {BRIGHTDATA_TOKEN}"},
json={"zone": "serp_api2", "format": "raw", # gl/hl pin the locale so results are stable
"url": "https://www.google.com/search?q=amazon+nova+act+sdk&brd_json=1&gl=us&hl=en"})9 organic results → 1. github.com/aws/nova-act · 2. nova.amazon.com/act · 3. docs.aws.amazon.com/nova-act …Jede URL zu sauberem LLM-bereitem Markdown (Web Unlocker), derselbe FDA-Arzneimitteleintrag, den unser Agent durch Ausfüllen eines Formulars erreicht hat, direkt abgerufen:
json={"zone": "web_unlocker", "format": "raw", "data_format": "markdown",
"url": "https://www.accessdata.fda.gov/.../ApplNo=214836"}→ 8,4 KB sauberes Markdown, ein Aufruf, kein Browser, keine CAPTCHA-Lösung, kein Parsing.Eine bekannte Quelle zum reinen strukturierten Datensatz (Web Scraper API), einen vorgefertigten Collector auslösen und saubere Felder erhalten, niemals die Seite. Wir führten den Crunchbase-Scraper für ein Unternehmen aus:
requests.post("https://api.brightdata.com/datasets/v3/trigger?dataset_id=gd_l1vijqt9jfj7olije",
headers={"Authorization": f"Bearer {BRIGHTDATA_TOKEN}"},
json=[{"url": "https://www.crunchbase.com/organization/anthropic"}]) # -> snapshot_id, then poll→ 89 strukturierte Felder (Mitarbeiter, HQ, CB-Rang, Status, Finanzierung …),
bereit in ~70s, kein Browser, kein Agent, keine 3,4-MB-Seite, kein Parsing.Der Kontrast ist die Architektur. Der Agent war hier das richtige Tool, weil man handeln musste, um die Daten zu erreichen. Es gab keine URL, also suchte er das Formular und navigierte zu Antrag 214836. Sobald eine URL existiert oder du Suchergebnisse oder Massendatensätze mit bekanntem Schema benötigst, verwendest du keinen Browser. Du rufst die Datenschicht auf. Sie ist deterministischer, schneller und günstiger, mit weit weniger des Zuverlässigkeitsbudgets des Agenten. Nova Act entdeckt und handelt. Bright Datas Datenschicht ruft im Maßstab ab.
Der Agent ruft Bright Datas Tools direkt auf
Die bisherigen Integrationen sind manuell orchestriert. Wir haben SERP und Web Unlocker aufgerufen und dann dem Agenten einen Browser übergeben. Es gibt eine engere Integration. Du gibst Nova Act Bright Datas Web MCP-Server als Tools, und der Agent selbst entscheidet, wann er suchen, scrapen oder entdecken soll. Nova Act läuft auf AWS’s Strands-Framework, also akzeptiert es MCP-Tools direkt:
from strands.tools.mcp import MCPClient
from mcp import StdioServerParameters
from mcp.client.stdio import stdio_client
bd_mcp = MCPClient(lambda: stdio_client(StdioServerParameters(
command="npx", args=["-y", "@brightdata/mcp"], env={"API_TOKEN": BRIGHTDATA_TOKEN})))
with bd_mcp:
tools = bd_mcp.list_tools_sync() # search_engine, scrape_as_markdown, discover, batch…
with NovaAct(starting_page="https://example.com", tools=tools,
cdp_endpoint_url=endpoint, cdp_headers=headers) as nova:
nova.act_get("Use the search_engine tool to find 'Amazon Nova Act SDK'; "
"return the top result's URL.", schema=Out.model_json_schema())Wir haben es ausgeführt, und das eigene Trace des Agenten zeigt es. ‘Der Tool-Aufruf war erfolgreich und gab Suchinformationen zurück. Das oberste organische Ergebnis ist ‘https://github.com/aws/nova-act’…’ und es gab {'top_result_url': 'https://github.com/aws/nova-act'} zurück. Der Agent wählte Bright Datas search_engine-Tool selbst, Bright Data führte die Suche durch und der Agent nutzte das Ergebnis. Es dauerte einen act-Aufruf, etwa 32s, ohne Scraping einer Suchseite, bei der ein Browser-Agent wahrscheinlich sowieso blockiert würde.
Das ist der Unterschied zwischen dem gemeinsamen Einsatz zweier Tools und einem Agenten, der das andere selbst aufruft. Der Agent erhält in diesem Durchlauf fünf Tools direkt: search_engine, scrape_as_markdown, search_engine_batch, scrape_batch und discover. Das ist ein sauberer und konformer Weg für die Jobs, die ein Browser-Agent am schlechtesten macht: Suche und Massenabruf.
Die kombinierte Pipeline, Breite und Tiefe
Jede bisherige Komponente steht für sich. Kombiniert bauen sie einen verankerten, strukturierten Intelligence-Datensatz zu einem Thema auf. Du holst Breite aus dem offenen Web und Tiefe aus einer formulargeschützten maßgeblichen Quelle. Wir haben es mit GLP-1-Medikamenten ausgeführt, einer hochkarätigen pharmazeutischen Kategorie:
# 1. BREADTH , Bright Data SERP API discovers authoritative sources (no browser)
sources = serp_api("Ozempic semaglutide")[:3]
# 2. FETCH , Bright Data Web Unlocker pulls the top source as markdown (no browser)
context = web_unlocker(sources[0])
# 3. DEPTH , Nova Act fills the Drugs@FDA form for the authoritative record (agent)
fda = nova_act_fda("semaglutide") # verified against the live DOMEchte, End-to-End-Ausgabe:
{
"web_sources": ["ozempic.com", "mayoclinic.org/…semaglutide…", "accessdata.fda.gov/…/209637lbl.pdf"],
"web_context_chars": 59270,
"fda_authoritative": {"drug_name": "OZEMPIC", "active_ingredient": "SEMAGLUTIDE",
"application_number": "209637", "marketing_status": "Discontinued"},
"fda_grounded": true
}Jede Hälfte tat etwas, das die andere nicht konnte. Die Datenschicht durchsuchte das offene Web in zwei API-Aufrufen und lieferte drei maßgebliche Quellen und 59 KB sauberen LLM-bereiten Kontext, ohne Browser und ohne Agent. Der Agent ging dorthin, wo die Datenschicht alleine nicht hinkonnte. Er füllte das FDA-Suchformular aus und navigierte zum maßgeblichen Regulierungseintrag, Antrag 209637, Status Eingestellt für diese Produktzeile, Daten hinter einem Formular ohne URL.
Und die beiden bestätigen sich gegenseitig. Die Datenschicht gab unabhängig das FDA-Label 209637lbl.pdf für dieselbe Antragsnummer zurück, die der Agent durch Handeln erreicht hatte. Breite bestätigt Tiefe.
Dieser Durchlauf zeigt auch einen Fehler, den man einplanen sollte. Der FDA-Schritt des Agenten schlug beim Markennamen ‘Ozempic’ dreimal mit ActAgentFailed fehl und gelang beim Wirkstoff ‘Semaglutid’. Das sind die Zuverlässigkeitskosten des Terrains. Deshalb verifizierst du mit fda_grounded: true und planst Wiederholungen ein.
Dieselbe Pipeline, eine andere Branche
Das funktioniert über die Pharmaindustrie hinaus, und wir haben es verifiziert. Wir führten die identische Pipeline in einer anderen Branche aus, der Finanz-Compliance. SERP fand die Web-Präsenz des Unternehmens, seine eigene Seite und ein Finanzdata-Profil. Der Agent navigierte FINRAs BrokerCheck (eine schwierigere Angular-App als das FDA-Formular) zum maßgeblichen Regulierungseintrag eines Broker-Dealers: Firmenname, CRD-Nummer, Regulierer und Offenlegungsanzahl. Es verankerte sich mit einem Neuversuch.
Von Pharma bis Finanzen funktionierte dieselbe Pipeline ohne Codeänderungen außer der Abfrage und dem Schema. Sie sollte sich genauso auf Wettbewerbsanalyse von Preisen, Marktforschung und Produktsicherheitsüberwachung ausdehnen. Die Datenschicht übernimmt Breite und Skalierung, der Agent übernimmt formulargeschützte Tiefe, und die Felder des Agenten werden gegen die Live-Seite verankert.
Von einem Datensatz zu einem Markt
Es skaliert auch von einem Datensatz zu einem Markt. Wir führten die identische Pipeline über den GLP-1-Arzneimittelmarkt aus und erhielten einen strukturierten Wettbewerbs-Datensatz. Die Datenschicht übernahm die Breite, während der Agent den maßgeblichen FDA-Eintrag jedes Arzneimittels lieferte:
| Wirkstoff | FDA-Markenname | Antrags-Nr. | Status | Top-Quelle (SERP) |
|---|---|---|---|---|
| Semaglutid | OZEMPIC | 209637 | Verschreibungspflichtig | drugs.com |
| Tirzepatid | MOUNJARO | 215866 | Verschreibungspflichtig | ncbi.nlm.nih.gov |
| Liraglutid | LIRAGLUTIDE | 212552 | Verschreibungspflichtig | drugs.com |
Der Marktdurchlauf enthüllte sogar eine Live-Diskrepanz. Antrag 209637 zeigte im obigen Einzeldatensatz-Durchlauf Eingestellt und in dieser Tabelle Verschreibungspflichtig. Ein FDA-Antrag kann mehrere Produkteinträge mit unterschiedlichen Status enthalten, also ist jeder Agenten-Lesevorgang ein Snapshot einer Zeile. Genau deshalb verifizierst du jeden Lesevorgang.
Das ungeschriebene reCAPTCHA
Ein Moment, den wir nicht gescriptet hatten, machte den Fall der Architektur von selbst. Bei zwei der drei Abfragen präsentierte die FDA-Seite dem Agenten ein reCAPTCHA.
Das echte reCAPTCHA, auf das der Agent bei Drugs@FDA stieß, mitten im Durchlauf aufgenommen. Nova Acts Leitplanke weigerte sich, es zu lösen. Die Sitzung erreichte trotzdem den Eintrag, weil sie auf Bright Datas Browser API läuft.
Nova Acts Leitplanke weigerte sich, es als Rätsel zu behandeln. Aus seinem Trace, Wort für Wort: ‘Ich sollte keinen Menschen vortäuschen oder durch das Lösen von CAPTCHAs oder anderen Herausforderungen so tun als ob.’ Das ist das Verhalten, das man von einem autonomen Agenten möchte.
Er kam trotzdem durch, weil die Sitzung auf Bright Datas Browser API läuft. Ein bloßer lokaler Browser konnte die FDA-Seite nicht einmal laden. Dieser Browser lief zweimal mit 90 Sekunden Timeout ab, obwohl er example.com im selben Durchlauf problemlos erreichte. Er erreichte weder das CAPTCHA noch die Daten. Die Bright Data-Sitzung erreichte den Eintrag.
Die Arbeitsteilung ist also real und verifiziert. Der Agent löst keine CAPTCHAs. Er wird es nicht tun, und er sollte es nicht tun. Die Datenschicht kann das Formular nicht navigieren. Nur der Agent auf Bright Data beendet die Aufgabe.
Das CAPTCHA ist intermittierend, und ein späterer roher Durchlauf hatte keines. Diese beiden CAPTCHA-betroffenen Agenten-Abfragen dauerten etwa 1m50s und 2m37s echter Reibung. Der Datensatz hat drei Zeilen, aber das Muster gilt für einen ganzen Markt.
Das ist Nova Act und Bright Data kombiniert. Kein Tool alleine löst es.
Einschränkungen
- Nova Act ist noch früh. Stand Mitte 2026 ist es eine Forschungsvorschau, nur auf Englisch, mit einem kostenlosen Tier, das deine Interaktionen begrenzt. Es gibt bei jedem Durchlauf ‘Amazon sammelt Daten zu Interaktionen in dieser Version’ aus. Produktion ist AWS-gekoppelt, mit IAM, S3 und Bedrock AgentCore. Bestätige Produktions-Tier-Bedingungen und Preise mit AWS, bevor du etwas Kritisches darauf aufbaust.
- Der Agent ist fragil auf popup-schweren Verbraucherseiten. Auf booking.com war der
ActActuationErrorder Agent, der gegen die Seite kämpfte, nicht Bright Data, das beim Bereitstellen scheiterte. Bevorzuge direkte Ergebnis-URLs, schließe Popups explizit, verlasse dich auf das Wiederholungsbudget oder lagere zur Datenschicht aus. - Compliance hat zwei Seiten. Es ist die Leitplanke, die man möchte, aber eingeschränkte Ziele bedeuten einen Account Manager- oder KYC-Überprüfungsschritt, also plane die Vorlaufzeit ein. Und die Legalität von Scraping für KI ist 2026 umstritten, mit wegweisenden Urteilen zu öffentlichen Daten, dem EU-KI-Gesetz und Urheberrechtsklagen, die noch im Gange sind. Öffentliche Daten sind keine automatische Erlaubnis, also halte dein Rechtsteam eingebunden.
- Erkennung ist ein Wettrüsten. Agenten-Fingerprinting und Pay-per-Crawl eskalieren weiter. Voraus zu bleiben ist kontinuierliche Arbeit, weshalb die Schicht eine verwaltete Abhängigkeit ist und keine einmalige Lösung.
- Ein autonomer Browser ist eine Angriffsfläche. Seiten können Prompt-Injection tragen, die den Agenten lenkt, und Nova Acts eigene Dokumentation weist darauf hin. Begrenze es. Verwende URL-Allowlists und Blocklists und halte es von Seiten fern, die es nicht braucht. Steuere sensible Eingaben wie Anmeldedaten und Zahlungen direkt über Playwright mit
nova.page, anstatt das Modell tippen zu lassen.
Nächste Schritte
Tausche Nova Act gegen den Agenten nächsten Jahres aus und die Aufteilung gilt immer noch: Die darunter liegende Schicht ist der dauerhafte Teil. Beginne also damit, die Aufgabe zu klassifizieren, nicht das Tool. Wenn das Ziel eine stabile URL oder einen vorgefertigten Collector hat, sende es an die Datenschicht und überspringe den Browser. Behalte Nova Act für das, was eine Aktion erfordert: ein auszufüllendes Formular, einen mehrstufigen Pfad, ein Portal ohne Scraper dahinter.
Für alles, das du mehr als einmal ausführen möchtest, setze diese Dinge von der ersten Sitzung an:
- Verschiebe die eingebetteten Anmeldedaten der Zone in einen
Authorization: Basic-Header und füge deine IP zur Zone-Allowlist hinzu. Überspringe eines davon und du erhältstInvalid URLoder einen leeren Body mit dem Grund in den Antwort-Headern. - Erzwinge einen 1600×900-Viewport auf der verbundenen Seite und erstelle
logs_directory, bevor der Durchlauf startet. - Verankere jedes extrahierte Feld gegen
nova.pagein derselben Sitzung und plane 1,2 bis 1,5× für Wiederholungen ein.
Wenn eine Zone nicht mehr mithalten kann, erhöhe ihr Parallelitätslimit, bevor du den Agenten beschuldigst. Verlagere den Massenabruf zur SERP-API, Web Unlocker oder einer Web Scraper API. Die Browser API und Web MCP werden beide mit einem kostenlosen Tier geliefert, sodass du die Aufteilung testen kannst, bevor du dich festlegst. Eingeschränkte Ziele sind ein Gespräch mit dem Account Manager, kein Workaround.
Das ausführbare Skript für jede Demo hier ist im Begleit-Repo. Klone es, richte es auf dein eigenes Ziel aus und sieh, welche Hälfte der Aufteilung deine Aufgabe tatsächlich benötigt.
Häufig gestellte Fragen
Was ist Amazon Nova Act?
Amazon Nova Act ist ein AWS-SDK zum Erstellen von Browser-Agenten in Python. Du zerlegst einen Workflow in kleine, zuverlässige Befehle: act() für Aktionen und act_get() für typisierte Extraktion. Es steuert ein echtes Chromium durch Playwright. Stand Mitte 2026 ist es eine Forschungsvorschau.
Funktioniert Nova Act mit Bright Data?
Ja, über das Chrome DevTools Protocol. Nova Act verbindet sich mit Bright Datas Browser API über cdp_endpoint_url und cdp_headers. Der Setup-Haken ist, dass modernes Playwright die eingebetteten Anmeldedaten wss://-URL ablehnt, also verschiebe die Anmeldedaten in einen Authorization: Basic-Header und erzwinge einen 1600×900-Viewport.
Kann ich einen Proxy mit Nova Act verwenden?
Nicht mit dem nativen proxy-Parameter, wenn du über CDP verbindest. Nova Act wirft ValidationFailed mit der Meldung Cannot specify a proxy when connecting over CDP. Verbinde dich stattdessen über CDP mit Bright Datas Browser API, wo Unblocking, Geo-Routing und CAPTCHA-Lösung auf Bright Datas Seite stattfinden.
Ist Nova Act produktionsreif?
Stand Mitte 2026 ist es eine Forschungsvorschau, nur auf Englisch, mit einem gemessenen kostenlosen Tier. Produktion läuft auf AWS mit IAM, S3 und Bedrock AgentCore. In unseren Durchläufen war es auf kooperativen, strukturierten Seiten zuverlässig und auf feindseligen Verbraucherseiten fragil. Bestätige Produktionsbedingungen und Preise mit AWS, bevor du darauf aufbaust.
Was kostet es, einen Browser-Agenten so zu betreiben?
Bright Datas Browser API rechnet etwa 8 $/GB im Pay-as-you-go-Modell ab (Mitte 2026). Eine schwere Seite bewegte etwa 3,4 MB: ungefähr 27 $ pro 1.000 Seiten vor Wiederholungen. Plane 1,2 bis 1,5× oben drauf. Eine leichte Seite liegt näher bei 1,60 $ pro 1.000. Nova Acts Inferenz ist nicht öffentlich bepreist, also verwende für Massenarbeit die Datenschicht, keinen Browser.
Warum nicht meinen eigenen Headless-Browser und Proxys verwenden?
Die gemessenen Fehlermodi sind nur die halbe Antwort. Einen Browser zu betreiben ist schwerfällig, fragil bei mehrstufiger Ausführung und nicht-deterministisch. Aber die Hälfte, die schwerer selbst zu betreiben ist, sind Geografie, Compliance und Skalierung: ein Wettrüsten, das nie endet. Eine Infrastrukturschicht betreibt es, damit dein Engineering es nicht muss.
Wann sollte ich den Agenten verwenden, nicht die Datenschicht?
Wenn die Aufgabe ein fester, bekanntes Schema-Abruf ist, verwende eine Web Scraper API, die den Datensatz ohne Seite und ohne Inferenzkosten zurückgibt. Wenn sie Reasoning erfordert, das ein Scrape nicht erfassen kann (mehrstufige Navigation, Formularübermittlung, bedingte Logik), verwende den Agenten. In echten Systemen ergänzen sich die beiden.
