Agent kodujący AI skasował agenty AI w n8n. Mamy commit.

Trzy tygodnie temu opublikowaliśmy audyt, w którym prześledziliśmy powtarzaną wszędzie statystykę o 97% awarii aż do tekstu content-marketingowego bez żadnego źródła, a po drodze znaleźliśmy błąd integralności danych w najczęściej powielanym publicznym zbiorze workflow n8n, dający się wskazać co do jednego commita. Zapowiedzieliśmy wtedy, że rozszerzymy to samo narzędzie na najgorętszą obecnie podkategorię n8n: workflow budowane wokół agentów AI.

Zabraliśmy się za budowę tego porównania. Oto, co wydarzyło się zamiast tego.

Szum medialny jest dokładnie taki, jakiego można się spodziewać

Zanim ruszyliśmy dane, spisaliśmy, co obecnie krąży na temat niezawodności agentów AI w n8n. Ten sam wzorzec co ostatnio: konkretne, pewne siebie liczby, prawie żadnych źródeł.

Dwie z nich zasługują na dłuższe zatrzymanie się, bo to nie tylko brak źródła, to ta sama historia. W kwietniu 2026 blog branżowy opisał pięcioosobowy zespół wsparcia obsługujący około 40 powtarzających się pytań (status zamówienia, zwroty, wysyłka), agenta AI w n8n rozwiązującego 78% zgłoszeń bez udziału człowieka, resztę kierowaną do człowieka z dołączonym kontekstem, a twierdzenie skalowano cytatem „across 40+ production systems" (dosłownie: w ponad 40 systemach produkcyjnych), w tych samych trzech branżach w tej samej kolejności: ecommerce, prawo, logistyka. Miesiąc później inna strona opublikowała coś, co czyta się jak ten sam case study pod innym podpisem: ten sam pięcioosobowy zespół, te same ~40 pytań, te same 78%, te same 22% kierowane z kontekstem, identyczne twierdzenie „40+ systems" (dosłownie: ponad 40 systemów), i te same trzy branże w tej samej kolejności.

Żadna ze stron nie podaje nazwy klienta. Żadna nie publikuje liczby zgłoszeń, logów, definicji słowa „rozwiązane" ani punktu odniesienia. Jeden z tych samych dwóch podpisów jest też źródłem zupełnie innego, niemożliwego do zweryfikowania twierdzenia z naszego katalogu, porównania n8n z Zapierem opartego na jednym workflow i bez logów, co oznacza, że to nie jest odosobniona przesada jednej firmy, tylko to samo twierdzenie prane przez strony wyglądające na niezależne, „eksperckie".

Ten wzorzec potwierdził się w reszcie zebranej próbki: z dwunastu konkretnych, opatrzonych datą twierdzeń liczbowych o skuteczności agentów AI w n8n opublikowanych w 2026 roku, dziesięć pochodzi od firmy z bezpośrednim interesem komercyjnym w tym, żeby dane twierdzenie zostało uznane za prawdziwe, a żadne nie publikuje wystarczająco dużo, by samodzielnie odtworzyć wynik: żadnej nazwy klienta, żadnego eksportu logów, żadnego zdefiniowanego mianownika, żadnego punktu odniesienia. Nie nazywamy żadnego z nich fałszywym. Nazywamy je, precyzyjnie, publicznie niemożliwymi do zweryfikowania twierdzeniami strony zainteresowanej. To coś innego, i bardziej użytecznego, niż powiedzieć „fejk".

Spróbowaliśmy zbudować to porównanie. Wyszło zero.

Plan był prosty: podzielić nasz istniejący, przypięty do commita zbiór na workflow używające node'a agenta AI i te, które go nie używają, a potem puścić na obu grupach osobno te same detektory niezawodności co w pierwszym tekście. Ten sam zbiór, który już mieliśmy: Zie619/n8n-workflows, 2 061 plików, przypięty do commita 94007c1445d9.

Odfiltrowaliśmy prawdziwe typy node'ów AI w n8n: @n8n/n8n-nodes-langchain.agent i pokrewne.

Zero pasujących plików.

To niemała liczba jak na zbiór tej wielkości: to zbiór, który, sądząc po typach node'ów, w ogóle nie zawiera workflow z agentami AI. Co nie zgadzało się z niczym, co wiedzieliśmy o tym korpusie ani o tym ekosystemie, więc zanim uznaliśmy to za „adopcja AI w n8n jest niższa, niż się spodziewano", sprawdziliśmy po innym sygnale: po nazwach node'ów zamiast po ich typach. Node nazwany przez kogoś „AI Agent: Movie Recommendation" albo „OpenAI Chat Model" nie budzi wątpliwości co do tego, czym ma być, niezależnie od tego, co mówi jego pole typu.

