Jak agent AI myśli — ReAct, Chain-of-Thought i pętla która nigdy nie śpi

przez Łukasz | cze 4, 2026

Artykuł 2 z serii „Agenci AI — od konceptu do produkcji” RAG, Agent AI, Agentic RAG — czym się różnią


Poprzedni artykuł tej serii skończył się na rozróżnieniu: RAG odpowiada na pytanie, agent realizuje cel.

Ale to rodzi pytanie które każdy kto buduje agenta zadaje sobie prędzej czy później: jak właściwie agent decyduje co zrobić dalej?

Między „dostałem zadanie” a „zadanie wykonane” jest czarna skrzynka. Dla chatbota ta czarna skrzynka jest prosta — jeden prompt, jedna odpowiedź. Dla agenta to sekwencja decyzji, wywołań narzędzi i ocen wyniku która może trwać sekundy albo godziny.

Żeby budować agentów świadomie — a nie przez próby i błędy — trzeba zrozumieć co jest w środku tej czarnej skrzynki.

Pętla która napędza każdego agenta

Zacznijmy od analogii.

Wyobraź sobie że dostajesz zadanie: „Zarezerwuj mi hotel w Krakowie na weekend 14-15 czerwca, do 400 zł za noc, blisko centrum.”

Jak to robisz? Nie jednym ruchem. Najpierw szukasz opcji. Sprawdzasz ceny. Czytasz opinie. Może jedno miejsce ma dobry rating ale jest za drogie — odrzucasz. Drugie pasuje, ale patrzysz jeszcze na lokalizację. Potwierdzasz. Rezerwujesz.

To jest pętla: obserwujesz → planujesz → działasz → oceniasz wynik → wracasz do początku.

Agent AI działa identycznie. Każde wieloetapowe zadanie jest realizowane przez powtarzający się cykl czterech kroków — i ten cykl ma swoją nazwę: agent loop.

Cztery kroki pętli

Percepcja — agent patrzy na stan: co jest w oknie kontekstu, jakie były wyniki poprzednich akcji, co zwróciło ostatnie narzędzie, jaki jest cel.

Planowanie — na podstawie tego co widzi, agent decyduje co zrobić dalej. To jest moment decyzji: czy cel jest osiągnięty? Jeśli nie — jaka akcja przybliży mnie do celu? Jakie narzędzie wywołać?

Akcja — agent wykonuje to co zaplanował. Wywołuje narzędzie MCP, odpytuje bazę danych, robi request HTTP, pisze plik.

Ocena — agent patrzy na wynik akcji. Czy to działało? Co teraz wiem więcej? Co jest następnym krokiem? Czy napotkałem błąd który wymaga innej strategii?

I z powrotem do percepcji.

Pętla kręci się dopóki agent nie osiągnie celu, nie napotka przeszkody której nie może pokonać, albo — i to jest ważne — nie przekroczy limitu iteracji.

Limit iteracji jest krytyczny

Agent bez limitu może kręcić się w pętli nieskończenie. Narzędzie zwraca błąd, agent próbuje jeszcze raz, i jeszcze raz, i jeszcze raz. Minuty zamieniają się w godziny. Tokeny i koszty rosną.

Każdy agent produkcyjny musi mieć limit kroków po którym zatrzymuje się i raportuje do człowieka: „doszedłem do limitu X iteracji, oto co udało mi się ustalić, oto gdzie utknąłem.” To jest pierwsza zasada którą ignoruje większość ludzi budujących swojego pierwszego agenta.

ReAct — jak agent myśli zanim działa

Teraz wiemy że agent kręci się w pętli. Ale co dokładnie dzieje się w kroku „planowanie”? Jak agent decyduje co zrobić?

W 2022 roku badacze z Princeton i Google zaproponowali wzorzec który zmienił sposób budowania agentów: ReAct(Reasoning + Acting).

Pomysł jest prosty do bólu: zanim agent wykona akcję, niech najpierw „powie na głos” co myśli. Generuje explicite reasoning — widoczny łańcuch myślenia — a potem na jego podstawie podejmuje decyzję o akcji.

Wygląda to tak:

Thought: Użytkownik chce hotelu w Krakowie na 14-15 czerwca 
         do 400 zł. Powinienem najpierw sprawdzić dostępność.
         
Action: search_hotels(city="Kraków", checkin="2026-06-14", 
        checkout="2026-06-15", max_price=400)

Observation: [3 wyniki: Hotel A — 380 zł, Hotel B — 350 zł, 
             Hotel C — 420 zł]

Thought: Hotel C jest za drogi. Hotel A i B mieszczą się 
         w budżecie. Sprawdzam odległość od centrum.
         
Action: get_location(hotel_id="hotel_A")

