Runtime długotrwałych agentów AI: sesje i checkpointy

Viacheslav Dubrov

2026-05-26 · Zaktualizowano 2026-09-06 · 40 min · Agenci AI

Tłumaczenie automatyczne Ten artykuł został automatycznie przetłumaczony z angielskiego oryginału.

Aktualizacja artykułu

Pierwotnie opublikowano 26 maja 2026 r. Artykuł sprawdzono i zaktualizowano 6 września 2026 r. Aktualizacja obejmuje nowsze możliwości runtime’u i opcje wdrażania, a także poprawione porównania platform, mechanizmy kontroli budżetu oraz linki do źródeł.

Uruchomienie agenta może trwać wiele godzin, ale jego proces roboczy może w dowolnej chwili zostać uruchomiony ponownie. Runtime przechowuje stan uruchomienia, wykonuje narzędzia i odzyskuje działanie, jeśli wywołanie narzędzia zatrzyma się w połowie. Model nadal wybiera kolejne działanie. Część 6 opisuje harness: kod, który dostarcza kontekst, sprawdza wywołania narzędzi i decyduje, czy praca została zakończona.

Czym jest runtime agenta AI?

Runtime agenta AI to infrastruktura, która utrzymuje agenta korzystającego z narzędzi po zakończeniu pojedynczego wywołania modelu. Przechowuje stan sesji, uruchamia narzędzia, zapisuje checkpointy, obsługuje sekrety, tworzy trace’y, egzekwuje limity kosztów i definiuje sposób wdrażania usługi. Model wybiera kolejne działanie. Runtime decyduje, gdzie to działanie zostanie wykonane, zapisuje wynik i odtwarza uruchomienie po awarii. Harness decyduje, czy dane działanie jest dozwolone. Nie jest on magazynem, ale tabela uwzględnia go, ponieważ runtime musi uruchomić go w określonym miejscu.

Cztery z pięciu prymitywów przechowują stan albo ograniczają możliwości kodu: sesja, sandbox, checkpoint i trace. Harness podejmuje decyzje dotyczące pamięci, kontraktów narzędzi i uprawnień. Ten artykuł opisuje usługi i magazyny, których potrzebuje. Część 6 omawia jego mechanizmy sprawdzania, ponawiania oraz testy akceptacyjne.

Długie uruchomienia łamią założenia dotyczące procesów bezstanowych

Bezstanowy endpoint czatu może przechowywać stan żądania w jednym procesie i odrzucić go po zwróceniu odpowiedzi. Długie uruchomienie agenta obejmuje restarty workerów, wdrożenia, resetowanie kontekstu i pauzy na zatwierdzenie. Proces workera nie może już być źródłem prawdy.

Zespół OpenAI Codex opisuje długość tych uruchomień w swoim tekście o projektowaniu harnessu:

„Regularnie obserwujemy, że pojedyncze uruchomienia Codex pracują nad jednym zadaniem przez ponad sześć godzin (często wtedy, gdy ludzie śpią).”

Zespół inżynieryjny Anthropic opisuje odpowiadający temu problem stanu w Effective harnesses for long-running agents:

„Główne wyzwanie związane z długotrwałymi agentami polega na tym, że muszą pracować w oddzielnych sesjach, a każda nowa sesja zaczyna się bez pamięci o tym, co wydarzyło się wcześniej.”

Obserwacje te prowadzą do tego samego projektu runtime’u: stan należy utrwalać poza workerem, a workery muszą być wymienialne.

Sesja musi znajdować się poza procesem workera. Trwały magazyn rejestruje wywołania modelu, intencje i wyniki wywołań narzędzi oraz zatwierdzenia, aby po awarii inny worker mógł wznowić działanie od ostatniego bezpiecznego punktu. Przed takim wznowieniem oczekujące działanie zewnętrzne wymaga uzgodnienia, aby można było uznać wznowienie za bezpieczne. Checkpointy pozwalają również runtime’owi uruchomić świeżą sesję modelu po zapełnieniu okna kontekstowego, bez odtwarzania całej historii. W sformułowaniu Anthropic instancje harnessu stają się jednorazowe i możliwe do ponownego uruchomienia, a trwały stan znajduje się gdzie indziej.

Pięć prymitywów, które trzeba rozmieścić przed wdrożeniem

Materiał Anthropic Scaling Managed Agents dostarcza użytecznego słownika pięciu odpowiedzialności runtime’u. Harness posuwa agenta do przodu, sesja rejestruje jego działania, a sandbox wykonuje polecenia. Checkpoint daje kolejnemu workerowi punkt wznowienia, a trace zachowuje dane potrzebne do późniejszego debugowania. Implementacja może łączyć komponenty, ale odpowiedzialności i granice awarii nadal muszą mieć jasno określone nazwy.

Sesja. Zapisywany osobno dziennik zdarzeń append-only obejmujący wywołania modelu, żądane i zakończone wywołania narzędzi, błędy oraz zatwierdzenia. Baza checkpointów pomaga w odzyskiwaniu działania, ale historia stanu grafu nie zastępuje tego dziennika.

Termin ten jest przeciążony znaczeniowo, dlatego w artykule stosuję schemat nazewnictwa na poziomie aplikacji dla trzech zakresów. Wątek to konwersacja użytkownika prowadzona przez wiele dni. Jest to zakres o najdłuższym czasie życia i może zawierać wiele uruchomień.

Sesja modelu jest najkrótsza: to jeden ciągły odcinek kontekstu modelu. Kompakcja — krok polegający na podsumowaniu okna, aby praca mogła być kontynuowana — wydłuża sesję modelu, zamiast ją kończyć. Restart lub celowy nowy start kończy sesję. W części 6 określenie „sesja modelu” jest używane właśnie w tym znaczeniu.

W tym artykule „sesja” oznacza trwały dziennik jednego uruchomienia. Wiele sesji modelu może zapisywać do jednego dziennika, a jeden wątek konwersacji może zawierać wiele dzienników uruchomień. Aby odzyskać działanie, wybudź uruchomienie, wczytaj jego sesję, uzgodnij oczekujące działanie zewnętrzne, a następnie wznów po ostatnim zdarzeniu: wake(sessionId) → getSession(id) → reconcile pending effects → resume from last event.

W LangGraph thread_id jest kluczem magazynowania i pobierania checkpointera dla historii stanu grafu wątku (zob. LangGraph persistence); nie definiuje on granic konwersacji, sesji modelu ani dziennika zdarzeń z tego artykułu. Nadaj dziennikowi zdarzeń własny trwały identyfikator uruchomienia lub sesji, a następnie jawnie określ sposób mapowania tych identyfikatorów na wątki LangGraph. OpenAI Agents SDK dostarcza dziesięć wbudowanych backendów sesji, w tym SQLiteSession, RedisSession, SQLAlchemySession, MongoDBSession i EncryptedSession (zob. dokumentację Sessions). Przechowują one zmienną historię konwersacji, w tym jej usuwanie, czyszczenie i kompakcję; w razie potrzeby mapuj identyfikator sesji SDK na identyfikator zdarzeń uruchomienia, ale nie traktuj historii SDK jako dziennika odzyskiwania lub audytu append-only bez równoważnej gwarancji niezmienności.

Harness. Pętla orkiestracji i jedyny prymityw w tym zestawieniu, który podejmuje decyzje. Składa prompt z pamięci, wywołuje model, sprawdza proponowane wywołanie narzędzia względem reguł uprawnień, wykonuje dozwolone działania, zapisuje wyniki z powrotem w sesji, stosuje reguły ponawiania i decyduje, czy zadanie zostało zakończone. Mechanizmy planowania i zarządzania kontekstem kodują założenia dotyczące możliwości modelu. Obowiązkowa autoryzacja i izolacja również implementują wymagania, które pozostają ważne wraz z rozwojem modeli. Anthropic wskazuje to bezpośrednio — cytat znajduje się w sekcji o trybach awarii poniżej, która dotyczy głównie sytuacji, gdy te założenia stają się nieaktualne.

Zespół OpenAI Codex nazywa to projektowaniem harnessu: tworzenie oprogramowania nadal wymaga pracy inżynieryjnej, ale coraz większa jej część dotyczy infrastruktury pomocniczej, a nie samego kodu. CompiledStateGraph LangGraph, Deep Agents firmy LangChain wraz z punktem wejścia create_deep_agent oraz sam Claude Code są harnessami w tym znaczeniu.

Sandbox. Izolowane środowisko wykonywania, w którym faktycznie uruchamiane są polecenia. Strona OpenAI Agents SDK dotycząca pojęć sandboxa przypisuje zatwierdzenia, tracing, przekazywanie sterowania oraz stan potrzebny do wznowienia uruchomień zewnętrznemu runtime’owi. Polecenia, zmiany plików i izolację środowiska przypisuje sesji sandboxa.

„Zewnętrzny runtime” oznacza tam harness wraz z jego magazynami stanu. W słowniku tej serii zatwierdzenia i przekazywanie sterowania są decyzjami harnessu (Część 4 i Część 6); tracing oraz księgowanie wznowień to prymitywy sesji i checkpointu.

Sandboxy różnią się czasem życia i zakresem pamiętania stanu między uruchomieniami. Najprostszy wariant to świeży efemeryczny sandbox: uruchamiasz go dla pojedynczego zadania, niszczysz po jego zakończeniu i ponosisz koszt zimnego startu przy każdym uruchomieniu.

