Top 5 Open-Source-Agentic-AI-Frameworks
Wir haben 4 beliebte Open-Source-Agentic-Frameworks in 2.000 Durchläufen (5 Aufgaben, je 100 Durchläufe pro Framework) einem Benchmark unterzogen und dabei die End-to-End-Latenz, den Token-Verbrauch und architektonische Unterschiede gemessen.
Benchmark für Agentic-AI-Frameworks
Wir untersuchten, wie die Frameworks selbst das Agentenverhalten und die daraus resultierenden Auswirkungen auf Latenz und Token-Verbrauch beeinflussen.
LangGraph ist das schnellste Framework mit den niedrigsten Latenzwerten über alle Aufgaben hinweg, während LangChain die höchste Latenz und den höchsten Token-Verbrauch aufweist.
Über 5 Aufgaben und 2.000 Durchläufe hinweg zeigt sich LangChain als das token-effizienteste Framework, während AutoGen bei der Latenz führend ist; LangGraph und LangChain folgen dicht dahinter. CrewAI weist das insgesamt schwerste Profil auf.
Sie können unsere Methodik hier im Detail einsehen.
Aufgabe 1: Einfache Aggregation
Zunächst maßen wir den Overhead jedes Frameworks, wenn ein einzelnes Tool aufgerufen und das Ergebnis zurückgegeben wird, ohne komplexes Reasoning durchzuführen.
LangChain & LangGraph: Für einfache Aufgaben arbeiten sie nahezu so schnell wie nicht-agentischer Code, beide schließen unter 5 Sekunden mit weniger als 900 Prompt-Tokens ab. Die Zustandsmaschinen-Architektur von LangGraph führt auf dieser Einfachheitsebene zu keiner spürbaren Latenz im Vergleich zu LangChain; der Overhead der Zustandsverwaltung materialisiert sich, wenn die Aufgabenkomplexität wächst.
AutoGen: Liegt sowohl bei Latenz als auch Token-Verbrauch leicht über LangChain und LangGraph, was die Basiskosten seiner Multi-Agenten-Konversationsschleife widerspiegelt – zwei Agenten tauschen Nachrichten aus, selbst bei einer einstufigen Aufgabe.
CrewAI: Selbst bei einem einzelnen Tool-Aufruf zeigt es das, was man als „Management-Overhead" bezeichnen könnte, es verbraucht nahezu das 3-fache der Tokens von LangChain und benötigt fast 3-mal länger. Der mehrstufige Verifizierungsprozess zwischen seinen Planner- und Analyst-Personas bietet einen gründlichen, aber ressourcenintensiven Ansatz, der Vollständigkeit über Geschwindigkeit stellt. Diese Kosten sind strukturell: Sie treten unabhängig von der Aufgabenkomplexität auf.
Aufgabe 2: Vergleichende Umsatzanalyse (Zustandsverwaltung)
In Aufgabe 2 wollten wir die Fähigkeit der Frameworks sehen, zwei verschiedene Filtergruppen im Speicher zu halten (Zustandspersistenz) und zu kombinieren.
CrewAI
In unserer Log-Analyse stellten wir fest, dass CrewAI die höchste Infrastrukturtransparenz unter den Frameworks bietet, jedoch auf Kosten des höchsten Ressourcenverbrauchs.
Anstatt abgerufene Daten sofort zurückzugeben, validiert CrewAI wiederholt seine eigenen Prozesse durch einen Selbstüberprüfungsmechanismus. Dieses explorative Verhalten führte dazu, dass die konfigurierte max_iter=10-Grenze erreicht wurde, wodurch einige Durchläufe in einer kontinuierlichen Denkschleife stecken blieben, ohne eine JSON-Ausgabe zu erzeugen.
Die Ursache für dieses Verhalten liegt darin, dass CrewAI mehrschichtige Anweisungen in den System-Prompt einfügt, jedem Agenten eine Rolle, ein Ziel und eine Hintergrundgeschichte zuweist und gleichzeitig bei jedem Schritt eine ReAct-artige Thought → Action → Observation-Schleife erzwingt. Selbst bei einfachen Aufgaben kann das LLM dieses Zeremoniell nicht überspringen und produziert pflichtgemäß ausführliche innere Monologe, was sich in Multi-Agenten-Szenarien weiter verstärkt.
CrewAI verbrauchte fast doppelt so viele Tokens wie die anderen Frameworks und benötigte über dreimal so lange wie LangChain, wodurch es besser für komplexe Zustandsübergänge und multifaktorielle Entscheidungsfindung geeignet ist als für einfache Datenabrufaufgaben.
LangChain
Das schnellste und kosteneffektivste Framework. In unseren Logs beobachteten wir, dass LangChain die Aufgabe in 5-6 Schritten ohne Umwege abschließt: Load → Filter → Calculate → Filter → Calculate → Output. Da seine Zustandsverwaltung sehr einfach ist, ist der Overhead nahezu null und die Latenz die niedrigste unter allen Frameworks.
AutoGen
Lieferte eine sehr ausgewogene Leistung. In Aufgabe 2 entsprach es LangGraph sowohl im Token-Verbrauch als auch in der Latenz fast exakt, was zeigt, dass der Overhead der Konversationsschleife sich nicht wesentlich verstärkt, wenn die Aufgabenkette linear bleibt.
Es fügt jedoch gelegentlich einen zusätzlichen Verifizierungsschritt hinzu, um Parameter während des Tool-Aufrufprozesses zu bestätigen, was es etwas langsamer als LangChain macht. Wenn es auf einen Fehler bei einem Tool-Aufruf stößt oder die Daten nicht wie erwartet zurückkommen, aktualisiert es sofort sein Reasoning im nächsten Schritt und gelangt zum korrekten JSON. Da es Tool-Ausgaben als Konversationsfluss verwaltet, ist es eines der widerstandsfähigsten Frameworks gegenüber logischen Fehlern.
LangGraph
In dieser Aufgabe ist LangGraph das stabilste Framework dank seiner graphenbasierten Architektur. In seinen Logs beobachteten wir, dass der Zustand während des gesamten Durchlaufs sehr sauber mitgeführt wird. Das Risiko von Datenkontamination oder dass sich Segmente gegenseitig stören, ist bei diesem Framework auf dem niedrigsten Niveau. Über alle 100 Durchläufe hinweg erzielte es Ergebnisse in nahezu derselben Anzahl von Schritten und innerhalb desselben Latenzbereichs.
Aufgabe 3: Schwellenwert-Parsing (numerische Disziplin)
In dieser Aufgabe wollten wir sehen, wie genau die Frameworks natürlichsprachliche numerische Bedingungen wie „weniger als 1 Jahr Betriebszugehörigkeit" und „mehr als 70 $ monatliche Gebühren" in präzise Tool-Parameter wie tenure_max=12 und charges_min=70.0 übersetzen.
Das LLM weiß, wie es diese Umwandlung vornimmt; was wir wirklich testen wollten, war, ob das Framework diese Parameter während seiner eigenen Wiederholungsmechanismen, Re-Prompt-Kontexte und Zustandsverwaltungszyklen schützen kann.
LangChain & LangGraph
Beide Frameworks übergaben die Parameter (tenure_max=12, charges_min=70) direkt und exakt so an das Tool, wie das LLM sie produzierte, ohne jegliche Modifikation oder Re-Prompt-Schleife. Diese Effizienz zeigt sich in den Zahlen: Beide Frameworks schlossen Aufgabe 3 in unter 9 Sekunden mit unter 1.800 Prompt-Tokens ab, den niedrigsten Werten in dieser Aufgabe.
Als wir messen wollten, ob numerische Schwellenwerte ohne Eingriffe des Frameworks erhalten bleiben, erfüllten diese beiden unsere Erwartungen: Welcher Parameter auch generiert wurde, genau das wurde ausgeführt.
AutoGen
AutoGen ist bei der numerischen Korrektheit vollständig erfolgreich. In einigen Durchläufen wurde beobachtet, dass das Framework einen Verifizierungsschritt hinzufügte, bevor es den vom LLM generierten Parameter an das Tool übergab, was bedeutet, dass das Framework einen zusätzlichen Schritt aufwendete, während es den Parameter bewahrte. Mit 2.480 Tokens und 8 Sekunden entsprach es der Latenz von LangChain trotz des zusätzlichen Schritts, was bestätigt, dass der Verifizierungs-Overhead real, aber gering ist. Es erfüllte unsere Erwartungen hinsichtlich der Parameterintegrität, wobei der Bestätigungsschritt eher marginale Token-Kosten als eine bedeutende Latenzstrafe verursachte.
CrewAI
Das auffälligste Verhalten wurde bei CrewAI beobachtet, das Aufgabe 3 in 30 Sekunden mit 4.360 Tokens abschloss, den höchsten Werten in dieser Aufgabe. Zwei unterschiedliche Fehlermuster gingen aus der Log-Analyse hervor.
In einigen Durchläufen wurde ein Wert, der 68,81 % hätte betragen sollen, 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 reißen kann.
Die Logs zeigen, dass das LLM zunächst die korrekten Parameter produzierte, tenure_max=12 und charges_min=70. Sobald CrewAI jedoch in eine „Failed to parse"-Schleife eintrat, drängte das Framework das LLM zum Überdenken. Im Re-Prompt-Kontext verschob das LLM den Schwellenwert auf tenure_max=14 und deaktivierte den charges_min-Filter vollständig, was eine Abwanderungsrate von 46,84 % ergab, was tatsächlich der Abwanderungsrate aller Kunden mit einer Betriebszugehörigkeit von weniger als 14 entspricht. Dies war genau das Szenario, das wir beobachten wollten: Der Wiederholungsmechanismus des Frameworks kann einen Parameter verfälschen, den das LLM richtig ermittelt hatte.
Aufgabe 4: Fehlerresilienz und Pivot-Fähigkeit
In dieser Aufgabe wollten wir sehen, wie jedes Framework mit disruptiven Szenarien umgeht und die Auswirkungen auf Latenz und Token-Verbrauch beobachten. Das Tool wirft nacheinander 3 verschiedene Fehlertypen (Network, Timeout, Rate Limit) und drängt den Agenten in die Ecke. Die ersten beiden Fehler weisen den Agenten an, es erneut zu versuchen, und nachdem beide erneut versucht wurden, teilt der eingehende Rate-Limit-Fehler dem Agenten mit, 10 Sekunden zu warten. Sobald der Agent wartet und es erneut versucht, funktioniert das Tool normal.
LangGraph & AutoGen
Diese beiden Frameworks fanden bei Tool-Ausfällen in dieser Aufgabe autonom alternative Lösungen.
Als das Tool eine Rate-Limit-Warnung zurückgab, entschieden sich diese Agenten, anstatt zu pausieren und zu warten, das fehlschlagende Tool vollständig aufzugeben und einen alternativen Weg zu finden. Ihr Ansatz war: „Da dieses Tool nicht funktioniert, werde ich jede Zahlungsmethode einzeln filtern, die Abwanderungsrate für jede separat berechnen und dann die Ergebnisse selbst kombinieren."
Methode: Anstatt die Aufgabe mit einem einzigen Tool-Aufruf zu erledigen, zerlegten sie sie, indem sie zwei separate Tools verwendeten, eines zum Filtern und eines zum Berechnen, und jede PaymentMethod (Electronic check, Mailed check usw.) einzeln verarbeiteten.
Diese Agenten arbeiten mit zielorientiertem Reasoning statt mit Pfadabhängigkeit. Wenn der kürzeste Pfad nicht verfügbar ist, können sie innerhalb von Sekunden einen alternativen Ausführungsplan konstruieren.
LangGraph erreichte 15.010 Prompt-Tokens in Aufgabe 4, die höchste Token-Zahl für eine einzelne Aufgabe im gesamten Benchmark, weil seine Zustandsmaschine die wachsende Historie jedes manuellen Tool-Aufrufs bei jedem Schritt wieder in den Kontext aufnahm. AutoGen folgte mit 10.750 Tokens, etwas eingedämmter aufgrund seiner konversationsbasierten Handhabung von Zwischenergebnissen. Trotzdem schlossen beide in etwa 24-27 Sekunden ab, was bestätigt, dass die zusätzlichen Token-Kosten sich nicht in bedeutende Latenz übersetzten, da der Pivot selbst schnell war.
CrewAI
Obwohl CrewAI in den vorherigen Aufgaben den höchsten Token-Verbrauch zeigte, wies es in dieser Aufgabe den niedrigsten Token-Verbrauch, aber die höchsten Latenzwerte auf.
Warum die niedrigsten Tokens?
CrewAI durchlief keine 10-15-stufige manuelle Umgehungslösung wie seine Konkurrenten. Als es auf Fehler stieß, baute es, anstatt bei jedem Schritt die gesamte Historie und komplexe Zwischendaten wiederholt in das LLM zu pumpen, eine fokussiertere, modulare Reasoning-Schleife auf. Durch die Vermeidung unnötiger Ausführlichkeit wurde es in dieser Aufgabe zum kosteneffektivsten Framework.
Warum hohe Latenz?
Die Management-Struktur von CrewAI pausiert und bewertet den Plan neu, wenn sie auf einen Fehler stößt. Als es die 10-Sekunden-Warte-Warnung erhielt, verbrachte es mehr Zeit in der „Strategieplanungs"-Phase. Darüber hinaus entschied es sich, anstatt auf ein anderes Tool zum Filtern umzuschwenken, beharrlich darauf zu warten, dass sich das Haupttool erholt, oder es mit dem stabilen Tool zu versuchen, was die Gesamtdauer verlängerte.
LangChain
LangChain durchlief in dieser Aufgabe seine bedeutendste Transformation und bewies, warum Resilienz von der richtigen Konfiguration abhängt.
In unserem ersten Durchlauf stürzte LangChain bei jedem einzelnen Versuch mit einem ConnectionError ab.
Der standardmäßige AgentExecutor von LangChain behandelt rohe Python-Exceptions, die innerhalb eines Tools ausgelöst werden, als fatale Fehler und beendet den Prozess. Anders als seine Konkurrenten wendet es standardmäßig keine „Fehler sind Beobachtungen"-Philosophie an. Da der Agent den Fehler nie sieht, hat er keine Chance, darüber nachzudenken.
Wir umhüllten den Tool-Aufruf innerhalb von langchain_agent.py mit einem try-except-Block. Dies wandelte den Fehler in eine lesbare Nachricht um, die der Agent verarbeiten konnte.
Verhalten nach der Korrektur: Nach Anwendung der Korrektur beobachteten wir in den Logs von LangChain, dass es exakt dasselbe Reasoning wie LangGraph zeigte. Es erhielt 3 Fehler vom Tool, wechselte sofort die Strategie und schwenkte auf die Verwendung von zwei separaten Tools um, eines zum Filtern und eines zum Berechnen, verarbeitete jede Zahlungsmethode einzeln und kombinierte die Ergebnisse.
LangChain ist tatsächlich genauso fähig und anpassungsfähig wie LangGraph, aber weil die Fehlerbehandlung des Frameworks standardmäßig deaktiviert war, hatte es keine Gelegenheit, diese Fähigkeit zu demonstrieren. Nach ordnungsgemäßer Konfiguration erreichte es das korrekte Ergebnis mit demselben alternativen Pfadansatz.
Warum traten diese Unterschiede auf? (Analyse der Framework-Architektur)
Wenn das Agentenverhalten ausschließlich vom LLM abhinge (GPT-5.2), hätten sich alle Frameworks ähnlich verhalten sollen. Die deutlichen Unterschiede in diesen Verhältnissen sind jedoch in den eigenen inneren Schleifenmechanismen der Frameworks verwurzelt:
1. LangGraph & AutoGen (90 % Pivot):
LangGraph arbeitet mit einer Zustandsmaschinen-Architektur, während AutoGen auf einem konversationsbasierten Modell arbeitet. In beiden Systemen werden Fehler als Feedback-Schleife verarbeitet. In LangGraph geht der Zustand, der den Fehler empfängt, an den nächsten Knoten über; in AutoGen leitet der Proxy-Agent den Fehler als Chat-Nachricht an den Assistenten weiter. Dieser ständige Anstoß-Mechanismus zwingt den Agenten, weiter nach einer Lösung zu suchen. Weil der Agent wiederholt mit der Frage konfrontiert wird: „Ich habe einen Fehler erhalten, was soll ich tun?", steigt die Wahrscheinlichkeit, dass er sich für einen alternativen manuellen Pfad entscheidet, auf 90 %.
2. LangChain (65 % Pivot / 35 % Warten):
LangChain läuft auf einer sequenziellen AgentExecutor-Architektur. Selbst mit vorhandener Fehlerbehandlung hat seine Ausführungsschleife eine linearere Struktur und ist primär darauf ausgerichtet, eine endgültige Antwort zu produzieren. Wenn das Tool für 3-4 Schritte Fehler wirft, zieht es LangChain manchmal vor, darauf zu warten, dass das Tool beim nächsten Versuch erfolgreich ist oder ein Ergebnis aus dem bestehenden Kontext zu produzieren, anstatt auf eine alternative Strategie umzuschwenken. Da die Zustandsbindung von LangChain flexibler ist als die von LangGraph, liegt sein Warten/Direktlösung-Verhältnis bei etwa 35 %.
3. CrewAI (0 % Pivot):
CrewAI arbeitet mit einer Managementprozess-Architektur. Seine Agenten sind in Rollen- und Aufgabendefinitionen eingebettet. Wenn Fehler auftreten, löst seine interne Architektur typischerweise Selbstkorrektur- oder Wiederholungslogik aus. Eine radikale Strategieänderung wie „lass uns den gesamten Plan verwerfen und manuelles Filtern in 5 Schritten durchführen" steht jedoch im Konflikt mit der Managementplan-Struktur von CrewAI. Es arbeitet mit der Disziplin „Ich sollte das mir gegebene Tool reparieren oder die nächstliegende Alternative verwenden", anstatt seinen Plan vollständig aufzugeben. Dies ist grundlegend ein planzentrierter Ansatz im Gegensatz zu einem zielzentrierten.
Aufgabe 5: Orchestrierung unstrukturierter Daten (Routing unstrukturierter Daten)
In Aufgabe 5 beobachteten wir, wie sich die Frameworks verhalten, wenn sie auf JSON- und Langtext-Spalten (LongText) innerhalb einer CSV stoßen. Die Agenten mussten zuerst den Datentyp dieser Spalten erkennen und dann die richtigen Verarbeitungstools entweder sequenziell oder parallel auswählen.
In der realen Welt erfordert das Management unstrukturierter Daten, dass ein Agent über standardmäßige tabellarische Daten hinausgeht und mit JSON-Blobs, free-Text-Absätzen oder verschachtelten Objekten arbeitet.
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- einen Orchestrierungsmechanismus, der mehrere unabhängige Tool-Aufrufe koordiniert.
Wir haben Aufgabe 5 speziell darauf ausgelegt, diese beiden Fähigkeiten getrennt zu messen.
AutoGen
AutoGen lieferte eine starke Leistung in dieser Aufgabe und schloss mit 8.170 Prompt-Tokens und einer medianen Latenz von 47 Sekunden ab, das schnellste und token-effizienteste Ergebnis in Aufgabe 5.
Die Konversationsschleife im Kern seiner Architektur, das Messaging zwischen AssistantAgent und UserProxyAgent, wird typischerweise als eine Struktur angesehen, die zu Ausführlichkeit führt. In Aufgabe 5 verwandelte sich diese Struktur jedoch in einen Vorteil.
Durch die Betrachtung des Konversationsverlaufs erkannte das LLM, dass die Spalten Metadata und SupportNotes unabhängig voneinander waren. Es sendete dann eine einzige TOOL CALLS-Antwort, die 4 Tools gleichzeitig auflistete: inspect_column(Metadata), inspect_column(SupportNotes), parse_json_column(…) und summarize_text_column(…) liefen alle parallel. Dadurch konnte es die Aufgabe in 3 LLM-Zügen abschließen, mit den wenigsten Tokens und den wenigsten Schritten.
Der technische Grund für dieses Verhalten ist klar: Die Tool-Ausführungs-Engine von AutoGen führt die vom LLM zurückgegebene tool_calls-Liste atomar aus und sammelt die Ergebnisse in einem einzigen Konversationsschritt. Die Philosophie des Frameworks, „die Konversation zu verwalten", erlaubt es natürlicherweise, mehrere parallele Kanäle gleichzeitig zu öffnen, und die Token- und Latenzzahlen bestätigen dies direkt.
LangGraph
LangGraph schloss mit 9.150 Prompt-Tokens und 70 Sekunden Median ab, nah an AutoGen bei den Tokens, aber langsamer bei der Zeit. Seine Zustandsmaschinen-Architektur zeigte in Aufgabe 5 gleichzeitig ihre größte Stärke und ihre bemerkenswerteste Schwäche.
In jedem Durchlauf sammelt die llm node → tools node → llm node-Schleife alle vorherigen Tool-Ausgaben im Zustand und übergibt sie an das LLM. Diese Struktur garantiert, dass der Agent niemals etwas vergisst, was normalerweise ein bedeutender Vorteil ist.
In Aufgabe 5 wirkte diese Stärke jedoch gegen ihn. LangGraph fand die richtigen Tools und baute das richtige Segment auf. Aber selbst nach Abschluss der Analyse erkannte es Mehrdeutigkeiten im sich ansammelnden Zustand, interpretierte abgeschlossene Schritte als noch ausstehend und löste wiederholt zusätzliche Tool-Aufrufe aus. Obwohl es die notwendigen Daten abgerufen hatte und kurz davor war, die richtige Antwort zu produzieren, griff das „fehlender Schritt"-Signal der Zustandsmaschine ein und der Agent trat in unnötige Schleifen ein. Infolgedessen lag die Anzahl der Tool-Aufrufe pro Durchlauf zwischen 6 und 16. Die Fähigkeit des Zustands, „niemals etwas zu vergessen", ließ manchmal abgeschlossene Schritte als unvollständig erscheinen, zog den Agenten zurück in redundante Zyklen und trieb die Latenz trotz vergleichbarer Token-Zahl um 23 Sekunden über AutoGen.
CrewAI
Die Leistung von CrewAI in Aufgabe 5 erzeugte die höchste Varianz im gesamten Benchmark. In einigen Durchläufen folgte es einer makellosen Sequenz mit 5 Tool-Aufrufen, ohne Umwege, und führte wie ein Skript aus. In diesen Durchläufen funktionierte die durch Rolle und Aufgabe definierte Managementstruktur von CrewAI genau wie beabsichtigt: Wenn der Agent seine Rolle klar verstand, verhielt er sich vorhersehbar und diszipliniert.
In anderen Durchläufen (z. B. Durchlauf 16: 35 Tool-Aufrufe) brach jedoch vollständiges Chaos aus. Die Ursache war der innere Monolog (Thought), den CrewAI bei jedem Schritt generiert. Nachdem das Segment mit dem richtigen Filter korrekt aufgebaut war, begann der innere Monolog des Agenten zu hinterfragen, ob auch zusätzliche Filter angewendet werden sollten. Nachdem er das Ergebnis gesehen hatte, zweifelte er, ob das aktuelle Segment gültig war oder das vorherige Vorrang haben sollte. Dieser Zweifel trieb ihn dazu, die Daten von Grund auf neu zu laden. Dann filterte er erneut, trat in eine weitere Verifizierungsschleife ein, zweifelte erneut und wiederholte diese Spirale 8 Mal.
In CrewAI produziert jeder Thought eine unabhängige Bewertung, und diese Bewertungen erklären gelegentlich zuvor verifizierte Schritte für ungültig. Der „kontinuierliche Verifizierungs"-Reflex des Managementprozesses trieb den Agenten in einigen Durchläufen dazu, seine eigenen korrekten Entscheidungen erneut zu hinterfragen.
LangChain
Die AgentExecutor-Struktur von LangChain ist inhärent sequenziell, und Aufgabe 5 ist der Punkt, an dem diese Einschränkung am deutlichsten sichtbar wurde. Mit 10.070 Prompt-Tokens und 86 Sekunden Median war es das langsamste Framework in dieser Aufgabe, obwohl es nicht die höchste Token-Zahl hatte.
Es führt bei jedem Schritt einen einzelnen Tool-Aufruf aus, empfängt das Ergebnis und macht dann weiter, was bedeutet, dass 4 unabhängige Tools 4 separate LLM-Züge mit 4 separaten Wartezeiten erforderten. Der 47-Sekunden-Median von AutoGen gegenüber 86 Sekunden von LangChain ist eine direkte Messung der Kosten von sequenzieller gegenüber paralleler Ausführung.
In Aufgabe 5 pendelte sich die Tool-Anzahl von LangChain entweder bei 9 oder 15 ein. Diese beiden Cluster deuten auf zwei typische Strategien hin: In einigen Durchläufen übersprang es den Inspektionsschritt und ging direkt zum Parsing und Summarizing über (9 Tools), während es in anderen zuerst jede Spalte inspizierte, bevor es sie verarbeitete (15 Tools). Die lineare Executor-Identität von LangChain wurde hier deutlich: Es zeigte weder die parallele Effizienz von AutoGen noch das Monolog-Chaos von CrewAI.
Management unstrukturierter Daten und Framework-Architektur
Die Ergebnisse dieser Aufgabe zeigen, dass die Effizienz, mit der ein Framework unstrukturierte Daten (JSON, LongText) verwalten kann, direkt mit seinem inneren Schleifenmechanismus zusammenhängt:
Frameworks, die zu parallelen Tool-Aufrufen fähig sind (AutoGen), können unabhängige Datenspalten in einem einzigen Schritt verarbeiten. In realen Szenarien mit großen JSON-Objekten und zahlreichen Textspalten übersetzt sich dieser Unterschied in einen massiven Kosten- und Geschwindigkeitsvorteil.
Frameworks mit zustandsgesteuerten Schleifen (LangGraph) zeichnen sich durch Datenkonsistenz aus, tragen aber das Risiko, abgeschlossene, in der Historie angesammelte Schritte neu zu bewerten.
Monologbasierte Frameworks (CrewAI) sind tiefgreifend in der Lage, den Typ und die Bedeutung von Daten zu verstehen, aber diese Tiefe schlägt manchmal in übermäßiges Hinterfragen und Schleifen um.
Lineare Ausführungs-Frameworks (LangChain) verarbeiten verschiedene Zweige unstrukturierter Daten separat und erzielen ein Mittelweg-Ergebnis aus beiden Welten.
GitHub-Stern-Wachstum von Agentic-Frameworks
Vergleich von Agentic-AI-Frameworks
Agentic-AI-Frameworks variieren in mehreren Schlüsseldimensionen, und das Verständnis dieser Unterschiede ist für aussagekräftige Vergleiche unerlässlich.
Multi-Agenten-Orchestrierung
Multi-Agenten-Orchestrierung koordiniert mehrere spezialisierte KI-Agenten, um komplexe Workflows zu bewältigen, die die Fähigkeiten einzelner Agenten übersteigen. Anstatt einen monolithischen Agenten zu bauen, verteilt die Orchestrierung die Arbeit auf Agenten mit unterschiedlichen Rollen, Tools und Fachkenntnissen. Jedes Framework bietet unterschiedliche Ansätze zur Agentenkoordination.
LangGraph
LangGraph ist ein relativ bekanntes Framework und stellt eine wichtige Option für Entwickler dar, die Agentensysteme bauen.
Explizite Multi-Agenten-Koordination: Sie können mehrere Agenten als einzelne Knoten oder Gruppen modellieren, jeder mit eigener Logik, eigenem Speicher und eigener Rolle im System.
Es erstellt KI-Workflows über APIs und Tools hinweg. Somit ist es gut geeignet 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 Agentenzusammenarbeit, was es besonders nützlich für Forschungs- und Prototyping-Szenarien macht, in denen das Agentenverhalten Experimente oder iterative Verfeinerung erfordert.
CrewAI
CrewAI übernimmt den Großteil der Low-Level-Logik für Sie und bietet Multi-Agenten-Orchestrierung:
- Integration mit Monitoring-Tools für Tracing und Debugging
- Integrierte Ausführungskontrolle durch Flows mit bedingter Logik, Schleifen und Zustandsverwaltung
- Unterstützt hierarchische (Manager-Worker) und strukturierte Multi-Agenten-Koordination
OpenAI Swarm
Swarm ist ein leichtgewichtiges, experimentelles Multi-Agenten-Framework für Prototyping. Agenten arbeiten sequenziell durch Übergaben und übertragen Aufgaben unter Beibehaltung des gemeinsamen Kontexts. Es verwendet natürlichsprachliche Routinen und Python-Tools für flexible Workflows.
LangChain
LangChain ist ein Framework zum Erstellen von Single-Agent-LLM-Anwendungen mit RAG-Tooling. Es bietet modulare Komponenten einschließlich Chains, Tools, Speicher und Retrieval für Dokumentenverarbeitungs-Workflows.
LangChain arbeitet primär durch Single-Agent-Ausführungsmuster, bei denen ein Agent den Workflow verwaltet.
Agenten- und Funktionsdefinition
LangGraph
LangGraph verfolgt einen graphenbasierten Ansatz für das Agentendesign, bei dem jeder Agent als ein Knoten dargestellt wird, der seinen eigenen Zustand aufrechterhält. Diese Knoten sind durch einen gerichteten Graphen verbunden, der bedingte Logik, Multi-Team-Koordination und hierarchische Kontrolle ermöglicht. Dies ermöglicht es Ihnen, Multi-Agenten-Graphen mit Supervisor-Knoten für skalierbare Orchestrierung zu erstellen und zu visualisieren.
LangGraph verwendet annotierte, strukturierte Funktionen, die Tools an Agenten binden. Sie können Knoten aufbauen, sie mit verschiedenen Supervisoren verbinden und visualisieren, wie verschiedene Teams interagieren. Stellen Sie es sich so vor, als würden Sie jedem Teammitglied eine detaillierte Stellenbeschreibung geben. Dies erleichtert das Erstellen und Testen von Agenten, die zusammenarbeiten.
AutoGen
AutoGen definiert Agenten als adaptive Einheiten, die zu flexiblem Routing und asynchroner Kommunikation fähig sind. Agenten interagieren miteinander (und optional mit Menschen) durch den Austausch von Nachrichten, was kollaboratives Problemlösen ermöglicht. Wie LangGraph verwendet es annotierte, strukturierte Funktionen.
CrewAI
CrewAI verfolgt einen rollenbasierten Designansatz. Jedem Agenten wird eine Rolle (z. B. Researcher, Developer) und eine Reihe von Fähigkeiten, Funktionen oder Tools zugewiesen, auf die er zugreifen kann. Die Funktionsdefinition erfolgt durch strukturierte Annotationen.
OpenAI Swarm
OpenAI Swarm verwendet ein routinenbasiertes Modell, bei dem Agenten durch Prompts und Funktions-Docstrings definiert werden. Es hat keine formale Orchestrierung oder Zustandsmodelle und stützt sich stattdessen auf manuell strukturierte Workflows. Das Funktionsverhalten wird vom LLM durch Docstrings abgeleitet (Swarm erkennt, was eine Funktion tut, indem es ihre Beschreibung liest), was dieses Setup flexibel, aber weniger präzise macht.
LangChain
LangChain verwendet eine Chain-basierte Architektur, bei der ein einzelner Orchestrator-Agent Aufrufe an Sprachmodelle und verschiedene Tools verwaltet. Es definiert Funktionen durch explizite Schnittstellen wie Toolkits und Prompt-Vorlagen.
Obwohl primär auf zentralisierte Workflows ausgerichtet, unterstützt LangChain Erweiterungen für Multi-Agenten-Setups, es fehlt jedoch die integrierte Agent-zu-Agent-Kommunikation.
Speicher
Speicherfähigkeiten:
- Zustandsbehaftet: Ob das Framework persistenten Speicher über Ausführungen hinweg unterstützt.
- Kontextuell: Ob es Kurzzeitspeicher über Nachrichtenverlauf oder Kontextweitergabe unterstützt.
Speicherfunktionen sind ein Schlüsselelement beim Aufbau agentischer Systeme, um sich an Kontext zu erinnern und sich im Laufe der Zeit anzupassen:
- Kurzzeitspeicher: Verfolgt kürzliche Interaktionen und ermöglicht es Agenten, mehrzügige Konversationen oder schrittweise Workflows zu bewältigen.
- Langzeitspeicher: Speichert persistente Informationen über Sitzungen hinweg, wie Benutzerpräferenzen oder Aufgabenverlauf.
- Entitätsspeicher: Verfolgt und aktualisiert Wissen über bestimmte Objekte, Personen oder Konzepte, die während Interaktionen erwähnt werden (z. B. sich an einen Firmennamen oder eine früher erwähnte Projekt-ID erinnern).
LangGraph
LangGraph verwendet zwei Arten von Speicher: In-Thread-Speicher, der Informationen während einer einzelnen Aufgabe oder Konversation speichert, und Cross-Thread-Speicher, der Daten über Sitzungen hinweg speichert. Entwickler können MemorySaver verwenden, um den Ablauf einer Aufgabe zu speichern und ihn mit einer bestimmten thread_id zu verknüpfen. Für die Langzeitspeicherung unterstützt LangGraph Tools wie InMemoryStore oder andere Datenbanken. Dies bietet flexible Kontrolle darüber, wie Speicher über Ausführungen hinweg abgegrenzt und aufbewahrt wird.
AutoGen
AutoGen verwendet ein kontextuelles Speichermodell. Jeder Agent verwaltet den Kurzzeitkontext durch ein context_variables-Objekt, das die Interaktionshistorie speichert. Es hat keinen integrierten persistenten Speicher.
CrewAI
CrewAI bietet mehrschichtigen Speicher von Haus aus. Es speichert den Kurzzeitspeicher in einem ChromaDB-Vector-Store, kürzliche Aufgabenergebnisse in SQLite und den Langzeitspeicher in einer separaten SQLite-Tabelle (basierend auf Aufgabenbeschreibungen). Darüber hinaus unterstützt es Entitätsspeicher mittels Vector Embeddings. Dieses Speicher-Setup wird automatisch konfiguriert, wenn memory=True aktiviert ist,
OpenAI Swarm
Swarm ist zustandslos und verwaltet Speicher nicht nativ. Entwickler können Kurzzeitspeicher manuell über context_variables weitergeben und optional externe Tools oder Drittanbieter-Speicherschichten (z. B. mem0) integrieren, um längerfristigen Kontext zu speichern.
LangChain
LangChain unterstützt sowohl Kurzzeit- als auch Langzeitspeicher durch flexible Komponenten. Der Kurzzeitspeicher wird typischerweise über In-Memory-Puffer verwaltet, die den Konversationsverlauf innerhalb einer Sitzung verfolgen. Für den Langzeitspeicher integriert sich LangChain mit externen Vector Stores oder Datenbanken, um Embeddings und Retrieval-Daten zu persistieren.
Entwickler können Speicherbereiche und -strategien mit integrierten Speicherklassen anpassen, was ein effizientes Management von kontextuellem und entitätsspezifischem Speicher über Interaktionen hinweg ermöglicht.
Human-in-the-loop
LangGraph
LangGraph unterstützt benutzerdefinierte Haltepunkte (interrupt_before), um den Graphen zu pausieren und mitten in der Ausführung auf Benutzereingaben zu warten.
AutoGen
AutoGen unterstützt nativ menschliche Agenten über UserProxyAgent, die es Menschen ermöglichen, Schritte während der Agentenzusammenarbeit zu überprüfen, zu genehmigen oder zu ändern.
CrewAI:
CrewAI ermöglicht Feedback nach jeder Aufgabe durch Setzen von human_input=True; der Agent pausiert, um natürlichsprachliche Eingaben vom Benutzer zu sammeln.
OpenAI Swarm
OpenAI Swarm bietet kein integriertes HITL.
LangChain
LangChain erlaubt das Einfügen benutzerdefinierter Haltepunkte innerhalb von Chains oder Agenten, um die Ausführung zu pausieren und menschliche Eingaben anzufordern. Dies unterstützt Überprüfung, Feedback oder manuelle Eingriffe an definierten Punkten im Workflow.
Als bevorzugte Quelle hinzufügenModel Context Protocol (MCP)-Integration in Agentic-AI-Frameworks
KI-Agenten müssen mit externen Tools wie Datenbanken, APIs, Dateisystemen und Geschäftsanwendungen interagieren. Ohne einen Standard musste jedes Framework benutzerdefinierte Integrationen für jedes Tool erstellen, was ein fragmentiertes Ökosystem schuf. MCP löst dies, indem es ein universelles Protokoll bereitstellt, das es jedem Agenten ermöglicht, sich über eine einzige Schnittstelle mit jedem Tool zu verbinden.
Wie jedes Framework sich mit MCP integriert
LangGraph
LangGraph verbindet sich mit MCP-Servern über einen Adapter, der automatisch verfügbare Tools erkennt und sie in ein LangChain-kompatibles Format konvertiert. Agenten können diese Tools dann nahtlos neben ihren nativen Fähigkeiten nutzen.
AutoGen
AutoGen bietet integrierte MCP-Integration über sein Erweiterungsmodul. Entwickler können sich mit MCP-Servern verbinden und alle ihre Tools für AutoGen-Agenten mit nur wenigen Codezeilen verfügbar machen.
CrewAI
CrewAI-Agenten können direkt auf MCP-Server in ihrer Konfiguration verweisen, indem sie einfache URLs oder strukturierte Einstellungen verwenden. Das Framework verwaltet den Verbindungslebenszyklus und das Fehlermanagement automatisch.
OpenAI Swarm
Swarm profitiert von der nativen MCP-Unterstützung von OpenAI im gesamten Ökosystem. Da OpenAI MCP in ChatGPT und sein Agents SDK integriert hat, kann Swarm diese Infrastruktur direkt nutzen.
LangChain
LangChain bietet MCP-Tool-Calling-Funktionen, bei denen Python-Funktionen als Brücken zu MCP-Servern dienen. Dies ermöglicht das Abrufen von Tools aus verschiedenen Quellen und deren Integration in Chains, Agenten und andere LangChain-Komponenten ohne benutzerdefinierte Wrapper.
Was Agentic-AI-Frameworks tatsächlich tun?
Agentic-AI-Frameworks unterstützen das Prompt-Engineering und die Verwaltung, wie Daten zu und von LLMs fließen. Auf einer grundlegenden Ebene helfen sie, Prompts zu strukturieren, damit das LLM in einem vorhersehbaren Format antwortet und Antworten an das richtige Tool, die richtige API oder das richtige Dokument weiterleitet.
Wenn man von Grund auf neu baut, würde man den Prompt manuell definieren, das Tool extrahieren, das das LLM verwenden möchte, und den entsprechenden API-Aufruf auslösen. Frameworks optimieren dies durch:
- Prompt-Orchestrierung: Erstellen, Verwalten und Weiterleiten komplexer Prompts an LLMs
- Tool-Integration: Agenten externe APIs, Datenbanken, Code-Funktionen usw. aufrufen lassen
- Speicher: Zustand über Züge oder Sitzungen hinweg aufrechterhalten (kurz- und langfristig)
- RAG-Integration: Wissensabruf aus externen Quellen ermöglichen
- Multi-Agenten-Koordination: Strukturieren, wie Agenten zusammenarbeiten oder Aufgaben delegieren
Agentic-AI-Frameworks: Anwendungsfälle aus der Praxis
LangGraph – Multi-Agenten-Reiseplaner
Ein mit LangGraph erstelltes Produktionsprojekt demonstriert einen zustandsbehafteten Multi-Agenten-Reiseassistenten, der Flug- und Hoteldaten abruft (unter Verwendung von Google Flights & Hotels APIs) und Reiseempfehlungen generiert.4
CrewAI – Agentischer Content-Ersteller
Das offizielle Beispiel-Repository von CrewAI enthält Abläufe wie Reiseplanung, Marketingstrategie, Aktienanalyse und Recruiting-Assistenten, bei denen rollenspezifische Agenten (z. B. „Researcher", „Writer") an Aufgaben zusammenarbeiten.5
CrewAI verwandelt ein hochrangiges Content-Briefing in einen vollständigen Artikel unter Verwendung von Groq.
Kernfunktionen von Agentic-AI-Frameworks
Modellunterstützung:
- Die meisten sind modellagnostisch und unterstützen mehrere LLM-Anbieter (z. B. OpenAI, Anthropic, Open-Source-Modelle).
- Allerdings variieren die System-Prompt-Strukturen je nach Framework und können mit einigen Modellen besser funktionieren als mit anderen.
- Zugang zu und Anpassung von System-Prompts ist oft entscheidend für optimale Ergebnisse.
Tooling:
- Alle Frameworks unterstützen Tool-Nutzung, einen Kernbestandteil zur Ermöglichung von Agentenaktionen.
- Bieten einfache Abstraktionen zur Definition benutzerdefinierter Tools.
- Die meisten unterstützen Model-Context-Protocol (MCP), entweder nativ oder durch Community-Erweiterungen.
Speicher / Zustand:
- Verwenden Zustandsverfolgung, um Kurzzeitspeicher über Schritte oder LLM-Aufrufe hinweg aufrechtzuerhalten.
- Einige helfen Agenten, frühere Interaktionen oder Kontext innerhalb einer Sitzung zu behalten.
RAG (Retrieval-Augmented Generation):
- Die meisten enthalten einfache Einrichtungsoptionen für RAG und integrieren Vektordatenbanken oder Dokumentenspeicher.
- Dies ermöglicht es Agenten, auf externes Wissen zu verweisen während der Ausführung.
Weitere gemeinsame Funktionen
- Unterstützung für asynchrone Ausführung, die gleichzeitige Agenten- oder Tool-Aufrufe ermöglicht.
- Integrierte Handhabung für strukturierte Ausgaben (z. B. JSON).
- Unterstützung für Streaming-Ausgaben, bei denen das Modell Ergebnisse inkrementell generiert.
- Grundlegende Observability-Funktionen für die Überwachung und das Debugging von Agentenläufen.
Benchmark-Methodik
1. Aufgabenstruktur
Aufgabe 1: Misst, ob ein einzelner Tool-Aufruf mit dem korrekten Parameter erfolgen kann. Der Basis-Infrastruktur-Overhead des Frameworks zeigt sich in diesem einfachen Szenario am deutlichsten.
Aufgabe 2: Erfordert das Halten der Ergebnisse zweier separater Filtergruppen im Speicher und deren Kombination zu einer einzigen Ausgabe. Zustandsverwaltung und Multi-Segment-Koordination werden getestet.
Aufgabe 3: Misst, ob numerische Bedingungen in natürlicher Sprache ohne Verzerrung in Tool-Parameter übersetzt werden. Der eigentliche Test besteht darin, ob die Wiederholungs- und Re-Prompt-Mechanismen des Frameworks diese Parameter bewahren können.
Aufgabe 4: Ein Tool wirft nacheinander Network-, Timeout- und RateLimit-Fehler. Es wird gemessen, ob das Framework angesichts dieser Fehler die Strategie ändert.
Aufgabe 5: Der Agent muss zuerst JSON- und LongText-Spalten erkennen und dann die richtigen Tools mit den richtigen Scope-Parametern aufrufen. Es wird beobachtet, ob das Framework unabhängige 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 Tools und dieselben Prompts. Jedes Framework wurde in seiner nativen Struktur eingerichtet: LangChain mit AgentExecutor, LangGraph mit StateGraph, AutoGen mit AssistantAgent + UserProxyAgent und CrewAI mit Agent + Task + Crew.
Der IBM Telco Customer Churn-Datensatz (7.032 Kunden) wurde verwendet. Der Tool-Zustand wurde vor jedem Durchlauf zurückgesetzt. 100 unabhängige Durchläufe wurden für jede Framework- und Aufgabenkombination ausgeführt.
Die maximalen Iterationsgrenzen wurden entsprechend der Aufgabenkomplexität festgelegt: 10 für die Aufgaben 1, 2 und 3; 20 für Aufgabe 4 aufgrund der fehleranfälligen Tool-Schleife; und 20 für Aufgabe 5 aufgrund der 4-stufigen Erkennungskette.
Zitieren Sie diesen Benchmark
Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Şipi, Nazlı},
title = {{Top 5 Open-Source-Agentic-AI-Frameworks}},
year = {2026},
month = mar,
howpublished = {\url{https://aimultiple.com/agentic-frameworks}},
note = {AIMultiple. Abgerufen am 30. März 2026}
}Referenzlinks
Kommentare 1
Teilen Sie Ihre Gedanken
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.
Thank you for this informative and detailed article! It helped me get a reading on these frameworks.