Agentowy przepływ pracy różni się od klasycznej automatyzacji jedną rzeczą: nie mówisz systemowi, jak coś zrobić krok po kroku, tylko co ma osiągnąć — a on sam dobiera kroki i dopytuje, gdy czegoś mu brakuje. Wyobraź sobie, że tłumaczysz to dziesięciolatkowi: nie każesz mu wykonywać poleceń jedno po drugim, tylko mówisz, co ma powstać, a resztę zostawiasz jemu. Pokażę ci tę różnicę na konkretnym przykładzie i przeprowadzę cię przez budowę pierwszego takiego przepływu w Claude Code, bez pisania ani jednej linijki kodu.
Na początek dwa pojęcia. Agent to program oparty na modelu AI, który dostaje cel i samodzielnie planuje oraz wykonuje kroki, by go zrealizować — w odróżnieniu od skryptu, który tylko odtwarza z góry zapisaną sekwencję. Przepływ pracy (po angielsku workflow) to po prostu proces: ciąg czynności, które wiodą od punktu wyjścia do wyniku.
Posłuchaj
Około 6-minutowa rozmowa o tym artykule — jak złożyć pracę z Claude w powtarzalny, agentowy proces.
Wygenerowane przez NotebookLM, sprawdzone przez AURA.
Przepis kontra zamówienie w restauracji
W klasycznej automatyzacji to ty układasz każdy krok. Przeciągasz bloki na planszę, łączysz je, pilnujesz, by właściwe dane trafiły we właściwe miejsca, sam konfigurujesz połączenia z innymi usługami. Sam rysujesz całą mapę. Jeśli pominiesz krok albo coś pomylisz, całość się sypie.
Najprostsze porównanie to gotowanie z przepisu kontra zamówienie w restauracji. Klasyczna automatyzacja przypomina gotowanie obiadu z książki kucharskiej: krok pierwszy, sprawdzasz składniki, krok drugi, odmierzasz, ustawiasz piekarnik, pilnujesz czasu. Agentowy przepływ to wejście do restauracji i powiedzenie kelnerowi: „poproszę dobry stek”. Nie tłumaczysz, jak go przyprawić ani w jakiej temperaturze piec — podajesz wynik, a kuchnia zajmuje się resztą. Dobry kucharz może jeszcze dopytać: „a jak wysmażyć?”. Odpowiadasz „średnio” i reszta dzieje się bez ciebie.
Tak właśnie działa agent. Dajesz mu cel, on układa kroki, ale też zadaje pytania doprecyzowujące — bo wielu z nas dobrze wie, jaki chce uzyskać efekt, lecz nie wie dokładnie, jak do niego dojść.
Konkretny przykład. Potrzebujesz danych kontaktowych pięćdziesięciu gabinetów dentystycznych w jednym mieście, żeby wysłać każdemu spersonalizowaną wiadomość. W agentowym przepływie nie rozpisujesz każdego kroku. Mówisz, czego potrzebujesz, a agent sam ustala, skąd pobrać dane, jak znaleźć kontakty i jak przygotować wiadomości. Może po drodze dopytać, jaką ofertę chcesz przedstawić, żeby trafniej je napisać.
Gdzie się to buduje: Claude Code
Do zbudowania takiego przepływu nie trzeba umieć programować. Wystarczy darmowy edytor kodu Visual Studio Code (to bezpłatny program firmy Microsoft do pisania i uruchamiania kodu) oraz Claude Code — narzędzie, w którym model Claude czyta pliki, planuje i wykonuje zadania. Claude Code instaluje się w edytorze jako dodatek i wymaga płatnego planu Claude. Po zalogowaniu po prawej stronie pojawia się okno rozmowy — wygląda jak zwykły czat, ale na bieżąco widzisz, co model myśli i robi.
Cała praca toczy się w jednym folderze projektu. Po lewej stronie masz pliki, które Claude Code tworzy i zmienia; po prawej — rozmowę, w której planujesz, odpowiadasz na pytania i obserwujesz wykonywane czynności.
Framework WAT: przepływy, agent, narzędzia
Najłatwiej uporządkować to prostym schematem WAT — od angielskich słów workflows, agent, tools: przepływy, agent, narzędzia. Agentem jest tu Claude Code, czyli „mózg”, z którym rozmawiasz. Przepływy to procesy zapisane zwykłym językiem w plikach tekstowych (w formacie Markdown — to czysty tekst z nagłówkami i punktami, bez kodu). Narzędzia to konkretne czynności, zapisane już w kodzie — tej części nie musisz oglądać ani rozumieć.
Najprościej: przepływy to procesy, a narzędzia to pojedyncze działania. Wracając do kuchni — agent jest kucharzem. Kucharz albo korzysta z gotowego przepisu (przepływu), albo układa własny. W przepisie pojawiają się polecenia typu „wbij dwa jajka, dodaj szklankę mąki”. Jajka i mąka to narzędzia. Z kombinacji przepisów i składników powstaje wynik — ciasto albo gotowy, agentowy przepływ pracy.
Żeby agent działał według tego schematu, dostaje na starcie plik z instrukcją — nazywam go „instrukcją stanowiskową”, bo to dokładnie to, co nowy pracownik dostaje pierwszego dnia: zakres zadań, zasady, sposób pracy. Plik tłumaczy modelowi trzy warstwy WAT i — co istotne — jak utrzymać porządek w plikach, żeby projekt nie zamienił się w bałagan.
Tryby pracy: od planu po pełną autonomię
Na dole okna Claude Code wybierasz, ile swobody dać modelowi. Można pytać o zgodę przed każdą zmianą, pozwolić edytować automatycznie, włączyć tryb planowania albo pominąć pytania o zgodę. Moja praktyczna rada: zaczynaj od trybu planowania. Model wtedy nic nie zmienia — najpierw rozpisuje, co zamierza zrobić, i zadaje pytania. Plan zatwierdzasz dopiero, gdy wygląda sensownie.
Pełną autonomię (pomijanie pytań o zgodę) włączaj tylko wtedy, gdy siedzisz obok i patrzysz modelowi na ręce. Jeśli zauważysz, że zbacza z kursu, po prostu go korygujesz. To rozsądna zasada: im więcej swobody, tym uważniej trzeba obserwować.
MCP: jeden adres zamiast wielu sklepów
Żeby agent mógł sięgać po dane z internetu czy innych usług, potrzebuje narzędzi. Łączy się z nimi przez MCP (z angielskiego model context protocol — protokół kontekstu modelu). Brzmi technicznie, ale idea jest prosta. Weź pocztę: jest osobna czynność do wysłania wiadomości, do zapisania szkicu, do pobrania listy maili. MCP sprawia, że agent sam wybiera, której czynności użyć i jak ją uzupełnić — ty nie musisz o tym myśleć.
Wracając do ciasta: zamiast biegać osobno do sklepu z jajkami, do sklepu z mąką i po lukier, dajesz agentowi dostęp do jednego „supermarketu” i mówisz: bierz, czego potrzebujesz. W moim przykładzie tym supermarketem jest usługa do pobierania danych ze stron internetowych, podłączona przez MCP jednym poleceniem.
Jedna uwaga o bezpieczeństwie. Dostęp do takich usług działa na klucz API — to rodzaj hasła. Klucza nie wpisuje się wprost w rozmowę, bo zostaje w jej historii. Zapisuje się go w osobnym, lokalnym pliku konfiguracyjnym. Dzięki temu, jeśli kiedyś udostępnisz pliki projektu, klucz nie wypłynie razem z nimi.
Co się dzieje, gdy agent buduje
W moim przykładzie zadanie brzmiało: pobierz oferty pracy z serwisu rozłożone na wielu stronach i zapisz je w arkuszu. W trybie planowania agent zadał pytania (czy pobierać szczegóły każdej oferty, gdzie zapisać plik, czy filtrować wyniki), przedstawił plan, a po zatwierdzeniu wykonał zadanie — sam utworzył przy tym narzędzie i przepływ, których następnym razem użyje ponownie.
Najciekawsze widać przy trudniejszych zleceniach. Gdy okazało się, że żądanych pięciuset ofert w danym regionie po prostu nie ma, agent się zatrzymał, rozważył inne podejścia i dopytał, czy poszerzyć kryteria. Gdy narzędzie zwróciło tylko dwa wyniki zamiast setek, sam znalazł błąd w sposobie odczytu danych i poprawił narzędzie tak, by problem się nie powtórzył. Tę zdolność nazywa się samonaprawą: agent napotyka przeszkodę, nazywa ją, próbuje innej drogi i aktualizuje swoje przepływy oraz narzędzia.
Warto znać jeszcze jedno pojęcie. Im dłuższa rozmowa z modelem, tym więcej kontekstu się w niej gromadzi i tym gorzej model sobie radzi — to tak zwany „rozkład kontekstu”. Dlatego co jakiś czas warto rozmowę „skompresować”: model streszcza dotychczasowe ustalenia i pracuje dalej, pamiętając to, co istotne. Dla porządku: token to fragment tekstu, którym model operuje, a kontekst to cały tekst, który widzi naraz.
Dwa błędy, których łatwo uniknąć
Pierwszy: zbyt mglisty cel. „Potrzebuję narzędzia do zbierania kontaktów” to za mało — agent nie wie, z jakiej branży ani z jakich ról. Owszem, dopyta, ale lepiej od razu opisać problem konkretnie. Sprawdza się tu trik z trybem planowania: „oto z grubsza, czego chcę — pomóż mi przekuć to w solidny dokument wymagań”. Agent rozpisze, dopyta i sam zada właściwe pytania. Wolno traktować go jak eksperta; ty jesteś menedżerem, który pilnuje kierunku.
Drugi: brak definicji „gotowe”. Agent musi wiedzieć, kiedy się zatrzymać. Bez wyraźnej mety potrafi przekombinować albo zapętlić się w poprawkach. Zamiast „znajdź profile prezesów firm technologicznych” napisz: „potrzebuję dokładnie 75 profili, w arkuszu, z imieniem, nazwą firmy i adresem — po 75 kończysz”. Jasne wejście, jasne wyjście, powtarzalny wynik.
Dlaczego to bywa wygodniejsze
Trzy konkretne różnice względem klasycznej automatyzacji. Po pierwsze, mniej żmudnego szukania błędów — zamiast czytać logi po awarii, obserwujesz, jak agent sam radzi sobie z przeszkodą. Po drugie, sterowanie zwykłym językiem — nie musisz znać każdego bloku ani czytać dokumentacji połączeń; opisujesz, czego chcesz. Po trzecie, system z czasem dział sprawniej, bo po każdym potknięciu aktualizuje swoje przepływy i narzędzia.
Jedno ważne zastrzeżenie. Samonaprawa działa, gdy uruchamiasz agenta ręcznie i jesteś obok. Jeśli proces ma ruszać sam — co rano o szóstej albo po wysłaniu formularza na stronie — wdraża się już sam kod przepływu, a nie agenta. Taki proces traci wtedy zdolność samonaprawy, bo to agent ją zapewnia. To osobny temat, którego tu nie rozwijam.
Na koniec spokojna perspektywa. Jeśli dopiero uczysz się automatyzacji, nic nie tracisz — punkt ciężkości przesuwa się z budowania krok po kroku ku projektowaniu całych procesów. Liczy się nie to, ile bloków znasz, lecz jak jasno potrafisz opisać cel i metę.