Observation: 800m od Rynku Głównego

Thought: 800m to blisko centrum. Hotel A kosztuje 380 zł 
         i jest blisko. Rezerwuję.
         
Action: book_hotel(hotel_id="hotel_A", dates=["2026-06-14"])

Trzy zalety ReAct które robią różnicę w praktyce:

Debugging jest możliwy. Widzisz dokładnie skąd pochodzi każda decyzja agenta. Jeśli coś poszło nie tak — możesz śledzić rozumowanie krok po kroku i znaleźć moment gdzie agent zboczył z kursu.

Narzędzia są wywoływane trafniej. Agent który „przemyśli” co wywołać zanim to zrobi, robi mniej błędnych wywołań niż agent który po prostu reaguje na ostatni wynik.

Agent może się korygować. Reasoning jest widoczny — i agent może sam zauważyć że jego poprzedni krok był błędny, zanim podejmie kolejny.

Chain-of-Thought — „myślmy krok po kroku”

ReAct to wzorzec na poziomie architektury agenta. Chain-of-thought (CoT) to technika na poziomie promptowania modelu.

Idea: zamiast prosić model o bezpośrednią odpowiedź, zachęć go żeby najpierw pokazał swoje obliczenia. Jak matematyk który nie podaje samego wyniku, ale zapisuje wszystkie kroki.

Najprostszy możliwy CoT to dosłownie jedno zdanie dodane do promptu: „Myślmy krok po kroku.” Brzmi banalnie. Ale działa — szczególnie przy zadaniach wieloetapowych, matematycznych i logicznych.

Bardziej zaawansowany CoT to few-shot: dostarczasz modelowi przykłady pytanie + rozumowanie + odpowiedź, i model uczy się wzorca. Dla agentów operujących w specyficznej domenie — powiedzmy agent analizujący umowy prawne — few-shot CoT z przykładami z tej domeny jest jednym z najskuteczniejszych sposobów poprawy jakości.

Extended thinking — CoT wbudowany w model

Claude 3.7+ i kilka innych modeli poszło dalej: extended thinking jest wbudowane bezpośrednio w model, bez potrzeby specjalnego promptowania. Model generuje wewnętrzny długi łańcuch myślenia przed odpowiedzią — niewidoczny dla użytkownika (lub opcjonalnie widoczny).

Efekt: znacząco lepsza jakość przy złożonych, wieloetapowych zadaniach — za cenę wyższej latencji i więcej tokenów. Dla agentów wykonujących skomplikowane analizy gdzie czas odpowiedzi jest mniej ważny niż poprawność — extended thinking jest naturalnym wyborem.

Przykład który łączy wszystko: agent rezerwujący hotel

Wróćmy do zadania: „Zarezerwuj hotel w Krakowie na 14-15 czerwca.”

Chatbot dostałby to pytanie i wygenerował listę hoteli z opisem. Odpowiedź tekstowa. Nic nie zarezerwował.

Agent z agent loop, ReAct i dostępem do narzędzi wykonuje to zadanie od początku do końca:

Iteracja 1: Percepcja → cel jasny, narzędzia dostępne. Planowanie → wywołaj search_hotels. Akcja → [wywołanie]. Ocena → 3 wyniki, Hotel C za drogi.

Iteracja 2: Percepcja → mam 2 kandydatów. Planowanie → sprawdź lokalizację. Akcja → [wywołanie]. Ocena → Hotel A blisko centrum, Hotel B dalej.

Iteracja 3: Percepcja → Hotel A: 380 zł, 800m od centrum. Spełnia wszystkie kryteria. Planowanie → rezerwuj. Akcja → [wywołanie book_hotel]. Ocena → rezerwacja potwierdzona, numer #KRK2026-0891.

Wynik: „Zarezerwowałem Hotel A na 14-15 czerwca, 380 zł, 800m od Rynku Głównego. Numer rezerwacji: #KRK2026-0891.”

Trzy iteracje pętli. Trzy wywołania narzędzi. Jedno wykonane zadanie.

Co to zmienia dla kogoś kto buduje agenta

Zrozumienie agent loop, ReAct i CoT nie jest teorią akademicką — bezpośrednio wpływa na to jak projektujesz agenta.

Agent loop mówi ci: musisz zdefiniować kryterium sukcesu (jak agent wie że skończył?), ustawić limit iteracji (co gdy agent utknął?), i zdecydować gdzie wstawić human-in-the-loop (które akcje wymagają potwierdzenia człowieka przed wykonaniem?).

ReAct mówi ci: daj modelowi miejsce na reasoning zanim podejmie akcję. Nie optymalizuj prompta do minimum — reasoning kosztuje tokeny, ale zmniejsza błędy narzędziowe i ułatwia debugging gdy coś pójdzie nie tak.

