Przejdź do głównej zawartości
AI Developer Toolkit

Godziny autonomii: GSD Core, pętle Ralph, /goal i oh-my-claudecode

Pętle autonomiczne utrzymują agenta programistycznego w pracy przez wiele godzin bez człowieka, który co turę wciska Enter: wbudowane polecenie /goal w Claude Code i Codex, technika Ralph (wtyczka ralph-loop, ralph.sh od snarktank, ralph od frankbria), /gsd-autonomous z GSD Core oraz harnessy oh-my-claudecode i oh-my-codex. Każda z nich jest warta tyle, ile wyrocznia testowa, która decyduje o jej zatrzymaniu.

Masz jasne, nudne zadanie: 140 starych plików JavaScript do przeniesienia na TypeScript albo backlog 12 małych historyjek z gotowymi testami. Chcesz je uruchomić o 19:00 i o 9:00 przejrzeć gałąź. Ostatnim razem ktoś z zespołu puścił agenta na laptopie z --dangerously-skip-permissions, agent „skończył”, luzując dwie asercje, a jedna noc zjadła tygodniowy budżet.

Ta strona jest dla programisty, który uruchamia takie zadanie, i dla tech leada, który decyduje, gdzie przebiegi bez nadzoru są dozwolone: wybierz pętlę, uruchom ją w sandboksie z warunkiem stopu, którego agent nie sfałszuje, i rano w 15 minut przejrzyj dowody.

Która pętla autonomiczna pasuje do twojego zadania?

Dział zatytułowany „Która pętla autonomiczna pasuje do twojego zadania?”

Wszystkie te narzędzia nie pozwalają agentowi zakończyć tury, dopóki warunek nie jest spełniony. Różnią się tym, czy każda iteracja dostaje świeży kontekst, kto sprawdza warunek stopu i ile dokładają do kontekstu każdej sesji.

Twoje zadanieWybierzŚwieży kontekst co iterację?Kto decyduje o „gotowe”Stały koszt kontekstu (Claude Code)
Jeden cel, jedna sesja, polecenie, które go dowodziWbudowane /goal (Claude Code, Codex)Nie, jedna sesjaClaude Code: mały, szybki model po każdej turze. Codex: sam Codex, sprawdzający cel po każdej turze; pętla staje też na limicie użycia, budżecie tokenów celu albo tej samej blokadzie w trzech kolejnych turachZero: polecenie wbudowane, nie dodaje żadnej wtyczki
Ten sam prompt podawany ponownie w jednej sesji Claude Code albo CursoraWtyczka ralph-loop (od Anthropic dla Claude Code, własna Cursora dla Cursora)Nie, jedna sesjaDokładne dopasowanie ciągu <promise>, który wypisuje agent~84 tokeny
Backlog małych historyjek, każda mieści się w jednym kontekścieralph.sh od snarktankTak, nowy agent co iteracjęKażda historyjka w prd.json ma passes: true~195 tokenów (wtyczka ze skillami)
Długie przebiegi bez nadzoru, które muszą przetrwać limity APIralph od frankbriaTakWskaźniki ukończenia plus jawne EXIT_SIGNAL: trueNie jest wtyczką
Wielofazowy projekt greenfield z artefaktami planowania/gsd-autonomous z GSD CoreTak, świeże subagentyWeryfikator w każdej fazie; zatrzymuje się i pyta, gdy faza wymaga walidacji przez człowieka~10 700 tokenów
Zespół wielu agentów w Claude Codeoh-my-claudecode /autopilot, /ralphCzęściowo (subagenty)Jego pętle weryfikacji oparte na dowodach (testy, build, lint, typy)~3 915 tokenów
To samo w Codexoh-my-codex $ultragoalCzęściowoŚledzenie punktów kontrolnych dla każdego celuNiemierzalny: codex plugin w codex-cli 0.157.1 ma tylko add, list, marketplace i remove

