Subagenci i delegowanie

1. Przegląd koncepcji i problem systemowy

W złożonych zadaniach deweloperskich znaczną część czasu pochłania „brudna” praca rozpoznawcza: wyszukiwanie po słowach kluczowych w setkach plików, czytanie dokumentacji, przeglądanie logów systemowych czy sprawdzanie dziesiątek zależności.

Jeśli wszystkie te operacje wykonuje jeden główny agent w ramach pojedynczej sesji dialogowej:

1. Katastrofalne zanieczyszczenie kontekstu (Context Pollution): Tysiące linii surowego kodu i logów wypierają początkowe instrukcje systemowe użytkownika.
2. Degradacja uwagi (Lost-in-the-Middle): Agent zaczyna gubić się we własnych roboczych notatkach, tracąc z oczu pierwotny cel.
3. Sekwencyjne wąskie gardło (Sequential Bottleneck): Agent jest zmuszony przeglądać każde źródło po kolei, marnując minuty tam, gdzie pracę można zrównoleglić w sekundy.

Wzorzec subagentów (Subagents) wprowadza zasadę izolacji kontekstu wykonania: agent nadrzędny uruchamia odrębne procesy potomne z czystym oknem uwagi, deleguje im rutynowe zadania i otrzymuje zwrotnie jedynie uszczegółowiony, ustrukturyzowany wniosek.

2. Taksonomia architektoniczna i model mentalny

Ze względu na sposób organizacji pracy subagentów wyróżnia się trzy główne topologie:

• 1. Fork-Join (wzorzec Map-Reduce): Agent nadrzędny dzieli duże zadanie na $N$ niezależnych części (np. analizę 4 osobnych mikrousług), jednocześnie uruchamia 4 równoległych subagentów (Fork), czeka na ich zakończenie i scala wyniki w jeden raport (Join).
• 2. Transient Deep-Dive Worker (Jednorazowy zwiadowca): Subagent powstaje na potrzeby jednej specyficznej operacji: np. wejścia na stronę dokumentacji, przejścia autoryzacji, znalezienia przykładu użycia endpointu i zwrócenia jedynie 5 linii kodu. Po zakończeniu kontener subagenta jest usuwany.
• 3. Hierarchiczne drzewo z ograniczeniem głębokości (Bounded Delegation Tree): Proces nadrzędny zarządza subagentami pierwszego poziomu, które w razie potrzeby mogą uruchamiać workerów drugiego poziomu. Aby zapobiec niekontrolowanemu zużyciu zasobów, głębokość rekurencji jest ściśle limitowana (max_depth = 2).

3. Techniczny pipeline i mechanika wewnętrzna

Cykl życia pracy subagenta:

1. Delegation Call (Inicjacja delegowania): Główny agent wywołuje specjalne narzędzie startowe: invoke_subagent(task_name="grep_auth_logs", prompt="...", tools=["grep", "cat"]).
2. Context Sandbox Isolation (Tworzenie izolowanego wątku): Runtime podnosi nową sesję LLM z czystym kontekstem. Wstrzykiwane są do niej wyłącznie instrukcja dla podzadania oraz ograniczona lista dozwolonych narzędzi.
3. Autonomous Execution (Autonomiczna pętla wewnętrzna): Subagent realizuje własną pętlę ReAct, popełnia błędy, testuje hipotezy i formułuje wynik końcowy, nie obciążając agenta nadrzędnego komunikatami pośrednimi.
4. Synthesis & Garbage Collection (Zwinięcie i zwrot danych): Surowy log dialogu subagenta jest archiwizowany lub niszczony. Główny agent otrzymuje wiadomość od narzędzia z krótkim streszczeniem (np.: „Znaleziono 2 wycieki pamięci w pliku worker.ts: linie 14 i 89”).

4. Praktyczne scenariusze inżynierskie w produkcji

01. Równoległy audyt bezpieczeństwa dużego monorepo

Główny architekt uruchamia trzech subagentów jednocześnie:

• Worker 1: skanuje backend pod kątem SQL injection i niebezpiecznych surowych zapytań.
• Worker 2: sprawdza frontend pod kątem XSS i niebezpiecznych wywołań dangerouslySetInnerHTML.
• Worker 3: analizuje pliki konfiguracyjne Docker i CI/CD pod kątem otwartych portów i niezabezpieczonych obrazów. Każdy subagent czyta setki plików, ale główny architekt otrzymuje zwięzłą tabelę zbiorczą z trzema krytycznymi punktami.

02. Analiza tła dla ogromnych logów serwerowych

Zamiast przesyłać 50 megabajtów logów Nginx do głównego kontekstu, uruchamiany jest subagent-analityk. Filtruje on lokalnie logi za pomocą grep/awk, wykrywa anomalny wzrost statusów HTTP 500 i zwraca głównemu agentowi wyłącznie wydzielony stack trace.

03. Badanie zewnętrznych bibliotek bez utraty fokusu

Podczas gdy agent kodujący projektuje architekturę usługi, wysyła subagenta do przeczytania oficjalnej dokumentacji Stripe API. Subagent rozpracowuje składnię checkoutów i zwraca gotowy minimalny przykład kodu.

5. Pułapki, typowe błędy i bezpieczeństwo

• Burza tokenów i limity Rate Limits (TPM Spikes): Uruchomienie 10 subagentów jednocześnie generuje ogromny skok liczby zapytań do providera, co prowadzi do kaskadowych błędów 429 Too Many Requests. Zawsze stosuj kolejki zadań z ograniczeniem puli (np. maksymalnie 3 jednoczesnych workerów).
• Konflikty zapisu równoległego (Race Conditions): Jeśli dwóch subagentów spróbuje jednocześnie edytować ten sam plik w repozytorium, nastąpi nadpisanie lub uszkodzenie kodu. Nadawaj subagentom badawczym wyłącznie uprawnienia Read-Only.
• Nieskończona rekurencja delegowania (Fork Bomb): Subagent uznaje zadanie za zbyt trudne i uruchamia kolejnych 5 subagentów, którzy robią to samo. Zawsze zabraniaj agentom potomnym wywoływania narzędzia invoke_subagent.