27 razy zbudowałem tego samego bota — oto co naprawdę psuje się po wyjściu z demo

Zbudowałem tego samego bota customer service 27 razy. Ten sam zakres funkcjonalny, te same wymagania, różne frameworki. Potem przepuściłem przez każdy z nich identyczny zestaw 847 rozmów testowych z tymi samymi metrykami ewaluacyjnymi. Wyniki zaskoczyły mnie bardziej niż cokolwiek, co czytałem w dokumentacji. [1]

Dlaczego identyczne wymagania i różne frameworki to jedyna uczciwa metoda

Większość porównań frameworków agentowych wygląda tak samo: autor buduje hello-world w każdym narzędziu, mierzy czas do pierwszego działającego agenta, dodaje gwiazdki GitHub i publikuje ranking. To jest porównywanie opakowań, nie zawartości.

Jedyna uczciwa metoda to identyczne zadanie, identyczne dane testowe, identyczne metryki. Tylko wtedy różnice między frameworkami przestają być kwestią preferencji i stają się mierzalnym faktem.

847 rozmów testowych i metryki, które naprawdę mierzą produkcję

Zestaw 847 rozmów testowych zawierał nie tylko standardowe ścieżki, ale też edge case'y: sfrustrowanego użytkownika, który zmienia zdanie w połowie rozmowy, nieoczekiwane pytania spoza domeny, próby wyjścia poza zakres bota. To właśnie te przypadki rozdzielają frameworki, które działają w demo, od tych, które działają w produkcji. [1]

LangChain vs CrewAI: 6 godzin kontra 45 minut — ale która cena jest wyższa?

Liczby są prawdziwe: LangChain wymagał 6 godzin do działającego agenta, CrewAI — 45 minut. [1] Jeśli optymalizujesz pod developer experience, wybór wydaje się oczywisty. Problem w tym, że to złe kryterium.

Szybki start CrewAI i problem halucynowanych wywołań API

CrewAI pozwala wejść w temat szybko. API jest czytelne, abstrakcje intuicyjne, pierwsze wyniki pojawiają się niemal natychmiast. Ale w testach na 847 rozmowach wyszedł problem, który w demo nigdy się nie pojawia: CrewAI halucynuje fikcyjne wywołania API. [1]

To nie jest błąd, który łatwo wychwycisz na etapie developmentu. Pojawia się w produkcji, przy konkretnych kombinacjach inputu, i generuje ciche błędy trudne do debugowania. W kontekście polskiej firmy wdrażającej bota obsługi klienta — powiedzmy sp. z o.o. z branży e-commerce — taki błąd oznacza złe informacje przekazane klientowi, a w najgorszym przypadku niewykonaną akcję, o której system twierdzi, że ją wykonał.

LangChain: długi onboarding, ale przewidywalne zachowanie w edge case'ach

6 godzin do działającego agenta to realna bariera wejścia. LangChain ma rozbudowaną abstrakcję, dużo konfiguracji i dokumentację, która potrafi przytłoczyć. Ale w testach edge case'owych zachowywał się przewidywalnie. [1] Przewidywalność w produkcji jest warta więcej niż szybkość w developmencie.

Kiedy czas do pierwszego działającego agenta jest złym kryterium wyboru

Jeśli budujesz prototyp na hackathon albo proof of concept dla klienta — 45 minut ma sens. Jeśli budujesz system, który będzie obsługiwał prawdziwych użytkowników przez następne 12 miesięcy, liczy się co innego: jak framework zachowuje się przy wejściu, którego nie przewidziałeś. [2]

Problem z pamięcią: dlaczego AutoGen świetnie wygląda w demo i zawodzi po 3 wymianach

AutoGen robi dobre pierwsze wrażenie. Architektura multi-agent jest elegancka, kod jest czytelny, demo działa płynnie. Potem przychodzą testy produkcyjne i pojawia się konkretny problem: AutoGen traci kontekst rozmowy po 3 wymianach. [1]

Memory gap jako najczęstszy punkt awarii w multi-agent workflows

