Pętla Ralph: jak uruchamiam autonomiczne agenty AI na noc

Zbudowałem system autonomicznych agentów, który wykorzystuje hooki zatrzymania do przechwytywania prób zakończenia, pamięć opartą na systemie plików do zachowania stanu między oknami kontekstowymi oraz budżety spawnowania, aby zapobiec niekontrolowanej rekurencji. System dostarczył moją infrastrukturę deliberacji obejmującą 9 PRD (3455 linii Python, 141 testów) w ciągu wielu nocnych sesji.¹

TL;DR

Architektura Ralph umożliwia długotrwałe autonomiczne tworzenie oprogramowania przez AI, rozwiązując jednocześnie trzy problemy: wyczerpanie okna kontekstowego (rozwiązane przez świeży kontekst w każdej iteracji), trwałość stanu (rozwiązane przez system plików jako pamięć) oraz ciągłość zadań (rozwiązane przez pętle hooków zatrzymania, które uniemożliwiają agentowi zakończenie pracy przed ukończeniem zadania). Zaimplementowałem ten wzorzec w moim systemie hooków Claude Code i wykorzystałem go do budowy mojej infrastruktury deliberacji wieloagentowej. System działa, ale nauczył mnie trudnych lekcji o budżetach spawnowania, jakości kryteriów i zanieczyszczaniu systemu plików.

Problem okna kontekstowego

Każda konwersacja z AI operuje w ramach okna kontekstowego: bufora o stałym rozmiarze, przechowującego historię rozmowy, prompty systemowe, wyniki narzędzi i pamięć roboczą. Okno kontekstowe Claude mieści około 200 000 tokenów. Złożona sesja programistyczna może je wyczerpać w ciągu 30–60 minut intensywnej pracy.²

Zmierzyłem to bezpośrednio podczas budowy systemu deliberacji. Sesje, które zaczynały się od precyzyjnych edycji wielu plików w 8 modułach Python, degradowały się do tunelowego widzenia pojedynczego pliku po około 90 minutach. Agent przestawał odwoływać się do architektury, którą wcześniej przeczytał, ponieważ ten kontekst został skompresowany.³

Degradacja przebiega według przewidywalnej krzywej:

Iteration 1: [200K tokens] → writes code, creates files
Iteration 2: [200K tokens] → reads files from disk, continues
Iteration 3: [200K tokens] → reads updated files, continues
...
Iteration N: [200K tokens] → reads final state, verifies criteria

Porównajmy to z pojedynczą długą sesją:

Minute 0:  [200K tokens available] → productive
Minute 30: [150K tokens available] → somewhat productive
Minute 60: [100K tokens available] → degraded
Minute 90: [50K tokens available]  → significantly degraded
Minute 120: [compressed, lossy]    → errors accumulate

Agent ze świeżym kontekstem w każdej iteracji przewyższa agenta pracującego w ciągłej sesji, ponieważ każda iteracja przydziela pełne zasoby poznawcze do bieżącego stanu, zamiast dźwigać ciężar wcześniejszego rozumowania.

Moja implementacja

Hook zatrzymania

Mój system ochrony przed rekurencją przechwytuje próby zatrzymania agenta i sprawdza kryteria ukończenia:

#!/bin/bash
# From recursion-guard.sh - simplified
CONFIG_FILE="${HOME}/.claude/configs/recursion-limits.json"
STATE_FILE="${HOME}/.claude/state/recursion-depth.json"

# Safe defaults with config override
MAX_DEPTH=2
MAX_CHILDREN=5
DELIB_SPAWN_BUDGET=2
DELIB_MAX_AGENTS=12

# Load config with validation
load_config() {
    if [[ -f "$CONFIG_FILE" ]] && command -v jq &>/dev/null; then
        config_depth=$(jq -r '.max_depth // 2' "$CONFIG_FILE")
        if [[ "$config_depth" =~ ^[0-9]+$ ]] && [[ "$config_depth" -gt 0 ]]; then
            MAX_DEPTH="$config_depth"
        fi
    fi
}

Hook odczytuje plik kryteriów definiujący warunki sukcesu. Warunki muszą być weryfikowalne maszynowo: wynik testów (pass/fail), dane wyjściowe lintera, kody statusu HTTP, sprawdzanie istnienia plików.⁴

System plików jako trwała pamięć

