Jak działa unlazy i metoda Depth Tree w pracy agenta

Na czym polega działanie umiejętności unlazy

Umiejętność unlazy to narzędzie agenta stworzone w celu wyeliminowania jednego błędu: sytuacji, w której agent programistyczny zgłasza wykonanie zadania, zanim faktycznie zostanie ono ukończone. Jej podstawą jest Depth Tree, metoda dzieląca zadanie wzdłuż jego rzeczywistych granic i przypisująca każdemu elementowi końcowemu własne bramki akceptacji. Wersja 2 przeniosła egzekwowanie tych zasad z opisu tekstowego do plików, dzięki czemu agent musi udowodnić ukończenie pracy poprzez listę wykonywalnych poleceń, zamiast jedynie deklarować jej zakończenie.

Narzędzie jest publikowane przez Leonxlnx pod adresem github.com/Leonxlnx/unlazy na licencji MIT. Brak jest oznaczonego wydania, do którego można by się przypiąć: na dzień 2026-10-11 listy tagów i wydań w repozytorium są puste. Niniejszy przewodnik został pierwotnie opracowany w oparciu o kamień milowy kodu źródłowego 2.0.0 z dnia 2026-08-10. W dniu 2026-10-11 zweryfikowano go ponownie względem bieżącego kodu źródłowego w gałęzi main. Plik CHANGELOG oznacza to źródło jako "Unreleased, target 2.1.0" i informuje, że nie przypisano do niego tagu Git ani wydania GitHub dla wersji 2.1.0. Uruchomienie polecenia instalacji obecnie pobiera nowszą wersję kodu, a nie 2.0.0. Umiejętności w tym obszarze zmieniają się szybko, dlatego przed wdrożeniem tych rozwiązań w środowisku produkcyjnym należy zapoznać się z plikiem CHANGELOG repozytorium.

Umiejętność w tym kontekście oznacza standardowy plik SKILL.md, który mechanizm sterujący (harness) ładuje do kontekstu modelu, gdy zadanie pasuje do opisu umiejętności. Jeśli ten mechanizm jest nieznany, należy zacząć od lektury czym jest umiejętność agenta i jak mechanizm sterujący ją ładuje. unlazy to zwykły plik markdown oraz kilka skryptów Node, więc nie wymaga własnego serwera ani klucza API.

Dlaczego agenci zatrzymują się na 80 procentach i pomijają trzecią instrukcję

To zachowanie ma rozpoznawalny schemat. Użytkownik prosi o cztery rzeczy. Odpowiedź obejmuje pierwszą, drugą i czwartą. Podsumowanie końcowe wymienia wszystkie cztery jako wykonane. Żaden element nie wygenerował błędu, więc nic nie zostało oznaczone jako problematyczne, a brakujący fragment odkrywa się tydzień później.

Dokumentacja unlazy README opiera to zjawisko na opublikowanych badaniach nad lenistwem modeli. Cytuje ona arXiv 2512.20662, gdzie stwierdzono, że „szczegółowe, wieloczęściowe prompty nadal wykazują częściową zgodność i przedwczesne ucinanie treści w testowanych modelach”. Dokumentacja gates określa założenia projektowe wprost: „Powyższe reguły są prozą, a proza jest warstwą, którą ten projekt już traktuje jako najsłabszą”. Polecenie agentowi, aby bardziej się postarał, jest kolejną porcją prozy dodaną do tego samego kontekstu, który spowodował niedociągnięcia.

Dlatego wersja 2 przechowuje swój stan w plikach. Pole wyboru w GATES.md znajduje się poza zakresem uznaniowości modelu. Albo brama posiada pod sobą dowód, albo go nie posiada, a skrypt może to zweryfikować bez pytania agenta.

Drzewo głębokości, warstwa po warstwie

Drzewo głębokości to dekompozycja z regułą określającą, gdzie mogą występować podziały. Z dokumentacji metody:

Dziel tylko na granicach domen, komponentów lub weryfikacji. Podziały binarne są opcjonalne.

Warstwę 1 niech stanowi żądane zadanie.

