Jenseits von Vibe CodingKI-Agenten skalieren mit Infrastructure-First-Retrieval

Die meisten Entwickler bringen einen KI-Agenten mit einem gut formulierten Prompt dazu, eine einzelne Seite zu scrapen. Bitten Sie Claude, den Preis von dieser URL zu holen, fügen Sie einen Link ein, und in aller Regel bekommen Sie in einem einzigen Durchgang etwas Brauchbares.

Dieser Workflow bricht schnell zusammen, sobald Sie über den Prototyp hinauswachsen. In dem Moment, in dem aus einer Seite zehntausend werden, kämpfen Sie nicht mehr mit Prompts, sondern mit Infrastruktur. Bei Retrieval-Tests im großen Maßstab tauchen immer wieder dieselben Fehler auf:

• Agenten, die CAPTCHA-Seiten verarbeiten, als wären sie echter Inhalt.
• 200 KB große HTML-Payloads, die den Token-Verbrauch explodieren lassen.
• Wiederholungsversuche, die die Inferenzkosten vervielfachen.
• Frontend-Redesigns, die stillschweigend die Extraktionslogik zerstören.
• Dieselben URLs, die immer und immer wieder neu gecrawlt werden.

Die meisten Ausfälle von KI-Agenten sind Infrastrukturprobleme im Prompting-Kostüm. In dieser Anleitung geht es nicht um bessere Prompts, sondern um den Aufbau der Schicht zwischen dem Live-Web und Ihrem Modell: normalisiertes Markdown-Retrieval über den Crawlbase Web MCP Server, Circuit Breaker, die vergiftete Antworten schon vor der Inferenz abweisen, und Cloud Storage als dauerhaftes Agentengedächtnis. Zu jedem Beispiel weiter unten gibt es ein lauffähiges Gegenstück im Begleit-Repository.

Warum KI-Agenten bei Skalierung scheitern

KI-Agenten scheitern bei Skalierung, weil das öffentliche Web verrauscht, instabil und für ein Sprachmodell teuer in der direkten Verarbeitung ist. Eine moderne Webseite ist nicht nur Inhalt. Sie besteht aus JavaScript-Bundles, Hydration-Payloads, Analytics-Skripten, doppelten DOM-Bäumen, Cookie-Bannern und Framework-State. Eine Preisseite, die schlicht aussieht, kann deutlich mehr als 200 KB rohes HTML zurückgeben, bevor irgendetwas normalisiert wurde, und das meiste davon hat nichts mit dem zu tun, was der Agent tatsächlich braucht.

Viele Agenten-Pipelines kippen diese komplette Antwort nach wie vor direkt ins Kontextfenster, und daraus entstehen zwei getrennte Infrastrukturprobleme.

Die Token-Steuer sind die Kosten dafür, irrelevantes Frontend-Markup durch die Inferenz zu schleppen. Jedes überflüssige Byte aus dem Retrieval wird früher oder später zu Token-Kosten, Latenz, Wiederholungs-Overhead und Speicherdruck. Kontextkollaps ist der Reasoning-Fehler, der darauf folgt: Das Modell verliert den semantischen Fokus, weil es damit beschäftigt ist, Markup statt Bedeutung zu verarbeiten.

In der Praxis führt das zu Fehlern, die einzeln fast komisch wirken und in Summe teuer sind. Agenten ziehen Preise aus Empfehlungs-Karussells, fassen Cookie-Banner als Seiteninhalt zusammen, halten Hydration-JSON für Produktdaten oder behandeln ein CAPTCHA-Interstitial als gültige Antwort.

Warum Markdown rohes HTML schlägt

Markdown senkt den Token-Verbrauch und erhöht die Zuverlässigkeit der Extraktion, weil es Frontend-Rauschen entfernt und dabei die semantische Struktur erhält. Rohes HTML schleppt JavaScript-Payloads, CSS-Klassen, Navigations-Markup, Tracking-Skripte und Framework-Artefakte mit, die das Modell nicht braucht. Markdown behält das, worauf Reasoning tatsächlich angewiesen ist: Überschriften, Absätze, Listen, Tabellen und Links.

