Benchmark für Multiagenten-Frameworks: Herausforderungen und Stärken
Multiagentensysteme nutzen spezialisierte Agenten, die zusammenarbeiten, um komplexe Aufgaben zu lösen. Eine zentrale Herausforderung: Verschlechtert sich die Leistung mit zunehmender Anzahl an Agenten und Werkzeugen, oder können Orchestrierungsmechanismen die wachsende Komplexität effizient bewältigen?
Wir haben fünf agentenbasierte Frameworks in 750 Durchläufen mit drei Aufgaben verglichen. Dabei haben wir Latenz, Token-Verbrauch und Orchestrierungsaufwand gemessen, um zu ermitteln, welche Architekturmuster auch bei großer Datenmenge effizient bleiben und welche an Effizienz einbüßen.
Benchmark für Multiagenten-Frameworks
Wir haben untersucht, wie sich Token-Nutzung und Latenz mit zunehmender Anzahl an Agenten und Tools skalieren. In drei Aufgaben mit demselben Problem haben wir die Anzahl der Agenten und die Verfügbarkeit von Tools schrittweise erhöht. Für LangChain und LangGraph verwendeten wir Einzelagenten-Setups, um zu beobachten, wie deren sequentielle Architekturen die gleiche Komplexität bewältigen, der auch Mehragentensysteme begegnen.
Das Framework mit einer Genauigkeit unter 95 % (Swarm) wurde nicht in die Grafik aufgenommen. Unsere Benchmark-Methodik können Sie hier nachlesen.
Insbesondere bei Swarm stellten wir fest, dass sich die Genauigkeit mit dieser Komplexität veränderte, wobei architektonische Unterschiede und nicht die Leistungsfähigkeit des Modells eine Rolle spielten.
Die Genauigkeit agentenbasierter Frameworks lässt sich typischerweise durch die Auswahl des LLM (Level Mode) oder die Konfigurationsoptimierung verbessern. Die Untersuchung der architektonischen Ursachen für Genauigkeitsschwankungen in unserem Benchmark lieferte jedoch wertvolle Erkenntnisse. Sie half uns, die grundlegenden Designunterschiede zwischen den Frameworks zu verstehen.
Benchmark-Ergebnisse für Multiagenten-Frameworks
CrewAI zwingt alle Agenten zur sequenziellen Ausführung, was zu einem exponentiellen Token-Anstieg führt, da die Ausgabe jedes Agenten in den Kontext des nächsten Agenten einfließt. Diese Starrheit gewährleistet zwar die Vollständigkeit, verursacht aber einen enormen Overhead.
Swarm priorisiert Geschwindigkeit durch zustandsloses Routing, leidet aber unter einem fortschreitenden Genauigkeitsverlust (84 % → 0 %) mit zunehmender Aufgabenkomplexität. Ohne globale Zustandsverfolgung brechen Agenten vorzeitig ab und unterbrechen so mehrstufige Ketten.
LangChain verwendet einen einzelnen „Superagenten“ mit einheitlichem Kontext, wodurch der Koordinationsaufwand vollständig vermieden wird. Die Leistung bleibt effizient, solange die Größe der Werkzeugbibliothek (100 Werkzeuge) und die Komplexität der Schlussfolgerungen die Latenz nicht signifikant erhöhen.
LangGraph erreicht die gleiche Zuverlässigkeit wie LangChain, verursacht aber zusätzlichen Aufwand beim Durchlaufen des Graphen. Der Aufwand für die Zustandsverwaltung wird bei hoher Komplexität deutlich, die hohe Genauigkeit bleibt jedoch erhalten.
AutoGen generiert durch chatbasierte Koordination hohe Übergabezahlen, nutzt aber GroupChatManager, um unnötige Agenten dynamisch zu entfernen. Dies verhindert das exponentielle Wachstum von CrewAI bei gleichzeitig hoher Genauigkeit, obwohl der Tokenverbrauch aufgrund der erneuten Verarbeitung des Gesprächsverlaufs höher bleibt als bei Einzelagentensystemen.
CrewAI
Die rollenbasierte, sequentielle Pipeline von CrewAI führte jeden zugewiesenen Agenten aus, ohne dabei unnötige Agenten herauszufiltern. Diese Architektur hat weitreichende Konsequenzen für agentenbasierte Systeme, in denen jeder Agent eine kritische Funktion erfüllt. Sie stellt sicher, dass das Framework keine erwarteten Schritte überspringt und alle Agenten kontinuierlich nutzt, anstatt autonome Routing-Entscheidungen zu treffen. Diese Starrheit führt jedoch mit zunehmender Aufgabenkomplexität zu einem deutlich höheren Ressourcenverbrauch und längeren Latenzzeiten.
Exponentielles Ressourcenwachstum über alle Aufgaben hinweg
Von Aufgabe 1 bis Aufgabe 3 beobachteten wir einen kontinuierlich steigenden Tokenverbrauch und eine zunehmende Latenz. Die Latenz verdoppelte sich mit jeder zusätzlichen Aufgabe annähernd, während der Tokenverbrauch noch deutlich stärker anstieg. Die Anzahl der Agentenübergaben erhöhte sich entsprechend.
Warum CrewAI mehr Token und Zeit verbraucht
Die sequentielle Pipeline von CrewAI passte nahtlos zu beiden Arbeitsabläufen. In Aufgabe 1 sammelte der Datenanalyst Informationen, bevor der Schiedsrichter Entscheidungen traf. In Aufgabe 2 wurde dieses Muster mit erweiterten Agentenrollen fortgesetzt. CrewAI wählte alle Tools korrekt aus und demonstrierte, dass die sequentielle Ausführung Koordinationsprobleme beseitigt, da jeder Agent seine zugewiesenen Tools ohne Mehrdeutigkeiten in der Routenführung ausführt.
Diese natürliche Ausrichtung brachte jedoch erhebliche und stetig wachsende Kosten mit sich:
Der Mechanismus der Zustandsverdichtung:
- Jeder Agent erstellt nach Abschluss seiner Aufgabe einen detaillierten Bericht.
- Dieser Bericht wird an den nächsten Agenten in der Sequenz weitergeleitet.
- Wenn der letzte Schiedsrichter die Übergabe erhält, liest er ein Dokument, das die Historie und die Ausgaben aller vorherigen Agenten sowie seine eigenen Systemanweisungen und Werkzeugmetadaten enthält.
- Das LLM verbringt viel Zeit damit, zwischen den Aufgaben große Markdown-Zustandsobjekte zu lesen und neu zu generieren.
Dieses ausführliche Zustandsmanagement bettete selbst kleine Datenpunkte in umfangreiche Orchestrierungsmetadaten ein. CrewAI priorisiert die vollständige Kontextanalyse gegenüber der Effizienz.
Aufgabe 2-3 Steifigkeit:
- Das Framework führte alle 5 Agenten in der vordefinierten Reihenfolge aus, selbst wenn nur eine Teilmenge unbedingt erforderlich war.
- Diese Starrheit erhöhte sowohl die Tokenkosten als auch die Latenz, während gleichzeitig eine hohe Genauigkeit beibehalten wurde.
- Die Unfähigkeit des Frameworks, unnötige Agenten zu überspringen, erwies sich zunehmend als grundlegende architektonische Einschränkung.
- Jeder zusätzliche Agent verkomplizierte den Kontext, den nachfolgende Agenten verarbeiten mussten.
Schwarm
Der ressourcenschonende Routing-Mechanismus von Swarm demonstrierte echte Multiagenten-Delegation mit minimalem Orchestrierungsaufwand. Ein initialer Agent sammelte den notwendigen Kontext, erkannte aktiv, wann seine Aufgabe abgeschlossen war, und übergab die Sitzung explizit an einen anderen, entscheidungsbefugten Agenten. Diese zustandslose Architektur priorisierte Geschwindigkeit und Einfachheit und erreichte in einfachen Szenarien eine mit Einzelagenten-Baselines vergleichbare Leistung. Mit zunehmender Aufgabenkomplexität offenbarte dieser ressourcenschonende Ansatz jedoch grundlegende Skalierbarkeitsgrenzen, da das Fehlen globaler Zustandsverfolgung und zentraler Orchestrierung zu einem fortschreitenden Genauigkeitsverlust führte.
Progressiver Genauigkeitsverlust bei verschiedenen Aufgaben
Von Aufgabe 1 bis Aufgabe 3 beobachteten wir einen drastischen Genauigkeitsverlust trotz gleichbleibend hoher Ausführungsgeschwindigkeit. Die Genauigkeit sank von 84 % in Aufgabe 1 auf 22 % in Aufgabe 2 und erreichte schließlich 0 % in Aufgabe 3. Diese fortschreitende Verschlechterung zeigte, dass die zustandslose Architektur von Swarm, die für Geschwindigkeit bei kurzen Interaktionen optimiert ist, für mehrstufige Schlussfolgerungsketten grundsätzlich nicht skalierbar ist.
Warum die Genauigkeit mit zunehmender Komplexität abnimmt
Swarms ressourcenschonendes Routing sorgte für extrem niedrige Completion-Token-Verbrauch und geringe Latenzzeiten bei allen Aufgaben. Das Framework funktionierte wie ein Staffellauf unabhängiger Agenten ohne globalen Zustand, wobei jeder Agent autonome Übergabeentscheidungen ohne zentrale Steuerung traf. Dieser Ansatz minimiert den Token-Verbrauch und ermöglicht eine schnelle Ausführung, geht jedoch mit erheblichen Einbußen bei Zuverlässigkeit und Präzision einher, wenn die Anforderungen an die operative Persistenz steigen.
Der architektonische blinde Fleck:
Eine nachträgliche Analyse der Protokolle deckte eine architektonische Schwachstelle auf, die sich nicht allein durch Prompt-Engineering beheben ließ. Zunächst wurde ein Fehler in der Prompt-Implementierung (fehlende Übertragungsanweisungen) identifiziert und behoben. Doch selbst mit expliziten Übertragungsbefehlen konnte Swarm die Kette nicht abschließen.
Da das Framework zustandslos ist und keine globale Absichtsverfolgung bietet, würde der erste Empfängeragent (z. B. die Finanzabteilung) lediglich eine Bestätigung im Gesprächsverlauf senden (z. B. „Daten empfangen, Finanzprüfung wird gestartet“) und den Thread beenden. Swarm interpretiert jedes Gesprächsende als Aufgabenabschluss, was zwar die schnellsten, aber letztlich nutzlosesten Ergebnisse liefert. Ohne einen zentralen Orchestrator, der den Aufgabenstatus verwaltet und die Ausführung aller Schritte sicherstellt, kann das Framework nicht zwischen „Agent hat eine Bestätigung gesendet“ und „Aufgabe vollständig abgeschlossen“ unterscheiden. Diese grundlegende Einschränkung bedeutet, dass selbst eine echte Multiagenten-Delegation mit expliziten Übergaben den Aufgabenabschluss nicht garantieren kann, wenn die Kette über einfache Interaktionen hinausgeht.
Aufgabe 1-2: Zunehmende Präzisionsprobleme
In Aufgabe 1, in der Swarm mit kurzen Agentenketten eine starke Leistung zeigte, scheiterte das Framework dennoch in 16 % der Durchläufe aufgrund unvollständiger Übergabe. Die Analyse der Gesprächsprotokolle ergab, dass der Arbitrator zwar erfolgreich Entscheidungen traf, der Ausgabemechanismus von Swarm jedoch stattdessen die Zwischennachricht des Datenanalysten ausgab. Die Nutzer erhielten die Meldung „Ich werde diese Informationen nun an den Arbitrator weiterleiten“ anstelle der eigentlichen Entscheidung. Dies verdeutlicht, dass dynamische Routing-Systeme Gefahr laufen, Endergebnisse während Agentenübergängen zu verlieren.
In Aufgabe 2, bei der 5 Agentenoptionen und 20 Werkzeuge zur Verfügung standen, verschlechterte sich die Präzision deutlich, da die schlanke, kontextarme Prompt-Strategie des Frameworks unter der zunehmenden Komplexität an ihre Grenzen stieß:
- Die Quote der richtigen Werkzeugwahl sank auf 40 %, was einem Rückgang von 20 % gegenüber Aufgabe 1 entspricht.
- Agenten riefen gelegentlich irrelevante Tools auf oder gaben Routing-Nachrichten aus, wo eigentlich Tool-Aufrufe erwartet wurden.
- Agenten versuchten mitunter, Tools der falschen Domäne zu verwenden oder wiederholten fehlgeschlagene Anrufe.
- Ohne eine zentrale Steuerung verloren die Agenten den Überblick über den Ausführungsstatus oder wurden an Rollen übergeben, die zwar eindeutig klangen, aber die notwendigen Tool-Aufrufe nicht ausgeführt hatten.
Aufgabe 3: Das Übergabeparadoxon
Aufgabe 3 legte die grundlegende architektonische Beschränkung von Swarm offen: Trotz höchster Ausführungsgeschwindigkeit erreichte das Programm eine Genauigkeit von 0 %. Dieses vollständige Versagen offenbarte das sogenannte „Handoff-Paradoxon“: In einer Kette mit zehn Agenten benötigt Swarm an jedem Glied vollständig toolbasierte Übergaben. Ohne einen zentralen Orchestrator oder Zustandsgraphen (wie LangGraph) bricht die Kette jedoch bereits am ersten Glied ab. Während Swarm bei 1:1-Übergaben hervorragend abschneidet, versagt es bei mehrstufigen Arbeitsabläufen, die eine kontinuierliche operative Verarbeitung über lange Ketten hinweg erfordern.
Erschöpfung der Übergabekette:
In Aufgabe 1 mit nur einer Übergabe war die Kette kurz genug, um das Ziel im Kontext zu halten. Als sich die Kette in Aufgabe 3 jedoch auf neun Übergaben ausdehnte, sank die kumulative Erfolgswahrscheinlichkeit auf null. Jeder zusätzliche Spezialist fungierte als „Leckpunkt“, an dem eine Antwort im Gespräch den Prozess beenden konnte, bevor der endgültige Schiedsrichter erreicht war. Diese geometrische Ausfallrate zeigt, dass zustandsloses Routing zwar auf Geschwindigkeit optimiert ist, aber bei mehrstufigen Entscheidungsprozessen nicht skalierbar ist.
LangChain
LangChain führte Aufgaben als einfache Zustandsmaschine aus: Eingabeaufforderung empfangen, Werkzeuge auswerten, ausführen, abschließen. Wir konfigurierten LangChain als Einzelagenten-Executor ohne Übergaben und mit einem einzigen Agenten für alle Aufgaben. Dieser Ansatz mit einheitlichem Kontext gewährleistete eine einzige logische Einheit während der gesamten Ausführung, ohne Dialogsprünge und mit exakter Ausführung der jeweiligen Aufgabe ohne Orchestrierungsaufwand. Das lineare Ausführungsmodell des Frameworks zeigte, dass Aufgaben, die keine Agentenkollaboration erfordern, erheblich von der Vermeidung der in Multiagentensystemen inhärenten Koordinationskosten profitieren.
Effiziente Skalierung bis zum Erreichen des Werkzeugentropie-Schwellenwerts
LangChain lieferte in allen drei Aufgaben korrekte Ergebnisse. Aufgabe 3 zeigte jedoch die Empfindlichkeit des Frameworks gegenüber der Größe der Tool-Bibliothek und der Komplexität der Schlussfolgerungen, wobei die Latenz mit zunehmender Größe beider Dimensionen merklich anstieg.
Warum LangChain effizient blieb
Aufgabe 1-2: Vorteil der linearen Ausführung
In Aufgabe 1 erzielte LangChain minimale Latenz und optimierte die Token-Nutzung durch präzise Werkzeugauswahl. Das Framework vermied Ablenkungen durch Koordinationsmechanismen und verarbeitete nur die für die Aufgabenerfüllung notwendigen Daten. Die Einzelagentenarchitektur reduzierte den Kommunikationsaufwand zwischen den Agenten, die Berichtserstellung zwischen den Schritten und unnötige Dialoge.
In Aufgabe 2 implementierten wir LangChain mithilfe einer „Superagenten“-Architektur, in der ein einziger Controller direkten Zugriff auf alle 20 Tools hatte. Durch die Konsolidierung der Rollen in einer einzigen logischen Einheit umging das Framework die Notwendigkeit des Datenaustauschs zwischen den Agenten, der Berichtserstellung und der Dialogführung. Dieses lineare Ausführungsmodell stellte sicher, dass das LLM nur relevante Tool-Ergebnisse verarbeitete und vermied so das exponentielle Anwachsen der Eingabeaufforderungshistorie, das in Multiagenten-Frameworks auftritt.
Die einheitliche Kontextarchitektur sorgte dafür, dass die 20 Werkzeuge in der Bibliothek keine Auswahlschwierigkeiten verursachten. Der einzelne Agent verarbeitete Werkzeugaufrufe sequenziell, ohne sich mit anderen Agenten abstimmen oder verhandeln zu müssen, und gewährleistete so trotz der erweiterten Werkzeugbibliothek die korrekte Werkzeugauswahl. Die Tatsache, dass keine Übergaben stattfanden, bestätigte, dass mit zunehmender Komplexität kein zusätzlicher Orchestrierungsaufwand entstand.
Werkzeugentropie und Komplexität des Denkens
Aufgabe 3 brachte zwei wesentliche Herausforderungen mit sich, die sich auf die Leistung von LangChain auswirkten:
Werkzeugentropie:
Während Aufgabe 1 5 und Aufgabe 2 20 Werkzeuge umfasste, stellte Aufgabe 3 100 verfügbare Werkzeuge zur Verfügung. Da LangChain als Einzelagentensystem arbeitet, muss jede Nachricht die Definitionen aller 100 Werkzeuge in der Aufforderung enthalten. Dies führt zu zwei Engpässen:
- Der LLM muss 100 Optionen auswerten, um das richtige Werkzeug auszuwählen, was die Bearbeitungszeit erhöht.
- Die enorme Größe der Eingabeaufforderung (die alle Werkzeugdefinitionen enthält) verzögert die Zeit bis zum ersten Token des Modells und erhöht somit die Gesamtlatenz.
Komplexität des Denkprozesses (10 Expertenrollen):
In Aufgabe 1 und Aufgabe 2 fungierte der Agent lediglich als Schiedsrichter und traf eine Entscheidung. In Aufgabe 3 wurde der Agent angewiesen, nacheinander 10 Expertenmeinungen zu berücksichtigen.
Diese Anweisung führte dazu, dass das Modell deutlich längere Ausgaben generierte, wobei die Anzahl der Vervollständigungstoken im Vergleich zu Aufgabe 2 erheblich anstieg. Mehr generierter Text bedeutet direkt eine längere Ausführungszeit, da das Modell jedes Token nacheinander erzeugen muss.
Trotz dieser Herausforderungen lieferte LangChain stets korrekte Ergebnisse und wählte nie die falschen Werkzeuge aus. Die einfache Schleifenstruktur des Frameworks (AgentExecutor) verarbeitete Werkzeugaufrufe und -antworten ohne zusätzlichen architektonischen Aufwand, sodass Latenzanstiege proportional zur jeweiligen Aufgabenkomplexität blieben und nicht durch Orchestrierungsmechanismen verstärkt wurden.
Der Architekturansatz von LangChain bewies, dass die einheitliche Kontextausführung auch bei zunehmender Komplexität zuverlässig funktioniert, die Performance jedoch von der Größe der Tool-Bibliothek und der Tiefe der Argumentation abhängt. Die Fähigkeit des Frameworks, über alle Aufgaben hinweg korrekte Ergebnisse zu liefern und gleichzeitig die Token-Explosion und den Koordinationsaufwand von Multiagentensystemen zu vermeiden, demonstrierte den Wert linearer Ausführungsmodelle für Aufgaben, die keine Agentenkollaboration erfordern.
LangGraph
Wie unser Benchmark für agentenbasierte Frameworks zeigte, nutzte LangGraph eine Zustandsautomatenarchitektur mit expliziten Zustandsübergängen und graphenbasiertem Kontrollfluss. Wir konfigurierten LangGraph als Einzelagenten-Executor ohne Übergaben und mit einem einzigen Agenten für alle Aufgaben. Dieser Ansatz eliminierte die Kommunikation zwischen Agenten vollständig und ermöglichte gleichzeitig ein strukturiertes Zustandsmanagement, das den Ausführungsfortschritt über definierte Knoten und Kanten verfolgte. Das Framework demonstrierte, dass formales Zustandsmanagement mit einheitlicher Kontextausführung koexistieren kann.
Konstante Zuverlässigkeit trotz des Aufwands für die Graphverwaltung
LangGraph lieferte in allen drei Aufgaben fehlerfrei korrekte Ergebnisse. In Aufgabe 1 und Aufgabe 2 war die Leistung nahezu identisch mit der des linearen Ausführungsmodells von LangChain. Aufgabe 3 zeigte jedoch deutlichere Latenzerhöhungen im Vergleich zu LangChain, was die Rechenkosten der graphenbasierten Zustandsverwaltung bei hoher Werkzeugentropie und komplexer Argumentation verdeutlicht.
Warum LangGraph zu LangChain passte
Der Zustandsgraph von LangGraph ermöglichte einen formalen Kontrollfluss ohne die Notwendigkeit mehrerer Agenten. In beiden Aufgaben vermied das Framework Übergaben und wählte alle Werkzeuge korrekt aus. Der einzelne Controller griff direkt auf alle benötigten Werkzeuge zu und verarbeitete jeden Schritt über Zustandsübergänge anstatt über Agentenübergaben.
Die Implementierung des „Superagenten“ verhinderte, dass die kognitive Last auf mehrere Personas aufgeteilt wurde. Die Werkzeugauswahl blieb selbst bei 20 verfügbaren Werkzeugen in Aufgabe 2 präzise; der Agent rief niemals falsche oder irrelevante Werkzeuge auf. Der einheitliche Kontext verhinderte die Auswahlverwirrung, die Frameworks mit Agenten-zu-Agenten-Koordination häufig plagte.
Warum der Tokenverbrauch mit LangChain übereinstimmte
Beide Frameworks verwendeten identische LLM-Konfigurationen, Werkzeugdefinitionen und Systemaufforderungen. Im Gegensatz zu Multiagenten-Frameworks (AutoGen, CrewAI), die durch Agenten-zu-Agenten-Konversationen und Zwischennachrichten einen Koordinationsaufwand erzeugen, konsolidieren beide Einzelagenten-Frameworks die gesamte Expertise in einem einzigen Modellaufruf. Jedes ausgegebene Token repräsentiert entweder die Eingabeanweisungen oder die direkte Ausgabe, ohne zusätzlichen Aufwand durch die Kommunikation zwischen Agent A und Agent B. Darüber hinaus rufen beide Frameworks dieselben Werkzeuge in derselben Reihenfolge auf, um die Aufgabe zu lösen, und erhalten identische Daten vom zugrunde liegenden System, was zu sehr ähnlichen Token-Anzahlen führt. Die Token-Unterschiede zwischen den Frameworks waren vernachlässigbar, da das LLM in beiden Fällen dieselbe Schlussfolgerungsarbeit leistete.
Aufgabe 3: Verstärkter Aufwand für die Graphdurchquerung
Aufgabe 3 stellte LangChain vor dieselben Herausforderungen (100 Tools und eine Komplexität des Reasoning mit 10 Rollen), aber die graphenbasierte Architektur von LangGraph verstärkte die Auswirkungen auf die Leistung:
Werkzeugentropiebelastung:
Wie LangChain muss auch LangGraph aufgrund seiner Einzelagentenarchitektur alle 100 Werkzeugdefinitionen in jede Eingabeaufforderung einbeziehen. Das LLM muss für jede Auswahl die gesamte Werkzeugbibliothek auswerten, und die enorme Größe der Eingabeaufforderung verzögert die Generierung der Antwort.
Komplexität des Denkens:
Die Anweisung, zehn Expertenperspektiven nacheinander zu berücksichtigen, führte dazu, dass LangGraph deutlich längere Ausgaben generierte, genau wie bei LangChain. Der zusätzliche Aufwand von LangGraph wurde hier jedoch sichtbar.
Mehraufwand für die Graphverwaltung:
Während LangChain eine einfache Schleifenstruktur (AgentExecutor) verwendet, die Tools aufruft und Antworten verarbeitet, durchläuft LangGraph in jedem Schritt eine gesamte Graphstruktur. Für jeden Tool-Aufruf:
- Das Framework muss den gesamten Graphen von Anfang bis Ende durchlaufen.
- Der Nachrichtenverlauf (Status) wird bei jedem Knotenübergang aktualisiert.
- Das System validiert Übergänge zwischen Knoten und gewährleistet die Konsistenz des Zustands.
In Aufgabe 1 und Aufgabe 2 war dieser Mehraufwand vernachlässigbar. In Aufgabe 3 mit 100 Werkzeugen und komplexen Schlussfolgerungsanforderungen wurde die Belastung durch die Zustandsgraphenverwaltung jedoch erheblich. Die zusätzliche Latenz im Vergleich zu LangChain spiegelte direkt die Kosten für die Pflege und das Durchlaufen der Zustandsgraphenstruktur unter hoher Komplexität wider.
Trotz dieses Mehraufwands wählte LangGraph stets die richtigen Werkzeuge aus und rief in jedem Schritt nur die notwendigen Funktionen auf. Die formale Zustandsverfolgung des Frameworks ermöglichte einen strukturierten Kontrollfluss, allerdings auf Kosten einer längeren Verarbeitungszeit.
Der Architekturansatz von LangGraph hat gezeigt, dass explizites Zustandsmanagement die Zuverlässigkeit auch bei zunehmender Komplexität gewährleisten kann, obwohl der Aufwand für die Graphdurchquerung bei hoher Werkzeugentropie und komplexer Logik deutlicher wird. Für Anwendungen, die Nachvollziehbarkeit, Rollback-Funktionen oder komplexe Verzweigungslogik erfordern, kann dieser Kompromiss sinnvoll sein. Für einfache sequentielle Ausführung bietet die zusätzliche Struktur von LangGraph gegenüber einfacheren linearen Modellen wie LangChain nur einen geringen Mehrwert.
Autogen
AutoGen verbrauchte deutlich mehr Ressourcen als die Single-Agent-Baselines, erreichte aber nicht das extreme Niveau der sequenziellen Pipeline von CrewAI. Das Framework umfasste mehrere Konversationen zwischen einem UserProxy und spezialisierten Agenten. Jeder Gesprächszug erforderte einen vollständigen LLM-Durchlauf, der die gesamte bisherige Konversationshistorie neu verarbeitete.
AutoGen wählte jedoch stets die richtigen Werkzeuge aus und lieferte bei allen Aufgaben präzise Ergebnisse, ohne irrelevante Werkzeuge aufzurufen. Allerdings führte dies zu einem zusätzlichen Kommunikationsaufwand, da das Framework mehr Zeit mit der Koordination als mit der eigentlichen Ausführung verbrachte. Für diese einfache Aufgabe erwies sich die chatbasierte Koordination von AutoGen daher als unnötige Komplexität anstatt als kollaborativer Vorteil.
AutoGen nutzte eine Chat-basierte Architektur, bei der spezialisierte Agenten über einen UserProxy zusammenarbeiten, der die Workflow-Koordination verwaltet.
Wir haben AutoGen mithilfe des GroupChatManagers für alle drei Aufgaben konfiguriert, um eine dynamische Agentenauswahl anstelle einer erzwungenen sequenziellen Ausführung zu ermöglichen. Diese Architektur demonstrierte, dass intelligente Orchestrierung die Zusammenarbeit mehrerer Agenten ohne die exponentiell steigenden Ressourcenkosten starrer Pipelines ermöglichen kann.
Hohe Übergabequoten bei wettbewerbsfähiger Leistung
AutoGen verzeichnete die höchste Anzahl an Übergaben aller Frameworks. Bereits in Aufgabe 1 erreichte das Framework Übergabewerte, die CrewAI erst in Aufgabe 3 (9 Übergaben) erzielte. Dies spiegelte den dialogorientierten Charakter von AutoGen wider: Jede Interaktion zwischen dem UserProxy und den spezialisierten Agenten wird als Übergabe registriert, selbst bei der Diskussion über das aufzurufende Tool.
Trotz dieser hohen Anzahl an Übergaben blieb die Latenz von AutoGen in Aufgabe 1 und Aufgabe 2 jedoch mit sequenziellen Frameworks konkurrenzfähig. In Aufgabe 3 erreichte der Framework-Overhead von CrewAI 1,35 Millionen Token, während AutoGen nur 56.700 Token verbrauchte (im Vergleich zu 13.500 bei LangChain und 13.600 bei LangGraph).
Warum AutoGen trotz seiner Latenz mehr Token verbrauchte
AutoGen verbrauchte deutlich mehr Tokens als die Single-Agent-Baselines, erreichte aber nicht die extremen Werte der sequenziellen Pipeline von CrewAI. Das Framework umfasste mehrere Konversationen zwischen einem UserProxy und spezialisierten Agenten. Jeder Gesprächszug erforderte einen vollständigen LLM-Durchlauf, der den gesamten bisherigen Konversationsverlauf erneut verarbeitete.
Diese rekursive Tokenakkumulation erklärt, warum der Tokenverbrauch von AutoGen selbst bei vergleichbarer Latenz höher blieb als der von LangChain und LangGraph. Der Chatverlauf wächst mit jeder Runde und damit auch die Nachrichtengröße, doch der GroupChatManager des Frameworks verhindert die exponentielle Zunahme, die bei sequenziellen Pipelines auftritt, indem er unnötige Agenten entfernt.
AutoGen wählte jedoch stets die richtigen Werkzeuge aus und lieferte bei allen Aufgaben präzise Ergebnisse, ohne dabei irrelevante Werkzeuge aufzurufen. Der dadurch entstehende Kommunikationsaufwand führte dazu, dass das Framework mehr Zeit mit der Koordination als mit der Ausführung verbrachte. Diese Koordination stellte jedoch sicher, dass kein Agent jemals den Fokus verlor oder die falschen Werkzeuge aufrief.
AutoGen's GroupChatManager
Die architektonische Stärke von AutoGen: die dynamische Agentenauswahl über den GroupChatManager. Im Gegensatz zur sequenziellen Orchestrierung von Task 2 ermöglichte der GroupChat-Modus dem Framework, nur die benötigten Agenten aus dem verfügbaren Pool zu aktivieren.
Der Manager entfernte überflüssige Spezialisten und aktivierte nur 5–6 der 10 Agenten. Sobald der Schiedsrichter eine ausreichende Entscheidungsgrundlage gefunden hatte, beendete der Manager den Vorgang. Dadurch wurde das exponentielle Token-Wachstum verhindert, das entstanden wäre, wenn der Kontext nacheinander durch jeden verbleibenden Agenten geleitet worden wäre.
Dieses dynamische Pruning führte im Vergleich zur starren sequenziellen Pipeline von CrewAI zu deutlich geringerer Latenz und einem geringeren Token-Verbrauch. Während CrewAI alle 10 Agenten unabhängig von der Notwendigkeit zur Ausführung zwang, wählte AutoGen GroupChat adaptiv nur die für eine Entscheidungsfindung benötigten Agenten aus.
Trotz des Koordinierungsaufwands spiegelte die hohe Anzahl an Übergaben eine sorgfältige Abwägung wider, bei der die Agenten ihre Ergebnisse vor dem Abbruch abglichen. Die Fähigkeit von AutoGen, zwischen sequenziellem Modus und Gruppenchat-Modus zu wechseln, bietet eine Flexibilität, die starren Architekturen fehlt. Dies zeigt, dass chatbasierte Orchestrierung mit intelligenter Agentenauswahl bei komplexen Multiagenten-Workflows effizienter skalieren kann als feste Pipelines.
So funktioniert AutoGen GroupChatManager:
- In jedem Schritt entscheidet der Manager anhand des Gesprächskontexts, welcher Agent als Nächstes sprechen soll.
- Das Framework muss nicht alle Agenten nacheinander ausführen.
- Werden frühzeitig ausreichend Informationen gesammelt, kann der Manager auf unnötige Spezialisten verzichten.
- Der Manager kann die Schleife beenden, sobald der Agent über genügend Informationen verfügt, um eine Entscheidung zu treffen.
Die Herausforderung „Bitte fortfahren“: AutoGen hält standardmäßig Konversationen aufrecht. Für Benchmarks sind präzise Beendigungssignale entscheidend, um „Token-Bleeding“ zu vermeiden. Wir haben dies gelöst, indem wir sichergestellt haben, dass alle spezialisierten Agenten nach Abschluss einer Aufgabe ein explizites TERMINATE-Signal senden.
Manager-Overhead: Selbst mit GroupChatManager ist der interne Nachrichtenstatus von AutoGen aufgrund der Multiagenten-Orchestrierung größer als der von LangChain. Dies bietet jedoch deutlich strukturiertere Protokolle und Diskussionsverläufe als einfachere Frameworks.
Hinweis zu sequenzieller Ausführung vs. Gruppenchat: Wir haben alle Aufgaben mit dem GroupChatManager ausgeführt. In experimentellen Durchläufen mit sequenzieller Orchestrierung beobachteten wir einen mindestens doppelt so hohen Tokenverbrauch und eine höhere Latenz im Vergleich zum Gruppenchat-Modus. Dies bestätigt, dass die dynamische Agentenauswahl erhebliche Effizienzgewinne gegenüber festen Pipelines bietet.
Benchmark-Methodik für Multiagenten-Frameworks
Jedes Framework wurde 50 Mal (N=50) pro Aufgabe getestet.
Um Schwankungen im Denkprozess des Modells auszuschließen, verwendeten alle Frameworks dieselbe LLM-Konfiguration. Als Modell kam openai/gpt-5.2 über die OpenRouter-API zum Einsatz. Die Temperatur wurde auf 0,0 gesetzt.
Für die Antworten des LLM wurde keine maximale Token-Anzahl festgelegt, sodass die Frameworks so viel Kontext nutzen konnten, wie ihre interne Architektur zur Lösung der Aufgabe erforderte.
Zu den erfassten Metriken gehören: Anzahl der LLM-API-Aufrufe, Übergaben zwischen Agenten, Anzahl der aufgerufenen eindeutigen Agenten, Anzahl der ausgeführten Tool-Aufrufe und Genauigkeit der Tool-Aufrufe. Alle Metriken wurden pro Iteration protokolliert und über die 50 Durchläufe der Stichprobe aggregiert.
Wir trennten die Rohausgaben des LLM vom zusätzlichen Aufwand durch die Orchestrierung, um die Effizienz der Orchestrierung zu messen. Die LLM-Ausgabetoken repräsentieren die tatsächlich vom Modell generierten, nutzbaren Antworten, während der Framework-Overhead die Systembefehle, Werkzeugdefinitionen und Gesprächsverläufe umfasst, die das Framework im Hintergrund an das LLM übermitteln muss, um diese Antworten zu erhalten.
Diese Kennzahl, berechnet durch Subtraktion der Ausgabetoken von den Gesamttoken (Gesamt – Ausgabetoken), zeigt direkt die Verwaltungskosten des Frameworks an, die dem Benutzer verborgen bleiben. Dank dieser Unterscheidung erkennen wir, welche Frameworks effizient und schlank arbeiten und welche für jeden Orchestrierungsschritt wiederholt große Datenmengen in den LLM laden. Unsere Analyse basierte auf den Overhead-Token des Frameworks als primärer Effizienzkennzahl.
Um sicherzustellen, dass die Frameworks ausschließlich anhand ihrer Koordinationslogik bewertet wurden, synchronisierten wir alle anderen Variablen. Dadurch wurden Störfaktoren eliminiert und architektonische Unterschiede isoliert.
Die Agenten wurden in einer zentralen Datei definiert. Die Wrapper der einzelnen Frameworks fügten jeweils dieselbe Persona-Zeichenkette in ihre nativen Parameter ein: system_message für AutoGen, backstory für CrewAI, system prompts für LangChain/LangGraph und agent descriptions für Swarm. Es wurde keine frameworkspezifische Prompt-Entwicklung angewendet.
Alle Frameworks nutzten dieselben zugrundeliegenden Python-Funktionen. Werkzeugdefinitionen, Docstrings und Parameterschemata wurden standardisiert. Es wurden keine frameworkspezifischen, vorgefertigten Werkzeuge verwendet. Dadurch wird sichergestellt, dass die Ausführungslogik der Werkzeuge konsistent ist und sich lediglich die Orchestrierungsmechanismen unterscheiden.
In jeder Iteration wurden die Daten des „DataCo Smart Supply Chain“-Datensatzes an die Agenten übermittelt. Die Referenzdaten (Versandstatus, Zahlungsstatus, Gewinnmargen) blieben in allen Frameworks konstant.
Bei identischen Eingabebedingungen arbeitete jedes Framework in seinem nativen Strukturmodus. Wir zwangen die Frameworks nicht in unnatürliche Architekturen. Stattdessen implementierten wir jedes Framework gemäß seinem vorgesehenen Entwurfsmuster, um die Leistung in der Praxis zu messen.
AutoGen fungiert als dialogbasiertes Gruppenchatsystem. Es verwendet `initiate_chats` mit `TERMINATE`-Signalen zur Steuerung der Beendigungsbedingungen. Die Agenten kommunizieren über Nachrichtenaustausch, wobei ein UserProxy den Workflow koordiniert.
CrewAI implementiert eine aufgabenbasierte, sequentielle Pipeline. Dabei wird Process.sequential verwendet, wobei die Agenten in einer festgelegten Reihenfolge ausgeführt werden. Jeder Agent schließt seine Aufgabe ab und generiert einen Bericht, bevor der nächste Agent beginnt.
LangChain folgt einer linearen Kettenarchitektur. Es verwendet einen Standard-AgentExecutor, der die Tool-Aufrufschleife kapselt. Der Agent führt die Tools sequenziell innerhalb eines einzigen Kontexts aus.
LangGraph strukturiert die Ausführung als zyklischen Zustandsgraphen. Es verwendet StateGraph mit Knoten, die Verarbeitungsschritte darstellen, und bedingten Routing-Kanten, um den Ablauf zu bestimmen.
Swarm verwendet Handoff-basierte Routinen. Es nutzt transfer_to_agent-Funktionen, um die Kontrolle dynamisch zwischen Agenten auf Basis von Laufzeitentscheidungen zu übertragen.
Die Aufgaben wurden zunehmend komplexer, um verschiedene Orchestrierungsfähigkeiten und Fehlermodi auf die Probe zu stellen.
Aufgabe 1 (2 Agenten / 5 Tools): Testet den grundlegenden Orchestrierungsaufwand für einen einfachen Workflow, der die Erfassung von Bestellinformationen und die Entscheidungsfindung bei Rückerstattungen erfordert.
Aufgabe 2 (5 Agenten / 20 Tools): Testet die Routing-Intelligenz unter Störbedingungen. Es werden nur 2-3 Agenten und 3-5 Tools benötigt, es stehen jedoch 5 Agenten und 20 Tools zur Verfügung.
Aufgabe 3 (10 Agenten / 100 Tools): Testet die Grenzen der Hochentropiefilterung und Skalierbarkeit. Es werden nur 2–3 Agenten und 3–5 Tools benötigt, es stehen jedoch 10 Agenten und 100 Tools zur Verfügung, darunter 98 irrelevante Rausch-Tools, die das Routing stören sollen.
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich.