MLE-Agent: ein CLI-Agent für ML-Baselines, Kaggle-Tasks und Wochenberichte

Welches Problem MLE-Agent adressiert

Der Ausgangspunkt ist ein leeres Verzeichnis und eine vage Anforderung. Das README nennt als Beispiel den Satz "I want to predict the stock price based on the historical data". Genau an dieser Stelle setzt MLE-Agent an: Er soll aus einer unpräzisen Beschreibung ein Projektgerüst, einen Plan und ausführbaren Code machen, diesen Code lokal starten, Fehler lesen und korrigieren. Die Zielgruppe sind laut README Machine-Learning-Engineers und Forschende, die einen Pairing-Agenten neben sich haben wollen, keinen vollautomatischen Pipeline-Runner. Die zweite Zielgruppe sind Kaggle-Teilnehmende: der Auto-Kaggle-Modus soll von Datenaufbereitung bis Modelltraining ohne menschliche Interaktion durchlaufen. Drittens adressiert das Projekt den Berichtsaufwand: mle report erzeugt aus GitHub-Aktivität, mle report-local aus einem lokalen Git-Repository einen Wochenbericht mit Fortschritt, Kommunikationsnotizen, Referenzen und To-do-Liste. Das ist ein ungewöhnlich breiter Zuschnitt für ein Werkzeug dieser Größe, und genau darin liegt die erste Spannung: Planung, Codeausführung und Reporting teilen sich dieselbe CLI, aber nicht dieselben Fehlermodi.

Wie der Agent arbeitet: Rollen, Werkzeuge, RAG

Das README beschreibt mehrere Agenten, die miteinander interagieren, sowie einen Debugger-Coder-Zyklus: Der Coder schreibt, der Debugger liest die Fehlerausgabe und stößt eine Korrektur an. Der Ablauf ist damit nicht ein einzelner Prompt, sondern eine Schleife aus Planen, Ausführen, Auswerten und Nachbessern. Als Wissensquellen sind arxiv und Papers with Code angebunden, laut README um "best practices and state-of-the-art methods" zu ziehen. Zusätzlich gibt es lokales RAG, das README nennt es "Local RAG support to make personal ML/AI coding assistant". Der Punkt ist wichtig für die Bewertung: RAG heißt hier, dass Ihr eigener Codebestand als Kontext in die Anfragen fließt. Das erhöht die Trefferquote bei projektspezifischen Fragen, vergrößert aber auch den Prompt und damit die Kosten pro Anfrage. Die Dateisystem-Integration organisiert die Projektstruktur; der Agent legt Dateien an und ändert sie. Welche Provider tatsächlich verdrahtet sind, lässt sich aus dem Repository-Text nicht abschließend belegen: die Beschreibung nennt OpenAI, Anthropic, Gemini und Ollama, die Release Notes zu 0.4.0 nennen zusätzlich Mistral. Prüfen Sie die verfügbaren Modelle in der Dokumentation, bevor Sie eine Architektur darauf aufbauen.

Installation und die drei Einstiegspunkte