Większość wyborów rozstrzygają dwie reguły. Jeśli zadanie mieści się w jednej sesji, a „gotowe” jest poleceniem, użyj /goal: jest wbudowane i utrzymuje je dostawca. Jeśli jest większe niż jedno okno kontekstu, wybierz pętlę, która co iterację uruchamia agenta od nowa i trzyma stan na dysku.

Popularność na 2026-09-26 (gwiazdki na GitHubie, dossier badawcze o frameworkach): oh-my-claudecode 39,4 tys., oh-my-codex 33,4 tys., snarktank/ralph 21,9 tys., GSD Core 9,9 tys. (zarchiwizowany oryginał 64,5 tys.), frankbria/ralph-claude-code 9,6 tys. Wtyczka ralph-loop miała tego dnia 196 527 instalacji w oficjalnym marketplace Anthropic.

Zainstaluj i uruchom każdą pętlę

Dział zatytułowany „Zainstaluj i uruchom każdą pętlę”

Wbudowane /goal

Dział zatytułowany „Wbudowane /goal”

/goal jest wbudowane w Claude Code od v2.1.139 i w Codex od CLI 0.128.0, domyślnie włączone od 0.133.0. Model sprawdzający oraz polecenia wstrzymania i wznowienia opisuje strona o poleceniu /goal.

/goal Every file in src/legacy/ is TypeScript, `npx tsc --noEmit` exits 0 and `npm test` passes. Do not edit anything under tests/.

Bez interfejsu, w sandboksie albo w CI, /goal działa w trybie print:

Okno terminala
claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

/goal jest zaimplementowane jako hook Stop o zasięgu sesji, więc nie działa tam, gdzie ustawiono disableAllHooks, gdzie ustawienia zarządzane dopuszczają tylko zarządzane hooki, ani w katalogu, dla którego nie zaakceptowałeś okna zaufania.

Pętle Ralph: technika i trzy gotowe pakiety

Dział zatytułowany „Pętle Ralph: technika i trzy gotowe pakiety”

Technika Ralph Geoffreya Huntleya uruchamia agenta na tym samym prompcie w pętli, trzyma stan w plikach i w gicie i opiera się na testach, typach i linterach jako mechanizmie hamującym (backpressure). Minimalna forma z ghuntley/how-to-ralph-wiggum to while :; do cat PROMPT.md | claude ; done, bez limitu i bez wyroczni; gotowe pakiety dodają jedno i drugie.

Wtyczka ralph-loop od Anthropic podaje prompt ponownie przez hook Stop w bieżącej sesji, więc między iteracjami przetrwa też rozmowa.

/plugin install ralph-loop@claude-plugins-official
/ralph-loop:ralph-loop "Migrate src/legacy/*.js to TypeScript. All tests pass, tsc exits 0. Output <promise>DONE</promise> when complete." --completion-promise "DONE" --max-iterations 30
/ralph-loop:cancel-ralph

Po każdej próbie zakończenia wraca ten sam prompt, aż agent wypisze <promise>DONE</promise> albo skończy się iteracja 30. /ralph-loop:cancel-ralph zatrzymuje pętlę wcześniej. Stan leży w .claude/ralph-loop.local.md. Skrypt instalacyjny podaje, że --max-iterations domyślnie nie ma limitu, a obietnica to dokładne dopasowanie ciągu.

snarktank/ralph (Ryan Carson) w każdej iteracji startuje nowego agenta z czystym kontekstem i przerabia prd.json po jednej historyjce:

/plugin marketplace add snarktank/ralph
/plugin install ralph-skills@ralph-marketplace

Napisz PRD skillem prd, zamień go na prd.json skillem ralph, skopiuj ralph.sh i szablon promptu CLAUDE.md do scripts/ralph/, a potem uruchom w sandboksie:

Okno terminala
./scripts/ralph/ralph.sh --tool claude 20