Die genaue Reduktion hängt von der Website ab, die Richtung ist aber immer dieselbe: eine Größenordnung weniger Payload für dieselbe Information. Das zeigt sich als niedrigere Token-Kosten, schnellere Inferenz, sauberere Extraktion und stabileres Reasoning, alles nur durch ein besseres Signal-Rausch-Verhältnis im Kontextfenster.

Genau deshalb stellt der Web MCP Server normalisiertes Retrieval über crawl_markdown bereit, denselben Mechanismus, der auch hinter format=md in der Crawling API steckt. Wenn die Normalisierung vorgelagert passiert, darf der Prompt kurz und präzise sein:

Use crawl_markdown on https://example.com/pricing and return only:
plan names, monthly prices, and currency.
Do not paste raw HTML.
If the crawl fails, report the tool error.

Das Prinzip dahinter: Ein Modell sollte niemals beliebige Antworten aus dem Internet direkt verarbeiten. Es sollte normalisierte semantische Repräsentationen verarbeiten.

Was die Agenten-Datenebene ist

Die Agenten-Datenebene ist die Infrastrukturschicht zwischen dem Internet und dem LLM. Die meisten Teams richten ihre Aufmerksamkeit auf Prompts, Modelle und Agenten-Frameworks, doch im Produktivbetrieb ist der größere Engpass fast immer die Zuverlässigkeit des Retrievals. Die Datenebene verantwortet Retrieval, Validierung, Normalisierung, Persistenz und Kontextsteuerung, und zwar vollständig, bevor ein einziges Byte die Reasoning-Schicht erreicht.

Ohne diese Schicht arbeiten Agenten direkt gegen instabile Live-Webseiten. Das lässt sich wunderbar vorführen und verfällt rasant.

Je weiter KI-Systeme skalieren, desto mehr verschiebt sich der Engpass weg vom Prompting hin zu Retrieval-Zuverlässigkeit, Speicherverwaltung, Kontexteffizienz und deterministischem Zustand. Genau deshalb hören Markdown-Normalisierung, Retrieval-Validierung und persistenter Storage auf, Optimierungen zu sein, und werden zu Architektur.

Circuit Breaker: validieren vor der Inferenz

Ein Circuit Breaker hält vergiftetes Retrieval aus dem Kontextfenster heraus, und beim Scraping im Produktivbetrieb wiegt das schwerer, als es klingt, denn falsches Retrieval ist meist schlimmer als fehlendes. Fehlende Daten melden sich von selbst. Falsche Daten werden zusammengefasst, gespeichert und zur Grundlage von Entscheidungen.

Das Modul circuit_breaker.py im Begleit-Repository implementiert eine Fail-Closed-Validierung vor der Reasoning-Schicht:

def evaluate(
    result: CrawlResult,
    *,
    max_body_chars: int = DEFAULT_MAX_BODY_CHARS,
    expect_markdown: bool = True,
) -> CircuitDecision:

    if result.http_status != 200:
        return CircuitDecision(False, f"HTTP status {result.http_status}")

    if result.cb_status and result.cb_status != "200":
        return CircuitDecision(
            False,
            f"Crawlbase cb_status={result.cb_status}"
        )

    if not result.body.strip():
        return CircuitDecision(False, "empty body")

    if expect_markdown and not result.content_type.startswith("text/markdown"):
        return CircuitDecision(
            False,
            f"expected markdown, got {result.content_type}"
        )

    if len(result.body) > max_body_chars:
        return CircuitDecision(
            False,
            f"body exceeds {max_body_chars} chars"
        )

    return CircuitDecision(True, "ok")

Diese Funktion ist eine Firewall zwischen dem öffentlichen Web und dem Kontextfenster. Statt jeder Antwort zu vertrauen, prüft sie Transportstatus, den Crawlbase-cb_status, leere Bodies, Content-Type und Payload-Größe, bevor irgendetwas das Modell erreicht. Beachten Sie: cb_status ist die aktuelle Bezeichnung des Crawlbase-Statusheaders; älterer Code und ältere Tutorials nennen ihn teils noch pc_status.

Das ist wichtig, weil Anti-Bot-Systeme selten laut scheitern. Eine Anfrage kann auf der Transportschicht erfolgreich sein und trotzdem eine CAPTCHA-Seite, ein Zugriff-verweigert-Dokument, ein Challenge-Interstitial oder eine leere Hydration-Hülle ausliefern. Modelle argumentieren über all das souverän weiter, solange die Retrieval-Schicht es nicht vorher abweist.

