Accelerator-Serie: Aufbau eines robusten Web Scrapers mit LangGraph und TrueFoundry

Das Vertriebsteam gerät in Panik — nächste Woche findet eine große Gesundheitskonferenz statt. Auf der Veranstaltungswebsite sind 200 Redner — Ärzte, Führungskräfte und Forscher — aufgeführt, die sich auf ein Dutzend paginierter Unterseiten verteilen. Um eine Lead-Liste zu erstellen, muss jemand die Website öffnen, auf einen Namen klicken, die Details in eine Tabelle kopieren, einen neuen Tab öffnen, auf LinkedIn nach dieser Person suchen, die Profil-URL kopieren und wieder einfügen.

Sie müssen das 200 Mal machen.

Für Ingenieure führt diese Anfrage normalerweise zu einem schnellen Python-Skript mit Selenium oder BeautifulSoup. Sie überprüfen den Seitenquelltext, finden das Div mit dem Namen des Klassensprechers und extrahieren den Text. Es funktioniert perfekt für ungefähr eine Woche. Dann aktualisiert die Website ihr Frontend-Framework, die CSS-Klassen ändern sich und das Skript stürzt ab.

Wir haben das gebaut Profil Crawler Beschleuniger, um diesen Zyklus zu stoppen. Es ist ein autonomer Agent, der auf Websites navigiert und Daten auf der Grundlage dessen extrahiert, was auf der Seite steht, und nicht darauf, wie der HTML-Code strukturiert ist.

So haben wir die Lösung konzipiert und dabei LangGraph für die Orchestrierung, Playwright für die Interaktion und TrueFoundry für die Verwaltung der Infrastruktur verwendet.

Der Wandel: Von DOM-Selektoren zur semantischen Extraktion

Der Hauptgrund, warum Scraping-Skripte fehlschlagen, ist ihre Abhängigkeit vom Document Object Model (DOM). Wenn Sie einem Skript sagen, dass es nach div.content-wrapper > h2.title suchen soll, wird es in dem Moment kaputt gehen, in dem ein Entwickler einen Klassennamen ändert.

Wir sind zu einem agentischen Ansatz übergegangen. Wir sagen es dem Bot nicht woher Die Daten sind pixelweise angeordnet. Stattdessen geben wir das gerenderte HTML (in Markdown konvertiert) an ein LLM weiter. Das Modell liest den Text so, wie es ein Mensch tun würde. Es versteht, dass ein Abschnitt mit der Bezeichnung „Keynote Speakers“ die von uns gewünschten Daten enthält, unabhängig von den zugrunde liegenden Tags.

• Alter Weg (fragil): Hartcodierte CSS-Selektoren, die bei UI-Updates kaputt gehen.
• Neuer Weg (belastbar): Semantisches Verständnis, das sich an Layoutänderungen anpasst.

Tiefer Einblick in die Architektur

Wir brauchten ein System, das Entscheidungen treffen kann, nicht nur ein lineares Skript. Die Anwendung muss entscheiden: Ist diese Eingabe eine URL oder nur ein Firmenname? Haben wir ein Captcha gedrückt? Ist diese Seite eine Liste von Personen oder eine einzelne Biografie?

Wir haben uns für LangGraph entschieden, um diesen Workflow als Zustandsmaschine zu modellieren, insbesondere wenn Langflow gegen LangGraph Entscheidungen begünstigen eine staatliche Orchestrierung.

Der Logikfluss

Das System arbeitet in einer Schleife und nicht in einer geraden Linie:

1. Eingangs-Router: Das System prüft, ob der Benutzer eine direkte URL oder nur einen Firmennamen angegeben hat. Wenn es sich um einen Namen handelt, verwendet es zuerst ein Suchwerkzeug, um die richtige Domain zu finden.
2. Stealth-Navigation: Wir verwenden eine modifizierte Playwright-Instanz, um die Seite zu laden. Sie verarbeitet Banner zur Zustimmung zu Cookies und Bilder, die im Lazy-Loading-Modus geladen werden, automatisch.
3. Vektorfilterung (Die Optimierung): Eine einzelne Konferenzseite kann 200 Navigationslinks enthalten. Es ist langsam und teuer, sie alle in ein LLM-Kontextfenster einzufügen. Wir verwenden Schnelles Einbetten um den Linktext einzubetten und ein lokales abzufragen Adrant Instanz. Dadurch wird die Liste auf die 10 wichtigsten Links gefiltert, die für „Team“ oder „Sprecher“ relevant sind.
4. Extraktion: Das LLM analysiert den gefilterten Inhalt und extrahiert strukturierte Entitäten (Name, Rolle, Unternehmen).
5. Anreicherung: Schließlich durchsuchen wir die extrahierten Namen und verwenden ein Suchwerkzeug (Tavily), um ihre spezifischen LinkedIn-Profile zu finden.

