Sześć frameworki agentów AI w Pythonie porównane poprzez budowę tego samego agenta.
Ten sam agent badawczy zaimplementowany w LangGraph, CrewAI, PydanticAI, OpenAI Agents SDK, Smolagents oraz Google ADK, zawierający linie, tokeny, wyniki debugowania oraz przewodnik do wyboru.
Zadaj pytanie grupie ludzi, jakiego frameworku agentów użyć, a otrzymasz tuzin pewnych siebie, sprzecznych odpowiedzi. Jedna grupa uważa LangGraph za nadmiernie skomplikowany. Inna twierdzi, że to jedyna poważna opcja. Trzecia radzi całkowicie pominąć frameworki i komunikować się bezpośrednio z API modelu. Projekt klienta sprawia, że takie rozważania są kosztowne, więc praktycznym rozwiązaniem jest zaprzestanie kłótni i przeprowadzenie eksperymentu.
Eksperyment był prosty: w ciągu jednego weekendu stworzyć identycznego agenta w sześciu frameworkach Pythona, przy użyciu tej samej zadania, tego samego modelu, tych samych narzędzi oraz tej samej metody oceny. Projekt polegał na analizie dokumentów w rozumieniu roku 2026, co oznaczało pobieranie danych z plików PDF, porównywanie ich z bazą danych, pisanie streszczenia oraz wysyłanie wyników e-mailem. Wyniki nie sprzyjają żadnej z tych głośno głoszących opinie grup.
Co zostało stworzone i jak oceniono je
Agent testowy przyjmuje nazwę firmy, wyszukuje najnowsze wiadomości w internecie, wyodrębnia kluczowe dane finansowe, porównuje je z lokalną bazą danych SQLite i zwraca ustrukturyzowany podsumowanie w formacie JSON. To trzy narzędzia, jeden agent oraz jeden schemat wyjściowy.
Celowo jest to nudne. Prawie nikt nie wprowadza autonomicznego agenta do kodowania jako swojego pierwszego systemu produkcyjnego. Większość rzeczywistych zadań związanych z agentami to orkiestrator API z niewielką logiką dodatkową, a każda platforma powinna to bez problemu obsługiwać. GPT-4o służył jako model we wszystkich przypadkach, gdy to było możliwe w danej platformie.
Zmierzono pięć czynników:
- liczbę linii kodu potrzebnych
- liczbę tokenów na jedną próbę, uśrednioną na 10 prób
- średni czas oczekiwania
- liczbę godzin od początku do stworzenia działającego prototypu
- „ocenę naprawczą o godzinie 2 w nocy”, czyli stopień łatwości ustalenia przyczyny awarii w późnych godzinach nocnych
Ta ostatnia miara ma większe znaczenie, niż się wydaje. Rzeczy zawsze się psują.
LangGraph: dla osób, które lubią kontrolę
Około 210 linii kodu. Trzy godziny na stworzenie działającego agenta. 2 847 tokenów na jedną sesję.
LangGraph sprawia wrażenie projektu stworzonego przez inżynierów systemów rozproszonych. Deklaruje się stan, deklaruje węzły, łączy je krawędziami i kompiluje wynik. Brzmi to mniej jak budowa agenta AI, a bardziej jak projektowanie pipeline’u danych, co jest komplementem.
Pierwsza godzina jest trudna. Widok funkcji StateGraph, add_node i add_conditional_edges dla agenta z trzema narzędziami wydaje się zbyt skomplikowany, więc kuszące jest przerwanie pracy i spróba innego rozwiązania.
Następnie awaria zmienia sytuację. Podczas trzeciego zapytania testowego agent zachowywał się bardzo źle, a otwarcie LangSmith pokazało cały przebieg krok po kroku: który węzeł podjął złą decyzję, jaki stan miał, oraz dlaczego wywołał narzędzie bazy danych przed przeprowadzeniem wyszukiwania. Niewiele frameworków umożliwia tak bezpośrednią diagnostykę.
Cecha, o której ludzie rzadko mówią: trwałe wykonywanie. Przerwany proces kontynuuje się od swojego ostatniego punktu kontrolnego. W eksperymencie przeprowadzonym w weekend to przyjemne rozwiązanie. Natomiast w przypadku procesu przetwarzającego 10 000 dokumentów przez noc decyduje to o tym, czy będziesz mógł spać, czy zostaniesz obudzony o 3 rano.
LangGraph wykorzystał również najmniej tokenów podczas testu. Ponieważ graf przedstawia strukturę przepływu sterowania, model nie musi marnować tokenów na decydowanie o tym, co nastąpi dalej – już mu to podano.
Koszt to myślenie z góry. Nie chodzi o wklejanie instrukcji i liczenie na najlepsze. Dobrze zdefiniowany problem sprzyja użyciu odpowiedniej struktury, ale jeśli nadal próbujesz ustalić proces pracy, narysujesz więcej wykresów, niż uda ci się wdrożyć funkcji.
Ocena debugowania o 2 w nocy: 9/10. LangSmith zasłużył na swoją reputację – problemy zostały tu zdiagnozowane szybciej niż gdziekolwiek indziej.
CrewAI: szybki narzędzie do tworzenia prototypów
Około 340 linii kodu. 45 minut na stworzenie działającego agenta. 4 216 tokenów na jedną sesję.
Przejście od polecenia pip install crewai do poprawnego wyniku zajęło trzy kwadranse – to najszybszy start spośród wszystkich narzędzi, z wyjątkiem Smolagents.
CrewAI myśli w zespołach, a nie w pojedynczych agentach. Każdy członek zespołu ma określoną rolę, cel oraz historię, zadania są przekazywane grupie, a członkowie decydują, kto co będzie robił.
researcher = Agent(
role="Financial Research Analyst",
goal="Find and verify recent financial data",
backstory="You're a senior analyst at a hedge fund...",
)
Pole z historią wydarzeń wygląda na zabawne i spotkało się z ironicznym reakcją. Mimo to wyniki uzyskane dzięki agentowi CrewAI były znacznie bardziej szczegółowe niż przy użyciu tego samego zapytania przesłanego przez surowe wywołania API, więc określenie roli faktycznie wpływa na sposób, w jaki model podchodzi do zadania.
Szybkość ma swoją cenę. CrewAI zużył o około 48% więcej tokenów niż LangGraph przy wykonywaniu tego samego zadania. Architektura zakłada współpracę co najmniej dwóch lub trzech agentów, więc nawet badacz w połączeniu z pisarzem – zadanie, które jeden agent mógłby wykonać – wymagało dodatkowych kosztów związanych z delegowaniem zadań. Ponadto system działa synchronicznie, a wdrożenie go w asynchronicznym backendzie FastAPI wymagało otaczania wywołań funkcją run_in_executor. To do zniesienia, choć irytujące.
Koszty szybko rosną. Według jednego z opublikowanych porównań koszt testowania CrewAI wyniósł 1 088 dolarów, podczas gdy odpowiednia wersja PydanticAI kosztowała 390 dolarów. Jeśli agent będzie uruchamiany tysiące razy dziennie, różnica będzie się jeszcze bardziej powiększać.
W skali debugowania otrzymuje ocenę 5/10 o 2 w nocy. Sukcesy są wspaniałe, ale niepowodzenia zanikają w łańcuchu delegacji, który funkcjonuje jak czarna skrzynka. Jeden błąd pochłonął 40 minut, zanim okazało się, że chodziło o dwa agenty przekazujące sobie nawzajem tę samą zadanie.
PydanticAI: cichy nadmiarowca
Około 130 linii kodu. 1,5 godziny na stworzenie działającego agenta. 2 912 tokenów na jedną rundę.
Jeśli LangGraph nadaje się dla tych, którzy cenią kontrolę, a CrewAI dla niecierpliwych, to PydanticAI jest odpowiedni dla programistów, którzy chcą, aby kod był zrozumiały już po sześciu miesiącach. Został stworzony przez zespół Pydantic, a każdy, kto korzystał już z FastAPI, zna połowę tej API. Agenci są typowani, wyniki weryfikowane, a zależności wstrzykiwane, więc wszystko, co można wykryć przed uruchomieniem, faktycznie zostaje wykryte.
agent = Agent(
"openai:gpt-4o",
result_type=CompanyAnalysis, # Pydantic model
system_prompt="You are a financial research assistant.",
)
Argument result_type pełni więcej funkcji, niż się wydaje. Każda odpowiedź modelu jest automatycznie sprawdzana pod kątem Twojego schematu. Gdy model zwraca niepoprawny JSON, co w końcu się zdarza, framework to wykrywa i próbuje ponownie, więc nie jest potrzebny ręcznie napisany kod walidacyjny.
W projekcie full-stack-ai-agent-template przeprowadzono kontrolowane porównanie zgodne z tym wzorcem. Ta sama aplikacja do czatowania wymagała około 160 linii kodu w PydanticAI, około 280 w LangGraph oraz około 420 w CrewAI.
Kod krótszy nie jest automatycznie lepszy, ale w tym przypadku sprawdzono, jak szybko można zrozumieć każdą wersję. Wersję PydanticAI można było czytać i rozumieć linijka po linijce. Wersja LangGraph wymagała mentalnego śledzenia struktury grafu, natomiast wersja CrewAI wymagała zrozumienia jego modelu delegacji.
Ograniczeniem jest to, że PydanticAI to framework oparty na jednym agencie. Nie posiada wbudowanej orkiestracji wielu agentów, przekazywania zadań ani delegowania, więc projekt z trzema agentami oznacza konieczność samodzielnego napisania mechanizmów koordynacji. Istnieje moduł pydantic-graph, ale na razie nie dorównuje LangGraph ani CrewAI pod względem obsługi złożonych procesów pracy.
Debugowanie późną nocą oceniam na 8/10. Błędy typu pojawiają się wcześnie, IDE wskazuje problemy jeszcze przed uruchomieniem kodu, a ścieżki stosu pokazują właściwą linię kodu.
OpenAI Agents SDK: hit, który nie zyskał dużego rozgłosu
Około 150 linii kodu. Godzina na stworzenie działającego agenta. 2,791 tokenów na jedno uruchomienie.
Framework od dostawcy modeli brzmi jak mechanizm zmuszający do pozostania przy jego rozwiązaniach, i prawie nie trafił do testów. To oczekiwanie okazało się błędne.
SDK to produkcyjna wersja projektu Swarm stworzona przez OpenAI, składająca się z czterech podstawowych elementów: Agentów, Przekazywania zadań, Narzędzi oraz Zasad bezpieczeństwa. Najważniejszym z nich jest mechanizm Przekazywania zadań – określasz, które agenty mogą przekazywać zadania innym, a framework zajmuje się ich kierowaniem. Jest mniej elastyczny niż model grafowy LangGraph, ale dla około 80% zastosowań wieloagentowych wystarcza i jest znacznie prostszy.
agent = Agent(
name="Researcher",
instructions="You are a financial research assistant.",
tools=[search_tool, db_tool],
handoffs=[summary_agent],
)
Nie jest już również powiązany z jednym dostawcą. Obsługa ponad 100 modeli LLM została zapewniona dzięki adapterowi any-llm, a ten sam test został przeprowadzony z Claude bez żadnych zmian w kodzie.
Efektywność tokenów dorównywała LangGraph, co dało im najniższy wynik w teście. Wbudowany mechanizm śledzenia jest solidny, choć o krok w tyle za LangSmith.
Wadą jest mniejszy ekosystem. LangGraph posiada lata doświadczeń społeczności, tutoriale oraz sprawdzone wzorce. Tutaj produkt jest nowszy, więc w trudnych przypadkach często jesteś sam.
Ocena pod kątem debugowania o 2 w nocy: 7/10. Śledzenie jest wbudowane i przydatne, a błędy są wyraźne. Braki w dokumentacji sprawiają jednak, że trzeba częściej czytać kod źródłowy, niż byłoby to pożądane.
Smolagents: wybór minimalistów
Około 95 linii kodu. 30 minut na stworzenie działającego agenta. 3 340 tokenów na jedną sesję.
Te liczby to nie błąd drukarski. Rozwiązanie Hugging Face traktuje minimalizm poważnie – jego podstawowa logika składa się z zaledwie około 1 000 linii kodu w Pythonie, które można przeczytać w ciągu popołudnia. Spróbuj tego z LangGraph.
Różnica nie leży tylko w rozmiarze. Wszystkie inne frameworki tutaj wykorzystują wywołania narzędzi JSON, przy których agent wysyła informację o tym, jaką funkcję uruchomić z jakimi argumentami. Natomiast CodeAgent z Smolagents pisze prawdziwy kod w Pythonie.
agent = CodeAgent(
tools=[search_tool, db_tool],
model=InferenceClientModel(),
)
result = agent.run("Analyze recent financial news for Acme Corp")
Pisanie kodu umożliwia agentom naturalne łączenie narzędzi za pomocą pętli, warunków oraz łańcuchowych operacji, których nie mogą wyrazić wywołania JSON. Badania benchmarkowe potwierdzają to, ponieważ agenci kodowi osiągają lepsze wyniki niż te oparte na JSON w większości testów.
Kompromis dotyczy bezpieczeństwa, ponieważ agent generuje i uruchamia kod w Pythonie. Sandboxing jest dostępny za pośrednictwem E2B, Dockera i Pyodide, ale trzeba go samodzielnie skonfigurować. Domyślny LocalPythonExecutor wyraźnie nie stanowi bariery bezpieczeństwa, co podaje się w jego dokumentacji.
Użycie tokenów było wyższe w porównaniu z LangGraph i SDK OpenAI. Generowany kod w Pythonie jest bardziej rozbudowany w porównaniu z zwięzłym JSON, a każde importowanie oraz deklaracja zmiennej kosztuje tokeny.
Z Gemini lub GPT działa bez problemów, ale wydaje się nieco nieodpowiedni. Wyróżnia się dzięki modelom i infrastrukturze Hugging Face, a integracja z Hubem, która umożliwia udostępnianie i ładowanie agentów w taki sam sposób jak modeli, jest doskonała, jeśli już pracujesz w tym ekosystemie.
Ocena debugowania o godzinie 2 w nocy: 8/10. Czytanie kodu napisanego przez agenta jest lepsze niż dekodowanie serii wywołań narzędzi w formacie JSON, a w przypadku błędu pojawia się zwykły stack trace w Pythonie.
Google ADK: konik firmowy
Około 180 linii kodu. Dwie godziny na stworzenie działającego agenta. 3 102 tokeny na jedną rundę.
Kit rozwoju agentów Google pojawił się cicho w 2025 roku, a wielu programistów Pythona w ogóle go nie wypróbowało. To luka, którą warto zamknąć.
ADK ma wyraźne zdanie na temat struktury, ale jest elastyczny pod względem realizacji, co jest typowe dla narzędzi wewnętrznych Google. Agenci są definiowani za pomocą modelu, nazwy, instrukcji oraz narzędzi, podobnie jak w SDK OpenAI. Na górze znajdują się agenci do zarządzania przepływem pracy (sekwencyjni, równolegli i pętlowe), a także nowsza API AgentTeam do koordynacji kilku agentów.
from google.adk.agents import Agent
root_agent = Agent(
model="gemini-2.5-flash",
name="financial_analyst",
instruction="You are a financial research assistant.",
tools=[search_tool, db_tool],
)
Ramka oceny jest tym, co odróżnia ten narzędzie. Przypadki testowe są zapisywane w formacie JSON, adk eval je uruchamia, a użytkownik otrzymuje ustrukturyzowane raporty dotyczące tego, czy zachowanie odpowiada oczekiwaniom. Żadna inna z dostępnych ram nie oferuje tak rozwiniętych narzędzi do oceny.
Rozwój w produkcji również przebiega gładko, pod warunkiem korzystania z Google Cloud. Vertex AI Agent Engine zajmuje się skalowaniem, monitorowaniem i sesjami, ale ten warunek ma duże znaczenie.
ADK jest dostosowany do Gemini. Inne modele działają za pośrednictwem LiteLLM, jednak dokumentacja, przykłady i narzędzia zakładają użycie Gemini. Uruchamianie GPT-4o napotkało nieodnotowane przypadki specjalne, których rozwiązanie zajęło 45 minut.
Ocena podczas debugowania o 2 w nocy: 6/10. Interfejs deweloperski adk web pomaga. Jednak komunikaty o błędach są czasami niejasne, a dokumentacja jest obszerna w typowy dla Google sposób, co utrudnia jej nawigację.
Które wybrać
"To zależy" frustruje wszystkich, więc oto logika decyzyjna, która powstała po sześciu próbach stworzenia agenta:
- Wydanie do piątku: wybierz CrewAI lub Smolagents. CrewAI nadaje się dla zespołów, które nie czują się komfortowo z debugowaniem wykonywania kodu w Pythonie. Smolagents nadaje się dla tych, którzy potrafią to robić i chcą mieć jak najmniejsze wymagania co do zależności.
- Must run reliably for months: wybierz LangGraph lub PydanticAI. LangGraph nadaje się do logiki rozgałęzień, kroków z udziałem człowieka oraz wymogów trwałego wykonywania. PydanticAI nadaje się głównie do pracy z pojedynczym agentem przy strukturyzowanych wynikach, gdzie przyszli czytelnicy powinni rozumieć kod.
- Already committed to an ecosystem: wybierz OpenAI Agents SDK na platformie OpenAI ze względu na możliwości śledzenia i oceny, lub Google ADK na GCP ze względu na natywną integrację z Vertex AI oraz wbudowane narzędzia oceny.
Najtrudniejszą kwestią jest to, że w przypadku większości projektów framework ma mniejsze znaczenie niż projektowanie promptów i narzędzi. Jakość wyników była niemal identyczna we wszystkich sześciu przypadkach, gdy prompt systemu oraz opisy narzędzi otrzymały należytą uwagę. Różnice występowały natomiast w doświadczeniu programisty, możliwościach debugowania oraz kosztach operacyjnych.
Ustalona konfiguracja produkcyjna to: PydanticAI do zadań z jednym agentem, które stanowią większość pracy, oraz LangGraph, gdy proces jest naprawdę złożony. Nie ma potrzeby przepraszać za używanie dwóch frameworków.
Wszystkie sześć obok siebie
| Metric | LangGraph | CrewAI | PydanticAI | OpenAI SDK | Smolagents | Google ADK |
| ----------------- | ----------- | --------------- | ------------- | ---------------- | --------------- | --------------- |
| Lines of code | ~210 | ~340 | ~130 | ~150 | ~95 | ~180 |
| Time to prototype | 3 hrs | 45 min | 1.5 hrs | 1 hr | 30 min | 2 hrs |
| Avg tokens/run | 2,847 | 4,216 | 2,912 | 2,791 | 3,340 | 3,102 |
| Multi-agent | Yes (graph) | Yes (teams) | Manual | Yes (handoffs) | Yes (hierarchy) | Yes (AgentTeam) |
| Type safety | TypedDict | Pydantic config | Full generics | Generic context | Minimal | Standard |
| MCP support | Yes | Limited | Native + A2A | Native | Yes | Yes |
| Model-agnostic | Yes | Yes | Yes (20+) | Yes (100+) | Yes (LiteLLM) | Gemini-first |
| Best debugger | LangSmith | Logs | IDE/types | Built-in tracing | Code output | ADK Web UI |
| GitHub stars | ~48K | ~44K | ~15K | ~16K | ~26K | ~23K |
| 2 AM debug | 9/10 | 5/10 | 8/10 | 7/10 | 8/10 | 6/10 |
Żaden z tych danych nie opisuje całej historii, ale stanowią one bardziej uczciwy punkt wyjścia niż większość postów porównawczych.
Oczekuj zmian
Te frameworki zmieniają się szybciej, niż ktokolwiek może je udokumentować. Podczas pisania tego tekstu LangGraph wypuścił ważną aktualizację. Poziom enterprise CrewAI otrzymał nowe integracje w ciągu tygodnia. PydanticAI dodało wsparcie dla protokołu A2A, a Google ADK kilka dni wcześniej wprowadziło funkcję SkillToolset.
Każde porównanie ma określony czas ważności. Za sześć miesięcy różnice w wydajności mogą się zmniejszyć, mogą pojawić się brakujące funkcje, a framework, który odrzuciłeś, może stać się oczywistym wyborem. Dlatego wybierz ten, z którym twoja zespół może naprawiać błędy o 2 w nocy, gdy cały proces jest wstrzymany, a klient czeka, a nie ten z największą liczbą gwiazdek na GitHubie.
Pozycje pokrewne
- Agent Plugins 1.0.0: Ujednolicony format pakietowania umiejętności i serwerów MCP — Agent Plugins 1.0.0 standaryzuje foldery pluginów, plik plugin.json, umiejętności oraz plik mcp.json we wszystkich klientach. Opisuje, co obejmuje, a co pomija pod względem bezpieczeństwa, oraz przedstawia przykład użycia Google Agents CLI.
- MCP, A2A i ACP w praktyce: Jak bank łączy narzędzia i agenty — Opisuje, w jaki sposób MCP, A2A i ACP dzielą zadania związane z łączeniem modeli z narzędziami oraz agentami ze sobą, na przykładzie asystenta bankowego zajmującego się oszustwami i pożyczkami.