Człowiek jako węzeł

przez Łukasz | wrz 2, 2026

Jedyny element grafu, którego przepustowość spada wraz z użyciem. I jedyny, którego nikt nie budżetuje.

Punkt zatwierdzenia przez człowieka jest w opisach grafów wymieniany obok agentów, funkcji i routerów jako pełnoprawny typ węzła. Na tym zwykle się kończy — bo z perspektywy topologii to rzeczywiście jest po prostu miejsce, w którym wykonanie się zatrzymuje i czeka.

Tyle że ten węzeł ma właściwość, której nie ma żaden inny. Funkcja wywołana czterdziesty raz działa identycznie jak za pierwszym. Człowiek zapytany czterdziesty raz — nie.

To nie jest uwaga o ludzkiej naturze. To jest parametr projektowy, który ma konsekwencje dla topologii.

Co odróżnia ten węzeł od pozostałych

Ma przepustowość, której nie da się skalować. Węzeł obliczeniowy zwielokrotnisz. Agenta uruchomisz w pięciu kopiach. Człowieka nie — a jeśli dołożysz drugiego, to nie jest ten sam węzeł, tylko dwa różne, z różną oceną tej samej sprawy.

Ma opóźnienie liczone w godzinach. Nie milisekundach, nie sekundach. Węzeł, który czeka na odpowiedź w nocy, czeka do rana. To zmienia projekt całości: wszystko, co da się zrobić przed tym węzłem, powinno się zdarzyć przed nim, bo po nim zaczyna się kolejka.

Jego niezawodność zależy od tego, ile razy go użyto. I to jest właściwość, dla której warto było napisać ten artykuł.

Zeszklone zatwierdzanie jako charakterystyka techniczna

Zeszklone zatwierdzanie to odruchowe akceptowanie próśb bez przetworzenia treści — punkt kontrolny formalnie działa, wszystko jest wyświetlone poprawnie, a mimo to nie chroni, bo pojawia się zbyt często, żeby cokolwiek znaczyć.

W torze o grafach to nie jest dygresja o psychologii. To jest specyfikacja tego węzła.

Człowiek, który zatwierdził dwieście operacji, z czego sto dziewięćdziesiąt dziewięć było nieszkodliwych, wyciąga o dwusetnej wniosek, że prawdopodobnie też jest nieszkodliwa. I ma rację — statystycznie. Nauczył się dokładnie tego, czego uczył go graf.

Z tego wynika zależność, którą warto zapisać wprost:

Im więcej krawędzi przechodzi przez węzeł zatwierdzenia, tym mniej znaczy każde pojedyncze przejście.

Sygnał, który pojawia się zawsze, nie niesie informacji. Węzeł, który odzywa się przy każdej operacji, komunikuje dokładnie to samo co brak węzła — czyli nic. Różnica polega na tym, że produkuje przy tym wpis w logu, z którego wynika, że ktoś podjął decyzję.

Konsekwencja projektowa: uwaga jest zasobem

Skoro przepustowość jest ograniczona, a jakość spada z obciążeniem, to człowiek w grafie zachowuje się jak każdy inny zasób limitowany — i tak samo trzeba go budżetować.

Cztery reguły, które z tego wynikają.

Bramkuj przekroczenie granicy, nie wykonanie operacji. Pytanie przy każdym zapisie produkuje sto pytań bez treści. Pytanie, gdy zapis wychodzi poza obszar roboczy, produkuje jedno, które coś znaczy.

Rezerwuj węzeł dla nieodwracalnego. Wszystko, co cofniesz jednym poleceniem, zasługuje raczej na wpis w logu niż na zatrzymanie grafu. Zatwierdzenie kosztuje uwagę — wydawaj ją tam, gdzie cofnąć się nie da.

Zbieraj, zamiast przerywać. Jeśli graf musi zapytać o piętnaście rzeczy w ciągu przebiegu, lepiej zapytać raz o piętnaście niż piętnaście razy o jedną — pod warunkiem, że każda jest widoczna osobno. Z jednym zastrzeżeniem: zgoda zbiorcza ukrywa tę jedną pozycję, która jest groźna, więc pakowanie ma sens tylko dla rzeczy jednorodnych.

