Podręcznik operatora agentów: nadzorowanie tego, czego nie widać

Obsługa autonomicznych agentów AI to nowa dyscyplina: nie inżynieria, nie zarządzanie, nie operacje, lecz hybryda wymagająca wszystkich trzech. Rola operatora pojawia się, gdy agenty działają wystarczająco długo, by wąskim gardłem stał się nadzór, a nie generowanie kodu. Pięć obszarów odpowiedzialności definiuje tę rolę. Stos nadzoru je implementuje. Framework interwencyjny określa, kiedy działać.

Nikt nie został do tej pracy przeszkolony. Żaden wydział uniwersytecki tego nie uczy. Żadne ogłoszenie o pracę nie opisuje jej trafnie. W jednym miesiącu pisze się Python. W następnym zarządza się autonomicznym systemem, który sam pisze Python, wywołuje API, modyfikuje system plików i podejmuje decyzje architektoniczne, podczas gdy operator śpi. Pętla Ralph stworzyła tę rolę w mojej infrastrukturze: skrypt powłoki, który restartuje Claude Code ze świeżym kontekstem, odczytuje stan systemu plików i kontynuuje pracę w sesjach nocnych. Każdy zespół uruchamiający agenty autonomicznie odkrył tę samą rolę niezależnie, ponieważ te same problemy pojawiają się za każdym razem, gdy agent działa dłużej niż jedna sesja interaktywna.

Rola nie ma ustalonej nazwy. Niektóre zespoły nazywają ją „AI ops”. Inne włączają ją do inżynierii platformowej. Nieliczne przypisują ją menedżerom inżynierii, którzy nigdy nie napisali hooka. Ta niejednoznaczność ma znaczenie, ponieważ błędna identyfikacja roli prowadzi do błędnej alokacji pracy. Menedżer inżynierii bez wiedzy systemowej nie zdebuguje uszkodzonego stanu agenta. Inżynier platformowy bez wyczucia produktowego nie oceni, czy output agenta spełnia intencję specyfikacji. Rola operatora wymaga obu kompetencji: decyzji specyfikacyjnych (co agent powinien budować, jakie narzucić ograniczenia) i realizacji operacyjnej (monitorowanie sesji, odzyskiwanie po awariach, utrzymanie infrastruktury).

Pięć obszarów odpowiedzialności operatora

1. Delegowanie

Delegowanie oznacza pisanie specyfikacji, które ograniczają zachowanie agenta przed rozpoczęciem wykonywania. Jakość delegowania determinuje jakość autonomicznego outputu bardziej niż jakikolwiek inny czynnik.

Plik CLAUDE.md to artefakt delegowania. Koduje konwencje projektu, zabronione wzorce, wymagane zachowania i standardy jakości w dokumencie, który agent odczytuje na początku sesji.¹ PRD to artefakt delegowania. Określa kryteria akceptacji, z którymi agent weryfikuje się przed zgłoszeniem ukończenia. Opis zadania to artefakt delegowania. Szczegółowość opisu zadania wyznacza przestrzeń decyzyjną agenta.

Słabe delegowanie prowadzi do spirali skrótów: agent pomija kroki, ponieważ specyfikacja nie wymieniła ich jako obowiązkowych. Dobre delegowanie czyni wymagane kroki jawnymi. Moje PRD zawierają ponumerowane kryteria akceptacji, a każde kryterium mapuje się na obserwowalny artefakt (ścieżka pliku, wynik testu, konkretne zachowanie). Agent nie może oznaczyć kryterium jako spełnione bez dostarczenia artefaktu. Delegowanie określające obserwowalne rezultaty eliminuje całą klasę fantomowych ukończeń.

Umiejętność polega na rozpoznaniu, co należy wyspecyfikować, a co pozostawić otwarte. Nadmierna specyfikacja tworzy kruche agenty, które nie potrafią się adaptować, gdy napotkają nieoczekiwany kod. Niedostateczna specyfikacja tworzy agenty podejmujące decyzje architektoniczne, na które operator nie wyrażał zgody. Granica przesuwa się wraz z zaufaniem: dobrze przetestowany agent z solidnymi hookami zyskuje szerszą swobodę niż nowa konfiguracja uruchamiana po raz pierwszy w sesji nocnej.

2. Nadzór

Nadzór oznacza monitorowanie aktywnych sesji, przeglądanie diffów i wychwytywanie dryftu, zanim się skumuluje.

Dryft to centralne ryzyko. Agent zaczyna w zgodzie ze specyfikacją, podejmuje rozsądną mikrodecyzję, która odbiega nieznacznie, a następnie podejmuje kolejne decyzje budujące na tym odchyleniu. Po ósmej iteracji agent rozwiązuje inny problem niż ten, który został mu delegowany. Każda pojedyncza decyzja wyglądała rozsądnie w izolacji. Skumulowana trajektoria chybiła celu.

