LangGraph gegen Pydantic AI: Warum das Modell und nicht das Framework die Genauigkeit bestimmt
Ein kontrollierter Vergleich mit 160 Punkten zwischen LangGraph und Pydantic AI zeigt eine identische Genauigkeit bei der Aufrufung von Tools und verdeutlicht, dass die Wahl des Modells sowie die Gestaltung der Bewertung weitaus wichtiger sind.
Die Wahl zwischen Agent-Frameworks gehört zu den hitzigsten Debatten in der KI-Entwicklung, doch ein sorgfältig kontrollierter Benchmark deutet darauf hin, dass es sich dabei um eine der weniger entscheidenden Optionen hinsichtlich der Korrektheit handeln könnte. Als LangGraph und Pydantic AI mit identischen Aufgaben, Werkzeugen sowie Modell-Einstellungen ausgeführt wurden, erzielten sie genau denselben Score, während ein Wechsel des Modells ein Viertel der Ergebnisse veränderte. Dieser Artikel geht auf dieses Experiment ein, zeigt auf, was seine Zahlen belegen und was nicht, sowie wie man eigene Evaluierungsanstrengungen dort einsetzen sollte, wo sie tatsächlich zu Ergebnisänderungen führen.
Wie der Benchmark das Framework isolierte
Die Vergleichsstudie setzte LangGraph 1.2.9 gegen Pydantic AI 2.13.0 in vier Aufgaben ein, wobei pro Aufgabe und Framework 20 Ausführungen durchgeführt wurden: insgesamt 160 Ausführungen, ein Modell, Temperatur 0. Die gesamte Studie kostete 0,3767 Dollar an API-Kosten. Die Methodik ist dokumentiert und das Testframework ist Open Source, sodass die Einrichtung überprüft und erneut ausgeführt werden kann.
Sämtliche vier Aufgaben sind deterministisch und werden anhand einer exakten Übereinstimmung bewertet; jede von ihnen prüft eine andere Fähigkeit des Agenten:
inventory-reorder: Ein einziger Toolaufruf, gefolgt von arithmetischen Berechnungen am Ergebnisdependent-shipping-quote: Ein zweiter Toolaufruf, dessen Eingabe von dem Ausgangsergebnis des ersten abhängtrecover-stale-revision: Der Agent muss erkennen, dass seine Daten veraltet sind, und sie erneut abrufenrefund-policy-minimal-tools: Datenerfassung im Zusammenhang mit einer Rückerstattungsrichtlinie, wobei absichtlich nur wenige Tools zur Verfügung stehen
Alles um die Bibliothek herum blieb konstant: Jedes Framework erhielt für jede Aufgabe identische Anfragen, wurde mit Werkzeugen versorgt, die durch identische JSON-Schemata beschrieben wurden, und stützte sich auf eine gemeinsame Implementierung; außerdem wurde es von einem einzigen Bewertungssystem bewertet. Das Modell war auf gpt-4o bei einer Temperatur von 0 festgelegt, wobei parallele Aufrufe der Werkzeuge deaktiviert waren. Die Orchestrierungsbibliothek war das Einzige, was geändert werden durfte.
Diese Disziplin ist der Kern des Experiments. Viele veröffentlichte Vergleiche von Frameworks ändern gleichzeitig die Anfragen, die Werkzeuge sowie die Bibliothek und geben anschließend der Bibliothek alle Unterschiede zu. Wenn Sie einen zuverlässigen eigenen Vergleich wünschen, ist es die erste Voraussetzung, alles andere unverändert zu lassen.
Gleiche Korrektheit
Sowohl die Frameworks haben alle 80 Ausführungen korrekt abgeschlossen. Zusammenfassung:
LangGraph 1.2.9 Pydantic AI 2.13.0
Completed 80 / 80 80 / 80
Wilson 95% CI 0.954 - 1.0 0.954 - 1.0
Total cost $0.1881 $0.1886
Median wall time 3.863 s 5.526 s
Es handelt sich hier weder um einen Fall von „ungefähr vergleichbar“ noch um Werte, die im Rahmen der Streuung liegen. Bei denselben Aufgaben, Schemata, Modellen und Payloads waren die Ergebniswerte identisch. Das Wilson-Intervall von 0,954 bis 1,0 entspricht einem perfekten Ergebnis von 80 von 80 Punkten: Es zeigt an, dass bei dieser Stichprobe die tatsächliche Erfolgsrate mit sehr hoher Wahrscheinlichkeit bei über 95 Prozent für beide liegt. Hätte eine der Bibliotheken dazu geführt, dass die Agenten häufiger zur richtigen Antwort kamen, hätten die ausreichenden Versuche einen deutlichen Effekt aufzeigen müssen – doch es wurde keiner festgestellt. Es könnten dennoch sehr geringe Unterschiede übersehen werden, was eine normale Grenze für jede Stichprobe dieser Größe ist.
Das stärkste Indiz dafür, dass der Vergleich fair war, liegen in den Eingabetokens. Sie stimmten bei jedem Durchlauf in beiden Frameworks exakt überein: 311 für inventory-reorder, 791 für dependent-shipping-quote, 615 für recover-stale-revision und 926 für refund-policy-minimal-tools. Mit anderen Worten wandelten beide Bibliotheken dasselbe Schema in denselben API-Aufruf um – bytegenau in Bezug auf die Tokens. Die Ausgabetokens unterschieden sich bei einigen wenigen Durchläufen um wenige Einheiten, was eine normale Modellvarianz selbst bei einer Temperatur von 0 darstellt und für die halben Cent Differenz in den Gesamtkosten verantwortlich ist. Der Overhead des Frameworks trägt dazu nicht bei.
Ein Unentschieden ergibt zwar keinen spannenden Schlagzeileninhalt, beantwortet aber die praktische Frage: Was die Korrektheit der Toolaufrufe angeht, war bei dieser Skala und mit diesem Modell das Framework nicht die entscheidende Variable.
Latenz: eine konstante Differenz mit einer einfachen Erklärung
Die Frameworks unterschieden sich in einer Hinsicht, und das konsequent. Die folgende Liste gibt für jede Aufgabe an, um wie viel niedriger der Median-Wallzeitwert von LangGraph im Vergleich zu Pydantic AI war, gefolgt vom Bootstrap-95%-Konfidenzintervall für diese Ersparnis:
inventory-reorder: LangGraph liegt um 1,669 s vorn (Intervall von 1,481 bis 1,918 s)dependent-shipping-quote: liegt um 1,430 s vorn (Intervall von 1,241 bis 1,686 s)recover-stale-revision: liegt um 1,842 s vorn (Intervall von 1,658 bis 2,101 s)refund-policy-minimal-tools: liegt um 1,645 s vorn (Intervall von 1,427 bis 1,911 s)
In allen vier Aufgaben bleibt das gesamte Intervall weit entfernt von null. LangGraph beendete jede Ausführung etwa 1,4 bis 1,8 Sekunden früher – das entspricht einer Geschwindigkeitssteigerung von rund 1,4 Mal im Medianfall.
Verwandeln Sie das nicht in eine Empfehlung, ohne die Erklärung gelesen zu haben. Der Unterschied entsteht durch die Verbindung von asynchronem Code mit synchronem Code: Das Framework ist synchron, und Pydantic AI wurde über diesen synchronen Weg ausgeführt. Das zeigt nicht, dass der Agent-Loop von Pydantic AI an sich langsam ist. Die Zahl ist für diesen spezifischen Integrationsstil real und reproduzierbar, doch sie ist zugleich das am wenigsten übertragbare Ergebnis in der Studie. In einer Anwendung, die bereits von Anfang bis Ende asynchron ist, sollte sich der Unterschied verringern oder verschwinden.
Ein Einzelfall widerspricht dem Median
Ein Detail, das Beachtung verdient, steht im Widerspruch zum Ergebnis bezüglich der Latenzzeit. Die langsamste Ausführung in der Studie stammte von LangGraph: 16,196 Sekunden bei dependent-shipping-quote, im Vergleich zu einer schlechtesten Ausführung von Pydantic AI mit 10,228 Sekunden. Die nächstlangsamste Ausführung von LangGraph für diese Aufgabe dauerte 5,232 Sekunden – es handelt sich also offenbar um einen isolierten Ausreißer und nicht um ein starkes Schwanzverhalten. Da pro Aufgabe jedoch nur 20 Ausführungen durchgeführt wurden, lassen sich diese beiden Möglichkeiten nicht voneinander unterscheiden, und ein einzelner Datapunkt stellt keine Verteilung dar.
Die praktische Lehre: Die Medianwerte begünstigen hier LangGraph, doch wenn Sie eine Latenz-SLO festlegen, ist das Schwanzverhalten entscheidend – und Sie müssen es an Ihrer eigenen Arbeitslast messen, anstatt sich auf den Median eines anderen zu verlassen.
Der Wechsel des Modells änderte ein Viertel der Ergebnisse
In einer separaten Ausführung am selben System wurden die vier Aufgaben mit zwei Modellen durchgeführt, jeweils 40 Mal:
gpt-4o-mini gpt-4o
Completed 30 / 40 40 / 40
Cost (40 runs) $0.0057177 $0.094275
Die Frameworks, Aufgaben und Tools blieben unverändert. Nur das Modell unterschied sich, wodurch sich 25 Prozent der Ergebnisse änderten.
Die Art und Weise, wie gpt-4o-mini versagte, ist der aufschlussreichste Teil. Sein Aufruf der Tools funktionierte einwandfrei: Mit jedem Framework gelang es ihm bei allen Aufgaben außer einer korrekt abzuschließen. Die Ausnahme war refund-policy-minimal-tools, bei der es in allen 10 Versuchen zu dieser Aufgabe fehlschlug – fünfmal mit jedem Framework – und zwar stets auf dieselbe Weise. Es berechnete days_since_delivery = 19, indem es sowohl das Start- als auch das Enddatum zählte, obwohl die korrekte, ausschließliche Zählung 18 beträgt, und kam somit zu dem Schluss, dass der Kunde außerhalb des Rückerstattungszeitraums lag.
Das ist weder ein Framework-Fehler noch ein Fehler bei der Verwendung eines Tools. Es handelt sich um ein Modell, das bei der Berechnung inklusiver versus exklusiver Datenzählungen falsch vorgeht – innerhalb eines Agenten, der zuverlässig auf die falsche Zahl reagierte. Keine Orchestrierungsbibliothek kann einen solchen Fehler allein erkennen. Was ihn aufdeckt, ist eine deterministische Überprüfung: Die Berechnung von Datumsunterschieden mithilfe eines Tools anstelle der Anfrage an das Modell, die Arithmetik durchzuführen, oder die Validierung des Ergebnisses vor der weiteren Verarbeitung.
Daher endete der von der Branche diskutierte Vergleich unentschieden, während beim kaum jemand diskutierten Vergleich eine Differenz von 25 Punkten entstand. Für einen höheren Score waren etwa 16,5 Mal mehr Ressourcen nötig.
Was Sie daraus für Ihr eigenes System lernen können
Wählen Sie das Framework aufgrund der Benutzerfreundlichkeit
Basiere deine Entscheidung auf den Aspekten, mit denen du täglich umgehen musst: Typsicherheit, ob ein Graphenmodell zu deinem Problem passt, die Fehlersuch-Erfahrung sowie wie lesbar der Code für dein Team während eines Incidents ist. Diese Unterschiede sind real vorhanden. Auf dieser Grundlage gehört die Korrektheit nicht dazu. Für einen umfassenderen Vergleich der Optionen in diesem Zusammenhang siehe die Auswahl eines Python-AI-Agent-Frameworks.
Investiere dein Bewertungsbudget in das Modell
Hier führte die Wahl des Modells zu 25 Prozent Unterschieden in den Ergebnissen und veränderte die Kosten um einen Faktor von 16,5. Wenn du nur begrenzte Zeit hast, um etwas zu testen, teste das Modell an deinen eigenen Aufgaben. Beachte außerdem, dass beide Modelle in dieser Studie spezifische, ältere OpenAI-Modelle sind; neuere Modelle können sich anders verhalten, daher führe den Vergleich erneut mit den Modellen durch, die du tatsächlich verwenden möchtest.
Studieren Sie stattdessen die Fehlermöglichkeiten, nicht die Gesamterfolgsrate
Der informativste Teil dieser Vergleichsstudie war nicht die Ergebnistabelle, sondern refund-policy-minimal-tools – die Aufgabe, die absichtlich schwierig gestaltet wurde. Jedes Modell und jedes Framework bestand die anderen drei Aufgaben, wodurch diese nichts Aufschlussreiches zeigten. Eine Bewertungsmethode ist nur dann nützlich, wenn etwas fehlschlägt. Entwerfen Sie Aufgaben, die auf die konkreten Schwächen abzielen, vor denen Sie Angst haben – wie z. B. Logikfehler bei Datumsberechnungen, veraltete Daten oder aufeinanderfolgende Toolaufrufe – und erweitern Sie die Methode anhand tatsächlicher Produktionsfehler.
Vertrauen Sie Vergleichsstudien nicht, die einen Gewinner küren
Gehen Sie jeder Framework-Benchmark, die einen Gewinner ausweist, mit Misstrauen entgegen – einschließlich dieser hier. Was diese Studie überprüfbar macht, ist, dass die rohen JSONL-Ergebnisse, ein Manifest mit festgelegten Versionen und Hash-Werten sowie die zugehörige Toolsuite vollständig veröffentlicht wurden, zusammen mit den gesamten Daten jeder der 160 Ausführungen. Anwenden Sie denselben Standard auf alle Benchmarks, auf die Sie sich verlassen.
Beschränkungen der Belege
Der Umfang ist begrenzt: eine Modellfamilie, vier Aufgaben, ein Framework und ein fester Termin. Die Tests fanden am 24. und 25. Juli 2026 statt, wobei die Modelle gpt-4o und gpt-4o-mini sowie die Bibliotheksversionen LangGraph 1.2.9 und pydantic-ai-slim[openai] 2.13.0 verwendet wurden; die Ergebnisse können mit neueren Versionen abweichen. Die Korrektheit bei der Aufrufung von Tools ist außerdem nur eine Dimension eines Agentenframeworks – vermutlich nicht die, die Ihnen am wichtigsten ist; Zustandsverwaltung, Persistenz, Streaming und Observabilität werden hier nicht gemessen.
Was die Daten also belegen, ist bescheidener als in Schlagzeilen dargestellt: Bei diesen Aufgaben und in diesem Umfang konnte das Framework nicht vorhersagen, ob der Agent die richtige Antwort fand – im Gegensatz zum Modell.
Haupterkenntnisse
- Durch die Kontrolle aller Aspekte außer der Bibliothek wird ein Vergleich von Frameworks sinnvoll; identische Zählwerte der Eingabetoken sind ein guter Indikator für Fairness.
- LangGraph und Pydantic AI erzielten jeweils 80 von 80 Punkten bei der Korrektheit der Tool-Aufrufe mit
gpt-4o. - Der Latenzunterschied resultierte von einer Umstellung auf asynchrone Verarbeitung im Framework, nicht von langsamen Agentenschleifen, und ein einzelner Ausreißer zeigt, warum die Endlatenz separat gemessen werden muss.
- Durch den Wechsel des Modells änderten sich 25 Prozent der Ergebnisse, was auf einen konstanten Fehler in der Datenerfassung zurückzuführen war, den kein Framework erkennen konnte.
- Investieren Sie Evaluierungsanstrengungen in die Modellauswahl sowie in schwierige, fehleranfällige Aufgaben und verlagern Sie deterministische Logiken wie Rechenoperationen mit Datumsangaben außerhalb des Modells.
Verwandte Literatur
- Die Auswahl eines Python-AI-Agent-Frameworks im Jahr 2026: Ein praktischer Vergleich — Vergleicht fünf Python-AI-Agent-Frameworks hinsichtlich ihrer Handhabung von Fehlern und Komplexität, um Lesern zu helfen, das richtige Werkzeug für ihren Workflow zu finden.
- Von Rohtext zu Pipelines: Parser, LCEL, Runnables und Speicher in LangChain — Wie LangChain Rohtexte von Modellen in strukturierte Daten umwandelt, Schritte mithilfe von LCEL und der Runnable-Schnittstelle zusammenstellt sowie heute mit konversationaler Speicherung umgeht.