Sandboxy trwałe, wstrzymane zachowują system plików i snapshot pamięci między uruchomieniami. Kolejne wznowienie może dzięki temu uniknąć pełnego startu. Snapshot lub fork tworzy obraz copy-on-write przygotowanego rodzica, dzięki czemu wiele zadań może współdzielić zainstalowane zależności i rozgrzane cache’e bez współdzielenia zapisywalnego stanu.

Workspace’y per-worktree zapewniają zadaniom osobne checkouty; Git worktrees współdzielą infrastrukturę repozytorium i nie są sandboxami systemu operacyjnego. Wykonywanie należy dodatkowo ograniczyć za pomocą kontenera, VM lub polityki procesu. Aplikacja per zadanie może mieć również własny stos observability. Oddzielne logi, metryki i trace’y pozwalają debugować jedno uruchomienie bez przenikania jego stanu do innych. Tabela dostawców w dalszej części artykułu porównuje kontrakty izolacji i trwałości.

Checkpoint. Stan potrzebny do wznowienia: który węzeł grafu został wykonany, jakie są jego najnowsze wartości i co powinno zostać wykonane następnie. Dziennik zdarzeń odpowiada na pytanie, co się wydarzyło: jakie działania zażądano i jakie były ich wyniki. Checkpoint nie może odtworzyć zdarzeń, których harness nigdy nie zarejestrował.

PostgresSaver LangGraph zapisuje Checkpoint na granicy każdego super-kroku. Super-krok to jedna runda grafu — pojedynczy węzeł albo partia węzłów wykonana równolegle. Zapisy per zadanie trafiają do checkpoint_writes, dzięki czemu udane wyniki węzłów nie są obliczane ponownie, gdy jeden z sąsiednich węzłów zakończy się błędem.

Checkpoint jest zwykłym dictem (v, id, ts, channel_values, channel_versions, versions_seen, updated_channels). LangGraph serializuje go za pomocą opartego na msgpack JsonPlusSerializer, a nie JSON. datetime, set, Decimal oraz dataclasses są poprawnie odtwarzane po serializacji. Format opisano na stronie PyPI langgraph-checkpoint-postgres oraz w referencji checkpointów LangGraph.

StateSnapshot to osobny, bogatszy widok tworzony przez graph.get_state() na podstawie checkpointu. Pakiet debugowania może wyeksportować jego .values jako ostatni znany stan grafu; nie odtworzy jednak szczegółów zdarzeń, których harness nie zarejestrował.

Trace. Powierzchnia debugowania i audytu. Każde wywołanie modelu, wywołanie narzędzia i krok podagenta powinny emitować czas trwania, status, model i dostawcę, identyfikatory korelacji, liczbę tokenów oraz koszt. Prompty, uzupełnienia, argumenty narzędzi i wyniki narzędzi są treścią opcjonalną: wytyczne OpenTelemetry dotyczące GenAI domyślnie ograniczają się do metadanych, ponieważ pola te mogą zawierać dane wrażliwe. Przechwytuj je dopiero po ustaleniu zasad redakcji lub filtrowania, kontroli dostępu i retencji. Gdy sześciogodzinne uruchomienie zakończy się błędem, to trace pozwala ustalić, co poszło nie tak. Może wspierać dochodzenie, ale to dziennik zdarzeń i stan checkpointu wraz z obsługą idempotencji umożliwiają bezpieczne wznowienie lub odtworzenie. Do tego czasu wyjście terminala z uruchomienia dawno zniknie. Konwencje semantyczne GenAI OpenTelemetry standaryzują nazwy atrybutów: który model, który dostawca, ile tokenów, która konwersacja i który workflow. W przypadku miejsca docelowego zgodnego z OTLP i obsługującego te konwencje ta sama instrumentacja może eksportować trace do systemów takich jak Tempo, Jaeger, Honeycomb lub LangSmith, choć nadal mogą być wymagane adaptery backendu albo konfiguracja właściwa dla miejsca docelowego.

Polityka i sekrety przecinają wszystkie prymitywy

Dwie granice przecinają wszystkie pięć prymitywów. Są runtime’ową wersją argumentu bezpieczeństwa z Części 4. Sama decyzja o uprawnieniu należy do harnessu; poniżej opisano, gdzie fizycznie znajdują się mechanizmy, które ją egzekwują i dostarczają niezbędnych danych.

Egzekwowanie uprawnień

Drabina uprawnień z części 4 musi mieć miejsce, w którym będzie wykonywana. Sprawdzenie uruchamia się przed każdym wywołaniem narzędzia i decyduje, czy zostanie ono przepuszczone. W produkcji często stosuje się dwa wzorce. Middleware uprawnień systemu plików w Deep Agents może ograniczyć wbudowane narzędzia systemu plików do zadeklarowanych ścieżek. Nie zarządza ono poleceniami powłoki w sandboxie, własnymi narzędziami ani wywołaniami MCP; egzekwuj je w polityce sandboxa lub za własnym proxy narzędzi. Anthropic Managed Agents kieruje własne wywołania narzędzi MCP przez proxy przechowujące poświadczenia. Wykonywanie poleceń w sandboxie i uwierzytelnianie Git korzystają z oddzielnych ścieżek; proxy MCP nie jest uniwersalnym przechwytywaczem każdego działania. Gdy wrażliwe wywołanie wymaga zatwierdzenia człowieka, interrupt() LangGraph oraz hook zatwierdzania Deep Agents wstrzymują graf do czasu decyzji.

Broker sekretów

Model nie powinien widzieć długowiecznych sekretów, a sandbox zwykle również nie powinien mieć do nich dostępu. Warto skopiować wzorzec Managed Agents:

„W przypadku Git używamy tokena dostępu danego repozytorium, aby sklonować repozytorium podczas inicjalizacji sandboxa, a następnie podpinamy go do lokalnego remote Git. Git push i pull działają wewnątrz sandboxa, bez konieczności obsługiwania tokena przez agenta. W przypadku własnych narzędzi obsługujemy MCP i przechowujemy tokeny OAuth w bezpiecznym vault. Claude wywołuje narzędzia MCP przez dedykowane proxy; proxy otrzymuje token powiązany z sesją. … Harness nigdy nie uzyskuje dostępu do żadnych poświadczeń.”

W stosie referencyjnym market-analyst-agent — małym agencie LangGraph pobierającym dane rynkowe i zapisującym raport analityka, budowanym w ramach tej serii — worker wywołuje lokalnie narzędzia danych rynkowych. Opcjonalny serwer MCP udostępnia powierzchnię narzędzi; nie jest zaimplementowanym brokerem poświadczeń między workerem a dostawcami. Oba kontenery mogą odczytywać współdzielone deweloperskie .env. Broker produkcyjny wymagałby przeniesienia poświadczeń dostawców do magazynu, którego worker nie może odczytać, oraz kierowania każdego odpowiedniego wywołania przez brokera.

Sprawdź rozmieszczenie

Praktyczny test poprawności polega na zapisaniu każdego komponentu i wskazaniu, który z pięciu prymitywów implementuje. Postgres może obsługiwać sesję i checkpoint. Kontener workera jest harnessem. Usługa taka jak Daytona, Modal lub E2B zapewnia sandbox, a Tempo lub LangSmith przechowuje trace.

Następnie sprawdź awarie zależne od siebie. Jeśli dwa prymitywy działają w tym samym procesie, jedna awaria wyłącza oba. Jeśli współdzielą poświadczenie, jeden wyciek przekracza obie granice. Typowe przykłady to worker, który jest jednocześnie właścicielem trwałości trace’ów, albo token sidecara, który odblokowuje również bazę checkpointów.

Tryby awarii runtime’u produkcyjnego agenta AI

Runtime zarządza ponawianiem, przywraca wcześniejszą pracę, izoluje workspace’y i egzekwuje budżety. W miarę jak uruchomienia rozciągają się na wiele workerów i okien kontekstowych, awarie przesuwają się w stronę problemów ze stanem, zduplikowanych efektów ubocznych, rozbieżności sandboxa i przekroczeń budżetu.

Awarie dzielą się na cztery grupy:

• Awarie jakości danych wyjściowych: agent ogłasza sukces, zanim praca faktycznie się zakończy, zapomina, co zrobił po resecie okna kontekstowego albo ufa własnej ewaluacji i publikuje niesprawny wynik.
• Awarie kontroli kosztów: agent wpada w pętlę ponowień albo zużywa budżet tokenów lub wywołań narzędzi, nie tworząc nic użytecznego.
• Awarie stanu i procesów: workspace’y rozchodzą się ze sobą, ponieważ jedno uruchomienie modyfikuje pliki należące do innego; wywołania narzędzi wykonywane są więcej niż raz, ponieważ ponowienia odtwarzają je ponownie; albo praca przepada, gdy worker umiera między zdarzeniami.
• Awarie okna kontekstowego: model podsumowuje i kończy pracę zbyt wcześnie, ponieważ uważa, że kończy mu się miejsce, mimo że okno nadal ma zapas.

Tabela mapuje każdą awarię na sposób ograniczenia, podstawę rekomendacji oraz hook runtime’u, który ją egzekwuje. Zachowanie zależne od modelu może się zmieniać, dlatego obserwacje dostawców traktuj jako wskazówki do ponownego sprawdzenia założenia, a nie jako trwałe reguły.

Za większością tych wierszy stoją dwie idee. Anthropic o starzeniu się harnessu w Harness design for long-running application development:

