Human-in-the-Loop (HITL)

1. Przegląd koncepcji i problem systemowy

Pełna autonomia agentów (Fully Autonomous Agents) napotyka fundamentalne ograniczenie: niedeterministyczność dużych modeli językowych. Nawet jeśli model wykazuje dokładność na poziomie 98%, skumulowane prawdopodobieństwo błędu w 20-krokowym łańcuchu wykonania zbliża się do 33%. Jeśli agent ma bezpośredni dostęp do powłoki systemowej, produkcyjnych baz danych, API finansowych lub infrastruktury chmurowej, pojedyncza awaria lub halucynacja mogą prowadzić do utraty danych lub wielotysięcznych strat.

Human-in-the-Loop (HITL) to zasada architektoniczna budowania niezawodnych systemów agentowych. Zamiast ślepo ufać maszynie w całym procesie od początku do końca, system jest projektowany tak, aby najbardziej ryzykowne działania wymagały świadomej weryfikacji przez człowieka. HITL łączy szybkość pracy sztucznej inteligencji z odpowiedzialnością i kontekstowym osądem senior-inżyniera.

2. Taksonomia architektoniczna i model mentalny

Architektura HITL dzieli się na trzy kluczowe modele interakcji, w zależności od protokołu i krytyczności operacji:

┌─────────────────────────────────────────────────────────────┐
│                 TAKSONOMIA INTERAKCJI HITL                  │
├─────────────────────────────────────────────────────────────┤
│ 1. Synchroniczna bramka CLI (Blokada na STDIN: Prompt [y/N])│
│    Lokalne narzędzia deweloperskie (Claude Code, Cline)     │
├─────────────────────────────────────────────────────────────┤
│ 2. Asynchroniczna trwała bramka (Checkpointing stanu / Webhook)│
│    Łańcuchy długotrwałych procesów (LangGraph, Temporal, Inngest)│
├─────────────────────────────────────────────────────────────┤
│ 3. Eskalacja i polityka RBAC z poziomami dostępu           │
│    • Tylko do odczytu ➔ Automatycznie zatwierdzone (Poziom 0)│
│    • Modyfikacje lokalne ➔ Zatwierdzone przez dewelopera (Poziom 1)│
│    • Produkcja / Pieniądze ➔ Zatwierdzone przez lidera / multi-sig (Poziom 2)│
└─────────────────────────────────────────────────────────────┘

1. Synchroniczna bariera lokalna (Synchronous Approval):
   • Stosowana w agentach CLI oraz IDE. Agent blokuje strumień wykonania, wypisuje w konsoli planowaną komendę shellową lub diff i oczekuje na naciśnięcie klawisza przez użytkownika.
2. Asynchroniczna, trwała bariera czasowa (Durable Asynchronous Gate):
   • Stosowana w agentach backendowych. Po osiągnięciu punktu krytycznego agent zapisuje swój stan roboczy w bazie danych (Checkpointer), generuje zdarzenie (np. wiadomość na Slacku lub e-mail z przyciskami „Zatwierdź” / „Odrzuć”) i przechodzi w stan uśpienia.
3. Granularna macierz uprawnień (Tiered Action Policies):
   • Działania są klasyfikowane według poziomu potencjalnego ryzyka (Blast Radius). Bezpieczne operacje nie wymagają zatwierdzenia, podczas gdy operacje nieodwracalne wymagają wielopoziomowego potwierdzenia.

3. Potok techniczny i mechanika wewnętrzna

Cykl życia asynchronicznego procesu z udziałem człowieka (na przykładzie LangGraph):

