Czym jest inżynieria pętli w systemach AI

Czym jest inżynieria pętli

Inżynieria pętli to praktyka projektowania powtarzalnego cyklu, w którym działa agent AI: co go wybudza, do czego ma dostęp, w jaki sposób weryfikowany jest jego wynik oraz co powoduje jego zatrzymanie. Inżynieria promptów kształtuje pojedynczą wiadomość wysyłaną do modelu. Inżynieria pętli kształtuje proces, który wysyła tysiące wiadomości podczas nieobecności użytkownika. Jednostka pracy przesuwa się z promptu na pętlę.

W skrócie: użytkownik przestaje pisać instrukcje, a zaczyna tworzyć system sterowania. Agent nadal wymaga poprawnych instrukcji, lecz stają się one jedynie komponentem cyklu, który działa zgodnie z harmonogramem, pracuje w odizolowanej kopii kodu, weryfikuje własny wynik za pomocą testu i kończy działanie po wyczerpaniu budżetu.

Dlaczego termin ten pojawił się w 2026 roku

Nazwa ta jest obecnie ustalana w przestrzeni publicznej. Repozytorium GitHub cobusgreyling/loop-engineering przekroczyło 9 600 gwiazdek w ciągu dwóch miesięcy od momentu powstania (stan na lipiec 2026 roku), pod hasłem „Przestań promptować. Zaprojektuj pętlę. Uzyskaj wynik”. Gromadzi ono tę zmianę w sześciu blokach konstrukcyjnych: harmonogramowanie, worktrees, umiejętności, wtyczki i konektory, sub-agenci oraz trwała pamięć przechowywana poza konwersacją.

Cytuje ono Borisa Cherny'ego, który kieruje projektem Claude Code w Anthropic:

Nie promptuję już Claude'a. Mam uruchomione pętle, które promptują Claude'a.

Drugie repozytorium, AI-Builder-Club/skills, posiada blisko 1 100 gwiazdek (stan na lipiec 2026 roku) i bezpośrednio nazywa te dwie role: „codebase harness”, czyli uprząż bazy kodu, która czyni repozytorium bezpiecznym dla agenta w celu uruchamiania testów i wdrożeń, oraz „loop engineer”, czyli inżynier pętli, który budzi przepływy pracy na podstawie wyzwalacza, wykonuje zadanie i zapisuje wnioski do współdzielonego pliku, aby kolejna pętla mogła je odczytać.

Żadne z tych repozytoriów nie wymyśliło tej praktyki. Każdy, kto uruchamiał nightly build, linter w ramach continuous integration lub zadanie cron otwierające zgłoszenie, zna już ten schemat. Nowością jest to, że pracownik wewnątrz pętli jest teraz niedeterministyczny, co zmienia wymagania wobec otaczającej go infrastruktury.

Cztery elementy pętli

Każda działająca pętla składa się z tych czterech elementów. Pętla, w której brakuje choć jednego z nich, jest przyczyną nocnych awarii.

• Wyzwalacz (Trigger). Zdarzenie inicjujące wykonanie: licznik czasu, webhook, nowy pull request lub alert.
• Granica (Boundary). Pliki, dane uwierzytelniające oraz zasoby sieciowe, do których agent może uzyskać dostęp podczas działania.
• Weryfikacja (Verification). Sprawdzenie za pomocą kodu wyjścia, które decyduje, czy wynik działania zostanie zachowany, czy odrzucony.
• Budżet (Budget). Limit tokenów, czasu lub środków finansowych, który kończy działanie niezależnie od tego, czy zakończyło się ono sukcesem.

Potraktowanie tych czterech punktów jako pytań stanowi gotowy przegląd projektu dla każdego agenta, którego planujesz pozostawić w trybie ciągłego działania.

Wyzwalacz: co uruchamia agenta

Timer jest najprostszym wyzwalaczem, a na serwerze z systemem Linux timer systemd przewyższa crona, ponieważ zapewnia logowanie, pozwala na definiowanie warunków ponowienia prób i nie uruchamia drugiej kopii jednostki, która jest już w trakcie działania. Ta ostatnia właściwość eliminuje najczęstszy błąd nakładania się procesów w pętlach agenta: dwa uruchomienia edytujące tę samą gałąź.

Utwórz jednostkę w /etc/systemd/system/agent-loop.service:

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

Oraz timer w /etc/systemd/system/agent-loop.timer:

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