Dryft wykrywam za pomocą dwóch mechanizmów. Po pierwsze, hooki wymuszają twarde granice: zablokowane polecenia, wymagane wzorce, zabronione modyfikacje plików. Hooki wyłapują naruszenia w czasie rzeczywistym, zanim agent kontynuuje. Po drugie, okresowy przegląd logów wyłapuje miękki dryft, którego żaden hook nie wykryje: agent wybierający niepotrzebnie złożone podejście, budujący funkcję, której specyfikacja nie żądała, lub optymalizujący ścieżkę kodu, która nie była wąskim gardłem. Miękki dryft wymaga ludzkiego osądu, ponieważ żadna automatyczna kontrola nie jest w stanie określić, czy trajektoria agenta odpowiada intencji operatora.

Nadzór skaluje się słabo wraz z liczbą agentów. Jeden agent generujący jedną sesję na noc jest do przejrzenia przy porannej kawie. Pięć agentów generujących po osiem iteracji tworzy czterdzieści okien kontekstowych pracy. Priorytetyzacja staje się konieczna: najpierw przegląd awarii, potem sesje dotykające krytycznych ścieżek, na końcu czyste ukończenia zadań niskiego ryzyka.

3. Interwencja

Interwencja oznacza wiedzę, kiedy zatrzymać, przekierować lub zrestartować agenta w trakcie zadania.

Cztery wzorce wymagają interwencji:

Agent utknął w pętli. Ten sam błąd pojawia się w kolejnych iteracjach. Agent próbuje tej samej poprawki z drobnymi wariacjami. Każda iteracja zużywa pełne okno kontekstowe i nie przynosi postępu. Interwencja: zatrzymanie sesji, ręczna diagnoza przyczyny źródłowej, aktualizacja dokumentu przekazania o diagnozę, restart.

Agent wygenerował niepoprawny output, który przechodzi testy. Kod się kompiluje, testy są zielone, ale zachowanie nie odpowiada intencji specyfikacji. Brama dowodowa wyłapuje niektóre przypadki, ale agent potrafi wygenerować wiarygodne uzasadnienie dla błędnego zachowania. Interwencja: napisanie testu kończącego się niepowodzeniem, który oddaje prawidłowe zachowanie, a następnie restart.

Agent zamierza dotknąć produkcji lub systemów zewnętrznych. Każda operacja o nieodwracalnych konsekwencjach (wdrożenie na produkcję, wysłanie e-maili, modyfikacja bazy danych, wywołanie płatnego API) wymaga bramki. Moje hooki blokują destrukcyjne polecenia bash i zewnętrzne wywołania sieciowe. Operator decyduje, które bramki otworzyć i kiedy.²

Agent robi postępy, ale w złym kierunku. Praca jest kompetentna, lecz niewłaściwie ukierunkowana. Interwencja: zatrzymanie, doprecyzowanie specyfikacji w dokumencie przekazania, restart. Nie należy próbować przekierowywać w trakcie sesji przez konwersację. Agent zbudował już modele mentalne wokół błędnej interpretacji, a korekta kursu w tym samym oknie kontekstowym generuje niespójny output.

Wzorzec, przy którym nie należy interweniować: agent robi powolne, ale mierzalne postępy w kierunku właściwego celu. Niech pracuje.

4. Odzyskiwanie

Odzyskiwanie oznacza obsługę awarii po ich wystąpieniu: uszkodzony stan, błędne gałęzie, zepsute buildy i utrata danych.

Awarie agentów pozostawiają artefakty. Sesja, która uległa awarii, mogła zapisać częściowe pliki, zatwierdzić zmiany na złej gałęzi, zostawić pliki tymczasowe w katalogu roboczym lub zmodyfikować konfigurację dziedziczoną przez kolejne sesje. Odzyskiwanie wymaga odwrócenia tych artefaktów przed restartem.

Mój protokół odzyskiwania: inwentaryzacja szkód (git status, git log, git diff), zachowanie logu sesji jako danych diagnostycznych, cofnięcie do ostatniego zweryfikowanego commita, aktualizacja dokumentu przekazania o informacje co zawiodło i dlaczego, a następnie restart ze skorygowanymi ograniczeniami. Nie należy próbować ratować częściowej pracy z nieudanej sesji, chyba że jest ona wyraźnie poprawna i możliwa do wyizolowania. Dokument przekazania przenosi kontekst awarii między sesjami, aby kolejny agent nie powtórzył tych samych błędów.

Najgroźniejszy scenariusz odzyskiwania to awaria, która wygląda jak sukces. Agent raportuje ukończenie, testy przechodzą, build jest zielony, ale implementacja jest subtelnie błędna. Tryb awarii miraż pewności generuje dokładnie taką sytuację. Odzyskiwanie wymaga czytania kodu, a nie tylko raportu o ukończeniu.

