LangGraph czy CrewAI? Nawet trzykrotnie więcej tokenów zmienia wybór

Jeśli aplikacja musi zachować kontrolę nad stanem i obrać inną ścieżkę po błędzie narzędzia, wybrałbym LangGraph. Gdy praca rzeczywiście wymaga współpracy agentów o odrębnych rolach, CrewAI daje prostszy punkt wyjścia. Koszt tej wygody widać w benchmarku AIMultiple: przy pojedynczym wywołaniu narzędzia badana konfiguracja CrewAI zużyła niemal trzykrotnie więcej tokenów promptu niż LangChain, a LangGraph miał w tym zadaniu podobnie niski narzut jak LangChain.

To porównanie konkretnych konfiguracji, a nie stały przelicznik dla obu produktów. Wybór zmienia się wraz z zadaniem: dodatkowe etapy współpracy podnoszą koszt krótkiej operacji, lecz ścieżka zastępcza po awarii również może pochłonąć wiele tokenów. Dlatego obok kosztu trzeba rozpatrzyć sposób przechowywania wyników pośrednich i zachowanie agenta, kiedy narzędzie przestaje działać.

Co obejmował benchmark

Autorzy testu opisują 2000 przebiegów: każde z pięciu zadań uruchomiono po 100 razy w czterech konfiguracjach. Użyto tego samego modelu GPT-5.2, temperatury 0,1, poleceń i zestawu narzędzi, a stan narzędzi resetowano przed każdym przebiegiem. Zadania oparto na zbiorze IBM Telco Customer Churn obejmującym 7032 klientów. Porównano LangChain z AgentExecutor, LangGraph ze StateGraph, AutoGen z AssistantAgent i UserProxyAgent oraz CrewAI z Agent, Task i Crew.

• Prosta agregacja: jedno wywołanie narzędzia i zwrócenie wyniku ujawniają koszt dodatkowej orkiestracji.
• Dwie grupy filtrów: agent zachowuje oddzielne wyniki i łączy je w odpowiedzi, co sprawdza prowadzenie stanu.
• Warunki liczbowe: polecenie w języku naturalnym trzeba przełożyć na parametry narzędzia i zachować ich wartości po ponowieniu.
• Awaria narzędzia: następujące po sobie błędy sieci, przekroczenia czasu i limitu wywołań sprawdzają, czy agent czeka, ponawia próbę czy wybiera inną drogę.
• Dane mieszane: agent rozpoznaje kolumny JSON i tekstowe, po czym dobiera narzędzia do obu rodzajów danych.

Wyniki obejmują zachowanie całych konfiguracji: ich instrukcje, wywołania modelu, narzędzia i decyzje o kolejnych krokach. Nie wyodrębniają samego czasu pracy biblioteki. Jest to istotne również dla kosztów: większa liczba tokenów promptu może wynikać z przekazywania historii agentowi, ponowień albo dodatkowej weryfikacji, a nie z jednej niezmiennej opłaty narzucanej przez framework.

Kiedy dodatkowe tokeny zmieniają rachunek

W prostej agregacji LangChain i LangGraph kończyły zadanie w czasie poniżej pięciu sekund, zużywając mniej niż 900 tokenów promptu. Badana załoga CrewAI przechodziła przez etapy planisty i analityka oraz weryfikację, choć cel wymagał tylko użycia narzędzia i oddania odpowiedzi. Przy dużej liczbie takich krótkich operacji koszt koordynacji powraca w każdym przebiegu. To argument przeciw wprowadzaniu wieloagentowej załogi wyłącznie dlatego, że pierwszy przykład łatwo zbudować.

W zadaniu z dwiema grupami filtrów CrewAI zużywał niemal dwukrotnie więcej tokenów niż pozostałe konfiguracje i w części przebiegów osiągał limit iteracji bez wyniku JSON. Inny problem ujawnił test progów liczbowych: po błędzie parsowania niektóre ponowienia zmieniały uprzednio poprawne parametry. Dla aplikacji liczącej wartości na podstawie danych wejściowych koszt takiego przebiegu obejmuje więc również ryzyko błędnej odpowiedzi, którego sama liczba tokenów nie pokazuje.

Przy awarii relacja kosztów była odwrotna. LangGraph wybrał obejście wymagające kolejnych wywołań i przekazywał rosnącą historię wyników pośrednich do modelu; zużył więcej tokenów niż CrewAI, które pozostawało przy pierwotnym planie. Niższy wydatek na tokeny w tym zadaniu nie oznaczał lepszej reakcji na błąd. Liczby z prostego wywołania nie wystarczą zatem do oszacowania kosztu procesu, w którym liczą się ponowienia, czas oczekiwania i uzyskanie użytecznego wyniku.

Co dzieje się po błędzie narzędzia

