Top 5 Open-Source-Frameworks für agentische KI
Wir haben 4 beliebte Open-Source-Agentic-Frameworks in über 2.000 Durchläufen (5 Aufgaben, 100 Durchläufe pro Framework) einem Benchmarking unterzogen und die End-to-End-Latenz, den Token-Verbrauch und architektonische Unterschiede gemessen.
Benchmark agentischer KI-Frameworks
Wir haben untersucht, wie die Frameworks selbst das Verhalten von Agenten beeinflussen und welche Auswirkungen dies auf Latenz und Token-Verbrauch 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 Token-Verbrauch aufweist.
Über 5 Aufgaben und 2.000 Durchläufe hinweg erweist sich LangChain als das token-effizienteste Framework, während AutoGen bei der Latenz führt; LangGraph und LangChain folgen dicht dahinter. CrewAI weist das insgesamt schwerste Profil auf.
Weitere Details zu den Aufgaben finden Sie in der Benchmark-Methodik für agentische KI-Frameworks.
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 logische Schlussfolgerungen durchzuführen.
LangChain & LangGraph: Bei einfachen Aufgaben sind sie fast so schnell wie nicht-agentischer Code und schließen beide in unter 5 Sekunden mit weniger als 900 Prompt-Tokens ab. Die Zustandsmaschinen-Architektur von LangGraph verursacht auf dieser Einfachheitsebene im Vergleich zu LangChain keine spürbare Latenz; der Overhead der Zustandsverwaltung tritt mit zunehmender Aufgabenkomplexität zutage.
AutoGen: Liegt sowohl bei Latenz als auch Token-Verbrauch leicht über LangChain und LangGraph, was den Grundaufwand seines Multi-Agenten-Gesprächsloops widerspiegelt – zwei Agenten, die sogar für eine einstufige Aufgabe Nachrichten austauschen.
CrewAI: Selbst bei einer einzigen Tool-Anforderung zeigt es, was man als „Management-Overhead“ bezeichnen könnte, 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 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 Infrastruktur-Transparenz 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 das Limit max_iter=10 erreicht wurde, sodass einige Durchläufe in einer endlosen Denkschleife stecken blieben, ohne eine JSON-Ausgabe zu erzeugen.
Die Ursache dieses Verhaltens liegt darin, dass CrewAI mehrschichtige Anweisungen in den System-Prompt einfügt, jedem Agenten eine Rolle, ein Ziel und eine Hintergrundgeschichte zuweist und gleichzeitig einen ReAct-artigen Thought → Action → Observation-Loop bei jedem Schritt erzwingt. Selbst bei einfachen Aufgaben kann das LLM diese Zeremonie nicht überspringen und produziert pflichtbewusst ausführliche innere Monologe, die sich in Multi-Agenten-Szenarien weiter verstärken.
CrewAI verbrauchte fast doppelt so viele Tokens wie die anderen Frameworks und benötigte über dreimal so lange wie LangChain, was es besser für komplexe Zustandsübergänge und multifaktorielle Entscheidungsfindung geeignet macht als für einfache Datenabrufaufgaben.
LangChain
Das schnellste und kosteneffizienteste Framework. In unseren Logs beobachteten wir, dass LangChain die Aufgabe in 5–6 Schritten ohne Umwege abschließt: Laden → Filtern → Berechnen → Filtern → Berechnen → Ausgabe. Da die 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 LangGraph nahezu exakt sowohl im Token-Verbrauch als auch in der Latenz und zeigte, dass der Overhead des Gesprächsloops bei linearen Aufgabenketten nicht signifikant ansteigt.
Es fügt jedoch gelegentlich einen zusätzlichen Verifizierungsschritt ein, um Parameter während des Tool-Aufrufs zu bestätigen, wodurch es etwas langsamer als LangChain wird. Wenn ein Fehler bei einem Tool-Aufruf auftritt oder die Daten nicht wie erwartet zurückkommen, aktualisiert es sofort seine Schlussfolgerung im nächsten Schritt und gelangt zum korrekten JSON. Da es Tool-Ausgaben als Gesprächsfluss verwaltet, ist es eines der widerstandsfähigsten Frameworks gegenüber logischen Fehlern.
LangGraph
In dieser Aufgabe ist LangGraph dank seiner graphbasierten Architektur das stabilste Framework. In seinen Logs beobachteten wir, dass der Zustand während des gesamten Durchlaufs sehr sauber übertragen wird. Das Risiko von Datenkontamination oder sich gegenseitig störenden Segmenten ist in diesem Framework am geringsten. In allen 100 Durchläufen erzeugte es Ergebnisse in nahezu derselben Anzahl von Schritten und innerhalb derselben Latenzspanne.
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 vorzunehmen hat; was wir wirklich testen wollten, war, ob das Framework diese Parameter in seinen eigenen Wiederholungsmechanismen, Re-Prompt-Kontexten und Zustandszyklen schützen kann.
LangChain & LangGraph
Beide Frameworks übergaben die Parameter (tenure_max=12, charges_min=70) direkt an das Tool, genau wie sie vom LLM erzeugt wurden, 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, dem niedrigsten Wert in dieser Aufgabe.
Als wir messen wollten, ob numerische Schwellenwerte ohne Eingriff des Frameworks erhalten bleiben, erfüllten diese beiden unsere Erwartungen: Welcher Parameter auch immer generiert wurde, genau dieser wurde ausgeführt.
AutoGen
AutoGen ist vollständig erfolgreich in numerischer Korrektheit. In einigen Durchläufen wurde beobachtet, dass das Framework einen Verifizierungsschritt hinzufügte, bevor es den LLM-generierten Parameter an das Tool übergab, was bedeutet, dass das Framework einen zusätzlichen Schritt durchlief, während der Parameter erhalten blieb. Mit 2.480 Tokens und 8 Sekunden erreichte es trotz des zusätzlichen Schritts die Latenz von LangChain, was bestätigt, dass der Verifizierungs-Overhead real, aber gering ist. Es erfüllte unsere Erwartungen hinsichtlich der Parameterintegrität, wobei der Bestätigungsschritt marginale Token-Kosten verursachte, aber keine nennenswerte Latenzstrafe.
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 verschiedene Fehlermuster.
In einigen Durchläufen wurde ein Wert, der 68.81 % hätte sein 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 entfernen kann.
Die Logs zeigen, dass das LLM zunächst die korrekten Parameter tenure_max=12 und charges_min=70 erzeugte. Sobald CrewAI jedoch in eine „Failed to parse“-Schleife eintrat, drängte das Framework das LLM zur Neubewertung. 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 – tatsächlich die Abwanderungsrate aller Kunden mit einer Betriebszugehörigkeit von weniger als 14. Genau dieses Szenario wollten wir beobachten: Der Wiederholungsmechanismus des Frameworks kann einen Parameter korrumpieren, den das LLM richtig 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 drei verschiedene Fehlertypen (Network, Timeout, Rate Limit), die den Agenten in die Enge treiben. Die ersten beiden Fehler weisen den Agenten an, es erneut zu versuchen. 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 autonom alternative Lösungen, als sie in dieser Aufgabe mit Tool-Ausfällen konfrontiert wurden.
Als das Tool eine Rate-Limit-Warnung zurückgab, entschieden diese Agenten, statt zu pausieren und zu warten, das fehlerhafte Tool ganz aufzugeben und einen alternativen Weg zu finden. 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 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 mit 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 den wachsenden Verlauf jedes manuellen Tool-Aufrufs bei jedem Schritt wieder in den Kontext aufnahm. AutoGen folgte mit 10.750 Tokens, etwas begrenzter aufgrund seiner konversationellen Behandlung von Zwischenergebnissen. Trotzdem beendeten beide um die 24–27 Sekunden, was bestätigt, dass die zusätzlichen Token-Kosten nicht in eine nennenswerte Latenz umgesetzt wurden, 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 der niedrigste Token-Verbrauch?
CrewAI durchlief keinen 10-bis-15-schrittigen manuellen Workaround wie seine Wettbewerber. Als es auf Fehler stieß, pumpte es nicht wiederholt die gesamte Historie und komplexe Zwischendaten bei jedem Schritt zurück in das LLM, sondern baute einen fokussierteren, modularen Denk-Loop auf. Durch die Vermeidung unnötiger Ausführlichkeit wurde es das kosteneffizienteste Framework in dieser Aufgabe.
Warum hohe Latenz?
CrewAIs Management-Struktur pausiert und bewertet den Plan neu, wenn ein Fehler auftritt. Als es die 10-Sekunden-Warnung zum Warten erhielt, verbrachte es mehr Zeit in der Phase der „Strategieplanung“. Außerdem entschied es sich konsequent, auf die Wiederherstellung des Haupttools zu warten oder es mit dem stabilen Tool zu versuchen, anstatt auf ein anderes Tool zum Filtern umzusteigen, 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-Ausnahmen, die innerhalb eines Tools ausgelöst werden, als fatale Fehler und beendet den Prozess. Im Gegensatz zu seinen Mitbewerbern 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 der Korrektur: Nach Anwendung der Korrektur beobachteten wir in den Logs von LangChain, dass es genau dieselbe Argumentation wie LangGraph zeigte. Es empfing 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 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? (Framework-Architektur-Analyse)
Wenn das Agentenverhalten allein vom LLM (GPT-5.2) abhinge, hätten sich alle Frameworks ähnlich verhalten sollen. Die deutlichen Unterschiede in diesen Quoten sind jedoch in den eigenen inneren Loop-Mechanismen der Frameworks begründet:
1. LangGraph & AutoGen (90 % Pivot):
LangGraph arbeitet mit einer Zustandsmaschinen-Architektur, während AutoGen auf einem konversationsbasierten Modell basiert. In beiden Systemen werden Fehler als Feedback-Loop verarbeitet. Bei LangGraph gibt der Zustand, der den Fehler empfängt, diesen an den nächsten Knoten weiter; bei 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 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 sein Ausführungs-Loop eine linearere Struktur und ist primär darauf ausgerichtet, eine Final Answer zu produzieren. Wenn das Tool 3–4 Schritte lang Fehler wirft, zieht es LangChain manchmal vor, auf den Erfolg des Tools beim nächsten Versuch zu warten oder ein Ergebnis aus dem vorhandenen Kontext zu produzieren, anstatt auf eine alternative Strategie umzuschwenken. Da die Zustandsbindung von LangChain flexibler ist als die von LangGraph, liegt seine Warte-/Direktlösungsquote bei etwa 35 %.
3. CrewAI (0 % Pivot):
CrewAI arbeitet mit einer Managerial-Process-Architektur. Seine Agenten sind in Rollen- und Aufgabendefinitionen eingebettet. Bei Fehlern löst seine interne Architektur in der Regel Selbstkorrektur- oder Wiederholungslogik aus. Ein radikaler Strategiewechsel wie „Lass uns den gesamten Plan verwerfen und in 5 Schritten manuell filtern“ kollidiert jedoch mit der Managerial-Plan-Struktur von CrewAI. Es arbeitet mit der Disziplin: „Ich sollte das mir zugewiesene Tool reparieren oder die nächstliegende Alternative nutzen“, anstatt den Plan vollständig aufzugeben. Dies ist grundsätzlich 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 innerhalb einer CSV auf JSON- und Langtext-Spalten (LongText) stoßen. Die Agenten mussten zunächst den Datentyp dieser Spalten erkennen und dann die korrekten 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, Freitext-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.
Aufgabe 5 haben wir speziell dafür konzipiert, diese beiden Fähigkeiten getrennt zu messen.
AutoGen
AutoGen lieferte in dieser Aufgabe eine starke Leistung und schloss mit 8.170 Prompt-Tokens und einer medianen Latenz von 47 Sekunden ab – das schnellste und token-effizienteste Ergebnis in Aufgabe 5.
Der Gesprächs-Loop im Kern seiner Architektur, das Messaging zwischen AssistantAgent und UserProxyAgent, wird üblicherweise als Struktur angesehen, die zu Ausführlichkeit führt. In Aufgabe 5 wurde diese Struktur jedoch zu einem Vorteil.
Durch Betrachtung des Gesprächsverlaufs erkannte das LLM, dass die Spalten Metadata und SupportNotes voneinander unabhängig sind. Daraufhin sendete es eine einzelne TOOL CALLS-Antwort, die 4 Tools gleichzeitig auflistete: inspect_column(Metadata), inspect_column(SupportNotes), parse_json_column(…) und summarize_text_column(…) – alle parallel ausgeführt. Dadurch konnte es die Aufgabe in 3 LLM-Runden abschließen, mit den wenigsten Tokens und den wenigsten Schritten.
Der technische Grund für dieses Verhalten liegt auf der Hand: 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 Gesprächsschritt. Die Philosophie des Frameworks, „die Konversation zu managen“, ermöglicht 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 einer medianen Zeit von 70 Sekunden ab – nahe an AutoGen bei den Tokens, 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 Durchlauf akkumuliert der Loop llm node → tools node → llm node alle vorherigen Tool-Ausgaben im Zustand und übergibt sie an das LLM. Diese Struktur garantiert, dass der Agent niemals etwas vergisst, was normalerweise ein erheblicher Vorteil ist.
In Aufgabe 5 wirkte sich diese Stärke jedoch nachteilig aus. LangGraph fand die richtigen Tools und baute das richtige Segment auf. Aber 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 liefern, sprang das „fehlender Schritt“-Signal der Zustandsmaschine an, und der Agent geriet in unnötige Loops. Infolgedessen lag die Anzahl der Tool-Aufrufe pro Durchlauf zwischen 6 und 16. Die Kraft des Zustands, „niemals etwas zu vergessen“, ließ abgeschlossene Schritte manchmal als unvollständig erscheinen, zog den Agenten in redundante Zyklen zurück und trieb die Latenz um 23 Sekunden über die von AutoGen, obwohl die Token-Zahl vergleichbar war.
CrewAI
CrewAIs Leistung in Aufgabe 5 wies die höchste Varianz im gesamten Benchmark auf. In einigen Durchläufen folgte es einer makellosen Sequenz mit 5 Tool-Aufrufen, ohne Umwege, wie ein Skript. In diesen Durchläufen funktionierte die durch Rollen und Aufgaben definierte Management-Struktur 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 völliges Chaos aus. Die Ursache war der innere Monolog (Thought), den CrewAI bei jedem Schritt erzeugt. Nachdem das Segment korrekt mit dem richtigen Filter aufgebaut war, begann der innere Monolog des Agenten zu hinterfragen, ob nicht auch noch weitere Filter angewendet werden sollten. Nachdem er das Ergebnis gesehen hatte, zweifelte er, ob das aktuelle Segment gültig oder das vorherige vorzuziehen sei. Dieser Zweifel trieb ihn dazu, die Daten von Grund auf neu zu laden. Dann filterte er erneut, trat in eine weitere Verifikationsschleife ein, zweifelte wieder und wiederholte diese Spirale 8 Mal.
In CrewAI erzeugt jeder Thought eine unabhängige Bewertung, und diese Bewertungen machen gelegentlich zuvor verifizierte Schritte ungültig. Der Reflex des Managerial Process zur „kontinuierlichen Verifizierung“ trieb den Agenten in einigen Durchläufen dazu, seine eigenen richtigen Entscheidungen neu 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 einer medianen Zeit 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 einzelnen Tool-Aufruf aus, empfängt das Ergebnis und geht dann weiter, was bedeutet, dass 4 unabhängige Tools 4 separate LLM-Runden mit 4 separaten Wartezeiten erforderten. Der mediane Wert von 47 Sekunden von AutoGen gegenüber den 86 Sekunden von LangChain ist eine direkte Messung der Kosten 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 Parsen und Zusammenfassen über (9 Tools), während es in anderen zuerst jede Spalte inspizierte, bevor es 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 Loop-Mechanismus 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 schlägt sich dieser Unterschied in einem massiven Kosten- und Geschwindigkeitsvorteil nieder.
Frameworks mit zustandsgetriebenen Loops (LangGraph) zeichnen sich durch Datenkonsistenz aus, tragen aber das Risiko, abgeschlossene, in der Historie angesammelte Schritte erneut zu bewerten.
Monolog-basierte Frameworks (CrewAI) sind tiefgehend in der Lage, Typ und Bedeutung von Daten zu verstehen, aber diese Tiefe schlägt manchmal in übermäßiges Hinterfragen und Loops um.
Lineare Ausführungs-Frameworks (LangChain) verarbeiten verschiedene Zweige unstrukturierter Daten separat und liefern ein Mittelding aus beiden Welten.
GitHub-Sternwachstum agentischer Frameworks
Vergleich agentischer KI-Frameworks
Agentische KI-Frameworks variieren in mehreren Schlüsseldimensionen, und das Verständnis dieser Unterschiede ist für aussagekräftige Vergleiche unerlässlich.
Multi-Agent-Orchestrierung
Multi-Agent-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 Expertise. Jedes Framework bietet unterschiedliche Ansätze zur Agentenkoordination.
LangGraph
LangGraph ist ein relativ bekanntes Framework und stellt eine Schlüsseloption 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. Daher eignet es sich gut für RAG und benutzerdefinierte Pipelines.
AutoGen
AutoGen ermöglicht es mehreren Agenten, in einer Schleife Nachrichten auszutauschen. Jeder Agent kann auf Basis seiner internen Logik antworten, reflektieren oder Tools aufrufen.
Es verfügt über eine asynchrone Agentenkollaboration, wodurch es besonders nützlich für Forschungs- und Prototyping-Szenarien ist, in denen das Agenten-Verhalten Experimente oder iterative Verfeinerung erfordert.
CrewAI
CrewAI übernimmt den Großteil der Low-Level-Logik für Sie und bietet Multi-Agent-Orchestrierung:
- Integration mit Monitoring-Tools 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 Prototyping. Agenten arbeiten sequenziell durch Übergaben (Handoffs), wobei sie Aufgaben übertragen und dabei einen gemeinsamen Kontext beibehalten. 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 wie Chains, Tools, Memory und Retrieval für Workflows zur Dokumentenverarbeitung.
LangChain arbeitet hauptsächlich mit Single-Agent-Ausführungsmustern, bei denen ein Agent den Workflow verwaltet.
Agenten- und Funktionsdefinition
LangGraph
LangGraph verfolgt einen graphbasierten Ansatz für das Agentendesign, bei dem jeder Agent als Knoten dargestellt wird, der seinen eigenen Zustand aufrechterhä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 erstellen und 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. Man kann es sich so vorstellen, als würde man 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), indem sie Nachrichten austauschen, was kollaboratives Problemlösen ermöglicht. Wie LangGraph verwendet es annotierte, strukturierte Funktionen.
CrewAI
CrewAI verwendet 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 und stützt sich stattdessen 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 das 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 ü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 nicht über eingebaute 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.
Speichermerkmale sind ein zentraler Bestandteil beim Aufbau agentischer Systeme, um sich Kontext zu merken und sich im Laufe der Zeit anzupassen:
- Kurzzeitspeicher: Verfolgt kürzliche Interaktionen und ermöglicht Agenten, mehrzügige Konversationen oder schrittweise Workflows zu bewältigen.
- Langzeitspeicher: Speichert persistente Informationen über Sitzungen hinweg, wie Benutzereinstellungen oder Aufgabenverlauf.
- Entity Memory: Verfolgt und aktualisiert Wissen über bestimmte Objekte, Personen oder Konzepte, die während Interaktionen erwähnt werden (z. B. das Erinnern an einen zuvor genannten Firmennamen oder eine 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 speichert. 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 bietet flexible Kontrolle darüber, wie Speicher bereichsbezogen und über Ausführungen hinweg aufbewahrt wird.
AutoGen
AutoGen verwendet ein kontextuelles Speichermodell. Jeder Agent verwaltet Kurzzeitkontext über ein context_variables-Objekt, das die Interaktionshistorie speichert. Es verfügt über keinen eingebauten persistenten Speicher.
CrewAI
CrewAI bietet mehrschichtigen Speicher direkt einsatzbereit. Es speichert Kurzzeitspeicher in einem ChromaDB-Vector-Store, aktuelle Aufgabenergebnisse in SQLite und Langzeitspeicher in einer separaten SQLite-Tabelle (basierend auf Aufgabenbeschreibungen). Darüber hinaus unterstützt es Entity Memory mittels Vektor-Embeddings. Diese Speichereinrichtung 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 übergeben 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-Buffer verwaltet, die den Konversationsverlauf innerhalb einer Sitzung verfolgen. Für den Langzeitspeicher integriert LangChain externe Vector Stores oder Datenbanken zur Persistierung von Embeddings und Abrufdaten.
Entwickler können Speicherbereiche und -strategien mithilfe eingebauter Speicherklassen anpassen, was eine effiziente Verwaltung von kontextuellem und entitätsbezogenem Speicher über Interaktionen hinweg ermöglicht.
Human-in-the-Loop
LangGraph
LangGraph unterstützt benutzerdefinierte Breakpoints (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 und ermöglicht es Menschen, Schritte während der Agentenkollaboration zu überprüfen, zu genehmigen oder zu ändern.
CrewAI:
CrewAI ermöglicht Feedback nach jeder Aufgabe, indem human_input=True gesetzt wird; der Agent pausiert, um natürlichsprachliche Eingaben vom Benutzer zu sammeln.
OpenAI Swarm
OpenAI Swarm bietet kein eingebautes HITL.
LangChain
LangChain ermöglicht das Einfügen benutzerdefinierter Breakpoints innerhalb von Chains oder Agenten, um die Ausführung anzuhalten und menschliche Eingaben anzufordern. Dies unterstützt Überprüfung, Feedback oder manuelles Eingreifen an definierten Punkten im Workflow.
Model Context Protocol (MCP)-Integration in agentischen 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 erstellen, was ein fragmentiertes Ökosystem schuf. MCP löst dieses Problem, 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 MCP integriert
LangGraph
LangGraph verbindet sich über einen Adapter mit MCP-Servern, 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 eine integrierte MCP-Integration über sein Erweiterungsmodul. Entwickler können sich mit MCP-Servern verbinden und deren 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 automatisch das Verbindungs-Lebenszyklus- und Fehlermanagement.
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-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.
Als bevorzugte Quelle hinzufügenWas agentische KI-Frameworks tatsächlich tun?
Agentische KI-Frameworks unterstützen bei der Prompt-Konstruktion und verwalten, wie Daten zu und von LLMs fließen. Auf einer grundlegenden Ebene helfen sie, Prompts zu strukturieren, damit das LLM in einem vorhersagbaren Format antwortet, und leiten Antworten an das richtige Tool, die API oder das Dokument weiter.
Wenn man von Grund auf neu baut, würde man den Prompt manuell definieren, das vom LLM gewünschte Tool extrahieren und den entsprechenden API-Aufruf auslösen. Frameworks optimieren dies durch:
- Prompt-Orchestrierung: Erstellung, Verwaltung und Routing komplexer Prompts an LLMs
- Tool-Integration: Agenten können externe APIs, Datenbanken, Code-Funktionen usw. aufrufen
- Speicher: Aufrechterhaltung des Zustands über mehrere Runden oder Sitzungen hinweg (kurz- und langfristig)
- RAG-Integration: Ermöglicht Wissensabruf aus externen Quellen
- Multi-Agenten-Koordination: Strukturierung, wie Agenten zusammenarbeiten oder Aufgaben delegieren
Agentische 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 von Google Flights & Hotels APIs) und Reiseempfehlungen generiert.3
CrewAI – Agentischer Content Creator
Das offizielle Beispiel-Repository von CrewAI enthält Flows wie Reiseplanung, Marketingstrategie, Aktienanalyse und Recruiting-Assistenten, bei denen rollenspezifische Agenten (z. B. „Researcher“, „Writer“) an Aufgaben zusammenarbeiten.4
CrewAI verwandelt ein High-Level-Content-Briefing unter Verwendung von Groq in einen vollständigen Artikel.
Kernmerkmale agentischer 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 möglicherweise mit einigen Modellen besser als mit anderen.
- Zugriff auf und Anpassung von System-Prompts sind 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 über 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 beizubehalten.
RAG (Retrieval-Augmented Generation):
- Die meisten enthalten einfache Setup-Optionen für RAG, die Vektordatenbanken oder Document Stores integrieren.
- Dies ermöglicht Agenten, während der Ausführung auf externes Wissen zu verweisen.
Weitere gemeinsame Merkmale
- Unterstützung für asynchrone Ausführung, die gleichzeitige Agenten- oder Tool-Aufrufe ermöglicht.
- Eingebaute Behandlung für strukturierte Ausgaben (z. B. JSON).
- Unterstützung für Streaming-Ausgaben, bei denen das Modell Ergebnisse inkrementell generiert.
- Grundlegende Observability-Funktionen zur Überwachung und zum Debugging von Agentenläufen.
Benchmark-Methodik
1. Aufgabenstruktur
Aufgabe 1: Misst, ob ein einzelner Tool-Aufruf mit dem korrekten Parameter durchgeführt werden kann. Der Infrastruktur-Grundaufwand des Frameworks zeigt sich in diesem einfachen Szenario am deutlichsten.
Aufgabe 2: Erfordert, die Ergebnisse zweier separater Filtergruppen im Speicher zu halten und in einer einzigen Ausgabe zu kombinieren. 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 ist, 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. Gemessen wird, ob das Framework angesichts dieser Fehler die Strategie ändert.
Aufgabe 5: Der Agent muss zunächst JSON- und LongText-Spalten entdecken und dann die richtigen Tools mit den richtigen 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 zu konkretisieren, hier Aufgabe 5, die komplexeste Aufgabe im Benchmark agentischer KI-Frameworks. Jedes Framework erhielt den identischen Prompt und den identischen Satz an Tools; lediglich das Framework, das LLM umgibt, änderte sich.
Dem Agenten gegebener Prompt:
Analysiere abgewanderte Kunden (Churn=’Ja’), die mehr als 100 an MonthlyCharges zahlen.
- Filtere den Datensatz auf Churn=’Ja’.
- Inspiziere die Spalten ‚Metadata‘ und ‚SupportNotes‘, um ihre Datentypen zu ermitteln.
- Extrahiere die ‚device_type‘-Verteilung aus der JSON-Spalte ‚Metadata‘.
- Zähle Beschwerde-Schlüsselwörter aus der Freitext-Spalte ‚SupportNotes‘.
Gib 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 bei jedem Aufruf im Zustand halten und erkennen, dass eine Spalte JSON ist, während die andere Freitext ist. Ein Framework, das die unabhängigen Spalten parallel ausführt (AutoGen), wird viel schneller fertig als eines, das sie sequenziell ausführt (LangChain), und ein Framework, das abgeschlossene Schritte neu bewertet (LangGraph, CrewAI), loopt unnötig. 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 Durchlauf zurückgesetzt. 100 unabhängige Durchläufe wurden für jede Framework-Aufgaben-Kombination ausgeführt.
Maximale Iterationslimits wurden entsprechend der Aufgabenkomplexität festgelegt: 10 für Aufgaben 1, 2 und 3; 20 für Aufgabe 4 aufgrund des fehlerhaften Tool-Loops; 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-Frameworks für agentische KI}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/agentic-frameworks}},
note = {AIMultiple. Abgerufen am 10. August 2026}
}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.