Liście zawierają elementy dostarczalne. Każda warstwa powyżej integruje i weryfikuje to, co zwracają jej elementy podrzędne.

Liść jest większy niż punkt listy. Dokumentacja określa jego rozmiar poprzez wynik, a nie czas:

Niech każdy liść będzie spójnym elementem dostarczalnym.

Scalaj drobne, sąsiadujące liście; dziel liść, który ukrywa kilka niezależnych wyników.

Ta zasada zapobiega przekształceniu głębokiego drzewa w pozorowanie pracy. Jeśli liść brzmi "zmień nazwę zmiennej", nie przechodzi testu, a podział powyżej był o jedną warstwę za głęboki.

Każdy liść przechodzi następnie cztery przebiegi: pełna implementacja bez symboli zastępczych, ponowne odczytanie z perspektywy eksperta domenowego, poszukiwanie defektów, a następnie dopracowanie tam, gdzie jest to tanie, powtarzane aż do momentu, gdy pełny przebieg poprawkowy nie wykaże żadnych braków. Te przebiegi są drugim powodem, dla którego drobne liście są scalane. Cztery przebiegi nad dwuminutową zmianą to tylko teatr.

Głębokość wybiera się podczas wywoływania umiejętności:

/unlazy tree 5 refactor the payment module

Język naturalny również działa, ponieważ opis umiejętności dopasowuje się do intencji, a nie do komendy typu slash:

tree 3 build the landing page and do not stop until every gate is checked

Wcześniejsze wersje tego przewodnika podawały pasma głębokości z liczbą liści dla każdego poziomu. Obecna dokumentacja metody nie zawiera żadnych liczników liści i stanowi: "Nie traktuj głębokości jako arytmetycznej obietnicy dotyczącej wysiłku lub tokenów". Pozostały jedynie wytyczne jakościowe: "Użyj płytkiego drzewa lub pojedynczego rejestru dla funkcji, ograniczonego poszukiwania błędów lub dokumentu". Drzewo orkiestrowane służy do przypadków, w których kilka spójnych elementów dostarczalnych zyskuje na świeżych kontekstach lub niezależnej własności. Głębokie drzewo jest uzasadnione tylko wtedy, gdy jego dodatkowe gałęzie odpowiadają rzeczywistym granicom integracji.

Jeśli nie określisz głębokości, dokumentacja zaleca "wybór najmniejszego drzewa, które ujawnia każdy niezależny element dostarczalny i punkt integracji". Jeśli podasz liczbę, która nie pasuje do pracy, agent ma obowiązek to zgłosić zamiast tworzyć wypełniacze: "Jeśli żądana głębokość miałaby stworzyć puste liście, wskaż niedopasowanie i użyj najbliższej uczciwej dekompozycji". Głębokość opisuje pracę, więc zawyżanie tej liczby nie poprawia jakości.

Jak wygląda plik bramek

Przed rozpoczęciem jakichkolwiek prac agent zapisuje kryteria akceptacji w pliku bramek. Każda bramka to pole wyboru z przypisanym poleceniem.

# Gates: pricing section

- [ ] G1: three tiers render with real copy
  CHECK: node check.js pricing --tiers
  EXPECT: 3/3 tiers ok
  EVIDENCE: pending

- [ ] G2: annual toggle changes both price and label
  CHECK: node check.js pricing --toggle
  EXPECT: toggle ok
  EVIDENCE: pending

CHECK to polecenie. EXPECT to wynik uznawany za zaliczenie; zaliczenie wymaga również, aby polecenie zakończyło się kodem 0. EVIDENCE zaczyna się od pending. Po pomyślnym wykonaniu sprawdzający wypełnia bramkę odciskiem palca wyniku zamiast surowym wyjściem. Bramka ręczna nie posiada polecenia, dlatego w jej przypadku należy zarejestrować najmniejszy fakt potwierdzający wynik. Narzędzie dostarcza scripts/gate-check.mjs do tego celu. Za pomocą --status raportuje ono, które bramki pozostają otwarte, bez konieczności uruchamiania poleceń czy modyfikacji plików, co pozwala na audyt przebiegu bez czytania transkrypcji. Polecenia rejestru wykonywane są tylko po przekazaniu --approve, dlatego przed zatwierdzeniem należy przeczytać każde polecenie oraz każdy wywoływany przez nie skrypt. Osobne narzędzie scripts/gate-lint.mjs sprawdza jakość rejestru bez uruchamiania czegokolwiek.

