Czym jest projektowanie pętli agenta AI? Definicja

Znaczenie projektowania pętli

Projektowanie pętli polega na zaprojektowaniu cyklu, w którym działa agent AI: określeniu, co go uruchamia, do czego może uzyskać dostęp, jak sprawdzane są jego wyniki oraz co go zatrzymuje. Projektowanie promptów kształtuje pojedynczą wiadomość wysyłaną do modelu. Projektowanie pętli kształtuje proces, który wysyła tysiące wiadomości, gdy użytkownik śpi. Jednostka pracy zmienia się z promptu na pętlę.

W skrócie: przestaje się pisać instrukcje, a zaczyna się tworzyć system sterowania. Agent nadal potrzebuje dobrych instrukcji, ale stają się one jednym z elementów cyklu, który działa zgodnie z harmonogramem, pracuje w odizolowanej kopii kodu, potwierdza wynik za pomocą testu i kończy działanie po wyczerpaniu budżetu.

Dlaczego termin pojawił się w 2026 roku

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), pod hasłem „Stop prompting. Design the loop. Get a score.” Opisuje ono tę zmianę za pomocą sześciu elementów: planowania zadań, worktree, umiejętności, wtyczek i konektorów, podagentów oraz trwałej pamięci przechowywanej poza rozmową.

Zawiera cytat Borisa Cherny’ego, który kieruje Claude Code w Anthropic:

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,100 gwiazdek (stan na lipiec 2026) i bezpośrednio określa obie role: „uprząż kodu” (codebase harness), która zapewnia repozytorium bezpieczne środowisko do uruchamiania testów i wdrożeń przez agenta, oraz „inżyniera pętli” (loop engineer), który tworzy przepływy pracy uruchamiane przez wyzwalacz, wykonujące zadania i zapisujące zdobyte informacje we współdzielonym pliku, aby kolejna pętla mogła je odczytać.

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

Cztery elementy pętli

Każda działająca pętla ma te cztery elementy. Pętla, która pomija jeden z nich, może obudzić użytkownika o 3am.

• Wyzwalacz. Zdarzenie rozpoczynające wykonanie: timer, webhook, nowy pull request lub alert.
• Zakres. Pliki, dane uwierzytelniające i sieć, do których agent może uzyskać dostęp podczas tego wykonania.
• Weryfikacja. Kontrola z kodem wyjścia, który decyduje, czy wynik wykonania zostanie zachowany, czy odrzucony.
• Budżet. Limit tokenów, czasu i kosztów, który kończy wykonanie niezależnie od tego, czy zakończyło się powodzeniem.

Zamiana tych czterech elementów na pytania daje przegląd projektu dowolnego agenta, który ma działać bez nadzoru.

Wyzwalacz: co uruchamia agenta

Timer jest najprostszym wyzwalaczem. Na serwerze Linux timer systemd sprawdza się lepiej niż cron, ponieważ zapisuje zdarzenia w dzienniku, ponawia uruchomienia zgodnie z konfiguracją i nie uruchamia drugiej kopii jednostki, która nadal działa. Ta ostatnia właściwość eliminuje najczęstszy błąd nakładania się uruchomień w pętlach agentów: dwa uruchomienia modyfikujące tę samą gałąź.

Zapisz 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

Zapisz 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świetlać 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 jego uruchomienie dopiero przy następnym rozruchu. TimeoutStartSec=1800 ma większe znaczenie, niż mogłoby się wydawać: agent oczekujący na dane wejściowe może w przeciwnym razie pozostawać aktywny bez końca, a timer nigdy nie uruchomi się ponownie. Informacje o uruchomieniu można odczytać za pomocą journalctl -u agent-loop.service -n 50.

Jeśli pętla jest uruchamiana z crona, należy dodać własne zabezpieczenie przed nakładaniem się uruchomień, ponieważ cron bez problemu uruchomi drugą kopię:

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

flock -n natychmiast kończy działanie ze statusem 1, gdy blokada jest zajęta. Drugie uruchomienie kończy się więc po cichu, zamiast konkurować 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.

Granica: każdy przebieg otrzymuje własną kopię

Agent edytujący drzewo robocze może utracić niezatwierdzone zmiany. Git worktrees rozwiązują ten problem niewielkim kosztem: każdy przebieg otrzymuje własny katalog i własną gałąź, a wszystkie przebiegi współdzielą 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 po jednym wierszu dla każdego drzewa, podając jego ścieżkę, commit i gałąź. Po zakończeniu przebiegu git worktree remove /srv/agent/work/triage-01 usuwa katalog, a git worktree prune usuwa wpisy, których katalog już nie istnieje. Pętle równoległe stają się wtedy bezpieczne, ponieważ dwa agenty działające na dwóch gałęziach i w dwóch katalogach nie mogą nadpisać swoich zmian.