Każda iteracja implementuje następną historyjkę z passes: false, uruchamia kontrole, ustawia passes: true, dopisuje notatkę do progress.txt i commituje. Gdy wszystkie historyjki przechodzą, agent wypisuje <promise>COMPLETE</promise> i skrypt kończy działanie. Domyślnie jest 10 iteracji, a domyślnym narzędziem jest Amp; --tool przyjmuje tylko amp albo claude.

frankbria/ralph-claude-code dodaje limit wywołań (domyślnie 100 na godzinę), bezpiecznik i dwuwarunkową bramkę wyjścia:

Okno terminala
git clone https://github.com/frankbria/ralph-claude-code.git && cd ralph-claude-code && ./install.sh
cd ../my-project && ralph-enable && ralph --monitor

ralph-enable tworzy .ralph/ (prompt, plan i .ralphrc); ralph --calls 50 obniża godzinny limit.

Tryb autonomiczny GSD Core

Dział zatytułowany „Tryb autonomiczny GSD Core”

GSD Core, społecznościowy fork Get Shit Done, dla każdej fazy roadmapy przeprowadza discuss, plan, execute, verify i ship, a stan trzyma w .planning/. /gsd-autonomous prowadzi wszystkie pozostałe fazy (zakres ograniczają --from N, --to N i --only N), ale jego plik workflow mówi, że „pauses only for explicit user decisions (grey area acceptance, blockers, validation requests)”. W praktyce nocny przebieg zatrzymują dwie z tych sytuacji:

  • Faza, której weryfikator zwraca human_needed. Jeśli kontynuujesz bez walidacji, GSD zapisuje w STATE.md stan verification_deferred_human z poleceniem wznowienia verify-work i kończy tryb autonomiczny.
  • Decyzja typu „drzwi w jedną stronę”. Planista wstawia punkt kontrolny dla człowieka przed każdym zadaniem ocenionym jako one-way, na przykład migracją danych. /gsd-plan-phase --no-reversibility-gates go wyłącza; zostaw bramkę włączoną, bo pytanie rano kosztuje mniej niż nieodwracalna migracja, której nikt nie zatwierdził.

Zanim wyjdziesz, uruchom więc /gsd-discuss-phase dla faz, które mu przekazujesz. Instalacja: npx @opengsd/gsd-core@latest --claude --global (albo --codex, --cursor), przypięta do sprawdzonej przez ciebie wersji; pełny przebieg opisuje strona o GSD.

oh-my-claudecode i oh-my-codex

Dział zatytułowany „oh-my-claudecode i oh-my-codex”

Oba to harnessy wieloagentowe autorstwa Yeachana Heo, które dodają hooki, zespoły agentów i trwałe tryby.

/plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode
/plugin install oh-my-claudecode
/omc-setup

Ścieżka CLI to npm i -g oh-my-claude-sisyphus@latest, a potem omc setup. Doprecyzuj wymagania przez /deep-interview "tenant-scoped API keys", potem uruchom /autopilot "add tenant-scoped API keys with rotation" albo /ralph, który pracuje, dopóki praca nie zostanie zweryfikowana. Wpisz cancelomc w czacie (to wyzwalacz w prompcie, nie polecenie z ukośnikiem), żeby zatrzymać aktywne tryby OMC. Wersja 5.5.0 dodaje 64 skille, 19 agentów i 11 hooków.

Trzymaj się reguły z README: jeden główny mechanizm pętli na sesję. /goal i /ralph razem to dwa warunki stopu walczące o tę samą turę. Polecenia slash wymagają żywej sesji, więc README odradza poleganie na nich w CI.

Przeprowadź nocny build w sandboksie z wyrocznią testową

Dział zatytułowany „Przeprowadź nocny build w sandboksie z wyrocznią testową”

Sama pętla to łatwa część. O tym, czy nocny przebieg nadaje się do scalenia, decyduje warunek stopu, którego agent nie przesunie, maszyna, której nie uszkodzi, i przegląd dowodów zamiast linii: wyrocznia → sandbox → pętla z limitem → poranny przegląd.

  1. Napisz zadanie i wyrocznię, zanim powstanie jakikolwiek kod. Wyrocznia to jeden skrypt, który zwraca 0 tylko wtedy, gdy praca jest skończona, a agent nie może go edytować. Dla migracji na TypeScript:

    scripts/oracle.sh
    #!/usr/bin/env bash
    set -euo pipefail
    # 1. Nic nie zostało do migracji
    test -z "$(find src/legacy -name '*.js' -print -quit)"
    # 2. Typy i testy
    npx tsc --noEmit
    npm test -- --run

    Przykład zakłada Vitest; zastąp npm test -- --run poleceniem twojego runnera bez trybu watch (na przykład npx jest --ci). Uruchom go teraz i potwierdź, że kończy się błędem: wyrocznia, która przechodzi przed rozpoczęciem pracy, niczego nie dowodzi. Jeśli twoje testy przeszłyby na zaślepce, najpierw je popraw; zobacz siłę wyroczni testowej i kryteria akceptacji, których agent musi się trzymać.

  2. Zamroź to, czego agent nie może dotykać. Zacommituj PROMPT.md i wyrocznię na main przed uruchomieniem, żeby poranny diff względem main w kroku 5 zaczynał się od tego samego punktu; ten commit to BASE. Po każdej iteracji pętla porównuje chronione ścieżki (tests/, scripts/oracle.sh, package.json, package-lock.json, tsconfig.json, vitest.config.ts, .github/ i PROMPT.md) z BASE i zatrzymuje się, jeśli któraś się zmieniła. To łapie najczęstszy sposób, w jaki pętle oszukują: osłabienie testu, wykluczenie go w konfiguracji runnera albo poluzowanie kompilatora tak, by wyrocznia przeszła. loop.sh i jego log trzymaj poza drzewem roboczym repozytorium (na przykład /tmp/loop.sh), żeby nigdy nie trafiły do commitów agenta ani do zwracanego bundle. To higiena, nie ochrona: przy wyłączonych uprawnieniach agent działa jako ten sam użytkownik systemu co pętla i może przepisać oba pliki. Kontrola w sandboksie służy do wczesnego zatrzymania. Liczą się kontrole poza sandboksem w kroku 5: diff chronionych ścieżek, który tylko czyta obiekty gita, i wyrocznia w CI z czystego checkoutu, nigdy na twojej własnej maszynie.

  3. Uruchom jednorazowy sandbox z ograniczonym ruchem wychodzącym. Użyj harnessu E2B z przewodnika po sandboksach: wysyła repozytorium jako git bundle, dopuszcza ruch wychodzący tylko do API modelu i rejestru pakietów, nie trzyma tokena GitHuba i zwraca bundle z nowymi commitami. Żeby zamienić go w przebieg nocny, wyślij loop.sh do /tmp/ (harness i tak tam umieszcza swoje pliki, a domyślny użytkownik sandboksa ma prawo zapisu w /tmp), wywołaj go zamiast pojedynczego polecenia agenta i zwiększ timeoutMs. Pętla zapisuje log do /tmp/loop.log, poza repozytorium; pobierz go razem z bundle i traktuj zarówno log, jak i kod wyjścia pętli jako wskazówki, bo agent mógł je zmienić. E2B dokumentuje maksymalnie godzinę w planie Hobby i 24 godziny w Pro, więc nocny przebieg wymaga Pro albo lokalnego sandboksa z tego samego przewodnika.

  4. Uruchom pętlę z limitem, która sama sprawdza wyrocznię. Co iterację startuje agenta od nowa, ogranicza wydatek i liczbę iteracji i nigdy nie ufa temu, że agent sam ogłosi „gotowe”:

    /tmp/loop.sh (tylko w sandboksie, poza repozytorium)
    #!/usr/bin/env bash
    set -u
    BASE=$(git rev-parse HEAD); MAX=${MAX:-25}
    PROTECTED="tests scripts/oracle.sh package.json package-lock.json tsconfig.json vitest.config.ts .github PROMPT.md"
    for i in $(seq 1 "$MAX"); do
      echo "=== iteration $i $(date -u +%H:%M) ===" >> /tmp/loop.log
      claude -p --dangerously-skip-permissions --max-budget-usd 3 --output-format json < PROMPT.md >> /tmp/loop.log 2>&1
      if ! git diff --quiet "$BASE" -- $PROTECTED || [ -n "$(git status --porcelain -- $PROTECTED)" ]; then
        echo "STOP: protected files changed" >> /tmp/loop.log; exit 3
      fi
      grep -q '^BLOCKED:' MIGRATION.md 2>/dev/null && { echo "STOP: agent blocked" >> /tmp/loop.log; exit 4; }
      if bash scripts/oracle.sh >> /tmp/loop.log 2>&1; then echo "DONE at iteration $i" >> /tmp/loop.log; exit 0; fi
    done
    echo "STOP: iteration cap" >> /tmp/loop.log; exit 2

    --max-budget-usd ogranicza wydatek na API w jednym wywołaniu i działa tylko z --print (claude --help, 2.1.283). Przy MAX=25 i 3 USD na iterację wydatek nocy na API jest ograniczony do około 75 USD. --output-format json zapisuje w /tmp/loop.log pole total_cost_usd każdego wywołania. Przekaż ANTHROPIC_API_KEY do sandboksa z magazynu sekretów; to właśnie ten rachunek za API ogranicza --max-budget-usd.

    Kod wyjścia to pierwsza wskazówka, nie dowód, bo agent może edytować loop.sh: 0 gotowe, 2 osiągnięty limit, 3 ruszone chronione pliki, 4 agent prosi o pomoc.

  5. Przejrzyj poranną gałąź po dowodach. Ściągnij z sandboksa bundle i /tmp/loop.log (tutaj do /tmp/out.bundle i /tmp/loop.log). Pobierz bundle do gałęzi i obejrzyj ją bez uruchamiania: poniższe polecenia tylko czytają obiekty gita i nie wykonują żadnego kodu agenta. Jeśli diff chronionych ścieżek jest pusty, wypchnij gałąź i otwórz pull request, żeby CI, przegląd PR przez agenta i człowiek widzieli ją jak każdą inną zmianę.

    Okno terminala
    git fetch /tmp/out.bundle agent/ts-migration:agent/ts-migration  # tworzy gałąź, nie przełącza się na nią
    git diff --stat main...agent/ts-migration          # zakres: tylko src/ i MIGRATION.md?
    git diff main...agent/ts-migration -- tests scripts package.json package-lock.json tsconfig.json vitest.config.ts .github # musi być pusty
    git log --oneline main..agent/ts-migration | wc -l  # mniej więcej jeden commit na moduł
    git push origin agent/ts-migration                  # tylko jeśli diff powyżej jest pusty

    Wyrocznia, która się liczy, działa w CI na tym pull requeście, z czystego checkoutu agent/ts-migration, w jobie bez żadnych sekretów (permissions: contents: read, bez secrets.*). GitHub uruchamia plik workflow z gałęzi samego pull requesta, więc to twój workflow i twoja wyrocznia tylko dlatego, że diff chronionych ścieżek powyżej pokazał .github/ i scripts/ bez zmian od BASE. Nie uruchamiaj npm test ani wyroczni z tej gałęzi na swoim laptopie: jedno i drugie wykonuje kod napisany przez agenta, być może po prompt injection, tuż obok twoich kluczy SSH i tokenów. Jeśli chcesz mieć wynik przed CI, uruchom wyrocznię w świeżym, jednorazowym sandboksie bez żadnych poświadczeń.