5. Governance

Governance oznacza ustalanie polityk, budżetów, uprawnień i wymagań audytowych obowiązujących we wszystkich sesjach agentów.

Polityki definiują, co agenty mogą, a czego nie mogą robić. Moja warstwa governance obejmuje: budżet spawnów (maksymalna liczba iteracji na sesję nocną), pułap kosztów (maksymalny wydatek na API na sesję), listę dozwolonych poleceń bash, listę zabronionych wzorców plików oraz zestaw wymaganych kryteriów ukończenia.³ Każda polityka ma źródło w konkretnej awarii. Budżet spawnów istnieje, ponieważ wczesna sesja wykonała 47 iteracji bez konwergencji. Pułap kosztów istnieje, ponieważ sesja debugowania spaliła 200 dolarów na wywołania API, goniąc fałszywy trop. Każda polityka to blizna po lekcji opłaconej wysoką ceną.

Uprawnienia podlegają zasadzie minimalnych przywilejów. Agent generujący treści blogowe nie potrzebuje dostępu do zapisu poza katalogiem treści. Agent uruchamiający testy nie potrzebuje dostępu do sieci. Moje hooki wymuszają te granice na poziomie wywołań narzędzi, blokując operacje wykraczające poza zakres uprawnień sesji.²

Wymagania audytowe dopełniają warstwę governance. Każda sesja generuje ustrukturyzowany log: wykonane polecenia, zmodyfikowane pliki, uruchomione testy, ocenione kryteria ukończenia. Taksonomia siedmiu trybów awarii wyłoniła się z przeglądu sześciu miesięcy tych logów i kategoryzacji każdej awarii wymagającej ludzkiej interwencji.

Stos nadzoru

Pięć komponentów infrastrukturalnych implementuje pięć obszarów odpowiedzialności.

Hooki implementują automatyczny nadzór. Zdarzenia cyklu życia Claude Code (PreToolUse, PostToolUse, Notification) wyzwalają skrypty powłoki wymuszające polityki w czasie rzeczywistym.² Hook blokujący rm -rf to polityka governance zakodowana jako kontrola PreToolUse. Hook wymagający uruchomienia testów przed ukończeniem to ograniczenie delegowania zakodowane jako kontrola PostToolUse. 95 hooków w moim systemie koduje 95 decyzji o tym, co agenty mogą, a czego nie mogą robić — każdy odwołuje się do konkretnej awarii, której teraz zapobiega.

Brama dowodowa implementuje ustrukturyzowaną weryfikację. Sześć kryteriów (zgodność z wzorcami, najprostsze rozwiązanie, obsługa przypadków brzegowych, przechodzące testy, brak regresji, rozwiązanie właściwego problemu) musi wygenerować konkretne artefakty, zanim agent oznaczy pracę jako ukończoną.⁴ Brama przekształca nadzór z pytania „czy agent dobrze się spisał?” (subiektywne, nieweryfikowalne) na „czy agent dostarczył dowody dla wszystkich sześciu kryteriów?” (obiektywne, audytowalne). Każde słowo sygnalizujące niepewność w raporcie ukończenia wyzwala ponowną weryfikację.

Pętla jakości implementuje iteracyjne doskonalenie. Siedem kroków (implementacja, przegląd, ocena, poprawka, szersze spojrzenie, powtórzenie, raport) wymusza na agencie wielokrotne przejścia nad własną pracą.⁵ Pętla kompensuje strukturalne ograniczenie generowania jednoprzebiegowego: modele tworzą wiarygodne pierwsze wersje zawierające błędy widoczne dopiero przy ponownym czytaniu. Pętla jakości wymusza to ponowne czytanie.

Logi sesji implementują audyt ex post. System rejestruje każde wywołanie narzędzia, modyfikację pliku i raport ukończenia w ustrukturyzowanej formie. Sześć miesięcy logów sesji dało taksonomię awarii. Bez logów każda awaria pozostałaby izolowaną anegdotą.

Bramki kosztowe implementują egzekwowanie budżetu. Budżety spawnów ograniczają liczbę iteracji. Pułapy kosztów API ograniczają wydatki na tokeny. Agent, który nie osiągnął konwergencji w ramach budżetu spawnów, prawdopodobnie utknął, a kolejne iteracje nie pomogą. Budżet zmusza operatora do diagnozy i interwencji zamiast nadziei, że następna iteracja rozwiąże problem.

Kiedy interweniować, a kiedy pozwolić działać

Decyzja o interwencji to najbardziej konsekwencjalna ocena operatora. Zbyt wczesna interwencja marnuje pracę agenta. Zbyt późna pozwala na kumulację dryftu. Framework pomaga w podjęciu decyzji.

