AgentsMeetRL: eine kuratierte Liste für RL-Training von LLM-Agenten

Welche Lücke AgentsMeetRL füllt

Wer heute einen LLM-Agenten mit Reinforcement Learning trainieren will, steht vor einer unübersichtlichen Auswahl. Trainingsframeworks, Umgebungen, Reward-Modelle und fertige Agentenprojekte liegen verstreut über Paper, Repositories und Blogposts. AgentsMeetRL setzt genau dort an: Es ist eine kuratierte Liste von Open-Source-Repositories, in denen LLM-Agenten per Reinforcement Learning trainiert werden. Die Zielgruppe sind Forschende und Ingenieure, die wissen wollen, welche technischen Entscheidungen andere Projekte getroffen haben, bevor sie selbst eine Pipeline aufsetzen. Die Aufnahmekriterien sind eng gefasst: Ein Projekt gilt nur dann als Agentenprojekt, wenn es mindestens Mehrfachinteraktionen oder Tool-Nutzung aufweist. Damit fallen reine Single-Turn-Modelle heraus, während Tool-Integrated-Reasoning-Projekte ausdrücklich aufgenommen werden. Ein zweiter Filter greift bei der Veröffentlichung: Das Repository muss echten RL-Trainingscode oder ausführbaren Umgebungscode enthalten. Paper ohne veröffentlichten Code bleiben außen vor und werden in einem Abschnitt namens Under Review gesammelt.

Taxonomie und Zählweise der Einträge

Die Liste ist in 16 Kategorien gegliedert. Base Framework umfasst allgemeine RL-Trainingsframeworks wie veRL, OpenRLHF und trl. Daneben stehen General/MultiTask, Search & RAG, Web & GUI, Tool-Use, Code & SWE, Reasoning, Multi-Agent RL, Memory, Embodied, Domain-Specific, Reward & Training, Safety, VLM Agent, Self-Evolution und Environment. Die Badges im README nennen je Kategorie eine Anzahl: 29 für Base Framework, 64 für Environment, 50 für Search & RAG, 32 für Web & GUI, 30 für VLM Agent, 26 für Tool-Use, 26 für Code & SWE, 21 für General, 18 für Reasoning, 18 für Self-Evolution, 14 für Multi-Agent, 12 für Domain-Specific, 11 für Reward & Training, 9 für Safety, 8 für Memory und 7 für Embodied. Diese Zahlen sind Kategoriegrößen, keine Qualitätsaussage. Auffällig ist die Verteilung: Umgebungen und Suchagenten dominieren, Safety und Memory sind dünn besetzt. Wer in einem dieser dünnen Felder sucht, findet dort wenige Anknüpfungspunkte.

Reward-Typen als Ordnungsraster

Neben der thematischen Taxonomie führt das README eine zweite Klassifikation ein, die für die praktische Arbeit wichtiger ist: die Reward-Typen. Unterschieden werden External Verifier, etwa ein Compiler oder ein Mathe-Solver, Rule-Based, beispielsweise ein LaTeX-Parser mit Exact-Match-Scoring, Model-Based, also ein trainiertes Verifier- oder Reward-LLM, sowie Custom. Diese Einteilung ist der eigentliche Nutzen der Liste, weil die Wahl des Rewards das Training stärker bestimmt als die Wahl des Frameworks. Ein External Verifier liefert ein hartes, aber enges Signal. Ein Model-Based Reward skaliert besser auf offene Aufgaben, bringt aber einen trainierten Verifier als zusätzliche Fehlerquelle ins System. Die Liste dokumentiert diese Zuordnung projektweise, sodass sich Kandidaten mit ähnlichem Reward-Ansatz vergleichen lassen.

Wie die Einträge entstehen und wo sie irren können

Die Einträge basieren laut README auf Code-Analyse von Open-Source-Repositories mit LLM-Coding-Agenten. Das ist ein effizienter Weg, eine große Zahl von Projekten zu erfassen, und gleichzeitig die größte Schwachstelle. Das README benennt das offen: Die Analyse kann unfaithful cases enthalten, also Fälle, in denen die Beschreibung nicht exakt dem Code entspricht. Eine manuelle Prüfung findet statt, Lücken bleiben laut Projekt dennoch möglich. Wer sich auf ein Detail aus einem Eintrag verlässt, etwa die Angabe, welcher RL-Algorithmus verwendet wird, sollte das im Repository selbst nachsehen. Die Liste ist ein Zeiger, keine Quelle. Der Abschnitt unter jedem Tabellenkopf, der technische Details öffnet, ist entsprechend als Zusammenfassung zu lesen, nicht als Spezifikation.

Zugriff: Website, Repository, Zitation