Granica dotyczy również poświadczeń. Pętla działająca bez nadzoru przechowuje tokeny przez długi czas, a każdy przebieg stwarza możliwość ujawnienia tokenu w logu, commicie lub kontekście modelu. Ogranicz zakres tokenu do jednego repozytorium, którego dotyka pętla, i w miarę możliwości nie udostępniaj go w środowisku widocznym dla powłoki agenta. Przed przyznaniem pętli dostępu produkcyjnego zapoznaj się z zasadami ochrony sekretów przed agentami AI. Mocniejszą izolację zapewnia uruchomienie całej pętli na jednorazowej maszynie wirtualnej, którą można zniszczyć po każdym przebiegu.

Weryfikacja: bramka, która zapewnia bezpieczeństwo pętli

To właśnie odróżnia pętlę od zadania cron, które tylko wpisuje polecenia. Wynik agenta jest propozycją. 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 w tym skrypcie rzeczywistą pracę. Bez -e nieudane git fetch zostaje zignorowane, a wykonanie jest kontynuowane z użyciem nieaktualnego origin/main. Bez -u literówka w nazwie zmiennej zostaje rozwinięta do pustego ciągu, a czyszczenie zostaje wykonane w niewłaściwej ścieżce zamiast zakończyć się jednoznacznym błędem.

Blok if ! npm test stanowi sedno całego rozwiązania. Kod wyjścia kontroli, której można już ufać — 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 przeglądać. Jest to gorsze niż brak pracy. Pętla z bramką generuje gałąź, która przeszła już ten sam poziom kontroli, jaki musi przejść gałąź człowieka wnoszącego zmiany.

Należy wybrać bramkę, która rzetelnie sygnalizuje niepowodzenie. Zestaw testów, który kończy się powodzeniem dla pustego diffu, uczy pętlę, że brak działania jest sukcesem. Repozytoria ze słabymi testami tworzą słabe pętle. Dlatego popularne repozytoria stawiają „przygotowanie bazy kodu do pracy agenta” przed „napisaniem pętli”.

Budżet: co zatrzymuje wykonanie

Agent, który ponawia próby bez końca, generuje nieograniczone koszty. Każda pętla powinna mieć limit czasu rzeczywistego, wymuszany przez TimeoutStartSec powyżej, limit liczby ponowień w skrypcie oraz limit wydatków wymuszany przez konto dostawcy. Należy również rejestrować koszt każdego wykonania. Dzięki temu można wykryć narastanie kosztów pętli, zanim pojawi się ono na fakturze. Kontrola kosztów stale działającego agenta VPS opisuje kwestie rozliczeń, a zarządzanie kontekstem zachowywanym przez agenta między turami dotyczy największego pojedynczego czynnika wpływającego na koszt wykonania. Pętla, która co 30 minut ponownie odczytuje to samo repozytorium, ponosi ten koszt co 30 minut.

Koszt jest powodem, dla którego pętle zwykle są lepsze niż jedna długa sesja. Wykonanie rozpoczynające się od nowa, realizujące jedno wąsko określone zadanie i kończące działanie utrzymuje niewielki kontekst. Sesja pozostawiona otwarta przez osiem godzin zachowuje w historii wszystkie wcześniejsze błędy i przy każdej turze ponownie uwzględnia cały zapis rozmowy.

Wzorce formalizowane przez popularne repozytoria

Repozytorium loop-engineering opisuje siedem wzorców stosowanych w środowisku produkcyjnym. Warto traktować je jako zestaw możliwości, a nie manifest. Codzienny triage. Mechanizm obsługi pull requestów, który monitoruje komentarze recenzentów i odpowiada na nie. Mechanizm porządkowania wyników continuous integration, który podejmuje obsługę kompilacji zakończonych błędem. Mechanizm aktualizacji zależności. Przygotowywanie wersji roboczej dziennika zmian. Porządki po scaleniu zmian. Triage zgłoszeń.

Wzorce te mają wspólną cechę: wykonują ograniczone zadanie z jednoznacznym warunkiem przejścia. Polecenie „napraw kompilację zakończoną błędem” ma warunek powodzenia, który może odczytać maszyna. Polecenie „ulepsz bazę kodu” takiego warunku nie ma, dlatego nigdy nie staje się pętlą. Staje się nieuporządkowanym zadaniem wykonywanym zgodnie z harmonogramem.

Wzorce te mają również wspólny zapis wykonanych działań. Oba repozytoria przenoszą informacje o stanie z rozmowy do plików w repozytorium: co zostało uruchomione, co znaleziono i jaką podjęto decyzję. Ten plik jest pamięcią pętli. Dzięki niemu druga pętla może wykorzystać pracę pierwszej, zamiast ponownie wyszukiwać te same informacje. Umożliwia on również późniejszy audyt agenta, ponieważ kontekst modelu znika natychmiast po zakończeniu wykonania.

Gdzie zawodzą pętle

Problemy są prozaiczne i powtarzają się w różnych zespołach.

