DATAGEN: ein Multi-Agenten-System für Hypothesen, Analyse und Bericht, konfiguriert über YAML

Welches Problem hier tatsächlich adressiert wird

Der Ausgangspunkt ist eine CSV-Datei und eine Frage in natürlicher Sprache. Was normalerweise dazwischen liegt, ist Handarbeit: Spalten sichten, Ausreißer behandeln, ein Modell wählen, Plots erzeugen, Ergebnisse in Prosa gießen, alles gegenlesen. DATAGEN setzt an genau dieser Kette an und verteilt sie auf Rollen. Das README nennt acht Komponenten: hypothesis_agent, process_agent, visualization_agent, code_agent, searcher_agent, report_agent, quality_review_agent und note_agent. Die Zielgruppe sind damit weniger Data-Science-Teams mit etablierter Pipeline als Einzelpersonen, die einen ersten Durchlauf durch einen Datensatz brauchen und dabei nachvollziehen wollen, welcher Schritt welches Ergebnis produziert hat. Der Nutzen liegt nicht in einem einzelnen Modellaufruf, sondern in der Aufteilung: Der Code-Agent schreibt Analyse-Code, der Review-Agent prüft das Ergebnis, der Note-Agent protokolliert den Verlauf. Ob diese Aufteilung in der Praxis trägt, hängt an der Qualität der Übergaben zwischen den Agenten, und dazu sagt das README nichts.

Der Zustandsgraph und die Rolle des Note-Agenten

Laut README erzeugt das System mit LangGraph einen State Graph, der den gesamten Ablauf verwaltet. Die dokumentierten Schritte sind: Hypothesengenerierung, menschliche Auswahl (weiter oder Hypothese neu erzeugen), Verarbeitung mit Datenanalyse, Visualisierung, Suche und Berichtserstellung, Qualitätsprüfung, anschließend Revision nach Bedarf. Bemerkenswert ist der zweite Schritt. An dieser Stelle stoppt der Graph und erwartet eine Entscheidung von außen. Das ist kein nebensächliches Detail, sondern die Stelle, an der das System aufhört, autonom zu sein. Wer einen vollständig unbeaufsichtigten Lauf erwartet, wird hier unterbrochen. Der note_agent ist die zweite Besonderheit: Er hält den Verlauf fest, damit nachfolgende Agenten nicht bei jedem Schritt neu aus dem Rohtext aufbauen müssen. Das README beschreibt ihn als Zustandsverfolgung über die Analysephasen hinweg. Wie dieser Speicher begrenzt wird, ob er gekürzt, zusammengefasst oder vollständig weitergereicht wird, steht in dem vorliegenden Material nicht. Genau dort entscheidet sich aber, ob lange Analysen an Kontextgrenzen scheitern.

Installation: Conda, requirements.txt, .env

Die Einrichtung folgt einem vertrauten Muster. Zuerst das Repository klonen, dann eine Conda-Umgebung mit Python 3.10 anlegen (das README nennt 3.10 oder höher als Systemanforderung), aktivieren und die Abhängigkeiten installieren. Die Befehle lauten: conda create -n datagen python=3.10, conda activate datagen, pip install -r requirements.txt. Danach wird die Datei .env Example in .env umbenannt und ausgefüllt. Pflichtwerte sind WORKING_DIRECTORY (Standard ./data/, zugleich vom Filesystem-MCP-Server genutzt), CONDA_ENV (im Beispiel datagen) und CHROMEDRIVER_PATH, im Beispiel ./chromedriver-linux64/chromedriver. Alles andere ist als optional markiert: OPENAI_API_KEY, ANTHROPIC_API_KEY, GOOGLE_API_KEY, FIRECRAWL_API_KEY, CRW_API_KEY und CRW_API_URL, TAVILY_API_KEY, GITHUB_TOKEN sowie die LangChain-Tracing-Variablen LANGCHAIN_TRACING_V2, LANGCHAIN_PROJECT und LANGCHAIN_API_KEY. Zwei Hinweise aus dem README sind praktisch relevant: Fehlt FIRECRAWL_API_KEY, können die Suchfähigkeiten eingeschränkt sein. Und CONFIG_DIRECTORY ist optional, standardmäßig config/, wobei das README config_local für lokale Entwicklung empfiehlt, weil dieser Pfad bereits in .gitignore steht.

