Pętle agentów AI: jak samokorygujący się agent kodujący doprowadza robotę do końca

To, jak większość ludzi wciąż używa agenta kodującego AI, wygląda jak ping-pong. Ty promptujesz, on odpowiada, ty wyłapujesz, co jest nie tak, promptujesz znowu. To ty jesteś silnikiem korekty i siedzisz w pętli przy każdej kolejce.

Pętla to odwraca. Opisujesz, czego chcesz, agent bierze się do roboty, pisze własną listę kontrolną, znajduje własne słabe punkty i powtarza, aż wynik się broni. Przestajesz być tym, kto wyłapuje błędy. Agent wyłapuje własne.

Ta zmiana to nie hype. Ludzie, którzy zbudowali te narzędzia, na niej polegają. Boris Cherny i Cat Wu, twórcy Claude Code, mówią o kodowaniu w pętlach agentowych. Geoffrey Huntley, który ochrzcił "Ralph loop", odpala agenty w zwykłej pętli while na całą noc. Ten wzorzec ma już nazwę i warto go zrozumieć, zanim skopiujesz trzy prompty zobaczone na Instagramie.

Od ping-ponga promptów do pętli

Pojedynczy prompt to jeden strzał. Pytasz, dostajesz odpowiedź, transakcja się kończy. Żeby ją poprawić, musisz dostrzec lukę i promptować jeszcze raz. Przeskaluj to do prawdziwej funkcjonalności, a robisz ręcznie dziesiątki mikrokorekt.

Pętla agenta AI domyka tę lukę wewnątrz agenta. Wyznaczasz cel, agent planuje, działa, patrzy na wynik i poprawia, raz za razem, aż cel jest osiągnięty. Nie znikasz, sprawdzasz na końcu. Ale nie jesteś już wąskim gardłem przy każdej iteracji.

Ping-pong promptów wsadza w pętlę ciebie przy każdej kolejce. Prawdziwa pętla wsadza w nią agenta.

Czym tak naprawdę jest pętla agenta AI

Każda pętla agentowa kręci się wokół tych samych czterech taktów: planuj, działaj, obserwuj, koryguj. Agent decyduje o następnym kroku, robi go (pisze kod, uruchamia komendę, czyta plik), czyta, co się stało, i dostraja. Claude pisze kod, uruchamia testy, widzi porażkę, poprawia, uruchamia testy ponownie. To sprzężenie zwrotne to cały trik. To właśnie ono sprawia, że pętla się samokoryguje, a nie tylko powtarza.

Najmocniejsza wersja pętli rozdziela te takty na trzy role: jedna planuje, jedna buduje, jedna sprawdza. Trzymanie ich osobno to właśnie to, co powstrzymuje agenta przed ocenianiem własnego wypracowania w tym samym tchu, w którym je pisze.

Pętla z trzech komend, którą możesz skopiować już dziś

Oto układ, który krąży teraz po sieci, przerobiony na trzy komendy slash w Claude Code. Wklejasz każdą raz, agent tworzy komendę, a potem uruchamiasz je po kolei.

Planista, /spec:

Przepytuj mnie po jednym pytaniu na raz, aż w pełni zrozumiesz, czego chcę.
Potem napisz precyzyjny plan do specs/project.md: cel, dokładne wymagania,
przypadki brzegowe oraz to, co jest w zakresie, a co poza nim.
Trzymaj go krótkim i zwięzłym, nie pisz powieści.

Budowniczy, /build:

Przeczytaj specs/project.md i zbuduj dokładnie to, co opisuje, nic więcej.
Kiedy skończysz, wypisz każde wymaganie z planu i zaznacz, które z nich
pokryłeś.

Recenzent, /review:

Porównaj to, co zbudowano, ze specs/project.md, wymaganie po wymaganiu.
Dla każdego powiedz, czy jest pokryte. Wypisz potrzebne poprawki i odeślij
je do /build. Zatwierdź dopiero, gdy cały plan jest pokryty.

Trzy komendy, jedna pętla: spec pisze plan, build go implementuje, review porównuje go z planem i odsyła poprawki do build. Kręci się to, aż każde wymaganie jest spełnione.

Plan jest źródłem prawdy. Recenzja mierzy budowę względem niego, a nie względem wrażenia.

To pod maską spec-driven coding: to spisana specyfikacja, a nie historia czatu, rozlicza agenta. Open-source'owy Spec Kit od GitHub formalizuje ten sam pomysł komendami /specify, /plan, /tasks i /implement, a działa zarówno na Claude Code, Copilot, Cursor, Codex CLI, jak i Gemini CLI.

Dlaczego świeży kontekst sprawia, że pętla działa: Ralph loop

Geoffrey Huntley ochrzcił najsurowszą wersję tego wszystkiego w połowie 2025: Ralph loop. Pomysł to zwykła pętla powłoki, która podaje agentowi ten sam prompt względem spisanej specyfikacji, pozwala mu wybrać jedno zadanie i je dostarczyć, a potem startuje zupełnie nowego agenta z czystym kontekstem i podaje mu identyczny prompt jeszcze raz.

while są_jeszcze_zadania; do
  agent --prompt "Zajmij się następnym zadaniem z todo.md" --non-interactive
done