1. Wykonanie kroków do punktu kontrolnego: Agent analizuje zapytanie, tworzy plan i wykonuje obliczenia przygotowawcze (np. generuje zapytanie SQL do migracji danych).
2. Przechwycenie narzędzia (Tool Interceptor): Warstwa bezpieczeństwa sprawdza wywołanie: jeśli uruchamiane jest narzędzie execute_production_migration, następuje przerwanie interrupt().
3. Serializacja i utrwalenie stanu (State Persisting): Bieżący graf pamięci, historia wiadomości oraz argumenty wywołania narzędzia są zapisywane w repozytorium stanów.
4. Routing do operatora: Serwis wysyła interaktywną wiadomość na firmowy kanał Slack z opisem zmian i przyciskami potwierdzającymi.
5. Rewizja ludzka i modyfikacja: Inżynier może:
   • Zatwierdzić: przesłać sygnał wznowienia wykonania.
   • Odrzucić: przerwać sesję i zarejestrować powód odmowy.
   • Skorygować (Human-in-the-Edit): edytować parametry (np. zmniejszyć batch size zapytania) przed wykonaniem.
6. Wznowienie wykonania (Resume Thread): Silnik ładuje stan z bazy danych, stosuje decyzję inżyniera i kontynuuje cykl autonomiczny.

4. Praktyczne scenariusze inżynierskie w środowisku produkcyjnym

01. Kontrola niebezpiecznych migracji SQL na żywej bazie danych

Agent analizuje nową funkcjonalność i proponuje zmianę schematu PostgreSQL:

• Zamiast bezpośrednio wykonywać ALTER TABLE users ADD COLUMN status text NOT NULL, agent wystawia prośbę o zatwierdzenie.
• DBA widzi, że dodanie kolumny bez wartości domyślnej w tabeli zawierającej 20 mln rekordów zablokuje odczyty. Inżynier koryguje polecenie na utworzenie pola z DEFAULT poprzez bezpieczny wzorzec migracyjny i zatwierdza wykonanie.

02. Zatwierdzanie usuwania zasobów chmurowych w celu optymalizacji kosztów

Agent FinOps przeprowadza audyt infrastruktury AWS:

• Znajduje 14 nieużywanych instancji RDS oraz dysków EBS, które generują koszty rzędu $2,000 miesięcznie.
• Agent nie usuwa ich samodzielnie, lecz wysyła ustrukturyzowany raport do tech leada w korporacyjnym komunikatorze z linkami do każdego zasobu. Tech lead lub lekarz naciska „Terminate All”, po czym agent wykonuje czyszczenie.

03. Generowanie spersonalizowanych odpowiedzi prawnych lub compliance

AI formułuje odpowiedzi na zapytania użytkowników dotyczące usunięcia danych osobowych (GDPR Right to be Forgotten):

• Agent znajduje wszystkie powiązane encje w serwisach, tworzy skrypt usuwania i przygotowuje oficjalny list do klienta.
• Pracownik działu bezpieczeństwa weryfikuje poprawność złożenia dokumentów przed wysyłką.

5. Pułapki, typowe błędy i bezpieczeństwo

• Zmęczenie zatwierdzaniem (Approval Fatigue): Jeśli agent prosi o potwierdzenie przy każdym drobnym kroku (np. odczytaniu każdego pliku), programista przestaje czytać ze zrozumieniem i automatycznie akceptuje wszystkie żądania. Konfiguruj rozsądne progi wrażliwości.
• Podatność na podmianę intencji przez Prompt Injection: Jeśli agent przetwarza niezweryfikowane dane zewnętrzne (np. tekst ze strony internetowej), atakujący może zmusić model do sformułowania mylącego opisu akcji dla operatora („To bezpieczna aktualizacja cache”, choć pod maską dochodzi do kradzieży tokenów).
• Utrata transakcyjności przy timeoutach: Jeśli wątek zawiesi się w oczekiwaniu na odpowiedź człowieka przez kilka godzin lub dni, otwarte transakcje w bazach danych lub tymczasowe tokeny dostępu mogą wygasnąć, powodując awarię systemu po powrocie człowieka.
• Brak logów audytu (Audit Logging): Każda decyzja człowieka dotycząca zatwierdzenia lub odrzucenia działania agenta musi być obowiązkowo rejestrowana w chronionym logu z przypisaniem do ID użytkownika, aby zapewnić przejrzystość i możliwość badania incydentów.