Ten skrypt nie kasował AI w n8n. Kasował znak @.

Każdy typ node'a, który ten zbiór stracił, zaczyna się od tego samego znaku: @. Każdy typ node'a, który przetrwał, zaczyna się od n8n-nodes-. Nie ma trzeciej grupy, nie ma części wspólnej i nie ma w tym commicie ani jednego wyjątku. To, co usunęło node'y AI w n8n, nie było filtrem rozpoznającym AI. To była reguła, która nie umiała przeczytać nazwy pakietu npm ze scope'em.

Ten tekst robi trzy rzeczy. Koryguje liczbę, którą sami opublikowaliśmy, pokazuje faktyczną regułę i mówi, gdzie oryginalne typy node'ów nadal istnieją oraz na jakich warunkach można z nich skorzystać.

Liczba, którą podaliśmy źle

Zaczynamy od korekty, bo cała reszta tekstu na niej stoi.

W poprzednim tekście napisaliśmy, że w tym zbiorze skasowano 92,6% node'ów AI: 1 457 z 1 573. Arytmetyka była poprawna i wniosek pod nią też. Mianownik był za wąski jak na zdanie, które na nim zawiesiliśmy.

1 573 to liczba node'ów, których nazwa brzmi jak AI: wszystko, co człowiek podpisał jako „AI Agent", „OpenAI Chat Model", „Embeddings" i tak dalej. Tylko taki sygnał mieliśmy wtedy do dyspozycji, bo w zrzucie, do którego przypięta była analiza, pola z typami już nie istniały. Uczciwe odczytanie tamtej liczby jest więc wąskie: spośród node'ów, które dało się jeszcze rozpoznać po nazwie, 92,6% straciło swój typ. Nie odpowiada ona na pytanie, na które czytelnik ma prawo sądzić, że odpowiada, czyli ile node'ów skasowano w sumie. Procent, którego mianownikiem jest heurystyka od nazw, znaczy mniej, niż wygląda, a ta seria działa tylko wtedy, gdy z każdą liczbą w niej da się pospierać o mianownik.

Właściwy pomiar w ogóle nie potrzebuje nazw.

Pomiar node po node

Wyciągnęliśmy przez git archive drzewo workflows/ z dwóch commitów: baf2dfff (rodzic) i 3c0a92c4 (commit, który je zmienił). Po 2 057 plików z każdej strony, 2 057 obecnych w obu. Dla każdego node'a w każdym pliku dopasowaliśmy go między drzewami po polu id, a potem porównaliśmy pole type tego samego node'a przed i po. Żadnego dopasowania po nazwie, żadnej heurystyki, żadnego próbkowania. Każdy node w zbiorze, po obu stronach jednego commita.

3 977 node'ów, których typ zaczynał się od @, zostało zamienionych na n8n-nodes-base.noOp, w 759 z 2 057 plików (36,9%, mianownik: pliki workflow obecne w obu drzewach). Dwa kolejne node'y zmieniły się z prefiksu CUSTOM., konkretnie CUSTOM.klicktipp i CUSTOM.klicktippTrigger. Razem 3 979 node'ów.

W rozbiciu na scope'y npm zamienione node'y wyglądają tak:

A to dwanaście typów node'ów LangChain, które straciły ich najwięcej:

To 461 node'ów agenta, 632 node'y modelu czatu i 217 node'ów pamięci, które w jednym commicie przestały być agentami, modelami czatu i pamięcią, zachowując nazwy nadane im przez autorów.

Co przetrwało, i dlaczego to jest całe znalezisko

Potem puściliśmy to samo porównanie w drugą stronę. Nie co się zmieniło, tylko co się nie zmieniło.

Lista prefiksów, które zostały zamienione, ma dokładnie dwie pozycje: @ i cokolwiek dalej, oraz CUSTOM..

Ani jeden typ node'a zaczynający się od @ nie przeszedł tego commita. Ani jeden typ zaczynający się od n8n-nodes- nie został zamieniony. Żaden prefiks nie występuje na obu listach. Mając sam tekst typu node'a, przewidzisz, czy ten commit go zostawił, czy zamienił, nie wiedząc nic o tym, co ten node robił, jak się nazywał ani w którym pliku siedział. Na tym polega różnica między regułą a bałaganem, a to jest reguła.

Co ta reguła faktycznie robiła

