Długotrwałe agenty AI potrzebują trwałych kanałów

Dokumentacja trybu pracy w tle OpenAI opisuje dziś typowy problem agentów: zadania wymagające rozumowania mogą trwać kilka minut, programiści mogą odpytywać odpowiedź po ID, anulować ją i wznowić strumień od zapisanego numeru sekwencyjnego.¹

Jakie są najważniejsze wnioski?

• Długotrwałe wykonanie pracy przez agenta potrzebuje adresu. Klient musi móc ponownie połączyć się z tą samą pracą, wznowić strumień od znanego kursora, wysłać polecenie sterujące, anulować wykonanie i sprawdzić dowody.
• Samo odpytywanie daje zbyt wąski kontrakt. Odpytywanie potrafi zgłosić status, ale poważna praca agenta wymaga także poleceń, historii zdarzeń, wznawialnych strumieni, artefaktów, autoryzacji i punktów kontrolnych.
• Trwałe wykonywanie rozwiązuje tylko część systemu. Przepływy pracy w stylu Temporal zachowują stan wykonywania i historię zdarzeń, ale użytkownik nadal potrzebuje trwałej powierzchni komunikacyjnej wokół trwającej pracy.²³
• WebSockets pomagają, ale gniazdo nie jest całym adresem. Zerwane połączenie nie powinno usuwać drogi powrotu użytkownika do wykonania agenta.
• Powierzchnia produktu ma znaczenie. Użytkownik powinien widzieć jedno spójne wykonanie z dowodami, decyzjami i kolejnymi działaniami, a nie rozproszone logi i optymistyczny tekst statusu.

Długotrwałe agenty AI nie mieszczą się w dawnym schemacie żądanie-odpowiedź. Zwykłe żądanie ma endpoint, odpowiedź i limit czasu. Poważne wykonanie pracy przez agenta ma czas trwania, historię zdarzeń, pośrednie artefakty, przerwania ze strony użytkownika, stan modelu i narzędzi, reguły anulowania oraz człowieka, który może odejść i wrócić.

Brakującym obiektem nie jest kolejna wiadomość czatu. Brakującym obiektem jest trwały kanał: stabilny adres dla trwającego fragmentu pracy.

Wcześniej pisałem już, że zarządzane agenty przejmują infrastrukturę środowiska wykonawczego oraz że ślady wykonywania agentów stają się kontraktem środowiska wykonawczego. Trwałe kanały znajdują się między tymi dwiema ideami. Ślad dowodzi, co się wydarzyło. Zarządzane środowisko wykonawcze utrzymuje pracę przy życiu. Trwały kanał pozwala produktowi i użytkownikowi rozmawiać z tą pracą, dopóki trwa.

Co psuje się w starym modelu żądań?

Stary model webowy zakłada, że obliczenia kończą się w ramach żądania albo trafiają do zadania w tle. Trwały stan przechowuje baza danych. Serwer aplikacyjny pozostaje bezstanowy. Klient może odświeżyć stronę, trafić na inny serwer i odczytać ten sam wiersz bazy danych.

Praca agenta nadwyręża ten model na 3 sposoby. Może trwać minuty albo godziny. Niesie stan procesu, którego nie da się czysto sprowadzić do jednego rekordu w bazie. Wymaga dwukierunkowej kontroli: obserwowania, przerywania, zatwierdzania, przekierowywania, anulowania i wznawiania.

Zak Knill nazwał to samo napięcie problemem routingu. W poście z maja 2026 roku przekonuje, że długotrwała, stanowa i interaktywna praca agentów potrzebuje adresowalnego mechanizmu routingu, który potrafi wskazać proces wykonujący pracę, a nie tylko bazę danych przechowującą jej wyniki.⁴ Użyteczna część tej perspektywy brzmi tak: klient chce powiedzieć „dostarcz polecenie Y do wykonania X”, nawet jeśli pierwotne gniazdo, proces roboczy, karta albo proces zniknęły.

Zadania w tle nadal dobrze obsługują proste prace. Zmiana rozmiaru obrazu, eksport faktury czy nocna synchronizacja mogą potrzebować tylko stanów: w kolejce, uruchomione, zakończone sukcesem albo zakończone błędem. Praca agenta przekracza granicę wtedy, gdy użytkownik musi nią sterować, zanim się zakończy.

Dlaczego samo odpytywanie nie wystarcza?

Odpytywanie daje klientowi sposób, by zapytać: „czy to już gotowe?”. Nie daje jednak pełnego kontraktu interakcji.

Tryb pracy w tle OpenAI obejmuje odpytywanie, ponieważ rozwiązuje ono problem limitu czasu. Dokumentacja zaleca programistom pobieranie odpowiedzi w tle, dopóki status pozostaje queued albo in_progress, a następnie zatrzymanie się po osiągnięciu stanu końcowego.¹ Ta sama strona udostępnia też anulowanie i wznawianie strumienia za pomocą kursora sequence_number, co wykracza poza podstawowe odpytywanie i wskazuje na bogatszy kontrakt wykonania.¹

