Background agents i Ralph loop — kiedy mają sens, a kiedy palą tokeny

Background agenty (działające równolegle do mojej sesji) i Ralph loop (autonomiczna pętla z prompta z self-paced timing) to dwa narzędzia które potrafią dać 10x produktywności. Albo 10x kosztów. Granica jest cienka, pokazuję co ja w niej widzę.

Dwa tryby autonomii

Background agent: spawnujesz Agent z run_in_background: true. Wraca asynchronicznie, ty robisz coś innego w głównej sesji. Klasyczne use case: research, długi build, batch generacja.

Ralph loop: agent sam decyduje kiedy wrócić, używając ScheduleWakeup lub /loop. Działa w pętli z określonym celem dopóki ten cel nie jest spełniony albo dopóki nie powiesz "stop".

Pierwszy to "fire and forget", drugi to "fire and live with it".

Background agent: trzy realne case'y

1. Research równoległy

Mam 3 pytania o codebase. Spawnuję 3 explore agenty równolegle, każdy szuka czegoś innego. W tym czasie sam piszę plan dla głównego zadania.

// Pseudokod — pseudokod to jest w głównej sesji
spawn Agent({ description: "Find auth middleware", subagent: "Explore" })
spawn Agent({ description: "Map RBAC roles", subagent: "Explore" })
spawn Agent({ description: "Audit token storage", subagent: "Explore" })
// 3 minuty wszystkie 3 wracają, ja czekam tylko 3 minuty zamiast 9

Zysk: czas jest paralelizowany. Strata: token cost × 3, każdy agent ładuje swój kontekst.

2. Czekanie na coś długiego

Build trwa 8 minut. Spawnuję agenta który "patrzy na ten build i wraca z verdict-em". Ja w tym czasie piszę kolejne zmiany. Gdy build się skończy, dostaję notyfikację z wynikiem.

Klucz: agent nie ma sleep'a. Używa Monitor toola streamującego zdarzenia. Bezczynny, nie pali tokenów.

3. Generacja batch'owa

Mam 50 produktów do opisu na sklepie. Background agent generuje wszystkie 50 w pętli. Ja w głównej sesji robię UI dla tego sklepu. Gdy skończy, łączę.

Pułapka: jakość spada przy długich pętlach. Po ~30 elementach zaczynają się powtórzenia. Reguła: batch maks. 30, większe dziele na mniejsze sesje.

Ralph loop: dwa case'y które działają

1. Polling status

"Co 5 minut sprawdzaj status deployu, daj znać gdy zakończony". Pętla z /loop 5m. Pętla zatrzymuje się sama gdy deploy = success.

Działa bo: cel jest binarny, łatwo zweryfikować, koszt każdej iteracji niski.

2. Babysitting długiego procesu

Zlecam Ralphowi: "monitoruj testy, jak coś padnie, fix-up loop, max 3 iteracje". Po 3 nieudanych próbach zatrzymuje się i woła mnie.

Działa bo: jasna terminacja, bounded retry, model nie próbuje "magicznie naprawić" w nieskończoność.

Czego NIE robi Ralph

Trzy rzeczy w których Ralph regularnie zawodzi:

1. "Pisz kod aż będzie dobry." Brak jasnego celu = nieskończona pętla. Token cost rośnie liniowo, jakość wcale.

2. Eksploracja "co możesz zrobić". Open-ended generowanie. Model się rozsiada na różne tory, każda iteracja zaczyna w innym miejscu. Bez wartości.

3. Coś co wymaga creative judgment. "Napisz lepszą wersję posta". Co znaczy "lepsza"? Bez external feedbacka model krąży.

Reguła którą stosuję

Przed włączeniem Ralpha lub background agenta zadaję sobie 3 pytania:

Czy jest jasny stop condition? ("kompiluje się" tak, "wygląda dobrze" nie)
Czy każda iteracja jest tania? (< $0.50 per iter, < 30 sec)
Czy mogę to zrobić sam w 15 min? Jeśli tak, zrób sam, mniej overheadu.

Jeśli jakieś nie, nie włączam.

Token cost: realny rachunek

Z mojego billingu:

Use case	Czas	Koszt
1 background explore	2 min	$0.30
3 paralel exploreów	3 min wall	$0.90 ($0.30 × 3)
Ralph polling 5m, 30 min total	30 min	~$0.20
Ralph "fix tests" 3 iteracje	8 min	~$1.50
Ralph open-ended (bez stop condition)	60 min	$15+ ❌

Ostatnia linia to mój błąd z marca. Włączyłem Ralpha do "ulepszenia kodu", spawn dziecka 60 minut, dostałem $20 rachunek za nic. Stąd reguła stop condition.

Setup techniczny

Background agent spawnowanie:

Agent({
  description: "Audit deps for CVE",
  subagent_type: "general-purpose",
  prompt: "Run npm audit i pip-audit w ~/projects/*. ...",
  run_in_background: true
})

Ralph loop przez /loop:

/loop /check-deploy-status
# albo dynamic:
/loop
> Sprawdzaj co kilka minut czy CI przeszło na PR #123. Stop gdy zielone.

Stop kontrolny: zawsze mogę przerwać przez Ctrl+C w głównej sesji albo przez /loop-stop.

TL;DR

Background agenty: świetne do paralelizacji niezależnej pracy. Każdy z jasnym celem, ograniczonym scope.

Ralph loop: świetny do polling i bounded fix-up. Zły do creative work i open-ended.

Reguła kosztu: stop condition + tania iteracja + nie-zrobię-tego-sam-szybciej. Spełnione 3/3, włączaj. Mniej, zrób sam.

Autonomia agenta to kontinuum, nie binarka. Im mniej autonomii, tym mniej się myli ale więcej Cię kosztuje czasowo. Im więcej autonomii, tym potencjalnie szybciej ale ryzyko strat tokenów rośnie. Wybieraj świadomie, mierz koszty, miej stop condition.