Zasada raportowania w SKILL.md mieści się w jednej linii:

Nie twórz raportu o zakończeniu, dopóki jakakolwiek wymagana bramka jest niespełniona, porzucona, odroczona lub oczekuje na decyzję właściciela.

Równolegle agent otrzymuje polecenie: „ponownie zmierz każdą liczbę i potwierdzenie ukończenia bezpośrednio przed raportowaniem”. Bramka nie może zostać zamknięta tylko dlatego, że agent uważa pracę za zakończoną. Zamknięcie wymaga wykonania, którego wynik jest zgodny z EXPECT lub nie.

Twórz bramki, które mógłby uruchomić nieznajomy. „Wygląda dobrze” nie jest weryfikacją. test -s dist/index.html && echo ok drukujące ok jest weryfikacją, ponieważ kończy się wyraźnym błędem w przypadku pustego lub brakującego pliku.

Kontrakt PLAN.md przed pracą równoległą

Gdy drzewo zadań staje się na tyle rozbudowane, że liście działają w odrębnych kontekstach, przestają one współdzielić założenia. Referencja metody nakłada kontrakt przed rozgałęzieniem: „Napraw kontrakty przed rozgałęzieniem”. Plan wyszczególnia każdy wymagany rezultat w PLAN.md, „następnie zarejestruj interfejsy, formaty, wspólne założenia, konwencje błędów, nazewnictwo oraz własność, zanim liść rozpocznie pracę”.

Powód jest konkretny. Dwóm podagentom, którym polecono „dodać obsługę błędów”, wymyśli dwie różne struktury błędów, a oba liście przejdą własne bramki, ponieważ każdy z nich jest poprawny lokalnie. Awaria ujawnia się dopiero w punkcie styku. Ten punkt styku jest zadaniem warstwy nadrzędnej, a referencja orkiestracji precyzuje: „Zweryfikuj ponownie elementy podrzędne, następnie przeprowadź testy interfejsu, end-to-end oraz regresji”.

W trybie orkiestrowanym sterownik otrzymuje polecenie: „Przekaż każdemu liściowi tylko wspólny kontrakt, jego dokładną własność i zależności, jego własny rejestr” oraz „nie ujawniaj historii niepowiązanych liści”. Każdy rejestr liścia deklaruje ścieżki, do których może zapisywać, a te ścieżki OWNS nie mogą pokrywać się z żadnym innym liściem wysłanym w tym samym czasie. Gdy podagent kończy pracę, sterownik musi „ponownie uruchomić bramki wykonywalne zwróconego liścia, w tym bramki już sprawdzone”, ponieważ samo --status nie stanowi ponownej weryfikacji. Liść, którego pola zostały zaznaczone bez rzeczywistych dowodów, nie przetrwa tego ponownego uruchomienia.

Orkiestracja ma swój próg opłacalności. Referencja orkiestracji zaleca: „Pozostań w trybie solo, gdy jeden skoncentrowany kontekst może zaimplementować i zweryfikować zadanie bez ukrywania niezależnych wyników”. Każdy podagent musi odtworzyć swoje zrozumienie zadania od podstaw, więc przy małym zadaniu koszt tej konfiguracji przewyższa zysk z zaangażowania świeżej uwagi.

Jak zainstalować umiejętność unlazy?

Zalecaną ścieżką jest użycie CLI dla umiejętności:

npx skills add Leonxlnx/unlazy

Dodaj -g w celu instalacji na poziomie użytkownika lub --all dla każdego agenta wykrytego przez CLI. To polecenie instaluje wersję dostępną obecnie w gałęzi main. Brak jest oznaczonych wydań, dlatego plik README zaleca przypięcie konkretnego commita, jeśli wymagana jest instalacja, która nie zmieni się w czasie.

