Większość agentów AI chodzi jedną turą naraz. Ty piszesz, oni odpisują, oni czekają. Pętlę kręcisz ty. Agent jest tylko wywołaniem funkcji.
Hermes Agent ma ten tryb — to default. Ale niesie też inny tryb, /goal, w którym to agent kręci pętlę. Ustawiasz cel plus kryteria sukcesu, agent proponuje, wykonuje, ocenia, próbuje ponownie i nie odpuszcza, dopóki osobny LLM-sędzia nie zgodzi się, że kryteria są spełnione. v0.14.0 (16 maja 2026) dorzucił /subgoal, żebyś mógł dołożyć kolejne kryteria do żywej pętli w locie, bez restartu (#25449).
Ten wpis przechodzi przez to, co się tak naprawdę dzieje, kiedy to właściwe narzędzie i jakie tryby porażki czynią z niego narzędzie złe.
Tryb domyślny (dla kontrastu)
Każda sesja czatu w Hermesie to jedna tura na jedną wiadomość użytkownika. Agent czyta twoją wiadomość, opcjonalnie woła toole, oddaje odpowiedź. Jeśli zadanie nie jest skończone, musisz go popchnąć: „lec dalej", „spróbuj jeszcze raz", „a co z X". Zewnętrzną pętlę kręcisz ty.
To okej dla pracy zwiadowczej — „wyjaśnij ten kod", „napisz notkę", „znajdź mi buga". Chcesz, żeby agent przystawał po każdym kroku, żebyś mógł przekierować.
Nie jest okej dla zadań, gdzie warunek sukcesu jest konkretny, a droga do niego iteracyjna. „Refaktoruj ten moduł, dopóki pytest nie przejdzie" to trzydziestoturowe zadanie, jeśli sterujesz każdą turą z osobna. Z /goal to jedna komenda.
Co /goal faktycznie robi
/goal Make all tests in tests/api/ pass. Don't change the test assertions. Done when pytest exits 0.
Kiedy to wyślesz, dzieją się trzy rzeczy:
- 1.Tekst celu staje się prompt-em-celem dla workera. W każdej kolejnej turze worker-model dostaje system-message z celem i obecną najlepszą próbą.
- 2.Po każdej turze workera odpala się osobne wywołanie „sędziego"-LLM-a. Sędzia widzi cel, obecny stan i proponowaną wersję. Zwraca albo „done" (pętla wychodzi), albo „lec dalej, oto czego brakuje".
- 3.Pętla idzie, aż sędzia powie done — albo aż zatrzymasz ją
/stop, albo aż uderzysz w skonfigurowany limit iteracji.
Sędzia to kluczowy element. Nie jest tym samym wywołaniem LLM-a co worker i nie widzi łańcucha myśli — tylko cel i obecny stan. Ta separacja jest tym, co sprawia, że /goal działa: worker-model, który już sam siebie przekonał, że jego odpowiedź jest dobra, to fatalny sędzia. Świeże wywołanie LLM-a bez kontekstu jest dużo lepsze.
Ten wzorzec, wewnętrznie w codebase'ie Hermesa, nazywa się „Ralph loop", od kanonicznego pseudokodu while not done: do(work); ralph = judge(work). Rozszerzenie /subgoal z v0.14.0 daje użytkownikowi wstrzyknięcie nowych kryteriów sędziego do biegnącej pętli.
/subgoal — dorzucić kryteria w locie
Odpaliłeś /goal na refaktor modułu. Trzy iteracje wgłąb przypominasz sobie, że chciałbyś, żeby refaktor utrzymał też cyclomatic complexity poniżej 10 na funkcję. Nie chcesz zatrzymywać pętli i restartować.
/subgoal Each function must have cyclomatic complexity <= 10.
Następnym razem, kiedy odpali się sędzia, weźmie ten nowy warunek pod uwagę. Jeśli obecna najlepsza próba na nim nie przechodzi, pętla idzie dalej. Jeśli przechodzi, pętla wychodzi.
To rodzaj feature'a, który w bullecie z release notes wygląda mało — „kryteria dorzucone przez użytkownika do aktywnego /goal" — a okazuje się nośny dla każdego, kto naprawdę używa pętli. Realne cele uściślają się, kiedy patrzysz, jak agent pracuje. Bez /subgoal jedyna droga uściślenia to /stop + przedefiniować + znowu /goal — i tracisz stan w trakcie.
Praktyczne przykłady
Refaktor aż testy przejdą
/goal Refactor src/api/users.py so the User class follows the new naming convention in src/conventions.md. Don't break any existing tests. Done when:
1. pytest exits 0
2. The User class matches the convention rules in conventions.md
Worker próbuje refaktorów, sędzia sprawdza oba warunki. Kiedy oba są zielone, pętla wychodzi.
Iterowanie po UI
/goal Make the button on /pricing more prominent. Done when:
1. The button is the largest interactive element above the fold on desktop
2. It uses the primary brand color (#FF5A50)
3. Existing Lighthouse accessibility score doesn't drop
Worker zmienia CSS, sędzia robi screenshot przez tool browsera i sprawdza. Dużo iteracji bez tego, żebyś musiał stać nad agentem.
Znaleźć buga
/goal Find the cause of the intermittent test failure in tests/auth/test_session.py::test_logout_clears_cookie. Done when you produce a minimal failing repro and a one-paragraph explanation.
Sędzia sprawdza tu, czy obie części dostawy są — minimalne repro i wyjaśnienie — nie czy zlandowała jedna albo druga. /subgoal pozwala dorzucić warunek typu „wyjaśnienie musi powołać się na odpowiedni cykl request/response", jeśli pierwszy szkic jest zbyt mglisty.
Kiedy nie używać
/goal to złe narzędzie dla zadań, gdzie:
- •Warunek sukcesu jest mglisty. „Zrób to elegantszym" — sędzia nie potrafi tego stabilnie ocenić, więc pętla oscyluje albo przybija pieczątkę. Tu używaj tury po turze.
- •Chcesz widzieć pracę, jak się dzieje. Każda iteracja kończy się przed odpaleniem sędziego, więc nie dostajesz tej samej widoczności turę po turze. Używaj tury po turze albo
/handoff, jeśli liczy się przegląd w środku. - •Koszt ma większą wagę niż prędkość. Każda iteracja pętli to call workera plus call sędziego. Dla celu na 10 iteracji płacisz 20 wywołań LLM-a. Warto przy refaktorach; marnotrawstwo przy „jak nazwać tę zmienną".
- •Nie zastanowiłeś się nad kryteriami sukcesu. Śmieciowe kryteria → śmieciowa pętla.
/goalnagradza konkret, a agent wykorzysta każdą dwuznaczność.
Jak /goal współpracuje z /handoff
v0.14.0 wypuścił też /handoff, który przenosi żywą sesję między modelami bez utraty kontekstu (#23395). Te dwa składają się razem: możesz przenieść biegnące /goal z szybkiego modelu na deep-reasoningowy, kiedy cel uderzy w coś, czego szybki nie ogarnie. Sędzia dalej ocenia te same kryteria; worker po prostu zrobił się lepszy.
Tak samo z /sessions (#20805) — możesz przerwać cel, przeskoczyć do innej sesji i wrócić do niego później. Stan pętli jest checkpoint-owany.
Gdzie to siedzi w stacku agenta
Trzy różne kształty pracy autonomicznej, w rosnącej kolejności tego-jak-bardzo-agent-jedzie-sam:
- 1.Tura po turze — ty prowadzisz, agent odpowiada. Konwersacyjnie.
- 2.
/goal— ty ustawiasz kryteria, agent kręci, aż się spełnią. Autonomia z granicami. - 3.Cron-scheduling — agent chodzi bez nadzoru po harmonogramie, z dostawą na platformy komunikacyjne. Autonomia bez granic w czasie.
/goal to ten środkowy. To właściwy zasięg dla kategorii zadań, które wcześniej wymagały albo ciężkiego babysittingu, albo własnego skryptu. /subgoal z v0.14.0 robi pętlę sterowalną w locie, a to jest to, co przerabia ją z ciekawostki w codzienne narzędzie.