LLM_MultiAgents_Survey_Papers: eine kommentierte Literaturliste statt eines Frameworks

Ein Literaturverzeichnis, kein Agenten-Framework

Der Name legt eine Bibliothek nahe, der Inhalt ist eine Bibliografie. Das Repository besteht aus einer README, die Paper nach fünf Überschriften gruppiert: Multi-Agents Framework, Multi-Agents Orchestration and Efficiency, Multi-Agents for Problem Solving, Multi-Agents for World Simulation sowie Multi-Agents Datasets and Benchmarks. Jeder Eintrag folgt demselben Muster: ein Datum in eckigen Klammern, ein Titel, die Autoren und ein Link auf arxiv.org, in Einzelfällen zusätzlich ein Code-Link. Die primäre Sprache ist im Repository-Metadatensatz als unbekannt geführt, was zu einem Projekt passt, das im Wesentlichen aus Markdown besteht. Wer hier eine Installation sucht, sucht am falschen Ort. Der Nutzen liegt darin, dass jemand die Zuordnung von Arbeiten zu Themenfeldern schon vorgenommen hat, statt sie aus einer Volltextsuche selbst rekonstruieren zu müssen.

Die fünf Stränge und was sie trennen

Die Kategorisierung ist der eigentliche Beitrag des Repositories. Framework-Einträge versammeln Systeme wie AutoGen, MetaGPT, CAMEL, AgentVerse und OpenAgents, also Arbeiten, die Rollen, Konversationsprotokolle und Ausführungscontainer bereitstellen. Der Strang Orchestration and Efficiency behandelt dagegen die Frage, wie viele Aufrufe und welche Topologie sinnvoll sind, erkennbar an Titeln wie Are More LLM Calls All You Need? oder More Agents Is All You Need. Problem Solving ist nach Anwendungsdomänen untergliedert, darunter Software development, Embodied Agents, Science Debate und Database. World Simulation bündelt Arbeiten zu Society, Game, Psychology, Economy, Recommender System, Policy Making und Disease propagation Simulation. Die fünfte Gruppe sammelt Datensätze und Benchmarks. Diese Trennung ist nützlich, weil sie die Frage verschiebt: nicht welches System ist besser, sondern welche Rolle spielt ein Paper in der Forschungslandschaft. Uneinheitlich bleibt sie dort, wo ein System sowohl Framework als auch Problemlöser ist. AgentVerse etwa steht unter Framework, obwohl der Titel explizit kollaboratives Verhalten untersucht. Solche Grenzfälle muss man beim Durchsuchen selbst auflösen.

Der Datenfluss endet beim Leser

Zwischen den Bestandteilen des Repositories fließen keine Daten. Die README verlinkt auf drei Abbildungen im Wurzelverzeichnis: trend.png, LLM-MA.png und overview.png. Die erste zeigt laut Einbindung eine Trenddarstellung, die zweite die im Survey zusammengefasste Architektur, die dritte eine Übersichtstabelle, deren Details ausdrücklich im Paper stehen. Diese Bilder sind statische Assets, keine generierten Diagramme, und es gibt im Material keinen Hinweis auf ein Skript, das sie erzeugt. Der einzige Pflegeweg ist manuell: das README nennt eine Aktualisierung alle zwei Wochen und bittet um Kontakt, falls Paper fehlen. Es existiert kein Beitragsleitfaden mit Kriterien, keine Vorlage für Einträge und keine Angabe, wie ein Paper ausgewählt oder abgelehnt wird. Für eine Sammlung, die als Referenz dienen soll, ist das eine relevante Schwäche, weil die Vollständigkeit nicht überprüfbar ist.

Inbetriebnahme heißt hier: klonen und lesen

Es gibt keinen Build, keine Abhängigkeiten und keine Konfigurationsdatei. Wer das Repository nutzen will, klont den main-Branch und öffnet die README; die Bilder liegen relativ dazu im selben Verzeichnis. Ein Installationsbefehl, ein Paketname oder ein Config-Key ist im vorliegenden Material nicht enthalten, und ich erfinde keinen. Praktisch bedeutet das: das Repository lässt sich ohne Toolchain verwenden, aber auch ohne Werkzeug durchsuchen. Wer gezielt nach Arbeiten zu einem Teilthema sucht, ist auf die Textsuche des jeweiligen Git-Hosts oder auf einen lokalen Checkout angewiesen. Ein Index, ein Tag-System oder eine maschinenlesbare Datei wie eine BibTeX-Datei fehlt. Für die Übernahme in eine eigene Literaturverwaltung muss man die Einträge daher von Hand erfassen, was bei der im README sichtbaren Menge an Einträgen ein eigener Arbeitsschritt ist.

Was die Sammlung nicht leisten kann