Es gibt keinen Installationsschritt. Die Liste wird als HTML-Projekt gepflegt und über eine interaktive Dashboard-Website unter https://thinkwee.top/amr/ bereitgestellt. Das README verlinkt diese Website mit einem Badge. Wer die Rohdaten oder die Markdown-Struktur braucht, klont das Repository über den Default-Branch main. Für wissenschaftliche Nutzung verweist das README auf den Cite-this-repository-Knopf in der Seitenleiste, der die Zitationsangaben liefert. Beiträge laufen über Issues oder Pull Requests; das README lädt ausdrücklich dazu ein, eigene Projekte einzureichen. Ein Versionsschema oder Releases gibt es nicht, der einzige Zeitstempel ist die Angabe Last updated: 2026-08-26 im README.

Pflegeaufwand und Aktualisierungsrhythmus

Die Update-Einträge zeigen den Pflegeaufwand. Der August-2026-Bericht nennt 23 neue Repositories über 9 Kategorien, darunter 8 neue Umgebungen und 5 neue Such- und RAG-Projekte. Der Juli-Bericht nennt 13 neue Repositories aus 8 Kategorien, der Juni-Bericht 43 neue über 11 Kategorien. Jeder Eintrag wurde laut README durch Öffnen des Repositories verifiziert. Das ist ein erheblicher manueller Aufwand pro Monat und erklärt, warum die Liste in manchen Feldern schneller wächst als in anderen. Der August-Bericht hält ausdrücklich fest, dass keine qualifizierenden neuen Safety-, Embodied- oder Multi-Agent-RL-Repositories in diesem Fenster erschienen, weil die betreffenden Arbeiten nur SFT, nur Inferenz oder keinen veröffentlichten Code boten. Solche Negativbefunde sind für Leser nützlich, weil sie zeigen, wo das Feld gerade nicht vorankommt.

Grenzen und wann die Liste das falsche Werkzeug ist

AgentsMeetRL ist eine Übersicht, keine Bibliothek. Es gibt keine zu installierende Abhängigkeit, keine API und keine Trainingsfunktion. Wer eine Pipeline sucht, die er heute starten kann, muss sich für eines der gelisteten Projekte entscheiden und dessen eigene Dokumentation lesen. Eine zweite Grenze ist die Lizenz: Für AgentsMeetRL selbst wird keine Lizenz angegeben. Das betrifft nur die Liste, nicht die verlinkten Projekte, deren Lizenzen jeweils separat zu prüfen sind. Eine dritte Grenze ist die Abdeckung. Die Aufnahme verlangt Mehrfachinteraktion oder Tool-Nutzung, weshalb Arbeiten zu Single-Turn-RLHF oder reinem Instruction-Tuning fehlen. Und die Verifikation über LLM-Coding-Agenten bedeutet, dass ein Eintrag korrekt aussehen kann, ohne es zu sein. Wer belastbare Aussagen über Rechenbedarf, Stabilität oder Reproduzierbarkeit eines gelisteten Projekts braucht, bekommt sie hier nicht.

Alternative Ansätze zum Überblick

Der naheliegende Vergleich ist eine Paper-Liste wie Awesome-LLM-Reasoning oder eine reine arXiv-Sammlung. Der Unterschied liegt im Filter: Paper-Listen nehmen Arbeiten auf, sobald sie veröffentlicht sind, unabhängig davon, ob Code existiert. AgentsMeetRL prüft zusätzlich, ob das Repository tatsächlich Trainings- oder Umgebungscode enthält, und verschiebt Arbeiten ohne Code in den Under-Review-Abschnitt. Das kostet Aktualität und gewinnt Verlässlichkeit für Leser, die etwas ausprobieren wollen. Ein zweiter Vergleich sind die Frameworks selbst. veRL, OpenRLHF und trl sind in der Liste als Base Framework geführt und liefern jeweils eigene Dokumentation und Beispiele. Wer bereits weiß, welches Framework er nutzt, braucht AgentsMeetRL nur noch für die Frage, welche Umgebungen und Reward-Ansätze dazu passen.

Redaktionelles Fazit

Für Teams, die einen Überblick über RL-Trainingsframeworks und Umgebungen für Agenten brauchen, ist AgentsMeetRL ein sinnvoller Startpunkt, aber kein Ersatz für die Prüfung des jeweiligen Repositories. Wer fertige Trainingspipelines sucht, sollte zuerst einen Kandidaten aus der Kategorie Base Framework öffnen und dessen eigene Lizenz- und Abhängigkeitslage prüfen, denn die Liste selbst gibt keine Lizenz an und dokumentiert fremde Projekte, nicht deren Wartungszustand.

Offizielle Quellen

1. Issues
2. Project website
3. README
4. thinkwee/AgentsMeetRL on GitHub