• Brak kontroli. Dane wyjściowe narastają, nikt ich nie weryfikuje, zaufanie spada i pętla zostaje wyłączona.
• Nakładanie się uruchomień. Dwa uruchomienia w jednej gałęzi albo dwóch agentów w jednym drzewie roboczym powoduje konflikty, które agent następnie próbuje rozwiązać.
• Niezauważalny dryf. Pętla nadal przechodzi, ponieważ sprawdzenie jest zbyt słabe, aby zakończyć się niepowodzeniem.
• Nieograniczony zakres. Wyzwalacz uruchamiany przy każdym zatwierdzeniu w aktywnym repozytorium w ciągu jednego dnia staje się problemem związanym z kosztami.

Każdy z tych problemów ma takie samo rozwiązanie: ograniczyć zadanie, zaostrzyć sprawdzenie i rejestrować uruchomienie. Jeśli warunku zaliczenia nie można opisać jednym zdaniem, zadanie nie jest jeszcze gotowe do automatyzacji.

Rozpoczęcie bez znajomości terminologii

Nie jest potrzebny framework. Niewielki, stale działający serwer Linux, repozytorium git, którego zestaw testów kończy się niepowodzeniem, gdy powinien, jeden zegar systemd oraz jeden skrypt powłoki zawierający if tworzą kompletną pętlę. Od tego powinno zacząć większość osób, ponieważ kwestie projektowe zostają rozstrzygnięte podczas uruchamiania rozwiązania, a nie podczas wyboru narzędzia. Gdy jedna pętla działa stabilnie, uruchomienie drugiej wymaga głównie dodania kolejnego zegara i kolejnego worktree. Zobacz jak uruchomić agenta AI do programowania na VPS, aby skonfigurować środowisko bazowe, oraz aktualne opcje samodzielnie hostowanych agentów AI, jeśli agent ma działać na sprzęcie pozostającym pod kontrolą użytkownika.

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 i format danych wyjściowych. Inżynieria pętli optymalizuje cykl wokół wiadomości: wyzwalacz rozpoczynający uruchomienie, środowisko izolowane, w którym ono działa, kontrolę akceptującą lub odrzucającą dane wyjściowe oraz budżet kończący cykl. W pętli nadal potrzebny jest dobry prompt. Nie trzeba jednak codziennie dostrajać go jako głównego elementu, ponieważ bramka i wyzwalacz mają większy wpływ na wynik.

Czy do zbudowania pętli agenta potrzebny jest framework?

Nie. Timer systemd, osobny git worktree dla każdego uruchomienia, skrypt powłoki kończący działanie poleceniem testowym oraz limit wydatków na koncie dostawcy obejmują wszystkie elementy tej definicji. Frameworki dodają interfejsy harmonogramowania, wspólne formaty pamięci i routing między agentami. Są przydatne po uruchomieniu kilku pętli. Nie są jednak wymagane do rozpoczęcia pracy z pierwszą pętlą.

Czym jest uprząż dla codebase?

Jest to zestaw elementów umożliwiających agentowi pracę w repozytorium bez obecności człowieka: konfiguracja wykonywana jednym poleceniem, testy uruchamiane nieinteraktywnie i kończące się jednoznacznym błędem, linter oraz sposób wdrażania lub podglądu zmiany. Termin ten pojawił się w tej samej fali repozytoriów z 2026 co inżynieria pętli. Praktyczny test jest prosty: jeśli nowy człowiek współtworzący projekt nie może przejść od sklonowania repozytorium do pomyślnego zakończenia testów jednym poleceniem, agent również nie będzie mógł tego zrobić.

Jak zatrzymać pętlę agenta, zanim wygeneruje wysoki rachunek?

Ustaw limity w trzech miejscach. Ustaw TimeoutStartSec w jednostce systemd, aby zakończyć zawieszone uruchomienie. Ogranicz liczbę ponowień w skrypcie, zamiast wykonywać pętlę do skutku. Ustaw twardy limit wydatków na koncie API, ponieważ jest to jedyny limit, którego agent nie może obejść za pomocą argumentacji. Następnie rejestruj koszt każdego uruchomienia, ponieważ podwojenie kosztu pętli zwykle oznacza niekontrolowane rozszerzenie jej zakresu.

Które zadania warto najpierw przekształcić w pętlę?

Wybierz zadanie z warunkiem powodzenia możliwym do odczytu maszynowego i o niewielkim promieniu oddziaływania. Naprawa nieudanego builda, aktualizacja zależności i ponowne wygenerowanie dziennika zmian spełniają te warunki, ponieważ wynik można potwierdzić za pomocą zestawu testów lub diff. Praca otwarta, taka jak refaktoryzacja lub projektowanie, jeszcze się do tego nie nadaje, ponieważ bramka nie ma czego sprawdzać. Pętla bez bramki to kosztowny sposób generowania zaległości w przeglądach.