Die offensichtlichste Einschränkung ist die fehlende Bewertung. Ein Eintrag bedeutet, dass ein Paper existiert und in eine Kategorie passt, nicht dass es belastbar ist. Es gibt keine Notizen zu Ergebnissen, keine Angabe, ob Code verfügbar ist, und bis auf wenige Ausnahmen keine Verweise auf Repositories. Bei einer Liste, die als Einstieg in ein Forschungsfeld dient, ist das ein Problem, weil der Leser die Qualitätsprüfung vollständig selbst tragen muss. Hinzu kommt die zeitliche Streuung. Das README datiert die Anlage des Repositories auf 2024/01, die Liste enthält aber Einträge mit Datumsangaben bis 2026/04, etwa CORAL. Ob solche Einträge noch Eingang in eine überarbeitete Fassung des Surveys gefunden haben, lässt sich aus dem Material nicht ableiten. Wer die Liste als Beleg für den Stand der Forschung zitiert, sollte deshalb zwischen dem Survey selbst und der fortlaufend ergänzten Liste unterscheiden. Schließlich fehlt jede Angabe zur Lizenz. Ohne Lizenz ist nicht erkennbar, unter welchen Bedingungen Inhalte weiterverwendet werden dürfen; das ist keine Rechtsberatung, sondern der schlichte Hinweis, dass die Angabe im Repository fehlt.

Abgrenzung zu Awesome-Listen und zu Code-Sammlungen

Die naheliegende Alternative ist eine generische Awesome-Liste zum selben Thema. Der Unterschied liegt nicht im Format, sondern in der Bindung an eine Publikation: hier ist die Struktur aus einem Survey abgeleitet, der bei IJCAI 2024 angenommen wurde, und die Kategorien entsprechen dessen Gliederung. Eine freie Liste sammelt nach Popularität oder Eingangsdatum, dieses Repository sammelt nach einer veröffentlichten Taxonomie. Der Preis dafür ist die Abhängigkeit: ändert sich die Forschungsrichtung, bleibt die Struktur zunächst stehen. Die zweite Alternative sind die Frameworks selbst, also AutoGen, MetaGPT oder CAMEL. Sie lösen ein anderes Problem. Wer ein System bauen will, braucht deren APIs, Dokumentation und Release-Zyklen; wer verstehen will, welche Ansätze es gibt und wie sie sich unterscheiden, braucht die Übersicht. Die beiden Ebenen ersetzen einander nicht. Ein Vergleich der Framework-Einträge untereinander wäre hier auch nicht möglich, weil das Repository zu jedem nur Titel und Link nennt, ohne Merkmale wie unterstützte Rollenmodelle oder Kommunikationsmuster zu erfassen.

Pflegeaufwand und Lizenzlage

Der Aufwand liegt beim Betreiber, nicht beim Nutzer. Das README kündigt an, die Liste alle zwei Wochen zu aktualisieren, und nennt als Ziel, alle genannten Paper in die nächste Version des Surveys aufzunehmen. Das ist ein Versprechen mit offenem Ende: es gibt keine Releases, an denen sich ein Stand festmachen ließe, und der letzte Push-Zeitpunkt allein sagt nichts über die Vollständigkeit der Ergänzungen. Für Nutzer bedeutet das, dass ein Checkout zu einem beliebigen Zeitpunkt einen anderen Umfang hat als derselbe Checkout Wochen später, ohne dass eine Versionsnummer den Unterschied markiert. Wer die Liste in einer Publikation zitiert, sollte daher ein Abrufdatum festhalten. Zur Lizenz lässt sich aus dem vorliegenden Material nichts sagen, weil keine Lizenzdatei und keine Lizenzkennung genannt sind. Das betrifft auch die Bilder: ohne Lizenzangabe ist unklar, ob trend.png, LLM-MA.png und overview.png außerhalb des Repositories weiterverwendet werden dürfen. Diese Frage muss man klären, bevor man die Abbildungen in eigene Unterlagen übernimmt.

Für wen sich der Checkout lohnt

Die Sammlung passt zu Lesern, die einen strukturierten Einstieg in ein breites Feld suchen und bereit sind, von dort aus den jeweiligen Papern zu folgen. Sie passt zu Lehrenden, die eine Gliederung für ein Seminar brauchen, und zu Autoren, die prüfen wollen, ob eine Arbeit schon in einer der fünf Gruppen verortet wurde. Sie passt nicht zu Teams, die eine Abhängigkeit in eine Build-Pipeline aufnehmen wollen, denn es gibt nichts zu installieren. Sie passt auch nicht als Ersatz für die Lektüre des Surveys: die README selbst verweist für Details auf das Paper unter arxiv.org/abs/2402.01680, und die Übersichtstabelle wird ausdrücklich nur dort ausgeführt. Wer die Liste übernimmt, sollte zuerst klären, ob für das Repository inzwischen eine Lizenz ausgewiesen ist, und zweitens, ob die Einträge nach 2024/02 noch Teil einer überarbeiteten Survey-Fassung sind. Beides ist aus dem Repository allein nicht zu beantworten.

Redaktionelles Fazit

Wer eine Einstiegsbibliografie zu LLM-Multi-Agenten braucht und mit einer reinen Linkliste arbeitet, findet hier eine nach fünf Strängen sortierte Sammlung, die auf dem Survey unter arxiv.org/abs/2402.01680 aufsetzt. Wer lauffähigen Code, Versionierung oder eine belastbare Lizenzangabe erwartet, ist hier falsch: das Repository hat keine Releases, keine deklarierte Lizenz und laut README nur den Anspruch, die Liste alle zwei Wochen zu ergänzen. Vor dem Zitieren sollte man prüfen, ob der jeweilige Eintrag im Survey selbst noch als aktuell geführt wird, denn die Liste enthält auch Einträge mit Datumsangaben aus 2025 und 2026, die nach dem Publikationsstand des Surveys entstanden sind.

Offizielle Quellen

1. Issues
2. Project website
3. README
4. taichengguo/LLM_MultiAgents_Survey_Papers on GitHub