microsoft/RD-Agent: ein Agent, der Machine-Learning-Pipelines selbst baut

Welche Arbeit RD-Agent überhaupt abnimmt

Das Projekt adressiert einen konkreten Teil der Entwicklungsarbeit: das wiederholte Aufstellen einer Hypothese, deren Umsetzung in Code, das Ausführen und das Auswerten des Ergebnisses. Die Projektbeschreibung nennt als Ziel, hochwertige generische Forschungs- und Entwicklungsprozesse zu automatisieren und KI datengetriebene KI betreiben zu lassen. Adressat sind damit nicht Anwender, die ein Modell einmal trainieren, sondern Teams, die dieselbe Schleife viele Male durchlaufen: Hypothesen zu Faktoren, Merkmalen oder Modellvarianten erzeugen, bewerten und verwerfen. Die README listet dafür getrennte Szenarien auf, darunter Data Science, Kaggle, Quant-Faktor-Entwicklung sowie das Fine-Tuning von LLMs. Ein Szenario ist damit nicht ein einzelnes Skript, sondern eine vordefinierte Schleife mit eigener Bewertungslogik. Wer nur ein Notebook beschleunigen will, ist hier falsch; wer einen Bewertungsmaßstab hat, gegen den Varianten automatisch antreten können, findet die passende Struktur.

Der Loop: Hypothese, Code, Ausführung, Bewertung

Die Architektur folgt dem Muster, das die README an mehreren Stellen sichtbar macht: Ein Agent erzeugt eine Idee oder einen Faktor, ein zweiter erzeugt daraus ausführbaren Code, die Ausführung liefert ein Ergebnis, das gegen eine Metrik bewertet wird, und die Bewertung fließt in die nächste Runde zurück. Genau diese Trennung erklärt, warum die MLE-bench-Tabelle zwei Rollen getrennt ausweist: R&D-Agent o3(R)+GPT-4.1(D). Das R steht für das Reasoning-Backend, das D für das Backend, das den Code schreibt. Der Loop ist also nicht ein Modell, das alles tut, sondern eine Aufgabenteilung zwischen einem Planungs- und einem Umsetzungsschritt. Diese Aufteilung ist der eigentliche Mechanismus und zugleich der Grund, warum die Modellkonfiguration über LiteLLM mehr ist als ein Detail: Läuft eines der beiden Backends in ein Limit oder liefert es unbrauchbaren Code, bricht die Schleife nicht mit einer Fehlermeldung ab, sondern sie dreht weiter und produziert Varianten, die die Bewertung nicht bestehen. Für die Quant-Variante ist die Schleife als eigener Beitrag beschrieben und unter dem Titel R&D-Agent-Quant auf der NeurIPS 2025 angenommen.

Szenarien statt eines universellen Agenten

RD-Agent ist kein einzelner Agent mit einem Prompt, sondern eine Sammlung von Szenarien unter rdagent/scenarios. Die README verweist auf rdagent/scenarios/rl/autorl_bench/README.md für die RL-Bench und auf rdagent/app/finetune/llm/README.md für den Fine-Tuning-Agenten FT-Agent. Der Pfad rdagent/app/ deutet auf ausführbare Einstiegspunkte, rdagent/scenarios/ auf die jeweilige Fachlogik. Diese Trennung hat eine praktische Konsequenz: Der Aufwand, ein neues Szenario zu betreiben, besteht nicht darin, einen Prompt zu ändern, sondern darin, die Bewertungsfunktion und den Ausführungspfad für die eigene Domäne bereitzustellen. Die mitgelieferten Szenarien sind deshalb als Vorlagen zu lesen, nicht als Abdeckung aller Fälle. Wer ein Szenario sucht, das exakt die eigene Metrik kennt, wird es nicht finden. Die Frage ist, ob die vorhandene Struktur sich so weit anpassen lässt, dass die eigene Metrik an der Stelle der Bewertung eingesetzt werden kann. Die Dokumentation ist hier der maßgebliche Ort, nicht die README.