Kluczowe spostrzeżenie: pliki przetrwają między oknami kontekstowymi. Mój katalog .claude/ służy jako trwała pamięć agenta — to rozproszona architektura kontekstu, która z tego początkowego wzorca opartego na systemie plików rozrosła się do siedmiowarstwowego systemu liczącego 650 plików:

Każda nowa iteracja odczytuje bieżący stan z dysku i kontynuuje od miejsca, w którym zakończyła się poprzednia. Hook startu sesji inicjalizuje czysty stan:

# From session-start.sh - recursion state initialization
RECURSION_STATE_FILE="$RECURSION_STATE_DIR/recursion-depth.json"
# Initialize with safe defaults
{
  "depth": 0,
  "agent_id": "root",
  "parent_id": null,
  "initialized_by": "session-start"
}

Jeśli stan ulegnie uszkodzeniu (co zdarzyło się dwa razy podczas rozwoju), wzorzec odzyskiwania odtwarza go z bezpiecznych wartości domyślnych zamiast powodować awarię:

if ! jq -e '.depth' "$RECURSION_STATE_FILE" &>/dev/null; then
    # Corrupted state file, recreate with safe defaults
    echo "- Recursion state recovered (was corrupted)"
fi

Format specyfikacji zadania

Skuteczne zadania Ralph zawierają trzy elementy: cel, kryteria ukończenia i wskaźniki kontekstu:

OBJECTIVE: Implement multi-agent deliberation with consensus validation.

COMPLETION CRITERIA:
- All tests in tests/test_deliberation_lib.py pass (81 tests)
- post-deliberation.sh validates consensus above 70% threshold
- recursion-guard.sh enforces spawn budget (max 12 agents)
- deliberation-pride-check.sh passes 5 quality checks
- No Python type errors (mypy clean)

CONTEXT:
- Follow patterns in lib/deliberation/state_machine.py
- Consensus thresholds in configs/deliberation-config.json
- Spawn budget model: agents inherit budget, not increment depth

Co zbudowałem z wykorzystaniem tego wzorca

Infrastruktura deliberacji (9 PRD)

Największy projekt w pętli Ralph: 9 dokumentów wymagań produktowych (PRD) zaimplementowanych w wielu sesjach.

Łączny wynik: 3455 linii Python w 8 modułach, 141 testów, 4 commity. Każda sesja kontynuowała pracę od stanu systemu plików pozostawionego przez poprzednią. Świeży kontekst oznaczał, że każde PRD otrzymywało pełną uwagę agenta bez obciążenia historią konwersacji z wcześniejszych PRD.⁵

System jakości bloga (12 modułów)

Linter bloga zaczynał jako skrypt z 3 modułów i rozrósł się do 12 modułów poprzez iteracyjne pętle Ralph. Każda iteracja dodawała moduł, uruchamiała pełny zestaw testów i weryfikowała zero regresji. Kryteria ukończenia ewoluowały:

• Iteracja 1: „Wszystkie 77 testów przechodzi”
• Iteracja 5: „Wszystkie 77 testów przechodzi ORAZ linter raportuje 0 błędów we wszystkich 33 postach”
• Iteracja 8: „Wszystkie testy przechodzą ORAZ 0 błędów ORAZ 0 ostrzeżeń ORAZ wynik głębokości ≥2 we wszystkich postach”

Porażki i lekcje

Porażka 1: katastrofa budżetu spawnowania

Na początku budowy systemu deliberacji uruchomiłem sesję bez limitów budżetu spawnowania. Agent utworzył 3 podagenty eksploracyjne. Każdy podagent utworzył własne podagenty. W ciągu kilku minut hook recursion-guard przechwytywał dziesiątki prób spawnowania. Sesja zużywała tokeny API w tempie 10-krotnie wyższym niż normalnie, zanim ręcznie ją zakończyłem.⁶

Rozwiązanie: Dodałem model budżetu spawnowania do recursion-limits.json. Agenty dziedziczą budżet od swojego rodzica zamiast inkrementować głębokość. Agent główny z budżetem=12 może utworzyć łącznie do 12 agentów na wszystkich poziomach rekurencji. To było kluczowe spostrzeżenie architektoniczne: dziedziczenie budżetu zapobiega wykładniczemu wzrostowi, jednocześnie pozwalając na głębokie łańcuchy agentów. Budżet spawnowania odpowiada bezpośrednio regule separacji z algorytmu boids Reynoldsa — ograniczeniu, które nie pozwala agentom stłoczyć się wokół tego samego podproblemu.

