Artykuł 4 z serii Anatomia Agenta AI ← Jak agent pamięta — cztery typy pamięci i dlaczego to zmienia wszystko
Poprzednie trzy artykuły serii były konceptualne. Agent loop, ReAct, typy pamięci — solidny fundament. Ale w pewnym momencie trzeba przestać czytać i zacząć budować.
Barierą był kod. Python, LangChain, API keys w zmiennych środowiskowych, deployment. Dla developera — kwadrans pracy. Dla marketera, właściciela strony czy kogoś kto nie programuje zawodowo — zaporowy próg wejścia.
n8n ten próg likwiduje. Nie całkowicie i nie dla każdego use case — ale dla pierwszego agenta, dla automatyzacji które mają sens biznesowy, dla prototypu który chcesz pokazać klientowi jutro — n8n wystarczy.
Czym jest n8n i dlaczego nie Zapier
n8n to narzędzie do budowania automatyzacji przez przeciąganie i łączenie "klocków" (nodes) na wizualnym płótnie. Wygląda jak Zapier lub Make. Ale jest kilka różnic które robią z niego inne narzędzie.
Open source i self-hosting. n8n możesz uruchomić na własnym serwerze. Twoje dane nie przechodzą przez zewnętrzną infrastrukturę. Dla wielu use casów z danymi firmowymi — to decydujące.
Natywny AI Agent node. Zapier "integruje" z AI przez zewnętrzne wywołania. n8n ma dedykowany węzeł AI Agent który implementuje agent loop z narzędziami, pamięcią i obsługą błędów — wbudowany, bez zewnętrznych frameworków.
Natywna obsługa MCP. Od wersji 1.88 n8n obsługuje MCP jako klient — agent w n8n może korzystać z serwerów MCP bezpośrednio. To oznacza że cały ekosystem serwerów MCP (GitHub, Slack, Postgres, Webflux Słownik...) jest dostępny bez pisania własnych integracji.
Kod gdy potrzebujesz. Każdy node możesz rozszerzyć o własny JavaScript lub Python. Nie musisz — ale możesz, gdy no-code już nie wystarcza.
Jak myśleć o n8n: przepływy i agenty
W n8n budujesz dwie różne rzeczy i ważne żeby ich nie mylić.
Workflow to sekwencja deterministycznych kroków. Trigger → krok 1 → krok 2 → krok 3 → wynik. Każdy krok zawsze wykonuje to samo. To jest klasyczna automatyzacja — świetna dla powtarzalnych procesów bez wyjątków.
Agent to coś innego. Trigger → AI Agent → [agent sam decyduje jakich narzędzi użyć i ile razy] → wynik. Agent nie idzie przez z góry ustalony przepływ — ocenia sytuację, dobiera narzędzia, iteruje. To jest agentic workflow.
Dla pierwszego projektu: zacznij od workflow. Gdy workflow nie wystarczy bo zadanie wymaga decyzji i wyjątków — dodaj węzeł AI Agent.
Praktyczny przykład: agent monitorujący branżę
Budujesz stronę lub prowadzisz projekt contentowy. Chcesz wiedzieć co piszą konkurenci i co dzieje się w branży — bez ręcznego sprawdzania RSS feedów codziennie.
Zbudujemy agenta który:
- Co tydzień pobiera nowe artykuły z kilku RSS feedów
- Dla każdego artykułu klasyfikuje temat i ocenia relevantność
- Wysyła Ci podsumowanie tylko z tymi które naprawdę warto przeczytać
Oto jak to wygląda w n8n krok po kroku.
Krok 1: Trigger czasowy
Node: Schedule Trigger Ustawienie: każdy poniedziałek, 08:00.
Tyle. To jest pierwszy klocek — raz w tygodniu uruchamia cały przepływ.
Krok 2: Pobierz artykuły z RSS
Node: RSS Feed Read (powtórzony dla każdego źródła) Parametr: URL Twojego RSS feeda.
n8n obsługuje scalanie wielu źródeł RSS — możesz podłączyć 10 feedów i wyniki scalają się w jeden strumień.
Wynik: lista artykułów z ostatnich 7 dni — tytuł, URL, opis, data.
Krok 3: AI Agent klasyfikuje i ocenia
Node: AI Agent Model: GPT-4o mini (szybki, tani, wystarczający do klasyfikacji)
System prompt:
Jesteś ekspertem od contentu z branży [Twoja branża].
Analizujesz artykuły pod kątem ich relevantności dla właściciela
strony internetowej który buduje treści o [Twój temat].
Dla każdego artykułu zwróć JSON:
{
"relevancja": 1-5,
"temat": "jedna z kategorii: SEO/AI/WordPress/Narzędzia/Inne",
"powod": "jedno zdanie dlaczego warto przeczytać (lub nie)",
"warto": true/false
}Input: tytuł + opis artykułu z RSS.
Agent przechodzi przez każdy artykuł i klasyfikuje. To nie jest agent loop w pełnym sensie — to jeden krok z AI. Ale to jest AI jako część workflow.
Krok 4: Filtruj tylko relevantne
Node: Filter Warunek: warto == true AND relevancja >= 4
Odfiltrowujemy szum — zostają tylko artykuły które agent uznał za naprawdę warte uwagi.
Krok 5: Generuj podsumowanie
Node: AI (nie Agent — to jeden krok generowania) Model: GPT-4o mini
Prompt:
Na podstawie poniższych artykułów wygeneruj tygodniowe
podsumowanie branżowe w formie newsletter-owego intro
(3-4 zdania), a potem bullet-pointy z każdym artykułem
(tytuł + jedno zdanie dlaczego warto).Krok 6: Wyślij email lub zapisz w Notion
Node: Gmail / Slack / Notion
Gotowe podsumowanie trafia gdzie chcesz. Email, Slack channel, nowa strona w Notion.
Co właśnie zbudowałeś
Sześć klocków. Żadnej linii kodu. Agent który co tydzień monitoruje branżę za Ciebie.
Ale zwróć uwagę na coś ważnego: to nie jest autonomiczny agent. To workflow z krokiem AI w środku. Agent sam nie decyduje ile RSS feedów sprawdzić, nie szuka nowych źródeł, nie zmienia strategii gdy znajdzie coś nieoczekiwanego.
To jest właśnie granica między workflow a agentem. I to jest dobra granica na start — przewidywalne, tanie, łatwe do debugowania.
Gdy będziesz chciał żeby system sam szukał nowych źródeł, sam decydował o częstotliwości, sam reagował na trendy — wtedy potrzebujesz pełnego węzła AI Agent z narzędziami. n8n to umożliwia — ale to już kolejny poziom.
MCP w n8n — dlaczego to zmienia możliwości
Wróćmy do tematu MCP który pojawił się wcześniej w serii.
n8n od wersji 1.88 obsługuje MCP Client. Oznacza to że agent w n8n może korzystać bezpośrednio z serwerów MCP — bez ręcznego budowania integracji przez REST API.
Praktycznie: jeśli Twoja baza danych, CRM lub inny system ma serwer MCP — agent w n8n ma do niego dostęp przez jeden węzeł konfiguracyjny. Zamiast budować node z API credentials, nagłówkami i obsługą paginacji — podajesz URL serwera MCP i agent sam odkrywa dostępne narzędzia.
Dla stron na WordPress — Webflux Słownik ma serwer MCP. Agent w n8n może odpytywać słownik o definicje pojęć bezpośrednio. To jest dokładnie ten typ integracji który staje się banalnie prosty przez MCP.
Kiedy n8n nie wystarczy
n8n jest narzędziem, nie odpowiedzią na wszystko. Są przypadki gdzie potrzebujesz więcej:
Złożona logika agenta. Agent który musi dynamicznie planować wieloetapowe strategie, korygować swoje działanie na podstawie złożonych wyników, zarządzać wieloma subagentami równolegle — potrzebuje frameworka kodu (LangGraph, CrewAI) gdzie masz pełną kontrolę nad agent loop.
Produkcja z wymaganiami SLA. n8n cloud ma limity i dostępność na poziomie "good enough". Systemy krytyczne z wymaganiami 99.9% uptime i SLA — potrzebują własnej infrastruktury i własnego deployment.
Specyficzne wymagania bezpieczeństwa. Przetwarzasz dane medyczne, finansowe, prawne? Self-hosted n8n jest opcją, ale pełna kontrola wymaga własnego stosu.
Ale dla 80% use casów które chcesz przetestować, zbudować jako MVP, albo uruchomić dla siebie lub małego teamu — n8n jest właściwym narzędziem. A umiejętność szybkiego prototypowania w n8n jest bardziej wartościowa niż czekanie aż nauczysz się Pythona na poziomie który pozwoli Ci zbudować to samo od zera.
Jak zacząć
n8n cloud — darmowe konto na n8n.io. 14 dni trial z pełnymi możliwościami, potem darmowy tier z limitem 5 aktywnych workflows. Wystarczy żeby zacząć i zbudować przykład z artykułu.
Szablony — n8n ma galerię gotowych workflow na n8n.io/workflows. Wyszukaj "AI agent" albo "RSS" i znajdziesz dziesiątki gotowych punktów startowych. Lepiej zacząć od szablonu niż od pustego płótna.
Dokumentacja AI Agent — docs.n8n.io/advanced-ai ma dedykowany dział dla AI i agentów z przykładami.
W następnym artykule serii: teraz wiesz jak agent działa, jak pamięta i jak go zbudować. Ale co z system promptem który nim steruje? Prompt engineering dla agentów to coś fundamentalnie innego niż prompt do chatbota — i większość osób popełnia te same błędy.
Pojęcia ze słownika: Agentic workflow · Agent framework · MCP · Tool use · Agent loop · Human-in-the-loop
![Artykuł 2 z serii "Agenci AI — od konceptu do produkcji" ← RAG, Agent AI, Agentic RAG — czym się różnią Poprzedni artykuł tej serii skończył się na rozróżnieniu: RAG odpowiada na pytanie, agent realizuje cel. Ale to rodzi pytanie które każdy kto buduje agenta zadaje sobie prędzej czy później: jak właściwie agent decyduje co zrobić dalej? Między "dostałem zadanie" a "zadanie wykonane" jest czarna skrzynka. Dla chatbota ta czarna skrzynka jest prosta — jeden prompt, jedna odpowiedź. Dla agenta to sekwencja decyzji, wywołań narzędzi i ocen wyniku która może trwać sekundy albo godziny. Żeby budować agentów świadomie — a nie przez próby i błędy — trzeba zrozumieć co jest w środku tej czarnej skrzynki. Pętla która napędza każdego agenta Zacznijmy od analogii. Wyobraź sobie że dostajesz zadanie: "Zarezerwuj mi hotel w Krakowie na weekend 14-15 czerwca, do 400 zł za noc, blisko centrum." Jak to robisz? Nie jednym ruchem. Najpierw szukasz opcji. Sprawdzasz ceny. Czytasz opinie. Może jedno miejsce ma dobry rating ale jest za drogie — odrzucasz. Drugie pasuje, ale patrzysz jeszcze na lokalizację. Potwierdzasz. Rezerwujesz. To jest pętla: obserwujesz → planujesz → działasz → oceniasz wynik → wracasz do początku. Agent AI działa identycznie. Każde wieloetapowe zadanie jest realizowane przez powtarzający się cykl czterech kroków — i ten cykl ma swoją nazwę: agent loop. Cztery kroki pętli Percepcja — agent patrzy na stan: co jest w oknie kontekstu, jakie były wyniki poprzednich akcji, co zwróciło ostatnie narzędzie, jaki jest cel. Planowanie — na podstawie tego co widzi, agent decyduje co zrobić dalej. To jest moment decyzji: czy cel jest osiągnięty? Jeśli nie — jaka akcja przybliży mnie do celu? Jakie narzędzie wywołać? Akcja — agent wykonuje to co zaplanował. Wywołuje narzędzie MCP, odpytuje bazę danych, robi request HTTP, pisze plik. Ocena — agent patrzy na wynik akcji. Czy to działało? Co teraz wiem więcej? Co jest następnym krokiem? Czy napotkałem błąd który wymaga innej strategii? I z powrotem do percepcji. Pętla kręci się dopóki agent nie osiągnie celu, nie napotka przeszkody której nie może pokonać, albo — i to jest ważne — nie przekroczy limitu iteracji. Limit iteracji jest krytyczny Agent bez limitu może kręcić się w pętli nieskończenie. Narzędzie zwraca błąd, agent próbuje jeszcze raz, i jeszcze raz, i jeszcze raz. Minuty zamieniają się w godziny. Tokeny i koszty rosną. Każdy agent produkcyjny musi mieć limit kroków po którym zatrzymuje się i raportuje do człowieka: "doszedłem do limitu X iteracji, oto co udało mi się ustalić, oto gdzie utknąłem." To jest pierwsza zasada którą ignoruje większość ludzi budujących swojego pierwszego agenta. ReAct — jak agent myśli zanim działa Teraz wiemy że agent kręci się w pętli. Ale co dokładnie dzieje się w kroku "planowanie"? Jak agent decyduje co zrobić? W 2022 roku badacze z Princeton i Google zaproponowali wzorzec który zmienił sposób budowania agentów: ReAct (Reasoning + Acting). Pomysł jest prosty do bólu: zanim agent wykona akcję, niech najpierw "powie na głos" co myśli. Generuje explicite reasoning — widoczny łańcuch myślenia — a potem na jego podstawie podejmuje decyzję o akcji. Wygląda to tak: Thought: Użytkownik chce hotelu w Krakowie na 14-15 czerwca do 400 zł. Powinienem najpierw sprawdzić dostępność. Action: search_hotels(city="Kraków", checkin="2026-06-14", checkout="2026-06-15", max_price=400) Observation: [3 wyniki: Hotel A — 380 zł, Hotel B — 350 zł, Hotel C — 420 zł] Thought: Hotel C jest za drogi. Hotel A i B mieszczą się w budżecie. Sprawdzam odległość od centrum. Action: get_location(hotel_id="hotel_A") Observation: 800m od Rynku Głównego Thought: 800m to blisko centrum. Hotel A kosztuje 380 zł i jest blisko. Rezerwuję. Action: book_hotel(hotel_id="hotel_A", dates=["2026-06-14"]) Trzy zalety ReAct które robią różnicę w praktyce: Debugging jest możliwy. Widzisz dokładnie skąd pochodzi każda decyzja agenta. Jeśli coś poszło nie tak — możesz śledzić rozumowanie krok po kroku i znaleźć moment gdzie agent zboczył z kursu. Narzędzia są wywoływane trafniej. Agent który "przemyśli" co wywołać zanim to zrobi, robi mniej błędnych wywołań niż agent który po prostu reaguje na ostatni wynik. Agent może się korygować. Reasoning jest widoczny — i agent może sam zauważyć że jego poprzedni krok był błędny, zanim podejmie kolejny. Chain-of-Thought — "myślmy krok po kroku" ReAct to wzorzec na poziomie architektury agenta. Chain-of-thought (CoT) to technika na poziomie promptowania modelu. Idea: zamiast prosić model o bezpośrednią odpowiedź, zachęć go żeby najpierw pokazał swoje obliczenia. Jak matematyk który nie podaje samego wyniku, ale zapisuje wszystkie kroki. Najprostszy możliwy CoT to dosłownie jedno zdanie dodane do promptu: "Myślmy krok po kroku." Brzmi banalnie. Ale działa — szczególnie przy zadaniach wieloetapowych, matematycznych i logicznych. Bardziej zaawansowany CoT to few-shot: dostarczasz modelowi przykłady pytanie + rozumowanie + odpowiedź, i model uczy się wzorca. Dla agentów operujących w specyficznej domenie — powiedzmy agent analizujący umowy prawne — few-shot CoT z przykładami z tej domeny jest jednym z najskuteczniejszych sposobów poprawy jakości. Extended thinking — CoT wbudowany w model Claude 3.7+ i kilka innych modeli poszło dalej: extended thinking jest wbudowane bezpośrednio w model, bez potrzeby specjalnego promptowania. Model generuje wewnętrzny długi łańcuch myślenia przed odpowiedzią — niewidoczny dla użytkownika (lub opcjonalnie widoczny). Efekt: znacząco lepsza jakość przy złożonych, wieloetapowych zadaniach — za cenę wyższej latencji i więcej tokenów. Dla agentów wykonujących skomplikowane analizy gdzie czas odpowiedzi jest mniej ważny niż poprawność — extended thinking jest naturalnym wyborem. Przykład który łączy wszystko: agent rezerwujący hotel Wróćmy do zadania: "Zarezerwuj hotel w Krakowie na 14-15 czerwca." Chatbot dostałby to pytanie i wygenerował listę hoteli z opisem. Odpowiedź tekstowa. Nic nie zarezerwował. Agent z agent loop, ReAct i dostępem do narzędzi wykonuje to zadanie od początku do końca: Iteracja 1: Percepcja → cel jasny, narzędzia dostępne. Planowanie → wywołaj search_hotels. Akcja → [wywołanie]. Ocena → 3 wyniki, Hotel C za drogi. Iteracja 2: Percepcja → mam 2 kandydatów. Planowanie → sprawdź lokalizację. Akcja → [wywołanie]. Ocena → Hotel A blisko centrum, Hotel B dalej. Iteracja 3: Percepcja → Hotel A: 380 zł, 800m od centrum. Spełnia wszystkie kryteria. Planowanie → rezerwuj. Akcja → [wywołanie book_hotel]. Ocena → rezerwacja potwierdzona, numer #KRK2026-0891. Wynik: "Zarezerwowałem Hotel A na 14-15 czerwca, 380 zł, 800m od Rynku Głównego. Numer rezerwacji: #KRK2026-0891." Trzy iteracje pętli. Trzy wywołania narzędzi. Jedno wykonane zadanie. Co to zmienia dla kogoś kto buduje agenta Zrozumienie agent loop, ReAct i CoT nie jest teorią akademicką — bezpośrednio wpływa na to jak projektujesz agenta. Agent loop mówi ci: musisz zdefiniować kryterium sukcesu (jak agent wie że skończył?), ustawić limit iteracji (co gdy agent utknął?), i zdecydować gdzie wstawić human-in-the-loop (które akcje wymagają potwierdzenia człowieka przed wykonaniem?). ReAct mówi ci: daj modelowi miejsce na reasoning zanim podejmie akcję. Nie optymalizuj prompta do minimum — reasoning kosztuje tokeny, ale zmniejsza błędy narzędziowe i ułatwia debugging gdy coś pójdzie nie tak. CoT mówi ci: przy złożonych zadaniach "myślmy krok po kroku" to nie magia — to zmiana trybu pracy modelu. Dla zadań domenowych few-shot CoT z przykładami z Twojej domeny jest wart inwestycji. W następnym artykule: agent myśli i działa — ale co pamięta? Jak działa pamięć agenta między krokami, między sesjami i między zadaniami — i dlaczego zły design pamięci jest jednym z najczęstszych błędów przy budowaniu agentów produkcyjnych. Pojęcia ze słownika: Agent loop · Chain-of-thought · Reasoning model · Tool use · Human-in-the-loop · Agent AI](https://webflux.pl/wp-content/uploads/2026/06/agent_mysli.webp)
