
Claude Code Workflows: czym są i kiedy naprawdę ich potrzebujesz
Zaktualizuj Claude Code do wersji 2.1.154, a w /config znajdziesz nowy wiersz o nazwie Dynamic workflows. Włącz go, a Claude będzie mógł napisać skrypt JavaScript, który rozdziela pracę na maksymalnie 16 agentów działających jednocześnie. To właśnie ta funkcja, o której wszyscy szepczą. Oficjalna dokumentacja mówi, co ona robi. Nie mówi natomiast tego, co naprawdę Cię interesuje: czy jej potrzebujesz, czy może subagenci, których już masz, w zupełności wystarczą?
I tu właśnie leży problem. Claude Code workflows pojawiły się jako research preview, a dokumentacja czyta się jak materiał referencyjny, nie jak porada. Uruchomiliśmy więc jedyny dołączony workflow, /deep-research, w naszym własnym pipeline treści, zapisaliśmy rzeczywiste liczby i spisaliśmy szczerą ocenę. W skrócie: jeśli wciąż jesteś w stanie ręcznie śledzić swoich agentów, nie potrzebujesz jeszcze workflow. Niektórzy z Was zdecydowanie go potrzebują. Sprawdźmy, do której grupy należysz.
Najważniejsze wnioski:
- Claude Code workflow to skrypt JavaScript, który Claude pisze w celu orkiestracji subagentów na dużą skalę (research preview, wersja 2.1.154+, wszystkie płatne plany).
- Potrzebujesz go tylko wtedy, gdy zadanie wymaga więcej agentów, niż jedna rozmowa jest w stanie skoordynować. W przeciwnym razie subagenci wystarczą.
- Obecnie dostępny jest jeden workflow:
/deep-research. Działa w tle, a Twoja sesja pozostaje responsywna. - Workflows pochłaniają dużo tokenów. Zmierzyliśmy rzeczywiste uruchomienie, zanim polecimy którekolwiek (liczby poniżej).
Czym jest Claude Code Workflow?
Claude Code workflow to skrypt JavaScript, który orkiestruje subagentów na dużą skalę. Opisujesz zadanie, Claude pisze skrypt, a środowisko wykonawcze uruchamia go w tle, podczas gdy Twoja sesja czatu pozostaje responsywna. To funkcja w fazie research preview w Claude Code, wymaga Claude Code w wersji 2.1.154+ i działa na wszystkich płatnych planach (Pro, Max, Team, Enterprise, a także API oraz Bedrock/Vertex/Foundry).
A teraz wersja z życia wzięta. Wyobraź sobie, że podchodzisz do kuchennego blatu i opisujesz posiłek, na który masz ochotę. Szef kuchni zapisuje przepis, przekazuje go do zaplecza pełnego kucharzy, a oni biorą się do pracy, podczas gdy Ty dalej rozmawiasz przy blacie. Nie zarządzasz każdym kucharzem z osobna. Robi to przepis. Ten przepis to workflow, kucharze to subagenci, a kuchnia działająca na zapleczu to środowisko wykonawcze.
Workflow nie jest kolejnym agentem. To skrypt, który mówi Twoim agentom, co mają robić, w jakiej kolejności i co zrobić z wynikami. To rozróżnienie jest ważniejsze niż cokolwiek innego w tym artykule, a w następnej sekcji przełożymy je na konkrety.
Jedno szybkie wyjaśnienie, żeby uniknąć nieporozumień. Wyszukaj „claude code workflows", a trafisz na repozytoria GitHub, wtyczki i
marketplacepełen społecznościowych narzędzi typu swarm, takich jak Ruflo, claude-flow iwshobson/agents. To są zewnętrzne orkiestratory. Oficjalna funkcja Anthropic o nazwie Dynamic workflows to coś innego — wbudowana funkcja. Jeśli nie widzisz jej w/configw wersji 2.1.154+, to nie jest ta oficjalna.
To wpisuje się w inne premiery Anthropic w fazie research preview, jak niedawny fast mode research preview: wypuszczony wcześnie, za przełącznikiem, wciąż niedopracowany. Traktuj to jak preview, bo tym właśnie jest. Pełna specyfikacja znajduje się w oficjalnej dokumentacji workflows.
Workflows vs subagenci vs skills: kto trzyma plan?
Najprostszy sposób na rozróżnienie tych trzech pojęć to jedno pytanie: kto trzyma plan? Skill to spakowane instrukcje i wiedza, które Claude ładuje na żądanie. Subagent to oddzielny kontekst wykonujący jedno delegowane zadanie. Workflow to skrypt orkiestrujący, który koordynuje subagentów na dużą skalę — do 16 jednocześnie. Ten sam zestaw narzędzi, trzy różne zadania.

