Cztery elementy, z których trzeci sprawia najwięcej kłopotu, a czwarty jest pomijany najczęściej.
Odpowiedź „graf składa się z agentów” jest niepełna i prowadzi na manowce. Prowadzi do architektury, w której wszystko, co się dzieje, jest czyimś rozumowaniem — czyli do systemu droższego, wolniejszego i mniej przewidywalnego, niż musiał być.
Graf wykonania ma cztery elementy. Trzy z nich mają odpowiedniki w pętli, więc będą znajome. Czwarty w pętli nie istnieje i dlatego bywa dobudowywany na końcu, gdy jest już za późno.
Węzeł: co istnieje
Węzeł to miejsce, w którym coś się wykonuje. Nie musi być agentem i najczęściej nie powinien.
Agent. Prowadzi własną pętlę, sam decyduje o krokach. Drogi, wolny, niepowtarzalny w wyniku. Używasz go tam, gdzie potrzebny jest osąd.
Funkcja deterministyczna. Zwykły kod. Pobranie danych, przeliczenie, zapis, wysyłka. Tani, szybki, dający ten sam wynik za każdym razem. Większość węzłów w dobrze zaprojektowanym grafie to właśnie ten typ.
Router. Podejmuje jedną decyzję: dokąd dalej. Może być warunkiem w kodzie albo wywołaniem modelu z jednym pytaniem. Rozdzielenie routingu od pracy jest jedną z niewielu rzeczy, które warto zrobić od razu — bo wtedy widać w logu, dlaczego graf poszedł tą, a nie inną ścieżką.
Złączenie. Czeka na kilka wejść i scala je w jedno. Wygląda niewinnie, dopóki nie okaże się, że jedno z wejść nigdy nie przyjdzie.
Punkt zatwierdzenia. Zatrzymuje wykonanie i czeka na człowieka. Jedyny typ węzła, którego niezawodność spada z częstotliwością użycia — o tym jest osobny artykuł w tym torze.
Praktyczna zasada przy projektowaniu: jeśli węzeł da się zrobić funkcją, zrób go funkcją. Agent w miejscu, gdzie wystarczy if, to koszt bez korzyści i jedno miejsce mniej, w którym rozumiesz, co się stało.
Krawędź: co wolno po czym
Krawędź to nie strzałka na diagramie, tylko odpowiedź na pytanie, jakie przejścia są dozwolone i kto komu może przekazać pracę.
Dwie rzeczy warto tu rozdzielić, bo mieszają się notorycznie.
Krawędź dozwolona to część projektu: z węzła A można przejść do B albo do C, nigdzie indziej. To jest granica, którą ustalasz z góry — nawet w grafie, w którym droga powstaje w trakcie.
Krawędź wybrana to rozstrzygnięcie w czasie działania: tym razem poszliśmy do C. To jest to, co odróżnia graf wykonania od grafu przepływu — nie brak reguł, tylko to, że wybór spośród nich zapada w trakcie.
Konsekwencja, którą warto zapisać: graf agentowy nie znaczy „agent robi, co chce”. Znaczy, że wybiera spośród przejść, na które pozwoliłeś. Jeśli twój graf pozwala na wszystko z wszystkiego, nie zbudowałeś grafu — zbudowałeś jedną wielką pętlę z dodatkowymi kosztami.
Stan: co płynie po krawędziach
Tu zaczynają się kłopoty, bo w pętli stan był prosty: historia rosła, wszystko trafiało do kontekstu, model nie pamiętał niczego, a ciągłość utrzymywał kod.
W grafie stan ma trzy właściwości, których w pętli nie miał.
Jest współdzielony. Kilka węzłów czyta i zapisuje to samo. Powstaje pytanie, którego wcześniej nie było: co się dzieje, gdy dwa zapisy dotyczą tego samego pola.
Przeżywa węzeł. Węzeł się kończy, stan zostaje. To dobrze — na tym polega ciągłość między przebiegami. Ale znaczy też, że stan musi mieszkać poza procesem wykonawczym, czyli w bazie albo kolejce, a nie w pamięci.
Nie jest tym samym co kontekst. To jest rozróżnienie, które warto wbić na stałe. Stan grafu to prawda o zadaniu. Kontekst węzła to to, co dostał model przy konkretnym wywołaniu. Węzeł zwykle dostaje wycinek stanu, nie całość — i decyzja o tym, który wycinek, jest osobną decyzją projektową o dokładnie takich samych konsekwencjach kosztowych jak w pętli.
Praktycznie: jeśli każdy węzeł dostaje cały stan, płacisz kwadratowy rachunek pomnożony przez liczbę węzłów. To jest najczęstszy sposób, w jaki graf robi się nieprzyzwoicie drogi.
Granice uprawnień: czego nie wolno, niezależnie od decyzji
Czwarty element, w pętli nieobecny, bo pętla ma jeden zestaw uprawnień i nie ma czego rozdzielać.
W grafie każdy węzeł może mieć własne: inny model, innego dostawcę, inny katalog roboczy, inną politykę sieciową, inny zestaw narzędzi. I to nie jest funkcja, którą ktoś dobudował — przy architekturze, w której każdy węzeł jest osobnym procesem, heterogeniczność jest konsekwencją, nie dodatkiem.
Scenariusz, który to unaocznia: większość węzłów działa na modelu lokalnym, w kontenerze bez wyjścia do sieci, na plikach. Jeden ma dostęp do internetu i zapisuje wyniki do współdzielonego katalogu. Węzeł analizujący czyta ten katalog i nie ma jak niczego wysłać, bo jego kontener nie ma ścieżki na zewnątrz.
Kluczowe jest to, gdzie mieszka ograniczenie. Instrukcja w prompcie to życzenie — agent poproszony o dane, których nie ma, będzie ich szukał każdą dostępną drogą. Odcięty ruch wychodzący to fakt.
Ta sama zasada dotyczy budżetu. Sprawdzenie limitu przed uruchomieniem węzła jest granicą. Raport o przekroczeniu po fakcie jest sprawozdaniem.
Z jednym zastrzeżeniem, którego nie wolno pominąć: hamulec zewnętrzny jest wart tyle, ile zabezpieczenie panelu, który nim steruje. Opisywaliśmy na cyberflux.pl łańcuch wywołań dający nieuwierzytelnionemu atakującemu kontrolę nad instancją orkiestratora — a więc również nad wszystkimi budżetami, które w niej ustawiono.
Jak to sprawdzić u siebie
Weź proces, o którym myślisz, i wypisz go w czterech kolumnach, zanim cokolwiek zaimplementujesz. Kartka wystarczy.
Węzły — wypisz je i przy każdym dopisz typ. Policz, ile z nich to agenty. Jeśli więcej niż połowa, wróć i sprawdź, które dałoby się zamienić na funkcję.
Krawędzie — dla każdego węzła wypisz, dokąd wolno przejść. Jeśli przy którymś napiszesz „wszędzie”, masz tam problem projektowy, nie elastyczność.
Stan — wypisz pola, które przeżywają pojedynczy węzeł. Przy każdym zaznacz, kto zapisuje. Jeśli zapisujących jest więcej niż jeden, to jest miejsce na konflikt.
Granice — przy każdym węźle dopisz, czego mu nie wolno. Jeśli przy którymś nie umiesz nic wpisać, to znaczy, że wolno mu wszystko.
Ostatnia kolumna jest zwykle najbardziej pusta i zwykle najbardziej potrzebna.
Co dalej
Cztery elementy opisują graf statycznie. Zostaje pytanie, które w tym artykule pojawiło się przy krawędziach i zostało odłożone: kto właściwie rozstrzyga, którą krawędzią pójdzie wykonanie — i co się zmienia, gdy decyzja zapada z góry, a co, gdy w trakcie.
To jest jedyna różnica, która naprawdę dzieli dwa podejścia do orkiestracji, i od niej zależy koszt, przewidywalność i sposób debugowania całości.
O tym jest artykuł czwarty: Kto rysuje krawędź — z góry czy w trakcie.
Stan na sierpień 2026. Podział na cztery elementy jest uogólnieniem z dokumentacji narzędzi orkiestrujących i z opracowań branżowych — poszczególne frameworki nazywają je różnie i nie wszystkie wyodrębniają granice uprawnień jako osobną warstwę.