Produkt, który kończy na odpytywaniu, zwykle rozrzuca stan agenta po zbyt wielu miejscach:

Odpytywanie może pozostać jedną ze ścieżek dostępu. Błędem jest traktowanie go jako kontraktu produktu.

Co powinien zawierać trwały kanał?

Trwały kanał to nazwany kontrakt komunikacyjny wokół wykonania. Implementacja może używać silnika przepływów pracy, kolejki, tabeli zdarzeń, WebSocket, strumienia SSE, tematu pub/sub, zarządzanej sesji agenta albo mieszaniny tych elementów. Ważniejszy od transportu jest kontrakt produktu.

Minimalny kontrakt ma 9 części:

Każde zdarzenie potrzebuje typu, numeru sekwencyjnego, znacznika czasu, aktora, referencji do payloadu i polityki maskowania. Bez tej struktury dziennik zdarzeń staje się tylko kolejnym zapisem czatu.

Kanał potrzebuje też wyczucia. Nie należy strumieniować każdego tokena, gdy użytkownik potrzebuje decyzji. Nie należy chować awarii narzędzi za przyjaznym spinnerem. Nie należy zamieniać działającego agenta w burzę powiadomień. Dobry kanał pokazuje kilka zdarzeń, które pomagają użytkownikowi zaufać pracy, pokierować nią albo ją zatrzymać.

Jak istniejące systemy wskazują ten wzorzec?

Temporal daje dojrzałe słownictwo po stronie wykonywania. Wykonanie przepływu pracy ma historię zdarzeń, odtwarzanie, deterministyczny kod przepływu pracy oraz aktywności dla pracy ze światem zewnętrznym, takiej jak wywołania API, zapytania do bazy danych, wywołania LLM i operacje I/O na plikach.² Dokumentacja przekazywania wiadomości TypeScript w Temporal opisuje przepływy pracy jako stanowe usługi, które odbierają zapytania, sygnały i aktualizacje. Klienci mogą pobrać uchwyt przepływu pracy po ID przepływu pracy, odpytać stan, wysłać sygnały i wykonać aktualizacje.³

Ten model dobrze mapuje się na pracę agentów. Zapytania odpowiadają na pytanie „jaki stan zgłasza wykonanie?”. Sygnały odpowiadają na „proszę zmienić kurs”. Aktualizacje odpowiadają na „wykonaj śledzoną zmianę i zwróć wynik”. Historia zdarzeń odpowiada na „co się wydarzyło?”. Zespół nie musi używać Temporal, aby uczyć się z tej formy, ale sama forma daje produktom agentowym lepsze słownictwo niż „zadanie w tle plus czat”.

Cloudflare Durable Objects wskazują inny element: adresowalną koordynację. Cloudflare opisuje każdy Durable Object jako globalnie unikalną instancję z pamięcią masową, przydatną do stanowej koordynacji między wieloma klientami.⁵ Dokumentacja WebSocket opisuje długotrwałe połączenia dwukierunkowe oraz hibernację, która utrzymuje klientów w połączeniu, gdy obiekt śpi, a następnie wybudza obiekt po nadejściu wiadomości.⁶ Nie czyni to z Durable Objects uniwersalnego środowiska wykonawczego dla agentów. Pokazuje jednak, dlaczego adresowalny obiekt koordynacyjny wydaje się naturalny dla żywych powierzchni agentowych.

Artykuł Anthropic o długotrwałych agentach dodaje stronę pracy ludzkiej. Tekst mówi, że agenty nadal mają trudność z działaniem przez wiele okien kontekstu, i opisuje wzorzec, w którym późniejsze sesje robią postęp krok po kroku, zostawiając jasne artefakty dla kolejnej sesji.⁷ Trwałe kanały powinny przenosić te artefakty na powierzchnię produktu, a nie zakopywać je w prywatnych logach.

Co zbudowałbym najpierw?

Zacząłbym od małej usługi wykonań, a nie od wielkiej platformy orkiestracji.

Należy utworzyć tabelę runs z właścicielem, statusem, znacznikami czasu i bieżącym podsumowaniem. Należy utworzyć tabelę albo strumień run_events z monotonicznie rosnącymi numerami sekwencyjnymi. Duże payloady i artefakty warto przechowywać osobno, a ze zdarzeń odwoływać się do nich referencjami. Następnie dodać jeden wznawialny endpoint strumienia i jeden endpoint typowanych sygnałów. Anulowanie powinno być idempotentne. Każde przejście stanu powinno trafić do dziennika zdarzeń.

Potem trzeba ograniczyć słownik zdarzeń:

UI może teraz pokazać jedno spójne wykonanie. Użytkownik może odejść, wrócić, przejrzeć zdarzenia, sprawdzić artefakty i sterować pracą z tego samego adresu. Agent może przestać deklarować sukces w prozie, a zacząć dołączać dowody do przejść stanu.

Czego zespoły powinny unikać?

Warto unikać 3 skrótów.