Ohne Circuit Breaker ist die Fehlerkette im Produktivbetrieb vorhersehbar:

1. Die Zielseite liefert eine CAPTCHA-Seite.
2. Der Agent behandelt dieses HTML als echten Inhalt.
3. Extraktions-Pipelines speichern vergiftete Daten.
4. Monitoring-Systeme melden Änderungen, die es nie gab.
5. Wiederholungsschleifen vervielfachen Token- und Crawl-Kosten zugleich.

Ein einziges falsches Retrieval kann einen ganzen Multi-Agenten-Workflow vergiften, und genau deshalb gehört die Validierung vor die Inferenz und nicht dahinter. Die lauffähige Fassung finden Sie in der Circuit-Breaker-Implementierung.

Warum Storage besser ist als erneutes Crawlen

Produktiv-Agenten sollten ihr Gedächtnis abfragen, bevor sie das Internet abfragen. Die meisten Agenten-Tutorials behandeln das Web als zustandslos; echte Systeme können sich das nicht leisten. Dieselben URLs immer wieder neu zu crawlen erhöht den Token-Verbrauch, destabilisiert das Retrieval, erzeugt inkonsistente Ausgaben und verursacht Crawl-Overhead, der nichts einbringt.

Hier verdient sich Crawlbase Cloud Storage seinen Platz in der Architektur. Die Ingest-Pipeline legt normalisierte Markdown-Snapshots mit store=true ab, statt bei jedem Lauf Live-Seiten neu zu verarbeiten:

params = {
    "token": token,
    "url": url,
    "format": "md",
    "md_readability": "true",
    "store": "true",
}

Das Ergebnis ist ein rid-basierter Retrieval-Workflow, in dem Agenten Referenzen austauschen statt vollständiger Payloads. Statt bei jedem Schritt große Dokumente durch das Modell zu schieben, persistiert das System normalisiertes Markdown, Retrieval-Metadaten, rid-Referenzen und Token-Schätzungen und holt den Inhalt dann per Referenz über storage_get, wenn ein Schritt ihn wirklich braucht.

Es gibt einen zweiten Vorteil, den man leicht übersieht: Determinismus. Das Live-Internet ist nichtdeterministisch, dank Frontend-Redesigns, A/B-Tests, Personalisierung und ganz normaler DOM-Fluktuation. Snapshots aus dem Storage geben Ihnen eine feste Eingabe, über die sich argumentieren lässt, und das ist der Unterschied zwischen einer Pipeline, die Sie debuggen können, und einer, die Sie nur beobachten können.

Den vollständigen Workflow finden Sie im Storage-first-Ingest-Skript des Begleit-Repositorys.

Änderungserkennung, ohne alles neu zu verarbeiten

Persistenter Storage macht die Änderungserkennung dramatisch billiger, weil das System normalisierte Snapshots vergleicht, statt ganze Webseiten erneut durch das Modell zu schicken. Das Skript change_detection.py im Begleit-Repository vergleicht gespeichertes Markdown mit einem frischen, normalisierten Crawl, und dieser Vergleich ist bewusst langweilig:

prev_hash = hashlib.sha256(previous.encode("utf-8")).hexdigest()
curr_hash = hashlib.sha256(current.encode("utf-8")).hexdigest()

Stimmen die beiden Hashes überein, meldet das Skript UNCHANGED und hält an. Es läuft kein Zusammenfassungs-Durchgang, es findet keine nachgelagerte Inferenz statt, und es werden keine Token verbraucht. Genau darum geht es bei diesem Muster: Der billigste Reasoning-Schritt ist der, den Sie nie ausführen. Die lauffähige Fassung ist die Implementierung der Änderungserkennung.

Das Begleit-Repository zur Datenebene

Das Begleit-Repository zeigt diese Muster im Zusammenspiel in einer einzigen Retrieval-Pipeline. Statt rohe Webseiten ins Modell zu schicken, validiert der Workflow Antworten vor der Inferenz, überführt Seiten in normalisiertes Markdown, legt Snapshots für späteres Retrieval ab und vergleicht Gespeichertes deterministisch mit Live-Inhalten. Getragen wird das von drei Modulen:

• circuit_breaker.py für die Fail-Closed-Validierung des Retrievals.
• ingest.py für den Storage-first-Ingest von Markdown.
• change_detection.py für Snapshot-Vergleiche und Monitoring-Workflows.

Entscheidend sind nicht die Skripte, sondern die Form: Ein URL-Batch kommt herein, der Circuit Breaker weist ab, was ein Modell nie erreichen sollte, was übrig bleibt wird zu Markdown normalisiert und gespeichert, und der Agent liest später kleine Ausschnitte per Referenz, statt neu zu crawlen. Agenten sollten über validiertes, normalisiertes, persistentes Retrieval argumentieren, nicht über beliebige Antworten aus dem Internet.

Den Web MCP Server mit Claude verbinden

Der Web MCP Server lässt sich direkt in Claude Desktop oder Claude Code einklinken. Die Dokumentation zu KI und MCP und der Leitfaden zur Claude-Integration behandeln Einrichtung, Cloud-Storage-Workflows und die Retrieval-Tools ausführlicher. Die Konfiguration für Claude Desktop ist kurz:

{
  "mcpServers": {
    "crawlbase": {
      "type": "stdio",
      "command": "npx",
      "args": ["@crawlbase/mcp@latest"],
      "env": {
        "CRAWLBASE_TOKEN": "YOUR_TOKEN",
        "CRAWLBASE_JS_TOKEN": "YOUR_JS_TOKEN"
      }
    }
  }
}

Nach einem Neustart von Claude stehen die Retrieval-Tools in der Modellumgebung bereit: crawl_markdown für normalisierte Abrufe sowie storage_get, storage_list und storage_bulk_get, um zu lesen, was Sie bereits gecrawlt haben. Dieselben Infrastrukturmuster funktionieren dann interaktiv in Claude oder operativ über Python-Pipelines, und genau darum gehören sie in die Datenebene und nicht in einen Prompt.

Produktionsmuster, die skalieren

Eine Handvoll Regeln trennt Retrieval-Systeme, die den Produktivbetrieb überstehen, von denen, die nur in der Demo gut aussehen.

Markdown als Standard

Behandeln Sie rohes HTML als Rückfallebene, nicht als Standardformat fürs Reasoning. Die meisten Seiten transportieren weit mehr Frontend-Rauschen als Inhalt, und dieses Rauschen kostet Token, ohne die Extraktionsqualität zu verbessern. Markdown behält die Semantik und wirft den Ballast weg, was Reasoning schneller, günstiger und stabiler macht.

Im Fehlerfall blockieren

Falsches Retrieval ist schlimmer als fehlendes. Eine CAPTCHA-Seite, ein Soft Block oder ein kaputtes Rendering kann HTTP 200 zurückgeben und dem Modell trotzdem Gift verabreichen. Weisen Sie verdächtiges Retrieval an der Grenze ab, statt darauf zu hoffen, dass das Modell es bemerkt.

Zuerst das Gedächtnis abfragen

Prüfen Sie den Storage, bevor Sie neu crawlen. Dieselben Seiten wiederholt abzurufen erzeugt Token-Kosten, instabile Ausgaben und doppelten Crawl-Overhead. Persistente Snapshots lassen Agenten über eine feste statt über eine bewegliche Eingabe argumentieren.

Kontextbudgets durchsetzen

Kontextfenster sind eine Infrastrukturressource mit Preisschild. Große Payloads erhöhen Kosten, Latenz und Reasoning-Instabilität gleichzeitig; begrenzen Sie die Payload-Größe deshalb, bevor Inhalt ins Fenster gelangt, und nicht erst, wenn die Rechnung kommt.

Retrieval vom Reasoning trennen

Validierung und Normalisierung gehören dem Modell vorgelagert. Die Pipeline in retrieval, validation, normalization, persistence und reasoning aufzuteilen, verschafft Ihnen saubere Fehlerisolation, stabilere Ausgaben und ein System, das Sie im großen Maßstab tatsächlich debuggen können.

Was tatsächlich skaliert

