O czym jest ten film
- Agenty pracują coraz dłużej, budzą się same (webhooki, zadania cykliczne, automatyzacje) i wykonują działania, których nie wolno powtórzyć — dlatego muszą być „trwałe”: wznawialne i świadome tego, na którym kroku stanęły.
- Większość programistów pisze w kółko ten sam kod agentowy: tabelę wiadomości, kolejkę zadań, strumieniowanie do interfejsu, sterowanie, forkowanie rozmowy, pauzy na zatwierdzenie, ponawianie prób, podsumowania. Efekt bywa kruchy i ciężki w debugowaniu.
- Pi Durable — biblioteka od zespołu stojącego za szkieletem agentowym Pi — zapisuje na bieżąco wszystko do bazy: wypowiedzi, wywołania narzędzi, rzeczy, na które agent czeka. Jeśli proces padnie, nowy otwiera plik i jedzie dalej.
- Każde narzędzie deklaruje, czy można je bezpiecznie uruchomić ponownie: wyszukiwanie tak (np. po świeże dane), wysyłka maila czy pull requesta — nie.
- Stan trwałego agenta to więcej niż historia czatu: to pełna lista wykonanych i oczekujących wywołań narzędzi, czekających zatwierdzeń oraz flag w stylu „deploy już się wykonał”.
- Wszystkie ekrany — telefon, terminal, Slack — są tylko klientami tego samego agenta; z tego samego powodu tryb wielu użytkowników i sterowanie w trakcie pracy dostaje się „w pakiecie”.
- To nie silnik workflow: agent sam decyduje o kolejnych krokach i dostępnych narzędziach — trwałość wykorzystuje jego mocne strony zamiast zamykać go w sztywnym scenariuszu.
- Pi Durable działa wszędzie, gdzie JavaScript: w przeglądarce na IndexedDB, w Node z SQLite, w obiektach trwałych Cloudflare czy w CellD od Deno; model podłączysz dowolny, bez więzienia u jednego dostawcy.
- Demo samonaprawiającego się oprogramowania: błąd trafia do Sentry, webhook budzi agenta, ten analizuje przyczynę, pisze poprawkę, testuje ją, otwiera pull request, scala go i zamyka zgłoszenie — zostawiając kompletny ślad.
- Ekosystem rusza: Open Code 2 można uruchomić jako bibliotekę w obiekcie trwałym, SDK agentowe Cloudflare ma gotowy harness, a twórca Pi zbudował multiplayerową aplikację agentową działającą w całości na telefonie z Androidem.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Trwałość to wymóg, nie ozdobnik
Na czym polega: Agent, który ma pracować godzinę, ruszać sam z webhooka i wykonywać kroki „tylko raz”, musi przeżyć własną awarię i wiedzieć, gdzie skończył.
Jak stosować: Przy projektowaniu agenta zacznij od pytania: „co się stanie, gdy proces padnie w połowie?” — i zadbaj, żeby dało się podnieść pracę bez powtórek.
Na co uważać: Ręczne sklejanie tego (kolejki, tabele, retry) bywa kruche; autorowi zastąpienie tego biblioteką pozwoliło skasować 8 tys. linii kodu.
2.Oznaczaj narzędzia: bezpieczne do powtórki czy nie
Na czym polega: W Pi Durable każde narzędzie deklaruje, czy po awarii można je wywołać ponownie — wyszukiwanie tak, wysłanie maila czy pull requesta nie.
Jak stosować: Podziel swoje narzędzia na idempotentne i „jednorazowe”; po restarcie wykonuj bez lęku tylko te pierwsze, a przed drugimi sprawdzaj flagę „już zrobione”.
Na co uważać: Źle zaklasyfikowane narzędzie to podwójny mail albo dwa pull requesty do tego samego błędu — szkody rosną szybko.
3.Stan agenta to więcej niż historia czatu
Na czym polega: W magazynie lądują nie tylko wiadomości, ale i lista wykonanych oraz dopiero planowanych wywołań narzędzi, czekające zatwierdzenia i informacje w stylu „deploy się już wykonał”.
Jak stosować: Zamiast restartować zadanie z pustym kontekstem, wznawiaj przebieg i pozwól agentowi dokończyć od dokładnie tego kroku, na którym stanął.
Na co uważać: Zwykłe „wznów” na historii czatu gubi te dane — agent nie wie, co już odrobił, a co dopiero zamierzał.
4.Każdy ekran to tylko klient tego samego agenta
Na czym polega: Telefon, przeglądarka, terminal i Slack patrzą na jedną instancję agenta, bo stan leży w bazie, a nie w żywym procesie.
Jak stosować: Buduj interfejsy jako cienkie klienty — sterowanie, wstrzymanie i wznowienie działają z każdego urządzenia z tą samą, pełną historią.
Na co uważać: Dostęp do bazy i identyfikatora rozmowy to dostęp do samego agenta — pilnuj, kto go ma.
5.Wspólna praca i sterowanie w locie przychodzą w pakiecie
Na czym polega: Skoro stan jest wspólny, kilku użytkowników może prowadzić agenta równocześnie, wtrącając się w trakcie pracy; banalnie łatwe robią się też forki i subagenty.
Jak stosować: Wykorzystaj to w narzędziach zespołowych — wspólna praca nad jednym zadaniem bez ręcznego synchronizowania rozmów.
Na co uważać: Równoległe prowadzenie wymaga ustalenia, kto decyduje; wbudowane pauzy na zatwierdzenie warto stosować konsekwentnie.
6.Trwały agent to nie silnik workflow
Na czym polega: Workflow sztywno steruje krokami; trwały agent sam wybiera następny ruch i narzędzia, a trwałość daje mu bezpieczeństwo wykonywania.
Jak stosować: Gdy zadanie jest nieprzewidywalne (naprawa błędu, research), wybierz agenta trwałego; gdy kroki są stałe i proste, workflow wystarczy.
Na co uważać: Autonomia plus wznawialność to podwyższone ryzyko — dorzuć guardy, np. „jedno zgłoszenie błędu = jeden pull request”.
7.Nie zamykaj się u jednego dostawcy
Na czym polega: Pi Durable działa wszędzie, gdzie JavaScript: w przeglądarce (IndexedDB), w Node z SQLite, w obiektach trwałych Cloudflare czy w CellD od Deno; model podłączysz dowolny.
Jak stosować: Zacznij lokalnie (np. Mac mini + SQLite), a na obiekt trwały przenieś się, gdy potrzebujesz ciągłości na infrastrukturze.
Na co uważać: Silne sprzężenie z jednym dostawcą utrudni później taką wędrówkę — projektuj warstwę modelu wymienne.
8.Samonaprawiające się oprogramowanie to realny setup, nie pokaz slajdów
Na czym polega: Błąd wpada do Sentry, webhook przez tunel Cloudflare budzi agenta; ten klasyfikuje zgłoszenie, analizuje przyczynę, pisze poprawkę, testuje, otwiera pull request, scala go i zamyka sprawę — z pełnym śladem.
Jak stosować: Zacznij od wąskiego obwodu: jeden projekt, automatyczne scalanie tylko w narzędziach niepublicznych, człowiek na przeglądzie kodu wszędzie indziej.
Na co uważać: Filtruj szum (np. awarie testowych workerów), deduplikuj zgłoszenia i pilnuj, by agent ruszał wyłącznie na pilnowane przez ciebie repozytoria.
9.Rozmawiaj z tym samym agentem, który odrobił robotę
Na czym polega: Po zakończonej akcji nie odpalasz świeżego agenta z pustą głową — wracasz do tego samego przebiegu, z kompletnym zapisem, i mówisz np., że poprawka ci nie pasuje.
Jak stosować: Przechowuj identyfikator rozmowy razem ze zgłoszeniem i pull requestem, żeby kontekst był zawsze pod ręką.
Na co uważać: Długie historie kosztują — korzystaj z kompakcji (w przykładach biblioteki jest gotowy mechanizm skracania starych wiadomości).
10.Nie czytaj README — pokaż agentowi folder z przykładami
Na czym polega: Repozytorium ma katalog przykładów (reload i restart, nadpisywanie narzędzi, kompakcja, zadania potomne), które autor wskazał agentowi jako weryfikowalne wzorce do naśladowania.
Jak stosować: Wskaż taki folder swojemu agentowi i poproś o integrację według przykładów; autor udostępnia gotowy prompt do wklejenia.
Na co uważać: Przykłady to punkt wyjścia — własne zabezpieczenia i polityki bezpieczeństwa musisz dopisać samodzielnie.
Redakcyjne tłumaczenie
Agent, który naprawia oprogramowanie, kiedy śpię
To jest agent, który naprawia mi oprogramowanie, kiedy śpię. To jest agent działający w całości w przeglądarce — na IndexedDB i JavaScripcie, bez żadnego serwera. To jest agent, który pracuje bezpośrednio na telefonie z Androidem. To jest agent, który sam zabiera się do moich prawdziwych zadań z listy, zanim w ogóle o to poproszę — na SQLite i Node.js. To jest agent działający w stu procentach na taniej cyfrowej ramce na zdjęcia. A wszystko to jest możliwe dzięki czemuś, co nazywa się Pi Durable. Zapnijcie pasy: jeśli budujecie agenty — jakiekolwiek — chcecie to zobaczyć.
Dlaczego zwykłe agenty przestają wystarczać
Zastanówmy się, jak dziś pracujemy z agentem. Odpalamy go i obserwujemy. Czasem utknie; zauważymy to albo nie. Zatrzymujemy proces, wracamy i zagrzewamy go: „Dalej, dasz radę”. Podobno nie wypada już odzywać się niegrzecznie do Claude’a, więc dorzuciłem odrobinę pozytywnego wzmocnienia. To wszystko jakoś działa, bo siedzimy przy klawiaturze i wymieniamy się komunikatami w tę i z powrotem. Ktoś się rozprasza, wraca po chwili — a tu proces wygasł. No to stawia go na nogi i jedzie dalej. Przy takich zadaniach to zjawisko bardzo częste i w gruncie rzeczy niegroźne.
Tyle że agenty działają dziś coraz dłużej — i w dodatku robią coraz więcej. Składają pull requesty, prowadzą badania, może właśnie poszły sprawdzić twoje konto bankowe, żeby podesłać wyniki na firmowego Slacka.
Jest jeszcze sprawa uruchamiania i zatrzymywania. Jeśli budujecie agentów w aplikacjach, często muszą być długotrwałe i muszą przeżyć własne awarie. Coraz więcej agentów rusza dziś z własnej inicjatywy — bo coś je wyzwoli: akcja, automatyzacja, trigger. Agent zabiera się do pracy i odkręca serię kroków. Ludzie robią to na co dzień: automatyzacje w stylu Claude Code, zadania cykliczne (cron), webhooki. I w tym scenariuszu przychodzi webhook, agent zaczyna działać, pada z błędem. Skąd ma wiedzieć, że ma dokończyć? Trzeba wrócić i sprawdzić, czy w nocy coś się nie wysypało.
Jeśli agent ma pracować godzinę, startować sam i robić rzeczy, które nie mogą się wydarzyć dwa razy, musi być trwały: kontynuować pracę, dawać się wznowić i dokładnie wiedzieć, na którym kroku stanął — żeby niczego nie powtarzać. Bo wyobraźcie sobie: agent wysyła maila, cały proces rusza od nowa i lecą dwa maile, dwa pull requesty, a kto tam wie co jeszcze. I właśnie w takich sytuacjach agenty trwałe pokazują, na co je stać.
Kod, który pisze każdy — i nikt nie lubi pisać
Jeśli pisaliście kiedyś agenta — do aplikacji, jako bota supportowego, asystenta, bota na Slacka czy narzędzie wewnętrzne; ja chyba wszystkie te warianty kiedyś napisałem — to niemal na pewno za każdym razem powstawało to samo. Tabela na wiadomości. Kolejka zadań do odrobienia. Gniazdo streamujące do interfejsu. Coś, co pozwala sterować, gdy użytkownik wpisze prompt w pół kroku. Może fork rozmowy. Może pauza na zatwierdzenie i wznowienie. Ponawianie tego, co ponawiać trzeba, i hamowanie przed tym, czego nie wolno. Skracanie starych wiadomości do podsumowań. I trzymanie stanu aplikacji w zgodzie z tym, co agent faktycznie odrobił. Do tego debugowanie awarii potrafi wyciąć z człowieka nerwy: bez końca stop i start. Przynajmniej u mnie tak było.
Miesiąc temu pokazywałem moje „urządzenie promptowe” działające na komputerze — całość stała na ręcznie skleconym agencie. Szczerze mówiąc: bolało. Zabierało mnóstwo czasu i było potwornie kruche. Kiedy wyszła biblioteka Pi Durable, przeskoczyłem na nią i skasowałem jakieś osiem tysięcy linii własnego kodu — a w zamian dostałem lepszy system. Za darmo. Mówię wam: dużo lepszy system, dokładnie za darmo.
Czym jest Pi Durable
Jeśli nie znacie Pi: to znakomity, rozbudowalny szkielet do budowy agentów, napędzający między innymi OpenClaw i mnóstwo programistycznych setupów agentowych — mój włącznie. Korzystam z Pi od dawna: mam konfigurację i minimalną, i własną, dopracowaną. Raz lubię w niej pogrzebać, raz lubię po prostu używać Pi tak, jak jest. To naprawdę udany projekt — więc nie zdziwi was, że Pi Durable również się broni.
(Informacja dodatkowa: OpenClaw to głośny projekt agenta-asystenta działającego lokalnie, na własnym sprzęcie użytkownika. „Durable” znaczy „trwały” — czyli odporny na awarie i wznawialny.)
Pi Durable to biblioteka od tego samego zespołu, służąca do budowy własnych agentów trwałych: agenta kodującego, bota supportowego, bota na Slacka — czego chcecie. Zasada działania jest prosta: biblioteka zapisuje wszystko na bieżąco do magazynu — co zostało powiedziane, jakie wywołania narzędzi padły, na co agent akurat czeka. Jeśli proces umiera, nowy otwiera plik i kontynuuje. Wszystko, co podłączę — telefon, przeglądarkę, Slack — patrzy na dokładnie tego samego agenta. Do tego każde narzędzie deklaruje, czy bezpiecznie jest wykonać je ponownie. Po awarii wyszukiwanie ma sens powtórzyć — być może po świeże dane. Ale jeśli agent wysyła maila, to nie chcesz, żeby cały proces ruszył od zera i posłał drugiego.
Konkretnie: plik bazy, rozmowa, wysyłacie ją z identyfikatorem, a wasze narzędzia to zwykłe funkcje. Proste? Proste.
Więcej niż historia czatu
Ktoś mógłby machnąć ręką: „Przecież mam historię czatu w agencie. Klikam wznów, rozmowa się wczytuje i piszę dalej”. Czasem to naprawdę wystarcza — zwłaszcza w kodowaniu. Ale trwały stan to coś więcej niż tekst i historia wędrująca razem z promptem. To pełna lista wywołań narzędzi: wykonanych, tych, które miały właśnie paść, zatwierdzeń, na które agent czeka, i informacji w stylu „deploy już się wydarzył”. Wszystko, co zrobił albo nie zdążył zrobić, leży w tym magazynie. Dlatego gdy wracacie do rozmowy w Pi Durable, praca podnosi się dokładnie tam, gdzie została — albo okazuje się, że agent w międzyczasie wszystko już skończył, gdy was nie było. I to jest ten ideał: chce się czasem, żeby rzeczy po prostu działały — a gdy padną, dokańczały robotę, gdy tylko znowu ruszą.
Agent, a nie silnik workflow
Świadomy czytelnik może sięgnąć po silnik workflow. Tyle że workflow to zwykle sztywno sterowane kroki — a tutaj to agent decyduje, co zrobi dalej i jakie narzędzia ma w zasięgu. Trwałość wykorzystuje mocne strony agenta, zamiast zamykać go w sztywnym scenariuszu, wersjonowanym pod konkretny kawał kodu.
Co dostajesz za darmo
Z takiej architektury wynika cały pakiet rzeczy gratis.
Po pierwsze: każdy ekran, jaki zbudujecie, to tylko klient. Telefon, terminal, komputer — jakikolwiek sposób kontaktu z agentem trwałym pozwala wejść w środek procesu, pokierować nim i pracować na dokładnie tym samym przebiegu, z pełną historią.
Po drugie: praca zespołowa przychodzi w pakiecie. Skoro kilka osób ma dostęp do tego samego agenta, mogą nad nim pracować razem — nawet kilku użytkowników prowadzących prompt równocześnie. Z tego samego powodu można zmieniać kurs w trakcie działania; sterowanie, forkowanie i podpinanie podagentów robią się banalnie proste.
Po trzecie: wspólny, zapisany stan. Czy agent czeka na zatwierdzenie, na minutnik, na cokolwiek — wygląda tak samo dla każdego, kto go obserwuje.
Gdzie to się uruchamia
Pomyślicie może: trwałe agenty, obiekty trwałe — brzmi jak świat Cloudflare. Tymczasem Pi Durable działa wszędzie tam, gdzie JavaScript. W wersji Armona całość chodziła w przeglądarce, z zapisem do IndexedDB i bez żadnego serwera. U mnie pracuje na Macu mini, w czystym Node, z SQLite jako bazą. Biblioteka pasuje też znakomicie do obiektów trwałych Cloudflare albo do CellD od zespołu Deno. I podłączycie do niej dowolny model: OpenAI, coś lokalnego — co chcecie. Budując system agentowy, nie zamykacie się w jednym dostawcy i jego sposobie robienia rzeczy.
(Informacja dodatkowa: Durable Objects to mechanizm Cloudflare utrzymujący stan procesu między zapytaniami; CellD to biblioteka zespołu Deno dająca podobne możliwości lokalnie, na własnej maszynie.)
Demo: samonaprawiające się oprogramowanie
Skoro już wiecie, co agenty trwałe mają w sobie, pokażę kawałek mojego samonaprawiającego się setupu.
Załóżmy, że mam w aplikacji buga — bo, dodajmy szczerze, bugi mam, a w tej aplikacji szczególnie, bo to kod wyskrobany przez AI na szybko. Klikam i trafiam na błąd. Błąd leci do Sentry (Informacja dodatkowa: Sentry to popularna platforma do wychwytywania i raportowania błędów w aplikacjach.) — zależnie od przepływu może to dotrzeć z opóźnieniem — a stamtąd webhookiem, przez tunel Cloudflare, do mojego setupu. I to rozkręca proces.
Najpierw system ocenia, czy to w ogóle bug do naprawienia, czy coś, czego naprawić się nie da — na przykład awaria testowego workera. Widać, jak zgłoszenie wchodzi, analiza je klasyfikuje i agent rusza do pracy. Po wejściu w szczegóły widać, jak ustala przyczynę źródłową, korzystając z analizy dostarczanej przez Sentry. W każdym momencie widać, co się dzieje.
Mogę to zatrzymać — i agent faktycznie staje. W tym miejscu skończył już szukanie przyczyny; mamy ją na ekranie razem z propozycją poprawki: „Wartość koszyka odczytuje item.discount.percent bezwarunkowo, a produkty w pełnej cenie — kabel, karta przy kasie — nie mają rabatu, więc discount ma wartość undefined”. Mamy przyczynę, mamy dokładny przebieg. Agent zatrzymany — klikam wznowienie i podnosi robotę dokładnie tam, gdzie stanął: pisze poprawkę, przepuszcza ją przez moje zwykłe testy i otwiera pull request.
Pull request leży w GitHubie: widać, co się zmieniło, widać checki, całość. Wszystko kręci się w moim własnym setupie, mam dokładny commit, mogę przejrzeć każdą linię. Ładna, drobna poprawka. Powiedziałbym: wygląda dobrze. Zdecydowanie przeglądnąłem cały ten kod. Świetnie się prezentuje. Klikam scalanie.
A teraz najlepsza część. Po chwili — może minucie, może dwóch — system sam zamyka zgłoszenie jako rozwiązane i oznacza je jako rozwiązane również u mnie, zostawiając znakomity ślad tego, co się wydarzyło. A ponieważ to jeden pełny przebieg agenta, mogę wrócić i odezwać się bezpośrednio do agenta, który robotę wykonał — w tym samym wątku, z kompletnym zapisem. Nie muszę odpalać świeżego agenta z pustym kontekstem, żeby pytać „co się stało, czemu nie zadziałało” albo „nie podoba mi się ta poprawka”. Mogę wejść zaraz po przeglądzie kodu i powiedzieć wprost: „to mi nie gra”.
Nie musicie przechodzić przez pull requesty. Mam oprogramowanie, na którym zależy mi mniej — tam poprawki scalają się automatycznie. To nie są narzędzia publiczne, skierowane do użytkowników: to rzeczy, nad którymi pracuję dla siebie albo dla rodziny. Mówiąc najprościej: błędy wpadają do Sentry, robimy triage, pobieramy analizę przyczyny źródłowej od Sentry, agent przejmuje robotę i pisze poprawkę, testuje ją, otwiera pull request, scala go i oznacza zgłoszenie jako rozwiązane — w moim systemie i w Sentry.
Cały mój system jeździ na agentach trwałych
To jeden mały przykład — a wycisnąć można znacznie więcej. W demie pominąłem sporo rzeczy: zabezpieczenia rozróżniające, czy to prawdziwa robota dla agenta; pilnowanie, czy zgłoszenie dotyczy oprogramowania, które w tym setupie akurat śledzę; guardy w stylu „na jedno zgłoszenie z Sentry przypada najwyżej jeden pull request”, żeby przy powtórnym wpadnięciu tego samego błędu nie narosły duplikaty. Jest tego mnóstwo, ale nie o to chodzi. Chodzi o to, ile da się z trwałych agentów zrobić — demo to tylko mały test.
Cała moja osobista okolica — dokumenty, czaty, listy zadań — operuje na agentach Pi Durable na tej jednej maszynie. I działa to świetnie: znacznie mniej bugów niż w czymkolwiek, co sam skleiłem.
To nie tylko moja fanaberia
Wydaje mi się, że wielu ludzi przyzwyczaiło się do agentów działających właśnie tak. Problem w tym, że ich budowa szybko robi się skomplikowana — a wokół trwałych agentów robi się teraz głośno. Wyszło właśnie Open Code 2, a jedną z większych nowości jest możliwość uruchomienia go jako biblioteki — na serwerze albo wewnątrz obiektu trwałego — i podpięcia dowolnego klienta Open Code. SDK agentowe Cloudflare ma już gotowy harness, który odpala Pi Durable w obiekcie trwałym. I jak mówiłem, to nie jest wyłącznie sprawa Cloudflare. Można wziąć CellD od zespołu Deno, które — ironia losu — od przejęcia Deno przez Cloudflare samo jest już „sprawą Cloudflare”, ale to biblioteka działająca lokalnie, na waszej maszynie, a nie na infrastrukturze dostawcy. A Mario, twórca Pi, zbudował na Pi Durable multiplayerową aplikację agentową, działającą w całości na telefonie z Androidem. W stu procentach na telefonie — z wyjątkiem wywołań modelu, które oczywiście idą w sieć. Sam agent i Pi Durable kręcą się na jego telefonie. Rewelacja.
Od czego zacząć
Jeśli budujecie agentów — zróbcie je trwałymi. Możecie napisać wszystko sami albo wziąć Pi Durable i dostać to wszystko w pakiecie. Jeśli chcecie wpleść to w swój system albo sprawdzić, ile by to kosztowało, zajrzyjcie do README — ale moim zdaniem lepszym miejscem jest folder pełen przykładów. Wskazałem na niego agenta: ma wszystko — reload i restart, nadpisywanie narzędzi, kompakcję, zadania potomne. To zestaw weryfikowalnych przykładów prosto ze źródła, na których można budować. I szczerze: agent zrobił z tym kawał dobrej roboty. Jeśli macie już system agentowy, w opisie filmu zostawiam prompt do skopiowania — wklejcie go swojemu agentowi i zobaczcie, co da się zyskać.
Budujecie agentów jakiegokolwiek rodzaju? Warto to zbadać. Jeśli chcecie więcej o moim osobistym agencie, o setupie albo o samonaprawiającym się oprogramowaniu — dajcie znać w komentarzach, chętnie wejdę głębiej. To naprawdę fajny system i robi się fajniejszy z każdą wersją; sam edytor dokumentów jest, moim zdaniem, wart waszego czasu. Eksperymentuję też z ciekawymi zastosowaniami trwałych agentów w kreatywnych laboratoriach i eksploracjach, a także z botem zespołu Syntax na Slacku. Dajcie znać, co myślicie. Testowaliście Pi Durable? Bo ja uważam, że jest świetne.