---
title: "Was ist Agentic Web Scraping und wie funktioniert es?"
description: "Beim Agentic Web Scraping navigiert der Agent die Seite selbst, wählt den nächsten Schritt und extrahiert Daten nach Schema. Wir erklären Schleife und Kosten."
url: https://proxynet.io/de/blog/agentic-web-scraping-how-it-works-2026
date: 2026-09-21
author: "Acar Diveroli"
category: "KI, Web Scraping"
lang: de
---

# Was ist Agentic Web Scraping und wie funktioniert es?

Sie haben 200 verschiedene kleine Websites vorliegen und müssen aus allen dieselben Felder erfassen — Produktname, Preis, Bestand. Für jede Website ein eigenes Skript zu schreiben bedeutet Hunderte Selektoren; alle in eine einzige Scraping-API zu geben bedeutet leere Datensätze für die meisten, weil ihre Struktur nicht passt. Gibt man dieselbe Aufgabe einem KI-Agenten, ändert sich das Bild: Der Agent liest jede Seite selbst, entscheidet anhand dieser Seite, wo die Daten liegen, und folgt nötigenfalls einem Link, um seinen Plan unterwegs zu korrigieren.

Das ist Agentic Web Scraping (Scraping mit Agenten) in einem Satz. In diesem Beitrag erklären wir, was Scraping mit Agenten ist, mit welchen Schritten die Agentenschleife bei einer Erfassungsaufgabe arbeitet, die Bausteine des Systems, ein funktionierendes Skelett in Code, die Kosten- und Zuverlässigkeitsseite gegenüber regelbasierten Skripten und die typischen Fehlermodi des Agenten. Die andere Seite der Frage „wer wählt den Weg" — die feste Pipeline, in der das Modell nur im Parsingschritt arbeitet — haben wir in unserem Beitrag [KI-Scraper](/de/blog/ai-web-scraper-how-it-works-2026) behandelt.

> **Hinweis: Kurze Antwort**
>
> Beim Agentic Web Scraping entscheidet das Sprachmodell auch, welcher Schritt der Erfassungsaufgabe ausgeführt wird: Es beobachtet die Seite, wählt die nächste Aktion (gehen, klicken, extrahieren), bewertet das Ergebnis des Tools und extrahiert die Daten nach dem Schema, das Sie definiert haben. Bei mehrstufigen Aufgaben mit veränderlicher Struktur und unklarer Rentabilität bringt es Wert; bei stabilen, hochvolumigen Aufgaben bleibt das regelbasierte Skript die günstigere und vorhersagbarere Lösung.

## Was ist Agentic Web Scraping?

Es gibt drei Stufen, Daten von einer Seite zu erfassen, und um den Begriff richtig zu verwenden, muss man alle drei auseinanderhalten. Auf der ersten Stufe liegt alles in der Hand des Entwicklers: Das Skript weiß im Code, welche Adresse es besucht und aus welchem Element es Daten nimmt. Auf der zweiten Stufe wird die Parsing-Arbeit an das Modell übergeben, doch der Weg bleibt fest: Die Seite kommt, das Modell extrahiert die Felder, der Ablauf endet — das war das Thema unseres Beitrags [KI-Scraper](/de/blog/ai-web-scraper-how-it-works-2026). Auf der dritten Stufe tritt das Modell in die Schleife: Welche Seite besucht wird, welcher Knopf gedrückt wird, wann gestoppt wird, wird zur Laufzeit entschieden. Diese dritte Stufe ist Agentic Web Scraping.

In der Unterscheidung des Anthropic-Artikels [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents) gesagt: Abläufe, deren Schritte der Code zeichnet, sind Workflows; Abläufe, in denen das Modell seinen eigenen Prozess steuert, sind Agenten. Scraping mit Agenten ist diese Definition, angewendet auf die Datenerfassung. Den Unterschied auf einen Satz verdichtet: Beim KI-Scraper lautet die Antwort auf die Frage „wer parst die Seite?" das Modell; beim Scraping mit Agenten geht auch die Antwort auf die Frage „wer wählt den Weg?" an das Modell über.

## Wie arbeitet die Agentenschleife bei der Erfassung?