Różnicuj to, co rzadkie. Jeśli poważne zatwierdzenie wygląda identycznie jak rutynowe, zostanie przetworzone tym samym odruchem. Musi łamać wzorzec — innym układem, innym potwierdzeniem, wymaganym działaniem, które nie jest kliknięciem w to samo miejsce co zawsze.

Wpis w logu a decyzja

Tu jest punkt, w którym ten węzeł styka się z odpowiedzialnością — i warto go postawić ostro, bo dotyczy każdego, kto buduje graf dla organizacji, a nie dla siebie.

Kiedy nadzór jest realny, zatwierdzenie jest dowodem, że ktoś rozważył konkretną operację i ją przyjął. Kiedy nadzór zeszklał, ten sam wpis powstaje z odruchu. Artefakt jest identyczny. To, co reprezentuje, nie.

Konsekwencja wykracza poza inżynierię: węzeł zatwierdzenia, którego nikt nie czyta, nie czyni systemu bezpieczniejszym. Czyni skutek przypisywalnym. Ryzyko nie zostało zmniejszone — zostało przesunięte z organizacji na osobę, która kliknęła.

A kliknęła, bo graf ją tego nauczył.

Dlatego ślad audytowy z zapisem zatwierdzenia ma wartość dowodową tylko wtedy, gdy da się wykazać, że zatwierdzenie było decyzją. Inaczej rejestr dokumentuje odruch i przypisuje go człowiekowi.

Kiedy człowiek w grafie w ogóle ma sens

Trzy przypadki, w których ten węzeł zarabia na swój koszt.

Nieodwracalność. Wysłanie, usunięcie, płatność, publikacja, zmiana uprawnień. Wszystko, czego nie cofniesz.

Rozstrzygnięcie, którego graf nie umie podjąć. Nie „czy to poprawne”, tylko „czy tego chcemy” — decyzja wartościująca, nie weryfikacyjna. Graf potrafi sprawdzić, czy tekst spełnia kryteria. Nie potrafi rozstrzygnąć, czy w ogóle chcemy go publikować.

Wymóg zewnętrzny. Regulacja albo umowa mówi, że decyzję podejmuje człowiek. Wtedy węzeł istnieje niezależnie od tego, czy pomaga — i tym bardziej warto zadbać, żeby zatwierdzenie było decyzją, a nie tylko wpisem.

Poza tymi trzema przypadkami warto sprawdzić, czy węzła nie da się zastąpić granicą infrastrukturalną z poprzedniego artykułu. Granica, która nie pozwala czegoś zrobić, jest tańsza i nie degraduje się z użyciem.

Jak to sprawdzić u siebie

Dwie liczby, obie łatwe do zebrania, obie rzadko zbierane.

Ile próśb o zatwierdzenie generuje twój graf na jedną osobę dziennie. Jeśli nie znasz tej liczby, to jest pierwsza rzecz do zmierzenia — bez niej nie wiesz, czy twój nadzór działa, czy tylko istnieje.

Jaki procent zatwierdzeń kończy się odmową. Jeśli bliski zeru, masz jedną z dwóch sytuacji: albo pytasz o rzeczy, o które nie trzeba pytać, albo ludzie przestali czytać. Obie wymagają tej samej reakcji — mniej pytań.

I jedno pytanie jakościowe, które warto zadać osobie zatwierdzającej: czy pamięta ostatnią rzecz, którą zatwierdziła?Nie „czy zatwierdziła” — czy pamięta, co to było. Odpowiedź „nie” nie oznacza, że ktoś jest niedbały. Oznacza, że graf pyta za często.

Co dalej

Węzły, krawędzie, stan, awarie, granice i człowiek — graf jest opisany. Zostaje pytanie, które przewijało się przez wszystkie te artykuły i nie doczekało się odpowiedzi: skąd właściwie wiadomo, co się wydarzyło.