Instalacja ręczna polega na sklonowaniu repozytorium do katalogu umiejętności agenta:

git clone https://github.com/Leonxlnx/unlazy ~/.claude/skills/unlazy

git clone https://github.com/Leonxlnx/unlazy ~/.codex/skills/unlazy

Następnie należy sprawdzić, czy pliki zostały poprawnie umieszczone:

ls ~/.claude/skills/unlazy/SKILL.md

Wyświetlenie ścieżki oznacza, że plik znajduje się na dysku. No such file or directory oznacza, że klonowanie nastąpiło w inne miejsce, zazwyczaj dlatego, że katalog umiejętności nie istniał pod założoną nazwą i git utworzył nowy. Nie należy polegać wyłącznie na komunikacie agenta. Agent informujący o zainstalowaniu umiejętności nie potwierdza fizycznej obecności pliku. Moduł sprawdzający oraz opcjonalny hook wymagają środowiska Node 16 lub nowszego i nie korzystają z zewnętrznych pakietów uruchomieniowych.

Według stanu na 2026-10-11 plik README dokumentuje dwa środowiska uruchomieniowe: Claude Code, gdzie umiejętność wywołuje się za pomocą /unlazy, oraz Codex CLI, gdzie używa się $unlazy. Dokumentacja nie przewiduje ścieżki dla środowisk bez mechanizmu ładowania umiejętności, dlatego wklejanie zawartości SKILL.md do plików reguł innych narzędzi jest nietestowane. Aby dowiedzieć się, co zapewnia niezawodne ładowanie pliku SKILL.md, należy zapoznać się z sekcją tworzenie własnej umiejętności agenta, która opisuje frontmatter oraz dopasowywanie opisów decydujące o uruchomieniu umiejętności.

Czy Stop hook działa poza Claude Code?

Nie, i jest to kwestia wymagająca precyzji. Wszystko powyżej to instrukcje, a instrukcje mogą zostać zignorowane. Jedynym elementem wymuszania strukturalnego jest Stop hook, który stanowi funkcję Claude Code.

node <path-to-skill>/scripts/install-hooks.mjs            # this project only (settings.local.json)
node <path-to-skill>/scripts/install-hooks.mjs --global   # every project
node <path-to-skill>/scripts/install-hooks.mjs --uninstall

Stop hook uruchamia się w momencie, gdy agent próbuje zakończyć swoją turę. Skanuje on rejestr bieżącej sesji oraz stan dyspozycji i blokuje zatrzymanie, dopóki bramki nie zostaną spełnione, dzięki czemu tura nie może zakończyć się przy niezaznaczonym polu. Nie wykonuje on samych sprawdzeń ani nie wywołuje modelu. Nie jest to jednak darmowe. Dokumentacja ekonomii tokenów wskazuje, że „blokada powoduje kolejną kontynuację agenta, co zużywa pracę modelu”. Informacje o ogólnym mechanizmie oraz innych zdarzeniach, do których można się podpiąć, znajdują się w sposób wyzwalania hooków Claude Code wokół tury. README zaleca instalację hooka wyłącznie za zgodą użytkownika. Zaleca również zachowanie .claude/settings.local.json, .unlazy/ oraz .unlazy-hook-state.json w regułach ignorowania.

Posiada on zawór bezpieczeństwa, co jest ważniejsze, niż mogłoby się wydawać. Jeśli agent nie poczyni żadnych postępów w bramkach przez sześć kolejnych zablokowanych zatrzymań, hook zwalnia go zamiast więzić, a edycje dotyczące wyłącznie metadanych nie resetują tego licznika. Linia ABANDON: <gate> <reason> również pozwala na zakończenie sesji, ale jako widoczne przekazanie, a nie zaliczenie. Porzucona bramka jest raportowana jako wynik nieudany, a nie jako ukończona praca. Bez tych dwóch wyjść awaryjnych, bramka niemożliwa do przejścia w danym środowisku zużywałaby tokeny, dopóki sesja nie zostałaby przerwana ręcznie.

