Wpisuję jedno polecenie i nagle widzę pięć osobnych rozmów, które ruszają równolegle. Każda ma inną „osobowość”: jedna udaje kompletnego początkującego, druga inżyniera, trzecia dyrektora w dużej firmie. Wszystkie czytają ten sam materiał i każda wraca z własną oceną — a moja główna rozmowa zostaje czysta. To są sub-agenty. Pokażę ci, czym naprawdę są, czym różnią się od skilli, kiedy warto je włączyć, a kiedy tylko spowolnią ci pracę.
Czym jest sub-agent
Wyobraź sobie, że twoja główna rozmowa z Claude Code to dyrygent. To z nią rozmawiasz, jej wydajesz polecenia, ona prowadzi cały projekt. W terminologii narzędzia nazywa się ją sesją główną albo orkiestratorem. Sub-agent to pracownik, którego ten dyrygent powołuje do jednego konkretnego zadania: „przeczytaj te pliki”, „zrób research”, „napraw ten błąd”.
Najważniejsza rzecz: sub-agent rozmawia tylko z sesją główną, nigdy bezpośrednio z tobą. Dostaje zadanie, wykonuje je w osobnym oknie i wraca z krótkim raportem. Sesja główna czyta ten raport i przekazuje ci wynik. Ty cały czas masz do czynienia z jednym rozmówcą — resztą zarządza on sam.
Co istotne, każdy sub-agent budzi się ze świeżym, pustym kontekstem. „Kontekst” to po prostu pamięć bieżącej rozmowy: wszystko, co do tej pory napisałeś i co model przeczytał. Sub-agent tego nie dziedziczy. Dostaje czystą kartkę, swoje zadanie i tyle. Może też mieć własny model językowy, własną osobowość, własne uprawnienia i własną wiedzę specjalistyczną — o tym za chwilę.
Po co to komu — pięć powodów
Sub-agenty nie są efektowną zabawką. Każda z ich zalet rozwiązuje konkretny, codzienny problem.
Trzymają główny kontekst w czystości. Im dłużej rozmawiasz, tym bardziej zapełnia się okno kontekstu, i tym więcej śmieci zalega w pamięci modelu. Jeśli masz przed sobą zadanie, które wypluje ścianę tekstu, do której nigdy więcej nie zajrzysz — na przykład przeczytanie raportu na 300 stron po to, by wyciągnąć trzy fakty — oddaj je sub-agentowi. On przeczyta wszystko u siebie, a do ciebie wróci krótkie streszczenie. Twoja główna rozmowa zostaje lekka.
Pracują równolegle. Jeśli zadania są od siebie niezależne, nie muszą czekać jedno na drugie. Masz piętnaście rozdziałów książki do sprawdzenia? Kolejność nie ma znaczenia, więc piętnastu sub-agentów może je recenzować w tym samym czasie. To różnica między czekaniem w kolejce a obsłużeniem wszystkich naraz.
Oszczędzają pieniądze. Modele różnią się ceną. Najmocniejszy (Opus) jest najdroższy, tańsze (Sonnet, Haiku) wystarczają do prostszej roboty. Możesz więc na co dzień rozmawiać z mądrym, drogim „szefem”, a on rozdziela monotonną pracę między tanich „pracowników”. Czytanie i streszczanie raportu spokojnie zrobi tani model — nie ma sensu płacić za to najwyższą stawkę.
Dają bezstronnego recenzenta. Skoro sub-agent budzi się bez pamięci, nie zna twoich wcześniejszych argumentów i nie ma powodu, by się z tobą zgadzać. To częsty problem, który widzę: modele bywają potakiwaczami, przyklaskują pomysłom, zamiast je sprawdzać. Świeży sub-agent, ustawiony na bezlitosną krytykę planu, da ci uczciwszą ocenę niż rozmówca, który właśnie chwalił ten sam pomysł trzy zdania wyżej.
Są specjalistami. Zamiast jednego asystenta od wszystkiego możesz mieć wąsko wyspecjalizowanych pracowników: jeden zna się na bezpieczeństwie, drugi pisze testy, trzeci dokumentację, czwarty na bazach danych. Każdy robi jedną rzecz, ale naprawdę dobrze.
Sub-agent kontra skill — gdzie naprawdę leży różnica
Tu robi się ciekawie, bo na pierwszy rzut oka sub-agent i skill to to samo. I po części tak jest.
Oba są dosłownie jednym plikiem tekstowym w formacie markdown. Na górze pliku siedzi krótki nagłówek (tak zwany front matter) z dwoma kluczowymi polami: nazwą i opisem. Pod spodem są właściwe instrukcje — co dany element ma robić i w jakiej kolejności. To wszystko. Skill i sub-agent mają identyczną budowę.
Ten nagłówek działa według prostej, sprytnej zasady, którą nazywam stopniowym odsłanianiem (progressive disclosure). Kiedy wydajesz polecenie, Claude Code nie czyta od razu wszystkich twoich skilli i sub-agentów w całości — to byłoby marnowanie pamięci. Czyta tylko nazwę i opis, a na ich podstawie decyduje: „czy to pasuje do tego, o co właśnie poproszono?”. Jeśli tak, dopiero wtedy wczytuje całą resztę pliku i go uruchamia. Jeśli nie — pomija.
A teraz jedyna różnica, która naprawdę ma znaczenie: sub-agent działa w osobnym, czystym oknie kontekstu i może pracować równolegle z innymi, na własnym modelu. Skill zwykle uruchamia się wewnątrz twojej głównej rozmowy. To wszystko. Skill jest jak umiejętność, którą włączasz u siebie tu i teraz — „teraz potrafię pisać posty na LinkedIn”, „teraz robię research”. Sub-agent jest jak osobny pracownik, którego wysyłasz w teren.
I — co ważne — one ze sobą współpracują, nie konkurują. Sub-agent może wywołać skill, a skill może powołać sub-agenty. Możesz mieć świetny skill do researchu na LinkedIn i przekazywać go sub-agentom do wykonania. To nie jest wybór „albo-albo”.
Jak napisać dobry sub-agent
Najważniejsza, a najczęściej zaniedbywana część to opis w nagłówku. To on jest wyzwalaczem — to po nim Claude decyduje, czy w ogóle uruchomić sub-agent. Słaby, ogólnikowy opis prowadzi do tego, co nazywam chybieniami: sub-agent odpala się, kiedy nie powinien, albo milczy, kiedy bardzo go potrzebujesz.
Dlatego opis pisz precyzyjnie. Zamiast „pomaga z planami” napisz, kiedy dokładnie ma się włączyć i na jakie frazy reagować — na przykład „uruchom, gdy poproszę o skrytykowanie albo przejrzenie planu”. Jeśli chcesz, by włączał się chętnie, możesz wprost zaznaczyć, żeby był używany aktywnie (proactively).
Strojenie tego opisu to praca metodą prób. Za pierwszym razem rzadko jest idealnie. Kiedy sub-agent nie odpalił, choć powinien, zatrzymaj się i zapytaj sam siebie — albo wprost Claude'a — dlaczego tak się stało, a potem popraw opis. Tak samo, gdy włączył się niepotrzebnie. Drobna uwaga z praktyki: jeśli w opisie otworzysz cudzysłów, pamiętaj go zamknąć — niedomknięty cudzysłów potrafi po cichu rozłożyć cały nagłówek i sub-agent w ogóle nie zadziała.
Dopiero gdy nagłówek jest dopracowany, przechodzisz do właściwej treści — czyli instrukcji, jak sub-agent ma pracować i które skille wywołuje. Tu też się iteruje: po każdym użyciu masz okazję powiedzieć mu, co zrobił dobrze, a co źle, i tak go szlifujesz.
W nagłówku da się ustawić znacznie więcej niż samą nazwę i opis. Możesz przypisać konkretny model (mądry i drogi albo tani i szybki), nadać kolor, by od razu widzieć w terminalu, który sub-agent działa, oraz — to ważne — ograniczyć jego uprawnienia. Możesz wskazać, z jakich narzędzi wolno mu korzystać, a jakie są zabronione. Możesz na przykład odebrać mu prawo do zapisywania i edytowania plików, czyniąc go agentem tylko do odczytu. Możesz określić, z których zewnętrznych usług (serwerów MCP) może korzystać, i czy ma pamiętać cokolwiek między uruchomieniami. Jeśli nie wiesz, jak to zapisać, poproś Claude'a, by zajrzał do dokumentacji i pomógł ci złożyć poprawny nagłówek pod konkretne wymagania.
Twój czy zespołu — gdzie sub-agent mieszka
Sub-agent może żyć w dwóch miejscach, i ten wybór ma praktyczne konsekwencje.
Poziom projektu to sub-agenty zapisane wewnątrz konkretnego projektu, w jego repozytorium (czyli w folderze z całym kodem i ustawieniami danego przedsięwzięcia). Jeśli udostępnisz to repozytorium współpracownikom, dostaną razem z nim te sub-agenty. To dobry wybór, gdy chcesz, by cały zespół pracował na tych samych narzędziach.
Poziom globalny to sub-agenty zapisane przy twoim koncie, w folderze domowym. Należą do ciebie i działają w każdym projekcie na twoim komputerze — niezależnie od tego, nad czym akurat pracujesz. Ale gdy udostępnisz komuś repozytorium projektu, te globalne nie pójdą razem z nim. Zostają u ciebie.
Skoro sub-agent to tylko plik tekstowy, przeniesienie go z jednego miejsca w drugie jest banalne. Jeśli przez pomyłkę utworzysz coś globalnie, a chciałeś mieć to tylko w jednym projekcie, po prostu prosisz o przeniesienie pliku. Moja domyślna rekomendacja: trzymaj sub-agenty na poziomie projektu, chyba że naprawdę chcesz mieć dane narzędzie wszędzie.
Kiedy odpuścić — i jeden ostrzeżony tryb „na grubo”
Sub-agenty są świetne, ale wciskanie ich do każdego zadania pogarsza wyniki. Mam jedno proste pytanie kontrolne: czy to zadanie zaraz wsypie do mojej rozmowy stos rzeczy, do których nigdy nie wrócę? Jeśli tak — deleguj. Jeśli nie — zostaw to w głównej rozmowie.
Sygnały, że sub-agent się przyda: masz do przeczytania mnóstwo plików, spodziewasz się ściany tekstu na wyjściu, powtarzasz tę samą robotę po raz setny (zbuduj wtedy własny, stały sub-agent), albo masz wiele niezależnych zadań do puszczenia równolegle.
A teraz, kiedy lepiej odpuścić:
- Szybka, drobna poprawka. Powołanie sub-agenta to narzut, który tu się nie zwróci.
- Kroki zależne od siebie. Jeśli zadanie idzie po kolei — najpierw 1, potem 2, potem 3 — sub-agenty nic nie dadzą, bo ich siłą jest praca równoległa, a tu i tak trzeba czekać.
- Agenci musieliby ze sobą rozmawiać. Tu uwaga na granicę pojęć: sub-agenty rozmawiają wyłącznie z sesją główną, nigdy między sobą. Jeśli uruchomisz pięciu sub-agentów, są dla siebie nawzajem niewidoczni. Gdy zadanie wymaga, by wykonawcy wymieniali się informacjami i dzielili wspólną listą zadań, potrzebujesz czegoś innego — tak zwanego zespołu agentów. To osobna, droższa konstrukcja właśnie dlatego, że oni ze sobą gadają. Sub-agenty łączy z sesją główną prosta relacja jeden-do-jednego.
- Potrzebny pełny kontekst rozmowy albo pytanie do ciebie. Sub-agent budzi się czysty i nie ma jak zadać ci pytania — rozmawiasz tylko z sesją główną. Jeśli zadanie wymaga całej historii albo dopytania, zostaw je w głównym wątku.
Jest też nowszy, mocniejszy tryb: dynamiczne przepływy pracy (dynamic workflows). Gdy zlecasz duży projekt, Claude potrafi sam powołać do niego naraz kilkadziesiąt, a w skrajnych przypadkach nawet kilkaset sub-agentów i rozdzielić robotę między nich. To potężne, ale kosztowne — taki przepływ potrafi błyskawicznie zjeść twój limit sesji. Z tego powodu zmieniono nawet jego frazę-wyzwalacz na bardziej dosadną („ultracode”), żeby nie odpalał się przez przypadek przy zwykłym poleceniu. Traktuj to jako opcję „na grubo”: świadomie i z ręką na bezpieczniku.
Bezpieczeństwo: zakładaj najgorsze
Jedna zasada, której się trzymam i którą polecam tobie: jeśli agent może dotknąć danych, zakładaj, że to zrobi — nawet jeśli nigdy go o to nie poprosisz. Dlatego jest ogromna różnica między prawdziwą warstwą uprawnień a samym proszeniem.
Napisanie w instrukcji „nie ruszaj tych danych, nie martw się nimi” to słaba ochrona — to tylko prośba. Mocna ochrona to wprost zdefiniowane uprawnienia: lista narzędzi, z których wolno mu korzystać, i lista zewnętrznych usług, do których ma dostęp. Jeśli sub-agent ma tylko czytać, odbierz mu prawo zapisu na poziomie ustawień, a nie tylko w treści promptu.
To staje się szczególnie ważne, gdy sięgasz po cudze sub-agenty. Skoro to zwykłe pliki tekstowe, w sieci krążą ich tysiące — gotowe specjalizacje od ludzi, którzy znają się na czymś lepiej niż ty. To wygodne, ale każdy taki plik wczytujesz do swojego systemu w ciemno. W tekście może czaić się tak zwane wstrzyknięcie poleceń (prompt injection): ukryta instrukcja, która próbuje przejąć kontrolę nad twoim agentem. Dobrym zabezpieczeniem jest tu sub-agent-weryfikator: ustawiony tylko do odczytu, bez prawa wysyłania czegokolwiek na zewnątrz, którego jedynym zadaniem jest sprawdzić, czy w pobranym pliku nie ma niczego złośliwego.
Co z tego zapamiętać
Sub-agent to nie magia, tylko prosty mechanizm: świeży kontekst, własny model, jedna wąska specjalizacja i krótki raport z powrotem. Jego wartość pojawia się w czterech sytuacjach — gdy chcesz mieć specjalistę, gdy chronisz czystość głównej rozmowy, gdy masz niezależne zadania do puszczenia równolegle i gdy taniej jest oddać monotonną robotę słabszemu modelowi. Poza tymi sytuacjami sub-agent częściej przeszkadza, niż pomaga.
Moja zasada na koniec: nie szukaj zadań pod sub-agenty — szukaj sub-agentów pod zadania, które naprawdę do nich pasują. Następnym razem, gdy poczujesz, że rozmowa zaraz spuchnie od czegoś, do czego i tak nie wrócisz, zatrzymaj się na sekundę i zadaj sobie to jedno pytanie. Jeśli odpowiedź brzmi „tak” — to twój moment, by delegować.