711 z 2 061 plików (34,5%) zawiera co najmniej jeden node, którego nazwa jednoznacznie opisuje funkcję AI albo LLM. W tych plikach policzyliśmy każdy pojedynczy node pasujący do tego wzorca: 1 573 node'y. Z tego 1 457, czyli 92,6%, ma typ n8n-nodes-base.noOp, czyli dosłowny placeholder n8n „nic nie rób". Node nadal jest w pliku. Jego nazwa jest nietknięta. Jego funkcja zniknęła.

Ten commit

Prześledziliśmy to tak samo, jak wcześniej błąd grafu połączeń w pierwszym tekście: czytając pełną, publiczną historię commitów repozytorium źródłowego, a nie tylko przypięty zrzut.

W najwcześniejszym commicie dotykającym jednego przykładowego pliku (5 sierpnia 2025, prawdziwy kontrybutor) typy node'ów są poprawne i konkretne: @n8n/n8n-nodes-langchain.agent dla node'a AI Agent, @n8n/n8n-nodes-langchain.lmChatOpenAi dla OpenAI Chat Model, @n8n/n8n-nodes-langchain.memoryBufferWindow dla jego pamięci. Prawdziwy, działający, poprawnie otypowany workflow agenta AI w n8n.

Te typy przechodzą przez kolejny commit bez zmian, ten sam, w którym po raz pierwszy pojawiają się spreparowany node „Error Handler" i szablonowy node „Workflow Documentation", opisane przez nas w pierwszym tekście, co przy okazji potwierdza, że te dwa błędy wprowadzono osobno, nie w tym samym przebiegu.

