LangGraph-Agent für Katalogdaten
Das Datenteam lud Katalogdaten von Drittanbietern von Hand, und das war langsam. Ich habe einen Agenten-Workflow gebaut, der eine kurze Anfrage entgegennimmt, die passenden Teiledaten abruft, bereinigt und in den Katalog schreibt. Jobs starten nach Zeitplan, lassen sich nach einem Fehler fortsetzen und enden mit einem Bericht, den alle prüfen können.
- Meine Rolle
- Ich habe ihn allein gebaut: die Recherche, die Architektur, den Agenten, die Zeitplanung und die Demo-Oberfläche.
- Status
- Ein funktionsfähiger Prototyp mit Demo-Oberfläche für das Datenteam. Bei meinem Ausscheiden im Juli 2026 war er nicht in Produktion.
- Stack
- Python, LangGraph, OpenAI API, APScheduler, PostgreSQL
- Umfang
- Anfragen nach Marke, Modell, Baujahr und Region für die 7 Fahrzeugmarken des Unternehmens
Das Problem
Fahrzeug- und Teiledaten von Drittanbietern in den Firmenkatalog zu laden, war wiederkehrende Handarbeit. Jemand musste viele Parameter auswählen, die Daten herunterladen, bereinigen und jeden Datensatz den richtigen Katalogtabellen zuordnen.
Ziel war es, das zu automatisieren, damit das Datenteam es nicht mehr von Hand erledigen muss.
So funktioniert es
- Anfrage Marke, Modell, Baujahr und Region, ausgewählt aus Drop-down-Listen.
- Varianten auflösen Alle passenden Fahrzeugvarianten finden und daraus den abzurufenden Katalogumfang ableiten.
- Abrufen Die Katalog-API des Drittanbieters aufrufen, mit Caching und Wiederholungsversuchen.
- Normalisieren und zuordnen Datensätze bereinigen und den richtigen Katalogtabellen zuordnen.
- Schreiben In Batches in PostgreSQL speichern, mit Checkpoints, damit sich ein Job sicher fortsetzen oder abbrechen lässt.
- Bericht Zeigen, wie jeder Batch normalisiert und zugeordnet wurde, damit das Datenteam ihn prüfen kann.
- SchedulerAPScheduler mit einer kleinen Oberfläche für geplante und manuelle Läufe
- CacheKatalogdaten bis auf Gruppenebene zwischengespeichert
- KontrolleUmfangsgrenzen, Jobstatus und sichtbare API-Nutzung
Was ich gebaut habe
- Einfach angefangen, dann berechenbar gemacht. Die erste Version nahm eine Anfrage in natürlicher Sprache entgegen, hatte einen Rückfrageschritt und protokollierte jeden Agentenschritt zum Debuggen. Sobald der Workflow stabil lief, habe ich den Freitext durch Drop-down-Eingaben ersetzt, damit Läufe wiederholbar sind.
- Warum LangGraph. Das LLM erledigt nur einen kleinen Teil der Arbeit. LangGraph lohnt sich trotzdem: Der Workflow ist strukturiert, leicht nachzuvollziehen und kann nach einem Fehler fortgesetzt werden.
- Für sehr große Jobs gebaut. Das Speichern erfolgt stückweise und lässt sich fortsetzen, sodass ein Fahrzeugmodell mit über 100.000 Varianten nach einem Fehler nicht von vorn beginnt.
- Zeitplanung. APScheduler führt Jobs nach Zeitplan oder auf Abruf aus, gesteuert über eine kleine Oberfläche.
- Nachprüfbare Ergebnisse. Automatische Berichte zeigen, wie jeder Batch normalisiert und zugeordnet wurde, sodass auch Personen ohne technischen Hintergrund das Ergebnis prüfen können.
- Dokumentation. Ich habe eine Referenzdokumentation zum Katalogschema geschrieben, die sagt, welche Tabellen der Agent liest und welche er schreibt.
Technische Abwägungen
Vor dem Bau habe ich Eigenentwicklung und Zukauf verglichen. Ich habe bestehende KI-Tools zur Datenerfassung und Workflow-Engines wie Airflow, Prefect und Celery geprüft und einen schlanken Ansatz gewählt, der zur Projektphase passte und später wachsen konnte.
Außerdem habe ich den Jobumfang und die kostenpflichtige API-Nutzung sichtbar gehalten, statt sie hinter autonomem Verhalten zu verstecken. Das Design reduziert Handarbeit, während Menschen die Kontrolle über Kosten und Daten behalten.
Status
Der Prototyp funktioniert, mit Zeitplanung und einer Demo-Oberfläche für das Datenteam, und er wurde gerade in ein einheitliches internes Admin-Tool integriert. Bei meinem Ausscheiden im Juli 2026 war er nicht in Produktion.
Diese Seite enthält keinen Code des Arbeitgebers, keine internen Daten und keine privaten URLs.