Die 5 besten Open-Source-Frameworks für agentenbasierte KI im Jahr 2026
Wir haben vier gängige Open-Source-Agentenframeworks in 2.000 Durchläufen (fünf Aufgaben, jeweils 100 Durchläufe pro Framework) verglichen und dabei die End-to-End-Latenz, den Tokenverbrauch und die architektonischen Unterschiede gemessen.
Benchmark für agentenbasierte KI-Frameworks
Wir haben untersucht, wie die Frameworks selbst das Agentenverhalten beeinflussen und welche Auswirkungen dies auf Latenz und Tokenverbrauch hat.
LangGraph ist das schnellste Framework mit den niedrigsten Latenzwerten über alle Aufgaben hinweg, während LangChain die höchste Latenz und den höchsten Tokenverbrauch aufweist.
In fünf Aufgaben und 2.000 Durchläufen erweist sich LangChain als das tokeneffizienteste Framework, während AutoGen hinsichtlich der Latenz führend ist; LangGraph und LangChain folgen dicht dahinter. CrewAI weist insgesamt die höchste Latenz auf.
Unsere Methodik können Sie hier im Detail einsehen.
Aufgabe 1: Grundlegende Aggregation
Zunächst haben wir den Aufwand jedes Frameworks gemessen, indem wir einfach ein einzelnes Tool aufgerufen und das Ergebnis zurückgegeben haben, ohne dabei komplexe Schlussfolgerungen zu ziehen.
LangChain & LangGraph: Bei einfachen Aufgaben arbeiten sie nahezu so schnell wie nicht-agentenbasierter Code und benötigen jeweils weniger als 5 Sekunden und weniger als 900 Eingabeaufforderungstoken. Die Zustandsautomatenarchitektur von LangGraph verursacht im Vergleich zu LangChain auf diesem einfachen Niveau keine spürbare Latenz; der Aufwand für die Zustandsverwaltung macht sich erst bei zunehmender Aufgabenkomplexität bemerkbar.
AutoGen: Liegt sowohl hinsichtlich Latenz als auch Tokenverbrauch etwas über LangChain und LangGraph, was die Grundkosten seiner Multi-Agenten-Konversationsschleife widerspiegelt, bei der zwei Agenten selbst für eine einstufige Aufgabe Nachrichten austauschen.
CrewAI: Selbst bei einem einzigen Tool-Aufruf zeigt es einen erheblichen Verwaltungsaufwand: Es verbraucht fast dreimal so viele Token wie LangChain und benötigt fast dreimal so lange. Der mehrstufige Verifizierungsprozess zwischen den Planer- und Analysten-Personas ist zwar gründlich, aber ressourcenintensiv und priorisiert Vollständigkeit vor Geschwindigkeit. Diese Kosten sind strukturell bedingt und treten unabhängig von der Aufgabenkomplexität auf.
Aufgabe 2: Vergleichende Einnahmenanalyse (Landesmanagement)
In Aufgabe 2 wollten wir die Fähigkeit der Frameworks untersuchen, zwei verschiedene Filtergruppen im Speicher zu halten (Zustandspersistenz) und diese zu kombinieren.
CrewAI
Unsere Log-Analyse ergab, dass CrewAI zwar die höchste Transparenz der Infrastruktur unter den Frameworks bietet, dies jedoch auf Kosten des höchsten Ressourcenverbrauchs geht.
Anstatt die abgerufenen Daten sofort zurückzugeben, validiert CrewAI seine Prozesse wiederholt durch einen Selbstprüfungsmechanismus. Dieses explorative Verhalten führte dazu, dass das konfigurierte Limit von max_iter=10 erreicht wurde, wodurch einige Durchläufe in einer Endlosschleife hängen blieben, ohne eine JSON-Ausgabe zu erzeugen.
Die Ursache für dieses Verhalten liegt darin, dass CrewAI mehrschichtige Anweisungen in die Systemeingabeaufforderung einfügt und jedem Agenten eine Rolle, ein Ziel und eine Hintergrundgeschichte zuweist, während gleichzeitig in jedem Schritt eine ReAct-ähnliche Schleife aus Gedanke → Handlung → Beobachtung erzwungen wird. Selbst bei einfachen Aufgaben kann das LLM diese Prozedur nicht überspringen und erzeugt pflichtgemäß ausführliche interne Monologe, was sich in Szenarien mit mehreren Agenten noch verstärkt.
CrewAI verbrauchte fast doppelt so viele Token wie die anderen Frameworks und benötigte mehr als dreimal so lange wie LangChain, wodurch es sich besser für komplexe Zustandsübergänge und multifaktorielle Entscheidungsfindung als für einfache Datenabrufaufgaben eignet.
LangChain
Das schnellste und kostengünstigste Framework. Unsere Protokolle zeigen, dass LangChain die Aufgabe in nur 5–6 Schritten ohne Umwege erledigt: Laden → Filtern → Berechnen → Filtern → Berechnen → Ausgabe. Dank des sehr einfachen Zustandsmanagements ist der Overhead nahezu null und die Latenz die geringste aller Frameworks.
AutoGen
Die Leistung war sehr ausgewogen. In Aufgabe 2 entsprach sie nahezu exakt der von LangGraph hinsichtlich Tokenverbrauch und Latenz, was zeigt, dass sich der Overhead der Konversationsschleife nicht wesentlich erhöht, wenn die Aufgabenkette linear bleibt.
Gelegentlich fügt es jedoch einen zusätzlichen Verifizierungsschritt hinzu, um Parameter während des Toolaufrufs zu bestätigen, wodurch es etwas langsamer als LangChain ist. Tritt bei einem Toolaufruf ein Fehler auf oder werden die Daten nicht wie erwartet zurückgegeben, aktualisiert es im nächsten Schritt umgehend seine Argumentation und erhält das korrekte JSON. Da es Toolausgaben als Dialogprozess verarbeitet, zählt es zu den robustesten Frameworks gegenüber logischen Fehlern.
LangGraph
LangGraph erwies sich in dieser Aufgabe dank seiner graphenbasierten Architektur als das stabilste Framework. In den Protokollen konnten wir beobachten, dass der Zustand während des gesamten Laufs sehr sauber erhalten blieb. Das Risiko von Datenverfälschungen oder sich gegenseitig beeinflussenden Segmenten ist in diesem Framework minimal. Über alle 100 Läufe hinweg lieferte es Ergebnisse mit nahezu der gleichen Anzahl an Schritten und innerhalb desselben Latenzbereichs.
Aufgabe 3: Schwellenwertanalyse (numerische Disziplin)
In dieser Aufgabe wollten wir sehen, wie genau die Frameworks numerische Bedingungen der natürlichen Sprache, wie z. B. „weniger als 1 Jahr Betriebszugehörigkeit“ und „monatliche Gebühren von mehr als 70 $“, in präzise Werkzeugparameter wie tenure_max=12 und charges_min=70.0 übersetzen.
Das LLM weiß bereits, wie diese Konvertierung durchgeführt wird; was wir eigentlich testen wollten, war, ob das Framework diese Parameter während seiner eigenen Wiederholungsmechanismen, des erneuten Eingabeaufforderungskontexts und der Zustandsverwaltungszyklen schützen kann.
LangChain & LangGraph
Beide Frameworks übergaben die Parameter (tenure_max=12, charges_min=70) direkt und unverändert, ohne jegliche Nachbearbeitung oder erneute Eingabeaufforderung, an das Tool – genau so, wie sie vom LLM generiert wurden. Diese Effizienz spiegelt sich in den Zahlen wider: Beide Frameworks schlossen Aufgabe 3 in unter 9 Sekunden mit weniger als 1.800 Eingabeaufforderungs-Tokens ab – der niedrigste Wert in dieser Aufgabe.
Als wir messen wollten, ob numerische Schwellenwerte erhalten bleiben, ohne dass das Framework eingreift, erfüllten diese beiden unsere Erwartungen: Welcher Parameter auch immer generiert wurde, genau dieser wurde ausgeführt.
AutoGen
Autogen lieferte vollständig korrekte numerische Ergebnisse. In einigen Durchläufen wurde beobachtet, dass das Framework vor der Übergabe des vom LLM generierten Parameters an das Tool einen Verifizierungsschritt einfügte. Dies bedeutet, dass das Framework einen zusätzlichen Schritt benötigte, um den Parameter zu erhalten. Bei 2.480 Token und 8 Sekunden erreichte es trotz des zusätzlichen Schritts die gleiche Latenz wie LangChain. Dies bestätigt, dass der Verifizierungsaufwand zwar vorhanden, aber gering ist. Unsere Erwartungen hinsichtlich der Parameterintegrität wurden erfüllt, da der Bestätigungsschritt lediglich einen geringfügigen Token-Verlust verursachte, anstatt eine nennenswerte Latenzzeitverlängerung.
CrewAI
Das auffälligste Verhalten zeigte sich bei CrewAI, das Aufgabe 3 in 30 Sekunden mit 4.360 Token abschloss – dem höchsten Wert in dieser Aufgabe. Die Protokollanalyse ergab zwei unterschiedliche Fehlermuster.
In einigen Durchläufen wurde ein Wert, der eigentlich 68,81 % betragen sollte, als 0,6878 (Dezimalverhältnis) zurückgegeben. Dies deutet darauf hin, dass die Ausgabeserialisierung des Frameworks die Ausgabe des LLM aus ihrem ursprünglichen Kontext entfernen kann.
Die Protokolle zeigen, dass das LLM anfänglich die korrekten Parameter lieferte: tenure_max=12 und charges_min=70. Nachdem CrewAI jedoch in eine „Fehler beim Parsen“-Schleife geraten war, veranlasste das Framework das LLM zu einer erneuten Überprüfung. Im Kontext der erneuten Abfrage verschob das LLM den Schwellenwert auf tenure_max=14 und deaktivierte den Filter charges_min vollständig. Dies führte zu einer Abwanderungsrate von 46,84 %, was der Abwanderungsrate aller Kunden mit einer Vertragslaufzeit von weniger als 14 Jahren entspricht. Genau dieses Szenario wollten wir beobachten: Der Wiederholungsmechanismus des Frameworks kann einen Parameter verfälschen, den das LLM zuvor korrekt ermittelt hatte.
Aufgabe 4: Fehlertoleranz und Pivot-Fähigkeit
In dieser Aufgabe wollten wir untersuchen, wie die einzelnen Frameworks mit Störungen umgehen und welche Auswirkungen dies auf Latenz und Tokenverbrauch hat. Das Tool erzeugt nacheinander drei verschiedene Fehlertypen (Netzwerkfehler, Timeout, Ratenbegrenzung), wodurch der Agent in eine Sackgasse gerät. Die ersten beiden Fehler fordern den Agenten zu einem erneuten Versuch auf. Nach beiden erfolglosen Versuchen fordert der Fehler „Ratenbegrenzung“ den Agenten auf, 10 Sekunden zu warten. Sobald der Agent gewartet und es erneut versucht hat, funktioniert das Tool wieder normal.
LangGraph & Autogen
Diese beiden Frameworks fanden bei Werkzeugausfällen in dieser Aufgabe selbstständig alternative Lösungen.
Als das Tool eine Warnung wegen Überschreitung des Ratenlimits ausgab, beschlossen die Agenten, anstatt abzuwarten, das fehlerhafte Tool komplett aufzugeben und einen alternativen Weg zu suchen. Ihr Ansatz war: „Da dieses Tool nicht funktioniert, filtere ich jede Zahlungsmethode einzeln, berechne die Abwanderungsrate für jede separat und kombiniere die Ergebnisse dann selbst.“
Methode: Anstatt die Aufgabe mit einem einzigen Toolaufruf zu erledigen, haben sie sie in zwei separate Tools aufgeteilt, eines zum Filtern und eines zum Berechnen, wobei jede Zahlungsmethode (Elektronischer Scheck, Postscheck usw.) einzeln verarbeitet wird.
Diese Agenten arbeiten zielorientiert anstatt pfadabhängig. Ist der kürzeste Pfad nicht verfügbar, können sie innerhalb von Sekunden einen alternativen Ausführungsplan erstellen.
LangGraph erreichte in Aufgabe 4 15.010 Prompt-Tokens – die höchste Token-Anzahl in einer einzelnen Aufgabe des gesamten Benchmarks. Grund dafür war, dass die Zustandsmaschine die wachsende Historie jedes manuellen Tool-Aufrufs in jedem Schritt in den Kontext einordnete. AutoGen folgte mit 10.750 Tokens, etwas weniger, da es Zwischenergebnisse dialogbasiert verarbeitet. Trotzdem schlossen beide Aufgaben in etwa 24–27 Sekunden ab, was bestätigt, dass die zusätzlichen Token-Kosten keine nennenswerte Latenz verursachten, da der Pivot-Prozess selbst schnell ablief.
CrewAI
Obwohl CrewAI in vorherigen Aufgaben den höchsten Tokenverbrauch aufwies, zeigte das Unternehmen in dieser Aufgabe den niedrigsten Tokenverbrauch, jedoch die höchsten Latenzwerte.
Warum der niedrigste Token?
CrewAI verzichtete im Gegensatz zu seinen Mitbewerbern auf einen manuellen Workaround mit 10 bis 15 Schritten. Anstatt bei jedem Fehler die gesamte Historie und die komplexen Zwischenergebnisse erneut in das LLM einzuspeisen, entwickelte es eine fokussiertere, modulare Argumentationsschleife. Durch die Vermeidung unnötiger Ausführlichkeit erwies es sich als das kosteneffektivste Framework für diese Aufgabe.
Warum hohe Latenz?
Die Managementstruktur von CrewAI unterbricht den Plan und überprüft ihn erneut, sobald ein Fehler auftritt. Nach Erhalt der 10-Sekunden-Wartewarnung verbrachte das System mehr Zeit in der Strategieplanungsphase. Anstatt auf ein anderes Filtertool umzusteigen, wartete es beharrlich auf die Wiederherstellung des Haupttools oder versuchte es mit dem stabilen Tool, was die Gesamtdauer verlängerte.
LangChain
LangChain durchlief bei dieser Aufgabe seine bedeutendste Transformation und bewies damit, warum Resilienz von der richtigen Konfiguration abhängt.
Bei unserem ersten Testlauf stürzte LangChain bei jedem einzelnen Versuch mit einem ConnectionError ab.
Der standardmäßige AgentExecutor von LangChain behandelt rohe Python-Ausnahmen, die innerhalb eines Tools ausgelöst werden, als schwerwiegende Fehler und beendet den Prozess. Im Gegensatz zu Konkurrenzprodukten verfolgt er nicht standardmäßig den Ansatz „Fehler sind Beobachtungen“. Da der Agent den Fehler nie sieht, hat er keine Möglichkeit, ihn zu analysieren.
Wir haben den Tool-Aufruf in langchain_agent.py in einen try-except-Block eingeschlossen. Dadurch wurde der Fehler in eine lesbare Meldung umgewandelt, die der Agent verarbeiten konnte.
Verhalten nach der Fehlerbehebung: Nach der Anwendung des Fixes stellten wir in den Logs von LangChain fest, dass es genau dasselbe Verhalten wie LangGraph zeigte. Es erhielt drei Fehler vom Tool, änderte daraufhin umgehend seine Strategie und nutzte fortan zwei separate Tools – eines zum Filtern und eines zum Berechnen –, verarbeitete jede Zahlungsmethode einzeln und kombinierte die Ergebnisse.
LangChain ist tatsächlich genauso leistungsfähig und anpassungsfähig wie LangGraph, doch da die Fehlerbehandlung des Frameworks standardmäßig deaktiviert war, konnte es diese Leistungsfähigkeit nicht unter Beweis stellen. Nach korrekter Konfiguration erzielte es mit demselben alternativen Ansatz das richtige Ergebnis.
Warum traten diese Unterschiede auf? (Architekturanalyse des Frameworks)
Wenn das Verhalten der Agenten ausschließlich vom LLM abhinge (GPT-5.2), hätten sich alle Frameworks ähnlich verhalten müssen. Die deutlichen Unterschiede in diesen Verhältnissen sind jedoch in den jeweiligen internen Regelkreismechanismen der Frameworks begründet:
1. LangGraph & AutoGen (90 % Pivot):
LangGraph basiert auf einer Zustandsautomatenarchitektur, während AutoGen auf einem konversationsbasierten Modell beruht. In beiden Systemen werden Fehler in einer Feedbackschleife verarbeitet. Bei LangGraph wird der Zustand, der den Fehler empfängt, an den nächsten Knoten weitergegeben; bei AutoGen leitet der Proxy-Agent den Fehler als Chatnachricht an den Assistenten weiter. Dieser ständige Anstoß zwingt den Agenten, fortwährend nach einer Lösung zu suchen. Da der Agent wiederholt mit der Frage „Ich habe einen Fehler erhalten, was soll ich tun?“ konfrontiert wird, steigt die Wahrscheinlichkeit, dass er einen alternativen, manuellen Lösungsweg wählt, auf 90 %.
2. LangChain (65 % Pivot / 35 % Warten):
LangChain basiert auf einer sequenziellen AgentExecutor-Architektur. Trotz Fehlerbehandlung weist die Ausführungsschleife eine eher lineare Struktur auf und ist primär auf die Generierung eines Endergebnisses ausgerichtet. Sollte das Tool in drei bis vier Schritten Fehler ausgeben, wartet LangChain mitunter lieber auf den Erfolg des nächsten Versuchs oder liefert ein Ergebnis aus dem bestehenden Kontext, anstatt eine alternative Strategie zu verfolgen. Da die Zustandssperrung in LangChain flexibler ist als in LangGraph, liegt das Verhältnis von Wartezeiten zu direkten Lösungsversuchen bei etwa 35 %.
3. CrewAI (0% Pivot):
CrewAI arbeitet mit einer Managementprozessarchitektur. Die Agenten sind in Rollen- und Aufgabendefinitionen eingebunden. Bei Fehlern löst die interne Architektur typischerweise Selbstkorrektur- oder Wiederholungslogik aus. Eine radikale Strategieänderung wie „Wir verwerfen den gesamten Plan und führen die Filterung manuell in fünf Schritten durch“ steht jedoch im Widerspruch zur Managementplanstruktur von CrewAI. Das System arbeitet nach dem Prinzip „Ich repariere das mir zur Verfügung gestellte Werkzeug oder nutze die nächstliegende Alternative“, anstatt den Plan komplett aufzugeben. Dies ist im Grunde ein planorientierter, nicht ein zielorientierter Ansatz.
Aufgabe 5: Orchestrierung unstrukturierter Daten (Routing unstrukturierter Daten)
In Aufgabe 5 untersuchten wir das Verhalten der Frameworks beim Umgang mit JSON- und LongText-Spalten (LongText) in einer CSV-Datei. Die Agenten mussten zunächst den Datentyp dieser Spalten ermitteln und anschließend die passenden Verarbeitungswerkzeuge entweder sequenziell oder parallel auswählen.
In der realen Welt erfordert die Verwaltung unstrukturierter Daten, dass ein System über standardmäßige Tabellendaten hinausgeht und mit JSON-Blobs, Freitextabsätzen oder verschachtelten Objekten arbeiten kann.
Damit ein Framework diese Art von Daten korrekt verarbeiten kann, muss es zwei Dinge gut können:
1. Eine Erkennungsintelligenz, die versteht, welches Tool zu welchem Datentyp passt.
2- ein Orchestrierungsmechanismus, der mehrere unabhängige Tool-Aufrufe koordiniert.
Aufgabe 5 wurde speziell entwickelt, um diese beiden Fähigkeiten getrennt zu messen.
AutoGen
AutoGen lieferte bei dieser Aufgabe eine starke Leistung ab und erreichte 8.170 Prompt-Tokens bei einer mittleren Latenz von 47 Sekunden – das schnellste und tokeneffizienteste Ergebnis in Aufgabe 5.
Die dem Kern der Architektur zugrunde liegende Gesprächsschleife, die Nachrichtenübermittlung zwischen AssistantAgent und UserProxyAgent, wird üblicherweise als Struktur angesehen, die zu Ausführlichkeit führt. In Aufgabe 5 erwies sich diese Struktur jedoch als Vorteil.
Durch die Analyse des Gesprächsverlaufs erkannte LLM, dass die Spalten „Metadata“ und „SupportNotes“ voneinander unabhängig waren. Daraufhin sendete es eine einzige TOOL CALLS-Antwort, die vier Tools gleichzeitig auflistete: inspect_column(Metadata), inspect_column(SupportNotes), parse_json_column(…) und summarize_text_column(…). Diese wurden alle parallel ausgeführt. Dadurch konnte die Aufgabe in nur drei LLM-Zügen mit minimalem Token- und Schrittaufwand abgeschlossen werden.
Der technische Grund für dieses Verhalten ist klar: Die Tool-Ausführungs-Engine von AutoGen führt die vom LLM zurückgegebene Tool-Aufrufliste atomar aus und sammelt die Ergebnisse in einem einzigen Konversationsschritt. Die Philosophie des Frameworks, die Konversation zu verwalten, ermöglicht es naturgemäß, mehrere parallele Kanäle gleichzeitig zu öffnen, was durch die Token- und Latenzwerte direkt bestätigt wird.
LangGraph
LangGraph erreichte 9.150 Eingabeaufforderungs-Tokens und eine mittlere Bearbeitungszeit von 70 Sekunden, was in Bezug auf die Tokens nahe an AutoGen liegt, aber langsamer in der Bearbeitungszeit ist. Die Zustandsautomatenarchitektur zeigte in Aufgabe 5 gleichzeitig ihre größte Stärke und ihre bemerkenswerteste Schwäche.
Bei jedem Durchlauf sammelt die Schleife llm-Knoten → Werkzeugknoten → llm-Knoten alle vorherigen Werkzeugausgaben im Zustand und übergibt sie an den LLM. Diese Struktur stellt sicher, dass der Agent nichts vergisst, was normalerweise ein erheblicher Vorteil ist.
In Aufgabe 5 wirkte sich diese Stärke jedoch negativ aus. LangGraph fand zwar die richtigen Werkzeuge und erstellte das korrekte Segment, doch selbst nach Abschluss der Analyse erkannte es Unklarheiten im akkumulierten Zustand, interpretierte bereits abgeschlossene Schritte als noch ausstehend und löste wiederholt zusätzliche Werkzeugaufrufe aus. Obwohl es die notwendigen Daten bereits abgerufen hatte und kurz vor der korrekten Antwort stand, aktivierte sich das Signal des Zustandsautomaten für einen fehlenden Schritt, und der Agent geriet in unnötige Schleifen. Dadurch schwankte die Anzahl der Werkzeugaufrufe pro Durchlauf zwischen 6 und 16. Die Fähigkeit des Zustandsautomaten, „nie etwas zu vergessen“, ließ abgeschlossene Schritte mitunter unvollständig erscheinen, was den Agenten in redundante Zyklen zurückzog und die Latenz trotz vergleichbarer Tokenanzahl um 23 Sekunden über die von AutoGen erhöhte.
CrewAI
Die Leistung von CrewAI in Aufgabe 5 wies die größte Varianz im gesamten Benchmark auf. In einigen Durchläufen folgte das Programm einer fehlerfreien Sequenz mit nur fünf Tool-Aufrufen, ohne Umwege, und funktionierte wie ein Skript. In diesen Durchläufen funktionierte die rollen- und aufgabenorientierte Managementstruktur von CrewAI exakt wie vorgesehen: Sobald der Agent seine Rolle klar verstand, verhielt er sich vorhersehbar und diszipliniert.
In anderen Durchläufen (z. B. Durchlauf 16: 35 Tool-Aufrufe) kam es jedoch zu völligem Chaos. Die Ursache lag im internen Monolog (Gedanken), den CrewAI in jedem Schritt generiert. Nachdem das Segment mit dem richtigen Filter korrekt erstellt worden war, begann der Agent in seinem inneren Monolog zu hinterfragen, ob weitere Filter angewendet werden sollten. Nach Betrachtung des Ergebnisses zweifelte er daran, ob das aktuelle Segment gültig sei oder ob das vorherige Vorrang haben sollte. Dieser Zweifel veranlasste ihn, die Daten komplett neu zu laden. Anschließend filterte er erneut, durchlief eine weitere Verifizierungsschleife, zweifelte wieder und wiederholte diese Spirale achtmal.
In CrewAI erzeugt jeder Gedanke eine unabhängige Bewertung, und diese Bewertungen können zuvor bestätigte Schritte mitunter ungültig machen. Der „kontinuierliche Überprüfungsreflex“ des Managementprozesses veranlasste den Agenten in einigen Durchläufen dazu, seine eigenen korrekten Entscheidungen erneut zu hinterfragen.
LangChain
Die AgentExecutor-Struktur von LangChain ist von Natur aus sequenziell, und diese Einschränkung zeigte sich besonders deutlich bei Aufgabe 5. Mit 10.070 Eingabeaufforderungstoken und einer mittleren Ausführungszeit von 86 Sekunden war es das langsamste Framework in dieser Aufgabe, obwohl es nicht die höchste Tokenanzahl aufwies.
Es führt in jedem Schritt einen einzelnen Tool-Aufruf durch, empfängt das Ergebnis und fährt dann fort. Das bedeutet, dass vier unabhängige Tools vier separate LLM-Durchläufe mit vier separaten Wartezeiten benötigen. Die mittlere Laufzeit von 47 Sekunden bei AutoGen im Vergleich zu 86 Sekunden bei LangChain ist ein direkter Indikator für die Kosten sequenzieller versus paralleler Ausführung.
In Aufgabe 5 pendelte sich die Anzahl der verwendeten Tools in LangChain im Allgemeinen bei 9 oder 15 ein. Diese beiden Häufungen deuten auf zwei typische Strategien hin: In einigen Durchläufen wurde der Inspektionsschritt übersprungen und direkt mit dem Parsen und Zusammenfassen begonnen (9 Tools), während in anderen Durchläufen jede Spalte vor der Verarbeitung inspiziert wurde (15 Tools). Hier wurde die lineare Executor-Identität von LangChain deutlich: Es zeigte weder die parallele Effizienz von AutoGen noch das chaotische Monologverhalten von CrewAI.
Verwaltung unstrukturierter Daten und Framework-Architektur
Die Ergebnisse dieser Untersuchung zeigen, dass die Effizienz, mit der ein Framework unstrukturierte Daten (JSON, LongText) verarbeiten kann, direkt mit seinem inneren Schleifenmechanismus zusammenhängt:
Frameworks, die parallele Toolaufrufe ermöglichen (z. B. AutoGen), können unabhängige Datenspalten in einem einzigen Schritt verarbeiten. In realen Szenarien mit großen JSON-Objekten und zahlreichen Textspalten führt dies zu einem erheblichen Kosten- und Geschwindigkeitsvorteil.
Frameworks mit zustandsgesteuerten Schleifen (LangGraph) zeichnen sich durch hohe Datenkonsistenz aus, bergen aber das Risiko, dass bereits abgeschlossene, in der Historie angesammelte Schritte erneut ausgewertet werden.
Monologbasierte Frameworks (CrewAI) sind zwar in hohem Maße in der Lage, die Art und Bedeutung von Daten zu verstehen, aber diese Tiefe schlägt manchmal in übermäßiges Fragen und Schleifen um.
Lineare Ausführungsframeworks (LangChain) verarbeiten verschiedene Zweige unstrukturierter Daten separat und erzeugen so ein Ergebnis, das die Vorteile beider Welten vereint.
GitHub-Starwachstum von agentenbasierten Frameworks
Vergleich agentenbasierter KI-Frameworks
Agentische KI-Frameworks unterscheiden sich in mehreren Schlüsselaspekten, und das Verständnis dieser Unterschiede ist für aussagekräftige Vergleiche unerlässlich.
Multiagenten-Orchestrierung
Die Multiagenten-Orchestrierung koordiniert mehrere spezialisierte KI-Agenten, um komplexe Arbeitsabläufe zu bewältigen, die die Fähigkeiten eines einzelnen Agenten übersteigen. Anstatt einen monolithischen Agenten zu entwickeln, verteilt die Orchestrierung die Arbeit auf Agenten mit unterschiedlichen Rollen, Werkzeugen und Fachkenntnissen. Jedes Framework bietet unterschiedliche Ansätze zur Agentenkoordination.
LangGraph
LangGraph ist ein relativ bekanntes Framework und gilt als wichtige Option für Entwickler, die Agentensysteme erstellen.
Explizite Multiagenten-Koordination: Sie können mehrere Agenten als einzelne Knoten oder Gruppen modellieren, von denen jeder über eine eigene Logik, einen eigenen Speicher und eine eigene Rolle im System verfügt.
Es erstellt KI-Workflows über APIs und Tools hinweg. Daher eignet es sich gut für RAG- und benutzerdefinierte Pipelines.
AutoGen
AutoGen ermöglicht es mehreren Agenten, durch den Austausch von Nachrichten in einer Schleife zu kommunizieren. Jeder Agent kann basierend auf seiner internen Logik antworten, reflektieren oder Tools aufrufen.
Es verfügt über eine asynchrone Agentenkollaboration und eignet sich daher besonders für Forschungs- und Prototyping-Szenarien, in denen das Agentenverhalten experimentell ermittelt oder iterativ verfeinert werden muss.
CrewAI
CrewAI übernimmt den Großteil der Low-Level-Logik für Sie und bietet Multi-Agenten-Orchestrierung:
- Lässt sich in Überwachungstools zur Fehlersuche und -behebung integrieren.
- Integrierte Ausführungssteuerung durch Flows mit bedingter Logik, Schleifen und Zustandsverwaltung
- Unterstützt hierarchische (Manager-Mitarbeiter) und strukturierte Multiagenten-Koordination
OpenAI Schwarm
Swarm ist ein leichtgewichtiges, experimentelles Multiagenten-Framework für Prototyping. Die Agenten arbeiten sequenziell mit Aufgabenübergaben und behalten dabei den gemeinsamen Kontext bei. Es nutzt Routinen für natürliche Sprache und Python-Tools für flexible Arbeitsabläufe.
LangChain
LangChain ist ein Framework zum Erstellen von Single-Agent-LLM-Anwendungen mit RAG-Tools. Es bietet modulare Komponenten wie Chains, Tools, Speicher und Retrieval für Dokumentenverarbeitungs-Workflows.
LangChain arbeitet primär mit Single-Agent-Ausführungsmustern, bei denen ein Agent den Workflow verwaltet.
Agenten- und Funktionsdefinition
LangGraph
LangGraph verwendet einen graphenbasierten Ansatz für das Agentendesign, bei dem jeder Agent als Knoten dargestellt wird, der seinen eigenen Zustand verwaltet. Diese Knoten sind über einen gerichteten Graphen verbunden, was bedingte Logik, die Koordination mehrerer Teams und hierarchische Steuerung ermöglicht. So können Sie Multiagentengraphen mit Supervisor-Knoten für eine skalierbare Orchestrierung erstellen und visualisieren.
LangGraph verwendet annotierte, strukturierte Funktionen , die Tools Agenten zuordnen. Sie können Knoten erstellen, diese mit verschiedenen Supervisoren verbinden und visualisieren, wie unterschiedliche Teams interagieren. Stellen Sie sich das so vor, als würde jedes Teammitglied eine detaillierte Stellenbeschreibung erhalten. Dadurch wird es einfacher, Agenten zu entwickeln und zu testen, die zusammenarbeiten.
AutoGen
AutoGen definiert Agenten als adaptive Einheiten , die flexibles Routing und asynchrone Kommunikation ermöglichen. Agenten interagieren miteinander (und optional mit Menschen) durch den Austausch von Nachrichten, was kollaborative Problemlösung ermöglicht. Ähnlich wie LangGraph annotierte, strukturierte Funktionen verwendet.
CrewAI
CrewAI verfolgt einen rollenbasierten Designansatz . Jedem Agenten wird eine Rolle (z. B. Forscher, Entwickler) und eine Reihe von Fähigkeiten, Funktionen oder Werkzeugen zugewiesen, auf die er zugreifen kann. Die Funktionsdefinition erfolgt über strukturierte Annotationen .
OpenAI Schwarm
Swarm verwendet ein routinenbasiertes Modell , in dem Agenten über Eingabeaufforderungen und Funktionsbeschreibungen definiert werden. Es verfügt über keine formale Orchestrierung oder Zustandsmodelle, sondern setzt stattdessen auf manuell strukturierte Arbeitsabläufe. Das Funktionsverhalten wird vom LLM anhand der Beschreibungen abgeleitet (Swarm identifiziert die Funktion anhand ihrer Beschreibung), was dieses Setup zwar flexibel, aber weniger präzise macht.
LangChain
LangChain verwendet eine kettenbasierte Architektur, in der ein einzelner Orchestrator-Agent Aufrufe an Sprachmodelle und verschiedene Tools verwaltet. Funktionen werden über explizite Schnittstellen wie Toolkits und Prompt-Vorlagen definiert.
LangChain konzentriert sich zwar primär auf zentralisierte Arbeitsabläufe, unterstützt aber Erweiterungen für Multi-Agent-Setups. Allerdings fehlt eine integrierte Agent-zu-Agent-Kommunikation.
Erinnerung
Speicherkapazität :
- Stateful : Gibt an, ob das Framework persistenten Speicher über mehrere Ausführungen hinweg unterstützt.
- Kontextbezogen : Ob es das Kurzzeitgedächtnis durch Nachrichtenverlauf oder Kontextweitergabe unterstützt.
Speicherfunktionen sind ein Schlüsselelement beim Aufbau agentenbasierter Systeme, um Kontext zu speichern und sich im Laufe der Zeit anzupassen:
- Kurzzeitgedächtnis : Speichert die letzten Interaktionen und ermöglicht es den Agenten, mehrstufige Gespräche oder schrittweise Arbeitsabläufe zu bewältigen.
- Langzeitgedächtnis : Speichert dauerhafte Informationen über mehrere Sitzungen hinweg, wie z. B. Benutzerpräferenzen oder Aufgabenverlauf.
- Entitätsspeicher : Speichert und aktualisiert Wissen über spezifische Objekte, Personen oder Konzepte, die während Interaktionen erwähnt wurden (z. B. das Erinnern eines Firmennamens oder einer Projekt-ID, die zuvor erwähnt wurde).
LangGraph
LangGraph verwendet zwei Speichertypen: In-Thread-Speicher , der Informationen während einer einzelnen Aufgabe oder Konversation speichert, und Cross-Thread-Speicher , der Daten sitzungsübergreifend sichert. Entwickler können MemorySaver verwenden, um den Ablauf einer Aufgabe zu speichern und ihn mit einem bestimmten thread_id zu verknüpfen. Für die Langzeitspeicherung unterstützt LangGraph Tools wie InMemoryStore oder andere Datenbanken. Dies ermöglicht eine flexible Steuerung der Speicherverwaltung und -nutzung über mehrere Ausführungen hinweg.
AutoGen
AutoGen verwendet ein kontextuelles Speichermodell . Jeder Agent verwaltet den kurzfristigen Kontext mithilfe eines context_variables-Objekts, das die Interaktionshistorie speichert. Es verfügt über keinen integrierten persistenten Speicher.
CrewAI
CrewAI Es bietet standardmäßig geschichteten Speicher. Kurzzeitdaten werden in einem ChromaDB-Vektorspeicher, aktuelle Aufgabenergebnisse in SQLite und Langzeitdaten in einer separaten SQLite-Tabelle (basierend auf Aufgabenbeschreibungen) gespeichert. Zusätzlich wird Entitätsspeicherung mittels Vektoreinbettungen unterstützt. Diese Speicherkonfiguration wird automatisch eingerichtet, wenn `memory=True` aktiviert ist.
OpenAI Schwarm
Swarm ist zustandslos und verwaltet den Speicher nicht nativ. Entwickler können den Kurzzeitspeicher manuell über context_variables übergeben und optional externe Tools oder Speicherschichten von Drittanbietern (z. B. mem0) integrieren, um längerfristige Kontextinformationen zu speichern.
LangChain
LangChain unterstützt sowohl Kurzzeit- als auch Langzeitgedächtnis durch flexible Komponenten. Das Kurzzeitgedächtnis wird typischerweise über In-Memory-Puffer verwaltet, die den Gesprächsverlauf innerhalb einer Sitzung speichern. Für das Langzeitgedächtnis integriert LangChain externe Vektorspeicher oder Datenbanken, um Einbettungen und Abrufdaten zu speichern.
Entwickler können Speicherbereiche und -strategien mithilfe integrierter Speicherklassen anpassen und so eine effiziente Verwaltung des kontextbezogenen und entitätsspezifischen Speichers über verschiedene Interaktionen hinweg ermöglichen.
Der Mensch im Regelkreis
LangGraph
LangGraph unterstützt benutzerdefinierte Haltepunkte (interrupt_before), um den Graphen anzuhalten und während der Ausführung auf Benutzereingaben zu warten.
AutoGen
AutoGen unterstützt nativ menschliche Agenten über UserProxyAgent, wodurch Menschen Schritte während der Zusammenarbeit der Agenten überprüfen, genehmigen oder ändern können.
CrewAI :
CrewA I ermöglicht Feedback nach jeder Aufgabe durch Setzen von human_input=True; der Agent pausiert, um natürlichsprachliche Eingaben vom Benutzer zu sammeln.
OpenAI Schwarm
OpenAI Swarm bietet kein integriertes HITL.
LangChain
LangChain ermöglicht das Einfügen benutzerdefinierter Haltepunkte innerhalb von Ketten oder Agenten, um die Ausführung anzuhalten und menschliche Eingaben anzufordern. Dies unterstützt Überprüfung, Feedback oder manuelle Eingriffe an definierten Punkten im Workflow.
Integration des Model Context Protocol (MCP) in agentenbasierte KI-Frameworks
KI-Agenten müssen mit externen Tools wie Datenbanken, APIs, Dateisystemen und Geschäftsanwendungen interagieren. Ohne einen Standard musste jedes Framework individuelle Integrationen für jedes Tool entwickeln, was zu einem fragmentierten Ökosystem führte. MCP löst dieses Problem durch ein universelles Protokoll, das es jedem Agenten ermöglicht, sich über eine einzige Schnittstelle mit jedem Tool zu verbinden.
Wie sich die einzelnen Frameworks in MCP integrieren lassen
LangGraph
LangGraph verbindet sich über einen Adapter mit MCP-Servern, der automatisch verfügbare Tools erkennt und in ein LangChain-kompatibles Format konvertiert. Agenten können diese Tools dann nahtlos neben ihren nativen Funktionen nutzen.
AutoGen
AutoGen bietet über sein Erweiterungsmodul eine integrierte MCP-Anbindung. Entwickler können sich mit nur wenigen Codezeilen mit MCP-Servern verbinden und all ihre Tools den AutoGen-Agenten zur Verfügung stellen.
CrewAI
CrewAI-Agenten können MCP-Server in ihrer Konfiguration direkt über einfache URLs oder strukturierte Einstellungen referenzieren. Das Framework übernimmt automatisch das Verbindungslebenszyklus- und Fehlermanagement.
OpenAI Schwarm
Swarm profitiert von der nativen MCP-Unterstützung von OpenAI in seinem gesamten Ökosystem. Da OpenAI MCP in ChatGPT und dessen Agents SDK integriert hat, kann Swarm diese Infrastruktur direkt nutzen.
LangChain
LangChain bietet Funktionen zum Aufrufen von MCP-Tools, wobei Python-Funktionen als Schnittstellen zu MCP-Servern fungieren. Dadurch können Tools aus verschiedenen Quellen abgerufen und ohne benutzerdefinierte Wrapper in Chains, Agents und andere LangChain-Komponenten integriert werden.
Was leisten agentenbasierte KI-Frameworks eigentlich?
Agentische KI-Frameworks unterstützen die Entwicklung von Prompts und die Verwaltung des Datenflusses zu und von LLMs . Im Wesentlichen helfen sie dabei, Prompts so zu strukturieren , dass das LLM in einem vorhersehbaren Format antwortet, und leiten die Antworten an das richtige Tool, die richtige API oder das richtige Dokument weiter.
Bei einer Neuentwicklung müssten Sie die Eingabeaufforderung manuell definieren, das vom LLM benötigte Tool extrahieren und den entsprechenden API-Aufruf auslösen. Frameworks vereinfachen diesen Vorgang durch:
- Prompt-Orchestrierung : Erstellen, Verwalten und Weiterleiten komplexer Prompts an LLMs
- Toolintegration : Agenten können externe APIs, Datenbanken, Codefunktionen usw. aufrufen.
- Gedächtnis : Aufrechterhaltung des Zustands über mehrere Runden oder Sitzungen hinweg (kurz- und langfristig)
- RAG-Integration : Ermöglichung des Wissensabrufs aus externen Quellen
- Multiagenten-Koordination : Strukturierung der Zusammenarbeit und Aufgabenverteilung zwischen Agenten
Agentische KI-Frameworks: Anwendungsfälle aus der Praxis
LangGraph – Multi-Agent-Reiseplaner
Ein mit LangGraph erstelltes Produktionsprojekt demonstriert einen zustandsbehafteten, Multiagenten-Reiseassistenten , der Flug- und Hoteldaten abruft (unter Verwendung der Google Flights & Hotels APIs) und Reiseempfehlungen generiert. 4
CrewAI – Agentic-Content-Ersteller
Das offizielle Beispiel-Repository von CrewAI umfasst Abläufe wie Reiseplanung , Marketingstrategie , Aktienanalyse und Rekrutierungsassistenten , bei denen rollenspezifische Agenten (z. B. „Researcher“, „Writer“) bei Aufgaben zusammenarbeiten. 5
CrewAI wandelt mithilfe von Groq ein grobes Inhaltsbriefing in einen vollständigen Artikel um.
Kernmerkmale von agentenbasierten KI-Frameworks
Modellunterstützung :
- Die meisten sind modellunabhängig und unterstützen mehrere LLM-Anbieter (z. B. OpenAI, Anthropic, Open-Source-Modelle).
- Allerdings variieren die Systemaufforderungsstrukturen je nach Framework und funktionieren bei manchen Modellen besser als bei anderen.
- Der Zugriff auf und die Anpassung von Systemabfragen sind oft unerlässlich für optimale Ergebnisse.
Werkzeuge :
- Alle Frameworks unterstützen die Nutzung von Tools , die einen Kernbestandteil der Ermöglichung von Agentenaktionen darstellen.
- Bieten Sie einfache Abstraktionen zur Definition benutzerdefinierter Werkzeuge an.
- Die meisten unterstützen das Model-Context-Protocol (MCP) , entweder nativ oder durch Community-Erweiterungen.
Speicher / Zustand :
- Verwenden Sie die Zustandsverfolgung , um das Kurzzeitgedächtnis über Schritte oder LLM-Aufrufe hinweg aufrechtzuerhalten.
- Einige Hilfsmittel unterstützen Agenten dabei, frühere Interaktionen oder den Kontext innerhalb einer Sitzung beizubehalten .
RAG (Retrieval-Augmented Generation) :
- Die meisten bieten einfache Einrichtungsoptionen für RAG , die Integration von Vektordatenbanken oder Dokumentenspeichern.
- Dies ermöglicht es den Agenten, während der Ausführung auf externes Wissen zurückzugreifen .
Weitere gemeinsame Merkmale
- Unterstützung für asynchrone Ausführung , wodurch gleichzeitige Agenten- oder Toolaufrufe ermöglicht werden.
- Integrierte Verarbeitung strukturierter Ausgaben (z. B. JSON).
- Unterstützung für Streaming-Ausgaben , bei denen das Modell die Ergebnisse inkrementell generiert.
- Grundlegende Observability-Funktionen zur Überwachung und Fehlersuche bei Agentenläufen.
Benchmark-Methodik
1. Aufgabenstruktur
Aufgabe 1: Es wird geprüft, ob ein einzelner Tool-Aufruf mit dem korrekten Parameter durchgeführt werden kann. Der grundlegende Infrastruktur-Overhead des Frameworks wird in diesem einfachen Szenario am deutlichsten sichtbar.
Aufgabe 2: Erfordert das Speichern der Ergebnisse zweier separater Filtergruppen im Speicher und deren Zusammenführung zu einem einzigen Ergebnis. Zustandsverwaltung und Koordination mehrerer Segmente werden getestet.
Aufgabe 3: Es wird geprüft, ob numerische Bedingungen in natürlicher Sprache verzerrungsfrei in Werkzeugparameter übersetzt werden. Der eigentliche Test besteht darin, ob die Wiederholungs- und Aufforderungsmechanismen des Frameworks diese Parameter beibehalten können.
Aufgabe 4: Ein Tool gibt nacheinander Netzwerk-, Timeout- und RateLimit-Fehler aus. Gemessen wird, ob das Framework angesichts dieser Fehler seine Strategie ändert.
Aufgabe 5: Der Agent muss zunächst JSON- und LongText-Spalten erkennen und anschließend die richtigen Tools mit den korrekten Bereichsparametern aufrufen. Dabei wird beobachtet, ob das Framework die einzelnen Tools parallel oder sequenziell ausführt.
2. Konfiguration
Alle Frameworks verwendeten dasselbe LLM-Modell (openai/gpt-5.2) und denselben Temperaturwert (0,1). Für alle Aufgaben erhielt jeder Agent dieselben Werkzeuge und dieselben Anweisungen. Jedes Framework wurde in seiner nativen Struktur eingerichtet: LangChain mit AgentExecutor, LangGraph mit StateGraph, AutoGen mit AssistantAgent + UserProxyAgent und CrewAI mit Agent + Task + Crew.
Für die Analyse wurde der Datensatz „Telco Customer Churn“ (7.032 Kunden, IBM) verwendet. Der Tool-Status wurde vor jedem Durchlauf zurückgesetzt. Für jede Framework- und Aufgabenkombination wurden 100 unabhängige Durchläufe durchgeführt.
Die maximale Anzahl an Iterationen wurde entsprechend der Aufgabenkomplexität festgelegt: 10 für die Aufgaben 1, 2 und 3; 20 für Aufgabe 4 aufgrund der unzuverlässigen Werkzeugschleife; und 20 für Aufgabe 5 aufgrund der 4-stufigen Entdeckungskette.
Referenzlinks
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich.