Dlaczego rozmowa o inżynierii grafów rozjeżdża się po trzech zdaniach i jak rozpoznać, o którym grafie mówi twój rozmówca.
Dwie osoby rozmawiają o grafach w agentach. Pierwsza ma na myśli schemat w n8n. Druga zespół agentów, które same ustalają, kto co robi. Trzecia, gdyby dołączyła, myślałaby o encjach i relacjach w bazie wiedzy.
Wszystkie trzy używają tego samego słowa i wszystkie trzy mają rację. To nie jest spór o definicję — to trzy różne problemy, które przypadkiem dostały jedną nazwę.
Ten artykuł je rozdziela, bo bez tego reszta toru byłaby rozmową o niczym.
Skąd wzięło się zamieszanie
Określenie graph engineering rozeszło się w lipcu 2026 i w kilka tygodni trafiło do tytułów przewodników, ofert szkoleniowych i opisów narzędzi. Nazwa jest świeża, jej znaczenie nieustalone, a różni autorzy przypisują jej różne zakresy.
Warto od razu powiedzieć rzecz, którą powtarza większość uczciwych opracowań: nie pojawiła się żadna nowa zdolność. Orkiestracja grafowa działała w LangGraph, AutoGen i Google ADK na długo przed powstaniem terminu. Nowe jest słownictwo, nie technika.
To nie znaczy, że nazwa jest bezwartościowa. Znaczy, że opisuje coś, co już robiłeś — i dlatego warto wiedzieć, co dokładnie.
Graf pierwszy: przepływ deterministyczny
Rysujesz go sam, z góry, w całości.
Trigger odpala, dane płyną po przewodach, a każde rozgałęzienie to warunek, który ktoś zakodował wcześniej. Wynik jest powtarzalny, koszt policzalny przed uruchomieniem, a debugowanie polega na przejściu ścieżki, którą widać na ekranie.
To jest n8n, Zapier, Make, Airflow. To jest też każdy workflow, który narysowałeś w Miro, zanim cokolwiek zaimplementowałeś.
Ważne: taki graf może zawierać krok inteligentny i nadal pozostaje deterministyczny. Węzeł AI Agent w n8n prowadzi własną pętlę, wybiera narzędzia i decyduje, kiedy skończyć — ale wszystko dookoła niego jest schematem, który zaprojektował i utrzymuje człowiek. Inteligentny krok wewnątrz maszyny, która sama inteligentna nie jest.
Większość ludzi, mówiąc „graf”, ma na myśli właśnie ten. I najczęściej mają rację co do własnego przypadku.
Graf drugi: wykonanie agentowe
Tu krawędzie nie są narysowane z góry. Definiujesz cel i obsadę, a droga do celu powstaje w trakcie.
Węzły mają mandaty, nie instrukcje krok po kroku. Jeden agent bada, drugi recenzuje, trzeci decyduje, czy praca może pójść dalej. To, który zadziała następny, rozstrzyga się w czasie działania — na podstawie tego, co znaleziono po drodze.
Ten graf odpowiada na inne pytanie niż pętla. Pętla pyta: czy ten wykonawca ma kontynuować. Graf pyta: który wykonawca zadziała następnie, z jakim stanem i pod jakimi warunkami.
To jest znaczenie, które branża miała na myśli, nadając nazwę w lipcu. Praktycznie: Paperclip, wielagentowe tryby w LangGraph, zespoły agentów w AutoGen.
I to jest znaczenie, o którym jest ten tor.
Graf trzeci: wiedza
Encje i relacje. Węzeł to firma, osoba, produkt albo dokument. Krawędź to typ powiązania: zależy od, zastępuje, zostało zdecydowane przez.
Agent nie wykonuje się po tym grafie — porusza się po nim, szukając odpowiedzi. Zamiast przeszukiwać płaskie dokumenty po podobieństwie, skacze po powiązaniach.
To jest GraphRAG, pamięć agenta oparta na grafie, Evidence Graph. Dyscyplina starsza od całego zamieszania o kilka lat i mająca własną, dojrzałą literaturę.
Ten graf opisuje, co system wie. Drugi opisuje, czym system jest. To samo słowo, niepowiązany problem.
Dlaczego to nie jest spór akademicki
Bo pomyłka kosztuje konkretnie.
Jeśli szukasz rozwiązania dla drugiego grafu, a trafisz na materiały o trzecim, dostaniesz architekturę bazy wiedzy zamiast orkiestracji — i odwrotnie. Jeśli twój problem należy do pierwszego grafu, a ktoś sprzeda ci drugi, kupisz zmienny koszt, niepowtarzalny wynik i trudniejszy debug w zamian za elastyczność, której nie potrzebujesz.
Najczęstszy błąd idzie właśnie w tę stronę: większość procesów, które nazywamy dziś agentem AI, to deterministyczne przepływy z krokiem LLM w środku. Te należą do grafu pierwszego. Wstawianie tam orkiestratora zespołowego to komplikowanie czegoś, co działało.
Sięganie po graf agentowy, zanim praca do tego zmusi, to kupowanie sobie problemu systemów rozproszonych, którego się wcześniej nie miało.
Jak sprawdzić, o którym grafie mówisz
Trzy pytania, po jednym na każde znaczenie. Odpowiedz na nie o konkretnym procesie, nie o kategorii.
Czy potrafisz narysować ten proces w całości, z góry, ze wszystkimi rozgałęzieniami? Tak → graf pierwszy. Nie potrzebujesz niczego więcej i nie potrzebujesz tego toru.
Czy droga zależy od tego, co znajdziecie po drodze — i czy pracę wykonuje więcej niż jedna rola? Tak → graf drugi. Sprawdź jeszcze trzy warunki: praca trwa dłużej niż jeden przebieg, wymaga budżetu i wymaga śladu audytowego. Jeśli na wszystkie trzy odpowiedź brzmi „nie”, prawdopodobnie wystarczy pojedynczy agent bez orkiestratora.
Czy pytanie brzmi „jak agent ma znaleźć odpowiedź w naszych danych”, a nie „kto ma ją znaleźć”? Tak → graf trzeci. To jest temat na context engineering, nie na ten tor.
I odpowiedź czwarta, najczęstsza w praktyce: nie wiem, bo nigdy tego procesu nie opisałem. Wtedy problemem nie jest wybór grafu. Zacznij od opisania procesu — bardzo często okazuje się wtedy, że jest deterministyczny i cała rozmowa o agentach była przedwczesna.
Nazewnictwo, którego używam w tym torze
Żeby nie mnożyć niejasności, w kolejnych artykułach trzymam się jednego zestawu określeń:
- graf przepływu — krawędzie ustalone z góry, deterministyczny,
- graf wykonania — krawędzie rozstrzygane w trakcie, agentowy,
- graf wiedzy — encje i relacje, bez wykonania.
Kiedy piszę „graf” bez przymiotnika, chodzi o graf wykonania. Angielskie źródła zwykle rozdzielają tylko dwa ostatnie i pomijają pierwszy — moim zdaniem niesłusznie, bo to właśnie on jest domyślnym skojarzeniem większości czytelników.
Zaproponowany podział jest narzędziem, nie taksonomią. W praktyce systemy budowane są hybrydowo: graf przepływu może zawierać węzeł, który wewnętrznie prowadzi własny graf wykonania. Węzeł grafu wykonania może sięgać po graf wiedzy jako źródło. Ta sama struktura bywa też czytana różnie w zależności od tego, o co pytasz — zapis kolejności kroków jest grafem przepływu dla wykonawcy i grafem wiedzy dla tego, kto analizuje, co się wydarzyło.
Rozróżnienie ma sens dopóty, dopóki pomaga ustalić, o czym rozmawiacie. Kiedy zaczyna wymuszać przypisanie czegoś do jednej szufladki na siłę, przestaje być przydatne.
Co dalej
Skoro wiadomo już, o którym grafie mowa, zostaje pytanie, które w tym artykule padło tylko w formie testu: kiedy jedna pętla przestaje wystarczać.
Odpowiedź nie brzmi „gdy zadanie jest skomplikowane”. Skomplikowane zadania da się prowadzić jedną pętlą i zwykle tak jest taniej. Granica leży gdzie indziej i da się ją wskazać precyzyjnie.
O tym jest artykuł drugi: Kiedy pętla przestaje wystarczać.
Stan na sierpień 2026. Termin „inżynieria grafów” ma kilka miesięcy i jego znaczenie nie jest ustalone — opis powyżej jest próbą uporządkowania, a nie relacją z konsensusu, którego nie ma.