Installation und die Konfiguration, die wirklich zählt

Die README nennt als Plattform Linux und verweist auf das Paket rdagent bei PyPI, das sich mit pip installieren lässt. Für den Betrieb sind zwei Dinge zu klären: die Laufzeitumgebung für den erzeugten Code und der Zugang zu den Sprachmodellen. Als Standard-Backend für die Anbindung mehrerer Anbieter nennt die README LiteLLM. Das bedeutet, dass die Modellwahl nicht im Code festgeschrieben ist, sondern über die Konfiguration läuft, die LiteLLM versteht, also über Umgebungsvariablen wie den API-Schlüssel und den Endpunkt des Anbieters. Welche Schlüsselnamen im Einzelnen erwartet werden, steht nicht in der README und muss der Dokumentation entnommen werden; ich habe das Projekt nicht installiert und kann die Konfiguration deshalb nicht bestätigen. Ein weiterer Einstiegspunkt ist in der README genannt: rdagent server_ui startet eine Web-Oberfläche zum Beobachten der Läufe, die laut README das Szenario data_science derzeit ausnimmt. Für den Fine-Tuning-Pfad verweist die README auf einen eigenen Leitfaden unter rdagent/app/finetune/llm/README.md.

Die MLE-bench-Zahlen und was sie nicht sagen

Die README führt eine Tabelle zu MLE-bench, einem Benchmark mit Datensätzen aus 75 Kaggle-Wettbewerben. Für R&D-Agent o3(R)+GPT-4.1(D) nennt sie 51,52 Prozent in der Kategorie Low, 19,3 Prozent in Medium, 26,67 Prozent in High und 30,22 Prozent über alle Kategorien, jeweils mit Standardabweichung. Zum Vergleich führt dieselbe Tabelle AIDE o1-preview mit 34,3 Prozent in der Kategorie Low. Diese Zahlen sind der stärkste Beleg im Material dafür, dass der Ansatz in einem standardisierten Wettbewerbsformat funktioniert. Sie sind aber kein Beleg für den Erfolg im eigenen Projekt. Kaggle-Aufgaben haben eine feste Metrik, einen festen Datensatz und eine klare Zielfunktion. Genau diese Klarheit fehlt in vielen internen Fragestellungen. Die Spannweite zwischen Low und Medium, von über 50 auf unter 20 Prozent, zeigt zudem, dass die Aufgabenkomplexität den Ausschlag gibt. Wer aus der Tabelle eine Erwartung für sein eigenes Problem ableitet, extrapoliert über die Bedingungen hinaus, unter denen gemessen wurde.

Wo der Ansatz an seine Grenzen kommt

Der Loop optimiert gegen eine Metrik. Fehlt diese Metrik oder ist sie teuer zu erheben, verliert das System seinen Kompass: Es erzeugt weiterhin Code und Varianten, aber die Auswahl zwischen ihnen wird beliebig. Das ist der wichtigste Fall, in dem RD-Agent das falsche Werkzeug ist. Ein zweiter Punkt betrifft die Kosten. Jede Runde besteht aus mindestens zwei Modellaufrufen plus einer Ausführung, und die Anzahl der Runden ist nicht durch eine feste Obergrenze aus der README begrenzt, sondern durch die Konfiguration des jeweiligen Szenarios. Wer den Loop unbeaufsichtigt laufen lässt, bezahlt für Modellaufrufe, deren Ergebnis er nicht geprüft hat. Drittens die Plattform: Die README nennt Linux, und der erzeugte Code wird ausgeführt. Das verlangt eine isolierte Umgebung, weil generierter Code nicht vertrauenswürdig ist. Die README beschreibt diese Isolation nicht als Teil des Konzepts; sie bleibt Aufgabe des Betreibers. Wer keine Container- oder VM-Isolation bereitstellen kann, sollte den Code nicht auf einem Rechner mit Zugriff auf interne Daten ausführen.