Po pierwsze, czystego zapisu czatu. Czat może inicjować pracę i zbierać doprecyzowania. Nie powinien być jedynym obiektem środowiska wykonawczego dla długotrwałego zadania.

Po drugie, surowego strumieniowania tokenów jako głównej powierzchni postępu. Strumienie tokenów pomagają programiście debugować opóźnienia, ale większość użytkowników potrzebuje kamieni milowych, blokad, artefaktów i decyzji. Trwały kanał nadal może udostępniać surowe zdarzenia do eksperckiej inspekcji.

Po trzecie, wycieku prywatnego procesu. Publiczna powierzchnia produktu powinna pokazywać dowody, a nie prywatne prompty, treści punktów zaczepienia, lokalne ścieżki plików czy wewnętrzną maszynerię oceniania. Użytkownik potrzebuje wystarczająco dużo, by zaufać pracy. Nie potrzebuje każdego wewnętrznego triku, który ją umożliwił.

Ta granica prywatności dotyczy też publicznego pisania o systemach agentowych. Należy dzielić się kontraktem. Prywatna maszyneria powinna pozostać prywatna.

Jak trwały kanał zmienia ocenę?

Trwały kanał sprawia, że ocena staje się mniej teatralna.

Zamiast pytać, czy końcowa odpowiedź brzmi wiarygodnie, osoba oceniająca może sprawdzić wykonanie:

• Czy wykonanie zaczęło się z właściwym właścicielem, uprawnieniami i zakresem?
• Czy agent przed działaniem udostępnił plan?
• Czy każdy deklarowany artefakt pochodzi z zapisanego zdarzenia?
• Czy awarie tworzyły użyteczne punkty kontrolne?
• Czy sygnały użytkownika zmieniły wykonanie w oczekiwany sposób?
• Czy anulowanie zakończyło się jednym stanem końcowym?
• Czy raport końcowy cytował dowody z dziennika zdarzeń?

Ta lista zmienia bramkę dowodów w coś, co środowisko wykonawcze może wspierać bezpośrednio. Łączy się także z warstwą porządkowania: wiele produktów agentowych wygra dzięki temu, że uczyni chaotyczne wykonania zrozumiałymi, wznawialnymi i możliwymi do sprawdzenia.

Krótkie podsumowanie

Długotrwałe agenty AI potrzebują trwałych kanałów, ponieważ użytkownik potrzebuje stabilnej drogi powrotu do pracy. Odpytywanie może zgłaszać status, ale samo nie uniesie całego kontraktu. Dobre wykonanie agenta potrzebuje ID przepływu pracy, uporządkowanych zdarzeń, wznawialnych strumieni, typowanych sygnałów, idempotentnego anulowania, referencji do artefaktów, uprawnień i czytelnych dla człowieka punktów kontrolnych. Trwałe wykonywanie utrzymuje pracę przy życiu; trwałe kanały pozwalają użytkownikowi i produktowi z nią współdziałać.

FAQ: długotrwałe agenty AI i trwałe kanały

Czy długotrwałe agenty AI wymagają Temporal?

Nie. Temporal daje zespołom mocne słownictwo przepływów pracy i dojrzały model wykonywania, ale kontrakt trwałego kanału może działać na prostszej infrastrukturze. Warto zacząć od stabilnych ID wykonań, uporządkowanych zdarzeń, wznawialnych strumieni, typowanych poleceń i artefaktów. Do silnika przepływów pracy należy przejść wtedy, gdy uzasadniają to ponowienia, odtwarzanie, timery i skala operacyjna.

Czy WebSockets wystarczą do pokazywania postępu agenta?

Nie. WebSockets dają żywe połączenie dwukierunkowe. Produkt nadal potrzebuje trwałego adresu, historii zdarzeń, kursora ponownego połączenia, uprawnień i stanów końcowych. Gniazdo może przenosić kanał, ale nie powinno definiować całego kanału.

Czy odpytywanie zawsze jest złe?

Nie. Odpytywanie działa przy prostych kontrolach statusu i może pozostać ścieżką awaryjną. Problemy zaczynają się wtedy, gdy staje się jedynym sposobem obserwowania, sterowania albo odzyskiwania długotrwałego wykonania agenta.

Co mały zespół powinien zbudować najpierw?

Należy zbudować zasób runs i dopisywany dziennik run_events. Wznawialny strumień warto dodać, gdy dziennik zdarzeń ma już numery sekwencyjne. Typowane sygnały należy dodać tylko dla poleceń, które produkt potrafi bezpiecznie obsłużyć: zatwierdź, wstrzymaj, zmień, dodaj kontekst i anuluj.

Co należy umieszczać w zdarzeniach wykonania agenta?

Należy rejestrować przejścia stanu, plany, rozpoczęcia i zakończenia pracy narzędzi, tworzenie artefaktów, sygnały od człowieka, blokady, anulowania, awarie i zakończenia. Wrażliwe payloady nie powinny trafiać bezpośrednio do tekstu zdarzenia. Prywatne szczegóły należy przechowywać za zamaskowanymi referencjami i kontrolą dostępu.

Źródła