„Każdy komponent harnessu koduje założenie dotyczące tego, czego model nie potrafi zrobić samodzielnie. Założenia te warto poddawać testom obciążeniowym, zarówno dlatego, że mogą być błędne, jak i dlatego, że wraz z rozwojem modeli mogą szybko się zdezaktualizować.”

Vercel o pokrewnym problemie zbyt wielu narzędzi kodujących zbyt wiele założeń, w We removed 80% of our agent’s tools:

„Usunęliśmy większość z nich i ograniczyliśmy agenta do jednego narzędzia: wykonywania dowolnych poleceń bash. Nazywamy to agentem systemu plików.”

Cytat opisuje rdzeń bashowy; agent wdrożony przez Vercel zachował dwa narzędzia, ExecuteCommand i ExecuteSQL, zastępujące stary przykład kodu wymieniający siedemnaście narzędzi. Część 3 omawia pełne porównanie przed i po. Zgłoszony wynik dla pięciu reprezentatywnych zapytań: skuteczność wzrosła z 4/5 do 5/5, a najgorszy przypadek skrócił się z 724 s / 100 kroków / 145 463 tokenów (niepowodzenie) do 141 s / 19 kroków / 67 483 tokenów (sukces). Ten najgorszy przypadek jest najbardziej spektakularny; średnio dla pięciu zapytań oszczędność tokenów wyniosła 37%. Wniosek nie brzmi „usuń swoje narzędzia”. Opcjonalna pomoc może stać się zbędna wraz ze zmianą zachowania modelu. Gdy model się zmienia, ponownie sprawdź to założenie.

Cognition zaobserwowało podobnie zmienną sytuację w zakresie długości sesji dla Sonnet 4.5. W Rebuilding Devin for Claude Sonnet 4.5 opisują model, który, wyczuwając wyczerpanie kontekstu, proaktywnie zapisuje SUMMARY.md / CHANGELOG.md, ale nie doszacowuje liczby pozostałych tokenów. Ich rozwiązaniem było włączenie kontekstu o rozmiarze 1 mln tokenów i ograniczenie użycia do 200 tys., aby model nadal uważał, że ma zapas. W momencie publikacji był to przełącznik beta.

Dokumentacja Anthropic dotycząca okna kontekstowego, sprawdzona 6 września 2026 r., wymienia Sonnet 5 i Opus 5 z domyślnym oknem 1 mln tokenów; Sonnet 4.5 pozostaje przy 200 tys. Aktualne modele Sonnet automatycznie otrzymują informacje o pozostałym kontekście, a kompaktowanie po stronie serwera jest dostępne w wersji beta dla modeli Claude 4.6 i nowszych. Zanim skopiujesz historyczny limit Cognition, przetestuj wybrany model z obsługiwanymi mechanizmami kontroli kontekstu. Większe okno lub licznik budżetu nie zapewniają niezawodnego przypominania, a żaden z nich nie zastępuje trwałego postępu poza modelem.

Zespół OpenAI zajmujący się harnessami ma wersję jednozdaniową: „Ludzie sterują. Agenci wykonują.” Gdy coś się psuje, warto zapytać, której zdolności brakuje i jak sprawić, by była dla agenta zarówno czytelna, jak i egzekwowalna.

Prawidłowy cykl życia uruchomienia

Dobrze działające uruchomienie jest nudne. To łańcuch małych, możliwych do odzyskania kroków, a każdy zakończony krok zapisuje trwały stan, zanim rozpocznie się kolejny.

Zapisywanie każdego wyniku przed rozpoczęciem kolejnego kroku ogranicza skutki awarii. Wyjątkiem jest zewnętrzne działanie w toku: worker może ulec awarii po zatwierdzeniu go przez dostawcę, ale przed zapisaniem wyniku przez harness. Następny worker musi uzgodnić to oczekujące działanie, zanim wznowi pracę od ostatniego ukończonego kroku.

1. Uruchom świeżą sesję albo wznowioną. Przy wznowieniu zamontuj workspace z jego ostatniego znanego stanu, odczytaj pliki postępu pozostawione przez poprzednią próbę (PROGRESS.md, feature-list.json), wczytaj ostatni checkpoint i sprawdź w dzienniku zdarzeń oczekujące intencje narzędzi. Uzgodnij każde oczekujące działanie zewnętrzne przed kolejnym wywołaniem modelu lub narzędzia.
2. Zaplanuj działanie przed wysłaniem jakichkolwiek wywołań narzędzi. Zapisz, jak wygląda „gotowe”, ile uruchomienie może wydać, jakie narzędzia agent może wywoływać oraz co powinno zakończyć uruchomienie wcześniej. Wartości te stają się kontrolami runtime’u; bez nich wykonanie nie ma mechanizmu ograniczającego.
3. Szereguj wywołania narzędzi powodujące efekty uboczne albo jawnie nimi koordynuj. Kontrola uprawnień harnessu decyduje, czy każde z nich dopuścić. Przed wysłaniem dopisz intencję pending wraz z kluczem idempotencji; po zwróceniu wyniku dopisz rezultat. Niezależne wywołania tylko do odczytu lub idempotentne mogą działać równolegle, jeśli każde ma własny trwały rekord intencji i wyniku, a ich rezultaty są agregowane deterministycznie. Jeśli worker umrze między efektem ubocznym a zapisem wyniku, wznowienie powinno odpytać dostawcę lub ponowić wywołanie z tym samym kluczem, a następnie dopisać odzyskany wynik albo needs_human. Stripe na przykład zwraca zapisany wynik pierwszego żądania dla powtórzonego klucza idempotencji; inny dostawca potrzebuje równoważnego kontraktu wyszukiwania lub ponawiania.
4. Wykonuj checkpoint na granicach super-kroków albo po każdym zdarzeniu w prostszym harnessie. Utrwalaj stan grafu, diff workspace’u oraz odwołania do utworzonych artefaktów. Ten checkpoint odczytuje krok 1 przy kolejnym wznowieniu. Jeśli checkpointu brakuje albo jest nieaktualny, odzyskanie może wymagać odbudowania stanu z dziennika zdarzeń, co jest znacznie wolniejsze.
5. Gdy agent uzna, że praca jest zakończona, przeprowadź ewaluację artefaktów: testy, ewaluator ze świeżym kontekstem, walidację schematu, kontrole przeglądarki. Jeśli kontrola przejdzie, uruchomienie kończy się sukcesem. Jeśli nie, uruchomienie wznawia się od ostatniego czystego checkpointu z komunikatem o błędzie dodanym do kontekstu i próbuje ponownie.

Żaden krok tej listy nie wymaga, aby agent pamiętał cokolwiek między uruchomieniami. Stan znajduje się w sesji i checkpoincie, a agent odczytuje go ponownie przy każdym wznowieniu.

Przed wysłaniem zapisz identyfikator operacji należący do aplikacji i powiąż go z zatwierdzonymi argumentami. Używaj go ponownie przy odzyskiwaniu tego samego zamiaru biznesowego, nawet jeśli ponowne planowanie wygeneruje nowy identyfikator wywołania narzędzia modelu. Identyfikatory modelu zapisuj osobno na potrzeby korelacji. Naturalnie idempotentne aktualizacje mogą zamiast tego wymagać warunku wstępnego wersji. Wytyczne AWS dotyczące ponowień wyjaśniają, dlaczego tożsamość żądania reprezentuje zamiar. Zdefiniuj, kiedy działanie jest rzeczywiście nowe i jak długo trwa deduplikacja: Stripe pozwala usuwać klucze po co najmniej 24 godzinach. Przed kolejną próbą uzgodnij zmienione payloady i wygasłe klucze.

Wybierz jednego aktywnego writera albo dzierżawę dla każdego wątku. Dla danych przychodzących podczas uruchomienia jawnie odrzucaj, kolejkować, przerywaj albo wycofuj; opis runtime’u Deep Agents przedstawia te możliwości. Anulowanie musi zatrzymać nowe wysyłanie, zapisać żądanie i uzgodnić działania w toku; zabicie workera nie cofa wywołania dostawcy.

Egzekwowanie budżetu należy umieścić obok wysyłania. Równoległe wywołania nie mogą wydawać tej samej pozostałej kwoty. Prometheus jest systemem monitorowania, a nie autorytatywnym rejestrem wydatków per żądanie. Rezerwuj ostrożnie i uzgadniaj rzeczywiste użycie; opóźnione rozliczenie dostawcy i anulowanie nadal mogą spowodować przekroczenie.

Nowe mechanizmy sterowania modelem pomagają kontrolować tempo uruchomienia, ale nie zarządzają jego limitem wydatków. Beta budżetów zadań Anthropic udostępnia obsługiwanym modelom Messages API budżet orientacyjny w pętli agentowej. Budżet może zostać przekroczony; max_tokens ogranicza jedną odpowiedź, a nie całe uruchomienie. Obsługa zależy od modelu: Opus 5 obsługuje budżety zadań, a Sonnet 5 nie. Utrzymuj rejestr wysyłania i ścieżkę anulowania także wtedy, gdy model otrzymuje wskazówkę budżetową.

Mechanizmy bezpieczeństwa dostawcy wymagają własnej ścieżki terminalnej. W przypadku OpenAI misalignment_policy_violation zatrzymaj wysyłanie, zachowaj powiązane rekordy i poproś operatora o przegląd zamiast ponawiać. Obsłuż błędy strumienia po częściowych danych wyjściowych i uzgodnij wcześniejsze efekty; Część 4 wyjaśnia granicę monitorowania.