Zatwierdzenie zostaje przy człowieku, a pull request przechodzi przez to samo CI i ten sam przegląd co praca człowieka. Dołącz pobrany loop.log, MIGRATION.md i wynik wyroczni z CI do pull requesta jako jego pakiet dowodów.

Jak udowodnić, że nocny przebieg wykonał zadanie?

Dział zatytułowany „Jak udowodnić, że nocny przebieg wykonał zadanie?”

Własne „gotowe” pętli to najsłabszy dowód, jaki masz. Ułóż warstwy kontroli, a za dowód uznawaj tylko te, które działają poza sandboksem:

KontrolaCo łapieKto ją uruchamia
Wyrocznia zawodzi przed przebiegiemWyrocznię, która niczego nie dowodziTy, przed startem
Diff chronionych plików po każdej iteracji, a potem na pobranej gałęziOsłabione lub usunięte testy, zmienioną wyrocznięloop.sh jako wczesny stop (agent może go edytować), potem ty, poza sandboksem
Wyrocznia uruchomiona przez pętlę, a potem przez CI na pull requeścieNieprawdziwe deklaracje „wszystkie testy przechodzą”loop.sh jako wskazówka, potem twoje CI, w jobie bez sekretów
Wyszukanie ucieczek z typów i pominiętych testówZielony wynik kupiony przez any albo .skipPrompt przeglądu powyżej albo reguła lintera
CI z czystego checkoutuWszystko, co działało tylko w sandboksieTwoje CI
Przegląd drugiego modeluBłędne zachowanie, którego nie pokrywają testyAgent przeglądający PR