Oto porównanie, które oficjalna dokumentacja sugeruje, ale nigdy nie przedstawia obok siebie:
| Skill | Subagent | Workflow | |
|---|---|---|---|
| Kto trzyma plan? | Ty/Claude w głównym kontekście | Oddzielny delegowany kontekst | Skrypt workflow (środowisko wykonawcze) |
| Czym jest | Spakowane instrukcje/wiedza ładowane na żądanie | Jedno izolowane zadanie we własnym kontekście | Skrypt JavaScript orkiestrujący subagentów (≤16 jednocześnie) |
| Skala | nd. | Kilka, koordynowane konwersacyjnie | Do 16 jednocześnie / 1000 na uruchomienie |
| Możliwość ponownego uruchomienia jako kod? | Nie | Nie | Tak (zapisz jako /command) |
| Najlepszy do | Wielokrotnego użytku wiedzy/instrukcji | Jednego delegowanego zadania | Więcej agentów, niż jedna rozmowa jest w stanie ogarnąć |
Jeśli jedna rozmowa z Claude jest jeszcze w stanie utrzymać cały plan w głowie, potrzebujesz subagenta, nie workflow. W momencie, gdy uruchamiasz więcej agentów, niż Ty — człowiek — jesteś w stanie śledzić (kto co robi i w jakiej kolejności), plan przerósł rozmowę. To właśnie jest granica, którą przekracza workflow.
Chcesz zgłębić pierwszy element? Nasz poradnik o skills omawia pakowanie wiedzy, którą Claude ładuje na żądanie. A jeśli zastanawiasz się, czy sięgnąć po pełny framework agentowy zamiast natywnej orkiestracji, to porównanie też pomoże. Nasza szczera opinia: natywne prymitywy zaprowadzą Cię dalej, niż myślisz, zanim framework zacznie się opłacać.
Kiedy naprawdę potrzebujesz Claude Code Workflow?
Potrzebujesz Claude Code workflow, gdy (a) zadanie wymaga więcej agentów, niż jedna rozmowa jest w stanie skoordynować, (b) chcesz zapisać orkiestrację jako wielokrotnie uruchamialny kod zamiast jednorazowego promptu, lub (c) potrzebujesz adversarial review lub krzyżowej weryfikacji, w której wielu agentów sprawdza nawzajem swoją pracę. Jeśli żaden z tych warunków nie jest spełniony, subagenci wystarczą. Bądź tu ze sobą szczery.
To jest ta część, której dokumentacja nie powie wprost, więc my to powiemy: prawdopodobnie nie potrzebujesz jeszcze workflow. Kilku subagentów koordynowanych w ramach zwykłej rozmowy radzi sobie z codzienną pracą. Workflows nie są ulepszeniem, do którego się dorasta. To narzędzie do jednego konkretnego kształtu problemu: więcej agentów, niż jeden umysł jest w stanie ogarnąć.
Przejdź przez tę listę kontrolną. Prawdopodobnie potrzebujesz workflow, jeśli odpowiesz tak na co najmniej jedno pytanie:
- Zadanie wymaga więcej agentów, niż jedna rozmowa jest w stanie ogarnąć.
- Chcesz mieć orkiestrację jako wielokrotnie uruchamialny kod, nie jednorazowy prompt, który przepisujesz.
- Potrzebujesz adversarial review lub krzyżowej weryfikacji (wielu agentów weryfikujących się nawzajem).
- Będziesz wielokrotnie uruchamiać to samo wieloagentowe zadanie, np. cykliczny audyt bazy kodu lub migrację 500 plików.
Odpowiedziałeś „nie" na wszystkie cztery? Zostań przy subagentach. Zaoszczędzisz tokeny, utrzymasz możliwość debugowania i nic nie stracisz. Osoby pracujące ze specyfikacjami rozpoznają ten wzorzec z dobrych praktyk CLAUDE.md: zapisz plan raz, uczyń go wielokrotnie uruchamialnym, przestań go przepisywać. Workflow to ten pomysł doprowadzony do punktu, w którym sam plan potrzebuje środowiska wykonawczego, by go zrealizować.
Jedyny workflow, który już masz: /deep-research
/deep-research to jedyny dołączony workflow dostępny w wersji preview. Wywołaj go pytaniem, a rozdzieli subagentów do równoległego badania tematu, krzyżowo zweryfikuje ich ustalenia i zwróci jedną syntetyczną odpowiedź do Twojego kontekstu — a to wszystko działając w tle, dzięki czemu Twoja sesja pozostaje użyteczna.
/deep-research What are the real token costs of running multi-agent research in Claude Code?To cały interfejs. Pod spodem przechodzi przez fazy: rozbija Twoje pytanie na wątki badawcze, uruchamia agentów do realizacji każdego z nich, przeprowadza etap krzyżowej weryfikacji lub recenzji, aby agenci wyłapywali nawzajem słabe twierdzenia, a następnie syntetyzuje końcową odpowiedź i zwraca ją do Twojego czatu. Nie sterujesz nim w trakcie działania. Pytasz, on pracuje, raportuje.