Vibe Coding reicht aus, um einen Agenten auf einer einzelnen Seite zum Laufen zu bringen. Schwierig wird es, wenn derselbe Workflow über Tausende von Seiten laufen muss, dauerhaft und ohne Aufsicht. Ab da lautet die Frage nicht mehr, wie man das Modell promptet, sondern wie man aufhört, es mit verrauschtem, instabilem oder teurem Retrieval zu füttern.

Zuverlässige Systeme laufen meist auf dieselben Entscheidungen hinaus: Markdown statt rohem HTML, Storage statt zustandslosem Crawlen, Circuit Breaker statt blinder Wiederholungsversuche, deterministische Snapshots statt Live-Browsing und Validierung vor der Inferenz. Je weiter Agenten skalieren, desto weniger verhalten sie sich wie Chatbots und desto mehr wie verteilte Systeme, und der Engpass verlagert sich auf Retrieval-Zuverlässigkeit, Speicherarchitektur, Normalisierung, Persistenz und Token-Steuerung.

Wenn Sie in diese Richtung bauen, zeigen unsere Anleitungen zu KI-Agenten-Workflows mit dem Web MCP Server und zum Aufbau eines KI-Forschungsdatensatzes dieselbe Datenebene an konkreten Aufgaben. Die nächste Generation von KI-Systemen wird nicht allein durch bessere Prompts definiert. Sie wird durch bessere Retrieval-Infrastruktur definiert.

Häufig gestellte Fragen

Warum scheitern KI-Agenten beim Scrapen großer Seitenmengen?

Kleine Demos funktionieren, weil das Modell verrauschtes Retrieval stillschweigend ausgleicht. Bei höheren Crawl-Volumina verarbeiten Agenten übergroße HTML-Payloads, CAPTCHA-Seiten, doppeltes Frontend-Markup und instabile Live-Antworten, und das führt zu Kontextkollaps, aufgeblähten Token-Kosten und inkonsistenter Extraktion. Der Fehler liegt in der Datenebene, nicht im Prompt.

Warum ist Markdown für KI-Agenten besser als HTML?

Markdown erhält die semantische Struktur und entfernt zugleich den größten Teil des Frontend-Rauschens, was Token-Verbrauch, Kontextverschmutzung, Inferenzlatenz und Extraktionsinstabilität senkt. Dieselbe Seite, die als rohes HTML 50K+ Token kostet, passt als Markdown typischerweise in ein paar Tausend Token, bei besserem Signal-Rausch-Verhältnis im Kontextfenster.

Was ist ein Circuit Breaker in der KI-Infrastruktur?

Er ist ein Validierungs-Gate, das läuft, bevor Inhalt das LLM erreicht. Es weist HTTP-Fehler, cb_status-Werte ungleich 200, leere Bodies, unerwartete Content-Types und übergroße Payloads ab, damit vergiftetes Retrieval nie zur Reasoning-Eingabe wird. Die Regel lautet fail closed: Sieht eine Antwort falsch aus, wird sie verworfen statt zusammengefasst.

Warum sollten Agenten Storage nutzen, statt Seiten neu zu crawlen?

Persistenter Storage liefert deterministisches Retrieval, historische Vergleiche, wiederholbare Workflows, niedrigere Crawl-Kosten und geringeren Token-Verbrauch. Agenten tauschen rid-Referenzen statt vollständiger Dokumente aus und holen Inhalte nur, wenn ein Schritt sie braucht. Produktiv-Agenten sollten ihr Gedächtnis abfragen, bevor sie das Internet abfragen.

Was ist die Agenten-Datenebene?

Die Agenten-Datenebene ist die Infrastrukturschicht zwischen dem Internet und dem LLM. Sie kümmert sich um Retrieval, Validierung, Normalisierung, Persistenz und Kontextsteuerung, und sie wird umso wichtiger, je weiter ein KI-System über den Prototyp hinaus skaliert.

NZ

Neil Zamora

Senior Architect · Crawlbase

Senior Architect bei Crawlbase mit Fokus auf den Systemen hinter großflächigem Crawling: Proxy-Rotation, Anti-Bot-Resilienz und den APIs, die diese Komplexität verbergen.

IK

Ian Kalvin

Technical Support Engineer · Crawlbase

Technical Support Engineer bei Crawlbase, der von der Front darüber schreibt, was beim Scraping und bei Proxy-Setups im Produktivbetrieb tatsächlich kaputtgeht.