Die Installation ist konventionell. Aus PyPI: pip install -U mle-agent, alternativ uv pip install -U mle-agent. Aus dem Quelltext klonen Sie das Repository, legen mit uv venv .venv eine virtuelle Umgebung an, aktivieren sie mit source .venv/bin/activate und installieren editierbar per pip install -e . Der eigentliche Einstieg läuft über mle new <project name>. Der Befehl legt ein Projektverzeichnis unter dem aktuellen Pfad an, und ab da arbeiten Sie innerhalb dieses Verzeichnisses: cd <project name>, dann mle start für den Baseline-Ablauf oder mle chat für den interaktiven Terminal-Dialog. Für Kaggle gibt es mle kaggle im Dialogmodus und mle kaggle --auto mit den Parametern --datasets, --description, --submission, --sub_example und --comp_id für den unbeaufsichtigten Lauf. Das README weist ausdrücklich darauf hin, dass Sie dem Wettbewerb vorher beigetreten sein müssen. Für Berichte stehen mle report (Weboberfläche auf http://localhost:3000/) und mle report-local --email=<git email> --start-date=YYYY-MM-DD --end-date=YYYY-MM-DD <path_to_git_repo> bereit. Ohne Datumsangaben umfasst der Bericht laut README die letzten sieben Tage. Diese Verzeichnisbindung ist eine Designentscheidung mit Konsequenz: Der Agent arbeitet dort, wo Sie ihn starten, nicht in einem isolierten Sandkasten.

Grenzen: unbeaufsichtigte Läufe und das Verzeichnis als Angriffsfläche

Die größte Einschränkung ist struktureller Natur. Ein Agent, der Code schreibt, ausführt und auf Fehler reagiert, braucht Schreibrechte und einen Interpreter. Der Auto-Kaggle-Modus geht noch weiter und verlangt laut README ausdrücklich, dass kein Mensch eingreift. Damit verschiebt sich die Fehlerquelle: Ein falsch verstandenes Ziel führt nicht zu einer Fehlermeldung, sondern zu einem lauffähigen Skript, das die falsche Größe optimiert. Das Debugger-Coder-Paar fängt Syntaxfehler und Abstürze, nicht aber eine falsch gewählte Zielfunktion oder ein Leck zwischen Trainings- und Validierungsdaten. Wer den Agenten auf ein Verzeichnis mit echten Daten, Zugangsdaten oder produktiven Skripten loslässt, riskiert Überschreibungen, die kein Test abfängt. Ein zweiter Punkt betrifft die Umgebung: Das README zeigt keinen Mechanismus, der Abhängigkeiten auf feste Versionen pinnt oder Läufe deterministisch wiederholt. Reproduzierbarkeit ist damit Aufgabe des Nutzers, nicht des Werkzeugs. Drittens der Report-Pfad: mle report-local liest Commit-Metadaten eines Git-Repositories, also auch Verweise auf Branches und Autoren. In Organisationen mit strengen Regeln zur Weitergabe von Repository-Metadaten an externe Modell-APIs ist das vorab zu klären.

Abgrenzung zu MLflow: Orchestrierung gegen Agentenverhalten

Der naheliegende Vergleich ist MLflow, und die Unterschiede liegen nicht im Funktionsumfang, sondern im Modell. MLflow protokolliert und vergleicht Experimente: Sie schreiben die Pipeline, MLflow zeichnet Parameter, Metriken und Artefakte auf und macht Läufe vergleichbar. MLE-Agent schreibt die Pipeline. Er erzeugt aus einer Beschreibung Code, führt ihn aus und korrigiert ihn. Das sind gegenläufige Richtungen: MLflow setzt voraus, dass Sie wissen, was Sie messen wollen, MLE-Agent setzt voraus, dass Sie es noch nicht wissen. Für ein Team, das über Monate Hunderte Läufe vergleichen muss, ist MLflow die passende Ebene. Für einen einzelnen Engineer, der an einem Nachmittag wissen will, ob ein Gradient-Boosting-Ansatz auf einem Datensatz überhaupt trägt, ist der Agent schneller. Die beiden schließen sich nicht aus: Der vom Agenten erzeugte Code kann in eine MLflow-verfolgte Struktur überführt werden. Nur leistet MLE-Agent diesen Schritt nicht von selbst, jedenfalls nicht laut dem vorliegenden Material.

Wartung, Release-Takt und Lizenz

Die Release-Historie ist der schwächste Punkt in der Bewertung. Die drei jüngsten Releases sind 0.3.1 vom 12. August 2024, 0.4.0 vom 12. September 2024 und 0.4.2 vom 12. Oktober 2024. Der letzte Push auf den Hauptzweig datiert auf den 10. Juli 2026, das Repository ist nicht archiviert. Ein Abstand von rund 21 Monaten zwischen letztem Release und letztem Push ist ein Signal, aber kein Beweis: Commits können Dokumentation, Tests oder Abhängigkeiten betreffen, ohne dass eine Version geschnitten wird. Für die Upgrade-Kosten heißt das konkret: Rechnen Sie damit, dass Sie die Versionsnummer selbst aus dem Repository ziehen oder aus dem Quelltext installieren müssen, wenn Sie aktuelle Änderungen wollen. Die Lizenz ist MIT. Das ist permissiv und erlaubt kommerzielle Nutzung, Modifikation und Weitergabe, solange Copyright-Hinweis und Lizenztext beiliegen. Diese Einordnung ist keine Rechtsberatung; prüfen Sie die LICENSE-Datei im Repository und die Bedingungen der von Ihnen genutzten Modell-APIs separat, denn die Lizenz des Agenten deckt nicht die Nutzungsbedingungen von OpenAI, Anthropic, Gemini oder Ollama ab.

Wann MLE-Agent das falsche Werkzeug ist

Es gibt Konstellationen, in denen Sie das Projekt liegen lassen sollten. Erstens: regulierte Umgebungen, in denen kein Quellcode und keine Commit-Metadaten an externe Endpunkte gehen dürfen. Der lokale Pfad über Ollama entschärft das teilweise, aber die Qualität des Debugger-Coder-Zyklus hängt dann am lokalen Modell, und dazu macht das README keine Aussage. Zweitens: Teams, die bereits eine funktionierende Projektstruktur mit festen Konventionen haben. mle new legt ein neues Verzeichnis an; ein Modus, der einen Agenten kontrolliert in eine bestehende Struktur einpasst, ist im vorliegenden Material nicht beschrieben. Drittens: Aufgaben, bei denen die Zielfunktion selbst Gegenstand der Arbeit ist. Wenn unklar ist, was überhaupt gemessen werden soll, produziert ein autonom laufender Agent Code, dessen Ergebnisse Sie nicht interpretieren können. In allen drei Fällen ist der manuelle Weg über ein Notebook und ein Versionskontrollsystem die ehrlichere Wahl.

Redaktionelles Fazit

Sinnvoll ist MLE-Agent für einzelne Engineers und kleine Teams, die schnell eine lauffähige Baseline, ein Kaggle-Gerüst oder einen Git-basierten Wochenbericht brauchen und dafür ein dediziertes Projektverzeichnis opfern können. Wer reproduzierbare Pipelines, feste Abhängigkeiten und Auditierbarkeit über Monate hinweg braucht, sollte zuerst prüfen, ob der Agent in eine bestehende Struktur passt, oder auf ein orchestrierungszentriertes Werkzeug wie MLflow setzen. Vor dem ersten echten Einsatz lohnt ein Blick in die Release-Historie: die letzten drei Releases stammen aus August, September und Oktober 2024, der letzte Push datiert auf Juli 2026. Klären Sie deshalb zuerst, ob der von Ihnen gewählte Provider-Pfad in der aktuellen Version noch gepflegt wird, und testen Sie mle new in einem Wegwerf-Repository, bevor der Agent auf ein bestehendes Projektverzeichnis zugreift.

Offizielle Quellen

1. Issues
2. License: MIT
3. MLSysOps/MLE-agent on GitHub
4. README
5. Releases