Jeśli któraś z tych kontroli wymaga od ciebie czytania całego diffa, wyrocznia jest za słaba; lekarstwem jest lepszy test, nie dłuższy przegląd. Tę zmianę wyjaśnia strona dowody zamiast diffów.

Ile kosztuje nocna pętla?

Dział zatytułowany „Ile kosztuje nocna pętla?”

Koszt ma dwie części. Część stała to to, co wtyczka dokłada do każdej sesji, zmierzone przez claude plugin details na Claude Code 2.1.283 (ostatnia kolumna tabeli decyzyjnej); /goal nie dokłada nic. Zmierz własną:

Okno terminala
claude plugin install ralph-loop@claude-plugins-official
claude plugin details ralph-loop@claude-plugins-official

Część zależna od przebiegu rośnie z liczbą iteracji, a spośród tych narzędzi kwotę ogranicza tylko tryb print Claude Code. Przed startem ustaw trzy limity: liczbę iteracji, budżet na wywołanie (--max-budget-usd w trybie print Claude Code) i limit czasu sandboksa. /usage w twojej własnej sesji nie widzi przebiegu z sandboksa, więc rzeczywisty wydatek odczytaj z logu albo z konsoli dostawcy API (dla Codex tylko z konsoli):

Okno terminala
# Tylko przebiegi Claude Code: Codex nie zapisuje total_cost_usd
grep -o '"total_cost_usd":[0-9.]*' /tmp/loop.log | awk -F: '{s+=$2} END {print s}'

Zostań przy domyślnym modelu narzędzia i najpierw dostrój poziom wysiłku (effort); aktualne ustawienia domyślne podaje przegląd modeli.

Zasady zespołu dla pętli bez nadzoru

Dział zatytułowany „Zasady zespołu dla pętli bez nadzoru”

