Czym jest Orkiestracja Równoległa i jak zastosować ją w Claude Code?

Orkiestracja Równoległa to sposób pracy w Claude Code, w którym zamiast wykonywać wiele zadań jedno po drugim w tej samej konwersacji, skill nadrzędny odpala niezależne subagenty naraz, każdy z własnym, izolowanym oknem kontekstowym. Testowałem swój skill do audytów treści pod SEO na kilku adresach jednocześnie i wynik wyglądał świetnie, dopóki nie przeczytałem raportów uważnie. Trzeci audyt „wiedział” o pierwszym i drugim, mimo że każdy miał być całkowicie od siebie niezależny. W tym wpisie pokazuję dokładnie, dlaczego tak się dzieje w każdym wieloetapowym procesie opartym o jedną konwersację w Claude Code, i jak eliminuje to Orkiestracja Równoległa: subagenci, z których każdy dostaje osobne, izolowane okno kontekstowe. Kiedy skille w Claude Code są podatne na zanieczyszczenie kontekstu? Chodzi o skille, które są czymś więcej niż jednym plikiem z promptem: takie, które mają podpięte narzędzia typu MCP, albo w instrukcjach mają wskazane wywoływanie innych, zależnych skilli. Jeśli Twój skill to pojedynczy, samodzielny prompt, to ten problem raczej się nie pojawi. Na czym polega zanieczyszczenie kontekstu przy zadaniach wsadowych? Pisałem już o tym, czym jest okno kontekstowe w dużych modelach językowych: działa jak pamięć operacyjna, która mieści całą historię danej konwersacji. To świetna cecha, kiedy kolejne zadania mają na sobie bazować. Staje się problemem, kiedy chcesz, żeby zadania były od siebie całkowicie niezależne, a mimo to idą jedno po drugim w tym samym oknie. Wyobraź sobie, że zlecasz trzem analitykom osobne raporty o trzech niepowiązanych firmach, ale sadzasz ich przy jednym stole i każesz każdemu kolejnemu czytać notatki poprzednika, zanim zacznie pisać swój. Nawet najbardziej zdyscyplinowany analityk złapie się na tym, że mimowolnie odnosi się do wcześniejszych ustaleń. Mój przypadek: Patent Content Auditor Przygotowałem skilla, który automatycznie audytuje treści pod SEO i analizuje je pod kątem patentów Google (Patent Content Auditor). Skill oprócz własnych instrukcji ma wskazane wywoływanie innych skilli, a także korzysta z narzędzi zewnętrznych: MCP do scrapowania oraz zewnętrznego API do pobierania wyników Google. Testowałem go na modelu Claude Sonnet 5, który ma obecnie milionowe okno kontekstowe. Podałem mu 3 adresy do zaudytowania jeden po drugim, w jednej konwersacji, krok po kroku: GŁÓWNA KONWERSACJA: jedno okno kontekstowe ├─ Audyt: URL 1 → raport 1 │ ├─ Audyt: URL 2 → raport 2 ⚠️ "widzi" treść raportu 1 │ └─ Audyt: URL 3 → raport 3 ⚠️ "widzi" treść raportu 1 i 2 ⚠️ ryzyko: kompaktowanie w dowolnym momencie może wyciąć instrukcje z początku sesji Dlaczego kolejne audyty „wiedzą” o poprzednich? To nie błąd modelu. To naturalna konsekwencja wspólnego okna kontekstowego. Model ma dostęp do całej historii konwersacji i z niej korzysta, bo tak działa. W treściach zaczęły się pojawiać odniesienia do wcześniejszych audytów, mimo że zamysł był inny: każdy audyt miał być autonomiczną jednostką wiedzy, możliwą do rozczytania bez znajomości pozostałych. Drugie ryzyko jest subtelniejsze: funkcja kompaktowania konwersacji uruchamia się w nieprzewidywalnym momencie, co może powodować utratę wcześniejszych danych. Zauważyłem to konkretnie w jednym z raportów: podsumowanie w ostatnim wykonanym audycie było krótsze niż minimum wskazane w skillu wywołanym na samym początku konwersacji. Ta instrukcja gdzieś po drodze się zgubiła. Jak dokładnie działa Orkiestracja Równoległa? Zamiast puszczać audyty jeden po drugim w jednej konwersacji, dodatkowy skill nadrzędny, orkiestrator, odpala N niezależnych subagentów naraz, z których każdy dostaje własne, izolowane okno kontekstowe. Wymagało to przeanalizowania całej logiki procesu, który miałem dotychczas, i dodania nowych elementów w niektórych narzędziach. AGENT GŁÓWNY: krótki prompt z listą URL i wytycznymi językowymi ├──▶ Subagent A: własne, izolowane okno kontekstowe, audyt URL 1 ├──▶ Subagent B: własne, izolowane okno kontekstowe, audyt URL 2 └──▶ Subagent C: własne, izolowane okno kontekstowe, audyt URL 3 (wszystkie działają równolegle i nie widzą swoich wyników) Jak wdrożyć Orkiestrację Równoległą? Trzy kluczowe elementy 1. Krótki prompt startowy Do agenta głównego idzie tylko krótki prompt: jakimi adresami ma się zająć, plus niezbędne wytyczne językowe. Zgodnie z instrukcjami zawartymi w skillu, agent zaczyna tworzyć subagentów: każdy z nich też dostaje krótki prompt startowy i zadanie wykonania pełnego procesu audytu. 2. Izolowane okno kontekstowe per subagent Dzięki temu proces nie idzie liniowo. W moim teście zostało odpalonych 7 audytów równolegle, każdy z takimi samymi wytycznymi. Jedyną zmienną był adres audytowanej strony. Każdy subagent nie wie, co robią inni ani jakie są ich wyniki. Skupia się wyłącznie na własnym zadaniu, bez szumu informacyjnego przechodzącego między audytami. Dodatkowy plus: główna konwersacja zużyła jedynie kilkadziesiąt tysięcy tokenów, tylko na wystartowanie procesu, oddelegowanie pracy i podsumowanie wyników na końcu. 3. Determinizm modelu i effortu Subagenci teoretycznie powinni dziedziczyć te same ustawienia co skill nadrzędny, ale jeśli nie ustawimy tego wprost, w teorii nie jest to deterministyczne. Dlatego najlepiej samemu, na poziomie skilla, zapisać wprost, jakiego modelu i jakiego effortu oczekujemy dla każdego wywołania subagenta: javascript // Ustawione na sztywno dla KAŻDEGO wywołania agenta // (głównego i przy automatycznym ponowieniu), // niezależnie od pozostałych parametrów wejściowych: model: 'claude-sonnet-5', effort: 'xhigh' Tej samej zasady można użyć w drugą stronę: jeśli zadanie jest proste, warto nakazać subagentowi użycie tańszego, szybszego modelu zamiast dziedziczyć domyślny np. Haiku. Na co uważać przy Orkiestracji Równoległej w Claude Code? Ograniczony wgląd w subagentów Kiedy praca jest oddelegowana, subagentów widać wyłącznie jako zadania w tle: ile tokenów zużyli, ile narzędzi użyli, jak długo pracowali (przy użyciu Claude Desktop). Nie widać ich procesu myślowego ani konkretnie wykonywanych kroków w czasie rzeczywistym. To możliwe tylko w głównym oknie konwersacji. Jeśli chcesz dokładnie sprawdzić, co się działo na zapleczu, trzeba zajrzeć do plików utworzonych na dysku w trakcie procesu. Limity narzędzi zewnętrznych Warto zwrócić uwagę na potencjalne limity odpytań, jeśli do procesu podpięte jest jakieś API. U mnie było to API do danych SERP, które musiało obsłużyć na jednym kluczu wiele odpytań jednocześnie, kiedy pracowało tylu agentów naraz. Sekwencyjnie czy Orkiestracja Równoległa? Porównanie CechaSekwencyjnie (jedno okno)Orkiestracja RównoległaNiezależność audytówKolejne raporty odnoszą się do poprzednichKażdy raport w pełni autonomicznyRyzyko kompaktowaniaMoże wyciąć instrukcje z początku sesji w dowolnym audycieDotyczy tylko pojedynczego, izolowanego zadaniaKoszt głównej konwersacjiRośnie z każdym kolejnym audytemKilkadziesiąt tysięcy tokenów, niezależnie od liczby audytówModel i effort subagentówDomyślne dziedziczenie, w teorii niedeterministyczneUstawione wprost w skilluCzas wykonaniaSuma czasu wszystkich audytówCzas najwolniejszego z audytów (działają współbieżnie)Widoczność w czasie rzeczywistymPełna: wszystko w jednym oknieOgraniczona do metryk tła: tokeny, liczba narzędzi, czas Gdzie jeszcze można zastosować Orkiestrację Równoległą? Ten wzorzec sprawdza się wszędzie tam, gdzie masz wiele niezależnych jednostek pracy do przetworzenia w ramach jednego zadania: - audyty treści dla wielu adresów URL naraz (mój przypadek), - analiza konkurencji dla wielu domen jednocześnie, - generowanie wielu niezależnych raportów lub artykułów z jednego kalendarza treści, - sprawdzanie wielu podstron pod kątem tej samej checklisty (np. zgodności ze schema markup), - każde zadanie, którego wynik ma być czytelny bez znajomości pozostałych elementów partii. FAQ Czy Orkiestracja Równoległa działa tylko w Claude Code, czy też przez API? + Subagenci z izolowanym kontekstem to nie tylko funkcja interfejsu Claude Code. Ten sam mechanizm jest częścią Claude Agent SDK, więc podobną orkiestrację można zbudować we własnej aplikacji, nie tylko przez skille odpalane w Claude Code. Ile subagentów mogę odpalić naraz? + Nie ma jednego, sztywnego, oficjalnie podanego limitu ich liczby. W praktyce granicą jest koszt tokenów oraz limity zewnętrznych narzędzi, z których korzystają. U mnie było to API do danych SERP, obsługujące na jednym kluczu odpytania od wszystkich agentów naraz. Czy subagenci mogą się ze sobą komunikować w trakcie pracy? + Nie. To sedno tego wzorca: do agenta nadrzędnego wraca wyłącznie ostateczny wynik każdego subagenta, nie pośrednie kroki ani wgląd w to, co robią pozostali. Czy to szybsze, czy wolniejsze niż podejście sekwencyjne? + Szybsze, jeśli zadania są faktycznie niezależne: działają współbieżnie, więc całość kończy się w czasie najwolniejszego z nich, a nie sumy wszystkich, jak przy podejściu krok po kroku.