![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. Pojęcia ze słownika: Agent loop · Chain-of-thought · Reasoning model · Tool use · Human-in-the-loop · Agent AI](https://webflux.pl/wp-content/uploads/2026/06/agent_mysli.webp "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. Pojęcia ze słownika: Agent loop · Chain-of-thought · Reasoning model · Tool use · Human-in-the-loop · Agent AI")
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:
- RAG, Agent AI, Agentic RAG — czym się różnią
- Jak agent myśli — ReAct, Chain-of-Thought i pętla działania
- Jak agent pamięta — cztery typy pamięci
- n8n — Twój pierwszy agent bez kodu
- Prompt engineering dla agentów
- Co może pójść nie tak — bezpieczeństwo agentów dla builderów
- NLWeb — jak sprawić żeby Twoja strona odpowiadała agentom
- Ile kosztuje agent w produkcji
- Jak wiedzieć że agent robi to co powinien
- 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
