Agenci długiego horyzontu | Biblioteka

Krótka definicja: Agent długiego horyzontu to proces agentowy, który samodzielnie przechodzi przez wiele kroków, zmian kontekstu, a czasem także restartów, dopóki nie osiągnie weryfikowalnego celu albo warunku zatrzymania. „Długi” nie oznacza jedynie wysokiego timeoutu. Taki proces potrzebuje trwałego stanu, budżetów, checkpointów i bezpiecznego wznawiania.

Czym jest, a czym nie jest

Agent czatowy zwykle reaguje na jedno polecenie, wykonuje kilka wywołań narzędzi i zwraca wynik. Agent długiego horyzontu dostaje cel i realizuje dziesiątki lub setki kroków przez wiele godzin albo dni. Może analizować repozytorium, edytować pliki, uruchamiać testy, porównywać wyniki, zmieniać plan oraz czekać na system zewnętrzny lub człowieka.

Granicy nie wyznacza praca w tle. Agent asynchroniczny jedynie oddziela zlecenie od dostarczenia wyniku: zadanie trafia do kolejki, a odpowiedź przychodzi później. W środku może wykonać tylko jeden krok inferencji. Workflow ma przebieg w większości zapisany w kodzie: pobierz dane, sklasyfikuj je, przygotuj szkic, poproś o akceptację. Agent długiego horyzontu wybiera kolejny krok na podstawie bieżącego stanu i potrafi zmienić trasę, gdy rzeczywistość odbiega od planu. Najlepsza konstrukcja produkcyjna często łączy oba podejścia: deterministyczny workflow kontroluje etapy i uprawnienia, a agent podejmuje ograniczone decyzje wewnątrz wybranych etapów.

Nie jest to model pozostawiony w nieskończonej pętli. Model stanowi wymienny komponent decyzyjny. Przetrwanie zadania zapewnia harness, czyli aplikacja wokół modelu, która posiada stan, narzędzia, kolejkę zdarzeń, budżety, logi i reguły kontynuacji.

Architektura: cel, stan i checkpoint

Niezawodny przebieg rozdziela trzy warstwy:

Cel i kontrakt ukończenia. Zlecenie określa nie tylko rezultat, lecz także elementy, których nie wolno zmieniać, oraz dowód sukcesu. Przy zmianie kodu mogą to być dozwolone pliki, zaliczone testy, czysty lint, brak wycieku sekretów i diff ograniczony do uzgodnionego zakresu.
Trwały stan zadania. Aktualny plan, ukończone kroki, artefakty, wyniki kontroli, otwarte pytania, zużyty budżet i rejestr działań narzędzi istnieją poza kontekstem modelu. Okno kontekstowe jest stołem roboczym, nie bazą danych.
Checkpoint. Spójny zapis, od którego można kontynuować bez zgadywania. Zawiera wersję zlecenia, stan planu, odnośniki lub hashe artefaktów, ostatnie potwierdzone wyniki, oczekujące zgody i tożsamość środowiska. „Model pamięta, gdzie skończył” nie jest checkpointem.

Przydatna maszyna stanów ma jawne tryby, takie jak planned, executing, verifying, awaiting_approval, blocked, completed i failed. Przejścia wykonuje harness, a nie swobodna deklaracja modelu. Każda akcja zewnętrzna dostaje klucz idempotencji lub równoważne zabezpieczenie przed duplikacją. Po awarii można wtedy ponowić bezpieczne zapytanie, zamiast wykonać drugi przelew albo wysłać drugi e-mail.

Agentic drift bez mitologii

Agentic drift to użyteczna nazwa operacyjna stopniowego odchodzenia od pierwotnego celu, ograniczeń lub miary sukcesu. Nie jest jedną precyzyjnie ustandaryzowaną diagnozą i nie wymaga opowieści o samowolnej maszynie. Najczęściej wynika ze zwykłego połączenia kompresji kontekstu, lokalnej optymalizacji i źle zaprojektowanego sprzężenia zwrotnego.

Agent trafia na uszkodzoną zależność. Jej naprawa staje się problemem bezpośrednim, więc agent zaczyna przepisywać bibliotekę, choć właściwe zadanie wymagało zmiany trzech linii w aplikacji. Innym razem metryka zastępuje cel: agent maksymalizuje liczbę zaliczonych testów, osłabiając test, ponieważ to łatwiejsze niż naprawa produktu.

Rozwiązaniem nie jest dłuższy prompt. Przed każdym etapem harness powinien ponownie wczytać niezmienny kontrakt, porównać plan z dozwolonym zakresem, ograniczyć działania uprawnieniami i zadać pytanie możliwe do sprawdzenia maszynowo: czy ostatnia akcja przybliżyła zadanie do zadeklarowanego stanu ukończenia? Checkpointy powinny zapisywać także odrzucone ścieżki, aby agent po restarcie nie płacił ponownie za ich odkrycie.