Porażka 2: kryteria spełniane trywialnie

Wczesne zadanie prosiło agenta o „napisanie testów, które przechodzą”. Agent napisał minimalne testy: assert True, assert 1 == 1. Technicznie kryteria zostały spełnione. Wynik był bezwartościowy.

Rozwiązanie: Kryteria muszą określać zarówno ilość, jak i jakość:

Porażka 3: zanieczyszczanie systemu plików

Iteracje eksplorujące ślepe zaułki zostawiały artefakty: częściowo zaimplementowane funkcje, przestarzałe pliki, sprzeczne konfiguracje. Iteracja 5 mogła budować na niedokończonym podejściu z iteracji 3, które zostało porzucone w iteracji 4.

Rozwiązanie: Dodałem krok czyszczenia do kryteriów hooka zatrzymania: „Nie istnieją pliki, które nie są referencjonowane przez importy lub testy”. To zmusza agenta do posprzątania ślepych zaułków, zanim iteracja może zostać ukończona.

Porażka 4: incydent z ((VAR++))

Podczas testów integracyjnych bash hook recursion-guard zawiódł po cichu w pierwszej iteracji. Błąd: ((VAR++)) zwraca kod wyjścia 1, gdy VAR wynosi 0 (ponieważ 0++ ewaluuje się do 0, co bash traktuje jako fałsz). Z włączonym set -e zabijało to skrypt.

Rozwiązaniem było VAR=$((VAR + 1)) zamiast ((VAR++)). Ten pułapka bash, udokumentowana w moim MEMORY.md, zapobiegła temu samemu błędowi w 6 kolejnych skryptach hooków.⁷

Kiedy Ralph działa, a kiedy nie

Dobre dopasowanie

• Implementacja od zera z jasnymi specyfikacjami (nowe API, nowy moduł, nowy zestaw testów)
• Automatyczna weryfikacja istnieje (testy, sprawdzanie typów, lintery, kompilacja)
• Ograniczony zakres, który można opisać w pojedynczym pliku zadania

Słabe dopasowanie

• Subiektywna jakość („niech UI ładnie wygląda”) nie ma maszynowo weryfikowalnych kryteriów
• Praca eksploracyjna, gdzie kierunek zależy od odkryć na etapach pośrednich
• Refaktoryzacja na dużą skalę, wymagająca zrozumienia globalnych relacji w kodzie w dziesiątkach plików

Kluczowe wnioski

Dla programistów budujących systemy autonomicznych agentów: - Należy zainwestować w maszynowo weryfikowalne kryteria ukończenia przed uruchomieniem autonomicznych pętli; mój system deliberacji odniósł sukces, ponieważ każde PRD miało testowalne kryteria sukcesu (łącznie 141 testów) - Budżety spawnowania należy wdrożyć od pierwszego dnia; model dziedziczenia budżetu (a nie inkrementacji głębokości) zapobiega wykładniczemu spawnowaniu agentów, jednocześnie umożliwiając głębokie łańcuchy - Do kryteriów ukończenia należy dodać czyszczenie systemu plików; artefakty ze ślepych zaułków porzuconych iteracji będą zanieczyszczać kolejne iteracje

Dla zespołów inżynierskich oceniających autonomiczne tworzenie oprogramowania przez AI: - Architektura Ralph zamienia czas ludzkiej implementacji na czas ludzkiej specyfikacji; ROI zależy od tego, czy wąskim gardłem jest zdolność implementacyjna czy jasność specyfikacji - Wyniki autonomicznej pracy należy audytować z taką samą rygorem, jaki stosuje się do kodu od zewnętrznych wykonawców; moje 141 testów istnieje, ponieważ nauczyłem się, że spełnienie kryteriów ukończenia nie gwarantuje gotowości produkcyjnej

Często zadawane pytania

Czym jest pętla Ralph w autonomicznym tworzeniu oprogramowania przez AI?