Nieoczywista część to reset kontekstu. Długa sesja gnije: okno zapełnia się starym rozumowaniem, ślepymi zaułkami i nieaktualną zawartością plików, a model po cichu zaczyna gubić instrukcje. Każda iteracja Ralpha to nowy agent, który czyta aktualne repo i listę zadań z dysku, robi jedną jednostkę pracy, commituje i wychodzi czysto. Huntley nazwał to celowo po postaci z Simpsons: wygląda na zbyt głupie, żeby działać, a działa. Jeśli widziałeś już długą sesję, która zaczyna halucynować, to wiesz, dlaczego świeże okno bije zapchane.

/loop i /goal w Claude Code

Claude Code dostarcza prymitywy pętli wprost. /goal ustala trwały stan końcowy, czyli jak wygląda "gotowe", a Claude po każdym przebiegu ocenia postęp względem niego, zamiast po prostu odpalać następny krok. /loop powtarza zadanie w danym rytmie albo do spełnienia warunku, w formach takich jak /loop every 10m czy /loop until: <warunek>. Razem tworzą pętlę, która sama się kieruje i sama kończy: Claude pracuje nad różnicą między stanem bieżącym a celem i zatrzymuje się, gdy cel jest spełniony albo gdy wciśniesz Ctrl+C.

Detal, który ma znaczenie: pętla zachowuje ciągłość. Pamięta, co próbowała i dlaczego się nie udało, więc każdy przebieg buduje na poprzednim, zamiast powtarzać ten sam ślepy zaułek. To dokładnie odwrotny kompromis niż reset czystego kontekstu u Ralpha, i oba są słuszne. Ciągłość dla ścisłej samokorekty, świeży kontekst, gdy okno gnije. Wiedza o tym, po które sięgnąć, to prawdziwa umiejętność.

Ta sama pętla, u każdego providera

Pętle to nie funkcja Claude, to kierunek, w którym zmierza cała branża. Nazwy się różnią, kształt nie.

Codex CLI pchnął pętlę najdalej publicznie. Zespół OpenAI przedstawił swoje /goal jako swoją wersję Ralph loop, a Andrew Chen z a16z zostawił je działające przez całą noc nad sterownikiem urządzenia, 14 godzin bez przerwy i bez interwencji. Zauważył też, że "pomnoży to zużycie tokenów 10 000 razy", co jest uczciwym kosztem pozwolenia agentowi mielić przez pół dnia.

Haczyk: pętla wzmacnia wszystko

Pętla nie wzmacnia tylko dobrego wyniku, wzmacnia też zły plan. Wyceluj samokorygującego się agenta w niejasną specyfikację, a z pewnością siebie zbuduje nie to, co trzeba, sprawdzi to względem tej samej niejasnej specyfikacji i zatwierdzi. Plan to dźwignia. Ostra specyfikacja oszczędza dziesięć promptów, mglista marnuje sto.

Dwa tryby awarii, na które trzeba uważać. Koszt wymyka się spod kontroli: każda iteracja pali tokeny, a nieograniczona pętla przy niejasnym celu potrafi spalić ich mnóstwo. I pętla może kręcić się w nieskończoność, ogłaszając zwycięstwo albo goniąc cel, którego nigdy nie zdoła spełnić. Ogranicz ją: jasny warunek until, pułap tokenów albo punkt kontrolny dla człowieka przed mergem. Pętla bez stopu to nie autonomia, to rozbieganie się.

Odpalanie pętli na całej flocie

Jednego samokorygującego się agenta łatwo dopilnować. Dźwignia ujawnia się, gdy odpalasz kilka naraz, każdy pętlący się nad własnym zadaniem, i to dokładnie tu pilnowanie jednego terminala przestaje się skalować.

Po to właśnie zbudowano AgentsRoom. To kokpit wielu agentów: każdy agent ma rolę, kropkę statusu na żywo i własny kolor, a ty nadzorujesz całą flotę z jednego okna. Wrzuć zgłoszenie na backlog, a agent je podbierze, przejdzie swoją pętlę plan-build-review i odda ci czysty diff. To spec-driven AI coding w praktyce: zgłoszenie jest specyfikacją, agent przechodzi pętlę, ty sprawdzasz wynik.

Ponieważ długie pętle gniją kontekst, AgentsRoom go pilnuje. Każdy agent na końcu każdej kolejki pisze jednolinijkowy status, a gdy agent przestaje go aktualizować dwie kolejki z rzędu, pojawia się ostrzeżenie z restartem za jednym kliknięciem na czystym kontekście, dokładnie ten sam reset świeżego okna, na którym opiera się Ralph loop. Przeczytaj, jak to działa, na stronie wykrywanie dryfu kontekstu.

A ponieważ pętla jest niezależna od providera, nie jesteś przywiązany do żadnego. Odpal jedno zgłoszenie na Claude Code, następne na Codex, jeszcze inne na Gemini CLI, wszystko w tym samym dashboardzie, każde pętlące się we własnym git worktree, żeby równoległe agenty nigdy na siebie nie wpadły. Odpal je, zanim się wylogujesz, a diffy sprawdź rano, o to właśnie chodzi w agentach kodujących w tle i nocnej zmianie.

Wyznacz cel raz, pozwól pętli go domknąć, sprawdź na końcu. Pobierz AgentsRoom, zajrzyj do macierzy zgodności providerów i przeczytaj więcej o recenzji per agent oraz obsłudze wielu providerów.