CoT mówi ci: przy złożonych zadaniach „myślmy krok po kroku” to nie magia — to zmiana trybu pracy modelu. Dla zadań domenowych few-shot CoT z przykładami z Twojej domeny jest wart inwestycji.

W następnym artykule: agent myśli i działa — ale co pamięta? Jak działa pamięć agenta między krokami, między sesjami i między zadaniami — i dlaczego zły design pamięci jest jednym z najczęstszych błędów przy budowaniu agentów produkcyjnych.

Cała seria Anatomia Agenta AI:

  1. RAG, Agent AI, Agentic RAG — czym się różnią
  2. Jak agent myśli — ReAct, Chain-of-Thought i pętla działania
  3. Jak agent pamięta — cztery typy pamięci
  4. n8n — Twój pierwszy agent bez kodu
  5. Prompt engineering dla agentów
  6. Co może pójść nie tak — bezpieczeństwo agentów dla builderów
  7. NLWeb — jak sprawić żeby Twoja strona odpowiadała agentom
  8. Ile kosztuje agent w produkcji
  9. Jak wiedzieć że agent robi to co powinien
  10. Agent-ready — checklista (ten artykuł)

Pojęcia ze słownika: Agent loop · Chain-of-thought · Reasoning model · Tool use · Human-in-the-loop · Agent AI

Agent kończy, ale zadania nie wykonał

Agent kończy, ale zadania nie wykonał

Objawy Agent odpowiada: „Przygotowałem i wysłałem potwierdzenie do klienta." Potwierdzenie nie zostało wysłane. Albo: „Zaktualizowałem wszystkie rekordy" — zaktualizował trzy z dwunastu. Albo: „Nie znalazłem żadnych zamówień" — bo narzędzie zwróciło błąd, którego nikt...

Agent zrobił coś, o co nikt nie prosił

Agent zrobił coś, o co nikt nie prosił

Objawy Operacja, której nikt nie zlecił. Dane wysłane pod adres, którego nie ma w żadnej konfiguracji. Rekord zmieniony poza zakresem zadania. Odpowiedź, z której wynika, że agent dostał instrukcje od kogoś innego niż ty. Cecha wspólna: technicznie wszystko zadziałało...

Agent zrobił to samo dwa razy

Agent zrobił to samo dwa razy

Objawy Ten syndrom różni się od pozostałych jedną rzeczą: objaw widzi klient, nie ty. Trzy identyczne wiadomości w skrzynce. Dwa zamówienia zamiast jednego. Podwójne obciążenie. Duplikaty rekordów, które ktoś zauważa tydzień później. W twoim dzienniku wszystko wygląda...

Agent gubi wątek w długim zadaniu

Agent gubi wątek w długim zadaniu

Objawy Pierwsze kroki idą wzorowo. Po kilkunastu agent zaczyna się rozjeżdżać. Przestaje przestrzegać reguły z promptu systemowego, której trzymał się na początku. Zmienia format odpowiedzi w połowie zadania. Wraca do czegoś, co już ustalił, i ustala to inaczej....

Agent podaje dane, których nie ma

Agent podaje dane, których nie ma

Objawy Numer zamówienia w idealnym formacie, którego nie ma w bazie. Kwota, której w dokumencie nie ma. Nazwa pola API, które nigdy nie istniało. Cytat z regulaminu, brzmiący dokładnie jak reszta regulaminu i w nim nieobecny. Cecha wspólna wszystkich tych przypadków:...

Działał wczoraj, dziś nie działa

Działał wczoraj, dziś nie działa

Objawy Nic się nie wywala. Nie ma wyjątków, nie ma timeoutów, dziennik wygląda tak samo jak zawsze. Po prostu odpowiedzi są gorsze. Postacie, w jakich to się objawia: Jakość. Agent zaczyna pomijać kroki, które wcześniej wykonywał, albo odpowiada ogólniej. Format....

Agent wybiera złe narzędzie

Agent wybiera złe narzędzie

Objawy Agent odpowiada nie na to pytanie. Pobiera listę zamówień, gdy pytano o jedno konkretne. Odpowiada z pamięci, choć miał sprawdzić w bazie. Albo sięga po właściwe narzędzie i wpisuje w argumenty coś, czego nie da się użyć. Sygnał, który odróżnia ten syndrom od...

Agent kręci się w kółko

Agent kręci się w kółko

Objawy Agent wykonuje kolejne obroty pętli, nie zbliżając się do zakończenia zadania. W dzienniku widać jedną z trzech postaci. Powtórzenie. To samo narzędzie, te same argumenty, raz za razem — czasem dziesiątki razy pod rząd. Oscylacja. Agent wywołuje na przemian dwa...