Tech lead może przyjąć tę listę jako politykę dla każdego przebiegu, którego nikt nie obserwuje:

  • Gdzie: jednorazowy sandbox z ruchem wychodzącym ograniczonym do API modelu i rejestrów pakietów; nigdy laptop ani runner z sekretami wdrożeniowymi.
  • Warunek stopu: zacommitowana wyrocznia, która zawodzi przed przebiegiem. Bez wyroczni nie ma przebiegu bez nadzoru.
  • Limity: iteracje, budżet na wywołanie i limit czasu sandboksa, zapisane w skrypcie przebiegu.
  • Chronione ścieżki: testy, wyrocznia, manifesty zależności, konfiguracja kompilatora i CI, sprawdzane przez skrypt przebiegu po każdej iteracji.
  • Wynik: gałąź i log, nigdy push do main ani wdrożenie.
  • Narzędzia: najpierw wbudowane /goal; pętle zewnętrzne przypięte do wersji i oceniane jak każda zależność.
  • Właściciel: jedna wskazana osoba zatwierdza wyrocznię przed przebiegiem i dowody po nim.

Co psuje się w pętlach autonomicznych i jak to naprawić?

Dział zatytułowany „Co psuje się w pętlach autonomicznych i jak to naprawić?”
ObjawPrzyczynaNaprawa
Rano pętla wciąż działa, a budżet użycia zniknąłBrak --max-iterations albo obietnica, której agent nigdy nie wypisuje/ralph-loop:cancel-ralph (wtyczka Claude Code), skill cancel-ralph (wtyczka Cursora), cancelomc wpisane w czacie (wyzwalacz OMC w prompcie, nie polecenie z ukośnikiem), /goal clear (Codex); następnym razem ustaw limit i budżet na wywołanie
Wyrocznia jest zielona, ale funkcja działa źleTesty osłabione, pominięte albo niezdolne do porażkiPrzywróć tests/ z BASE, wzmocnij wyrocznię, wznów od ostatniego dobrego commita
Agent wypisał <promise>DONE</promise> za wcześnieObietnica to dopasowanie ciągu, a nie kontrolaUruchamiaj wyrocznię w harnessie, nie w agencie; traktuj obietnicę jako wskazówkę
/ralph-loop:ralph-loop kończy się po jednej turzeHooki wyłączone (--bare, disableAllHooks) albo niezaufany katalogUruchom bez --bare, zaakceptuj okno zaufania, sprawdź, czy hook Stop jest na liście
Każda iteracja powtarza albo cofa poprzedniąJedna długa sesja zdryfowała albo brak pliku postępuUżyj pętli ze świeżym kontekstem i jednolinijkowej notatki postępu na iterację
Iteracje nie tworzą commitówHistoryjki za duże na jeden kontekstPodziel pracę; README snarktank wymaga, by każda historyjka mieściła się w jednym oknie kontekstu
O 2:00 pętla staje na limitachLimity API osiągnięte w trakcie przebieguLimit ralph --calls od frankbria albo mniej iteracji z mniejszymi historyjkami
Nocny przebieg GSD stanął w fazie 2 i czeka na odpowiedźNiejasność, blokada, weryfikacja human_needed albo punkt kontrolny „drzwi w jedną stronę”Odpowiedz albo uruchom polecenie verify-work zapisane w STATE.md; następnym razem przed wyjściem uruchom /gsd-discuss-phase

Dokąd dalej z pętlami autonomicznymi

Dział zatytułowany „Dokąd dalej z pętlami autonomicznymi”
Polecenie /goal Jak Claude Code, Codex i Cursor sprawdzają warunek stopu.
Sandboksy dla agentów: porównanie Użyty wyżej harness E2B oraz container-use i Docker Sandboxes do przebiegów lokalnych.
Siła wyroczni testowej Upewnij się, że testy zatrzymujące pętlę potrafią wykryć błędne zachowanie.
GSD Pełna pętla faz GSD Core, zanim oddasz mu pozostałe fazy.
Harnessy wieloagentowe Ruflo, wshobson/agents, Task Master i CCPM do pracy rozproszonej.
Frameworki pracy z agentami: porównanie Wszystkie frameworki w jednej tabeli, z ceremonią i kosztem kontekstu.

Autor:

Zobacz co nowego na platformie.

Polityka prywatności Regulamin Ustawienia cookie