O czym jest ten film
- Mario i Armin — twórcy agenta kodowania Pi — wydali Pi Durable: warstwę trwałości, dzięki której sesje, bieżąca praca i stan aplikacji przeżywają awarie, restarty i przeskoki między klientami.
- Autor tłumaczy różnicę między trwałym agentem a zwykłym wznowieniem sesji: trwały agent jest „odłączony” od interfejsu i obsługuje wielu klientów naraz — dokładnie na takich prymitywach budują produkty Anthropic i OpenAI.
- Główna demonstracja: proaktywny agent dyżurny. Tani klasyfikator Jev pilnuje strumienia zdarzeń, wykrywa incydent produkcyjny i sam uruchamia agenta, który przeprowadza pełne postępowanie: detekcja, śledztwo, przyczyna źródłowa, poprawka — człowiek zatwierdza wyłącznie wdrożenie.
- Przykładowa awaria to podręcznikowy błąd: asercja nie-null („!”) w API rabatów lojalnościowych. Agent sam znajduje przyczynę i łatkę, a wdrożenie jest operacją jednorazową, nieodtwarzalną.
- Interfejs „placu zabaw” pokazuje wszystkich agentów ze wszystkich urządzeń autora (dwa Maci mini, MacBook Pro, sandboxy exe.dev), a kompresja kontekstu odbywa się w tle.
- Współdzielony stan aplikacji: jeden obiekt JSON czytany i zapisywany przez wszystkie sesje agentów na danym urządzeniu — podstawa do debugowania wielu agentów naraz.
- Trwałe zadania mają fazy i można je wznawiać od wskazanego kroku, a zatwierdzenia załatwia podagent pytający człowieka — autor nazywa to „człowiekiem obok pętli”.
- Trwałym agentem da się sterować na żywo: zmiana zestawu narzędzi w trakcie sesji (np. tryb tylko do odczytu), rozszerzenia blokujące nieodwracalne komendy, rozwidlanie (fork) kontekstu.
- Główna teza: proaktywne agenty to przyszłość inżynierii. Kluczowy wskaźnik — ilu agentów wykonuje w danym momencie użyteczną pracę bez twojego udziału w ich uruchamianiu.
- Zastrzeżenie praktyczne: Pi Durable jest jeszcze eksperymentalne, więc autor czeka na stabilną wersję, zanim wprowadzi je na własną produkcję.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Agent proaktywny najpierw pracuje, potem czeka
Na czym polega: Proaktywny agent nie czeka na polecenia. Zdarzenie z zewnątrz (tu: wykryty incydent) uruchamia standardową procedurę — detekcja, śledztwo, analiza przyczyny, poprawka — a dopiero na końcu agent staje w miejscu przeznaczonym dla ludzkiej decyzji.
Jak stosować: Podłącz agenta pod strumień logów z produkcji; zdarzenia pasujące do niepokojących wzorców kieruj do niego jako zadania. Człowiek wchodzi wyłącznie na etapie przeglądu i zatwierdzenia wdrożenia.
Na co uważać: Agent musi mieć jasno rozpisaną procedurę i ograniczone uprawnienia. Bez tego „proaktywność” zamienia się w samowolę na produkcji.
2.Trwałość to coś więcej niż /resume
Na czym polega: /resume przywraca rozmowę, ale agent nadal żyje w jednym terminalu. Agent trwały działa we własnym, odłączonym środowisku, a różne klienty — przeglądarka, CLI, curl, telefon — łączą się z nim niezależnie.
Jak stosować: Wystaw agentowi API i traktuj każdy interfejs, swój i użytkowników produktu, jako klienta tego samego agenta. Zamykasz laptopa — agent dalej pracuje i wraca po restarcie od ostatniego punktu kontrolnego.
Na co uważać: Wiele klientów to wiele drzwi. Bez przemyślanej autoryzacji i tokenów wystawiasz agenta na świat.
3.Współdzielony stan aplikacji spina agentów w zespół
Na czym polega: Wszystkie sesje agentów na danym urządzeniu czytają i zapisują jeden wspólny obiekt JSON. Co zapisze jeden agent, drugi widzi natychmiast — nawet w innej sesji.
Jak stosować: Wynoś z rozmowy do stanu aplikacji wszystko, co ma przetrwać: wyniki zadań, znalezione przyczyny awarii, listy do weryfikacji. Dzięki temu debugujesz jeden problem, pracując naraz kilkoma agentami.
Na co uważać: Wspólna szuflada to też wspólne ryzyko pomyłki — ustal konwencję nazw kluczy i kontroluj, kto zapisuje co.
4.Zadania z fazami: wznawiaj od miejsca awarii
Na czym polega: Trwałe zadania (jobs) to powtarzalne operacje — czysty kod albo kod plus agent — podzielone na fazy. Jeśli coś padnie w jednej fazie, powtarzasz tylko ją, nie całość.
Jak stosować: Rozbijaj długie obługi (np. release check wymagający zatwierdzenia) na fazy i osadzaj w nich podagentów, którzy w razie potrzeby pytają człowieka. To „człowiek obok pętli”: obserwujesz przepływ, wchodzisz, gdy trzeba.
Na co uważać: Zbyt drobne fazy mnożą narzut; zbyt grube tracą zaletę wznowienia. Zadania w tle potrzebują też monitorowania statusów (ukończone, przerwane, bieżąca faza).
5.Zestaw narzędzi agenta można zmieniać w trakcie sesji
Na czym polega: Każde wywołanie narzędzia i każdy krok harnessu to osobne zadanie — a zadanie można podmienić. W demie autor przełącza agenta w tryb tylko do odczytu w połowie rozmowy; model nie rozumie, skąd zniknęły narzędzia.
Jak stosować: Zmniejszaj uprawnienia agenta przed ryzykownym etapem (przegląd, praca na cudzym środowisku) i przywracaj je po nim — bez restartowania sesji i utraty kontekstu.
Na co uważać: Nagłe odebranie narzędzi myli model — komunikuj zmianę w rozmowie albo licz na chwilę dezorientacji.
6.Tani klasyfikator jako bezpiecznik harnessu
Na czym polega: Autor dokłada do każdego polecenia powłoki ocenę klasyfikatora (Jev): operacje nieodwracalne, jak rm -rf, zostają zablokowane z pewnością 0,99 — a w razie potrzeby bezpiecznik da się świadomie wyłączyć w trybie podwyższonego ryzyka.
Jak stosować: Postaw micro-model przed wykonaniem destrukcyjnych komend w harnessie agenta. Koszt groszowy, opóźnienie pomijalne, a chroni produkcję przed „kreatywnością” agenta.
Na co uważać: Bezpiecznik bez wyłącznika blokuje pracę. Zostaw świadomą ścieżkę obejścia dla zaufanych operacji — z logowaniem.
7.Fork: rozgałęziaj kontekst i eksperymentuj równolegle
Na czym polega: Polecenie fork tworzy pełne rozwidlenie agenta — z kontekstem, opcjonalnie ze stanem — obok sesji pierwotnej. Można pójść w innym kierunku, zadać boczne pytanie albo testować wariant, nie psując głównej nitki.
Jak stosować: Gdy zgromadzony kontekst jest cenny, a chcesz sprawdzić kilka hipotez — rozwidlij zamiast zaczynać od zera. Razem z kompresją w tle to naturalny sposób zarządzania długimi rozmowami.
Na co uważać: Każdy fork to osobny agent do ogarnięcia — przy dużej liczbie rozwidleń potrzebny rejestr sesji i porządek w nazwach.
8.Wydziel komputer, który należy do agentów
Na czym polega: Autor trzyma agentów na osobnym Macu mini, do którego sam nigdy nie loguje się po to, żeby pracować — to piaskownica należąca wyłącznie do nich. Skoro agent ma pracować jak inżynier, w granicy potrzebuje całego komputera z narzędziami inżyniera.
Jak stosować: Odstaw starego Maca mini albo skorzystaj z chmurowych sandboxów, daj agentom pełne środowisko i izolację — izolacja jest warunkiem bezpiecznej autonomii.
Na co uważać: Pełna autonomia na pełnym komputerze wymaga warstwy bezpieczeństwa z punktu 6 oraz monitoringu, co agent tam wyrabia.
9.Trwałość lepiej mieć na własność
Na czym polega: Autor argumentuje, że oddawanie mechanizmu trwałych agentów na zewnętrzny użytek to ryzyko strategiczne: cudza technologia zmienia się z dnia na dzień (przykłady: Claude Code, Codex), a inteligencję — modele — i tak już bierzemy w dzierżawę.
Jak stosować: Jeśli budujesz poważne przepływy agentowe, opieraj się na rozwiązaniach open source, które możesz kontrolować, rozwidlać i rozszerzać — własny harness to element niezależności zespołu.
Na co uważać: „Własność” oznacza też koszt utrzymania. Wydania eksperymentalne (jak dziś Pi Durable) wymagają decyzji: czekać na stabilną wersję czy utrzymywać własny fork.
10.Mierz, ilu agentów pracuje dla ciebie tu i teraz
Na czym polega: Autor proponuje wskaźnik sukcesu inżyniera agentowego: liczba agentów wykonujących dla ciebie użyteczną pracę w danym momencie — bez tego, żebyś musiał ich uruchamiać. To różnica między mentalnością „odpalam zadania” a „agenty są wplecione w moją pracę i startują same”.
Jak stosować: Przejrzyj tygodniowe obowiązki (dyżury, przeglądy, monitoring) i zamieniaj kolejne czynności na agentów wyzwalanych zdarzeniami. Licznik rośnie — rośnie twoja przepustowość.
Na co uważać: Licznik sam w sobie nic nie znaczy. Liczy się praca użyteczna, więc każdy nowy proaktywny agent potrzebuje metryk jakości i ścieżki eskalacji do człowieka.
Redakcyjne tłumaczenie
Premiera, która ma znaczenie
Cześć, inżynierowie — IndyDevDan. Ten odcinek jest ważny, więc wyłączcie powiadomienia i dajcie sobie chwilę skupienia: może realnie podnieść wasze umiejętności w inżynierii agentowej. Mario i Armin — twórcy i opiekunowie agenta kodowania Pi — wydali właśnie Pi Durable. (Informacja dodatkowa: Armin Ronacher zasłynął jako twórca frameworka Flask; Pi to jego wspólny projekt z Mariem Zechnerem.)
Pi Durable sprawia, że bieżąca praca, rozmowy i stan aplikacji przeżywają awarie, przeskoki między klientami i same zmiany zachodzące w systemie. W tej chwili mam trwałe agenty działające na Macu mini M4, Macu mini M6, MacBooku Pro M5 oraz w chmurowych sandboxach exe.dev. (Informacja dodatkowa: exe.dev to serwis oferujący chmurowe środowiska deweloperskie.)
Zanim je pokażę, trzeba sobie rozprawić z pytaniem: czym właściwie jest trwały agent? Czy nie wystarczy /resume? Dlaczego ta premiera tyle znaczy dla inżynierów agentowych, czyli dla nas? W trakcie odcinka stanie się też jednoznacznie jasne, że Anthropic i OpenAI stawiają produkty — agentów dostępnych choćby przez Slacka — na dokładnie takich prymitywach trwałości i traktują je jako fundament budowania agentów obsługiwanych z wielu klientów naraz.
Na tym kanale trzymamy się blisko fundamentów najważniejszej technologii, jaką inżynier ma dziś w ręku — agentów. Naszą inteligencję, czyli modele, już bierzemy w dzierżawę. Tym bardziej musimy mieć na własność agenty, ich harness — „uprząż”, czyli warstwę kodu, narzędzi i reguł opakowującą model — a teraz także agenty trwałe. Pi Durable jest właśnie tym elementem układanki, zarówno do pracy inżynierskiej, jak i produktowej.
Czym jest trwały agent i czemu nie wystarczy /resume
Zacznijmy od pytania: a gdyby twoje agenty nigdy się nie zatrzymywały? Bo nie chodzi tu wyłącznie o Pi Durable — chodzi o całą kategorię trwałych agentów.
Pi Durable pozwala agentowi Pi przetrwać awarie i dokłada kilka powiązanych możliwości. /resume tylko odtwarza rozmowę, w tym samym terminalu, w tym samym procesie. Agent trwały jest natomiast odłączony: żyje we własnym środowisku, a ty — albo każdy z twoich inżynierów — łączysz się z nim przez jeden lub wielu klientów, kiedy potrzebujesz. Ta różnica zmienia wszystko.
Incydent na żywo: agent dyżurny w akcji
„Dan, twój trwały agent z czerwonego teamu znalazł problem na produkcji i przygotował poprawkę. Czeka na twój przegląd.”
Mój agentowy „czerwony team” (zespół szukający słabości) bezceremonialnie przerywa nagranie. Prosiłem, żeby nie wtrącał się, kiedy nagrywam — skoro przerywa, stało się coś poważnego. Zerkamy do przeglądarki: aplikacja pokazowa, w której na żywo spływa strumień zdarzeń, a klasyfikator Jev wykrył incydent. (Informacja dodatkowa: Jev to opisywany przez autora tani i bardzo szybki model klasyfikujący zdarzenia; w automatycznym transkrypcie nazwa bywa zapisywana różnie.) Wykrycie uruchamia agenta: przekazuje mu opis problemu, miejsce wystąpienia i błąd, a ten otwiera postępowanie incydentowe.
Widzicie dokładnie ten obieg, przez jaki przeszlibyście sami jako dyżurny inżynier: wykrycie, śledztwo, przyczyna źródłowa, poprawka, przedstawienie do przeglądu, wdrożenie. Agent przeszedł standardową procedurę krok po kroku — widać konkretne wywołania narzędzi: aktualizacja incydentu, czytanie logów, odpytywanie o wcześniejsze zdarzenia. Na końcu: poprawka gotowa do wdrożenia.
To agent szczególnego rodzaju — proaktywny. Nie czeka, aż zaczniesz pracować. Najpierw pracuje za ciebie, a dopiero potem czeka. Odrzucam pierwszy wniosek — chcę sam zrozumieć problem, zanim cokolwiek poleci na produkcję. Klikam odświeżenie i… cały stan zostaje na miejscu. Właśnie to znaczy „trwały”.
Co się zepsuło? API nakładające rabaty lojalnościowe przy finalizacji zamówienia, wypuszczone na sto procent ruchu — poważna awaria. Przyczyna: klasyczny, źle napisany null-check. Ktoś użył wykrzyknika. (Informacja dodatkowa: w TypeScript operator „!” to asercja nie-null — obiecuje kompilatorowi, że wartość nie jest nullem, ale niczego nie sprawdza w trakcie wykonania.) Nigdy nie używajcie asercji nie-null: łączcie wartości bezpiecznie albo wyciągajcie je zwykłym, ostrożnym if-em. Jeśli kodujecie dłużej niż dzień, ten błąd znacie na pamięć — i ja go znam.
Problem rozumiem, agent go rozwiązał, nie ma tu nic, co wymagałoby mojego czasu. Zatwierdzam wdrożenie. Dzięki trwałości Pi to wywołanie można wykonać na produkcji tylko raz — operacja jest z natury jednorazowa, nie da się jej przypadkiem odtworzyć ponownie. Produkcja się uspokaja. W międzyczasie Jev sklasyfikował setki nadpływających zdarzeń, płacąc po niecałe półtora centa za decyzję.
Ten agent nie czekał na mnie — i mógłby równie dobrze czekać na każdego z waszych inżynierów, bo każdy z nich jest po prostu klientem odłączonego agenta. Mówię to wprost: to przyszłość naszej branży. Kiedyś większość agentów będzie proaktywna i zbudowana właśnie tak. Najcenniejszy agent to ten, który nie potrzebuje cię do wypuszczenia kodu.
Sieć agentów na jednym ekranie
Przechodzimy do głównego pokazu: plac zabaw sieci agentów trwałych. Z lewej strony widać wszystkich agentów na wszystkich moich urządzeniach — sandboxy deweloperskie, M6, M4 i lokalny MacBook Pro M5. W rdzeniu interfejsu jest pięć zakładek: sesja, stan, zadania, narzędzia i rozszerzenia.
Uruchamiam agenta na M6: model Claude Sonic 5.5, najnowszy na rynku, z niskim poziomem rozumowania — prosto i zwyczajnie. Pierwsza zaleta rzuca się w oczy natychmiast: kompresja kontekstu odbywa się w tle. Jest znacznik kompresji, który można przesuwać; gdy agent go przekroczy, w tle rusza kondensacja historii — sesja zostaje rozdzielona i zagęszczana. Jeśli dojedziemy do rezerwy, agent się zatrzyma; progi można regulować wedle uznania. Przy trwałych agentach wokół waszego produktu i narzędzi dzieje się naraz wiele rzeczy, więc kompresja w tle to nie wygoda, lecz konieczność. Są też klasyczne statystyki i cała paleta poleceń wpisywanych po ukośniku.
Ważna rzecz organizacyjna: moi agenty działają na M6, czyli urządzeniu zbudowanym dla nich — ja sam nigdy na nie nie wchodzę. To klasyczne sandboxowanie. Radzę wam zdobyć jakiś komputer, który agenty mogą posiadać od deski do deski. Jeśli mają pracować jak wy, muszą mieć wasze narzędzia — a w granicy oznacza to po prostu cały komputer.
Stan aplikacji wspólny dla wszystkich sesji
Agent ma narzędzia do czytania i aktualizacji stanu oraz trwały obiekt stanu. Ale to nie jego prywatna szuflada: na M6 widać inne, po prostu trwające sesje trwałych agentów. Każda z nich korzysta z tego samego obiektu. Proszę jednego agenta o zapisanie podsumowania incydentu w stanie aplikacji — renderuje się z tego pełny interfejs z rozebranym na czynniki JSON-em. Przełączam się na innego agenta w tej samej sesji, każę wypisać pary klucz–wartość — i dostaję dokładnie to samo. Jeden współdzielony obiekt JSON dla wszystkich sesji agentów na urządzeniu.
Konsekwencja jest potężna: możesz debugować jeden problem, pracując naraz wieloma agentami przez wspólny stan. W poście premierowym twórcy podkreślają, że trwały ma być przede wszystkim stan aplikacji — samo przetrwanie awarii przez agenta nie wystarczy. Potrzebujesz stanu, który agenty dzielą, aktualizują i na którym mogą współpracować.
Trwałe zadania z fazami — i człowiek obok pętli
Zadania (jobs) to powtarzalne operacje, które agent chce wykonywać. Mogą być czystym kodem, ale prawdziwa dźwignia rodzi się z połączenia kodu z agentem. Przykład: proste zadanie robiące migawkę katalogu roboczego i zapisujące wynik do stanu aplikacji — po jego skończeniu w stanie pojawia się nowy wpis. Zadanie posłużyło do zaktualizowania stanu; pełne kółko się zamyka.
Zadania mają fazy: jeśli coś pójdzie nie tak w jednej z nich, powtarzasz tylko tę fazę, nie całość. Dokumentacja Pi Durable rozbiera to na części bardzo starannie. Duża część przyszłej pracy inżynierskiej będzie się toczyć godzinami i składać z wielu kroków — i właśnie do tego są fazy.
Przykład z dokumentacji: release check wymagający zatwierdzenia. Zamiast klasycznego „człowieka w pętli” — gdy siedzicie w terminalu i musicie obsłużyć każdy krok — uruchamiany jest podagent, który po prostu zadaje wam pytanie. Nazywam to „człowiekiem obok pętli”: nie siedzicie w terminalu, tylko obserwujecie procesy i przepływy, a wchodzicie wtedy, kiedy trzeba — dokładnie jak w demie incydentu, gdzie po rozwiązaniu problemu pojawiacie się wyłącznie po to, by zaakceptować albo odrzucić wdrożenie. Zatwierdzam i kontynuuję: agent wykonuje pracę, odpala testy, aktualizuje stan.
Kolejne zadanie, „change watch”, robi migawkę wyjściową katalogu i pilnuje go w pętli, krążąc w kółko; w każdej chwili można zatrzymać wykonanie. Agent ma też pełny wgląd: każę mu wypisać statusy zadań i widzę, co się ukończyło, co przerwano, na jakiej fazie coś stanęło. Pełna kontrola.
Trwałość trzeba mieć na własność
Na kanale nieustannie powracamy do jednego: chciejcie posiadać swoją technologię. Już samo to, że inteligencję — modele, przez które przepływa dziś wasz kod i algorytmy — bierzemy w dzierżawę, jest niezręczne. Modele lokalne nadchodzą; ledwo Apple wypuści M5 Ultra z 512 GB zunifikowanej pamięci, kupię jedno i pokażę wam liczby. Musimy posiadać inteligencję i każdy inny kawałek technologii agentowej, jaki da się uchwycić. Oddawanie trwałych agentów na zewnętrzny użytek to ogromne ryzyko dla organizacji inżynierskiej: czego nie kontrolujecie, trzymają ręce inne i może się to zmienić z dnia na dzień — wystarczy popatrzeć, jak ewoluują Claude Code i Codex. Agenty umożliwiają inżynierię agentową; jeśli oddacie je firmie, od której zależycie, jesteście od razu w gorszej pozycji. Dlatego tak cenię Pi i całą pracę, którą Mario i Armin w niego wkładają. Pi Durable to kolejny mocny akcent ich inżynierskiego gustu.
Jev: klasyfikacja całego strumienia za grosze
Pozdrowienia dla Jev: przez cały czas pokazu, przy setkach przetworzonych komunikatów, rachunek trzyma się w granicach sześciu centów. Produkt jest, jasne, pokazowy — zdarzenia generuję sztucznie, żeby zademonstrować mechanizm — ale rzucają się w oczy niezawodność, błyskawiczny czas decyzji i groszowy koszt. Wielu inżynierów sądzi, że Jev łatwo podmienić. Spróbujcie odtworzyć ten koszt, tę prędkość i tę niezawodność naraz — i zrozumiecie, dlaczego to narzędzie jest wyjątkowe. Czekam na ich kolejne modele.
Wielu klientów, jeden odłączony agent
Mam sieć trwałych agentów pracujących nad różnymi bazami kodu i różnymi problemami; są proaktywne, czytają strumień logów dzięki Jev. Nie czekają, aż zacznę pracować — pracują, a potem czekają. Ale da się pójść o krok dalej: do odłączonego agenta można łączyć się wieloma klientami naraz.
Jak to dziś wygląda u przeciętnego inżyniera? Siedzi w terminalu i przerzuca się promptami z agentem w interfejsie tekstowym, wszystko lokalnie. Ubezpieczam was: następny etap tak nie będzie wyglądał. Trzecia faza inżynierii agentowej to systemy pracujące bez was — a Pi Durable to kluczowy element tej układanki.
Schodzę więc do konkretu. Otwieram terminal; wszystkie komendy trzymam w just, żeby móc opuścić poziom aplikacji i zejść do warstwy, którą da się precyzyjnie sterować. Sprawdzam sieć i identyfikatory — to wszystkie ID mojej sieci agentów trwałych. Łączę się z EXC 2, sandboxem w chmurze: polecenie attach, wklejam identyfikator i… witajcie, te same sesje agentów. Powiem to bardzo wyraźnie: odłączyłem agentów od mojego interfejsu. Wiele klientów, jeden agent.
Po co komu wiele klientów? Wyobraźcie sobie klasycznego bota supportowego, który chcecie doprowadzić do perfekcji. Pilnujecie, czy brzmi ludzko, czy dobrze komunikuje, czy realnie odciąża zespół supportu przy tysiącach użytkownikach dziennie. Bot działa na waszej stronie, a wy dodatkowo macie interfejs — przeglądarkowy albo terminalowy — do podglądu tego samego agenta.
Tworzę nową sesję T002 w terminalu — i patrzcie na lewy panel w przeglądarce: nowy agent pojawił się tam w tej samej chwili. Bo te interfejsy to tylko klienci: moi agenty tu nie mieszkają — są w chmurze, w sandboxach, odizolowane, bezpieczne i z dużą autonomią. Hierarchia ma trzy poziomy: urządzenie, przestrzeń robocza, agent — i podpiąć się można z dowolnego urządzenia.
Pomyślcie o własnej aplikacji: otwieracie telefon i jesteście połączeni ze swoim agentem. Właśnie tam chcecie użyć agenta trwałego, a nie instancji przyklejonej do jednego okna — domyślnego agenta Pi, Claude Code czy Codexa. Wielkim laboratoriom trzeba oddać sprawiedliwość: już ruszyły w tę stronę. Claude jest dziś dostępny na desktopie, w telefonie, w aplikacjach biurowych — i dokładnie tak to robią: trwały agent działający w kontrolowanym środowisku, do którego podpięto klienty.
Narzędzia można zmieniać w locie
Każę agentowi wypisać narzędzia: podagenty, przeszukiwanie kontekstu, sprawdzanie zadań trwałych, stan aplikacji i klasyka. W dokumentacji Pi napisano wprost: wszystko, co robi harness — od wywołania modelu po wykonanie narzędzia — jest zadaniem. A zadanie ma szczególną właściwość: można je zmieniać.
Przełączam agenta w tryb tylko do odczytu — w połowie sesji. Proszę o listę narzędzi raz jeszcze, tym razem z przeglądarki. Zestaw się zmienił, a agent sam się gubi: „poprzednia lista była błędna, zawierała narzędzia, których nie mam”. Nie, przyjacielu, to ja zmieniłem ci zestaw narzędzi w trakcie rozmowy. Dla modeli to nowość — nie zdarzyło im się tracić narzędzia w środku sesji. A to potężna zdolność: w locie można zmieniać praktycznie każdą cechę trwałego agenta, w przeciwieństwie do klasycznej sesji, którą się odpala i taką już ma. W zestawie są m.in. polecenia listowania i sprawdzania zadań trwałych oraz handoff — przejście na świeży kontekst modelu, w duchu omawianej na kanale samokompresji. Można też przyglądać się argumentom każdego wywołania narzędzia.
Rozszerzenia: od gadatliwości Opusa do blokady rm -rf
Pi ma rozszerzenia i działają one również w wersji trwałej. Włączam dwa omawiane wcześniej na kanale. Pierwszy, „fix smartass Opus”, narodził się, gdy ręcznie inżynierowaliśmy prompt systemowy Opusa 5 — dla agentów rozwlekłych, które ciągają rozmowę w nieskończoność; gadatliwość uśmierzyliśmy promptem. Drugi to Jev damage control, jeden z dziesięciu poziomów Jev, którym poświęciliśmy osobny, bardzo popularny odcinek: tani, niezawodny klasyfikator osądzający każde polecenie bash.
Dla potwierdzenia, że rozszerzenie siedzi w systemie, każę agentowi pokazać swój prompt: pięć części — rola, narzędzia, komunikacja, granice operacyjne i aliasy. Używam aliasu SCR i agent natychmiast kondensuje odpowiedź. Teraz test bezpiecznika: ls, potem rm -rf na katalog — i dostaję blokadę: harness wstrzymał wykonanie, bo usunięcie jest nieodwracalne; pewność klasyfikatora: 0,99. Chcąc, mogę wejść w tryb podwyższonego ryzyka, wyłączyć bezpiecznik, a nawet cały prompt systemowy, i ponowić polecenie — wtedy przechodzi. Właśnie na żywo przerobiłem trwałemu agentowi konfigurację: raz bezpiecznik, raz nie.
Fork: rozwidlenie kontekstu
Jest też polecenie fork — pełne rozwidlenie agenta. Na sandboxu exe.dev powstaje kolejna warstwa: agent rozwidlony obok pierwotnego. Chcesz pójść w innym kierunku, zadać proste pytanie, sprawdzić wariant — rozwidlasz kontekst i eksperymentujesz równolegle, zwłaszcza gdy zgromadzona historia rozmowy jest dokładnie tym, czego potrzebujesz w tym momencie. Można forkować razem ze stanem, zacząć od świeżej rozmowy albo rozwidlić w dowolnym punkcie. To nie doklejka — jest wpisane w strukturę Pi Durable.
Inżynieria harnessu wyższego poziomu
Układając to wszystko w całość: agenty na własnych urządzeniach, skalujące się bezpiecznie dzięki izolacji, z autonomią zdobytą właśnie przez tę izolację, wyposażone w nasze narzędzia — a wokół nich warstwa agentowej infrastruktury. To jest zaawansowana inżynieria harnessu: myślimy o tym, gdzie dokładnie przebiega uprząż, i opakowujemy ją w kolejne warstwy — urządzenia, narzędzia, rozszerzenia — tak by zadania wykonywały się powtarzalnie i dały się wznawiać.
I proszę: kolejny incydent — ostrzeżenie o anomalii w API koszyka. Agenty proaktywne są dostępne już teraz i namawiam was, żebyście zaczęli je budować.
Gust ponad kod — uznanie dla twórców Pi
Wielkie uznanie dla Armina i Maria. Kod potrafi dziś wygenerować każdy — inżynierem oprogramowania nie każdy. To, co napisali, to kilkanaście tysięcy linii TypeScriptu (sam autor nie pamięta dokładnie: dziesięć czy piętnaście). Skoro kod jest taki tani, czemu ten produkt ma szansę trafić do dziesiątek, może setek tysięcy inżynierów, mnie włącznie? Bo ta premiera to popis gustu, osądu i podejmowania decyzji — a na tym właśnie polega inżynieria oprogramowania. Pisanie kodu, szczerze mówiąc, zawsze było dla większości z nas najłatwiejszą częścią pracy. Najtrudniejsze jest wiedzieć, co w ogóle jest warte zrobienia. Łatwo skopiować cudzy zmyślny model czy produkt; dużo trudniej odciąć wszystko poza jednym czy dwoma elementami, o których własna ekspertyza podpowiada: to się naprawdę liczy, to jest produkt, to jest wartość. Taki jest Pi, taki jest Pi Durable. Czekam na stabilną wersję 1.0 — dziś wydanie jest eksperymentalne, więc nie wdrożę go na własnej produkcji, chyba że chciałbym rozwidlić projekt i utrzymywać własną kopię, a tego nie chcę.
Pięć powodów, by przejść na trwałe agenty
Po pierwsze — agenty proaktywne. Na ich przyszłość stawiam wszystko, co mam; cały mój produkt trzeciej fazy wyrasta z tej idei, a słowo „proaktywny” i tak nie oddaje całej wizji. Chcesz, żeby agenty zaczynały pracę bez ciebie, żebyś przychodził do gotowego. W skrajnej postaci to inżynieria bez dotykania (zero touch engineering): wszystko zrobione, ty przeglądasz tylko „jak” i od czasu do czasu prostujesz to, co agent wypuścił — reszta pójdzie gładko. Demo przed chwilą to gotowy wzorzec: podstaw go pod swoje logi produkcyjne i postaw Jev na czele strumienia. Przez niespełna godzinę nagrania klasyfikacja całego strumienia, wykrywanie awarii i uruchomienie agenta incydentowego kosztowały 13 centów. Coraz więcej pracy wcale nie wymaga waszego udziału — jeśli zainwestujecie w agenty, w inżynierię harnessu, w narzędzie w pełni kontrolowane: otwarte, rozszerzalne, wasze. Nie mam sponsorów i nie przyjmuję — jedyną rzeczą, którą na tym kanale sprzedaję, są moje własne produkty, robione ręcznie dla dobrych, doświadczonych inżynierów wypuszczających kod na produkcję. Zeszłego roku ludzie byli pewni, że promuję Claude Code, na długo zanim stał się mainstreamem; dziś mówię o Pi. Dlaczego? Bo chodzi o kontrolę nad najważniejszą technologią dostępną dziś inżynierowi — agentem. A kontroluje się go harnessem, najlepiej takim, który sam jesteś w stanie kontrolować.
Zresztą, jeśli jesteście zaawansowani, pewnie już teraz pozwalacie agentom wypuszczać kod na produkcję. W demie incydentu ja sam nie wniósłem właściwie nic — dodałem tylko zbędny z konieczności przegląd bezpieczeństwa. W kodowaniu agentowym są dokładnie dwa wąskie gardła: planowanie i przegląd. Oba są dziś rozwiązywalne — niezależnie od Pi Durable, po prostu przez solidne fundamenty: promptowanie, kontekst, inżynierię harnessu.
Po drugie — agenty wieloklientowe. Gdy raz wystawisz agentowi API, do pracy inżynierskiej i do produktu, dostajesz jedno API i dowolną liczbę interfejsów: przeglądarka, własny wiersz poleceń, zwykły curl. „Oto API do moich urządzeń i trwałych agentów: uruchom ich, rozwiąż te problemy.” Z porządną autoryzacją i tokenami dochodzi telefon i wasz produkt — bo nie zapominajmy, że to wszystko jest ostatecznie dla użytkowników i budowanych produktów. Interfejsy w przeglądarce dla firmy i klientów, a obok nich agenty inżynierskie, które żadnego interfejsu nie potrzebują i po prostu pracują w tle.
Po trzecie — agenty wielosobowe: do tego samego agenta incydentowego mogą się podpiąć współpracownicy; kilku dyżurnych przegląda razem logi i razem prompuje agentów. To dziś modny temat wielkich laboratoriów, ale mnie multiplayer obchodzi mniej.
Waży się dla mnie czwarta rzecz: agenty długotrwałe. Zamykasz laptopa, odświeżasz stronę, ubijasz proces, restartujesz maszynę — agenty wracają i kontynuują od ostatniego punktu kontrolnego. Agent rozwidlony, pierwotny, główny — każdy na własnym sandboxie, nad własnym produktem. Przetestujcie to koniecznie sami: przerwijcie agentowi w pół kroku i zobaczcie, że wraca do roboty.
I po piąte — człowiek obok pętli. Wiem, że trudno przeskoczyć od razu z „w pętli” do „poza pętlą”, jeśli latami siedziało się w terminalu. To proces; inżynieria agentowa to nowa umiejętność, nie coś, co się bierze do ręki i od razu robi. Trwałe agenty odblokowują etap pośredni: zatwierdzasz przepływy, zatwierdzasz wdrożenia, robisz odrobinę przeglądu — i pozostajesz przy sterach tego, co leci na produkcję.
Jak autor to wdraża u siebie
U mnie zasada jest prosta: wszelka praca produktowa od teraz domyślnie biegnie na agentach trwałych. Najprostszy przykład — chatbot supportowy na stronie. Nie ma żadnego powodu, żeby nie był trwałym agentem Pi: użytkownik wraca do swojej sesji, wy czyścicie ją po sześciu godzinach, rządzacie nią, jak chcecie.
Poza tym mocno inwestuję w agenty proaktywne. Agent przyszłości nie czeka, aż poprosisz go o pracę — zaczyna pracować, a potem czeka na twoją akceptację; z czasem to on zaczyna pierwszy do ciebie pisać. To kontynuacja nurtu, który ciągniemy na kanale nieustannie: wyjdź z pętli. Ta idea jest osią kursu „Tactical Agentic Coding” (druga faza), a trzecia fazaOnly ją spotęguje. Im więcej pracy agenty odwalą bez ciebie, tym bardziej jesteś inżynierem agentowym, a nie tylko kimś, kto koduje z pomocą agenta. Nie chodzi o niańczenie agentów — chodzi o to, żeby pracowały bez ciebie.
Wskaźnik na koniec: ilu agentów pracuje dla ciebie?
Wszystko podlinkowano w opisie: demo sieci, demo agenta proaktywnego i dokumentacja. Własne urządzenia trzeba sobie dołożyć samodzielnie, ale to proste — zadbam, żeby instrukcje były jednoznaczne dla was i dla waszych agentów. To szablon, nie wyrocznia: jeśli wolicie, pomińcie Jev i filtrujcie wyłącznie błędy 4XX i 5XX albo róbcie prosty monitoring statusów. Sześć tysięcy zdarzeń, szesnaście centów — i to dopiero początek. Korzystajcie z tej okazji, dopóki proaktywne agenty nie stały się normą, bo kiedyś takie będą. Informacja, na którą nie reagujesz, jest nic nie warta — proszę, zróbcie z niej użytek.
Polecam każdemu inżynierowi agentowemu jeden wskaźnik: ilu agentów wykonuje dla ciebie w tej chwili użyteczną pracę? Nie chodzi o to, że siadasz i odpalasz zadania — to mentalność drugiej fazy, w której za każdy start odpowiadasz ty. Myślcie trzecią fazą: agenty, które startują bez ciebie, wplecione w strukturę twojej pracy. Trwałe agenty podnoszą ten licznik — w pętli, obok pętli i poza nią. U progu 2027 roku kluczem będzie przejście z „w” w „poza”. A raz wskoczysz na tę ścieżkę, będziesz skakać dalej — podwójnie, potrójnie, bez końca.
Zaczynajcie od dema Pi Durable. Pozdrowienia dla Maria i Armina oraz dla każdego, kto dotrwał do końca. Jeśli się czegoś nauczyliście — łapka w górę i subskrypcja; nowy odcinek co poniedziałek. Trzymajcie fokus i budujcie.