Ewaluacja powinna uwzględniać dowody spoza kontekstu, w którym powstaje wynik. Ewaluator ze świeżym kontekstem ogranicza błąd wspólnego kontekstu, a testy, lintery, kontrole przeglądarki i walidacja schematu dostarczają deterministycznych dowodów. Kontrola może zwrócić pass, fail albo needs_human. W przypadku agentów kodujących recenzentem może być inna sesja modelu z narzędziami tylko do odczytu. W przypadku agentów danych i raportów łącz walidację deterministyczną z modelem recenzującym tam, gdzie nadal potrzebny jest osąd.

Jedenaście wzorców wdrażania agentów AI i kryteria wyboru

Po nazwaniu pięciu prymitywów pojawia się pytanie, jaki układ ma je uruchamiać. Przez „układ” rozumiem rozmieszczenie tych prymitywów: gdzie znajduje się harness, gdzie utrwalany jest stan i jaki sandbox wykonuje pracę. Układ jest decyzją dotyczącą połączeń, a nie wyborem dostawcy. Wykres poniżej pokazuje, dla jakiej długości uruchomienia każdy układ jest najwygodniejszy. Późniejszy tekst omawia kryteria wyboru.

Jeśli masz przeczytać tylko jeden z jedenastu układów, wybierz układ 2: kolejka + worker + baza checkpointów. To domyślna rekomendacja dla większości zespołów, układ użyty w repozytorium referencyjnym oraz szkielet, który różnicuje większość pozostałych układów: kolejka → worker → trwały stan, z wymienionym źródłem sandboxa, właścicielem harnessu lub silnikiem stanu. Przeczytanie najpierw układu 2 przyspiesza przegląd pozostałych.

Wykres porównuje układy pod kątem długości uruchomienia. Poniższa macierz porównuje je pod kątem własności: każda obramowana komórka wskazuje komponent zapewniający dany prymityw.

1. SDK wewnątrz serwera aplikacyjnego (synchronicznie, w zakresie żądania)

Oryginalny układ. SDK agenta działa wewnątrz handlera żądania. Dobry dla zadań krótszych niż 30 sekund, demonstracji i narzędzi wewnętrznych. Zły dla wszystkiego, od czego klient HTTP może się rozłączyć. Limit czasu żądania Cloud Run wynosi maksymalnie 60 minut, a każda awaria warstwy webowej zabija uruchomienie. SDK jest harnessem. Niezaufane wykonywanie narzędzi wymaga osobnego sandboxa, a stan zwykle pozostaje w pamięci procesu, chyba że jawnie zapiszesz go gdzie indziej. Nie używaj tego układu do pracy trwającej wiele godzin.

2. Kolejka + worker + baza checkpointów

To domyślna rekomendacja dla większości zespołów oraz implementacja demonstracyjna o kształcie produkcyjnym w market-analyst-agent: Pythonowy worker z checkpointerem PostgreSQL, Redis Streams (albo RabbitMQ) dla kolejki wejściowej oraz sidecar MCP dla narzędzi. Dobry dla uruchomień od 10 minut do wielu godzin z idempotentnymi krokami. Lokalny runner może omijać kolejkę na potrzeby synchronicznego programowania, ale kolejka staje się częścią układu produkcyjnego, gdy potrzebujesz asynchronicznego przyjmowania zadań i backpressure.

W układzie produkcyjnym aplikacja przyjmuje żądanie, tworzy wiersz sesji, umieszcza zadanie w kolejce i zwraca identyfikator uruchomienia. Worker pobiera zadanie, uruchamia harness, zapisuje zdarzenia sesji i checkpointy, strumieniuje status oraz przechowuje artefakty w miarę postępu. Postgres pozostaje trwały, workery są wymienne, a długość kolejki zapewnia backpressure. Maszyny spot/preemptible działają poprawnie, jeśli trwałe zapisy dziennika zdarzeń i checkpointu zakończą się, zanim worker zgłosi sukces. Powiązane repozytorium demonstruje układ, ale nie zweryfikowane trwałe odzyskiwanie. Jego konsument odczytuje nowe wiadomości bez odzyskiwania oczekujących zadań, potwierdza wyjątki i ponownie dostarcza pracę z nowym stanem początkowym zamiast z określonym kontraktem wznowienia. Produkcja wymaga mechanizmu claim/lease/reclaim/ACK oraz testów awarii, zanim tę topologię będzie można nazwać odzyskiwalną.

W tym układzie worker jest harnessem. Jego kontener i workspace per wątek zapewniają granicę wykonywania, ale niezaufany kod nadal wymaga utwardzonego sandboxa lub VM. Magazyn zdarzeń jest właścicielem historii sesji; PostgresSaver jest właścicielem stanu checkpointów. Mogą współdzielić bazę tylko wtedy, gdy harness jawnie zapisuje oba schematy. Trace’y przechodzą przez OpenTelemetry do używanego przez ciebie stosu observability.

3. Trwały silnik workflow (w stylu Temporal)

Kod orkiestracji agenta działa wewnątrz Temporal Workflow; wywołania modelu i narzędzi działają jako Activities. Stan workflow znajduje się w dzienniku historii zdarzeń opartym na Cassandra, MySQL lub Postgres, dzięki czemu może być odtwarzany po awariach. Wdrożenia kodu workflow, które nakładają się na wykonywanie, wymagają bezpiecznego dla replay Worker Versioning albo patchy; zastąpienie kodu bez tej dyscypliny może zepsuć odtwarzanie. Integracja Temporal × OpenAI Agents SDK, ogólnie dostępna od marca 2026 r., dostarcza helpery OpenAIAgentsPlugin i activity_as_tool, a materiał agentic sandboxes opisuje przeniesienie działającego agenta do innego dostawcy sandboxa w połowie konwersacji. Bezczynne workflow zużywają zero mocy obliczeniowej. Zastrzeżenia są rzeczywiste: agenci czasu rzeczywistego nie są obsługiwani, streaming nadal ma status eksperymentalny, a LocalShellTool i ComputerTool są wyłączone, ponieważ nie pasują do modelu rozproszonego.

Wybierz ten układ, gdy uruchomienie ma rzeczywiste punkty oczekiwania: zatwierdzenia ludzi, callbacki zewnętrzne, długie uśpienia, ponowienia z regułami biznesowymi, okna wdrożeń — i gdy zespół może obsługiwać bezpieczne dla replay wersjonowanie workflow. Zatwierdzenie człowieka staje się trwałym uśpieniem, które nie zużywa mocy obliczeniowej, a nie pętlą odpytywania.

Kod Workflow jest harnessem. Sandbox zwykle znajduje się poza Temporal i jest wywoływany z Activities. Stan sesji i checkpointów zostaje połączony w dzienniku historii zdarzeń Temporal, a widoczność trace’ów zapewniają Temporal UI oraz spany OpenTelemetry na każdej Activity.

4. Dostawca sandboxa per sesja

Nowszy układ. Każde uruchomienie agenta otrzymuje własny microVM lub kontener od dostawcy sandbox-as-a-service. Harness znajduje się w trwałym miejscu, a sandbox jest jednorazowym środowiskiem wykonywania.

Czasy startu podawane przez dostawców mierzą różne przedziały i nie tworzą rankingu szybkości. Mierz osobno czas od żądania API do pierwszego pomyślnego polecenia oraz czas osiągnięcia gotowości aplikacji, uwzględniając stan obrazu/cache’a, region, współbieżność i p95/p99. Około sekundowy start kontenera w Modal nie obejmuje na przykład inicjalizacji aplikacji. Przed testami obciążeniowymi sprawdź limity współbieżności konta.

Daytona zapisuje relację rodzic–dziecko dla każdego niezależnego forka, zachowując pochodzenie wyprowadzonych sandboxów. Harness Codex firmy OpenAI korzysta z wariantu per-worktree: „Codex pracuje na w pełni izolowanej wersji aplikacji, wraz z jej logami i metrykami, które są usuwane po zakończeniu zadania”.

Wybierz ten układ, gdy agent uruchamia niezaufany kod, automatyzację przeglądarki, testy lub instalację pakietów. Kompromisem są wyższe koszty i silniejsze uzależnienie od dostawcy niż przy współdzielonych workerach.

Dostawca jest właścicielem sandboxa i niczego więcej. Harness, sesja, checkpoint i trace pozostają po twojej stronie, zwykle podłączone jak w układzie kolejka + worker z punktu 2.

5. Anthropic Managed Agents (hostowany harness)

Anthropic uruchomił Managed Agents w publicznej wersji beta 8 kwietnia 2026 r., za nagłówkiem beta managed-agents-2026-04-01. Usługa zapewnia hostowaną sesję, harness, sandbox oraz proxy MCP oparte na vault. wake(sessionId) może zainicjalizować harness na nowym workerze bez utraty trwałego stanu sesji.

Anthropic rozlicza Managed Agents według standardowych stawek tokenowych oraz dodatkowo $0.08 za godzinę sesji. Rozliczenie odbywa się z dokładnością do milisekundy i obejmuje wyłącznie czas, gdy status sesji to „running”; czas bezczynności jest bezpłatny. Niekontrolowana pętla ponowień zwiększa więc koszt godzin sesji niezależnie od kosztu tokenów.