Die allgemeine Arbeitsweise des Agenten — wahrnehmen, planen, handeln, bewerten — und die theoretische Grundlage dieser Schleife waren Thema unseres Beitrags [Wie KI-Agenten funktionieren](/de/blog/how-ai-agents-work); wir wiederholen sie nicht, sondern sehen uns ihre Form für die Datenerfassung an. In jeder Runde durchlaufen fünf Schritte:

1. **Wahrnehmen.** Was der Agent „sieht", sind nicht die Pixel des Browserfensters, sondern die strukturelle Zusammenfassung der Seite: der Accessibility-Baum, Überschriften, Linklisten, Formularfelder. Diese Zusammenfassung geht in das Kontextfenster des Modells ein; das rohe HTML kommt nicht vollständig hinein.
2. **Planen.** Mit Blick auf das Ziel — „extrahiere den Preis jedes Produkts in dieser Liste" — wählt das Modell die nächste Aktion: den Filterknopf klicken, auf die zweite Seite der Paginierung wechseln oder entscheiden, dass die Daten jetzt sichtbar sind.
3. **Handeln.** Die vom Modell gewählte Aktion ist ein Tool-Aufruf: etwa `git(url)`, `tıkla(betimleme)`, `doldur(alan, değer)`. Ausgeführt wird der Aufruf vom Browser; das Modell schreibt nur den Befehl.
4. **Extrahieren.** Sind die Zieldaten sichtbar, füllt das Modell die Felder nach dem von Ihnen definierten Schema. Dieser Schritt ist der Parsingschritt der festen Pipeline, eingebaut in den Agenten.
5. **Prüfen und wiederholen oder abschließen.** Typen und Pflichtfelder der Ausgabe werden im Code geprüft; fehlt etwas, sieht das Modell, welche Information fehlt, und kehrt zur betreffenden Seite zurück. Eine Abbruchbedingung wie ein Schrittbudget, ein Kostenlimit oder eine Seitenzahl verhindert, dass die Schleife endlos läuft.

Der vierte und der fünfte Schritt zeigen, dass Scraping mit Agenten gleichzeitig mit zwei getrennten Disziplinen arbeitet: Dem Modell bei seinen Entscheidungen und seiner Ausgabe nicht zu vertrauen, fügt auf einmal zwei Ebenen Arbeit hinzu — eine Validierungsebene und eine Abbruchebene. Fehlen beide, produziert das System, während es „funktioniert", stillschweigend fehlerhafte Daten.

## Bausteine

