Gdy po raz pierwszy wdrażaliśmy agenta AI dla klienta z branży produkcyjnej — zadanie: automatyzacja raportowania z wielu systemów — naiwnie uruchomiliśmy prostą pętlę z jednym LLM i zestawem narzędzi. Działało... dopóki nic nie szło inaczej niż powinno. Gdy jedno z narzędzi zwróciło nieoczekiwany wynik, agent wpadł w pętlę i przez 40 minut generował tokeny, zanim ręcznie go zatrzymaliśmy. Problem nie leżał w modelu. Problem tkwił w architekturze — nieprzygotowanej na realne warunki.
Dziś istnieją trzy dominujące wzorce architektur AI agentów: ReAct, Plan-and-Execute i refleksja. Każdy ma swoje miejsce, każdy ma ograniczenia. Ten artykuł to framework decyzyjny — kiedy wybrać dany wzorzec, czego od niego oczekiwać i gdzie może przysporzyć problemów.
Dlaczego wybór architektury ma znaczenie
Wybór architektury to nie tylko detal techniczny. Bezpośrednio wpływa na cztery metryki, które liczą się w produkcji:
- Niezawodność — jak agent reaguje na nieoczekiwane wyniki narzędzi lub błędy
- Koszty — ile tokenów zużywa na jedno zadanie
- Latencja — jak szybko użytkownik otrzymuje wynik
- Debugowalność — jak łatwo znaleźć, gdzie i dlaczego agent zawiódł
Ważne zastrzeżenie: ReAct, Plan-and-Execute i Reflexion to wzorce akademickie z lat 2022–2023 (Yao et al. 2022 dla ReAct). LangGraph, AutoGen, CrewAI i inne frameworki te wzorce *implementują* — ale ich nie wymyśliły. Wybór frameworku to decyzja drugorzędna. Pierwszorzędna jest wybór wzorca.
ReAct: pętla Reason-Act-Observe
ReAct (Reasoning + Acting) to najprostszy i najbardziej rozpowszechniony wzorzec. Agent działa w pętli:
- 1.Reason — na podstawie aktualnego stanu i historii LLM „myśli" (generuje tekst opisujący rozumowanie)
- 2.Act — wybiera i wywołuje narzędzie z konkretnymi parametrami
- 3.Observe — otrzymuje wynik narzędzia, wstawia go do kontekstu
- 4.Powtarza, aż osiągnie cel lub dojdzie do finalnej odpowiedzi
Mocną stroną ReAct jest adaptowalność. Jeśli coś zmieni się w trakcie działania — narzędzie zwróci nieoczekiwany wynik, API zmieni format — agent widzi to w fazie Observe i może zmienić podejście. Nie według wcześniej napisanego planu, lecz reaktywnie.
Gdzie ReAct działa dobrze
- Zadania z 2–4 krokami i jasnym celem (wyszukaj X, przetwórz Y, zapisz Z)
- Interaktywne narzędzia, gdzie kontekst zmienia się w czasie rzeczywistym
- Prototypowanie — ReAct jest najszybszy we wdrożeniu
- Gdy zależy na prostym audit logu (każdy krok Reason-Act-Observe jest widoczny)
Gdzie ReAct zawodzi
- Długie zadania z wieloma krokami — każdy nowy krok dodaje do kontekstu całą historię, koszty rosną kwadratowo
- Zadania równoległe — ReAct jest sekwencyjny, nie może jednocześnie wykonywać wielu gałęzi
- Bez limitu `max_steps` jest niebezpieczny — to nie przesada. Agent bez ustawionego limitu kroków może w nocy utknąć w pętli i wygenerować tysiące zbędnych wywołań API — a wraz z nimi rachunek rzędu tysięcy euro. Widzimy to w praktyce, to nie jest ryzyko hipotetyczne.
Ważna korekta powszechnego mitu: słowo „Reason" w ReAct *nie oznacza*, że agent rzeczywiście rozumuje poprawnie. Krok Reason to wyjście językowe — LLM generuje tekst, który wygląda jak rozumowanie. Może być pełen błędów, a model w żaden sposób tego nie sygnalizuje. Nieweryfikowalne „myślenie" to jedna z najczęstszych przyczyn cichego zawodzenia agentów ReAct.
Profil kosztowy ReAct
Typowe zadanie ReAct zużywa 2 000–3 000 tokenów przy 3–4 krokach. Przy 8+ krokach zużycie może wynieść 10 000–20 000 tokenów na jedno zadanie, ponieważ cała historia powtarza się w każdym oknie kontekstowym. Przy produkcyjnym obciążeniu zauważysz to na fakturze.
Plan-and-Execute: najpierw plan, potem kroki
Plan-and-Execute (P&E) dzieli agenta na dwie fazy:
- 1.Planner — otrzymuje cel i generuje eksplicytny plan kroków (np. „krok 1: pobierz dane z API, krok 2: przekształć format, krok 3: zapisz do bazy danych, krok 4: wyślij raport")
- 2.Executor — wykonuje kroki zgodnie z planem, jeden po drugim, bez ponownego planowania
Kluczowa zaleta: planner i executor nie muszą być tym samym modelem. To ekonomicznie interesujące — drogi, mocny model (np. klasy Claude Opus lub GPT) zajmuje się planowaniem, gdzie liczy się jakość. Tani, szybki model wykonuje execution, gdzie liczy się szybkość i cena. Dla długich zadań z N krokami może to być tańsze niż czysty ReAct.
Gdzie P&E działa dobrze
- Długie, ustrukturyzowane zadania (5+ kroków z jasną logiką)
- Przetwarzanie wsadowe — gdy trzeba przetworzyć 1 000 dokumentów tym samym procesem
- Audytowalne pipeline — plan to eksplicytny dokument, klient widzi go przed uruchomieniem
- Odporność na prompt injection — badania sugerują, że P&E ma pewną inherentną przewagę: executor nie ma dostępu do instrukcji planowania, atakujący w danych trudniej go więc przekieruje (nie jest to jednak pełna ochrona)
Gdzie P&E zawodzi
Podstawowy P&E ma stały plan. Gdy warunki zmieniają się w trakcie działania — API zwraca inny format, krok 3 kończy się błędem — agent kontynuuje według starego planu lub utknie. Dynamic replanning (ponowne planowanie po błędzie) to rozszerzenie, nie cecha podstawowa P&E. Trzeba je zaimplementować eksplicytnie.
Kolejny mit do obalenia: P&E *nie jest zawsze dokładniejszy* niż ReAct. W dynamicznym środowisku, gdzie warunki zmieniają się w trakcie działania, ReAct jest bardziej adaptowalny. P&E sprawdza się lepiej tam, gdzie środowisko jest przewidywalne i plan pozostaje ważny do końca.
Profil kosztowy P&E
Typowe zadanie P&E zużywa 3 000–4 500 tokenów (łącznie z fazą planowania). Na pierwszy rzut oka drożej niż ReAct. Ale dla zadań z 8+ krokami łączne zużycie jest niższe — executor pracuje z krótszym kontekstem niż pętla ReAct, która akumuluje całą historię. Rekomendacja: dla krótkich zadań (2–4 kroki) wybierz ReAct, dla długich (6+ kroków) rozważ P&E.
Refleksja i self-critique
Refleksja (Reflexion, Shinn et al. 2023) dodaje nad ReAct lub P&E warstwę samooceny:
- 1.Agent wykonuje zadanie (ReAct lub P&E)
- 2.Moduł refleksji ocenia wynik — „czy cel został osiągnięty? Gdzie wystąpiły błędy?"
- 3.Na podstawie refleksji pamięć agenta jest aktualizowana lub krok jest powtarzany ze zmodyfikowanym podejściem
Przykład wyników: na zadaniach z CodeContests GPT-4 przeszedł z około 19 % skuteczności przy prostym prompcie do około 44 % z iteracyjnym podejściem test-driven (opublikowany flow AlphaCodium). To realny wzrost — właśnie przy zadaniach z deterministyczną weryfikacją.
Gdzie refleksja pomaga
- Zadania kodowania z deterministyczną weryfikacją (kod albo przeszedł testy, albo nie)
- Iteracyjne wyniki — gdy pierwsza wersja nigdy nie jest wystarczająca i chcesz automatyczne ulepszanie
- Złożone analizy, gdzie potrzebujesz drugiego spojrzenia na wynik
Ograniczenia refleksji
Krytyczne ograniczenie: gdy ten sam model generuje wynik i krytykę, refleksja ma tendencję do powtarzania tych samych błędów. Model nie widzi luk we własnym rozumowaniu. Badania replikacyjne z 2025 roku to potwierdziły — single-agent Reflexion w iteracyjnych cyklach konwerguje do tej samej (błędnej) odpowiedzi. Rozwiązaniem jest albo inny model do weryfikacji, albo zewnętrzny deterministyczny weryfikator (testy, linter, walidacja schematu).
Więcej o tym, jak guardrails dla agentów AI pomagają wyłapać te błędy zanim dotrą do użytkownika.
Kiedy wystarczy jedno wywołanie LLM
Przed wyborem architektury agenta trzeba zadać pytanie: *czy naprawdę potrzebuję agenta?*
Szacujemy, że 40–50 % przypadków użycia, z którymi klienci przychodzą z żądaniem agenta, obsłuży jedno lub dwa wywołania LLM bez żadnej pętli. Przykłady:
- Klasyfikacja dokumentu (jedno wywołanie, structured output)
- Ekstrakcja pól z faktury (jedno wywołanie + tryb JSON)
- Generowanie raportu z przygotowanych danych (jedno wywołanie, długi prompt)
- Podsumowanie z cytowaniami (jedno wywołanie + pipeline agentic RAG)
Zasada: jeśli potrafisz z góry dokładnie zdefiniować wejścia, wyjścia i transformację — agent nie jest potrzebny. Agent dodaje wartość, gdy kroki nie są z góry znane lub środowisko jest dynamiczne.
Powiązana decyzja: chatbot vs copilot vs agent — gdzie przebiegają dokładne granice między tymi pojęciami.
Framework decyzyjny
Zamiast tabeli (która upraszczałaby trade-off) proponujemy serię pytań:
1. Ile kroków ma zadanie? - 1–3 kroki → jedno wywołanie LLM lub prosty ReAct - 4–7 kroków, przewidywalne środowisko → Plan-and-Execute - 8+ kroków z logiką równoległą → P&E + executor DAG lub multi-agent
2. Czy środowisko zmienia się w trakcie działania? - Nie (przetwarzanie wsadowe, deterministyczny proces) → P&E - Tak (interaktywne, dane real-time, nieprzewidywalne API) → ReAct
3. Czy potrzebujesz audytowalnego wyniku? - Tak, klient chce widzieć plan przed uruchomieniem → P&E - Nie, liczy się wynik → ReAct (krótszy czas do uruchomienia)
4. Jaki jest koszt błędu? - Niski (narzędzie wewnętrzne, łatwo naprawić) → ReAct z limitem max_steps - Wysoki (klient, obszar regulowany) → P&E + refleksja + human-in-the-loop
5. Czy masz dedykowany zespół do utrzymania? - Nie → Możliwie najprostszy wzorzec. ReAct z jasnym max_steps, logowanie każdego kroku. - Tak → Możesz sobie pozwolić na P&E + dynamic replanning + refleksja.
Architektury hybrydowe w praktyce
W produkcji prawie nigdy nie widzimy czystego ReAct ani czystego P&E. Typowe kombinacje:
- P&E + executor ReAct — planner generuje kroki, każdy krok wykonuje mini-agent ReAct z dostępem do narzędzi
- ReAct + refleksja — po zakończeniu pętli ReAct uruchamia się moduł refleksji, który ocenia jakość wyniku
- P&E + dynamic replanning — przy błędzie kroku cały plan jest weryfikowany na nowo, nie tylko dany krok
LangGraph jest dziś de facto standardem dla implementacji tych hybrydowych wzorców w Pythonie. Alternatywy jak AutoGen (Microsoft) czy CrewAI są mocne w koordynacji multi-agent, ale LangGraph ma największy ekosystem i stabilność produkcyjną.
Szersze spojrzenie na to, ile kosztuje agent w produkcji, w tym cennik per-wywołanie i sposoby optymalizacji, znajdziesz w osobnym artykule.
Debugowalność — niedoceniany wymiar
Architektura wpływa również na to, jak łatwo znaleźć błąd. Z praktyki:
ReAct: Każdy krok Reason-Act-Observe jest widoczny w trace logu. Gdy agent zawodzi przy kroku 7, widać dokładnie, jaki wejściowy Observe otrzymał i jaki Reason wygenerował. Dobrze debugowalny — jeśli masz poprawnie zalogowany każdy krok.
P&E: Plan to eksplicytny dokument — łatwo widać, gdzie executor odchylił się od planu. Ale błędy w samym planie (błędna logika plannera) są trudniejsze do wykrycia, ponieważ planner działa raz i jego decyzje nie są inkrementalne.
Refleksja: Najtrudniejsza do debugowania. Iteracyjne cykle produkują dużo logów, a gdy model powtarza ten sam błąd w każdym cyklu, może być trudno ustalić przyczynę źródłową.
Więcej o tym, jak skonfigurować observability dla agentów AI — tracing, logowanie i alerty — w środowisku produkcyjnym.
Najczęstsze pytania
Czym jest architektura ReAct i skąd pochodzi?
ReAct (Reasoning + Acting) to wzorzec dla agentów AI zaproponowany przez Yao et al. w 2022 roku (publikacja akademicka). Agent działa w pętli Reason–Act–Observe: LLM myśli, wybiera narzędzie, otrzymuje wynik i powtarza. LangGraph, LangChain i inne frameworki ten wzorzec implementują, ale go nie wymyśliły.
Kiedy wybrać Plan-and-Execute zamiast ReAct?
Plan-and-Execute jest odpowiedni dla długich, ustrukturyzowanych zadań (6+ kroków) z przewidywalnym środowiskiem, gdy chcesz mieć audytowalny plan przed uruchomieniem. ReAct sprawdza się lepiej przy krótkich, dynamicznych zadaniach, gdzie warunki zmieniają się w trakcie. Dla 1–3 kroków rozważ, czy agent w ogóle jest potrzebny.
Czy Plan-and-Execute jest zawsze dokładniejszy niż ReAct?
Nie. P&E ma przewagę przy zadaniach ustrukturyzowanych i przewidywalnych. W dynamicznym środowisku, gdzie warunki zmieniają się w trakcie działania, P&E zawodzi — agent kontynuuje według nieaktualnego planu. ReAct jest bardziej adaptowalny, ponieważ reaguje na każdy wynik Observe.
Dlaczego uruchomienie agenta ReAct bez limitu max_steps jest niebezpieczne?
Bez ustawionego limitu kroków agent może wpaść w pętlę (np. wielokrotnie wywołuje narzędzie zwracające błąd, ale agent nie ocenia tego jako stanu terminalnego). Taki niekontrolowany agent potrafi w nocy wygenerować tysiące wywołań i rachunek rzędu tysięcy euro. Każdy agent produkcyjny musi mieć ustawiony eksplicytny parametr max_steps lub max_iterations.
Czy mogę łączyć ReAct z refleksją?
Tak, architektury hybrydowe są w produkcji powszechne. Typowa kombinacja: pętla ReAct do wykonywania kroków, moduł refleksji po zakończeniu do oceny jakości wyniku. Ważne zastrzeżenie: refleksja działa niezawodnie tylko wtedy, gdy wynik ocenia inny model lub zewnętrzny deterministyczny weryfikator (testy, walidacja schematu) — nie ten sam model, który wynik wygenerował.
*Jeśli rozważasz wdrożenie agenta AI w swojej firmie i nie jesteś pewien, która architektura jest odpowiednia dla Twojego przypadku użycia, chętnie ocenimy konkretną sytuację. W MP Industrial Solutions pomagamy klientom wybrać podejście odpowiadające ich realnym wymaganiom dotyczącym niezawodności, kosztów i możliwości zespołu — nie to, które wygląda najbardziej imponująco na demo.*