systemctl list-timers powinno wyświetlić kolumnę NEXT z czasem w przyszłości oraz kolumnę LEFT z odliczaniem. Pusty wynik oznacza, że timer nie jest włączony, ponieważ enable bez --now planuje go tylko na następny rozruch. TimeoutStartSec=1800 ma większe znaczenie, niż się wydaje: agent zawieszony w oczekiwaniu na dane wejściowe będzie utrzymywał jednostkę jako aktywną w nieskończoność, przez co timer nigdy nie zostanie uruchomiony ponownie. Przeczytaj przebieg za pomocą journalctl -u agent-loop.service -n 50.

Jeśli zamiast tego sterujesz pętlą za pomocą cron, dodaj własne zabezpieczenie przed nakładaniem się procesów, ponieważ cron bez problemu uruchomi drugą kopię:

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

flock -n kończy działanie natychmiast ze statusem 1, gdy blokada jest zajęta, dzięki czemu drugie uruchomienie znika po cichu zamiast rywalizować z pierwszym. Ta sama konfiguracja usługi i timera systemd ma zastosowanie do każdego długotrwałego zadania na serwerze, niezależnie od tego, czy jest to agent, czy nie.

Granica: zapewnienie odrębności dla każdego uruchomienia

Agent edytujący drzewo robocze może doprowadzić do utraty niezacommitowanych zmian. Git worktrees rozwiązują ten problem niskim kosztem: każde uruchomienie otrzymuje własny katalog i własną gałąź, współdzieląc jeden magazyn obiektów.

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list wyświetla jedną linię dla każdego drzewa, zawierającą jego ścieżkę, commit oraz gałąź. Po zakończeniu uruchomienia git worktree remove /srv/agent/work/triage-01 usuwa katalog, a git worktree prune czyści wpisy, których katalogi przestały istnieć. Pętle równoległe stają się w tym momencie bezpieczne, ponieważ dwaj agenci pracujący na dwóch gałęziach w dwóch różnych katalogach nie mogą nadpisać swoich zmian.

Granica dotyczy również poświadczeń. Pętla działająca bez nadzoru przechowuje długoterminowe tokeny, a każde uruchomienie stanowi ryzyko wycieku tokena do logów, commita lub kontekstu modelu. Ogranicz zakres tokena wyłącznie do repozytorium, na którym operuje pętla, w miarę możliwości nie umieszczaj go w środowisku powłoki agenta i zapoznaj się z jak chronić sekrety przed agentami AI przed przyznaniem pętli dostępu do środowiska produkcyjnego. Aby uzyskać silniejszą izolację, umieść całą pętlę na jednorazowej maszynie wirtualnej, którą można zniszczyć po każdym uruchomieniu. Wybór narzędzia również wyznacza część granicy jeszcze przed rozpoczęciem pisania kodu, dlatego warto przeczytać porównanie zarządzanego środowiska piaskownicy Cowork z Claude Code uruchamianym lokalnie, zanim podejmiesz decyzję, jak duży poziom izolacji musisz zbudować samodzielnie.

Weryfikacja: bramka zapewniająca bezpieczeństwo pętli

To etap, który odróżnia pętlę od zwykłego zadania cron, które jedynie wykonuje polecenia. Wynik działania agenta jest propozycją. Ostateczną decyzję podejmuje bramka.

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

set -euo pipefail wykonuje rzeczywistą pracę w tym skrypcie. Bez -e nieudane polecenie git fetch jest ignorowane, a proces jest kontynuowany w oparciu o nieaktualny stan origin/main. Bez -u literówka w nazwie zmiennej powoduje rozwinięcie jej do pustego ciągu znaków, przez co czyszczenie odbywa się w niewłaściwej ścieżce zamiast zakończyć się głośnym błędem.

Blok if ! npm test stanowi istotę całego rozwiązania. Kod wyjścia sprawdzenia, któremu ufasz – na przykład zestawu testów lub narzędzia do sprawdzania typów – decyduje o tym, czy gałąź zostanie wypchnięta, czy usunięta. Pętla bez bramki generuje pracę, której nikt nie ma czasu przejrzeć, co jest gorsze niż brak jakichkolwiek zmian. Pętla z bramką tworzy gałąź, która spełniła te same wymagania, co gałąź stworzona przez człowieka. Pozytywny wynik bramki nie informuje o skali zmian wprowadzonych przez agenta, dlatego warto połączyć to sprawdzenie z instrukcją typu zasada wymuszająca na agencie wprowadzanie najmniejszych działających zmian, co pozwala utrzymać rozmiar diffa na poziomie umożliwiającym szybką weryfikację.