Przeczytaj zastrzeżenia. Zniżka Batch API nie obowiązuje („Sesje są stanowe i interaktywne. Nie ma trybu batch”). Managed Agents nie jest dostępny przez AWS Bedrock ani Google Vertex AI. W ramach bety tunele MCP i „śnienie” agenta są objęte dodatkowym research preview, do którego trzeba uzyskać dostęp; koordynacja wielu agentów i samoewaluacja oceniana według rubryki są udokumentowanymi częściami bety. Uzależnienie od dostawcy jest wysokie: rezygnujesz ze swobody projektowania harnessu w zamian za brak konieczności samodzielnego uruchamiania pętli.

Domyślna konfiguracja chmurowa umieszcza wszystkie pięć prymitywów u Anthropic. Przy sandboxach self-hosted samodzielnie obsługujesz wykonywanie, systemy plików i ruch wychodzący sieci, podczas gdy Anthropic uruchamia orkiestrację i model. Dane wejściowe i wyniki narzędzi nadal trafiają do płaszczyzny sterowania dostawcy; dołączone umiejętności i pamięć są tam przechowywane i synchronizowane. Własne wykonywanie nie czyni całego systemu self-hosted.

Claude Platform on AWS również obsługuje Managed Agents i sandboxy self-hosted; jest to odrębna usługa od Bedrock. W tym środowisku autonomiczna sesja potrzebuje zdarzenia user-role do ponownego uwierzytelnienia po sześciu godzinach, a sesje self-hosted nie mogą dołączać magazynów pamięci. First-party Managed Agents nie ma tych dwóch ograniczeń. Przed skopiowaniem projektu sesji sprawdź zarówno platformę, jak i model.

6. LangChain Deep Agents Deploy (zarządzany otwarty harness)

deepagents deploy pakuje deepagents.toml do LangSmith Deployment z trwałym wykonywaniem, pamięcią, obsługą wielu tenantów, human-in-the-loop, observability, izolowanym wykonywaniem kodu i zaplanowanymi uruchomieniami. Obsługiwane są tryby wdrażania cloud, hybrid i self-hosted. Dostawców sandboxów (LangSmith Sandboxes, Daytona, Modal, Runloop lub własnego) można przełączać jedną wartością konfiguracji. Pliki agenta i pamięć znajdują się w wirtualnym systemie plików z wymiennymi backendami; trwałość checkpointów jest oddzielna, a pamięć może być przypisana użytkownikowi, asystentowi albo obu stronom. Uzależnienie od dostawcy jest mniejsze niż w Managed Agents: harness jest objęty licencją MIT, instrukcje korzystają z otwartego standardu AGENTS.md, a agenci są udostępniani przez MCP, protokół A2A (Agent2Agent) i Agent Protocol. Zobacz materiał LangChain runtime-behind-production-deep-agents.

Domyślnie hostowane są wszystkie pięć prymitywów, ale każdy można przełączyć konfiguracją. Sandbox znajduje się za jedną wartością konfiguracji. System plików pamięci jest oddzielony od trwałości wątków i checkpointów. Trace trafia do LangSmith.

7. Usługa lub zadanie Google Cloud Run

Cloud Run ma dwa różne tryby runtime’u, a wybór zależy od sposobu wywoływania agenta. Usługi są związane z HTTP i skalują się do zera między żądaniami; harness działa jako handler żądania i zwraca wynik po zakończeniu uruchomienia. Zadania działają do ukończenia bez punktu wejścia HTTP; harness działa jako jednorazowy worker, który kończy się po wykonaniu zadania. Oba tryby mogą hostować harness, ale żaden nie przechowuje stanu między uruchomieniami. Sesje i checkpointy muszą znajdować się w Postgres, Spannerze lub podobnym zewnętrznym magazynie.

Twarde limity obu trybów znacząco się różnią. Limit czasu żądania usługi Cloud Run: domyślnie 300 s, maksymalnie 3600 s (60 min). WebSockets mają ten sam limit. Zadania Cloud Run: domyślnie 10 min na zadanie, maksymalnie 168 godz. (7 dni); dla zadań korzystających z GPU maksymalnie 1 godz. Rozliczanie per instancja (zawsze przydzielony CPU) nadal pozwala na scale-to-zero; minimalna liczba instancji jest osobnym ustawieniem; zadania nie mają HTTP i nie skalują się automatycznie.

Usługi używaj do synchronicznych uruchomień trwających do 60 minut. Zadania wybierz dla dłuższej pracy jednorazowej lub asynchronicznej. Cloud Run Jobs może utrzymywać zadanie przez wiele dni, ale nie zapewnia trwałego replay po wdrożeniach, zmianach wersji ani wymianie workera. Dłuższy workflow może obejmować wiele wykonań, jeśli zewnętrzny orkiestrator jest właścicielem trwałego postępu.

Cloud Run hostuje harness. Stan sesji i checkpointów znajduje się w Postgres, Spannerze lub innym zewnętrznym magazynie, a trace’y mogą przepływać przez Cloud Logging i OpenTelemetry. Kontener usługi jest środowiskiem wykonywania; dodaj osobny sandbox, gdy agent uruchamia niezaufany kod.

8. AWS Lambda: ograniczone czasowo wywołania i trwałe workflow

Maksymalny timeout funkcji Lambda wynosi 900 s (15 minut) i jest niezmienny. Jeśli funkcję wystawia API Gateway, limit integracji zależy od typu API. HTTP APIs pozwala na 30 sekund; integracje REST mają domyślnie 29 sekund, natomiast regionalne i prywatne API REST mogą konfigurować dłuższy timeout. Lambda durable functions, uruchomione w grudniu 2025 r., dodają zarządzane checkpointy, kroki i oczekiwania między wykonaniami trwającymi do jednego roku. Aktywne wywołanie nadal podlega limitowi, ale trwałe workflow może żyć dłużej. Porównaj obsługiwane runtime’y, regiony, reguły replay i idempotencję aktywności z wymaganiami.

Lambda może utrzymywać ograniczony harness w ramach limitu 15 minut. Stan sesji i checkpointów nadal wymaga jawnych zewnętrznych magazynów; dodaj osobny sandbox dla niezaufanego kodu i eksportuj trace’y do zewnętrznej telemetrii. Trwałe workflow Lambda może orkiestruje pracę trwającą wiele godzin przez serię ograniczonych czasowo wywołań.

9. AWS ECS / zadanie Fargate per uruchomienie

Fargate nie dokumentuje twardego limitu czasu działania zadania, w przeciwieństwie do zwykłego wywołania Lambda. Fargate nie obsługuje zadań GPU; obciążenia ECS z GPU wymagają odpowiednich instancji EC2 lub zewnętrznej usługi GPU. Fargate zapewnia izolację zadań opartą na wirtualizacji, choć poświadczenia i dozwolony dostęp sieciowy nadal wymagają modelu zagrożeń. Limity throttlingu Fargate pozwalają na początkowy burst 100 uruchomień i uzupełnianie w tempie 20 na sekundę, z osobnymi budżetami on-demand i spot. Limity usług ECS ograniczają usługi korzystające z AWS Cloud Map do 1000 zadań na usługę, a klastry oparte na EC2 do 5000 instancji kontenerów.

Fargate wymaga trybu awsvpc, więc każde zadanie otrzymuje interfejs sieciowy i prywatny adres IP. Ten układ pasuje do dostępu do danych wewnątrz VPC. Fargate Spot zwiększa ryzyko przerwania, a trwałość pozostaje twoją odpowiedzialnością, ponieważ platforma nie zapewnia replay w stylu Temporal.

Fargate hostuje harness i przydziela każdemu uruchomieniu własne zadanie. Oddziela to workspace’y i poświadczenia zadań, ale samo w sobie nie jest kompletnym sandboxem dla wrogiego kodu. Sesja, checkpoint i trace trafiają do zewnętrznych usług, takich jak RDS lub DynamoDB oraz CloudWatch/X-Ray.

Przed samodzielnym budowaniem warstwy sesji w AWS porównaj również Amazon Bedrock AgentCore Runtime. Hostuje on kod agenta z zarządzanym cyklem życia sesji i wyborem mocy obliczeniowej. AWS dokumentuje do 8 godzin na bezserwerowych microVM-ach albo 14 dni na typie Instances, który obsługuje również obciążenia GPU. Instances używa zarządzanych przez AWS zasobów EC2 na twoim koncie, z innym modelem bezpieczeństwa niż opcja bezserwerowa. Jawnie wybierz i przetestuj ten kontrakt obliczeniowy; dłużej żyjąca instancja nadal nie zapewnia dokładnie jednokrotnego wykonania efektu zewnętrznego.

10. Kubernetes Job lub namespace per sesja

Dobry wybór, jeśli już obsługujesz Kubernetes i chcesz mieć sandbox per sesja z kontrolą na poziomie klastra. Zły, gdy potrzebujesz startu krótszego niż sekunda, ponieważ pobranie obrazu kontenera i inicjalizacja poda trwają zbyt długo przy zimnym starcie. Wzorzec to jeden Job na uruchomienie agenta, z activeDeadlineSeconds, PersistentVolumeClaim dla workspace’u i sidecarem serwera MCP. Odzyskiwanie po awarii musisz zbudować samodzielnie. Przyjmowanie Kubernetes tylko po to, by hostować agentów, jest kosztowne pod względem konfiguracji i obsługi operacyjnej. Ma sens wyłącznie wtedy, gdy już używasz K8s z innych powodów.

Kubernetes hostuje harness i środowisko wykonywania per uruchomienie, zwykle jako jeden Job, a czasem w dedykowanym namespace. Silna izolacja nadal zależy od runtime class, polityki sieciowej, bezpieczeństwa podów oraz bazowej granicy kontenera lub VM. Sesja i checkpointy znajdują się w zewnętrznej bazie albo na PersistentVolumeClaim.

