Claude Code dorobił się tylu funkcji o podobnych nazwach, że łatwo sięgnąć po niewłaściwą — i to akurat tę najdroższą. Skille, sub-agenty, zespoły agentów, /goal, a od premiery modelu Opus 4.8 jeszcze dynamiczne workflow. Brzmią wymiennie, działają zupełnie inaczej, a różnica między nimi to różnica między poprawką za grosze a rachunkiem, który zjada połowę miesięcznego pakietu w jednym poleceniu. Pokażę ci, czym każda z tych rzeczy jest w prostych słowach i — co ważniejsze — kiedy sięgnąć po którą.
Skill, sub-agent, zespół agentów — co tu właściwie jest podobne
Zacznę od trzech pojęć, które najczęściej się mylą. Wszystkie dotyczą tego, ile Claude'ów pracuje nad zadaniem i czy rozmawiają ze sobą — i właśnie to je różni.
Skill to powtarzalny przepis. To zapisany proces, który możesz uruchomić sam w rozmowie z Claude'em albo zlecić agentowi do wykonania. Jeśli wykonujesz tę samą sekwencję kroków raz po raz, zamykasz ją w skillu i odtąd wołasz jedną komendą. Skill nie jest osobnym „pracownikiem” — to instrukcja, z której ktoś korzysta.
Sub-agent to równoległy pomocnik z własnym, czystym kontekstem. Kontekst to pole widzenia modelu — wszystko, co ma „w głowie” w danym momencie. Sub-agenta odpalasz, gdy chcesz coś zrobić obok głównej rozmowy, nie zaśmiecając jej. Czasem Claude uruchamia go sam, czasem ty go wołasz, a czasem budujesz własny plik agenta i przywołujesz go ręcznie. Kluczowe: sub-agenty nie rozmawiają ze sobą. Każdy pracuje we własnym pasie i raportuje wynik z powrotem do twojej głównej sesji — nie do innych sub-agentów.
Zespół agentów to mała załoga, która rozmawia. Tu agenci mają wspólną listę zadań, indywidualne role, własne narzędzia i specjalizacje — i wymieniają się między sobą. To pozwala budować coś w rodzaju „sali narad” czy rady, gdzie agenci debatują i wspólnie dochodzą do celu. Za tę rozmowę się płaci: każda wymiana między agentami to kolejne tokeny, więc zespół jest wyraźnie droższy niż pojedyncze sub-agenty. (Token to najmniejsza jednostka tekstu, którą model przetwarza — i według nich liczy się rachunek.)
To częsty błąd, który widzę: ktoś buduje zespół agentów do zadania, które rozpada się na niezależne kawałki i wcale nie wymaga, żeby agenci ze sobą gadali. Płaci wtedy za rozmowę, która niczego nie wnosi.
/goal kontra workflow — głębokość kontra szerokość
Teraz dwie funkcje, które najtrudniej rozróżnić, bo obie potrafią pracować długo i samodzielnie. Najprościej myśleć o nich jako o głębokości i szerokości.
/goal to pętla. Jeden (albo kilku) agentów wykonuje kolejne podejścia do tego samego zadania, raz za razem, dopóki nie spełni kryterium ukończenia — model w kółko pyta sam siebie „czy gotowe jest już prawdziwe?”. To głębokość: ten sam cel, wiele przebiegów, aż do mety. Taka pętla potrafi działać godzinami, teoretycznie nawet dobę, jeśli kryterium jest trudne do spełnienia.
Dynamiczne workflow to szerokość. Zamiast jednej pętli Claude pisze skrypt w JavaScripcie, który odpala wiele niezależnych sub-agentów — może być ich kilkadziesiąt, może kilkaset. Każdy pracuje sam, we własnym pasie, nad swoim wycinkiem. Nikt nie sprawdza w kółko „czy gotowe?” — wszyscy wykonują plan ustalony na samym początku, a na końcu wyniki łączą się w jedną całość i wracają do głównej sesji. Tu jest istotna różnica względem zwykłych sub-agentów: plan nie siedzi już przy Claude'ie, tylko w tym zapisanym skrypcie. Dzięki temu workflow można zachować i odpalić ponownie kiedy zechcesz.
Obraz, który warto zapamiętać: to drabina rosnącej mocy, kosztu i ryzyka. Na samym dole jest zwykła rozmowa z Claude'em. Wyżej skill. Jeszcze wyżej sub-agent. Potem zespół agentów. Następnie /goal. A na górze dynamiczne workflow. Im wyżej, tym więcej możesz zrobić jednym poleceniem — i tym więcej możesz przy okazji spalić.
Cała ta drabina na jednym slajdzie:
- Szybka rzecz → po prostu zapytaj Claude'a.
- Proces, który powtarzasz → zrób skill.
- Uciążliwe zadanie poboczne → zleć sub-agentowi.
- Mała załoga, która musi się dogadywać → zespół agentów.
- Ma działać, aż spełni kryterium →
/goal. - Wielkie zadanie do zrównoleglenia → dynamiczne workflow.
Kiedy workflow naprawdę się opłaca — i kiedy to przerost formy
Mam jedno pytanie, które rozstrzyga sprawę szybciej niż cała powyższa drabina: czy to zadanie rozpada się na wiele kawałków, które mogą działać niezależnie, w tym samym czasie? Jeśli tak — rozważ workflow. Jeśli nie — prawie na pewno go nie potrzebujesz.
Dwa zadania, do których workflow pasuje naprawdę dobrze: przejrzenie każdego pliku w bazie kodu albo migracja czterystu plików naraz. Stawka jest wysoka, kawałków jest dużo i każdy może dostać własny pas oraz pełną uwagę osobnego agenta. To dokładnie te sytuacje, w których rozdzielenie pracy na dziesiątki równoległych agentów coś realnie daje.
Moim zdaniem warto też powiedzieć szczerze, kiedy nie warto. Pojedyncze poprawki, krótkie pytania, ogólna praca z wiedzą, dążenie do jednego konkretnego rezultatu — tu workflow to przerost formy. Sama nazwa „workflow” nie znaczy, że musisz jej używać codziennie, żeby nie zostać w tyle. Dobrze jest wiedzieć, co dana funkcja robi i kiedy się przydaje — ale to nie to samo, co obowiązek używania jej do wszystkiego. Pytanie zawsze brzmi: czy to rozwiązuje problem, który faktycznie masz teraz?
Koszty i bezpieczeństwo — jak to działa pod spodem
Tu trzeba być uczciwym co do mechanizmu, bo on tłumaczy, skąd biorą się duże rachunki. Każdy agent to pełne wywołanie Claude'a — ma własny kontekst, który musi przeczytać, i odpala się ich wiele naraz. To znaczy, że zużycie tokenów wejściowych (czyli tego, co agenci wczytują) potrafi gwałtownie wystrzelić. Na szczęście tokeny wyjściowe, czyli to, co agenci wypisują, jest zwykle dużo mniejsze i tańsze — więc workflow bywa pracochłonny tokenowo, ale nie zawsze proporcjonalnie drogi.
Skala jest realna: jeden zbyt szeroki prompt potrafi pochłonąć sporą część miesięcznego limitu i działać kilkadziesiąt minut. Klasyczny przykład takiego niekontrolowanego zadania to puszczenie agentów na przeszukanie całego pulpitu i wszystkich lokalnych repozytoriów w poszukiwaniu jakiejś analizy — zakres niczym nie ograniczony, więc tokeny znikają hurtowo. Stąd trzy zasady, które stosuję, zanim odpalę cokolwiek szerokiego:
- Ogranicz zakres. Powiedz dokładnie, gdzie agenci mają szukać, a gdzie nie.
- Nazwij konkretny rezultat. Im precyzyjniej opiszesz, czego chcesz, tym mniej zbędnej pracy. (Ta sama logika dotyczy
/goal— niejasne polecenie potrafi zapętlić się na długo, bo agent nie wie, kiedy „gotowe” jest prawdziwe.) - Posadź pracowników na Haiku. Haiku to najszybszy i najtańszy z modeli Claude'a — w sam raz do wielu drobnych, równoległych zadań.
Jest też dobra wiadomość po stronie bezpieczeństwa: workflow nigdy nie odpala się przypadkiem. Claude najpierw prosi o potwierdzenie, a zanim cokolwiek ruszy, możesz obejrzeć surowy skrypt, który ma zostać wykonany. W trakcie komenda /workflows pokazuje wszystkie uruchomione przebiegi — widzisz, ilu agentów pracuje, na jakim modelu, ile zużyli tokenów i jak długo działają — i tam też możesz je zatrzymać.
Szczegóły, które łatwo przeoczyć
Kilka rzeczy, o których warto wiedzieć, zanim spróbujesz sam.
Gdzie zapisują się workflow. Domyślnie skrypt może wylądować w lokalizacji globalnej, gdzieś poza twoim projektem. Jeśli chcesz mieć go pod ręką w repozytorium, powiedz Claude'owi wprost, żeby zapisał go w .claude/workflows wewnątrz projektu — inaczej będziesz go potem szukać.
Skill mieści się w workflow. Skille i workflow to nie konkurencja — uzupełniają się. Skill mówi jak coś zrobić, workflow decyduje na ilu frontach i jak szeroko to wykonać. Skoro workflow odpala sub-agenty, a sub-agenty potrafią czytać i używać twoich skilli, to skill spokojnie zagnieżdża się w środku.
/deep research to gotowy workflow. Ta funkcja sama uruchamia workflow pod spodem: odpala wiele agentów do równoległego researchu, każą im głosować nad każdą tezą, a na końcu dostajesz raport z przypisami. Jeśli dużo szukasz źródeł, to dobry sposób, żeby zobaczyć workflow w działaniu, nie budując nic od zera.
ultracode to tryb na maksa. W ustawieniach poziomu wysiłku modelu masz niski, średni, wysoki, bardzo wysoki i maksymalny. Osobno jest ultracode — najinteligentniejszy i najdroższy: łączy bardzo wysoki poziom rozumowania z workflow włączonymi domyślnie. W tym trybie Claude pomija część zwykłych pytań o zgodę i od razu zaczyna orkiestrować, więc traktuj go jak narzędzie do świadomego, kosztownego wyjątku, nie do codziennej pracy.
Cała ta rodzina funkcji sprowadza się do jednej decyzji: nie pytaj, która jest najmocniejsza, tylko która pasuje do problemu, który masz dziś przed sobą. Moc bez ograniczonego zakresu to nie przewaga — to rachunek. Następnym razem, gdy poczujesz pokusę odpalenia czegoś dużego, zadaj sobie to jedno pytanie o niezależne kawałki i nazwij rezultat, zanim naciśniesz „uruchom”.