To nie jest problem specyficzny dla AutoGen — to najczęstszy punkt awarii w systemach wieloagentowych w ogóle. Agent A przekazuje zadanie do agenta B, ale nie przekazuje pełnego kontekstu. Agent B odpowiada na podstawie niekompletnych informacji. Użytkownik dostaje odpowiedź, która ignoruje połowę tego, co powiedział wcześniej.

W praktyce wygląda to tak: użytkownik opisuje problem w pierwszej wiadomości, doprecyzowuje w drugiej, podaje kluczowy szczegół w trzeciej — i właśnie w tym momencie system "zapomina" punkt wyjścia. Dla użytkownika to sygnał, że bot jest bezużyteczny. Dla firmy to utracona konwersja albo eskalacja do konsultanta, której można było uniknąć.

Frameworki memory-first jako odpowiedź branży na ten problem w 2026

Dyskusja na Hacker News z początku 2026 roku pokazuje wyraźną ewolucję: od prostych wrapperów na prompt i tool calls (dominujących w 2024) do systemów modelujących czas, pamięć i porażkę. [3] Kategoria "memory-first frameworks" — gdzie Letta jest najczęściej wymienianym przykładem — wyrasta z konkretnego bólu produkcyjnego, który AutoGen i podobne narzędzia odsłoniły.

To nie jest trend marketingowy. To odpowiedź na realne awarie w realnych wdrożeniach.

Multi-agent hype kontra rzeczywistość: dlaczego Agent A + Agent B działa tylko przy kupowaniu kawy

Systemy wieloagentowe wyglądają przekonująco w każdej prezentacji. Jeden agent zbiera dane, drugi analizuje, trzeci podejmuje decyzję — elegancki podział odpowiedzialności. Problem pojawia się, gdy użytkownik robi coś, czego nie przewidziałeś.

Gdzie systemy wieloagentowe naprawdę się sypią

Wszystkie testowane frameworki multi-agent sypały się przy dwóch scenariuszach: sfrustrowany użytkownik i nieoczekiwany input. [1] Frustracja użytkownika to nie jest edge case — to codzienność w obsłudze klienta. Użytkownik, który zmienia zdanie, cofa się do poprzedniego kroku albo zadaje pytanie spoza domeny, skutecznie dezorientuje systemy zaprojektowane pod liniowe przepływy.

Demo-scenariusze są liniowe. Produkcja nie jest.

LlamaIndex, Mastra, DeerFlow — trzy różne filozofie projektowania agentów

LlamaIndex jest opisywany jako "powerful but exhausting" [1] — narzędzie, które daje dużą kontrolę, ale wymaga dużo konfiguracji i głębokiego zrozumienia tego, co dzieje się pod spodem. Dla doświadczonego developera to zaleta. Dla zespołu, który chce szybko wdrożyć i utrzymywać, to koszt.

Mastra idzie w przeciwnym kierunku: czyste API, dobra obsługa błędów, nie próbuje robić wszystkiego. [1] W testach zachowywała się przewidywalnie, co w kontekście produkcyjnym jest konkretną wartością.

DeerFlow to przypadek, który najbardziej zaskakuje: lepiej obsługuje edge case'y niż frameworki z 50-krotnie większą liczbą gwiazdek na GitHubie. [1] Ograniczenie jest jednak realne — minimalna dokumentacja. Jeśli napotkasz problem, jesteś w dużej mierze zdany na siebie.

Cztery kategorie frameworków, które warto znać: full-stack (LangGraph, CrewAI, AutoGen), provider SDKs (Anthropic, OpenAI), lightweight (Smolagents, Pydantic AI, Mastra, Agno) i specialized (Letta, LlamaIndex, Haystack). [2] Każda kategoria ma sens w innym kontekście — i żadna nie jest domyślnie "lepsza".

Mapa decyzyjna: który framework wybrać zależnie od tego, co budujesz