Hier ist die Systemarchitektur:

‍

Infrastruktur und TrueFoundry-Integration

Der Betrieb von Headless-Browsern und LLM-Agenten in der Produktion verursacht betriebliche Probleme: Speicherlecks durch Chromium, Ratenbeschränkungen für LLM-APIs und die Notwendigkeit einer Prozessisolierung.

Wir haben das bereitgestellt auf Wahre Gießerei um mit diesen spezifischen Einschränkungen umzugehen.

1. Das AI-Gateway (Beobachtbarkeit und Caching)

Diese Anwendung nutzt LLMs häufig für Navigationsentscheidungen. Ohne Verwaltung steigen die Kosten schnell in die Höhe. Wir leiten alle Model-Calls über den TrueFoundry KI-Gateway.

• Zwischenspeichern: Wenn der Agent dieselbe Site zweimal scrapt, liefert das Gateway zwischengespeicherte LLM-Antworten für die Extraktionsschritte. Dadurch werden Latenz und Kosten erheblich reduziert.
• Ratenbegrenzung: Wir legen strenge Grenzwerte pro Benutzer fest, um eine Ausschöpfung der API-Kontingente bei großen Batch-Aufträgen zu verhindern.
• Ausfallsicherung: Wenn OpenAI ausfällt, leitet das Gateway Anfragen automatisch an Anthropic oder Azure OpenAI um, ohne dass der Crawl fehlschlägt.

2. Modellkontext-Protokoll (MCP)

Wir haben die Anwendung strukturiert mit dem Modellkontextprotokoll (MCP). Der „Crawler“ ist nicht nur eine Python-Funktion; er ist ein MCP-Server. Dies ermöglicht es uns, die Browserumgebung in einer Sandbox zu installieren. Wenn der Browser abstürzt (was bei Websites mit vielen JavaScript-Inhalten häufig der Fall ist), wird die Hauptanwendungslogik nicht unterbrochen.

Infrastruktur-Diagramm

Vergleich: Script gegen Agent

Wir haben den standardmäßigen Python-Skriptansatz mit dieser Architektur verglichen.

Umgang mit Edge-Fällen

Den Weg des Glücks zu beschreiten ist einfach. Um es zuverlässig zu machen, mussten drei spezifische technische Probleme gelöst werden:

1. Doppelte Daten: Profile erscheinen oft auf mehreren Seiten (z. B. sowohl „Führung“ als auch „Über uns“). Wir haben eine hinzugefügt Deduplizierungsknoten am Ende der Grafik. Es übergibt die vollständige Liste an ein kleineres, billigeres LLM, um Datensätze auf der Grundlage der Namensähnlichkeit vor der Anreicherung zusammenzuführen.
2. Anti-Bot-Erkennung: Standard Playwright wird von modernen WAFs leicht erkannt. Wir haben undetected-playwright im Docker-Container implementiert, der den Browser-Fingerabdruck (Navigator-Objekt, WebGL-Anbieter) so aktualisiert, dass er als Standardbenutzergerät erscheint.
3. Token-Limits: Große Seiten mit Datenschutzrichtlinien und Fußzeilen verschwenden Tokens. Wir verwenden Header-basiertes Chunking um den Markdown aufzuteilen. Das LLM verarbeitet nur Chunks, die für „Team“ oder „Speakers“ relevant sind, und verwirft den Rest.

Fazit

Diese Architektur löst die „letzte Meile“ der Datenerfassung, indem spröde Skripte durch adaptive Agenten ersetzt werden. Indem wir es auf TrueFoundry ausführen, stellen wir sicher, dass das System beobachtbar, kosteneffizient und skalierbar ist.

Sie können genau diese Architektur — einschließlich der Gateway-Konfiguration und der Dockerized Agents — noch heute aus der TrueFoundry-Anwendungsbibliothek bereitstellen.

‍