11. Lokalny Docker Compose (tylko do developmentu)

To punkt odniesienia dla następnej sekcji. Ten układ odzwierciedla topologię produkcyjną jeden do jednego (te same prymitywy i kształt sieci), ale działa na jednym komputerze. Nie odzwierciedla natomiast izolacji: jeden współdzielony mount workspace’u, jeden Postgres, brak utwardzonego sandboxa oraz brak osobnych domen awarii między workerem a jego stanem. Nie wdrażaj niczego o takim kształcie.

Compose odwzorowuje układ nr 2 na jednym hoście. W stosie referencyjnym Postgres przechowuje stan checkpointów, a kontener workera jest harnessem. Sesja o kształcie produkcyjnym potrzebuje własnego dziennika zdarzeń append-only; sama historia PostgresSaver nie zapewnia takiego dziennika. Współdzielony mount workspace’u jest wygodny podczas developmentu, ale nie izoluje niezaufanych uruchomień. Opcjonalny stos OpenTelemetry zapisuje trace’y.

Stos referencyjny: Docker Compose

Topologia referencyjna użyta w slavadubrov/market-analyst-agent obejmuje workera LangGraph, checkpointer Postgres, Qdrant do wyszukiwania, sidecar MCP, kolejkę Redis do asynchronicznych uruchomień o kształcie produkcyjnym oraz opcjonalny stos observability Prometheus / Grafana / Loki / Tempo / OTel. W lokalnym Compose Redis jest opcjonalny wyłącznie dlatego, że synchroniczny runner może wywołać workera bezpośrednio. docker compose up uruchamia lokalnie podstawową topologię; sidecar MCP i stos observability są profilami opcjonalnymi (--profile mcp, --profile observability).

Diagram pokazuje PostgresSaver lokalnej demonstracji. Sesja o kształcie produkcyjnym dodaje osobny schemat zdarzeń dla intencji i wyników narzędzi; samo PostgresSaver nadal jest jedynie stanem checkpointów.

Jedynym elementem wartym pokazania bezpośrednio jest kanoniczne połączenie LangGraph. To ilustracyjny fragment, a nie przykład uruchamialny z repozytorium. Uruchomienie go wymaga langgraph, langgraph-checkpoint-postgres i psycopg[binary,pool], dostępnej bazy PostgreSQL z uprawnieniem do tworzenia tabel checkpointera, POSTGRES_PASSWORD oraz wcześniej zbudowanego StateGraph w builder; zobacz konfigurację checkpointera Postgres w LangGraph.

import os
from urllib.parse import quote

from langgraph.checkpoint.postgres import PostgresSaver

password = quote(os.environ["POSTGRES_PASSWORD"], safe="")
DB_URI = f"postgresql://agent:{password}@postgres:5432/agent"
# `builder` is your StateGraph, already built
session_id = "session-123"
with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()  # creates tables on first run
    graph = builder.compile(checkpointer=checkpointer)
    result = graph.invoke(
        {"messages": [{"role": "user", "content": "Continue the task"}]},
        {"configurable": {"thread_id": session_id}},
    )

Observability, które przetrwa uruchomienie

Krótkie handlery żądań łatwo debugować: gdy coś się psuje, czytasz odpowiedź i bieżący log. Długotrwali agenci nie mają tego komfortu. Gdy sześciogodzinne uruchomienie kończy się błędem, interesujące zdarzenie miało miejsce pięć godzin wcześniej, bieżące wyjście terminala zniknęło, a worker, który je wytworzył, został zastąpiony. Nikt nie odtworzy uruchomienia z pamięci. Dlatego debugujesz na podstawie trwałych artefaktów zapisanych, gdy uruchomienie nadal działało.

Stosy produkcyjne zwykle obejmują cztery rodzaje artefaktów w dwóch grupach. Dwa odczytujesz po zakończeniu uruchomienia, na potrzeby postmortemów i replay: przeszukiwalny dziennik zdarzeń każdego kroku oraz trace’y OpenTelemetry pokazujące, gdzie zużyto czas i tokeny. Dwa odczytujesz w trakcie uruchomienia. Jeden to bieżący podgląd tego, co agent tworzy w workspace. Drugi to stos observability per worktree, który sam agent może odpytywać podczas pracy.

Ustrukturyzowany dziennik zdarzeń (odczytywany po uruchomieniu)

Każde wywołanie modelu, wywołanie narzędzia, wynik, błąd i zatwierdzenie zapisane w trwałym magazynie, z kluczem w postaci identyfikatora sesji i znacznika czasu. Po zakończeniu uruchomienia odczytujesz go jak zwykłą tabelę bazy danych. Addy Osmani wyznacza prosty standard w Long-running Agents: „Jeśli nie potrafisz odtworzyć z trwałego magazynu tego, co agent zrobił w ciągu ostatnich 24 godzin, masz nie długotrwałego agenta, lecz długotrwały skrypt powłoki, który przypadkiem wywołuje LLM.”

Trace’y OpenTelemetry GenAI (odczytywane po uruchomieniu)

Ten sam rodzaj danych krok po kroku emitowany jest jako spany z użyciem standardowych atrybutów z konwencji semantycznych gen_ai.*: nazwa modelu, dostawca, liczba tokenów wejściowych i wyjściowych, identyfikator konwersacji oraz nazwa workflow. Konwencje nadal mają poziom stabilności Development.

W 2026 r. zostały przeniesione z głównego repozytorium konwencji semantycznych OpenTelemetry do własnego repozytorium konwencji semantycznych GenAI. Nazw atrybutów można używać do instrumentacji, ale przypnij wersję rewizji, którą zweryfikowałeś, zamiast numeru wersji głównego repozytorium. Pola właściwe dla dostawcy znajdują się w podprzestrzeniach nazw (anthropic.*, openai.*) opartych na gen_ai.provider.name. Powodem stosowania standardu jest przenośność: na miejscach docelowych zgodnych z OTLP, które obsługują te konwencje, zmiana backendu może nie wymagać ponownej instrumentacji kodu, choć nadal mogą być potrzebne adaptery backendu lub konfiguracja właściwa dla miejsca docelowego.

Oś czasu wywołań narzędzi i diffy workspace’u (odczytywane w trakcie uruchomienia)

Najszybszy sposób sprawdzenia, co agent robi w tej chwili, to obserwowanie tego, co tworzy w workspace, a nie przeszukiwanie dziennika sesji. Szybki start Anthropic Harness Primitives for Long-Running Claude Agents dostarcza do tego pętlę obserwacyjną z dwoma panelami: watch -n 5 'git log --oneline -8' pokazuje najnowsze commity agenta, a watch -n 5 'find screenshots -name "*.png" | tail -5' najnowsze wykonane przez niego zrzuty ekranu. Dwa panele terminala odświeżane co pięć sekund wystarczą, aby stwierdzić, czy uruchomienie rzeczywiście postępuje, czy kręci się w kółko.

Efemeryczny stos per worktree (odczytywany przez samego agenta w trakcie uruchomienia)

Jak napisano w tekście OpenAI o harnessie: „Logi, metryki i trace’y są udostępniane Codexowi przez lokalny stos observability, efemeryczny dla danego worktree”. Każdy worktree agenta otrzymuje własne krótkotrwałe Loki + Prometheus + Tempo, ograniczone wyłącznie do tego uruchomienia. Agent odpyta je podczas pracy. Dzięki temu prompt w rodzaju „żaden span w tych czterech ścieżkach użytkownika nie może przekraczać dwóch sekund” staje się czymś, co agent może bezpośrednio zweryfikować, a nie zgadywać.

(Ewaluator ze świeżym kontekstem z tabeli trybów awarii odczytuje te artefakty, aby zdecydować „gotowe”. Należy do ewaluacji, nie do observability; zob. § prawidłowy cykl życia uruchomienia. Zależy od każdej z powyższych powierzchni.)

Minimalny self-hosted stos observability

Dla czegoś takiego jak market-analyst-agent:

1. OpenTelemetry Collector z GenAI Normalizer Processor (contrib, alpha) dla obsługiwanych atrybutów GenAI. Użyj ogólnych procesorów Attributes lub Transform, aby filtrować albo przepisywać pola gen_ai.*.
2. Tempo (lub Jaeger) dla trace’ów, z kluczami gen_ai.conversation.id / thread_id.
3. Loki dla wpisów ustrukturyzowanego dziennika zdarzeń.
4. Prometheus dla gen_ai.client.token.usage, gen_ai.client.operation.duration i gen_ai.client.operation.time_to_first_chunk — metryki gen_ai.server.* pochodzą z serwera modelu, więc otrzymasz je tylko wtedy, gdy hostujesz wagi (zob. konwencje metryk GenAI).
5. Grafana z dashboardami opartymi na gen_ai.agent.name i gen_ai.request.model.

Hostowane alternatywy (wybierz jedną, nie trzy):

• LangSmith: natywna integracja z LangGraph; także cel wdrażania dla Deep Agents Deploy.
• Braintrust: najlepsze dopasowanie, jeśli priorytetem są zestawy regresyjne w podejściu eval-first.
• Arize Phoenix: OSS, natywnie zgodny z OTLP (protokołem przewodowym OpenTelemetry), współpracuje z instrumentacją OpenInference.
• Dashboard tracingu OpenAI: automatyczny przy użyciu OpenAI Agents SDK lub jego integracji z Temporal.
• Tracing Claude firmy Anthropic: dla sesji działających wewnątrz Managed Agents.