Ausführung: main.py, user_input und der datapath

Der dokumentierte Einstieg ist ein Python-Skript, kein CLI-Werkzeug und kein Server. Man legt die Datendatei in das Datenverzeichnis, etwa YourDataName.csv, öffnet main.py und ändert die Variable user_input in der Funktion main(). Das README zeigt dafür ein Beispiel im Wortlaut: datapath:YourDataName.csv, gefolgt von der Zeile 'Use machine learning to perform data analysis and write complete graphical reports'. Gestartet wird mit python main.py. Das ist eine bewusste Designentscheidung und gleichzeitig eine Einschränkung. Der Auftrag steht im Quellcode, nicht in einem Argument. Für wiederkehrende Läufe bedeutet das entweder Datei bearbeiten oder das Skript umbauen. Der datapath wird relativ zum WORKING_DIRECTORY aufgelöst, weshalb der Pfad in user_input nur den Dateinamen enthält. Wer die Datei woanders ablegt, muss WORKING_DIRECTORY in .env anpassen. Eine Kommandozeilen-Schnittstelle oder eine Batch-Verarbeitung mehrerer Dateien ist im vorliegenden Material nicht beschrieben.

Modellwahl pro Agent: die eigentliche Stärke

agent_models.yaml im CONFIG_DIRECTORY ist der interessanteste Teil des Projekts. Jeder Agent bekommt dort einen provider und einen model_config-Block mit model und temperature (Bereich 0.0 bis 2.0, laut README). Das Beispiel im README kombiniert drei Anbieter in einer Datei: hypothesis_agent mit provider openai und dem Modell gpt-5-nano, note_agent mit provider google und gemini-2.5-pro, code_agent mit provider anthropic und claude-haiku-4-5, jeweils mit temperature 1.0. Als mögliche Provider nennt das README openai, google, anthropic, ollama und groq. Damit lässt sich ein teures Modell genau dort einsetzen, wo es zählt, und ein günstiges für Routineaufgaben. Der Wechsel zwischen Entwicklung und Produktion läuft laut README über einen anderen Konfigurationsordner, also über CONFIG_DIRECTORY, nicht über Codeänderungen. Das ist eine saubere Trennung. Zu beachten ist, dass temperature 1.0 in allen drei Beispielen steht. Für Code-Erzeugung ist das ein hoher Wert, und wer reproduzierbare Läufe braucht, wird hier zuerst ansetzen müssen. Das README kommentiert diese Wahl nicht.

Wo das System an Grenzen stößt

Die Qualitätsprüfung ist ein Agent, kein Test. Der quality_review_agent bewertet die Arbeit anderer Agenten, vermutlich ebenfalls über einen Modellaufruf. Ob ein statistisch falscher Schluss, eine verletzte Annahme oder ein stiller Fehler in einer Aggregation dabei auffällt, lässt sich aus dem README nicht ableiten. Wer Zahlen aus dem erzeugten Bericht weiterverwendet, braucht eine unabhängige Prüfung. Ein zweiter Punkt betrifft die Abhängigkeiten nach außen: Chromedriver, Firecrawl beziehungsweise der kompatible Scraper fastCRW, Tavily und GitHub werden über MCP-Server angebunden. Das sind zusätzliche Prozesse und zusätzliche Fehlerquellen, und die Suchfähigkeiten sind laut README eingeschränkt, wenn der Firecrawl-Schlüssel fehlt. Drittens die Datenhaltung: Das Filesystem-MCP arbeitet auf WORKING_DIRECTORY. Was dort liegt, ist für den Agenten erreichbar. Für vertrauliche Daten ist das eine Frage, die vor dem ersten Lauf geklärt werden muss, nicht danach. Schließlich fehlen im vorliegenden Material Angaben zu Tests, Fehlerbehandlung und Wiederaufsetzen nach einem Abbruch. Bei einem mehrstufigen Graphen mit externen Aufrufen ist das ein reales Risiko.