Wybierz bramkę, która kończy się niepowodzeniem w sposób rzetelny. Zestaw testów, który przechodzi przy pustym diffie, uczy pętlę, że brak działania jest sukcesem. Repozytoria ze słabymi testami otrzymują słabe pętle, dlatego popularne projekty stawiają "przygotowanie bazy kodu pod agenta" przed "napisaniem pętli". Jeśli chcesz sprawdzić, czy Twój zestaw testów faktycznie wykryje regresję, zamiast jedynie wykonywać linie kodu, testowanie mutacyjne jest odpowiednim narzędziem. Z kolei agent, który zamiast prosić o przejrzenie diffa, dostarcza raport z dowodami, który można uruchomić ponownie zamienia wynik tego testu w coś, co możesz samodzielnie potwierdzić.

Budżet: co przerywa działanie

Agent, który ponawia próby w nieskończoność, generuje nieograniczone koszty. Każda pętla musi posiadać limit czasowy, wymuszany przez TimeoutStartSec powyżej, licznik prób wewnątrz skryptu oraz limit wydatków narzucony na poziomie konta dostawcy. Należy rejestrować koszt każdego uruchomienia, aby wykryć dryf pętli, zanim odzwierciedli się on na fakturze. Kontrola kosztów dla agenta VPS działającego w trybie ciągłym omawia kwestie rozliczeniowe, a zarządzanie kontekstem przenoszonym przez agenta między turami opisuje najważniejszy czynnik wpływający na koszt pojedynczego uruchomienia. Pętla, która co 30 minut ponownie odczytuje to samo repozytorium, płaci za tę operację przy każdym cyklu.

Koszty są powodem, dla którego pętle zazwyczaj przewyższają jedną długą sesję. Uruchomienie, które zaczyna się od zera, wykonuje jedno wąskie zadanie i kończy działanie, utrzymuje niewielki kontekst. Sesja pozostawiona otwarta przez osiem godzin przechowuje w swojej historii każdy wcześniejszy błąd i przy każdej turze płaci za cały zapis konwersacji.

Wzorce kodyfikowane przez popularne repozytoria

Repozytorium loop-engineering wymienia siedem wzorców produkcyjnych, które warto traktować raczej jako menu niż manifest. Codzienna segregacja zgłoszeń (triage). Opiekun pull-requestów, który monitoruje komentarze z recenzji i odpowiada na nie. Czyściciel ciągłej integracji, który wyłapuje nieudane kompilacje. Czyściciel zależności. Twórca changeloga. Porządki po scaleniu kodu. Segregacja zgłoszeń (issue triage).

Wspólną cechą tych zadań jest wąski zakres i oczywisty warunek zakończenia. "Napraw niedziałającą kompilację" ma warunek zaliczenia, który maszyna potrafi odczytać. "Ulepsz bazę kodu" go nie posiada, więc nigdy nie staje się pętlą. Staje się chaosem realizowanym według harmonogramu.

Wspólną cechą jest również zapis w formie dokumentacji. Oba repozytoria wyprowadzają stan poza konwersację, zapisując go w plikach wewnątrz repozytorium: co zostało uruchomione, co znaleziono i jakie decyzje podjęto. Ten plik stanowi pamięć pętli i jest powodem, dla którego kolejna pętla może bazować na pracy poprzedniej, zamiast ponownie ją odkrywać. Jest to również sposób na audyt agenta po fakcie, ponieważ kontekst modelu znika w momencie zakończenia działania. Koordynacja na żywo odbywa się osobnym kanałem i jedna sesja Claude Code może przekazać pracę innej na tej samej maszynie, gdy obie są aktywne, jednak nic z tej wymiany nie przetrwa zakończenia sesji, dlatego to plik pozostaje elementem, który można odczytać później.

Gdzie pętle zawodzą

Awarie są powtarzalne i występują w różnych zespołach.

• Brak bramki. Wyniki gromadzą się bez weryfikacji, zaufanie spada, a pętla zostaje wyłączona.
• Nakładanie się. Dwa uruchomienia w jednej gałęzi lub dwa agenty w jednym drzewie roboczym powodują konflikty, które agent próbuje następnie rozwiązać.
• Cichy dryf. Pętla przechodzi pomyślnie, ponieważ test jest zbyt słaby, by wykryć błąd.
• Nieograniczony zakres. Wyzwalacz uruchamiany przy każdym commicie w aktywnym repozytorium generuje wysokie koszty w ciągu jednego dnia.