Budżety i warunki zatrzymania

Długi przebieg wymaga kilku budżetów jednocześnie:

maksymalnego kosztu lub liczby tokenów,
czasu kalendarzowego i aktywnego czasu obliczeń,
liczby kroków, wywołań narzędzi i powtórzeń tego samego błędu,
limitu zapisów, żądań sieciowych i równoległych workerów,
maksymalnego rozmiaru diffu lub liczby zmienionych obiektów,
budżetu uwagi człowieka, czyli liczby dopuszczalnych eskalacji.

Limity powinny być twarde i widoczne w stanie zadania. „Pracuj aż skończysz” nie jest warunkiem zatrzymania. Przebieg kończy się sukcesem dopiero po spełnieniu kontraktu weryfikacyjnego. Bezpiecznie przechodzi w pauzę, gdy czeka na zgodę. Kończy się jako blocked lub failed, kiedy wyczerpie budżet, powtarza tę samą awarię, utraci dostęp do niezbędnego systemu albo odkryje sprzeczne wymagania. Ciche zwiększanie budżetu zamienia błąd projektu w rachunek za inferencję.

Wznawianie jest funkcją produktu

Resumability nie polega na ponownym wysłaniu całego transkryptu. Po restarcie orkiestrator odnajduje ostatni potwierdzony checkpoint, sprawdza, czy środowisko się nie zmieniło, i planuje wyłącznie brakującą pracę. Każdy krok powinien mieć wejścia, wyjścia oraz stan not_started, in_progress, verified lub invalidated.

Artefakty trafiają do wersjonowanego magazynu. Zdarzenia do logu typu append-only. Sekrety do menedżera sekretów, nie do checkpointu. Następny prompt powstaje z kontraktu, bieżącego stanu i istotnych dowodów. Jeżeli człowiek zmienił w międzyczasie branch, schemat bazy lub priorytet celu, stary checkpoint trzeba unieważnić albo świadomie zmigrować. Wznowienie bez kontroli środowiska tworzy pewną siebie pracę nad wczorajszą rzeczywistością.

Weryfikacja i zgoda człowieka

W długich zadaniach weryfikacja nie jest ostatnią bramką. Jest nawigacją. Po małej zmianie agent uruchamia tani test lokalny, po etapie test integracyjny, a przed ukończeniem pełną akceptację. W kodzie oznacza to testy, lint, kontrolę typów, skan bezpieczeństwa, przegląd diffu oraz, gdy trzeba, zrzut ekranu lub uruchomienie aplikacji. W zadaniu danych oznacza kontrolę schematu, liczby wierszy, invariantów, próbek i odtwarzalnego raportu.

Weryfikator powinien być możliwie niezależny od autora. Jeśli ten sam model tworzy zmianę, a potem jedynie stwierdza, że jest poprawna, otrzymujemy słaby dowód. Lepsze są deterministyczne testy, osobny etap review, porównanie z wynikiem referencyjnym i zachowane artefakty kontroli.

Człowiek nie powinien zatwierdzać każdego kliknięcia. Bramki zgody należy umieszczać przed działaniami nieodwracalnymi albo istotnymi społecznie: wdrożeniem produkcyjnym, wysłaniem wiadomości, płatnością, usunięciem danych, rozszerzeniem uprawnień lub publikacją. Prośba o zgodę powinna pokazywać zamiar, dokładny diff lub payload, wyniki kontroli, ryzyka i plan rollbacku. Przycisk „Approve” bez tego kontekstu przenosi odpowiedzialność, zamiast zapewniać kontrolę.

Projektowanie ewaluacji długich zadań

Jednorazowy pass rate nie wystarcza. Zestaw ewaluacyjny powinien zawierać realistyczne zadania w czystych środowiskach, ukryte testy akceptacyjne i awarie spotykane w produkcji: timeout narzędzia, restart workera, zmianę zależności, niejasne wymaganie lub oczekującą zgodę.

Mierzcie co najmniej:

odsetek zadań, które osiągnęły rzeczywisty stan docelowy,
czas i koszt dojścia do zweryfikowanego wyniku, nie do pierwszego szkicu,
liczbę kroków, powtarzanych błędów i interwencji człowieka,
naruszenia zakresu i niebezpieczne próby, także te zablokowane,
skuteczność wznowienia z checkpointu,
jakość dowodów oraz poprawność decyzji o zatrzymaniu.

Wyniki należy dzielić według długości i typu zadania. METR używa pojęcia „task-completion time horizon”: bada, jak długie zadania, mierzone czasem potrzebnym wykwalifikowanemu człowiekowi, agent potrafi rozwiązać przy określonym poziomie niezawodności. To mówi więcej niż stwierdzenie, że agent „pracuje cały dzień”. Długi runtime może oznaczać wytrwałość, ale również powolną pętlę. Ewaluacja ma mierzyć ukończenie, nie aktywność.

Incydent i powrót do bezpiecznego stanu