Alternative: ein Skript mit festem Ablauf statt Agenten

Der naheliegende Vergleich ist kein anderes Multi-Agenten-Framework, sondern ein gewöhnliches Analyse-Skript mit festen Schritten, etwa pandas für die Aufbereitung, scikit-learn für das Modell und matplotlib für die Plots. Der Unterschied liegt nicht in der Ausgabequalität, sondern in der Steuerung. Ein Skript führt dieselben Operationen in derselben Reihenfolge aus, jedes Mal. DATAGEN entscheidet pro Lauf, welchen Code der code_agent schreibt und welche Visualisierung sinnvoll erscheint. Das ist der Vorteil, wenn der Datensatz unbekannt ist und man einen Erkundungslauf will. Es ist der Nachteil, wenn ein Bericht in einem Monat mit denselben Zahlen erneut erzeugt werden soll. Wer Reproduzierbarkeit braucht, ist mit einem festen Skript besser bedient, auch wenn dessen Erstellung länger dauert. Umgekehrt skaliert ein festes Skript nicht auf die Frage 'was könnte in diesen Daten stecken', und genau diese Frage beantwortet DATAGEN mit dem hypothesis_agent, bevor überhaupt Code entsteht.

Wartung, Lizenz und was vor dem Einsatz zu klären ist

Das Projekt steht unter MIT-Lizenz. Das ist permissiv und erlaubt kommerzielle Nutzung, Veränderung und Weitergabe, sofern Lizenz- und Urheberrechtshinweis erhalten bleiben. Rechtliche Einordnung ist das nicht; wer DATAGEN in ein Produkt einbettet, muss die Haftungsfreistellung der MIT-Lizenz selbst bewerten. Zu den Betriebskosten macht das README keine Angaben. Klar ist nur, dass jeder Agent eigene Modellaufrufe erzeugt und dass mehrere Anbieter parallel konfigurierbar sind. Die Kosten skalieren also mit der Zahl der Agentenschritte und der Wahl der Modelle in agent_models.yaml, nicht mit der Größe der Eingabedatei. Wartungsseitig fällt auf, dass es laut den vorliegenden Angaben keine Releases gibt und das README an einer Stelle mitten im Satz abbricht. Die Konfigurationsstruktur wird als 'Progressive Disclosure' bezeichnet, der Rest der Erklärung fehlt. Wer das Projekt einsetzen will, sollte daher mit der Struktur in config/ beginnen und die dort liegenden Dateien agent_models.yaml, den Ordner agents/ und mcp.yaml als maßgeblich behandeln. Ein Upgrade-Pfad ist nicht dokumentiert, und Änderungen an der Konfigurationsstruktur würden eigene Anpassungen brechen. Das ist bei einem Projekt ohne Versionsnummern der größte Unsicherheitsfaktor.

Redaktionelles Fazit

Wer einen LangGraph-Ablauf braucht, bei dem Hypothese, Code, Visualisierung, Recherche und Review als getrennte Agenten mit eigenen Modellen in agent_models.yaml stehen, findet hier eine konkrete Vorlage. Wer reproduzierbare Zahlen ohne manuelle Prüfschritte erwartet, sollte zuerst einen Lauf mit einer kleinen CSV in ./data/ durchführen und den generierten Code prüfen, bevor er den Bericht verwendet.

Offizielle Quellen

1. Issues
2. License: MIT
3. README
4. zi-yue-1129/DATAGEN on GitHub