Was andere anders machen

Der naheliegende Vergleich ist AIDE, das in der MLE-bench-Tabelle als eigener Eintrag erscheint. Der Unterschied liegt in der Kopplung: AIDE ist im Material als einzelner Agent vertreten, der eine Aufgabe bearbeitet, während RD-Agent die Rollen aufteilt und die Bewertung als eigene Stufe in den Loop einbaut. Das ist kein Qualitätsurteil, sondern eine Aussage über die Angriffsfläche. Eine geteilte Schleife lässt sich an der Bewertungsstufe austauschen, ohne den Code-Generator anzufassen. Ein einzelner Agent lässt sich leichter als Ganzes gegen ein anderes Modell tauschen. Der Preis der Aufteilung ist die zusätzliche Konfiguration: zwei Backends statt einem, zwei Fehlerquellen statt einer. Wer nur schnell ein Modell auf einem Datensatz trainieren will, fährt mit einem einzelnen Agenten kürzer. Wer dieselbe Schleife über Wochen mit wechselnden Metriken betreiben will, profitiert von der Trennung. Diese Abwägung ist aus der Struktur ableitbar, nicht aus Messwerten.

Pflege, Lizenz und was vor dem Einsatz zu prüfen ist

Das Projekt steht unter der MIT-Lizenz, die kommerzielle Nutzung und Änderung erlaubt, solange der Copyright-Hinweis erhalten bleibt. Das ist eine der permissivsten Varianten und stellt keine Weitergabeplicht für eigene Änderungen auf. Rechtlich verbindlich ist der Lizenztext im Repository, nicht diese Zusammenfassung. Zur Pflege: Die letzten im Material genannten Releases sind v0.6.1 vom 28. Juni 2025, v0.7.0 vom 8. Juli 2025 und v0.8.0 vom 3. November 2025. Zwischen v0.6.1 und v0.7.0 liegen zehn Tage, zwischen v0.7.0 und v0.8.0 knapp vier Monate. Das Muster deutet auf eine Phase mit häufigen, kleineren Anpassungen hin, gefolgt von größeren Sprüngen. Für Betreiber heißt das: Vor einem Upgrade ist der Diff zwischen den Minor-Versionen zu prüfen, weil die Szenarien eigene Einstiegspunkte unter rdagent/app/ und rdagent/scenarios/ haben und sich deren Struktur zwischen Releases verschieben kann. Die README nennt CI-, CodeQL- und Dependabot-Workflows, was auf automatisierte Prüfungen hindeutet, aber nichts über die Stabilität der Szenario-Schnittstellen aussagt. Konkret zu klären sind vor dem ersten produktiven Lauf: welches Modell als Reasoning- und welches als Coding-Backend konfiguriert wird, wo der generierte Code ausgeführt wird und ob die eigene Metrik an der Bewertungsstufe des gewählten Szenarios einsetzbar ist.

Redaktionelles Fazit

Wer wiederkehrende Modellierungs- oder Faktorarbeit auf eigenen Daten automatisieren will und bereit ist, einen LiteLLM-fähigen Endpunkt sowie Docker oder Conda bereitzustellen, findet in RD-Agent ein MIT-lizenziertem Gerüst, das genau diese Schleife kapselt. Wer eine fertige, stabile Plattform mit Zusagen zu Reproduzierbarkeit sucht, sollte zuerst die Release-Historie prüfen: zwischen v0.6.1 und v0.8.0 liegen nur rund vier Monate, was ein schnelles Bewegungstempo bedeutet. Vor dem Einsatz ist zu klären, welches Modell als Reasoning- und welches als Coding-Backend konfiguriert wird, denn die veröffentlichten MLE-bench-Zahlen gelten für die Kombination o3(R)+GPT-4.1(D) und nicht für ein einzelnes Modell.

Offizielle Quellen

1. License: MIT
2. microsoft/RD-Agent on GitHub
3. Project website
4. README
5. Releases