Instrumentowanie węzła LangGraph

To ilustracyjny fragment pomijany przez runner przykładów repozytorium. Zakłada, że węzeł LangGraph ma już aktywny span OpenTelemetry, bieżący thread_id oraz obiekt odpowiedzi dostawcy usage zawierający input_tokens i output_tokens; konfiguracja tracera, eksportu oraz mapowania użycia właściwego dla dostawcy pozostają poza tym fragmentem.

# In the LangGraph node, around the model call:
span.set_attribute("gen_ai.operation.name", "chat")
span.set_attribute("gen_ai.provider.name", "anthropic")
span.set_attribute("gen_ai.request.model", "<your-model-id>")
span.set_attribute("gen_ai.response.model", "<your-model-id>")
span.set_attribute("gen_ai.conversation.id", thread_id)
span.set_attribute("gen_ai.agent.name", "market-analyst")
span.set_attribute("gen_ai.workflow.name", "research_then_write")
span.set_attribute("gen_ai.usage.input_tokens", usage.input_tokens)
span.set_attribute("gen_ai.usage.output_tokens", usage.output_tokens)

Nazwy atrybutów pochodzą dosłownie z rejestru konwencji semantycznych GenAI OpenTelemetry.

Trzy zapytania, które warto mieć na dashboardzie

# Loki: output tokens per agent in the last hour (one completion event per call)
sum by (gen_ai_agent_name) (
    sum_over_time({service_name="market-analyst-agent"} | json | event = "model_call_completed" | unwrap gen_ai_usage_output_tokens | __error__="" [1h])
)

# PromQL: p95 model latency per model
histogram_quantile(0.95,
    sum by (le, gen_ai_request_model) (
        rate(gen_ai_client_operation_duration_bucket[5m])
    )
)

# TraceQL: long-running tool calls
{ span.gen_ai.operation.name = "execute_tool" && duration > 30s }

Agregacja LogQL zakłada dokładnie jedno zarejestrowane zdarzenie ukończenia na wywołanie modelu. Usuń duplikaty tych zdarzeń przed ingestem; rate zgłaszałoby tokeny na sekundę zamiast tej jednogodzinnej sumy. Zweryfikuj mapowanie pól względem wdrożonego strumienia Loki.

Wzorzec pakietu debugowania

Gdy uruchomienie zakończy się błędem, worker powinien utworzyć /workspaces/${THREAD_ID}/_debug/ zawierający artefakty, o które poprosiłbyś w postmortemie:

• events.jsonl: eksport z osobno zapisywanego dziennika zdarzeń append-only harnessu, obejmujący intencje narzędzi, wyniki, zatwierdzenia i błędy.
• checkpoints.jsonl: historia stanu grafu z checkpointer.list({"configurable": {"thread_id": ...}}), oznaczona jako checkpointy, a nie dziennik zdarzeń.
• last_state.json: StateSnapshot.values z ostatniego udanego super-kroku.
• trace.json: spany wyeksportowane przez OTLP dla uruchomienia; podstawą są metadane, a przechwycona treść podlega polityce trace’ów.
• tool_calls.csv: (ts, tool, input_hash, latency_ms, status, error).
• workspace.tar.zst: katalog workspace’u oraz git diff względem commita inicjalizującego.
• screenshots/*.png: to, co agent widział.
• PROGRESS.md, feature-list.json oraz inne pliki postępu utworzone przez agenta.
• env.txt: tagi obrazów, wersja modelu, SHA commita harnessu.

Łącznie artefakty te mogą dostarczyć człowiekowi lub agentowi recenzującemu wystarczających dowodów do odtworzenia awarii, pod warunkiem że harness zapisywał magazyn zdarzeń, gdy uruchomienie nadal działało. „Agent się zablokował” jest nieprecyzyjne. Przykład konkretnego raportu: sesja s_123 zużyła 71 procent tokenów na powtarzanie trzech poleceń po awarii npm install.

Wybór właściwego układu: przewodnik decyzyjny

Większość powyższego porównania sprowadza się do kilku decyzji.

Zacznij od długości uruchomienia

Użyj długości uruchomienia jako pierwszego filtra:

• Poniżej 30 sekund, idempotentne: SDK w cyklu życia żądania, w serwerze aplikacyjnym.
• Od 30 s do 60 min: kolejka + worker + baza checkpointów.
• Od 60 min do 24 godz.: ta sama kolejka + worker albo Cloud Run Job dla pracy jednorazowej. Jeśli potrzebujesz również wersjonowania i replay, użyj trwałego silnika workflow.
• Powyżej 24 godz., z koniecznością przetrwania wdrożeń: trwały silnik workflow (w stylu Temporal). Cloud Run Jobs może utrzymywać długą pracę do limitu zadania, ale nie zapewnia semantyki replay.
• Wielodniowe pętle treningowe reinforcement learning: Job K8s + wolumen + Temporal.

Po tym zgrubnym filtrowaniu sprawdź efekty uboczne, odzyskiwanie, replay, izolację, lokalizację danych oraz zespół, który będzie obsługiwał system.

Dopasowanie platformy do przypadku użycia

Macierz jest gęsta i żadna pojedyncza zielona komórka nie rozstrzyga architektury; zwykle decydują komórki warunkowe, w których platforma obsługuje coś tylko z zastrzeżeniem. Szeroki zakres obsługiwanych obciążeń jest przydatny, ale nie pokazuje rezydencji danych, semantyki replay, zależności od dostawcy, dojrzałości operacyjnej ani kosztu późniejszego przeniesienia stanu.

Komórki warunkowe stosują tę samą regułę dla każdej platformy. Opcje AWS/VPC i GPU Deep Agents zależą od wdrożenia hybrydowego lub dostawcy sandboxa; Managed Agents może używać wykonywania obsługiwanego przez klienta, zachowując hostowaną orkiestrację. Wiersz dotyczący wyboru sandboxa obejmuje integrację z zewnętrznym dostawcą, którą budujesz na własnym runtime’ie albo konfigurujesz w zarządzanym harnessie. Nie obiecuje ona snapshotu działającego stanu. Kubernetes Job również potrzebuje warstwy API lub kolejki dla interaktywnego żądania; szybkie ukończenie nie czyni go usługą HTTP. Przed wyborem porównaj dostęp sieciowy, sprzęt, odzyskiwanie i ścieżkę eksportu stanu dla wybranego wdrożenia. Wiersz dotyczący kodu harnessu odnosi się do dostępu do implementacji pętli, a nie do przenośności zarządzanego wdrożenia lub jego stanu. Wykonywanie GPU w Kubernetes wymaga również węzłów GPU, sterowników i pluginu urządzeń.

Managed Agents wymaga Claude oraz orkiestracji obsługiwanej przez Anthropic. Opcjonalny sandbox self-hosted może pasować do wykonywania w prywatnej sieci, ale wymóg samodzielnego hostowania inferencji albo płaszczyzny sterowania nadal wyklucza tę opcję. Sprawdź, które dane wejściowe narzędzi, wyniki, umiejętności i pamięć mogą przekraczać tę granicę. Wewnętrzna praca nad kodem może pasować, jeśli takie przepływy danych są akceptowalne, a zespół chce przekazać obsługę harnessu.

Koszt warto zamodelować przed zobowiązaniem się do rozwiązania, a nie po nim. Stawka za godzinę sesji to $0.08/godz. ponad standardowe koszty tokenów. Jeśli pojedyncza sesja działałaby nieprzerwanie, daje to około $58/miesiąc za sesję. Przy 100 sesjach działających nieprzerwanie byłoby to około $5800/miesiąc przed uwzględnieniem tokenów. Pomnóż $0.08 przez oczekiwaną liczbę godzin współbieżnych sesji, dodaj wynik do rachunku za tokeny i porównaj z kosztem stosu kolejka + worker na własnej infrastrukturze. Późniejsza migracja z Managed Agents jest zmianą platformy, a nie zmianą konfiguracji.

Hostowany harness a własny harness

Rozróżnienie dotyczy tego, kto obsługuje harness, a nie tego, kto napisał jego kod. Hostowany oznacza, że dostawca uruchamia pętlę harnessu w swojej infrastrukturze, a ty wywołujesz API. Własny oznacza, że uruchamiasz pętlę we własnej infrastrukturze, nawet jeśli sam kod harnessu pochodzi od dostawcy.

LangChain pojawia się po obu stronach tej granicy, co często prowadzi do nieporozumień. Dostarcza LangGraph, bibliotekę na licencji MIT, którą hostujesz samodzielnie (własny harness), oraz Deep Agents Deploy, zarządzany produkt uruchamiający harness Deep Agents w LangSmith Deployment w domyślnym trybie cloud (hostowany harness). Ta sama firma, dwa różne modele operacyjne. Wybierasz tego, kto uruchamia pętlę, a nie logo znajdujące się na bibliotece. (Deep Agents Deploy ma również tryb self-hosted dla zespołów, które chcą ergonomii harnessu bez komponentu chmurowego; ten tryb należy do kategorii własnych harnessów).

Wybierz hostowany harness, jeśli jego obsługa modeli, granica danych, zachowanie podczas odzyskiwania i punkty rozszerzeń już spełniają wymagania. Wybierz własny harness, jeśli są to ograniczenia, które przewidujesz zmieniać. Migracja między tymi wariantami zmienia stan, observability i granice wykonywania, dlatego przed produkcją przetestuj ścieżkę wyjścia.

Hostowany sandbox a własne środowisko wykonywania

Wybierz hostowany sandbox, gdy izolacja, wstrzymywanie/wznawianie lub semantyka forków dostawcy pasują do modelu zagrożeń i budżetu startowego. Docker lub Fargate mogą pasować do zaufanych obciążeń wewnętrznych wymagających dostępu do VPC albo ścisłej rezydencji danych, ale standardowy kontener nie jest wystarczającą granicą dla wrogiego kodu. Część 4 omawia katalog opcji izolacji dla tego przypadku.

Magazyny stanu: Git, baza danych i object storage obok siebie

Długotrwali agenci zwykle korzystają jednocześnie z trzech magazynów stanu, ponieważ każdy z nich przechowuje inny artefakt.

Git przechowuje stan workspace’u: kod, dokumenty i pliki postępu zmieniane przez agenta. Każdy commit daje harnessowi stabilny punkt odzyskiwania, a kolejnej sesji zwartą historię.

Baza checkpointów przechowuje stan grafu: jakie decyzje podjęto, które węzły uruchomiono, jakie wyniki zwrócono i co należy wykonać dalej. Magazyn artefaktów przechowuje duże wyniki końcowe, takie jak PDF-y, pliki Parquet i zrzuty ekranu. Artefakty te nie należą do Git ani do bazy checkpointów.

Kiedy używać Git jako stanu

Używaj Git, gdy obciążenie ma charakter kodowy (edycje wielu plików, refaktoryzacje, generowanie aplikacji) albo dokumentowy w stopniu, w którym historia plików ma znaczenie. Wzorzec jest prosty: utwórz branch uruchomienia, wykonaj commit inicjalizujący, a następnie commituj w istotnych punktach: po konfiguracji, po każdej funkcji, po przejściu testów i po końcowym sprzątaniu. Ostatni SHA commita workspace’u zapisz obok wiersza checkpointu. Przy wznowieniu kolejny worker przełącza się na branch, odczytuje git log --oneline -8, sprawdza git status i najnowszy diff, a następnie odczytuje PROGRESS.md albo dowolny plik przekazania zapisany przez poprzednią sesję.

Dzięki temu Git jest powierzchnią odzyskiwania artefaktu, nad którym trwają prace, a nie zamiennikiem bazy checkpointów. Git może odpowiedzieć na dwa pytania: co się zmieniło i która wersja przeszła testy. Nie powie harnessowi, który węzeł grafu uruchomić następnie, które wywołanie narzędzia czeka na zatwierdzenie ani które ponowienie użyło już swojego klucza idempotencji. Harness Anthropic wykorzystuje commity inicjalizujące i commity per funkcja jako źródło prawdy przy odzyskiwaniu workspace’u; model odczytuje git log --oneline -8, aby odzyskać stan. Pomiń Git, gdy produktem pracy jest pojedyncza odpowiedź konwersacyjna. Narzut się nie zwróci.

Kiedy używać checkpointów w bazie danych

Używaj checkpointów w stylu PostgresSaver, gdy agent ma strukturę grafu z wieloma węzłami, a stan pośredni ma znaczenie (planner → researcher → writer → verifier). Repozytorium referencyjne używa tego dokładnie z tego powodu. Nie umieszczaj artefaktów workspace’u o rozmiarze terabajtów w checkpoincie; trafiają one do object storage.

Kiedy używać magazynu artefaktów (S3 / GCS)

Używaj object storage, gdy:

• wynik jest większy, niż powinna przenosić baza checkpointów;
• konsumenci końcowi potrzebują artefaktu dostępnego pod adresem URL bez przechodzenia przez agenta; lub
• artefakt i stan uruchomienia mają różne okresy retencji.

Możesz na przykład usuwać dziennik sesji po 30 dniach, ale przechowywać raport końcowy przez lata. Układ kluczy oprzyj na (thread_id, checkpoint_id, artifact_name), aby można było odtworzyć uruchomienie, które wytworzyło artefakt.

Kiedy prosić o zatwierdzenie człowieka

Wymagania dotyczące zatwierdzania ustalaj na podstawie ryzyka działania, już udzielonego zakresu uprawnień oraz polityki wdrożenia. Odwracalny zapis roboczy do bazy różni się od obciążenia klienta lub destrukcyjnej zmiany na produkcji. Gdy zatwierdzenie jest wymagane, pokaż rzeczywiste działanie, argumenty i miejsce docelowe, utrwal decyzję i sprawdź ją ponownie, jeśli proponowane wywołanie się zmieni; nie wykonuj odrzuconego wywołania. interrupt() LangGraph i middleware zatwierdzania Deep Agents mogą wstrzymać uruchomienie na czas tej decyzji. Część 4 wyjaśnia, dlaczego jest to decyzja dotycząca uprawnień, a nie instrukcja w prompcie.

Praktyczna checklista produkcyjna

Przed wdrożeniem długotrwałego agenta odpowiedz na te pytania konkretnymi elementami infrastruktury.

1. Który magazyn jest właścicielem zdarzeń sesji i checkpointów?
2. Co się dzieje, gdy worker umrze w połowie wywołania narzędzia?
3. Czy jedno uruchomienie może uszkodzić workspace innego?
4. Które działania wymagają zatwierdzenia?
5. Czy model lub sandbox może odczytać surowe poświadczenia?
6. Które wywołania narzędzi można bezpiecznie ponawiać?
7. Gdzie egzekwowany jest limit kosztu per uruchomienie?
8. Jakie deterministyczne dowody decydują o zakończeniu i które pozostałe kryteria wymagają recenzenta?
9. Gdzie znajdują się końcowe wyniki po usunięciu sandboxa?
10. Czy jutro będziemy potrafili wyjaśnić nieudane uruchomienie bez ponownego jego wykonywania?

Jeśli odpowiedź na którekolwiek z tych pytań brzmi „prompt mówi agentowi, żeby uważał”, system nie jest jeszcze wdrożony. Nadal jest demonstracją.

Następną warstwą jest pętla harnessu

Ten runtime może utrzymywać uruchomienie przy życiu i zapewniać możliwość odzyskania, ale trwałość nie dowodzi poprawności pracy. Część 6, Harness Engineering for AI Agents, otwiera prymityw harnessu z powyższej tabeli: jak trace informuje, z którą z kilku awarii masz do czynienia, gdzie znajdują się reguły ponawiania i zatrzymywania, co musi zachować przekazanie oraz jak zewnętrzna kontrola akceptacyjna decyduje, że uruchomienie jest zakończone. To również ostatni artykuł serii.

Referencje

Materiały inżynieryjne

• OpenAI, Harness engineering: leveraging Codex in an agent-first world.
• Anthropic Engineering, Effective harnesses for long-running agents.
• Anthropic Engineering, Harness design for long-running application development.
• Anthropic Engineering, Scaling Managed Agents: Decoupling the brain from the hands, 8 kwietnia 2026 r.
• Cognition AI, Rebuilding Devin for Claude Sonnet 4.5: Lessons and Challenges.
• Vercel, We removed 80% of our agent’s tools.
• Addy Osmani, Long-running Agents.

LangGraph i Deep Agents

• Dokumentacja LangGraph, Persistence.
• Referencja LangGraph, Checkpoints.
• langgraph-checkpoint-postgres w PyPI.
• Dokumentacja LangChain, Deep Agents overview.
• Dokumentacja LangChain, Deep Agents permissions.
• Blog LangChain, The runtime behind production Deep Agents.

OpenAI Agents SDK

• OpenAI Agents SDK, Sessions.
• OpenAI Agents SDK, Sandbox concepts.

Temporal

• Blog Temporal, Introducing Temporal and agentic sandboxes: the OpenAI Agents SDK.
• Blog Temporal, Production-ready agents with the OpenAI Agents SDK + Temporal.
• README Temporal × OpenAI Agents SDK contrib (temporalio/sdk-python).

Platforma Anthropic

• Anthropic, Claude platform pricing: stawki za godzinę sesji Managed Agents.
• anthropics/cwc-long-running-agents: zadanie Code with Claude 2026 z ewaluatorem-podagentem i wzorcami plików postępu.

Dostawcy sandboxów

• ZenML, E2B vs Daytona: sandbox comparison for platform engineers.
• Dokumentacja Daytona, Sandboxes.
• Changelog Daytona, Sandbox fork and snapshot endpoints.
• Dokumentacja Modal, Sandboxes.
• Dokumentacja Modal, Cold start guide.
• Runloop on AWS Marketplace.
• Vercel Sandbox pricing and limits.

Limity czasu i kwoty platform chmurowych

• Google Cloud, Configure request timeout for services.
• Google Cloud, Using WebSockets.
• Google Cloud, Set task timeout for jobs.
• AWS, Configure Lambda function timeout.
• AWS, Lambda quotas.
• AWS, Fargate throttling quotas.
• AWS, ECS service quotas and API throttling limits.

Observability

• OpenTelemetry, Semantic conventions for generative AI systems.
• OpenTelemetry, Gen AI attributes registry.
• OpenTelemetry, Semantic conventions for GenAI agent and framework spans.
• OpenTelemetry, Semantic conventions for generative AI metrics.

Kod Market Analyst Agent (worker LangGraph, checkpointer Postgres, pamięć Qdrant, sidecar MCP i opisana powyżej topologia Docker Compose) znajduje się na GitHub.