To naprawdę przydatne przy nieuporządkowanych pytaniach badawczych, przy których w przeciwnym razie otworzyłbyś dziesięć kart i stracił popołudnie. Jeśli już budujesz narzędzia badawcze, nasze zestawienie najlepszych serwerów MCP dobrze komponuje się z tym rodzajem równoległego badania. Ale „przydatne" i „warte rachunku za tokeny" to nie to samo — i właśnie to postanowiliśmy zmierzyć.
Co się stało, gdy uruchomiliśmy workflow w naszym własnym pipeline
Nasze uruchomienie /deep-research stworzyło 9 subagentów w 4 fazach, zużyło nieco ponad 1 milion tokenów i zakończyło się w około 8 minut czasu zegarowego. Czy było warto? Przy szybkim pytaniu — absolutnie nie. Przy zadaniu badawczym, które w przeciwnym razie koordynowalibyśmy ręcznie między pół tuzina agentów — zwróciło się. Oto szczera analiza.
W naszym pipeline ten artykuł, który właśnie czytasz, sam został wyprodukowany przez system wieloagentowy: research, brief, pisanie, walidacja, tłumaczenie i publikacja — każdy etap działa jako oddzielny subagent. Żyjemy więc już w świecie „zbyt wielu agentów na jedną rozmowę" z powyższej listy kontrolnej. To czyni nas odpowiednim przypadkiem testowym, nie wydumanym.
Uruchomiliśmy /deep-research na żywym słowie kluczowym, które już badaliśmy, i zapisaliśmy pełny przebieg:
| Metryka | Nasze uruchomienie /deep-research |
|---|---|
| Uruchomieni subagenci | 9 |
| Fazy | 4 (dekompozycja → rozdzielenie → krzyżowa weryfikacja → synteza) |
| Łączna liczba tokenów | ~1,05 mln |
| Czas zegarowy | ~8 minut |
| Werdykt: czy warto? | Przesada przy jednorazowych pytaniach; opłaca się przy prawdziwym wieloźródłowym researchu |
Najbardziej zaskoczyła nas faza krzyżowej weryfikacji. Kilka wczesnych twierdzeń wygenerowanych przez jednego agenta zostało po cichu skorygowanych, gdy inny agent je zakwestionował — to coś, co pojedyncza rozmowa zwykle macha ręką. Ten adversarialny krok to prawdziwa wartość, więcej niż surowy paralelizm. Koszt tokenowy jest jednak wysoki, a te agenty działają na modelach klasy Opus (zobacz co nowego w Opus 4.8, żeby zrozumieć, dlaczego to ważne dla rachunku). Milion tokenów za pytanie, na które mógłbyś odpowiedzieć dwoma promptami, to zły interes. Na pytanie, które naprawdę wymaga uzgodnienia sześciu źródeł — to okazja w przeliczeniu na Twój czas.
To jest dokładnie ten rodzaj orkiestracji, który budujemy dla klientów w Techsy, więc mieliśmy silne założenie wstępne co do tego, gdzie się opłaca, a gdzie tylko przepala budżet. Nasza opinia: uruchamiaj go przy trudnych pytaniach, pomijaj przy łatwych.
Jak napisać i zapisać własny workflow
Aby stworzyć własny workflow, opisz zadanie Claude'owi w języku naturalnym, używając słowa kluczowego workflow, przejrzyj i zatwierdź wygenerowany skrypt, a następnie zapisz go jako wielokrotnie używalny /command. Dla wyższego nakładu ustaw /effort ultracode, a Claude samodzielnie zaplanuje workflow. Nie musisz pisać JavaScriptu — Claude pisze skrypt, Ty go zatwierdzasz.
Oto pełny cykl, który jednocześnie służy jako instrukcja krok po kroku:
-
Włącz Dynamic workflows. W planie Pro otwórz
/configi włącz wiersz Dynamic workflows. (Masz wersję 2.1.154+, prawda?)bash/config # then enable the "Dynamic workflows" row -
Opisz zadanie ze słowem kluczowym
workflow. Umieść słowoworkfloww dowolnym miejscu promptu, na przykład: „Uruchom workflow, aby przeprowadzić audyt każdego pliku trasy w tym repozytorium pod kątem brakujących kontroli autoryzacji." Claude Code podświetla to słowo i pisze skrypt zamiast pracować krok po kroku. Chcesz, żeby Claude sam zdecydował? Ustaw/effort ultracode, który łączy rozumowaniexhighz automatyczną orkiestracją workflow dla każdego istotnego zadania (i zużywa więcej tokenów, więc wróć do/effort highprzy rutynowej pracy). -
Przejrzyj i zatwierdź wygenerowany skrypt. Claude pokazuje Ci orkiestrację JavaScript, zanim cokolwiek uruchomi. Przeczytaj ją. To Twoja szansa, by wyłapać rozdzielenie szersze, niż chcesz.
-
Zapisz jako
/commanddo ponownego użytku. Gdy zadziała, zapisz workflow jako niestandardowe polecenie slash, żeby audyt w przyszłym kwartale był jednym naciśnięciem klawisza.
Wielokrotna używalność to cichy zwycięzca. Jednorazowy /deep-research jest poręczny, ale zapisany workflow do „audytu autoryzacji we wszystkich trasach" lub „migracji tego katalogu do nowego API" zamienia wielogodzinną koordynację w pojedyncze powtarzalne polecenie. Wtedy koszt tokenowy zaczyna się amortyzować między uruchomieniami, zamiast boleć jednorazowo.
Ograniczenia, koszty i jak wyłączyć workflows
Workflows uruchamiają maksymalnie 16 agentów jednocześnie z twardym limitem 1000 agentów na uruchomienie, nie akceptują danych wejściowych w trakcie działania i można je wznowić tylko w ramach tej samej sesji. Z założenia pochłaniają dużo tokenów, ponieważ każdy agent konsumuje kontekst. Możesz całkowicie wyłączyć tę funkcję za pomocą disableWorkflows w konfiguracji lub zmiennej środowiskowej CLAUDE_CODE_DISABLE_WORKFLOWS.
Każde z tych ograniczeń ma znaczenie dla Twojego zadania. Brak danych wejściowych w trakcie oznacza, że nie możesz korygować kursu po uruchomieniu, więc niejasny prompt marnuje tokeny warte pełnego uruchomienia. Wznowienie tylko w tej samej sesji oznacza, że jeśli zamkniesz terminal, uruchomienie przepada. 1000 agentów na uruchomienie brzmi ogromnie, ale szerokie rozdzielenie przy stawkach klasy Opus to realne pieniądze, więc traktuj domyślne 16 agentów jednocześnie jako funkcję, nie jako pułap, który trzeba przesuwać.
Aby wyłączyć:
export CLAUDE_CODE_DISABLE_WORKFLOWS=1
# or set "disableWorkflows": true in your configPułapka z wersją myli ludzi: jeśli /config nie pokazuje wiersza Dynamic workflows, masz wersję poniżej 2.1.154. Najpierw zaktualizuj. A jeśli budujesz takie pipeline agentowe do prawdziwej pracy i chcesz, żeby naprawdę się opłacały, budujemy pipeline agentowe dla zespołów B2B. Umów się na bezpłatną konsultację →, jeśli orkiestracja staje się wąskim gardłem.
Podsumowanie
Oto cały artykuł w pięciu zdaniach. Claude Code workflow to skrypt JavaScript, który Claude pisze w celu orkiestracji subagentów na dużą skalę, dostępny jako research preview w wersji 2.1.154. Ten, który istnieje dzisiaj, to /deep-research. Potrzebujesz workflow tylko wtedy, gdy zadanie przerasta to, co jedna rozmowa jest w stanie skoordynować, gdy chcesz wielokrotnie uruchamialnej orkiestracji lub gdy potrzebujesz, aby agenci krzyżowo się weryfikowali. Nasze rzeczywiste uruchomienie kosztowało ~1 mln tokenów za 9 agentów w 8 minut, co jest przesadą przy łatwych pytaniach i opłaca się przy trudnym researchu. Prawdopodobnie jeszcze go nie potrzebujesz i to jest w porządku.
O autorze
Mert Batur Gurbuz jest współzałożycielem Techsy.io, gdzie zespół dostarcza agentów AI, systemy automatyzacji i pipeline głosowe/SDR dla klientów B2B. Studiuje na University of Birmingham i pisze o stosie narzędzi LLM, którego zespół Techsy faktycznie używa w produkcji.
Współzałożyciel, Techsy.io, University of Birmingham · LinkedIn
Często zadawane pytania
Czym jest Claude Code workflow?
Claude Code workflow to skrypt JavaScript, który orkiestruje subagentów na dużą skalę. Opisujesz zadanie, Claude pisze skrypt, a środowisko wykonawcze uruchamia go w tle, podczas gdy Twoja sesja pozostaje responsywna. To funkcja w fazie research preview w Claude Code w wersji 2.1.154+, dostępna na wszystkich płatnych planach.
Jaka jest różnica między workflow a subagentem?
Subagent to pojedyncze delegowane zadanie działające we własnym, oddzielnym kontekście, koordynowane przez Ciebie w rozmowie. Workflow to skrypt orkiestrujący, który koordynuje wielu subagentów jednocześnie — do 16. Jeśli jedna rozmowa jest jeszcze w stanie utrzymać cały plan, użyj subagenta. Jeśli plan potrzebuje środowiska wykonawczego do śledzenia agentów, użyj workflow.
Ile kosztuje Claude Code workflow w tokenach?
W naszym zmierzonym uruchomieniu /deep-research 9 subagentów w 4 fazach zużyło około 1,05 miliona tokenów w około 8 minut. Workflows z założenia pochłaniają dużo tokenów, ponieważ każdy agent konsumuje własny kontekst, a te agenty działają na modelach klasy Opus. Przy prostych pytaniach to marnotrawstwo; przy prawdziwym wieloźródłowym researchu — koszt się zwraca.
Czy potrzebuję płatnego planu, żeby korzystać z Claude Code workflows?
Tak. Dynamic workflows działają na wszystkich płatnych planach Claude (Pro, Max, Team, Enterprise), a także przez API oraz Bedrock/Vertex/Foundry. Nie ma dostępu w darmowym planie. W planie Pro włączasz tę funkcję, przełączając wiersz Dynamic workflows w /config po aktualizacji do Claude Code w wersji 2.1.154 lub nowszej.
Czym jest /deep-research w Claude Code?
/deep-research to jedyny dołączony workflow dostępny w wersji research preview. Zadajesz mu pytanie, a on rozdziela subagentów do równoległego badania tematu, przeprowadza etap krzyżowej weryfikacji, w którym agenci weryfikują nawzajem swoje ustalenia, a następnie syntetyzuje jedną odpowiedź i zwraca ją do Twojego kontekstu — a to wszystko działając w tle.
Jak zapisać workflow jako polecenie slash?
Opisz zadanie Claude'owi, używając słowa kluczowego workflow, przejrzyj i zatwierdź wygenerowany skrypt JavaScript, a następnie zapisz zatwierdzony skrypt jako niestandardowy /command. Po tym całe wieloagentowe zadanie uruchamia się jednym naciśnięciem klawisza — i właśnie wtedy workflows zaczynają amortyzować swój koszt tokenowy między powtarzalnymi uruchomieniami.
Ilu agentów może jednocześnie uruchomić workflow?
Workflow uruchamia maksymalnie 16 agentów jednocześnie, z twardym limitem 1000 agentów na uruchomienie. Domyślny limit 16 agentów jednocześnie istnieje z dobrego powodu: szerokie rozdzielenie przy stawkach klasy Opus szybko staje się kosztowne. Traktuj limity jako barierki ochronne, nie jako cele, i utrzymuj rozdzielenie tak wąskie, jak pozwala na to zadanie.
Jak wyłączyć Dynamic workflows?
Ustaw disableWorkflows na true w konfiguracji lub wyeksportuj zmienną środowiskową CLAUDE_CODE_DISABLE_WORKFLOWS=1 przed uruchomieniem Claude Code. Oba sposoby całkowicie wyłączają tę funkcję. Jeśli po prostu nie widzisz wiersza Dynamic workflows w /config, prawdopodobnie masz wersję poniżej wymaganej 2.1.154 i musisz najpierw zaktualizować.
Czy naprawdę potrzebujesz Claude Code workflows, czy subagenci wystarczą?
Subagenci wystarczają, dopóki zadanie nie przerośnie jednej rozmowy. Kilku subagentów koordynowanych w zwykłej rozmowie pokrywa codzienną pracę bez kosztu tokenowego. Naprawdę potrzebujesz workflow tylko wtedy, gdy zadanie uruchamia więcej agentów, niż jedna rozmowa jest w stanie ogarnąć, gdy chcesz wielokrotnie uruchamialnej orkiestracji jako kodu lub gdy potrzebujesz, aby agenci adversarialnie weryfikowali się nawzajem.