Granice zamiast instrukcji: jak zachować kontrolę nad autonomicznymi agentami AI

Im bardziej autonomiczne stają się agenty AI, tym częściej próbujemy zarządzać nimi w zwykły sposób — piszemy w prompcie reguły: „nie ruszaj tego”, „pracuj tylko tam”, „nigdy nie rób tego”. Podczas eksperymentu z trzema równoległymi agentami w ciągu dwóch dni zebrałem żywą kolekcję przypadków, w których ten sposób zawodzi — i w których działa inny. Teza artykułu jest prosta: instrukcja to prośba, którą agent wykonuje z pewnym prawdopodobieństwem; granica to właściwość systemu, która nie zależy od posłuszeństwa. Dopóki agent był jeden i pracował pod nadzorem, różnica wydawała się stylistyczna. Gdy agentów zrobiło się wielu, okazała się architektoniczna.

Pięć incydentów jednej sesji

Wszystkie poniższe przypadki wydarzyły się w jednej sesji roboczej na tym blogu — są udokumentowane, a każdy ilustruje inny sposób, w jaki zarządzanie przez tekst zawodzi.

Instrukcji nie było — zdarzyła się awaria. Agent, przygotowując się do swojego zadania, wykonał git stash w katalogu głównym i zabrał do stasha moje niezacommitowane pliki, niezwiązane z jego zadaniem. Nikt niczego nie „złamał”: zakaz po prostu nie istniał. To fundamentalna właściwość instrukcji — pisze się je po awariach. Pełnej listy tego, czego agent nie powinien robić, napisać nie można.

Instrukcja była — i nie zadziałała. Po pierwszej awarii dodałem agentom wyraźną regułę: „pracuj ściśle w swoim katalogu roboczym”. Jeden z agentów i tak wykonał polecenie git w katalogu głównym — po prostu odwołał się do niego ścieżką absolutną. Nie ze złośliwości i nie z głupoty: model jest probabilistyczny, a przestrzeganie tekstowej reguły to też prawdopodobieństwo, pomnożone przez długość kontekstu i liczbę przebiegów.

Techniczna granica zadziałała po cichu. W tym samym eksperymencie ani razu nie zdarzyła się najbardziej oczekiwana awaria — „jeden agent przełączył gałąź wszystkim”. Nie dlatego, że agenty były ostrożne, ale dlatego, że git worktree fizycznie nie pozwala wypisać jednej gałęzi do dwóch kopii roboczych. Zabezpieczenie jest wbudowane w narzędzie. Nie trzeba go pamiętać, nie trzeba go przestrzegać — po prostu jest.

Instrukcja stała tam, gdzie powinna stać granica. Najbardziej nieprzyjemne odkrycie: produkcji tego bloga strzegła linijka w prompcie. Push do master uruchamia autodeploy, a od każdego agenta oddzielał go tylko tekst „żadnego git push”. Utrzymał się — ale to szczęście, a nie kontrola: prawdziwą granicą są tu uprawnienia dostępu, protected branch, token bez prawa zapisu. Prośba stała na miejscu zamka.

Granica ponad samym agentem. Dwukrotnie w ciągu sesji środowisko wykonawcze zatrzymało nie agentów doświadczalnych, lecz mojego głównego asystenta: klasyfikator uprawnień zablokował SSH do serwera produkcyjnego i masowe usuwanie niezacommitowanych zmian — działania, które formalnie wynikały z zadania, ale wymagały wyraźnego ludzkiego „tak”. Obie blokady były słuszne. I obie wydarzyły się ponad „dyscypliną” agenta, który całkiem szczerze uważał, że działa zgodnie z planem.

Zasada nie jest nowa — nowa jest tylko istota

Inżynieria przerabiała tę lekcję na długo przed LLM. W systemie produkcyjnym Toyoty zasada nazywa się poka-yoke: błąd zapobiega urządzenie procesu, a nie czujność wykonawcy. Część, którą można włożyć tylko właściwą stroną, jest pewniejsza niż plakat „wkładaj właściwie”. W inżynierii platformy to samo nazywa się guardrails, w bezpieczeństwie — defense in depth. Wszędzie ta sama myśl: nie polegaj na tym, że wykonawca przeczytał, zrozumiał i nie zapomniał — spraw, by niewłaściwe działanie było niemożliwe lub kosztowne.

„Instrukcja to prośba. Granica to właściwość systemu. Kontrola, która opiera się na prośbach, to nie kontrola, lecz szczęście o efekcie kumulacyjnym.”

– główny wniosek dwóch dni pracy z równoległymi agentami