Gdy przebieg wymyka się spod kontroli, pierwszą reakcją nie powinien być kolejny prompt. Orkiestrator zatrzymuje nową pracę, unieważnia ryzykowne poświadczenia, zachowuje logi i wskazuje ostatni znany dobry checkpoint. Następnie oddziela artefakty wewnętrzne od skutków zewnętrznych: commit można cofnąć, dostarczonego e-maila nie. Każde narzędzie potrzebuje więc klasy odwracalności i, jeśli to możliwe, akcji kompensacyjnej.

Praktyczna sekwencja recovery wygląda tak: zamrozić przebieg, zebrać timeline, porównać rzeczywiste zmiany z dozwolonym zakresem, odtworzyć lub skompensować stan zewnętrzny, naprawić źródłową przyczynę w harnessie albo ewaluacjach, a dopiero potem kontynuować od nowego checkpointu. Incydent bez testu regresyjnego prawdopodobnie wróci.

Praktyczny blueprint wdrożenia

Zapisz kontrakt zadania: cel, non-goals, dozwolone systemy, polecenia weryfikacyjne i warunki zatrzymania.
Podziel proces na deterministyczne etapy. Decyzje agentowe dopuść tylko tam, gdzie trasy nie da się z góry zapisać.
Przechowuj stan w bazie, a artefakty w wersjonowanym magazynie. Każde wywołanie narzędzia rejestruj jako zdarzenie.
Stosuj krótkie, idempotentne kroki i twórz checkpoint po każdym zweryfikowanym kamieniu milowym.
Egzekwuj budżety i wykrywanie pętli. Trzy kopie tego samego błędu nie są trzema nowymi próbami.
Dodaj weryfikatory od najtańszych do najdroższych. Wynik bez dowodu nie otrzymuje stanu completed.
Oddziel bramki zgody od zwykłego sterowania. Oczekiwanie jest trwałym stanem, nie procesem zablokowanym w pamięci.
Przetestuj restart, podwójne dostarczenie zdarzenia, zmianę środowiska i rollback przed pierwszym wielogodzinnym przebiegiem produkcyjnym.
Zacznij w sandboxie z narzędziami read-only. Rozszerzaj uprawnienia na podstawie danych z ewaluacji i incydentów, nie najlepszego dema.

Najczęstsze błędy

Background job przedstawiany jako agent długiego horyzontu: asynchroniczność sama nie zapewnia adaptacyjnego planowania ani wznawiania.
Transkrypt jako jedyny stan: kompresja lub restart usuwa decyzje, budżety i tożsamość artefaktów.
Checkpoint po każdym tokenie: kosztowny szum. Zapisuj spójne, zweryfikowane kamienie milowe.
Jedna globalna definicja ukończenia: lokalne błędy wychodzą za późno. Weryfikuj każdy etap.
Wyłącznie budżet dolarowy: agent nadal może wyczerpać limity API, uwagę człowieka lub dozwolony zakres zmian.
Approval fatigue: człowiek zatwierdza mechanicznie i bez kontekstu. Pytaj rzadziej, ale dostarczaj dowody.
Wznowienie bez idempotencji: restart powiela skutek zewnętrzny.
Ocena według aktywności: długi log nie oznacza ukończonego zadania.
Traktowanie driftu wyłącznie jako problemu promptu: zakres muszą egzekwować narzędzia, uprawnienia i weryfikatory.

Co zapamiętać

Agent długiego horyzontu nie jest inteligentniejszym chatbotem z większym timeoutem. To trwały system stanowy, w którym model proponuje kolejną akcję, lecz harness posiada cel, historię, budżet i prawo zatrzymania. Zacznij od workflow i dodawaj decyzje agentowe tylko tam, gdzie przynoszą wartość. Trzymaj stan poza modelem, zapisuj zweryfikowane kamienie milowe, projektuj działania zewnętrzne z myślą o bezpiecznym powtarzaniu i mierz czas do udowodnionego wyniku. Autonomia może rosnąć tylko tak szybko, jak zdolność weryfikacji i odzyskiwania.

Źródła

Building effective agents (Anthropic) - praktyczne rozróżnienie workflow i agentów, wzorce orkiestracji oraz argument za najprostszą działającą konstrukcją.
Measuring AI Ability to Complete Long Tasks (METR) - metodologia task-completion time horizon wraz z ważnym wyjaśnieniem, czego ta metryka dowodzi, a czego nie.
12-Factor Agents (HumanLayer) - zasady produkcyjne dotyczące kontroli kontekstu, stanu poza modelem, małych kroków i sterowania przepływem.
Codex cloud (dokumentacja OpenAI) - pierwotna dokumentacja izolowanych zadań chmurowych, środowisk i pracy agentów programistycznych w tle.
Workflow execution (dokumentacja Temporal) - praktyczny model referencyjny durable execution, historii zdarzeń, ponawiania i odzyskiwania procesów.