W przypadku Codex lub innego środowiska uruchomieniowego, install-hooks.mjs nie ma gdzie się zainstalować, ponieważ zapisuje jedynie pliki ustawień Claude. Użytkownik nadal otrzymuje plik bramek i sprawdzalne testy, jednak bez żadnych strukturalnych zabezpieczeń powstrzymujących model przed przedwczesnym zakończeniem tury. W takim przypadku plik bramek jest dokumentem, który należy przeczytać samodzielnie.

unlazy czy ponytail: co wybrać?

Te dwie umiejętności zyskały popularność w tym samym sezonie i wpływają na objętość kodu w przeciwnych kierunkach, co ułatwia ich pomylenie.

ponytail sprawia, że agent zachowuje się jak starszy programista, którego pierwszym pytaniem jest to, czy dany kod w ogóle musi istnieć. Ogranicza zakres, preferuje bibliotekę standardową i zmniejsza diff. unlazy zakłada, że zakres został już ustalony i zwiększa nakład pracy, dopóki każda część zadania nie zostanie ukończona i zweryfikowana.

Wybór zależy od rodzaju napotkanego problemu. Jeśli agent zamienia małą funkcjonalność w cały framework, należy wybrać umiejętność ponytail i jej personę leniwego starszego programisty. Jeśli agent pozostawia trzeci element czteroczęściowego żądania niedokończony, a następnie zgłasza sukces, należy wybrać unlazy.

Możliwe jest uruchomienie obu, przy czym kolejność ma znaczenie. Najpierw należy ustalić zakres za pomocą pytania ponytail, a następnie przekazać uzgodniony zakres do bramek unlazy. Odwrotna kolejność spowoduje zbudowanie drzewa zadań dla pracy, którą ponytail by usunął, co wiąże się z niepotrzebnym nakładem pracy. Ta kolejność jest moją rekomendacją, a nie udokumentowaną integracją między tymi dwoma projektami.

Jaki jest koszt głębokości (depth) w przypadku agenta hostowanego na VPS?

Wysiłek to tokeny, a na serwerze VPS, gdzie agent korzysta z własnego klucza API, tokeny oznaczają realne koszty. Projekt nie podaje już konkretnych wartości określających, o ile parametr unlazy zwiększa zużycie zasobów.

Wcześniejsze wersje tego przewodnika zawierały zestawienia mnożników tokenów wyjściowych i kosztów, oparte na sześciu przebiegach testowych. Autorzy wycofali te dane. Plik references/token-economy.md informuje obecnie, że surowe prompty, ślady (traces), wyniki i rekordy punktacji nie są dostępne w repozytorium, „dlatego liczby te nie są tutaj odtwarzalne”, dodając: „Nie należy traktować ich jako gwarancji produktu”. Dokumentacja metody idzie o krok dalej: „Nie należy traktować głębokości jako arytmetycznej obietnicy dotyczącej wysiłku lub liczby tokenów”. Usunięto te liczby, aby nie powielać danych, pod którymi sami autorzy już się nie podpisują.

Informacje o kosztach zawarte w dokumentacji mają charakter kierunkowy. Główna rekomendacja brzmi: „Przenieś powtarzalną, deterministyczną weryfikację do komend i ogranicz kontekst orkiestracji”. Tryb solo zużywa dodatkowe tokeny wyjściowe w ramach jednego kontekstu. Tryb orkiestrowany dodaje nowe konteksty, a każdy z nich przed wykonaniem jakiegokolwiek użytecznego zadania odczytuje kontrakt oraz własny rejestr. Dokumentacja ostrzega w obu przypadkach: „Nie należy orkiestrować zadania, które może zostać zaimplementowane i zweryfikowane w jednej, skoncentrowanej sesji”. Ostrzega również przed utrzymywaniem całego procesu budowania w jednym kontekście tylko po to, by uniknąć narzutu subagenta, gdy liście i kontrakty są jasne.

Z powyższego wynikają cztery ustawienia:

• Wybierz najmniejszą głębokość, przy której liście stanowią rzeczywiste jednostki pracy, a następnie zatrzymaj się. Niepotrzebna głębokość to niepotrzebny wydatek.
• Pozostań w trybie solo, gdy jedna skoncentrowana sesja wystarcza do zbudowania i zweryfikowania zadania, ponieważ koszt konfiguracji subagenta przewyższa zyski z nowego kontekstu.
• Zainstaluj hook Stop, jeśli korzystasz z Claude Code. Sam hook nie wykonuje wywołań modelu, ale każdy blok wysyła agenta z powrotem do pracy, a ta praca jest rozliczana.
• Ustaw twardy limit wydatków na poziomie konta przed rozpoczęciem jakichkolwiek długotrwałych zadań.

Ostatni punkt jest najbardziej istotny. Narzędzie zaprojektowane tak, aby odmawiać wczesnego zatrzymania, z założenia będzie kontynuować pracę. Budżetowanie i alerty to zadania oddzielne od tworzenia promptów, a utrzymywanie kosztów agenta pod kontrolą na VPS opisuje limity, które warto wdrożyć w pierwszej kolejności.

Co zmierzyli autorzy i co to udowadnia

Repozytorium publikowało niegdyś własny test, co zdarza się rzadziej, niż powinno. Od tego czasu wycofano się z tego testu, co zdarza się jeszcze rzadziej. W pliku README widnieje obecnie jedynie informacja, że „wcześniejsze wersje README przytaczały również wewnętrzne porównanie z sześciu przebiegów” oraz że „surowe artefakty potrzebne do odtworzenia tych dokładnych proporcji i liczebności nie znajdują się w tym repozytorium”. Zalecenie brzmi: „Traktuj wyniki jako historyczne dane projektowe, a nie jako gwarancję wyników testów wydajnościowych”.

Konfiguracja przetrwała w pliku research/validation-protocol.md: dwa zadania budowania, trzy warunki dla każdego (brak umiejętności, drzewo 3, drzewo 6) oraz jeden świeży folder i sesja na każdy przebieg. Protokół określa to jako „eksploracyjne porównanie przeprowadzone przez opiekuna”. Stwierdza, że proporcje tokenów, liczba samodzielnie wykrytych defektów, awarie w czasie rzeczywistym oraz błędy w numeracji raportów nie mogą zostać odtworzone ani zweryfikowane na podstawie repozytorium. Dokument zaznacza również, że porównania tego nie należy opisywać jako dowodu na to, że unlazy powoduje konkretną poprawę lub mnożnik kosztów. Wcześniejsze wersje tego przewodnika przedstawiały liczby z poszczególnych przebiegów tego testu. W związku z wycofaniem się autorów, usunęliśmy je.

Jedna lekcja projektowa przetrwała liczby. Zasada, aby „mierzyć każdą liczbę i deklarację ukończenia bezpośrednio przed raportowaniem”, nadal znajduje się w SKILL.md, a szablon gates ostrzega przed kopiowaniem dostarczonej liczby do EXPECT jako własnego dowodu. Pewne podsumowanie znajdujące się na szczycie uszkodzonej kompilacji jest dokładnie tym, przeciwko czemu skierowane są bramki (gates).

Teraz ograniczenia. Na dzień 2026-10-11 nie pozostał żaden opublikowany wynik, który można by ocenić, a jedynie metoda i protokół poprawnego ponownego przeprowadzenia testu. Należy przetestować to na własnej pracy: wykonać to samo zadanie dwukrotnie, raz w wersji standardowej, a raz z plikiem gates, a następnie policzyć bramki, które zamknęły się z dowodami możliwymi do samodzielnego odtworzenia. Ta liczba jest jedyną w tym obszarze, która należy do użytkownika.

FAQ

Czym jest Depth Tree w umiejętności unlazy?