Zanim wybierzesz framework, odpowiedz na trzy pytania: ile narzędzi potrzebuje twój agent, jak długi jest kontekst i czy zadanie jest sekwencyjne.

Reguła praktyczna: mniej niż 10 narzędzi i zadanie sekwencyjne — single agent wystarczy

Jeśli twój agent używa mniej niż 10 narzędzi, pracuje na mniej niż 50 000 tokenów kontekstu i realizuje zadanie sekwencyjne — single agent wystarczy. [2] Dodawanie kolejnych agentów do prostego problemu nie zwiększa możliwości systemu, za to zwiększa liczbę punktów awarii.

Prosty test z [2]: czy LLM musi decydować, których narzędzi użyć i kiedy przestać? Jeśli tak — potrzebujesz agenta. Jeśli przepływ jest z góry określony — wystarczy zwykły łańcuch wywołań.

Full-stack vs lightweight vs provider SDK — kiedy każda kategoria ma sens

Full-stack (LangGraph, CrewAI, AutoGen) sprawdza się, gdy budujesz złożony system z wieloma agentami i potrzebujesz gotowych abstrakcji do orkiestracji. Płacisz za to złożonością i — jak pokazują testy — potencjalnymi niespodziankami w edge case'ach.

Lightweight (Mastra, Pydantic AI, Smolagents) ma sens, gdy zadanie jest ograniczone, zespół jest mały i priorytetem jest przewidywalność zachowania. Mniej magii, mniej niespodzianek.

Provider SDKs (Anthropic, OpenAI) warto rozważyć, gdy i tak jesteś zablokowany na jednym dostawcy modeli i nie potrzebujesz przenośności. Mniej warstw abstrakcji to mniej miejsc, gdzie coś może pójść nie tak.

Czerwone flagi w dokumentacji, które przewidują problemy produkcyjne

Kilka sygnałów, które warto sprawdzić przed wyborem:

Dokumentacja pokazuje tylko happy path — brak przykładów obsługi błędów to sygnał, że framework nie był projektowany z myślą o produkcji. Brak sekcji o zarządzaniu pamięcią w systemach wieloagentowych to kolejna czerwona flaga. Jeśli wszystkie przykłady są liniowe i nie ma ani jednego scenariusza z nieoczekiwanym inputem — wiesz, że testy były robione w warunkach laboratoryjnych.

Werdykt: boring wins

Trzy miesiące testów i 847 rozmów prowadzą do jednego wniosku: frameworki, które wygrywają w produkcji, to nie te z najlepszym DX ani największą liczbą gwiazdek na GitHubie. To te, które zachowują się przewidywalnie, gdy coś idzie nie tak. [1]

Ekosystem agentowy w 2026 jest dojrzalszy niż dwa lata temu, ale wciąż daleki od stabilności. Większość frameworków była projektowana pod demo, nie pod produkcję. Ewolucja w kierunku modelowania pamięci i porażki [3] to dobry znak, ale nie oznacza, że problem jest rozwiązany.

Zanim wybierzesz framework do następnego projektu, zrób jeden konkretny krok: zbuduj minimalnego agenta i przepuść przez niego 20 rozmów z nieoczekiwanym inputem — sfrustrowany użytkownik, zmiana zdania w połowie, pytanie spoza domeny. Zachowanie frameworka w tych 20 rozmowach powie ci więcej niż cała dokumentacja.

Gwiazdki GitHub mierzą popularność. Twoje testy mierzą niezawodność. Tylko jedno z tych kryteriów ma znaczenie w produkcji.

Źródła

[1] Spent 3 months testing agent frameworks — r/LangChain

[2] Agent Frameworks 101 – The Complete Guide to Building AI Agents in 2026 — Substack

[3] Agentic Frameworks in 2026: Less Hype, More Autonomy — Hacker News

[4] A Comprehensive Empirical Evaluation of Agent Frameworks — arXiv

[5] Top AI Agent Frameworks in 2026: A Production-Ready Comparison — Towards AI

[6] I Tested Every AI Agent Framework So You Don't Have To! (2026) — YouTube