Nie przechodzą już przez następny commit: 3c0a92c4 z 29 września 2025, scalający pull request, którego własny opis w części czyta się jak losowa zbitka komunikatów-placeholderów (fraza „Initial plan", dosłownie: plan wstępny, pojawia się w nim cztery razy), budujący przy okazji niezwiązaną z tym infrastrukturę Docker i Kubernetes. Wśród współautorów commita widnieje Co-authored-by: copilot-swe-agent[bot] obok ludzkiego konta na GitHubie. W tym jednym commicie zmieniło się 2 057 plików workflow. W przykładowym pliku każdy node typu LangChain (agent, model czatu, trzy osobne node'y embeddingów OpenAI w innym sprawdzonym przez nas pliku) zamienia się w n8n-nodes-base.noOp. Nazwa node'a jest nietknięta w każdym sprawdzonym przez nas przypadku. Nadpisane zostało wyłącznie pole, które mówi n8n, co dany node faktycznie robi.

Sprawdziliśmy to niezależnie na trzech plikach; wszystkie trzy pokazują identyczny wzorzec, w identycznym commicie. Potwierdziliśmy, że ten commit jest bezpośrednim przodkiem zrzutu, do którego przypięta jest nasza analiza; nic pomiędzy nimi tego nie naprawia.

Nie przypisujemy tego niczyjej indywidualnej decyzji i nie wiemy, czy ktokolwiek zweryfikował ten konkretny diff przed scaleniem. To, co możemy stwierdzić wprost: autorstwo autonomicznego agenta kodującego jest przypisane do commita, który, robiąc przy okazji coś zupełnie innego, po cichu skasował definicję funkcjonalną dokładnie tej kategorii node'ów, którą musiałoby policzyć każde badanie „agentów AI w n8n".

Dlaczego to gorsze, niż brzmi, dla każdego, kto korzysta z tego zbioru

Ten sam test puściliśmy na naszym drugim, niezależnie licencjonowanym zbiorze: enescingoz/awesome-n8n-templates (licencja CC BY 4.0), bez wspólnej historii z pierwszym. 226 z 342 plików (66,1%) ma nazwy node'ów sugerujące AI. Każdy odpowiadający im typ node'a jest nietknięty: prawdziwe typy agent, lmChatOpenAi, lmChatAnthropic, lmChatGoogleGemini, embeddingsOpenAi, zero podmienionych na noOp. Cokolwiek stało się w zbiorze podstawowym, jest właściwością historii tego konkretnego repozytorium, a nie tego, jak n8n eksportuje workflow z agentami AI.

To już trzeci, niezależnie potwierdzony przez nas błąd jakości danych w zbiorze podstawowym, i każdy z nich jest niewidoczny dla innego rodzaju sprawdzenia. Błąd grafu połączeń, o którym pisaliśmy wcześniej, nie wyjdzie w skanie bezpieczeństwa, bo referencje donikąd nie tworzą żadnej ścieżki do wykorzystania. Ten nie wyjdzie w naiwnym liczeniu node'ów AI/LLM po nazwie, bo nazwy zostały nietknięte; zniknęło tylko pole, po którym faktycznie kluczowałoby automatyczne liczenie. Każdy, kto zrobił albo planuje zrobić analizę „ile workflow n8n używa agentów AI" na tym konkretnym repozytorium z ponad 56 tysiącami gwiazdek, filtrując po typie node'a, niemal na pewno zaniżył liczbę, być może bliską zmierzonym przez nas 92,6%.

Co udało nam się jeszcze zmierzyć

Skoro dane o node'ach AI ze zbioru podstawowego są bezużyteczne do tego konkretnego porównania, puściliśmy analizę na czystym zbiorze: mniejszym, ale wiarygodnym. Te same detektory co w pierwszym tekście, te same definicje, żadnego nowego kodu:

Powiemy wprost, czego się spodziewaliśmy na starcie: że workflow z agentami AI, jako nowsze i bardziej eksperymentalne, pokażą gorszą dyscyplinę obsługi błędów niż zwykła automatyzacja. To niekoniecznie to, co pokazują dane. Na kilku sygnałach grupa z AI wypada o kilka punktów wyżej, nie niżej. Przy uwierzytelnianiu webhooków, już i tak bliskim powszechności w obu grupach, grupa z AI wypada nieco gorzej, ale liczby bazowe (odpowiednio 46 i 22 workflow z webhookiem) są zbyt małe, żeby się na nich mocno opierać.

Podajemy to uczciwie, zamiast naginać do bardziej dramatycznej historii, jakiej może się spodziewaliśmy. Na tym jednym zbiorze, przy tej wielkości próby, nie widzimy wyraźnego dowodu, że workflow z agentami AI są konfigurowane mniej starannie niż zwykła automatyzacja. Nie mamy też większej próby ze zbioru podstawowego, żeby to zestawić, z powodu opisanego wyżej. Traktuj tę tabelę jako pierwsze podejście, nie ostateczną odpowiedź; wrócimy do tego, jeśli pojawi się większy, czysto otypowany publiczny zbiór.

Czego świadomie nie twierdzimy

• Werdyktu o niezawodności agentów AI w ogóle. Mierzymy skonfigurowane zabezpieczenia w publikowanych szablonach, na jednym zbiorze, przy n=342. To nie jest badanie działania na produkcji ani badanie na dużej próbie.
• Intencji stojącej za tym commitem. Możemy stwierdzić, co się zmieniło, w którym commicie i z jakim przypisanym autorstwem. Nie możemy stwierdzić dlaczego, ani czy ktokolwiek to zweryfikował.
• Że dwanaście skatalogowanych przez nas twierdzeń marketingowych jest zmyślonych. Stwierdzamy, że w opublikowanej formie są niemożliwe do zweryfikowania przez zewnętrznego czytelnika, co jest twierdzeniem węższym i łatwiejszym do obrony.

Jak to powtórzyć u siebie

Ten sam otwarty pipeline co poprzednio, teraz z detektorem erozji node'ów i podziałem na kohorty w drugim zbiorze: github.com/adix65/n8n-reliability.

python3 -m n8n_reliability.cli fetch-corpus --dest data/corpus/n8n-workflows
python3 -m n8n_reliability.cli analyze --corpus-dir data/corpus/n8n-workflows --out-dir out

Każda liczba powyżej ma licznik, mianownik i commit albo ścieżkę pliku, z którego pochodzi, w repozytorium. Jeśli któregoś procentu z tego tekstu nie da się sprowadzić do tych trzech rzeczy, to błąd w tekście, a nie fakt o n8n albo o agentach kodujących AI.

SEVENEDGE buduje i utrzymuje automatyzacje n8n na serwerach klientów, obok programów pisanych na zamówienie. Ten tekst jest analizą statyczną publicznie udostępnionych plików workflow i publicznie dostępnej historii commitów, a nie twierdzeniem o systemie któregokolwiek klienta ani oceną ogólnej niezawodności któregokolwiek agenta kodującego.