npm ma dwa sposoby nazywania pakietu. Nazwa bez scope'u wygląda tak: n8n-nodes-mcp. Nazwa ze scope'em wygląda tak: @n8n/n8n-nodes-langchain, gdzie część przed ukośnikiem to przestrzeń nazw organizacji, a wiodące @ jest obowiązkowym elementem składni, nie ozdobnikiem. Typ node'a w n8n zapisuje się jako nazwa pakietu, kropka i własna nazwa node'a, więc typ ze scope'em nosi to @ na początku tekstu.

Walidator napisany jako „przyjmij nazwę pakietu pasującą do n8n-nodes-*, a resztę podmień na placeholder" daje dokładnie te dwie tabele powyżej. On nie patrzy na to, co node robi. Patrzy na pierwszy znak.

I tu jest rzecz, przy której warto się zatrzymać. n8n trzyma wszystkie swoje oficjalne node'y AI w jednym pakiecie ze scope'em, @n8n/n8n-nodes-langchain. Node'y społeczności, pisane przez pojedynczych autorów, publikuje się zwykle bez scope'u, jako n8n-nodes-<coś>. Reguła skasowała więc każdy oficjalny node AI od n8n w tym zbiorze, a zostawiła na miejscu każdy node społeczności: n8n-nodes-mcp, n8n-nodes-klicktipp, n8n-nodes-hdw i resztę, napisane przez ludzi bez żadnego związku z firmą n8n. Skasowane zostały dokładnie te pakiety, które trzymały się konwencji npm dla kodu firmowego. Te, które się jej nie trzymały, przeszły nietknięte.

Na @n8n przypada 3 951 z 3 977 zamienionych node'ów o typie zaczynającym się od @, czyli 99,3% (mianownik: node'y o typie z prefiksem @ zamienione w tym commicie). To jest cały powód, dla którego te zniszczenia wyglądają na atak na AI. To nie jest fakt o AI. To jest fakt o tym, gdzie n8n trzyma swoje node'y AI.

Nie doszliśmy do tego odczytania sami. Po publikacji poprzedniego tekstu komentujący na r/n8n, użytkownik LennyFromCurly, podsunął, że przyczyną jest resolver pakietów, a nie cokolwiek związanego z AI. Wróciliśmy do drzew, żeby to sprawdzić, i tabele prefiksów powyżej są tym sprawdzeniem. Hipoteza jest jego i się broni.

Jak dziś wyglądają cztery kopie

Zrobiliśmy spis typów na aktualnym stanie czterech repozytoriów, w których żyje ten zbiór.

Jedna uwaga metodologiczna, zanim ktokolwiek użyje tej pierwszej kolumny do czegoś. 393 node'y noOp występują też w kopiach sprzed defektu. noOp w n8n to prawdziwy node, który ludzie świadomie wstawiają do workflow: jako punkt zbiegu, zaślepkę albo podpisaną gałąź, która celowo nic nie robi. Liczenie node'ów noOp nie jest więc testem na korupcję danych: w tym zbiorze 393 z nich to czyjaś decyzja projektowa, a nie uszkodzenie. To jest pułapka w oczywistym sprawdzeniu i dlatego mierzyliśmy różnicę na jednym commicie, zamiast liczyć placeholdery w zrzucie.

Jak odzyskać oryginalne typy

44510/n8n-workflow nadal ma oryginalne typy node'ów. Jego HEAD, 578cbef8, to obiekt gita obecny w historii samego Zie619, co czyni go forkiem zrobionym przed defektem, a nie niezależnym scrape'em tych samych workflow. To mocniejszy dowód pochodzenia niż data commita, bo datę może wpisać każdy, a wspólnego obiektu nie.

Wszystko poniżej jest warunkiem do tego zdania, nie przypisem do niego.

• Nie nazywamy tego repozytorium czystym ani działającym. Twierdzenie, którego bronimy, jest węższe: nie jest dotknięte dwoma defektami opisanymi w tej serii. Nie audytowaliśmy go pod kątem niczego innego.
• Nie ma w HEAD wykrytej licencji. Bez licencji domyślnie obowiązują pełne prawa autorskie. Czytaj, porównuj, użyj do odtworzenia oryginalnego typu node'a, którego już masz u siebie. To nie jest źródło do redystrybucji i nie wskazujemy go jako takie.
• Ma własny problem: 48 referencji połączeń, które prowadzą donikąd, całkowicie osobnych od 27 525, o których pisaliśmy przy commicie 5ffee225 w pierwszym tekście tej serii. Wygląda to na wcześniejszy i niezwiązany z tym defekt. Nie prześledziliśmy jego przyczyny i żadnej nie proponujemy.
• Data ostatniego commita nie przewiduje tu niczego. Tym, co przewiduje, czy kopia jest dotknięta, jest pochodzenie jej drzewa gita albo SHA, które da się porównać ze znanym. Jeśli wybierasz kopię do pracy, to jest pytanie, które trzeba jej zadać.
• Cztery repozytoria to nie jest badanie. Zie619/n8n-workflows ma około 7,6 tys. forków. Sprawdziliśmy w sumie cztery repozytoria, więc nie mamy obrazu reszty i niczego na nią nie rozciągamy.