- **Browser-Tool.** Die Hände des Agenten. Eine Automatisierungsbibliothek wie [Playwright](https://playwright.dev/python/docs/proxy) stellt den Accessibility-Baum bereit, den das Modell sehen kann, und die Aktionen, die es nutzen kann; es gibt auch ein fertiges Bauteil, das diese Aufgabe als MCP-Server erledigt. Die Einrichtung und die Proxy-Flags haben wir in unserem Beitrag [Playwright MCP](/de/blog/playwright-mcp) erklärt; das Protokoll selbst überlassen wir unserem Beitrag [Was ist MCP?](/de/blog/what-is-mcp).
- **Schema und Validierung.** Das JSON-Schema der gewünschten Daten bindet die Ausgabe des Modells an einen Vertrag. Typ-, Pflicht- und Bereichsprüfungen bleiben im Code; verdächtige Datensätze landen in einer separaten Warteschlange, statt in den Hauptspeicher geschrieben zu werden.
- **Haltepunkt und Gedächtnis.** Lange Aufgaben lassen sich unterbrechen; die besuchten Adressen, abgeschlossenen Seiten und gesammelten Datensätze des Agenten werden ausgelagert. Das Kontextfenster ist das Kurzzeitgedächtnis; das Gedächtnis einer Aufgabe mit 200 Websites passt nicht in das Fenster des Modells, aber in eine Datei.
- **Sicherheitsgrenzen.** Die Domains, die der Agent öffnen darf, die Zahl der Schritte, die er gehen darf, und die Tools, die er aufrufen darf, werden von Anfang an eingeschränkt; der Inhalt der gescrapten Seite geht als Daten an das Modell, nicht als Anweisung. Diese ganze Ebene — Positivliste, Rate-Limit und Injection-Bereinigung eingeschlossen — haben wir in unserem Beitrag [Sicherer Webzugriff für LLMs](/de/blog/llm-safe-web-access) aufgebaut.

## Ein kleines Agenten-Skelett

Der folgende Python-Entwurf zeigt das anbieterunabhängige Skelett der Schleife oben. Die Browser-Seite ist Playwright; die Funktion `model_cagir` wird mit dem Client Ihres Anbieters gefüllt, und vom Modell wird entweder eine Aktion oder eine schemaentsprechende Ausgabe erwartet.

```python
import json
from playwright.sync_api import sync_playwright

PROXY = {"server": "http://pr.proxynet.io:8000",
         "username": "kullanici", "password": "parola"}
HEDEF = "https://example.com/urun-listesi"
SEMA = {"urun_adi": str, "fiyat": float, "stokta": bool}

def gozlemle(sayfa):
    # Das Auge des Agenten: kein rohes HTML, sondern die strukturelle Zusammenfassung der Seite.
    return sayfa.locator("body").aria_snapshot()

def model_cagir(gozlem, talimat):
    # Mit dem offiziellen Client Ihres Anbieters füllen. gozlem + talimat geht
    # an das Modell; die Antwort ist entweder {"arac": ..., ...} oder schemaentsprechende Daten.
    raise NotImplementedError("der Modellaufruf erfolgt hier")

def dogrula(kayit):
    for alan, tur in SEMA.items():
        if not isinstance(kayit.get(alan), tur):
            raise ValueError(f"{alan} ist nicht vom erwarteten Typ")
    return kayit

with sync_playwright() as p:
    tarayici = p.chromium.launch(proxy=PROXY)
    sayfa = tarayici.new_page()
    sayfa.goto(HEDEF)

    for adim in range(8):                       # Abbruchbedingung: Schrittbudget
        karar = json.loads(model_cagir(gozlemle(sayfa),
                                       "Extrahiere die Produkte in der Liste."))
        if karar.get("arac") == "cikar":
            print(dogrula(karar["kayit"]))      # dem Modell nie direkt vertrauen
            break
        if karar["arac"] == "git":
            sayfa.goto(karar["url"])
        elif karar["arac"] == "tikla":
            sayfa.get_by_role(karar["rol"], name=karar["ad"]).click()
```

Drei Eigenschaften des Skeletts fassen den Rest des Beitrags zusammen: Was das Modell in jeder Runde sieht, ist kein rohes HTML, sondern eine strukturelle Zusammenfassung; die Schleife hat eine Abbruchbedingung; die Ausgabe des Modells wird nirgendwo geschrieben, bevor sie nicht durch `dogrula` gegangen ist. Alle Proxy-Optionen von Playwright haben wir in unserem Beitrag [Playwright-Proxy](/de/blog/playwright-proxy) tabellarisch gegeben.

## Nebeneinander mit regelbasiertem Scraping

Die drei Stufen in dieselbe Tabelle zu legen, klärt, welche Aufgabe in welche Stufe gehört:

| Kriterium | Regelbasiertes Skript | KI-Scraper (feste Pipeline) | Agent (agentic) |
|---|---|---|---|
| Wer wählt den Weg? | Der Entwickler, im Code | Der Entwickler, im Code | Das Modell, zur Laufzeit |
| Widerstandsfähigkeit bei Website-Änderungen | Niedrig | Hoch (beim Parsen) | Hoch (Parsen + Weg) |
| Stückkosten | Nahezu null | Token pro Seite | Token pro Runde; die Zahl der Runden ist variabel |
| Vorhersagbarkeit | Hoch | Mittel | Niedrig |
| Geeignete Aufgabe | Stabile Seiten, hohes Volumen | Seiten mit veränderlicher Struktur | Mehrstufige Aufgaben, deren Weg vorab unbekannt ist |

Die Kostenformel ist einfach: Die Gesamtgebühr des Agenten ist die Zahl der Runden multipliziert mit den pro Runde gesendeten und empfangenen Tokens. Beim regelbasierten Skript liegt diese Zahl nahe null; beim KI-Scraper ist die Zahl der Runden eins (ein einziger Parsing-Aufruf); bei Agentenaufgaben variiert die Zahl der Runden mit dem Schwierigkeitsgrad der Seite — die meisten Seiten enden in zwei Runden, während eine Aufgabe, die durch Filtermenüs geht, sechs bis acht Runden dauern kann. Deshalb wird das Budget des Agenten nicht an die Aufgabe selbst, sondern an ein Schrittbudget gebunden: Ein System, das ohne eine Obergrenze wie `for adim in range(8)` in der Schleife gebaut wird, kann auf einer kaputten Seite stundenlang Runden drehen. Wie die Stückkosten der Modellseite berechnet werden, haben wir in unserem Beitrag [Web Scraping mit GPT-6 Astra](/de/blog/gpt-6-astra-web-scraping) behandelt.

## Fehlermodi des Agenten

Die Fehler agentenbasierter Systeme unterscheiden sich von denen eines Skripts; ein Skript bricht und stoppt, ein Agent kann sich ohne zu brechen verirren. Die wichtigsten Modi und wo sie erscheinen:

- **In die Schleife geraten.** Der Agent pendelt zwischen denselben zwei Seiten hin und her oder klickt denselben Knopf mehrfach hintereinander. Äußerlich zeigt er sich in einer anschwellenden Rundenzahl und der Wiederholung derselben Aktionsfolge in den Protokollen; die Abhilfe ist, besuchte Adressen und Aktionen festzuhalten und dem Modell diese Liste in jeder Runde zu zeigen.
- **Zieldrift.** Das Modell wandelt das Ziel „extrahiere Preise" in das Ziel „durchstreife die Website" um; es kommen keine Datensätze, aber die Runde ist verbraucht. Abhilfe: das Ziel im Kontext jeder Runde wiederholen und der Zahl der leeren Runden eine Obergrenze setzen.
- **Erfundene Ausfüllungen.** Sind die Daten nicht sichtbar, füllt das Modell die Felder mit Wahrscheinlichkeiten. Die einzige Abhilfe ist die Validierungsebene; die Warteschlange für verdächtige Datensätze ist der einzige Ort, der diesen Fehlermodus abfängt.
- **Kostenexplosion.** Das vereinigte Ergebnis von Schleife und Drift: Eine Aufgabe ohne Schrittobergrenze und Budgetobergrenze kann in einem einzigen Lauf das Tagesbudget verbrauchen. Beide Obergrenzen stehen im Code, nicht im Gewissen des Modells.
- **Stille Verschlechterung.** Der hinterlistigste Modus: Der Agent kehrt mit wenigen Datensätzen „erfolgreich" zurück. Bleiben 30 von 200 Websites leer und schaut niemand hin, verbirgt sich der Fehler nicht im Protokoll, sondern im Bericht selbst. Abhilfe ist eine Warnung bei Unterschreitung: Eine Aufgabe, die unter die erwartete Datensatzzahl fällt, wird gesondert markiert.

## Was hat sich auf der Sperrseite geändert?

Für Bot-Schutzsysteme sieht der Agent aus wie jeder Scraper mit Headless-Browser: IP-Reputation, Anfragegeschwindigkeit und Browser-Signale werden genauso gemessen; die Intelligenz des Modells ist für diese Messungen unsichtbar. Zudem erzeugt der Agent mehr Anfragen als die feste Pipeline — für jede Entscheidung werden Zwischenseiten geöffnet und zu ihnen zurückgekehrt. Deshalb gewinnt die Sitzungskontinuität bei Agentenaufgaben an Bedeutung: Dass dieselbe Navigationssitzung stets von derselben Ausgangsadresse ausgeht, bedeutet, dass die Anfragen dazwischen nicht voneinander abgekoppelt werden. Ein [Sticky-Proxy](https://proxynet.io/de/sticky-proxy), der eine sich während der Sitzung nicht ändernde Adresse bereitstellt, passt deshalb zu Agentenaufgaben; bei langen Ziellisten wird zur Vergrößerung des Pools ein [Residential-Proxy](https://proxynet.io/de/residential-proxy) genutzt.

Auch auf der Seite des legitimen Rahmens wird nichts leichter: Der Agent muss weiterhin `robots.txt` und die Bedingungen der Website einhalten, Inhalte hinter einer Anmeldung und personenbezogene Daten bleiben eine separate Verantwortung. Eine Zeile ist hinzugekommen: Websites haben begonnen, Agenten, die sich beim Kommen offen zu erkennen geben (verifizierte Bot-Identität, signierte Anfragen), von denen zu trennen, die das nicht tun. Warum Agenten gesperrt werden und diese neue Ordnung haben wir in unserem Beitrag [Warum werden KI-Shopping-Agenten auf Websites blockiert?](/de/blog/ai-shopping-agents-blocked) behandelt; die Zusammenfassung lautet: Der legitime Weg ist nicht, der Erkennung auszuweichen, sondern die eigene Identität offen zu tragen.

## Anwendungsfälle

- **Listen, die durch Filtermenüs gehen.** In Katalogen, in denen Kategorie-, Filter- und Paginierungsschritte auf jeder Website anders funktionieren, reduziert der Agent stundenlange Arbeit pro Skript auf eine einzige Anweisung; die Skriptseite der Paginierungslogik haben wir in unserem Beitrag [Pagination](/de/blog/pagination-web-scraping) erklärt.
- **Langschwanz-Kataloge.** Hunderte kleine Händler-Websites in ein einziges Schema zu bringen, entsteht daraus, statt Selektoren pro Website zu schreiben, mit einem Agenten zu prototypisieren; das Hochskalieren mit der festen Pipeline findet sich in der Entscheidungstabelle unseres Beitrags [KI-Scraper](/de/blog/ai-web-scraper-how-it-works-2026).
- **Erste Einrichtung von Preis- und Bestandsüberwachung.** Auf einem neuen Zielset macht der Agent die erste Erkundung; ist der gefundene Weg stabil, wird dieselbe Aufgabe an ein regelbasiertes Skript übergeben; die End-to-End-Einrichtung der Überwachung steht in unserem Beitrag [Wettbewerbs-Preisüberwachung](/de/blog/competitor-price-tracking).
- **Live-Daten für Modell-Anwendungen.** Der Agent kann für Ihre Sprachmodellanwendung aktuelle Seiteninhalte sammeln und bereinigt anbieten; in dieser Nutzung muss die Zugriffsebene an die Regeln aus unserem Beitrag [Sicherer Webzugriff für LLMs](/de/blog/llm-safe-web-access) gebunden sein.

## Wann Agent, wann Skript?

| Bedarf | Empfehlung |
|---|---|
| Eine einzige, stabile Seite; hohes Volumen | Regelbasiertes Skript; kein Modell nötig |
| Seiten mit wechselnder Struktur; Weg fest | KI-Scraper (feste Pipeline + LLM-Parsing) |
| Mehrstufige Aufgabe, deren Schritte vorab unbekannt sind | Agent, mit Schritt- und Budgetobergrenzen |
| Prototyp und Erkundung, Aufgabe wächst später | Mit dem Agenten erkunden, den gefundenen Weg ans Skript übergeben |
| Millionen Seiten pro Tag | Kein Agent; regelbasierte Pipeline + Modell für Ausnahmen |

Die Regel der letzten Zeile lässt sich so zusammenfassen: Der Agent gehört zur **Erkundungs**phase einer Aufgabe, das Skript zur **Wiederholungs**phase. Den Weg, den der Agent einmal gefunden hat (besuchte Adressen, angeklickte Elemente, gesendete Formularwerte), in ein Skript zu übertragen, heißt, dieselbe Aufgabe von nun an ohne Tokens wiederholen zu lassen.

## Rechtlicher und ethischer Rahmen

Der Agent ändert das Recht des Scrapings nicht: `robots.txt`, Bedingungen der Website, personenbezogene Daten und Regeln für Inhalte hinter einer Anmeldung gelten unverändert; den Rahmen haben wir in unserem Beitrag [Ist Web Scraping legal?](/de/blog/is-data-web-scraping-legal) erklärt. Die agentenbasierte Arbeit bringt zwei zusätzliche Verantwortungen mit. Erstens wird der Seiteninhalt an die Modell-API gesendet: Bei Seiten mit personenbezogenen Daten fällt diese Übertragung selbst unter die Regulierung, und vor dem Senden ist eine Bereinigung nötig. Zweitens liest der Agent nicht nur — er klickt und kann Formulare ausfüllen; die ihm gegebenen Berechtigungen müssen deshalb auf den Mindestbedarf begrenzt und seine Aktionen protokolliert werden.

## Häufig gestellte Fragen

### Ersetzt Agentic Web Scraping das klassische Scraping?

Nein. Ein Agent bringt Wert in Aufgaben, deren Weg vorab unbekannt ist; bei stabilen Seiten und hohem Volumen bleibt das regelbasierte Skript schneller, günstiger und vorhersagbarer. Das verbreitete Muster stellt die beiden nebeneinander: der Agent erkundet, das Skript wiederholt.

### Wie werden die Kosten des Scrapings mit Agenten berechnet?

Sie sind die Zahl der Runden multipliziert mit den Token-Kosten pro Runde. Beim regelbasierten Skript ist die Zahl der Runden null, beim KI-Scraper eins; bei Agentenaufgaben variiert sie mit dem Schwierigkeitsgrad der Seite. Deshalb wird das Budget nicht an die Aufgabe, sondern an die Schleife gebunden: Schrittobergrenze und Ausgabenobergrenze stehen im Code.

### Wann ist der Einsatz eines Agenten sinnvoll?

Wenn die Struktur jedes Mal anders ist, sich die Schritte nicht vorab schreiben lassen und das Volumen der Aufgabe die Token-Kosten deckt. Filtermenüs, mehrstufige Listen und Hunderte verschiedene kleine Websites erfüllen diese Definition; eine einzelne Produktseite erfüllt sie nicht.

### Wie werden die vom Agenten gesammelten Daten validiert?

Nicht anders als die Validierung in der festen Pipeline: ein JSON-Schema, Typ- und Pflichtfeldprüfungen, Bereichsprüfungen und ein manueller Abgleich an einer Stichprobe. Zusätzlich wird bei Agentenaufgaben die erwartete Datensatzzahl überwacht; eine Aufgabe, die unter dem Erwarteten bleibt, geht nicht stillschweigend durch, sondern wird gesondert markiert.

### Websites sperren Agenten — was ist der legitime Weg?

Die Identität des Agenten nicht verbergen, sondern offen tragen; die Bedingungen der Website und `robots.txt` einhalten; wenn sie vergeben werden kann, eine verifizierte Bot-Identität nutzen. Warum Agenten gesperrt werden und die Ordnung der signierten Agenten haben wir in unserem Beitrag [KI-Shopping-Agenten](/de/blog/ai-shopping-agents-blocked) erklärt.

### Mit welchem Werkzeug beginnt man mit Agentic Scraping?

Für die Browser-Seite Playwright und eine Schnittstelle, die es mit dem Modell verbindet: entweder ein fertiger MCP-Server oder Ihre eigene Schleife. Auf der Modellseite genügt jede API mit Unterstützung strukturierter Ausgaben; zum Einstieg können Sie das Skelett oben zusammen mit einer Schrittobergrenze verwenden.

## Fazit

Agentic Web Scraping bringt das Modell sowohl in den Weg als auch in das Parsen des Scrapings: Es beobachtet die Seite, entscheidet den nächsten Schritt und extrahiert die Daten nach dem Schema. Der Gewinn: variable, mehrstufige Aufgaben passen in eine einzige Anweisung; der Preis: Kosten, die mit der Rundenzahl wachsen, und eine Unvorhersehbarkeit, die mit Code gebändigt werden muss. Stehen Schrittobergrenze, Validierungsebene und Protokollierung am Platz, ist der Agent ein starkes Werkzeug für die Erkundung; sich wiederholende stabile Aufgaben bleiben im Skript. Beim Aufbau Ihrer Datenerfassungs-Pipeline können Sie sich unsere [Datenerfassungslösungen](/de/data-scraping) ansehen.