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 pojawił się w 2026

Nazwa jest obecnie utrwalana w publicznym użyciu. Repozytorium GitHub cobusgreyling/loop-engineering przekroczyło 9,600 gwiazdek w ciągu dwóch miesięcy od pierwszej publikacji (stan na lipiec 2026), a 2026-10-27 miało około 11,600 gwiazdek. Towarzyszy mu hasło „Przestań tworzyć prompty. Zaprojektuj pętlę. Uzyskaj wynik.” W lipcu 2026 plik README grupował tę zmianę w sześciu elementach: harmonogramowanie, worktree, skills, plugins i connectors, sub-agenci oraz trwała pamięć przechowywana poza rozmową. Obecny plik README nie zawiera już tej listy (sprawdzono 2026-10-27), ale nadal przechowuje stan pętli w pliku poza rozmową.

Repozytorium wskazuje Borisa Cherny'ego, który kieruje Claude Code w Anthropic, jako jedno ze źródeł inspiracji. Jego szeroko cytowana wypowiedź brzmi:

Nie tworzę już promptów dla Claude. Mam uruchomione pętle, które tworzą prompty dla Claude.

Drugie repozytorium, AI-Builder-Club/skills, ma około 1,300 gwiazdek (stan na 2026-10-27) i bezpośrednio określa obie role: „harness codebase”, który przygotowuje repozytorium tak, aby agent mógł bezpiecznie uruchamiać testy i wdrożenia, oraz „inżynier pętli”, który buduje przepływy pracy uruchamiane przez wyzwalacz, wykonujące zadanie i zapisujące wnioski we wspólnym pliku, aby następna pętla mogła je odczytać.

Żadne z tych repozytoriów nie stworzyło tej praktyki. Każdy, kto uruchamiał nocny build, linter w continuous integration albo zadanie cron otwierające zgłoszenie, zna już ten schemat. Nowością jest to, że pracownik wewnątrz pętli jest obecnie niedeterministyczny. Zmienia to wymagania wobec mechanizmów obsługujących pętlę.

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 cron, ponieważ zapewnia logowanie, ponawianie prób według zdefiniowanych zasad oraz zapobiega uruchomieniu drugiej kopii jednostki, która jest wciąż aktywna. 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łąź.

Najpierw należy utworzyć osobnego użytkownika dla agenta. Użytkownik ten stanowi część granicy bezpieczeństwa, więc posiada on wyłącznie /srv/agent i nic więcej:

sudo useradd --system --home-dir /srv/agent --shell /usr/sbin/nologin agent
sudo chown -R agent:agent /srv/agent

Następnie należy utworzyć 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 odliczającą czas. 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. Usługa typu Type=oneshot jest liczona jako uruchomiona, dopóki jej skrypt nie zakończy działania, a systemd domyślnie wyłącza limit czasu startu dla jednostek typu oneshot. Bez tej linii agent, który zawiesi się w oczekiwaniu na dane wejściowe, pozostawi jednostkę w stanie aktywacji na zawsze, a każde kolejne wyzwolenie timera stwierdzi, że proces nadal działa i nie uruchomi niczego nowego. Dzięki tej linii systemd przerywa działanie po 30 minutach i oznacza je jako nieudane. W przypadku zmiany jednostki na domyślny typ Type=simple, TimeoutStartSec przestaje obejmować sam proces, a RuntimeMaxSec= staje się ustawieniem ograniczającym czas. Przebieg można odczytać za pomocą journalctl -u agent-loop.service -n 50.

Jeśli pętla jest sterowana przez cron, należy dodać 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, więc drugie uruchomienie znika po cichu zamiast rywalizować z pierwszym. To samo ustawienie 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 każdemu uruchomieniu własnej kopii

Agent edytujący drzewo robocze może doprowadzić do utraty niezacommitowanych zmian. Git worktrees rozwiązują ten problem w sposób niskokosztowy: 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 drzewo robocze, ale tylko wtedy, gdy jest ono czyste. Jeśli drzewo zawiera nieśledzone pliki, zmodyfikowane pliki śledzone lub moduły podrzędne, git odmawia wykonania operacji do momentu dodania --force. Z tego powodu poniższy skrypt bramkujący wymusza usunięcie tylko w ścieżce, która odrzuca uruchomienie. 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ługożyjące tokeny, a każde uruchomienie stanowi ryzyko wycieku tokena do logów, commita lub kontekstu modelu. Ogranicz zakres tokena do jednego repozytorium, którego dotyczy pętla, w miarę możliwości usuń go ze środowiska 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ć jak zarządzany sandbox Cowork wypada w porównaniu z Claude Code na własnej maszynie przed podjęciem decyzji, jak duży poziom izolacji należy zbudować samodzielnie.

Weryfikacja: brama 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ą. Brama podejmuje decyzję.

#!/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 w tym skrypcie rzeczywistą pracę. Bez -e niepowodzenie git fetch jest ignorowane, a proces jest kontynuowany na przestarzałym origin/main. Bez -u literówka w nazwie zmiennej rozwinie się do pustego ciągu znaków, a czyszczenie zostanie wykonane w niewłaściwej ścieżce zamiast zakończyć się głośnym błędem. Ostatnia linia celowo nie zawiera --force: jeśli w drzewie pozostały nieśledzone lub niezatwierdzone pliki, git odmawia usunięcia, a -e kończy działanie z błędem po wypchnięciu zmian, zamiast cicho usuwać pracę, której nikt nie zatwierdził.