W przypadku agentów AI ta stara zasada staje się ostrzejsza z trzech powodów. Agentów jest wielu — prawdopodobieństwo zawiedzenia instrukcji mnoży się przez każdy przebieg każdego agenta. Agenty są szybkie — między „zaczął się mylić” a „dokończył psucie” mijają sekundy, człowiek nie zdąży zareagować. A agenty są dosłowne, lecz nie niezawodne: wykonują tekst promptu staranniej niż niejeden junior, a jednak probabilistycznie — a probabilistyczne przestrzeganie reguł w skali gwarantuje naruszenie.

Jak granice wyglądają w praktyce

Warstwy, które zbudowałem po tej sesji — od systemu plików po weryfikację:

• System plików: każdemu agentowi — własna kopia robocza (git worktree, który Anthropic zaleca dla równoległych sesji, w Claude Code jest wbudowany), a na poziomie OS — piaskownica: sandboxing w Claude Code izoluje system plików i sieć standardowymi prymitywami OS — według danych Anthropic zmniejszyło to ich wewnętrzne zapytania o uprawnienia o 84%, a udana prompt-injection pozostaje zamknięta w środku.
• Prawa zapisu: prod i master są chronione przez uprawnienia, a nie przez prompt — protected branch, tokeny bez prawa push, osobne konta dla agentów. Prośby o zostawienie w prompcie można, ale jako druga warstwa.
• Runtime: worktree nie izoluje baz, portów i kontenerów — są one wspólne dla wszystkich kopii. Agenci, którzy uruchamiają testy i serwery, potrzebują jednorazowych zasobów: tymczasowej bazy, własnego portu, kontenera na agenta.
• Uprawnienia do działań: nieodwracalne operacje przechodzą przez potwierdzenie lub klasyfikator — jak auto mode w Claude Code, który ocenia każde działanie zamiast albo pytać o wszystko, albo nie pytać o nic. To granica, która przesuwa się tylko na wyraźną decyzję człowieka.
• Weryfikacja po artefaktach: ufać nie samoopisowi agenta, a śladom na dysku. Mój zawieszony agent wyglądał w interfejsie na działającego; diagnozę postawił brak nowych plików w jego kopii przez dwadzieścia minut. Commity do własnej gałęzi — ten sam pomysł: wynik, który przetrwa i awarię, i optymizm agenta.

Instrukcje w tym schemacie nigdzie nie znikają — stają się ostatnią warstwą, a nie pierwszą. «Pracuj w swoim katalogu» w prompcie wciąż jest przydatne: zmniejsza częstotliwość prób. Ale między próbą a awarią powinna stać granica, a nie nadzieja.

Uczciwe zastrzeżenia

Granica nie jest absolutem: sandboxy się obchodzi, klasyfikatory się mylą, i publikowane analizy obejść regularnie to pokazują. Dlatego granice buduje się warstwami — jak wszystko w bezpieczeństwie. I granica kosztuje więcej niż instrukcja na starcie: skonfigurować worktree, uprawnienia i sandbox — to godziny, napisać linijkę w prompt — sekundy. Asymetria jest w czym innym: granica płaci się raz, instrukcja — prawdopodobieństwem porażki przy każdym przebiegu. U mnie konfiguracja izolacji zwróciła się przy pierwszym restarcie eksperymentu, który przeszedł bez ani jednego konfliktu.

Wniosek

Pytanie serii — jak wbudować agentów AI w realną pracę, nie tracąc kontroli. Odpowiedź tego artykułu: kontrola to nie to, co jest napisane agentowi, a to, co jest zbudowane wokół niego. Zanim dodasz do promptu kolejne «nigdy nie rób X», warto zapytać siebie: a czy można uczynić X technicznie niemożliwym? Jeśli tak — to jest właściwe miejsce na wysiłek. Prompt niech prosi; zabraniać powinien system.

Źródła i punkty odniesienia

• Making Claude Code more secure and autonomous with sandboxing (Anthropic Engineering) — izolacja systemu plików i sieci na poziomie OS; źródło liczby 84%.
• How we contain Claude across products (Anthropic Engineering, 2026) — jak zbudowane są granice wykonania w produktach agentowych jako całości.
• How we built Claude Code auto mode (Anthropic Engineering) — klasyfikator uprawnień jako granica między «pytać o wszystko» a «nie pytać o nic».
• Poka-Yoke (Lean Enterprise Institute) — klasyczna zasada zapobiegania błędom przez konstrukcję procesu.
• git-worktree i git-stash — oficjalna dokumentacja Git: mechanika kopii roboczych i wspólnego stasha.
• Claude Code: Best practices for agentic coding (Anthropic Engineering) — zalecenie worktree dla równoległych sesji.
• Jak uczciwie porównać LLM na własnym kodzie: eksperyment z trzema modelami Claude — poprzedni artykuł serii: eksperyment, w którym zebrano opisane incydenty.