W teście awarii LangGraph i AutoGen zmieniały strategię w około 90 proc. przebiegów, korzystając z innych narzędzi do filtrowania i obliczeń. Badana konfiguracja CrewAI nie porzuciła pierwotnego planu w obserwowanych przebiegach: czekała na działające narzędzie lub próbowała rozwiązania bliskiego pierwotnej ścieżce. To wynik przygotowanego zadania, nie gwarancja zachowania każdej aplikacji zbudowanej w którymkolwiek z tych frameworków.

Różnicę dobrze widać na poziomie informacji dostępnych agentowi. Gdy błąd staje się częścią stanu albo kolejną obserwacją, model może uwzględnić go przy wyborze następnej czynności. Gdy wyjątek kończy wykonanie lub logika procesu prowadzi z powrotem do tej samej operacji, szansa na zmianę strategii zależy od dodatkowego kodu. W testowanym AgentExecutor surowy wyjątek narzędzia początkowo przerywał pracę; po zamianie go na komunikat widoczny dla agenta konfiguracja mogła skorzystać z obejścia.

LangGraph: jawny stan i ścieżki odzyskiwania

Dokumentacja LangGraph opisuje węzły, które odczytują współdzielony stan, zapisują w nim wynik i wskazują następny etap. Dla przejściowej awarii można ustawić ponowienia. Błąd możliwy do obsłużenia przez model można zapisać w stanie i skierować wykonanie z powrotem do agenta; po wyczerpaniu prób można przejść do funkcji odzyskiwania lub kompensacji. Programista określa te przejścia, zamiast zdawać się na samą decyzję modelu.

Przerwanie pozwala zatrzymać graf przed czynnością wymagającą udziału człowieka, a checkpointer przechowuje stan potrzebny do wznowienia. Granice węzłów mają tu znaczenie praktyczne: po awarii wznowienie zaczyna się od węzła, w którym wykonanie zostało zatrzymane. Jeśli jeden węzeł łączy pobranie danych z dalszym przetwarzaniem, obie operacje mogą wykonać się ponownie. Bardziej szczegółowy podział ułatwia ustalenie, co zostało już ukończone, lecz wymaga staranniejszego zaprojektowania grafu.

CrewAI: załoga i Flow pełnią różne role

Dokumentacja CrewAI rozdziela Crews, czyli zespoły agentów z rolami, celami i narzędziami, od Flows, które określają kolejność pracy i przenoszą stan między etapami. Flow może uruchomić załogę do zadania wymagającego współpracy, odebrać wynik i skierować proces dalej. CrewAI nie jest więc pozbawiony mechanizmów stanu ani rozgałęzień; oferuje je na innym poziomie niż definicja samej załogi.

Gdy zadanie naturalnie dzieli się między specjalistów, zapisanie ról i delegacji w Crew może uprościć konstrukcję aplikacji. Jeśli jednak po awarii ma nastąpić określona czynność zastępcza, samo utworzenie agentów jej nie zapewnia. Taką decyzję trzeba przewidzieć w Flow albo w logice zadania. Benchmark pokazuje ograniczenie badanej konfiguracji Agent–Task–Crew, lecz nie jest pomiarem procesu, w którym załogę otacza dodatkowy Flow.

Dlaczego wynik LangChain nie jest wynikiem LangGraph

Warto oddzielić dwa pomiary, które łatwo zlać w jedno. Niemal trzykrotny narzut CrewAI w prostym zadaniu liczono względem testowej konfiguracji LangChain z AgentExecutor; LangGraph badano osobno jako StateGraph. Podobny niski koszt tych dwóch konfiguracji w tej próbie nie daje podstaw, by przenieść dokładnie ten sam współczynnik na każdą aplikację LangGraph. Zwłaszcza przy awarii graf może zużyć więcej tokenów, jeśli wybierze dłuższe, lecz skuteczne obejście.

Różnica dotyczy także wyboru narzędzia do nowego projektu. Materiały LangChain wyjaśniają, że współczesne implementacje agentów LangChain korzystają z prymitywów LangGraph, a bezpośrednie użycie LangGraph daje głębszą kontrolę. Wynik starszego AgentExecutor nie jest zatem prognozą kosztu agenta zbudowanego dziś innym API. Jeśli najważniejsze są określone przejścia, wznowienie i reakcja na awarię, przewagę architektoniczną ma jawny graf. Jeśli wartość przynosi współpraca agentów, CrewAI pozostaje sensownym wyborem, pod warunkiem uwzględnienia kosztu tej współpracy i zaprojektowania zachowania po błędzie.

Przeczytaj także:

• PostgreSQL czy MySQL? Benchmark zmienia zwycięzcę wraz z operacją
• Freemium czy trial? Więcej rejestracji nie musi dawać więcej klientów
• Pinecone czy pgvector? Filtry potrafią zmienić zwycięzcę