Każdy z tych problemów ma to samo rozwiązanie: ograniczenie zakresu zadania, zaostrzenie testów i logowanie przebiegu. Jeśli warunku powodzenia nie da się opisać jednym zdaniem, zadanie nie jest gotowe do automatyzacji.

Rozpoczęcie pracy bez dodatkowego oprogramowania

Nie jest wymagany żaden framework. Mały, stale działający serwer Linux, repozytorium git, którego zestaw testów kończy się niepowodzeniem w oczekiwanych przypadkach, jeden timer systemd oraz skrypt powłoki zawierający if tworzą kompletną pętlę. To rozwiązanie, od którego większość osób powinna zacząć, ponieważ pytania projektowe rozwiązuje się poprzez uruchomienie systemu, a nie wybór narzędzia. Gdy pierwsza pętla stanie się stabilna, uruchomienie drugiej sprowadza się głównie do dodania kolejnego timera oraz kolejnego drzewa roboczego (worktree). Zobacz jak uruchomić agenta AI do programowania na VPS, aby poznać podstawową konfigurację, oraz aktualne opcje samodzielnego hostowania agentów AI, jeśli chcesz, aby agent działał na sprzęcie, którym zarządzasz.

FAQ

Czy inżynieria pętli różni się od inżynierii promptów?

Inżynieria promptów optymalizuje pojedynczą wiadomość: sformułowanie, przykłady, format wyjściowy. Inżynieria pętli optymalizuje cykl wokół tej wiadomości: wyzwalacz uruchamiający proces, piaskownicę, w której jest on wykonywany, mechanizm sprawdzający akceptujący lub odrzucający wynik oraz budżet kończący działanie. Wewnątrz pętli nadal wymagany jest poprawny prompt. Prompt przestaje być jednak elementem dostrajanym codziennie, ponieważ to bramka i wyzwalacz mają większy wpływ na końcowy rezultat.

Czy do zbudowania pętli agenta potrzebny jest framework?

Nie. Timer systemd, osobne drzewo robocze git dla każdego uruchomienia, skrypt powłoki kończący się komendą testową oraz limit wydatków na koncie dostawcy pokrywają każdy element tej definicji. Frameworki dodają interfejsy szeregowania, formaty pamięci współdzielonej i routing dla wielu agentów, co jest przydatne przy uruchamianiu kilku pętli jednocześnie. Nie stanowią one jednak bariery wejścia dla pierwszej z nich.

Czym jest harness dla bazy kodu?

Jest to zestaw narzędzi pozwalający agentowi pracować w repozytorium bez obecności człowieka: konfiguracja uruchamiana jedną komendą, testy działające w trybie nieinteraktywnym i zgłaszające błędy w sposób czytelny, linter oraz mechanizm wdrażania lub podglądu zmian. Termin ten wywodzi się z tej samej fali repozytoriów z 2026 roku, co inżynieria pętli. Praktyczny test jest prosty: jeśli nowy współpracownik nie jest w stanie przejść od klonowania do zielonych testów za pomocą jednej komendy, agent również tego nie zrobi.

Jak zapobiec generowaniu wysokich rachunków przez pętlę agenta?

Należy nałożyć limity w trzech miejscach. Ustaw TimeoutStartSec w jednostce systemd, aby zawieszone uruchomienie zostało przerwane. Ogranicz liczbę ponownych prób wewnątrz skryptu, zamiast zapętlać proces do skutku. Ustaw twardy limit wydatków na koncie API, ponieważ jest to jedyna bariera, której agent nie jest w stanie obejść. Następnie monitoruj koszt każdego uruchomienia, ponieważ pętla, której koszt rośnie dwukrotnie, zazwyczaj oznacza pętlę, której zakres działań po cichu się rozszerzył.

Które zadania warto w pierwszej kolejności przekształcić w pętlę?

Wybierz zadanie z mierzalnym warunkiem zaliczenia i małym zasięgiem potencjalnych szkód. Naprawa nieudanego buildu, aktualizacja zależności czy generowanie changeloga kwalifikują się, ponieważ zestaw testów lub diff mogą potwierdzić poprawność wyniku. Prace o otwartym charakterze, takie jak refaktoryzacja czy projektowanie, na razie się nie kwalifikują, ponieważ brakuje mechanizmu weryfikacji, a pętla bez bramki to kosztowny sposób na generowanie długu technicznego.