W pętli log odpowiadał na pytanie, co robił agent. W grafie musi odpowiedzieć na trudniejsze: dlaczego zadziałał ten węzeł, a nie inny.

O tym jest artykuł dziewiąty: Co logować w grafie.


Stan na sierpień 2026. Zeszklone zatwierdzanie to termin wprowadzony na webflux.pl; mechanizmy, które za nim stoją — stronniczość automatyzacji i zmęczenie alertami — są opisane w literaturze o czynniku ludzkim od dekad.

Agent kończy, ale zadania nie wykonał

Agent kończy, ale zadania nie wykonał

Objawy Agent odpowiada: „Przygotowałem i wysłałem potwierdzenie do klienta." Potwierdzenie nie zostało wysłane. Albo: „Zaktualizowałem wszystkie rekordy" — zaktualizował trzy z dwunastu. Albo: „Nie znalazłem żadnych zamówień" — bo narzędzie zwróciło błąd, którego nikt...

Agent zrobił coś, o co nikt nie prosił

Agent zrobił coś, o co nikt nie prosił

Objawy Operacja, której nikt nie zlecił. Dane wysłane pod adres, którego nie ma w żadnej konfiguracji. Rekord zmieniony poza zakresem zadania. Odpowiedź, z której wynika, że agent dostał instrukcje od kogoś innego niż ty. Cecha wspólna: technicznie wszystko zadziałało...

Agent zrobił to samo dwa razy

Agent zrobił to samo dwa razy

Objawy Ten syndrom różni się od pozostałych jedną rzeczą: objaw widzi klient, nie ty. Trzy identyczne wiadomości w skrzynce. Dwa zamówienia zamiast jednego. Podwójne obciążenie. Duplikaty rekordów, które ktoś zauważa tydzień później. W twoim dzienniku wszystko wygląda...

Agent gubi wątek w długim zadaniu

Agent gubi wątek w długim zadaniu

Objawy Pierwsze kroki idą wzorowo. Po kilkunastu agent zaczyna się rozjeżdżać. Przestaje przestrzegać reguły z promptu systemowego, której trzymał się na początku. Zmienia format odpowiedzi w połowie zadania. Wraca do czegoś, co już ustalił, i ustala to inaczej....

Agent podaje dane, których nie ma

Agent podaje dane, których nie ma

Objawy Numer zamówienia w idealnym formacie, którego nie ma w bazie. Kwota, której w dokumencie nie ma. Nazwa pola API, które nigdy nie istniało. Cytat z regulaminu, brzmiący dokładnie jak reszta regulaminu i w nim nieobecny. Cecha wspólna wszystkich tych przypadków:...

Działał wczoraj, dziś nie działa

Działał wczoraj, dziś nie działa

Objawy Nic się nie wywala. Nie ma wyjątków, nie ma timeoutów, dziennik wygląda tak samo jak zawsze. Po prostu odpowiedzi są gorsze. Postacie, w jakich to się objawia: Jakość. Agent zaczyna pomijać kroki, które wcześniej wykonywał, albo odpowiada ogólniej. Format....

Agent wybiera złe narzędzie

Agent wybiera złe narzędzie

Objawy Agent odpowiada nie na to pytanie. Pobiera listę zamówień, gdy pytano o jedno konkretne. Odpowiada z pamięci, choć miał sprawdzić w bazie. Albo sięga po właściwe narzędzie i wpisuje w argumenty coś, czego nie da się użyć. Sygnał, który odróżnia ten syndrom od...

Agent kręci się w kółko

Agent kręci się w kółko

Objawy Agent wykonuje kolejne obroty pętli, nie zbliżając się do zakończenia zadania. W dzienniku widać jedną z trzech postaci. Powtórzenie. To samo narzędzie, te same argumenty, raz za razem — czasem dziesiątki razy pod rząd. Oscylacja. Agent wywołuje na przemian dwa...