Pętla Ralph to architektura długotrwałego autonomicznego tworzenia oprogramowania przez AI, która rozwiązuje jednocześnie trzy problemy: wyczerpanie okna kontekstowego (świeży kontekst w każdej iteracji zamiast jednej degradującej się sesji), trwałość stanu (system plików jako pamięć ponad granicami kontekstu) oraz ciągłość zadań (hooki zatrzymania, które nie pozwalają agentowi zakończyć pracy przed spełnieniem kryteriów ukończenia). Każda iteracja startuje z pełnym oknem kontekstowym 200K tokenów, odczytuje bieżący stan z dysku, kontynuuje pracę i zapisuje zaktualizowany stan z powrotem. Ten wzorzec dostarczył 3455 linii kodu Python i 141 testów w trakcie wielu nocnych sesji.

Czy agenty AI mogą pracować autonomicznie przez całą noc i pisać kod?

Tak, przy odpowiedniej infrastrukturze. Architektura pętli Ralph umożliwia nocne autonomiczne tworzenie oprogramowania dzięki połączeniu maszynowo weryfikowalnych kryteriów ukończenia (przechodzące lub niezaliczone testy, wynik lintera, sprawdzanie typów), budżetów spawnowania zapobiegających niekontrolowanej rekurencji oraz trwałości stanu opartej na systemie plików. Za pomocą tego wzorca zaimplementowałem 9 dokumentów PRD w trakcie wielu nocnych sesji. Kluczowym wymaganiem jest maszynowa weryfikowalność kryteriów ukończenia — subiektywne cele w rodzaju „spraw, żeby interfejs dobrze wyglądał” nie działają, ponieważ agenty spełniają niejasne kryteria w sposób trywialny.

Jak monitorować autonomiczne agenty AI, aby uniknąć niekontrolowanych kosztów?

Zachowanie autonomicznych agentów kontrolują trzy mechanizmy. Po pierwsze, budżety spawnowania ograniczają łączną liczbę agentów (domyślnie maksymalnie 12), wykorzystując dziedziczenie budżetu zamiast limitów głębokości — agenty dziedziczą pozostały budżet od rodzica, co zapobiega wykładniczemu wzrostowi, a mimo to dopuszcza pracę równoległą. Po drugie, hooki uruchamiają się w każdym punkcie cyklu życia i wymuszają ograniczenia, których model nie może pominąć. Po trzecie, kryteria ukończenia definiują maszynowo weryfikowalne warunki sukcesu, które hook zatrzymania sprawdza, zanim pozwoli agentowi zakończyć pracę. Bez budżetów spawnowania moje wczesne sesje zużywały tokeny API w tempie 10 razy wyższym niż normalne, dopóki nie zareagowałem ręcznie.

Jakie zabezpieczenia są potrzebne przy autonomicznym tworzeniu oprogramowania przez AI?

Niezbędne są cztery kategorie zabezpieczeń. Hooki prewencyjne (PreToolUse) blokują niebezpieczne operacje, takie jak wymuszony push na gałąź main czy odczyt plików z danymi uwierzytelniającymi. Budżety spawnowania zapobiegają rekurencyjnemu tworzeniu agentów — dziedziczenie budżetu jest bezpieczniejsze niż limity głębokości, ponieważ nakłada górny limit na łączną liczbę agentów, a jednocześnie dopuszcza szeroką współpracę równoległą. Wymogi porządkowania systemu plików chronią przed zanieczyszczeniem pozostałym po porzuconych iteracjach. Kryteria ukończenia muszą zaś określać zarówno ilość, jak i jakość — „testy przechodzą” daje trywialne testy w rodzaju assert True, natomiast „testy przechodzą ORAZ pokrycie >80% ORAZ brak błędów typów ORAZ linter czysty” daje wynik jakości produkcyjnej.

Kiedy pętla Ralph sprawdza się dobrze, a kiedy słabo?

Pętla Ralph sprawdza się najlepiej przy implementacjach od zera z jasną specyfikacją (nowe API, moduły, zestawy testów), przy zadaniach z automatyczną weryfikacją (testy, kontrolery typów, lintery) oraz przy ograniczonym zakresie, który da się opisać w jednym pliku zadania. Słabo radzi sobie z subiektywnymi celami jakościowymi pozbawionymi maszynowo weryfikowalnych kryteriów, z pracą eksploracyjną, której kierunek zależy od pośrednich odkryć, oraz z refaktoryzacją na dużą skalę, wymagającą zrozumienia globalnych zależności kodu w dziesiątkach plików. Zwrot z inwestycji zależy od tego, czy wąskim gardłem jest zdolność implementacyjna, czy klarowność specyfikacji.

Źródła