Jest to metoda dekompozycji. Zadanie jest dzielone wyłącznie na granicach domeny, komponentu lub weryfikacji. Warstwa 1 to zadanie główne, a każdy liść stanowi spójny element dostarczalny z własnymi bramkami. Małe, sąsiadujące liście są scalane, a liść ukrywający kilka niezależnych wyników jest ponownie dzielony. Każda warstwa powyżej liści integruje i weryfikuje: sprawdza ponownie elementy podrzędne, a następnie uruchamia testy interfejsów, testy end-to-end oraz regresyjne. Głębokość wybiera się podczas wywołania, na przykład tree 5. Jeśli głębokość nie zostanie określona, umiejętność wybiera najmniejsze drzewo, które ujawnia każdy niezależny element dostarczalny oraz punkt integracji.

Czy umiejętność unlazy działa poza Claude Code?

Częściowo. Umiejętność jest zapisana w formacie markdown, a plik README dokumentuje Codex CLI obok Claude Code, więc Depth Tree, plik bramek, testy uruchomieniowe oraz cztery przebiegi na liść działają w tym środowisku. Obecna dokumentacja nie obejmuje innych narzędzi. Wymuszanie jest realizowane inaczej. Mechanizm Stop hook, który blokuje zakończenie tury, gdy bramki nie są spełnione, jest funkcją Claude Code, instalowaną za pomocą node <path-to-skill>/scripts/install-hooks.mjs. W każdym innym środowisku nic nie powstrzymuje modelu przed przedwczesnym zakończeniem tury, więc to użytkownik musi odczytać plik bramek i odesłać go z powrotem.

O ile umiejętność unlazy zwiększa koszty tokenów?

Obecnie nikt nie jest w stanie podać wiarygodnej kwoty. Wcześniejsze wskaźniki tokenów autorów pochodziły z sześciu prób, których nie da się odtworzyć. Obecna dokumentacja zaleca, aby nie traktować ich jako gwarancji produktu ani nie postrzegać głębokości jako arytmetycznej obietnicy dotyczącej nakładu pracy lub liczby tokenów. Kierunek pozostaje jednak jasny. Tryb solo dodaje dane wyjściowe w ramach jednego kontekstu. Tryb orkiestrowany dodaje nowy kontekst dla każdego liścia, który przed rozpoczęciem pracy odczytuje kontrakt oraz rejestr. Mechanizm Stop hook nie wykonuje własnych wywołań modelu, ale każdy blok zmusza agenta do powrotu do pracy. Należy dokonać pomiaru na własnym zadaniu i w ramach własnego rozliczenia.

Czy powinienem użyć unlazy czy ponytail?

Dopasuj umiejętność do napotkanego problemu. ponytail jest przeznaczone dla agenta, który pisze zbyt wiele, ponieważ wciela się w rolę starszego programisty, który sprawdza, czy kod w ogóle musi istnieć i w pierwszej kolejności sięga po bibliotekę standardową. unlazy jest przeznaczone dla agenta, który kończy zbyt mało z tego, o co poproszono, ponieważ wymusza dekompozycję i odmawia zamknięcia bramki bez dowodów. Jeśli chcesz użyć obu, najpierw ustal zakres za pomocą ponytail, a następnie przekaż ten zakres do unlazy, aby nie płacić za mnożnik wysiłku przy pracy, która powinna zostać usunięta.

Dlaczego mój agent nadal kończy pracę przedwcześnie po zainstalowaniu unlazy?

Sprawdź cztery kwestie. Po pierwsze, potwierdź, że umiejętność znajduje się na dysku dzięki ls ~/.claude/skills/unlazy/SKILL.md, ponieważ sklonowanie do nieistniejącego katalogu jest częstym błędem. Po drugie, potwierdź, że plik bramek został zapisany przed rozpoczęciem pracy, ponieważ mechanizm hook skanuje rejestr sesji, a brak GATES.md uniemożliwia blokowanie. Po trzecie, sprawdź, gdzie zainstalowano hook: zwykłe uruchomienie install-hooks.mjs zapisuje dane tylko w settings.local.json bieżącego projektu, więc inny projekt wymaga --global. Po czwarte, pamiętaj, że zawór bezpieczeństwa działa zgodnie z projektem. Sześć kolejnych zablokowanych zatrzymań bez postępu w bramkach zwalnia agenta, a linia ABANDON: <gate> <reason> celowo kończy próbę jako widoczne przekazanie, które nie jest sukcesem.