Twoi agenci zostawiają po sobie procesy.
AgentsRoom je znajduje.
Agent AI uruchamia prawdziwy proces systemowy przy każdym wywołaniu narzędzia. Większość kończy się w kilka sekund. Niektóre nigdy, i to one trzymają gigabajty pamięci, nie zużywając ani odrobiny CPU.
Strażnik przeczesuje procesy potomne Twoich agentów, oznacza te, które przestały robić postępy, wskazuje odpowiedzialnego agenta i pozwala Ci zakończyć je jednym kliknięciem. Nic nie jest zabijane za Twoimi plecami.
Na co strażnik naprawdę patrzy: na procesy uruchomione przez jednego agenta i na to, które z nich przestały pracować.
Agent AI to nie jeden proces. Każde wywołanie narzędzia uruchamia na Twojej maszynie prawdziwy proces: wyszukiwanie, build, sprawdzenie typów, przebieg testów, skrypt. Pomnóż to przez kilku agentów pracujących równolegle, przez cały dzień, a dostaniesz setki procesów, które rodzą się i giną, a Ty nie zobaczysz ani jednego.
Prawie wszystkie się kończą. Problemem są te, które się nie kończą. Wyszukiwanie, którego wzorzec rozsadza silnik wyrażeń regularnych, nie wysypuje się i nie zwalnia: alokuje pamięć, ląduje w pamięci skompresowanej, a potem spędza resztę życia na błędach stron przy 4% CPU. Nigdy się nie skończy. Nic go nigdy nie zabije. A jeśli zamkniesz agenta, który go uruchomił, proces zostaje przypisany do procesu init i staje się sierotą, za którą nikt na maszynie już nie odpowiada.
Dlatego spowolnienie wkrada się po cichu. Nie ma jednego dramatycznego momentu, jest powolna kumulacja przez cały dzień pracy, a to dokładnie ten kształt, przez który ludzie obwiniają nie to, co trzeba: przegrzewanie, zbyt wielu agentów, wyciek pamięci w aplikacji. W sesji, którą zmierzyliśmy, sama aplikacja zajmowała 2,8 GB w 91 procesach, a osiem CLI agentów 1,6 GB łącznie. Żadne z nich nie było problemem.
Strażnik procesów jest siatką bezpieczeństwa. Pilnuje tego, co agenci zostawiają po sobie, mówi Ci, który proces się zawiesił i kto go uruchomił, i pozwala go zakończyć. Przyczyny źródłowe będą się dalej zmieniać: inne narzędzie, inny wzorzec, inny dostawca. Siatka nie musi się zmieniać.
Dlaczego maszyna z agentami AI zwalnia
Liczby poniżej pochodzą z jednej zmierzonej sesji na laptopie z 16 GB, na którym pracowało ośmiu agentów. Nic tu nie jest szacunkiem.
Maszyna działała od pięciu i pół godziny. Żadnego problemu termicznego: brak zarejestrowanego throttlingu, bateria przy 30,6 °C. Load average wynosił od 17 do 21 na 8 rdzeniach, a CPU spędzał 56% czasu w jądrze przy 1,5% bezczynności. To ta proporcja wszystko zdradza. Maszyna, która naprawdę pracuje, spędza czas w kodzie użytkownika; maszyna z 56% czasu systemowego to jądro, które nie robi nic poza kompresowaniem, dekompresowaniem i przerzucaniem pamięci do swapu.
Siedem zawieszonych procesów wyszukiwania trzymało po 3,9 do 8,0 GB każdy, łącznie 41,8 GB na maszynie z 16 GB RAM. Swap był na 22,3 GB z 23,5, a od startu systemu zapisano do niego około 993 GB. Zakończenie tych siedmiu procesów natychmiast oddało 15,5 GB, bez restartowania choćby jednego agenta i bez restartowania aplikacji.
Nikt nie wyłapuje tego ręcznie, bo zwykłe narzędzia kłamią na ten temat. Na macOS zawieszony proces może pokazywać 20 MB pamięci rezydentnej, trzymając w rzeczywistości 8 GB, bo wszystko, czego dotknął, przeszło przez kompresor pamięci. Zmierzyliśmy jeden na żywo: 4,7 GB rezydentnej przy rzeczywistym śladzie 14 GB. Rozmiar wirtualny też nie pomaga: na tej platformie nawet launchd raportuje około 440 GB rozmiaru wirtualnego, więc filtrowanie po nim oznacza całą maszynę.
Ta sama sesja, godzina po godzinie: bloki pamięci, których nikt już nie używa, i to, co się dzieje, gdy zostaną zwolnione.
A te procesy mają cztery właściwości, które gwarantują, że jutro nadal tu będą.
Nigdy się nie kończą
Ich własna pamięć jest w swapie, więc spędzają czas na błędach stron zamiast liczyć. Zdrowe wyszukiwanie wysyca rdzeń; te siedzą na 4%. Z tej spirali nie ma wyjścia, a czekanie nic nie daje.
Nigdy nie umierają
Wywołanie narzędzia nie ma limitu czasu. Nic na maszynie nie ma zdania o procesie, który od pięćdziesięciu minut nic nie robi. Będzie tam siedział, dopóki ktoś go nie zabije albo maszyna się nie zrestartuje.
Przeżywają swojego agenta
Zamknij kartę agenta, a proces może przetrwać, przypisany do procesu init. Od tego momentu nic go już z niczym nie łączy: to sierota i nikt go już nigdy nie posprząta. Dwa z siedmiu, które zmierzyliśmy, były już w tym stanie.
Kumulują się
Jeden na przebieg weryfikacji, jeden na pechowe wyszukiwanie. Dlatego spowolnienie przez cały dzień tylko rośnie i dlatego restart wydaje się je naprawiać. Nic nie naprawia, tylko zeruje licznik.
Co robi strażnik procesów
Pilnuje procesów uruchamianych przez Twoich agentów i jest celowo bardzo wąski w tym, czego dotyka.
Mierzy rzeczywistą pamięć
Nie rozmiar rezydentny, który zaniża zawieszony proces o gigabajty. Strażnik czyta rzeczywisty ślad pamięciowy, ze stronami skompresowanymi i wyrzuconymi do swapu włącznie, więc proces pokazujący 20 MB i trzymający 8 GB jest widziany takim, jaki jest.
Patrzy na CPU, nie tylko na RAM
Sama pamięć oznaczałaby każdy build na Twojej maszynie. Strażnik mierzy użycie procesora jako tempo między dwoma skanami, więc proces, który ciężko pracował, a potem się zawiesił, i tak zostanie złapany, a build, który naprawdę pracuje, zostaje w spokoju.
Łapie procesy osierocone
Proces, który przeżył agenta uruchamiającego go, jest zgłaszany sam z siebie, bo nikt inny go już nie posprząta. Właściciel jest zapamiętywany, dopóki proces jest jeszcze podpięty, bo to jedyny moment, w którym da się go ustalić.
Jedno kliknięcie, żeby zakończyć
Plakietka na pasku stanu wypisuje każdy zawieszony proces razem z agentem, który go uruchomił, jego pamięcią, wiekiem i CPU. Zakończenie jednego zamyka go wraz ze wszystkim, co sam odpalił. Pamięć wraca natychmiast, a Twoi agenci działają dalej.
macOS, Windows i Linux
Każdy system wymaga innego pomiaru, żeby powiedzieć prawdę o pamięci: strony skompresowane na macOS, pamięć rezydentna plus swap w systemie Linux, private commit w systemie Windows. Wszystkie trzy są zaimplementowane, nie zaplanowane.
Kosztuje prawie nic
Jedna migawka procesów na minutę, zmierzona na około 40 ms na maszynie z 824 działającymi procesami. Kosztowny pomiar pamięci uruchamia się tylko wtedy, gdy coś już wygląda na zawieszone, a gdy żaden agent nie jest aktywny, nie działa żaden skan.
Zasada, która nie pozwala mu wszczynać fałszywych alarmów
Strażnik, który oznacza Twoje buildy, to strażnik, którego wyłączysz w tydzień. Dlatego proces nigdy nie jest zgłaszany na podstawie samej pamięci. Musi być duży, musi żyć już jakiś czas i musi przestać używać procesora. Wszystko naraz.
To trzeci warunek wykonuje całą pracę. Sprawdzanie typów albo bundler też trzymają gigabajty przez kilka minut, ale przy tym wysycają rdzeń. Proces uwięziony w swapie kręci się w okolicach 4%, bo spędza życie na czekaniu na błędy stron zamiast na liczeniu. Ta różnica oddziela maszynę, która pracuje, od maszyny, która tonie, i jest jedynym sygnałem, który oddziela je w sposób pewny.
Użycie procesora jest zresztą mierzone, a nie odczytywane. Liczba, którą podaje typowe narzędzie systemowe, to średnia z całego życia procesu, i wciąż wygląda na zajętość przy czymś, co pracowało dwadzieścia minut, a potem się zawiesiło. Strażnik porównuje zużyty czas procesora między dwoma skanami, więc widzi ostatnią minutę, a nie ostatnią godzinę.
Jak to działa
Cztery kroki, raz na minutę, a ten kosztowny prawie nigdy się nie uruchamia.
Jedna tania migawka maszyny
Co minutę strażnik robi jedną migawkę wszystkich działających procesów i przechodzi drzewo pod każdym terminalem agenta. Zmierzony koszt na maszynie z 824 działającymi procesami: około 40 ms. Dopóki żaden agent nie działa, w ogóle się to nie dzieje.
Wyłonić podejrzanych
Z tej migawki zostawia tylko procesy potomne agentów, które żyją dłużej niż Twój próg i nie używają już procesora. W normalnym użyciu ta lista jest pusta i wszystko kończy się tutaj.
Zmierzyć te, które wyglądają na zawieszone
Tylko za tę krótką listę strażnik płaci rzeczywistym pomiarem pamięci, ze stronami skompresowanymi i wyrzuconymi do swapu włącznie. Proces, którego nie da się zmierzyć, nigdy nie jest oznaczany: niewiadoma to nie wyrok.
Zgłosić i zostawić decyzję Tobie
Na pasku stanu pojawia się plakietka, a jedno powiadomienie mówi Ci o tym raz. Otwierasz listę, widzisz, czym jest ten proces, ile trzyma, od jak dawna jest zawieszony i który agent go uruchomił, i kończysz go, jeśli chcesz.
Czego nigdy nie tknie
Narzędzie, które potrafi kończyć procesy, musi być wąskie w tym, co uznaje za swoją sprawę. Te granice są strukturalne, a nie są opcjami, o których włączeniu trzeba pamiętać.
- Samo CLI agenta. Niezależnie od tego, jakiego dostawcę uruchamiasz, strażnik chroni plik binarny, którym aplikacja uruchomiła ten terminal. Czyta tę nazwę z samego uruchomienia, a nie z listy zapisanej na sztywno, więc podproces tego samego CLI też jest chroniony, na dowolnej głębokości.
- Twoje terminale z komendami dev. Bezczynny serwer dev spełnia wszystkie kryteria zawieszonego procesu: gruby, stary, zero użycia procesora. Jest też dokładnie tym procesem, który chcesz widzieć w działaniu. Pilnowane są tylko terminale agentów, więc Twój serwer dev nigdy nie wchodzi w grę.
- Powłoka i wewnętrzna instalacja samej aplikacji. Helper terminala i powłoka, w której działa agent, są wykluczone z założenia. Kandydatami są wyłącznie procesy narzędzi znajdujące się pod CLI agenta.
- Wszystko, czego sam nie przygarnął. Jedyna ścieżka, która potrafi zakończyć proces, odrzuca każdy proces, którego strażnik nie podniósł z drzewa jakiegoś agenta. Nie może się stać sposobem na zamykanie czegokolwiek innego na Twojej maszynie.
I nic nie jest kończone automatycznie, dopóki o to nie poprosisz. Domyślnie strażnik zgłasza to, co znalazł, a Ty decydujesz, bo to Ty wiesz, czy duży, cichy proces był spodziewany.
Kiedy zarabia na swoje miejsce
Każda z tych sytuacji jest prawdziwa, żadna nie jest hipotetyczna.
Maszyna wolniejsza o 18 niż o 9 rano
Nie ma jednego momentu, w którym coś się zepsuło, jest tylko równy zjazd przez cały dzień. Ten kształt to niemal zawsze nagromadzone zawieszone procesy i najtrudniej go zdiagnozować ręcznie, bo w żadnej pojedynczej chwili nic nie wygląda źle.
Kilku agentów pracujących równolegle
Im więcej agentów uruchamiasz, tym więcej wywołań narzędzi się dzieje i tym większa szansa, że jedno się zawiesi. Odsetek awarii na wywołanie jest znikomy; pomnożony przez dzień równoległej pracy przestaje być znikomy.
Wyszukiwanie, które nigdy nie wraca
Wzorzec, który rozsadza silnik wyrażeń regularnych, alokuje gigabajty na pliku o rozmiarze kilkuset kilobajtów. Agent czeka na nie, Ty czekasz na agenta, a maszyna płaci za obu.
Zamknąłeś agenta, proces został
Zamknięcie karty nie zawsze cokolwiek zwalnia. Proces, który był już odłączony, zachowuje swoją pamięć i traci ostatnie połączenie z czymkolwiek, co widzisz w aplikacji.
Laptop z 16 GB
Na maszynie z dużą ilością RAM kilka zawieszonych procesów potrafi ukrywać się bardzo długo. Na laptopie z 16 GB szybko dobijają do swapu, a gdy system zaczyna kompresować pamięć, każdy agent zwalnia w tym samym momencie.
Zanim obwinisz aplikację
Kiedy maszyna się wlecze przy otwartym AgentsRoom, aplikacja jest oczywistym podejrzanym. Prawdziwe liczby, proces po procesie, z agentem, który uruchomił każdy z nich, zamieniają podejrzenie w coś, co da się sprawdzić.
To Ty ustalasz granice
Wartości domyślne są celowo ostrożne. Wszystko poniżej znajdziesz w ustawieniach, w zakładce Terminal, a każde z tych ustawień może też odczytać i zmienić agent przez narzędzia MCP AgentsRoom.
- Pilnuj procesów potomnych agentów
- Domyślnie włączone. Wyłącz je, a żaden skan już nigdy nie ruszy.
- Zgłaszaj powyżej progu pamięci
- Domyślnie dwa gigabajty. Poniżej tej wartości zawieszony proces nie jest wart przerywania Ci pracy. Podnieś próg na stacji roboczej z dużą ilością RAM, obniż go na laptopie, gdzie pamięci jest mało.
- Po minimalnym czasie życia
- Domyślnie pięć minut. To właśnie chroni wolne, ale uzasadnione zadanie przed oznaczeniem, bo prawie nic, na czym naprawdę Ci zależy, nie trwa pięciu minut bez użycia procesora.
- Kończ zawieszone procesy automatycznie
- Domyślnie wyłączone i jest to świadoma decyzja produktowa, a nie ostrożność. Strażnik wydaje osąd, a tylko Ty wiesz, czy duży, cichy proces był spodziewany. Włącz to, a zacznie działać sam, z powiadomieniem po fakcie.
Próg procesora nie jest wystawiony, i to celowo. To pomiar, który oddziela pracujący build od zawieszonego procesu, i nie jest to kwestia gustu.
Najczęściej zadawane pytania
Czy to znaczy, że AgentsRoom spowalnia mój komputer?
Nie, i właśnie dlatego ta funkcja istnieje. W zmierzonej przez nas sesji aplikacja zajmowała 2,8 GB w 91 procesach, a osiem CLI agentów 1,6 GB łącznie. Te 41,8 GB trzymały procesy narzędzi, które się zawiesiły. AgentsRoom jest akurat jedynym miejscem, z którego widać każdego agenta i każdy uruchomiony przez niego proces, więc jedynym miejscem, z którego można to rozstrzygnąć.
Czy zabije mój build albo przebieg testów?
Nie. Proces jest oznaczany tylko wtedy, gdy jest duży I stary I przestał używać procesora. Build, który naprawdę pracuje, wysyca rdzeń, więc nie spełnia trzeciego warunku i nigdy nie jest kandydatem. Ten warunek istnieje właśnie po to, żeby zrobić to rozróżnienie.
Czy pilnuje mojego serwera dev?
Nie i nigdy nie będzie. Bezczynny serwer dev spełnia wszystkie kryteria: trzyma dużo pamięci, działa od godzin i między żądaniami nie używa procesora. Pilnowane są tylko procesy potomne terminali agentów, więc Twoje komendy dev są poza zakresem z założenia.
Czy może zakończyć samego agenta?
Nie. CLI agenta jest chronione niezależnie od dostawcy, a ochrona opiera się na pliku binarnym, którym aplikacja uruchomiła ten terminal, a nie na liście znanych nazw. Powłoka i helper terminala samej aplikacji też są wykluczone.
Czym jest proces osierocony i dlaczego traktuje się go osobno?
Proces, którego rodzic się zakończył, zostaje przypisany do systemowego procesu init. Od tej chwili nic go już nie łączy z agentem, który go uruchomił, więc nikt go nigdy nie posprząta. AgentsRoom zapamiętuje właściciela, dopóki proces jest jeszcze podpięty, bo to jedyny moment, w którym da się to ustalić, i dzięki temu potrafi zgłosić go także później.
Ile kosztuje samo pilnowanie?
Jedna migawka procesów na minutę, zmierzona na około 40 ms na maszynie z 824 działającymi procesami. Droższy pomiar pamięci uruchamia się tylko na procesach, które już wyglądają na zawieszone, co w normalnym użyciu oznacza, że się nie uruchamia. A skan w ogóle nie istnieje, dopóki żaden agent nie jest aktywny.
Dlaczego nie wystarczy spojrzeć na kolumnę pamięci w Monitorze aktywności?
Bo na macOS zaniża ona problem o rząd wielkości. Proces wepchnięty do pamięci skompresowanej może pokazywać 20 MB rezydentnej, trzymając 8 GB. Zmierzyliśmy jeden na żywo: 4,7 GB rezydentnej przy rzeczywistym śladzie 14 GB. Rozmiar wirtualny nie jest lepszy: nawet procesy systemowe raportują go w setkach gigabajtów.
Czy działa z Claude Code, Codex i resztą?
Tak. Strażnik nie wie nic o żadnym konkretnym narzędziu ani dostawcy. Pilnuje procesów potomnych dowolnego terminala agenta, który uruchomiłeś, a chronione CLI odczytuje z samego uruchomienia. Dodanie dostawcy nic tu nie zmienia.
Czy działa w systemach Windows i Linux?
Tak. Każda platforma wymaga innego pomiaru, żeby pamięć była podana uczciwie: strony skompresowane na macOS, pamięć rezydentna plus wyrzucona do swapu w systemie Linux, private commit w systemie Windows. Wszystkie trzy są zaimplementowane.
Czy zakończy procesy bez pytania mnie o zdanie?
Nie, chyba że sam to włączysz. Domyślnie zgłasza to, co znalazł, razem z agentem, pamięcią, wiekiem i użyciem procesora, a Ty decydujesz. Automatyczne kończenie to ustawienie, wyłączone zaraz po instalacji.
Co dzieje się z agentem, gdy zakończę jeden z jego procesów?
Agent działa dalej. Jego wywołanie narzędzia dostaje błąd zamiast wisieć w nieskończoność, i to jest dokładnie ten wynik, o który Ci chodzi: ten proces i tak nigdy by się nie skończył. Nic nie jest restartowane i żaden kontekst nie ginie.
Czy to naprawia przyczynę źródłową?
Nie i nawet nie próbuje. Przyczyny się zmieniają: dziś jedno narzędzie, jutro inny wzorzec, za miesiąc inny dostawca. To siatka bezpieczeństwa, zaprojektowana tak, żeby działać dalej, gdy przyczyną okaże się coś, czego nikt jeszcze nie widział.
Może Cię też zainteresować
Kanarek kontekstu
Drugie wczesne ostrzeżenie: pilnuje kontekstu samego agenta zamiast maszyny i mówi Ci, że agent dryfuje, zanim zacznie wymyślać pliki i API.
Terminale dev
Uruchamiaj swoje serwery dev i długie komendy w AgentsRoom, z powiadomieniem, gdy długa komenda się skończy. To dokładnie te terminale, których strażnik procesów z założenia nigdy nie tyka.
Śledzenie statusu agentów
Zobacz na pierwszy rzut oka, którzy agenci pracują, którzy czekają na Ciebie, a którzy są bezczynni, bez czytania choćby jednego terminala.
Zużycie tokenów
Drugi zasób, który warto mieć na oku. Zużycie tokenów i limit dla każdego agenta, żebyś wiedział, gdzie ucieka Twoje wykorzystanie.
Widok podzielony
Kilku agentów obok siebie w jednym oknie, każdy z własnym panelem, kolorem i statusem na żywo.
CLI Doctor
Gdy agent nie potrafi wystartować, mówi Ci dlaczego i co z tym zrobić, zamiast zostawiać pusty terminal.
Przestań płacić za procesy, których nikt nie używa
AgentsRoom pobierzesz za darmo, a strażnik procesów działa od pierwszego uruchomienia.
Aplikacja towarzyszaca: monitoruj agentów w podrozy
Użyj Claude, Codex, Antigravity CLI lub innego dostawcy AI.
Wysyłaj bugi i prośby bezpośrednio do swojego publicznego backlogu.
Spojrzenie na AgentsRoom w akcji.