W pętli stan był notatnikiem jednego procesu. W grafie staje się zasobem, o który kilku wykonawców konkuruje jednocześnie.
W pętli stan jest prosty, bo jest jeden. Historia rośnie, kod dopisuje kolejne kroki, model nie pamięta niczego i cała ciągłość jest iluzją utrzymywaną przez pętlę. Jedno miejsce, jeden zapisujący, brak niespodzianek.
W grafie stan przestaje być notatnikiem, a zaczyna być bazą danych — z wszystkimi problemami, jakie ma baza danych, do której pisze kilku klientów naraz. Większość z nich jest znana od dekad. Nowe jest tylko to, że część zapisujących podejmuje decyzje niedeterministycznie.
Trzy pytania, które w pętli nie istniały
Kto zapisuje to samo pole. Węzeł badawczy dopisuje ustalenia, węzeł weryfikujący je koryguje, węzeł raportujący czyta całość. Jeśli dwa pierwsze działają równolegle, powstaje pytanie, którego wcześniej nie było: która wersja jest prawdziwa.
Co widzi węzeł, który zaczyna teraz. Stan sprzed dziesięciu minut czy aktualny. Przy pracy rozłożonej na godziny to nie jest szczegół — węzeł może pracować na obrazie świata, który zdążył się zmienić.
Kto wziął to zadanie. W pętli zadanie było jedno i wykonawca jeden. Przy kilku niezależnych wykonawcach dwóch może sięgnąć po to samo w tej samej chwili.
Atomowe pobranie: mechanizm, który wygląda na szczegół
Ostatnie z tych pytań ma rozwiązanie stare jak systemy kolejkowe i warto je zrozumieć, bo przy grafach agentowych wraca w nowym przebraniu.
Wykonawca nie „bierze zadania”. Wykonawca próbuje je zająć — w jednej operacji, która albo się powiedzie, albo nie, bez stanu pośredniego. Jeśli się powiodła, zadanie jest oznaczone jako jego i nikt inny go nie dostanie. Jeśli nie, sięga po następne.
W przepływie jednościeżkowym problem zwykle nie istnieje, bo nie ma dwóch chętnych. Zaczyna istnieć w momencie, gdy niezależnych wykonawców jest dwóch — i wtedy albo masz mechanizm, albo budujesz go sam.
Bez niego dostajesz syndrom, który u ciebie w Patologii nazywa się „agent zrobił to samo dwa razy” — z tą różnicą, że objaw widzi klient, nie ty. Dwa maile, dwa zamówienia, podwójne obciążenie. W logu wszystko wygląda poprawnie, bo każdy z wykonawców wykonał swoją pracę bez błędu.
Zasada: jeśli dwa węzły mogą sięgnąć po to samo, rozstrzygnięcie musi być atomowe i musi być po stronie magazynu stanu, nie po stronie agenta. Agent poproszony o sprawdzenie, czy ktoś już to wziął, sprawdzi — i między sprawdzeniem a zajęciem zmieści się drugi agent.
Stan a kontekst: rozróżnienie, które oszczędza pieniądze
Wracam do tego z poprzedniego artykułu, bo tutaj ma konsekwencję kosztową.
Stan grafu to prawda o zadaniu. Kontekst węzła to wycinek, który dostał model przy konkretnym wywołaniu.
Odruch przy projektowaniu jest taki, żeby przekazywać całość — jest prościej i nic nie ginie. Konsekwencja: każdy węzeł płaci za cały dotychczasowy dorobek grafu, przy każdym obrocie swojej wewnętrznej pętli. To jest kwadratowy rachunek z pętli, pomnożony przez liczbę węzłów.
Trzy sposoby, żeby to ograniczyć, w kolejności od najprostszego:
Wycinek zamiast całości. Węzeł redagujący nie potrzebuje logów wyszukiwania. Węzeł weryfikujący nie potrzebuje wcześniejszych wersji tekstu, tylko ostatnią i kryteria.
Referencja zamiast treści. Do stanu trafia identyfikator dokumentu, a węzeł pobiera treść wtedy, gdy jej potrzebuje. Kosztuje jedno wywołanie narzędzia więcej i oszczędza tokeny przy każdym obrocie.
Streszczenie na granicy węzła. Węzeł kończąc pracę zapisuje wynik, nie przebieg. Przebieg zostaje w jego logu, do wglądu przy debugowaniu, i nie obciąża nikogo dalej.
Co się dzieje, gdy dwa zapisy się kłócą
Cztery strategie, z których pierwsza jest domyślna i najczęściej zła.
Ostatni wygrywa. Nadpisuje bez pytania. Działa, dopóki nie okaże się, że nadpisany był ten poprawny.
Pierwszy wygrywa. Kolejne zapisy odrzucane. Bezpieczniejsze dla danych, gorsze dla świeżości.
Rozłączne pola. Każdy węzeł pisze wyłącznie do swojej części stanu i czyta cudze bez prawa zapisu. Najnudniejsze i najskuteczniejsze — konflikt nie powstaje, bo nie ma o co.
Rozstrzygnięcie jawne. Konflikt trafia do osobnego węzła, który decyduje. Drogie, ale czasem jedyne sensowne — na przykład gdy dwa węzły ustaliły sprzeczne fakty i któryś musi zostać uznany.
Wybieraj trzecią, dopóki się da. Większość konfliktów w grafach agentowych bierze się nie z natury problemu, tylko z tego, że nikt nie ustalił, kto jest właścicielem którego pola.
Stan przeżywa węzeł — i to jest cały sens
W pętli stan ginął razem z przebiegiem, chyba że sam zadbałeś o zapis. W grafie jest odwrotnie: stan jest tym, co trwa, a węzły są tym, co się kończy.
To ma dwie konsekwencje praktyczne.
Stan musi mieszkać poza procesem wykonawczym. W bazie, w kolejce, w plikach — byle nie w pamięci węzła, bo węzeł się skończy. Brzmi oczywiście, dopóki ktoś nie zbuduje grafu, w którym jeden długo żyjący proces trzyma wszystko i całość przewraca się przy restarcie.
Ciągłość między przebiegami jest domyślna, nie dobudowana. Zadanie może zasnąć na dwa dni i wrócić do przerwanej pracy z zachowanym kontekstem — bo kontekst nie był w procesie, tylko w stanie. To jest, obok podziału ról, główny powód, dla którego ktokolwiek sięga po graf.
Jak to sprawdzić u siebie
Nie potrzeba kodu. Wystarczy tabelka na kartce, wypełniona dla konkretnego procesu.
Wypisz pola stanu — wszystko, co przeżywa pojedynczy węzeł. Przy każdym dopisz trzy rzeczy: kto zapisuje, kto czyta, co się dzieje przy konflikcie.
Trzy sygnały ostrzegawcze:
Jeśli przy którymś polu zapisujących jest więcej niż jeden i nie umiesz odpowiedzieć na trzecie pytanie — masz tam cichy błąd czekający na produkcję.
Jeśli przy większości pól czytających jest „wszyscy” — prawdopodobnie przekazujesz cały stan wszędzie i płacisz za to przy każdym wywołaniu.
Jeśli którejś pozycji nie umiesz przypisać właściciela — to jest kandydat do rozbicia na dwa pola z rozłącznymi właścicielami.
Co dalej
Stan jest, wykonawcy nie wchodzą sobie w drogę. Zostaje sytuacja, w której jeden z węzłów po prostu nie kończy pracy — bo narzędzie zawiodło, model zwrócił bezsens albo proces padł.
W pętli awaria narzędzia była kłopotem jednego przebiegu. W grafie węzeł ma następników, którzy na niego czekają — a niektórzy z nich mogą czekać w nieskończoność.
O tym jest artykuł szósty: Kiedy zawodzi węzeł.
Stan na sierpień 2026. Mechanizmy opisane wyżej — atomowe zajmowanie zadań, strategie rozstrzygania konfliktów, oddzielenie stanu od procesu — pochodzą z systemów kolejkowych i baz danych, nie z narzędzi agentowych. Nowe jest wyłącznie to, że część zapisujących podejmuje decyzje niedeterministycznie.