Metazasada: interweniuj przy asymetrii informacyjnej, nie przy niskiej szybkości. Gdy operator wie coś, czego agent nie wie (właściwa ścieżka kodu, rzeczywiste wymaganie, tryb awarii z poprzedniej sesji), interwencja transferuje tę wiedzę. Gdy agent wie wszystko to, co operator, i po prostu przepracowuje problem — niech pracuje.

Lista kontrolna operatora

Przed rozpoczęciem

• [ ] Specyfikacja przejrzana: kryteria akceptacji są konkretne, obserwowalne i kompletne
• [ ] Hooki aktywne: hooki polityk są włączone i przetestowane dla danego typu zadania
• [ ] Budżet ustawiony: limit spawnów i pułap kosztów są skonfigurowane
• [ ] Piaskownica potwierdzona: agent nie może dotrzeć do produkcji, wysyłać zewnętrznych zapytań ani modyfikować plików poza zakresem
• [ ] Dokument przekazania aktualny: jeśli kontynuuje poprzednią pracę, dokument przekazania odzwierciedla najnowsze korekty
• [ ] Gałąź czysta: katalog roboczy jest na właściwej gałęzi bez niezatwierdzonych zmian

W trakcie

• [ ] Sprawdzaj logi w ustalonych odstępach (co 2–3 iteracje dla sesji nocnych)
• [ ] Weryfikuj, czy trajektoria odpowiada intencji specyfikacji, nie tylko jej literze
• [ ] Monitoruj zużycie zasobów: wydatki na tokeny, liczba iteracji, zmiany w systemie plików
• [ ] Obserwuj eskalację uprawnień: żądania dostępu, którego zadanie nie powinno wymagać
• [ ] Notuj wszelki miękki dryft do przeglądu posesyjnego

Po zakończeniu

• [ ] Przejrzyj wszystkie zmiany w plikach, nie tylko raport ukończenia
• [ ] Uruchom pełny zestaw testów niezależnie (nie ufaj wynikom testów raportowanym przez agenta)
• [ ] Sprawdź regresje w sąsiednim kodzie, którego agent bezpośrednio nie modyfikował
• [ ] Zweryfikuj bramę dowodową: każde kryterium ma konkretny artefakt, nie ogólne zapewnienie
• [ ] Zaktualizuj dokument przekazania o wyniki sesji i wszelkie korekty
• [ ] Zaloguj sesję: napotkane tryby awarii, wyzwolone hooki, podjęte decyzje interwencyjne
• [ ] Zaktualizuj governance: jeśli pojawił się nowy wzorzec awarii, napisz hook lub politykę zapobiegającą powtórzeniu

Operator jako rzemieślnik

Rola operatora agentów istnieje na przecięciu umiejętności inżynieryjnych i wyczucia produktowego. Pisanie hooków wymaga wiedzy systemowej. Pisanie specyfikacji wymaga zrozumienia produktu. Przeglądanie outputu agenta wymaga obu kompetencji: zdolności do oceny, czy kod jest poprawny, oraz czy poprawny kod rozwiązuje właściwy problem.

Czat to niewłaściwy interfejs dla operacyjnej połowy roli. Przewijanie transkryptów konwersacji w celu nadzorowania pracy autonomicznej nie skaluje się ponad jednego agenta prowadzącego jedną sesję. Opisany powyżej stos nadzoru (hooki, bramy dowodowe, pętle jakości, logi sesji, bramki kosztowe) kompensuje tę lukę interfejsową, kodując nadzór w infrastrukturze. Infrastruktura nie zastępuje operatora. Infrastruktura mnoży zasięg operatora.

Gust to system techniczny opisuje połowę opartą na osądzie. Wiedza o tym, co delegować, co weryfikować i co odrzucić, wymaga rozpoznawania wzorców budowanego przez doświadczenie. Każda sesja uczy operatora czegoś o zachowaniu agentów. Umiejętności operatora kumulują się dzięki świadomej praktyce, refleksji i infrastrukturze kodującej lekcje na stałe.

Ciemna fabryka reprezentuje teoretyczny punkt docelowy, poziom 5, na którym żaden człowiek nie czyta kodu. Obecna praktyka dla większości zespołów plasuje się na poziomie 3 lub 4: agent wykonuje pracę, operator nadzoruje i interweniuje. Przepaść między poziomem 4 a 5 to warstwa weryfikacji. Przepaść między poziomem 2 a 4 to operator.

Każdy zespół uruchamiający autonomiczne agenty wykształci operatorów. Pytanie brzmi, czy rozwinie tę rolę świadomie (z określonymi obowiązkami, wsparciem infrastrukturalnym i jawnym szkoleniem), czy przypadkowo — przypisując pracę temu, kto akurat nie śpi, gdy nocna sesja zawiedzie. Rzemiosło rozwija się stamtąd.