Blok if ! npm test stanowi istotę całego rozwiązania. Kod wyjścia sprawdzenia, któremu już ufasz – Twojego zestawu testów lub analizatora typów – decyduje o tym, czy gałąź zostanie wypchnięta, czy usunięta. Pętla bez bramy generuje pracę, której nikt nie ma czasu przejrzeć, co jest gorsze niż brak pracy. Pętla z bramą tworzy gałąź, która już spełniła wymagania stawiane gałęziom ludzkich współtwórców. "Zielona" brama nie mówi nic o tym, jak dużą część kodu agent musiał zmodyfikować, aby osiągnąć ten stan, dlatego warto połączyć to sprawdzenie z instrukcją typu zasada, dzięki której agent wybiera najmniejszą działającą zmianę, co utrzymuje diff na tyle małym, aby jego przegląd był tani.

Wybierz bramę, która zawodzi w sposób uczciwy. Zestaw testów, który przechodzi przy pustym diffie, uczy pętlę, że nicnierobienie jest sukcesem. Repozytoria ze słabymi testami otrzymują słabe pętle, dlatego najpopularniejsze repozytoria stawiają "przygotowanie bazy kodu pod agenta" przed "napisaniem pętli". Jeśli chcesz wiedzieć, czy Twój zestaw testów faktycznie wykryłby regresję, zamiast jedynie wykonywać linie kodu, testowanie mutacyjne jest sprawdzeniem, które daje odpowiedź, a agent, który zwraca raport z dowodami możliwymi do ponownego uruchomienia zamiast prosić o przeczytanie diffa zamienia tę odpowiedź w coś, co możesz samodzielnie zweryfikować.

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 dotyczące inżynierii pętli wymienia osiem wzorców produkcyjnych (stan na 2026-10-27). Warto czytać je jako zestaw możliwości, a nie manifest. Codzienny triage. Cienka pętla uruchamiana jako GitHub Action, bez pliku stanu. Mechanizm obsługujący pull requesty, który monitoruje komentarze z przeglądu i odpowiada na nie. Mechanizm continuous integration, który przejmuje nieudane buildy. Mechanizm przeglądu zależności. Przygotowywanie projektów changelogów. Porządki po scaleniu zmian. Triage zgłoszeń.

Łączy je wąsko określone zadanie z oczywistym warunkiem zaliczenia. „Napraw nieudany build” ma warunek powodzenia, który maszyna może odczytać. „Ulepsz repozytorium” takiego warunku nie ma, więc nigdy nie staje się pętlą. Staje się bałaganem z harmonogramem.

Łączy je również zapis w pliku. Oba repozytoria przenoszą stan poza rozmowę, do plików w repozytorium: co zostało uruchomione, co znaleziono i jakie podjęto decyzje. Ten plik jest pamięcią pętli. Dzięki niemu druga pętla może wykorzystać pracę pierwszej zamiast ponownie odkrywać te same informacje. Umożliwia również późniejszy audyt agenta, ponieważ kontekst modelu znika natychmiast po zakończeniu uruchomienia. Koordynacja w czasie rzeczywistym odbywa się osobnym kanałem, a jedna sesja Claude Code może przekazać pracę innej na tym samym komputerze, gdy obie nadal działają. Żadne informacje z tej wymiany nie przetrwają jednak zakończenia którejkolwiek sesji, dlatego plik pozostaje elementem, który można później odczytać.

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 jedną wiadomość: sformułowanie, przykłady, format wyjściowy. Inżynieria pętli optymalizuje cykl wokół wiadomości: wyzwalacz uruchamiający proces, piaskownicę, w której działa, test akceptujący lub odrzucający wynik oraz budżet, który go kończy. Wewnątrz pętli nadal potrzebny jest dobry prompt. Prompt przestaje być jednak elementem, który dostraja się codziennie, ponieważ to bramka i wyzwalacz mają większy wpływ na wynik.

Czy do zbudowania pętli agenta potrzebny jest framework?

Nie. Timer systemd, git worktree dla każdego uruchomienia, skrypt powłoki kończący się komendą testującą oraz limit wydatków na koncie dostawcy pokrywają każdy element 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 jest to jednak koszt wejścia dla pierwszej z nich.

Czym jest harness dla bazy kodu?

Jest to zestaw elementów pozwalających agentowi pracować w repozytorium bez obecności człowieka: konfiguracja za pomocą jednej komendy, testy działające w sposób nieinteraktywny i zgłaszające błędy w czytelny sposób, linter oraz sposób na wdrożenie lub podgląd zmiany. 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 człowiek nie potrafi przejść od sklonowania repozytorium 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 typu Type=oneshot, takiej jak powyżej, aby zawieszony proces został zabity (w usłudze typu Type=simple odpowiednikiem jest RuntimeMaxSec). Ogranicz liczbę ponownych prób wewnątrz skryptu, zamiast zapętlać go do skutku. Ustaw twardy limit wydatków na koncie API, ponieważ jest to jedyny sufit, którego agent nie jest w stanie obejść. Następnie loguj koszt każdego uruchomienia, ponieważ pętla, której koszt rośnie dwukrotnie, to zazwyczaj pętla, której zakres został po cichu rozszerzony.

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 i generowanie changeloga spełniają te kryteria, ponieważ zestaw testów lub diff mogą potwierdzić poprawność wyniku. Prace otwarte, takie jak refaktoryzacja czy projektowanie, na razie się nie kwalifikują, ponieważ nie ma czego sprawdzać, a pętla bez bramki to kosztowny sposób na generowanie długu technicznego w recenzjach.