Jeśli potrzebujesz odzyskać jeden node, nie potrzebujesz nic z tego: tekst typu jest krótki, a kiedy już wiesz, że node podpisany „AI Agent" był typu @n8n/n8n-nodes-langchain.agent, wpiszesz go ręcznie. Powód, żeby w ogóle sięgać po drzewo sprzed defektu, pojawia się wtedy, gdy potrzebujesz też parametrów, bo one poszły razem z typem.

Nie jesteśmy pierwsi, którzy to zauważyli

Warto być tu precyzyjnym co do tego, kto co znalazł, bo ta seria jest po części sporem o podawanie źródeł.

Nie jesteśmy pierwszymi ludźmi, którzy zauważyli, że z tym zbiorem jest coś nie tak. Zgłoszenie #123 w tym repozytorium, otwarte 9 października 2025, opisuje workflow przychodzące z pustymi połączeniami. Komentarz w tym wątku z 5 listopada 2025 stwierdza, że problem nadal występuje po naprawie, która miała go zamknąć, co zgadza się z tym, co znaleźliśmy w historii plików: commit 5ffee225 z 3 listopada 2025 to ten, który ogłosił naprawę i zostawił referencje wskazujące na node'y, których już tam nie było. Zgłoszenie #125, otwarte 20 października 2025, opisuje workflow, które po imporcie nie działają.

Użytkownicy zgłaszają więc objawy od blisko roku. Brakowało nigdy nie obserwacji. Brakowało mianownika i mechanizmu. Nikt nie policzył, ilu node'ów to dotyczy, i nikt nie nazwał reguły, która to zrobiła. To jest część, którą dokładamy, i jest to mniejszy wkład niż „odkryliśmy to", czyli zdanie, którego świadomie nie piszemy.

Czego świadomie nie twierdzimy

• Niczyjej intencji. Możemy stwierdzić, które typy node'ów się zmieniły, w którym commicie i w którą stronę. Nie możemy stwierdzić, po co ta reguła istniała, czy miała się w ogóle uruchomić na tych danych ani czy ktokolwiek przeczytał ten diff. Dotyczy to tak samo ludzi, jak i narzędzi.
• Że ta reguła wiedziała, czym jest AI. Dane mówią coś przeciwnego: kluczowała po pierwszym znaku nazwy pakietu i trafiła w LangChain, bo tam n8n trzyma swoje node'y AI.
• Obrazu sieci forków. Cztery repozytoria z około 7,6 tys. forków to cztery repozytoria.
• Że którakolwiek kopia jest czysta. Sprawdziliśmy dwa konkretne defekty i podaliśmy, co te sprawdzenia zwróciły.
• Przyczyny 48 referencji donikąd w 44510/n8n-workflow. Znaleźliśmy je, nie prześledziliśmy ich.

Jak to powtórzyć u siebie

Porównanie drzew, spis prefiksów i zliczenie typów w czterech repozytoriach siedzą w tym samym otwartym pipelinie co dwa poprzednie teksty: 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 w tym tekście ma licznik, mianownik i opisaną słowami definicję tego mianownika, łącznie z tą, po którą wróciliśmy, żeby ją poprawić. Jeśli któregoś procentu stąd nie da się sprowadzić do tych trzech rzeczy, potraktuj to jako błąd w tekście, a nie fakt o n8n. Ten standard jest powodem, dla którego 92,6% trzeba było poprawić publicznie, a nie po cichu podmienić, i wolimy opublikować korektę niż zostawić liczbę, która czyta się lepiej, niż mierzy.

Jeśli prowadzisz n8n w swojej firmie i chcesz wiedzieć, które z Twoich przepływów milkną, kiedy się wywalą, odezwij się. Przejdziemy przez nie na Twoich danych, na bezpłatnej rozmowie.

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.