Top 5 Open-Source Agentic AI Frameworks
Wir haben 4 beliebte Open-Source-Agentic-Frameworks über 2.000 Läufe hinweg gebenchmarkt (5 Aufgaben, 100 Läufe pro Framework), wobei wir End-to-End-Latenz, Token-Verbrauch und architektonische Unterschiede gemessen haben.
Agentic AI Frameworks Benchmark
Wir haben untersucht, wie die Frameworks selbst das Verhalten des Agent beeinflussen und welche Auswirkungen dies auf Latenz und Token-Verbrauch hat.
LangGraph ist das schnellste Framework mit den niedrigsten Latenzwerten über alle Aufgaben, während LangChain die höchste Latenz und den höchsten Token-Verbrauch aufweist.
Über 5 Aufgaben und 2.000 Läufe hinweg erweist 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 finden die Methodik des Agentic-KI-Framework-Benchmarks für weitere Details zu den Aufgaben.
Aufgabe 1: Einfache Aggregation
Zunächst haben wir den Overhead jedes Frameworks gemessen, wenn ein einzelnes Tool aufgerufen und das Ergebnis zurückgegeben wird, ohne komplexe Schlussfolgerungen durchzuführen.
LangChain und LangGraph: Für einfache Aufgaben sind sie fast so schnell wie nicht-agentischer Code; beide werden in unter 5 Sekunden fertig und benötigen weniger als 900 Prompt-Tokens. Die Zustandsmaschinen-Architektur von LangGraph führt bei dieser Einfachheit im Vergleich zu LangChain zu keiner merklichen Latenz; der Overhead der Zustandsverwaltung tritt erst mit zunehmender Aufgabenkomplexität in Erscheinung.
AutoGen: Liegt in Bezug auf Latenz und Token-Verbrauch leicht über LangChain und LangGraph, was die Grundkosten seiner Multi-Agenten-Konversationsschleife widerspiegelt: zwei Agenten tauschen sogar bei einer einstufigen Aufgabe Nachrichten aus.
CrewAI: Selbst wenn es nur einen einzelnen Tool-Aufruf ausführen soll, zeigt es einen so genannten „Managerial Overhead“: Es verbraucht fast das Dreifache der Tokens von LangChain und benötigt fast dreimal so lange. 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 testen, zwei verschiedene Filtergruppen im Speicher zu halten (Zustandspersistenz) und zu kombinieren.
CrewAI
In unserer Log-Analyse haben wir festgestellt, dass CrewAI unter den Frameworks das höchste Maß an Infrastruktur-Transparenz bietet, jedoch auf Kosten des höchsten Ressourcenverbrauchs.
Statt die abgerufenen Daten sofort zurückzugeben, validiert CrewAI wiederholt seine eigenen Prozesse über einen Selbstüberprüfungsmechanismus. Dieses explorative Verhalten führte dazu, dass das konfigurierte Limit max_iter=10 erreicht wurde und einige Lä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 eine ReAct-artige Schleife aus Thought → Action → Observation bei jedem Schritt erzwingt. Selbst bei einfachen Aufgaben kann das LLM diese Zeremonie 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 mehr als dreimal so lange wie LangChain, was es besser für komplexe Zustandsübergänge und mehrfaktorielle Entscheidungsfindung geeignet macht als für einfache Datenabrufaufgaben.
LangChain
Das schnellste und kosteneffizienteste Framework. In unseren Logs haben wir beobachtet, dass LangChain die Aufgabe in 5–6 Schritten ohne Umwege abschließt: Laden → Filtern → Berechnen → Filtern → Berechnen → Ausgabe. Da seine Zustandsverwaltung sehr einfach ist, ist der Overhead nahezu null und die Latenz unter allen Frameworks am niedrigsten.
AutoGen
Lieferte eine sehr ausgewogene Leistung. In Aufgabe 2 entsprach es sowohl beim Token-Verbrauch als auch bei der Latenz fast exakt LangGraph, was zeigt, dass sich der Overhead der Konversationsschleife nicht wesentlich aufsummiert, wenn die Aufgabenkette linear bleibt.
Allerdings fügt es gelegentlich einen zusätzlichen Verifizierungsschritt hinzu, um Parameter während des Tool-Aufrufs zu bestätigen, was es etwas langsamer macht als LangChain. Wenn es bei einem Tool-Aufruf auf einen Fehler stößt oder die Daten nicht wie erwartet zurückkommen, aktualisiert es sofort seine Überlegungen im nächsten Schritt und gelangt zum korrekten JSON. Da es Tool-Ausgaben als Konversationsfluss verwaltet, ist es eines der robustesten Frameworks gegen logische Fehler.
LangGraph
In dieser Aufgabe ist LangGraph dank seiner graphbasierten Architektur das stabilste Framework. In seinen Logs haben wir beobachtet, dass der Zustand während des gesamten Laufs sehr sauber mitgeführt wird. Das Risiko von Datenkontamination oder gegenseitiger Beeinflussung von Segmenten ist bei diesem Framework am geringsten. Über alle 100 Lä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 an monatlichen Gebühren“ in präzise Tool-Parameter wie tenure_max=12 und charges_min=70.0 übersetzen.
Das LLM weiß, wie diese Umwandlung vorzunehmen ist; 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 und LangGraph
Beide Frameworks übergaben die Parameter (tenure_max=12, charges_min=70) direkt an das Tool, genau so, wie das LLM sie erzeugt hatte, ohne jegliche Modifikation oder Re-Prompt-Schleife. Diese Effizienz zeigt sich in den Zahlen: Beide Frameworks schlossen Aufgabe 3 in unter 9 Sekunden mit weniger als 1.800 Prompt-Tokens ab, dem niedrigsten Wert in dieser Aufgabe.
Als wir messen wollten, ob numerische Schwellenwerte ohne Eingreifen des Frameworks erhalten bleiben, erfüllten diese beiden unsere Erwartungen: Welcher Parameter auch immer generiert wurde, genau dieser wurde ausgeführt.
AutoGen
Autogen ist bei der numerischen Korrektheit vollständig erfolgreich. In einigen Läufen wurde beobachtet, dass das Framework einen Verifizierungsschritt hinzufügte, bevor der vom LLM generierte Parameter an das Tool übergeben wurde, was bedeutet, dass das Framework einen zusätzlichen Schritt aufwendete, während der Parameter erhalten blieb. 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, dem höchsten Wert in dieser Aufgabe. Aus der Log-Analyse ergaben sich zwei unterschiedliche Fehlermuster.
In einigen Läufen wurde ein Wert, der 68.81 % hätte sein sollen, als 0.6878 (Dezimalverhältnis) zurückgegeben. Dies deutet darauf hin, dass die Ausgabe-Serialisierung des Frameworks die Ausgabe des LLM aus ihrem ursprünglichen Kontext lösen kann.
Die Logs zeigen, dass das LLM zunächst die korrekten Parameter erzeugte: tenure_max=12 und charges_min=70. Sobald CrewAI jedoch in eine „Failed to parse“-Schleife geriet, 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 korrumpieren, den das LLM richtig ermittelt hatte.
Aufgabe 4: Fehlerresilienz und Pivot-Fähigkeit
In dieser Aufgabe wollten wir sehen, wie jedes Framework mit störenden Szenarien umgeht, und die Auswirkungen auf Latenz und Token-Verbrauch beobachten. Das Tool wirft nacheinander 3 verschiedene Fehlertypen (Netzwerk, 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, beginnt das Tool normal zu funktionieren.
LangGraph und Autogen
Diese beiden Frameworks fanden in dieser Aufgabe autonom alternative Lösungen, wenn sie mit Tool-Ausfällen konfrontiert wurden.
Als das Tool eine Rate-Limit-Warnung zurückgab, beschlossen diese Agenten, statt zu pausieren und zu warten, das fehlschlagende Tool vollständig aufzugeben und einen alternativen Weg zu finden. Ihr Ansatz lautete: „Da dieses Tool nicht funktioniert, filtere ich jede Zahlungsmethode einzeln, berechne die Abwanderungsrate für jede separat und kombiniere dann die Ergebnisse selbst.“
Methode: Statt die Aufgabe mit einem einzigen Tool-Aufruf zu erledigen, zerlegten 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 Denken statt Pfadabhängigkeit. Wenn der kürzeste Weg nicht verfügbar ist, können sie innerhalb von Sekunden einen alternativen Ausführungsplan erstellen.
LangGraph erreichte in Aufgabe 4 15.010 Prompt-Tokens, die höchste Einzelaufgaben-Tokenzahl im gesamten Benchmark, weil seine Zustandsmaschine die wachsende Historie jedes manuellen Tool-Aufrufs bei jedem Schritt zurück in den Kontext aufnahm. AutoGen folgte mit 10.750 Tokens, etwas eingedämmter aufgrund seiner konversationellen Behandlung von Zwischenergebnissen. Trotzdem wurden beide in etwa 24–27 Sekunden fertig, was bestätigt, dass die zusätzlichen Token-Kosten keine nennenswerte Latenz verursachten, weil der Pivot selbst schnell war.
CrewAI
Obwohl CrewAI in früheren Aufgaben den höchsten Token-Verbrauch aufwies, zeigte es in dieser Aufgabe den niedrigsten Token-Verbrauch), aber die höchsten Latenzwerte.
Warum der niedrigste Token-Verbrauch?
CrewAI durchlief keinen 10–15-schrittigen manuellen Workaround wie seine Konkurrenten. Wenn es auf Fehler stieß, baute es, statt bei jedem Schritt die gesamte Historie und komplexe Zwischendaten wieder in das LLM zu pumpen, eine fokussiertere, modulare Argumentationsschleife auf. Durch die Vermeidung unnötiger Ausführlichkeit wurde es in dieser Aufgabe zum kosteneffizientesten Framework.
Warum hohe Latenz?
CrewAIs manageriale Struktur pausiert und bewertet den Plan neu, wenn sie auf einen Fehler stößt. Als sie die Warnung erhielt, 10 Sekunden zu warten, verbrachte sie mehr Zeit in der „Strategieplanungs“-Phase. Darüber hinaus entschied sie sich, statt für die Filterung auf ein anderes Tool umzusteigen, beharrlich dafür, zu warten, bis 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 Lauf stürzte LangChain bei jedem einzelnen Versuch mit einem ConnectionError ab.
Der standardmäßige AgentExecutor von LangChain behandelt rohe Python-Ausnahmen, die aus einem Tool geworfen werden, als fatale Fehler und beendet den Prozess. Im Gegensatz zu seinen 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 haben den Tool-Aufruf in langchain_agent.py mit einem try-except-Block umschlossen. Dadurch wurde der Fehler in eine lesbare Nachricht umgewandelt, die der Agent verarbeiten konnte.
Verhalten nach dem Fix: Nachdem wir den Fix angewendet hatten, beobachteten wir in den Logs von LangChain, dass es exakt dieselbe Argumentation wie LangGraph zeigte. Es erhielt 3 Fehler vom Tool, wechselte sofort die Strategie und ging dazu über, zwei separate Tools zu verwenden – 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, aber weil die Fehlerbehandlung des Frameworks standardmäßig deaktiviert war, hatte es keine Gelegenheit, diese Fähigkeit zu demonstrieren. Nachdem es richtig konfiguriert war, gelangte es mit demselben alternativen Pfadansatz zum korrekten Ergebnis.
Warum sind diese Unterschiede aufgetreten? (Analyse der Framework-Architektur)
Wenn das Agentenverhalten ausschließlich vom LLM (GPT-5.2) abhinge, hätten sich alle Frameworks ähnlich verhalten sollen. Die klaren Unterschiede in diesen Verhältnissen liegen jedoch in den eigenen inneren Schleifenmechanismen der Frameworks begründet:
1. LangGraph und AutoGen (90 % Pivot):
LangGraph arbeitet mit einer Zustandsmaschinen-Architektur, während AutoGen auf einem konversationsbasierten Modell basiert. In beiden Systemen werden Fehler als Rückkopplungsschleife verarbeitet. In LangGraph wird der Zustand, der den Fehler empfängt, an den nächsten Knoten weitergegeben; 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. Da der Agent immer wieder mit der Frage „Ich habe einen Fehler erhalten, was soll ich tun?“ konfrontiert wird, steigt die Wahrscheinlichkeit, dass er sich für einen alternativen manuellen Weg 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 eher lineare Struktur und ist hauptsächlich darauf ausgerichtet, eine endgültige Antwort zu erzeugen. Wenn das Tool 3–4 Schritte lang Fehler wirft, zieht es LangChain manchmal vor, auf einen Erfolg des Tools beim nächsten Versuch zu warten oder ein Ergebnis aus dem vorhandenen Kontext zu erzeugen, statt auf eine alternative Strategie umzuschwenken. Da die Zustandssperre von LangChain flexibler ist als die von LangGraph, liegt sein Verhältnis von Warten/direkter Lösung bei etwa 35 %.
3. CrewAI (0 % Pivot):
CrewAI arbeitet mit einer Managerial-Process-Architektur. Seine Agenten sind in Rollen- und Aufgabendefinitionen eingebettet. Wenn Fehler auftreten, löst seine interne Architektur typischerweise Selbstkorrektur- oder Wiederholungslogik aus. Ein radikaler Strategiewechsel wie „Lass uns den gesamten Plan verwerfen und manuelles Filtern in 5 Schritten durchführen“ steht jedoch im Konflikt mit CrewAIs managerieller Planstruktur. Es arbeitet mit der Disziplin „Ich sollte das mir gegebene Tool reparieren oder die nächstliegende Alternative verwenden“, statt seinen Plan ganz aufzugeben. Dies ist grundsätzlich ein planzentrierter Ansatz im Gegensatz zu einem zielzentrierten.
Aufgabe 5: Orchestrierung unstrukturierter Daten (Routing unstrukturierter Daten)
In Aufgabe 5 haben wir beobachtet, wie sich die Frameworks verhalten, wenn sie in einer CSV auf JSON- und Langtext-Spalten (LongText) 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 die Verwaltung unstrukturierter Daten, dass ein Agent über standardmäßige tabellarische Daten hinausgeht und mit JSON-Blobs, kostenlos-Text-Absätzen oder verschachtelten Objekten arbeitet.
Damit ein Framework diese Art von Daten korrekt verarbeiten kann, muss es zwei Dinge gut beherrschen:
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 entwickelt, um diese beiden Fähigkeiten getrennt zu messen.
AutoGen
AutoGen lieferte in dieser Aufgabe eine starke Leistung ab: Es erreichte 8.170 Prompt-Tokens und eine mittlere Latenz von 47 Sekunden – das schnellste und token-effizienteste Ergebnis in Aufgabe 5.
Die Konversationsschleife im Kern seiner Architektur – der Nachrichtenaustausch 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-Durchgängen mit den wenigsten Tokens und den wenigsten Schritten abschließen.
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 „Verwalte-die-Konversation“-Philosophie des Frameworks erlaubt es auf natürliche Weise, mehrere parallele Kanäle gleichzeitig zu öffnen, und die Token- und Latenzzahlen bestätigen dies direkt.
LangGraph
LangGraph erreichte 9.150 Prompt-Tokens und eine mediane Latenz von 70 Sekunden – bei den Tokens nahe an AutoGen, aber langsamer in der Zeit. Seine Zustandsmaschinen-Architektur zeigte in Aufgabe 5 gleichzeitig ihre größte Stärke und ihre auffälligste Schwäche.
In jedem Lauf akkumuliert die Schleife aus LLM-Knoten → Tools-Knoten → LLM-Knoten alle vorherigen Tool-Ausgaben im Zustand und übergibt sie an das LLM. Diese Struktur garantiert, dass der Agent nie etwas vergisst, was normalerweise ein erheblicher Vorteil ist.
In Aufgabe 5 wirkte diese Stärke jedoch gegen LangGraph. Es fand die richtigen Tools und baute das richtige Segment auf. Doch selbst nach Abschluss der Analyse erkannte es Mehrdeutigkeiten im akkumulierten 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 geben, sprang das „Fehlender Schritt“-Signal der Zustandsmaschine an und der Agent geriet in unnötige Schleifen. Infolgedessen lag die Anzahl der Tool-Aufrufe pro Lauf zwischen 6 und 16. Die Stärke des Zustands, „nie etwas zu vergessen“, ließ abgeschlossene Schritte manchmal als unvollständig erscheinen, zog den Agenten zurück in redundante Zyklen und erhöhte die Latenz um 23 Sekunden gegenüber AutoGen, trotz vergleichbarer Token-Zahl.
CrewAI
CrewAIs Leistung in Aufgabe 5 erzeugte die höchste Varianz im gesamten Benchmark. In einigen Läufen folgte es einer fehlerlosen Sequenz mit 5 Tool-Aufrufen, ohne Umwege, und führte sie wie ein Skript aus. In diesen Läufen funktionierte CrewAIs durch Rollen und Aufgaben definierte manageriale Struktur genau wie beabsichtigt: Wenn der Agent seine Rolle klar verstand, verhielt er sich vorhersehbar und diszipliniert.
In anderen Läufen (z. B. Lauf 16: 35 Tool-Aufrufe) brach jedoch völliges Chaos aus. Die Ursache war der innere Monolog (Thought), den CrewAI bei jedem Schritt erzeugt. Nachdem das Segment mit dem richtigen Filter korrekt aufgebaut worden war, begann der innere Monolog des Agenten zu hinterfragen, ob nicht 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 achtmal.
In CrewAI erzeugt jeder Thought eine unabhängige Bewertung, und diese Bewertungen machen gelegentlich zuvor verifizierte Schritte ungültig. Der „kontinuierliche Verifizierungs“-Reflex des Managerial Process drängte den Agenten in einigen Läufen dazu, seine eigenen richtigen Entscheidungen erneut in Frage zu stellen.
LangChain
Die AgentExecutor-Struktur von LangChain ist von Natur aus sequenziell, und Aufgabe 5 ist der Punkt, an dem diese Einschränkung am deutlichsten sichtbar wurde. Mit 10.070 Prompt-Tokens und einer medianen Latenz von 86 Sekunden war es das langsamste Framework in dieser Aufgabe, obwohl es nicht die höchste Token-Zahl hatte.
Es führt bei jedem Schritt einen einzigen Tool-Aufruf aus, erhält das Ergebnis und macht dann weiter, was bedeutet, dass 4 unabhängige Tools 4 separate LLM-Durchgänge mit 4 separaten Wartezeiten erforderten. Der Median von 47 Sekunden bei AutoGen gegenüber 86 Sekunden bei 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 bei 15 ein. Diese beiden Cluster verweisen auf zwei typische Strategien: In einigen Läufen übersprang es den Inspektionsschritt und ging direkt zum Parsen und Zusammenfassen über (9 Tools), während es in anderen zuerst jede Spalte inspizierte, bevor es sie verarbeitete (15 Tools). Die Identität des linearen Executors von LangChain wurde hier deutlich: Es zeigte weder die parallele Effizienz von AutoGen noch das Monolog-Chaos von CrewAI.
Verwaltung 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 parallele Tool-Aufrufe unterstützen (AutoGen), können unabhängige Datenspalten in einem einzigen Schritt verarbeiten. In realen Szenarien mit großen JSON-Objekten und zahlreichen Textspalten bedeutet dieser Unterschied einen massiven Kosten- und Geschwindigkeitsvorteil.
Frameworks mit zustandsgesteuerten Schleifen (LangGraph) zeichnen sich durch Datenkonsistenz aus, tragen aber das Risiko, dass abgeschlossene Schritte, die sich in der Historie angesammelt haben, erneut bewertet werden.
Monologbasierte Frameworks (CrewAI) sind sehr gut in der Lage, Typ und Bedeutung von Daten zu verstehen, aber diese Tiefe schlägt manchmal in übermäßiges Hinterfragen und Schleifen um.
Frameworks mit linearer Ausführung (LangChain) verarbeiten verschiedene Zweige unstrukturierter Daten getrennt und erzeugen so ein Mittelding aus beiden Welten.
GitHub Sternwachstum von Agentic-Frameworks
Agentic AI Frameworks vergleichen
Agentic-KI-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 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 sticht als wichtige Option für Entwickler hervor, 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. Daher eignet es sich gut für RAG und benutzerdefinierte Pipelines.
AutoGen
AutoGen ermöglicht es mehreren Agenten, durch das Weitergeben von Nachrichten in einer Schleife zu kommunizieren. Jeder Agent kann auf der Grundlage seiner internen Logik antworten, reflektieren oder Tools aufrufen.
Es verfügt über eine asynchrone Agentenkollaboration, was es besonders nützlich für Forschungs- und Prototyping-Szenarien macht, in denen das Verhalten von Agenten Experimentieren oder iterative Verfeinerung erfordert.
CrewAI
CrewAI übernimmt den größten Teil der Low-Level-Logik für Sie und bietet Multi-Agenten-Orchestrierung:
- Integriert sich in Überwachungstools für Tracing und Debugging
- Eingebaute Ausführungssteuerung 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 das Prototyping. Agenten arbeiten sequenziell durch Übergaben und übertragen Aufgaben, während der gemeinsame Kontext beibehalten wird. Es verwendet natürlichsprachliche Routinen und Python-Tools für flexible Workflows.
LangChain
LangChain ist ein Framework zum Erstellen von Einzelagenten-LLM-Anwendungen mit RAG-Tooling. Es bietet modulare Komponenten wie Chains, Tools, Speicher und Retrieval für Dokumentverarbeitungs-Workflows.
LangChain arbeitet hauptsächlich nach Einzelagenten-Ausführungsmustern, bei denen ein Agent den Workflow verwaltet.
Agenten- und Funktionsdefinition
LangGraph
LangGraph verfolgt einen graphbasierten Ansatz beim Agentendesign, bei dem jeder Agent als Knoten dargestellt wird, der seinen eigenen Zustand beibehält. Diese Knoten sind durch einen gerichteten Graphen verbunden, was bedingte Logik, Multi-Team-Koordination und hierarchische Steuerung ermöglicht. Dadurch können Sie Multi-Agenten-Graphen mit Supervisor-Knoten für skalierbare Orchestrierung bauen und visualisieren.
LangGraph verwendet annotierte, strukturierte Funktionen, die Tools an Agenten anbinden. Sie können Knoten ausbauen, sie mit verschiedenen Supervisoren verbinden und visualisieren, wie verschiedene Teams interagieren. Stellen Sie es sich so vor, als ob 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 flexibles Routing und asynchrone Kommunikation ermöglichen. Agenten interagieren miteinander (und optional mit Menschen), indem sie Nachrichten austauschen, 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 über strukturierte Annotationen.
OpenAI Swarm
OpenAI Swarm verwendet ein routinenbasiertes Modell, bei dem Agenten durch Prompts und Funktions-Docstrings definiert werden. Es verfügt über keine formale Orchestrierung oder Zustandsmodelle, sondern stützt sich auf manuell strukturierte Workflows. Das Verhalten von Funktionen 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 chainbasierte Architektur, bei der ein einzelner Orchestrator-Agent die Aufrufe an Sprachmodelle und verschiedene Tools verwaltet. Es definiert Funktionen über explizite Schnittstellen wie Toolkits und Prompt-Vorlagen.
Obwohl es hauptsächlich auf zentralisierte Workflows ausgerichtet ist, unterstützt LangChain Erweiterungen für Multi-Agenten-Setups, verfügt jedoch über keine eingebaute Agent-zu-Agent-Kommunikation.
Speicher
Speicherfähigkeiten:
- Zustandsbehaftet: Ob das Framework persistenten Speicher über Ausführungen hinweg unterstützt.
- Kontextuell: Ob es Kurzzeitgedächtnis über Nachrichtenverlauf oder Kontextübergabe unterstützt.
Speichermerkmale sind ein wichtiger Bestandteil beim Aufbau agentischer Systeme, um sich Kontext zu merken und sich im Laufe der Zeit anzupassen:
- Kurzzeitgedächtnis: Behält den Überblick über aktuelle Interaktionen und ermöglicht es Agenten, mehrstufige Konversationen oder Schritt-für-Schritt-Workflows zu verarbeiten.
- Langzeitgedächtnis: Speichert persistente Informationen über Sitzungen hinweg, wie z. B. Benutzerpräferenzen oder Aufgabenverlauf.
- Entitätsgedächtnis: Verfolgt und aktualisiert Wissen über bestimmte Objekte, Personen oder Konzepte, die während der Interaktionen erwähnt werden (z. B. das Erinnern eines zuvor genannten Firmennamens oder einer Projekt-ID).
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 sichert. Entwickler können MemorySaver verwenden, um den Ablauf einer Aufgabe zu speichern und mit einem 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 der Speicher über Ausführungen hinweg begrenzt und beibehalten wird.
AutoGen
AutoGen verwendet ein kontextuelles Speichermodell. Jeder Agent hält Kurzzeitkontext über ein context_variables-Objekt aufrecht, das den Interaktionsverlauf speichert. Es verfügt über keinen eingebauten persistenten Speicher.
CrewAI
CrewAI bietet gestaffelten Speicher ab Werk. Es speichert das Kurzzeitgedächtnis in einem ChromaDB-Vektor-Speicher, aktuelle Aufgabenergebnisse in SQLite und das Langzeitgedächtnis in einer separaten SQLite-Tabelle (basierend auf Aufgabenbeschreibungen). Darüber hinaus unterstützt es Entitätsgedächtnis mithilfe von Vektor-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 Kurzzeitgedächtnis manuell über context_variables übergeben und optional externe Tools oder Speicherebenen von Drittanbietern (z. B. mem0) integrieren, um langfristigeren Kontext 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 Konversationsverlauf innerhalb einer Sitzung verfolgen. Für das Langzeitgedächtnis integriert sich LangChain mit externen Vektor-Speichern oder Datenbanken, um Embeddings und Retrieval-Daten zu persistieren.
Entwickler können Speicherbereiche und -strategien mithilfe eingebauter Speicherklassen anpassen, was eine effiziente Verwaltung von kontextuellem und entitätsspezifischem Gedächtnis ü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, sodass Menschen während der Agentenkollaboration Schritte überprüfen, genehmigen oder ändern können.
CrewAI:
CrewAI ermöglicht Feedback nach jeder Aufgabe durch Setzen von human_input=True; der Agent pausiert, um natürliche Spracheingaben vom Benutzer zu sammeln.
OpenAI Swarm
OpenAI Swarm bietet kein eingebautes HITL.
LangChain
LangChain ermöglicht 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 manuelles Eingreifen an definierten Punkten im Workflow.
Model Context Protocol (MCP) Integration in Agentic-KI-Frameworks
KI-Agenten müssen mit externen Tools wie Datenbanken, APIs, Dateisystemen und Geschäftsanwendungen interagieren. Ohne einen Standard musste jedes Framework für jedes Tool benutzerdefinierte Integrationen erstellen, was ein fragmentiertes Ökosystem schuf. MCP löst dieses Problem, indem es ein universelles Protokoll bereitstellt, das es jedem Agenten ermöglicht, über eine einzige Schnittstelle mit jedem Tool zu verbinden.
Wie jedes Framework mit MCP integriert
LangGraph
LangGraph verbindet sich über einen Adapter mit MCP-Servern, der automatisch verfügbare Tools erkennt und sie in ein mit LangChain kompatibles Format umwandelt. Agenten können diese Tools dann nahtlos neben ihren nativen Fähigkeiten nutzen.
AutoGen
AutoGen bietet eine eingebaute MCP-Integration über sein Erweiterungsmodul. Entwickler können sich mit MCP-Servern verbinden und alle ihre Tools mit nur wenigen Codezeilen für AutoGen-Agenten verfügbar machen.
CrewAI
CrewAI-Agenten können in ihrer Konfiguration direkt auf MCP-Server verweisen, indem sie einfache URLs oder strukturierte Einstellungen verwenden. Das Framework übernimmt die Verwaltung des Verbindungslebenszyklus und des Fehlermanagements automatisch.
OpenAI Swarm
Swarm profitiert von der nativen MCP-Unterstützung von OpenAI in seinem 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-Fähigkeiten, 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.
Als bevorzugte Quelle hinzufügenWas tun Agentic-KI-Frameworks eigentlich?
Agentic-KI-Frameworks unterstützen beim Prompt-Engineering und bei der 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 leiten Antworten an das richtige Tool, die richtige API oder das richtige Dokument weiter.
Wenn man von Grund auf neu bauen würde, müsste man den Prompt manuell definieren, das Tool extrahieren, das LLM verwenden möchte, und den entsprechenden API-Aufruf auslösen. Frameworks rationalisieren dies, indem sie:
- Prompt-Orchestrierung: Erstellen, Verwalten und Routing komplexer Prompts an LLMs
- Tool-Integration: Agenten externe APIs, Datenbanken, Code-Funktionen usw. aufrufen lassen
- Speicher: Zustand über Runden oder Sitzungen hinweg aufrechterhalten (kurz- und langfristig)
- RAG-Integration: Aktivierung des Wissensabrufs aus externen Quellen
- Multi-Agenten-Koordination: Strukturierung, wie Agenten zusammenarbeiten oder Aufgaben delegieren
Agentic-KI-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 der Google Flights & Hotels APIs) und Reiseempfehlungen generiert.3
CrewAI – Agentischer Content-Ersteller
Das offizielle Beispiel-Repository von CrewAI enthält Flows wie Reiseplanung, Marketingstrategie, Aktienanalyse und Rekrutierungsassistenten, bei denen rollenspezifische Agenten (z. B. „Researcher“, „Writer“) an Aufgaben zusammenarbeiten.4
CrewAI verwandelt ein übergeordnetes Content-Briefing mithilfe von Groq in einen vollständigen Artikel.
Kernfunktionen von Agentic-KI-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 funktionieren mit einigen Modellen möglicherweise besser als mit anderen.
- Zugriff auf und Anpassung von System-Prompts ist oft für optimale Ergebnisse unerlässlich.
Tooling:
- Alle Frameworks unterstützen Tool-Nutzung, einen Kernbestandteil, um Agentenaktionen zu ermöglichen.
- Bieten einfache Abstraktionen zum Definieren benutzerdefinierter Tools.
- Die meisten unterstützen Model-Context-Protocol (MCP), entweder nativ oder durch Community-Erweiterungen.
Speicher / Zustand:
- Verwenden Zustandsverfolgung, um das Kurzzeitgedächtnis über Schritte oder LLM-Aufrufe hinweg aufrechtzuerhalten.
- Einige helfen Agenten, frühere Interaktionen oder Kontexte innerhalb einer Sitzung beizubehalten.
RAG (Abrufgestützte Generierung):
- Die meisten enthalten einfache Einrichtungsoptionen für RAG, die Vektordatenbanken oder Dokumentspeicher integrieren.
- Dies ermöglicht es Agenten, während der Ausführung auf externes Wissen zu verweisen.
Weitere gemeinsame Funktionen
- Unterstützung für asynchrone Ausführung, die gleichzeitige Agenten- oder Tool-Aufrufe ermöglicht.
- Eingebaute Behandlung strukturierter Ausgaben (z. B. JSON).
- Unterstützung für Streaming-Ausgaben, bei denen das Modell Ergebnisse inkrementell erzeugt.
- Grundlegende Observability-Funktionen zur Überwachung und Fehlerbehebung von Agentenläufen.
Benchmark-Methodik
1. Aufgabenstruktur
Aufgabe 1: Misst, ob ein einzelner Tool-Aufruf mit dem korrekten Parameter durchgeführt werden kann. Der Basis-Infrastruktur-Overhead des Frameworks zeigt sich in diesem einfachen Szenario am deutlichsten.
Aufgabe 2: Erfordert das Halten der Ergebnisse zweier getrennter Filtergruppen im Speicher und deren Kombination zu einer einzigen Ausgabe. Zustandsverwaltung und Mehrsegment-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 Netzwerk-, Timeout- und RateLimit-Fehler. Gemessen wird, ob das Framework angesichts dieser Fehler seine Strategie ändert.
Aufgabe 5: Der Agent muss zunächst JSON- und LongText-Spalten erkennen und dann die richtigen Tools mit den korrekten Scope-Parametern aufrufen. Beobachtet wird, ob das Framework unabhängige Tools parallel oder sequenziell ausführt.
Wie eine Aufgabe tatsächlich aussieht
Um das Setup konkret zu machen, hier ist Aufgabe 5, die komplexeste Aufgabe im Benchmark der Agentic-KI-Frameworks. Jedes Framework erhielt denselben Prompt und denselben Satz an Tools; nur das Framework, das LLM umgibt, änderte sich.
An den Agenten übergebener Prompt:
Analysieren Sie abgewanderte Kunden (Churn=’Ja’), die mehr als 100 an MonthlyCharges zahlen.
- Filtern Sie den Datensatz auf Churn=’Ja’.
- Untersuchen Sie die Spalten ‘Metadata’ und ‘SupportNotes’, um ihre Datentypen zu ermitteln.
- Extrahieren Sie die ‘device_type’-Verteilung aus der JSON-Spalte ‘Metadata’.
- Zählen Sie Beschwerde-Schlüsselwörter aus der kostenlos-Text-Spalte ‘SupportNotes’.
Geben Sie das Ergebnis nur als JSON zurück.
Erforderliche JSON-Ausgabe:
Warum diese Aufgabe zwischen Frameworks unterscheidet: Der Agent muss eine Kette von vier Tool-Aufrufen planen, das gefilterte Segment über jeden Aufruf hinweg im Zustand halten und erkennen, dass eine Spalte JSON und die andere kostenlos-Text ist. Ein Framework, das die unabhängigen Spalten parallel ausführt (AutoGen), ist viel schneller fertig als eines, das sie sequenziell ausführt (LangChain), und ein Framework, das abgeschlossene Schritte erneut bewertet (LangGraph, CrewAI), läuft unnötig in Schleifen. Das strikte JSON-Schema ermöglicht es uns, die Korrektheit automatisch zu bewerten.
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 Lauf zurückgesetzt. Für jede Framework-Aufgaben-Kombination wurden 100 unabhängige Läufe durchgeführt.
Die maximalen Iterationslimits wurden entsprechend der Aufgabenkomplexität festgelegt: 10 für die Aufgaben 1, 2 und 3; 20 für Aufgabe 4 aufgrund der unzuverlässigen 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 = aug,
howpublished = {\url{https://aimultiple.com/agentic-frameworks}},
note = {AIMultiple. Abgerufen am 10. August 2026}
}Ergebnisse und Zeitstempel von 25 Datenpunkten. Laden Sie die in diesem Artikel verwendeten Daten als ZIP-Datei herunter, die 5 CSV-Dateien enthält.
Referenzlinks
Cems Arbeit wurde von führenden globalen Publikationen zitiert, darunter Business Insider, Forbes, Washington Post, globalen Unternehmen wie Deloitte, HPE und NGOs wie dem World Economic Forum sowie supranationalen Organisationen wie der European Commission.
Während seiner Karriere war Cem als Tech-Berater, Tech-Einkäufer und Tech-Unternehmer tätig. Er beriet Unternehmen über ein Jahrzehnt lang bei McKinsey & Company und Altman Solon in Technologieentscheidungen. Er veröffentlichte auch einen McKinsey-Bericht zur Digitalisierung.
Er leitete die Technologiestrategie und Beschaffung eines Telekommunikationsunternehmens und berichtete dabei direkt an den CEO. Zudem führte er das kommerzielle Wachstum des Deep-Tech-Unternehmens Hypatos an, das innerhalb von 2 Jahren von null auf einen siebenstelligen jährlich wiederkehrenden Umsatz und eine neunstellige Bewertung anwuchs. Cems Arbeit bei Hypatos wurde von führenden Technologiepublikationen wie TechCrunch und Business Insider aufgegriffen.
Cem spricht regelmäßig auf internationalen Technologiekonferenzen. Er schloss sein Studium an der Bogazici University als Computer-Ingenieur ab und hat einen MBA von der Columbia Business School.
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.