Ein früheres CrewAI-README warb mit „5,76x schneller als LangGraph“ für ein konkretes QA-Beispiel. AIMultiple fand dagegen bei einer Single-Tool-Aufgabe ungefähr dreimal so viel Laufzeit und Tokenverbrauch wie mit LangChain. Beide Vergleiche betreffen Ausführung, aber andere Aufgaben und Vergleichspartner. Ohne diese Messbasis wird aus einem lokalen Ergebnis schnell ein vermeintlich allgemeiner Sieg.
Die historische Behauptung lautete: „CrewAI zeigt signifikante Performance-Vorteile gegenüber LangGraph und ist in bestimmten Fällen wie diesem QA-Task-Beispiel 5,76x schneller.“ Sie bezog sich auf die Ausführung dieses Beispiels, nicht auf die Zeit, die ein Mensch zum Programmieren braucht. Im aktuellen Projekt-README ist diese Zahl keine allgemeine Leistungsgarantie.
Fünfeinhalbmal schneller. Klingt nach einem Grund, morgen das Framework zu wechseln.
Nur: Es stimmt so nicht. Nicht in der Form, wie du es vermutlich verstehst.
Die Zahl ist echt. Der Test, der sie hervorgebracht hat, existiert. Aber was „schneller" in diesem Satz bedeutet, ist nicht das, was die meisten Leser annehmen. Und die Lücke zwischen dem, was gemessen wurde, und dem, was Leser daraus machen, leistet richtig viel Arbeit — wahrscheinlich mehr Arbeit, als irgendein Marketing-Team einer einzelnen Zahl jemals überlassen sollte.
Hier geht es darum, Framework-Benchmarks skeptisch zu lesen, mit dem CrewAI-vs-LangGraph-Fall als Anschauungsbeispiel. Wenn du 2026 ein Multi-Agent-Orchestration-Framework wählst, ist das relevant. Wenn du AI-Engineering unterrichtest, ist es noch relevanter, weil die Fähigkeit, einen irreführenden Benchmark zu erkennen, eine Karriere-Fertigkeit ist.
Was die CrewAI-Seite tatsächlich sagt#
Das README ist vorsichtig formuliert. „5,76x schneller in bestimmten Fällen wie diesem QA-Task-Beispiel (siehe Vergleich)." Der Link zeigt auf ein Repository, in dem beide Frameworks dieselbe Question-Answering-Aufgabe lösen. CrewAI ist in diesem konkreten Szenario schneller fertig. Nimm die rohen Zahlen und teile — 5,76x.
So weit, so nachvollziehbar. Niemand erfindet Daten. Die Stoppuhr lügt nicht.
Das Problem ist, was „dieses QA-Task-Beispiel" eigentlich misst. Denn ein Multi-Agent-Framework kann auf mindestens vier verschiedene Arten „schneller" sein, und die sind nicht austauschbar.
Die vier Geschmacksrichtungen von „schneller"#
Framework A kann schneller als Framework B sein in:
Entwicklungs-Geschwindigkeit — wie lange ein Mensch braucht, um die erste funktionierende Version zu schreiben. Gemessen in Codezeilen, Setup-Zeit, Stunden bis zum ersten grünen Test.
Ausführungs-Geschwindigkeit — wie lange das Framework zur Laufzeit braucht, um eine Aufgabe abzuschließen, sobald sie geschrieben ist. Gemessen in Wall-Clock-Sekunden pro Run.
Token-Effizienz — wie viele Tokens pro Arbeitseinheit verbraucht werden. Relevant, weil Tokens Geld und Context-Window-Plätze kosten.
Skalierungsverhalten — wie Latenz und Kosten wachsen, wenn du mehr Agents, Tools oder Iterationen hinzufügst. Ein Framework, das mit drei Agents schnell ist, kann bei zehn abstürzen.
Das sind unterschiedliche Dimensionen. Ein Framework kann in einer dominieren und in einer anderen verlieren. Im konkreten CrewAI-Claim war mit „5,76x schneller“ tatsächlich Ausführungs-Geschwindigkeit gemeint. Der Fehler wäre, daraus schnellere Entwicklung oder einen Vorteil für jede beliebige Aufgabe abzuleiten.
Was der unabhängige Benchmark gefunden hat#
Der sauberste unabhängige Test, den ich gesehen habe, ist AIMultiples Benchmark von Anfang dieses Jahres. Sie haben vier Frameworks laufen lassen — LangChain, LangGraph, AutoGen, CrewAI — über fünf Aufgaben, insgesamt zweitausend Runs. Gleiche Probleme, gleiche Modelle, Stoppuhr an, Methodik veröffentlicht.
Bei der Single-Tool-Aufgabe nutzte CrewAI in AIMultiples Test ungefähr dreimal so viele Tokens wie LangChain und brauchte ungefähr dreimal so lange. Das ist ein Ergebnis für diese Aufgabe und Konfiguration. Es ist weder ein Vergleich mit dem historischen QA-Beispiel noch eine Rangliste für jeden produktiven Agenten.
Gleiche Framework-Familien. Gegenteilige Schlussfolgerung. Was ist passiert?
Die Auflösung#
Wenn man beide Aussagen sauber weiterverfolgt, passen sie zusammen.
Die historische 5,76x-Angabe ist eine Laufzeitangabe für ein QA-Beispiel. Sie misst keine Entwicklungs-Geschwindigkeit und belegt keinen festen Vorteil bei Codeumfang oder Prototyping-Zeit. Rollenbasierte Agents können einen Entwurf verständlicher machen, aber wie schnell du damit einen belastbaren Prototyp baust, musst du an deiner Aufgabe messen.
Auch AIMultiple misst Laufzeit und Tokenverbrauch. Modellaufrufe, Zahl der Agents, Tool-Auswahl und zusätzliche Prüfungsschritte können das Ergebnis verändern. Eine feste Fünf-Sekunden-Pause pro Tool-Aufruf lässt sich daraus nicht ableiten. Zusätzliche Schritte können bei einfachen Aufgaben Overhead und bei schwierigeren Aufgaben hilfreich sein; dafür müssen Qualität und Aufwand zusammen geprüft werden.
Die scheinbar gegensätzlichen Ergebnisse betreffen also dieselbe Dimension, aber unterschiedliche Versuchsaufbauten. Du brauchst dieselbe Aufgabe, vergleichbare Modelle, Agentenzahl und Tool-Aufrufe sowie ein gemeinsames Qualitätsziel, bevor du daraus eine Entscheidung ableitest.
Warum das für die Framework-Auswahl wichtig ist#
Wenn du ein Multi-Agent-Framework auswählst, hat diese Unterscheidung praktische Konsequenzen.
Entwicklungs-Geschwindigkeit zählt am meisten beim Prototyping, wenn du klein bist, wenn du noch nicht weißt, ob das Problem sich lohnt. Ausführungs-Geschwindigkeit und Token-Effizienz zählen am meisten im Maßstab, wenn Tokens echtes Geld kosten, wenn Latenz für die Nutzer sichtbar wird.
CrewAI ist in der ersten Phase wirklich gut. Teams bauen in einem Wochenende lauffähige Multi-Agent-Prototypen. Das hat Wert, besonders beim Lernen.
Teuer kann die zweite Phase werden, wenn der Prototyp die Anforderungen an Zustand, Wiederaufnahme, Tests oder Kosten nicht erfüllt. Ein Framework-Wechsel kann dann Umbau verlangen. Ein allgemeiner Zeitpunkt nach sechs Monaten oder ein Umbauanteil von 50 bis 80 Prozent ist ohne konkrete Projekte und Berechnung nicht belastbar. Prüfe diese Anforderungen deshalb vor der Wahl am eigenen Ablauf.
CrewAI kann für einen Prototyp passen, LangGraph für Abläufe mit explizitem Zustand. Ob ein späterer Wechsel nötig ist, ergibt sich aus Anforderungen und Tests, nicht automatisch aus der Framework-Wahl.
Das Muster hinter dem konkreten Fall#
Zoome raus von CrewAI. Das ist eine Schablone, die überall in der Framework-Welt angewendet wird.
„Framework X ist zehnmal schneller als Framework Y" ist ein Satz, der unter Nachfragen fast immer zusammenbricht. Schneller bei was? Wie gemessen? Auf welcher Hardware? Mit welchen Modellen? Unter welcher Last? Für die Entwickler, die den Code schreiben, oder für die Maschine, die ihn ausführt?
Die Benchmarks, denen man vertrauen kann, haben ein paar Eigenschaften gemeinsam. Sie benennen die Dimension, die sie messen. Sie laufen über mehrere Aufgaben, nicht ein handverlesenes Szenario. Sie veröffentlichen ihre Methodik. Sie nennen Trade-offs. Die AIMultiple-Studie tut all das. Das CrewAI-README tut eines — es benennt die Aufgabe — und hört dann auf.
Eine nützliche Gewohnheit beim Lesen jedes Framework-Vergleichs: bei der Zahl kurz stoppen und fragen „Geschwindigkeit von was?". Wenn der Artikel das nicht klar macht, zählt die Zahl nicht. Das gilt für Datenbank-Vergleiche, Web-Framework-Shootouts, Compiler-Speed-Claims, Inferenz-Benchmarks, jede Spielart von Engineering-Marketing.
Für KI-Frameworks speziell gibt es noch eine Dimension, die selten gemessen wird, aber enorm wichtig ist: Verhalten bei Teil-Ausfällen. Multi-Agent-Systeme versagen auf seltsame Weise. Ein Agent liefert eine fehlerhafte Antwort zurück, ein Tool-Call läuft in ein Timeout, ein nachgelagerter Agent wird vom Rauschen verwirrt. Wie geht das Framework damit um? LangGraph hat eingebaute Retry- und State-Checkpointing-Primitive. CrewAI hat sie auch, aber weniger granular. AutoGen handhabt es über Conversation-Patterns, die schwerer zu überblicken sind. Kein Benchmark, den ich gesehen habe, misst das gut, aber es ist wahrscheinlich das, was ein Demo von einem Produktions-System mehr trennt als alle rohen Geschwindigkeits-Zahlen.
Was Anthropics eigene Erfahrung hinzufügt#
Anthropic hat im Juni letzten Jahres einen detaillierten Engineering-Post zum Bau ihres Research-Multi-Agent-Systems veröffentlicht. Die frühen Iterationen hatten Fehler, die kein Benchmark fangen würde: Agents, die für eine einzige einfache Anfrage fünfzig Subagents gespawnt haben, endlos nach Quellen suchten, die es nicht gab, sich gegenseitig in Status-Updates ertränkt haben. Der Fix war kein schnelleres Framework. Es waren härtere Constraints — Runden-Limits, explizite Contribution-Regeln, Konvergenz-Kriterien.
Anthropic berichtete, dass das Gesamtsystem mit Claude Opus 4 als Orchestrator und Claude Sonnet 4 als Subagents den einzelnen Claude Opus 4 in internen Research-Evaluierungen um 90,2 Prozent übertraf. Der Vergleich isoliert nicht die Wirkung der Constraints: Modellkombination, Tool-Nutzung, Parallelisierung und Tokenbudget gehören ebenfalls zum System.
Leitplanken und Orchestrierung sind wichtige Prüfgrößen neben dem Framework. Daraus folgt kein allgemeiner CrewAI- oder LangGraph-Sieger. Vergleiche konkrete Aufgaben mit gleichem Budget, Fehlerbehandlung und gemessener Ergebnisqualität.
Drei Fragen an jeden Framework-Claim#
Wenn du vor einem Framework-Vergleich stehst — egal ob du eins auswählst, einen Artikel dazu schreibst oder unterrichtest — sortieren drei Fragen das ehrliche Signal vom Marketing-Rauschen.
Erstens: Welche Dimension? Wenn ein Post sagt „X ist schneller", ohne Entwicklungs-Geschwindigkeit, Ausführungs-Geschwindigkeit, Token-Kosten oder Skalierungsverhalten zu spezifizieren, ist die Aussage nicht nützlich. Frag nach, welche es ist.
Zweitens: Was ist der Gegen-Fall? Jedes Framework, das in einer Dimension gewinnt, verliert in einer anderen. Wenn der Artikel keinen Trade-off erwähnt, verkauft er dir was. Der Trade-off ist nicht versteckt; der Autor hat ihn nur weggelassen.
Drittens: Wie sieht der Failure-Mode des Frameworks aus? Unter welchen Bedingungen bricht es? Wenn die Dokumentation Failure-Modes nicht benennt, ist das Framework entweder noch nicht im Maßstab eingesetzt worden — oder das Team verkauft dir das Demo.
Die historische 5,76x-Angabe nennt eine Laufzeitdimension und ein konkretes Beispiel. Was sie nicht liefert, ist ein allgemeiner Sieg oder ein vollständiges Bild von Kosten, Qualität und Fehlerverhalten. Die nützliche Frage ist deshalb, ob der verlinkte Versuchsaufbau deiner eigenen Aufgabe entspricht.
Sobald du einen davon klar gesehen hast, siehst du sie überall. Das ist die Fertigkeit, die es zu bauen lohnt.
