Subagents: przestań wrzucać całą robotę do jednego contextu
- data
- kategoria
- AI Agents
- także w
- AI Engineering · Automation · Engineering Practices
- czytanie
- 3 min / 666 słów
Mamy już bardzo sprawnego Claude.
Potrafi:
- pracować w repo,
- korzystać z contextu projektu,
- zdobywać dodatkowe informacje,
- używać tools i MCP,
- wykonywać powtarzalne skills.
Naturalny kolejny krok to dawanie mu coraz większych zadań:
Przeanalizuj wymagania, znajdź miejsce zmiany, zaimplementuj feature, dopisz testy, zrób review i popraw wszystkie problemy.
Da się.
Tylko że wszystko odbywa się w jednym context window.
Jeden context zaczyna mieć kilka problemów
1. Rośnie ilość informacji
Research, implementacja, wyniki testów, wcześniejsze błędy i poprawki zostają w historii tej samej sesji.
Im dłuższe zadanie, tym więcej szumu.
2. Role zaczynają się mieszać
Ten sam agent:
- wymyślił rozwiązanie,
- zaimplementował je,
- teraz ma niezależnie ocenić własną implementację.
Technicznie może znaleźć błędy.
Ale review ma większy sens, jeśli dostanie świeży context skupiony na ocenie rezultatu, a nie całą historię dochodzenia do niego.
3. Część pracy jest niezależna
Research kilku modułów albo analiza kilku potencjalnych problemów może być wykonana równolegle.
Nie ma powodu trzymać wszystkiego w jednym wątku.
Subagent to przede wszystkim osobny context
Najgorsze wprowadzenie do multi-agent systems brzmi:
Stworzymy zespół agentów: seniora, product managera i architekta.
Na początek nie potrzebujesz "AI firmy".
Potrzebujesz prostszego modelu:
Subagent to osobna instancja pracy z własnym contextem, której delegujesz konkretne zadanie.
Main Claude może powiedzieć:
reviewer:
przeanalizuj ten diff i znajdź blocking issues
Reviewer nie potrzebuje całej historii implementacji.
Potrzebuje:
- requirements,
- diff,
- zasad projektu,
- instrukcji review.
Fresh context jest feature'em
Wyobraź sobie zadanie:
main Claude:
- przeczytał 40 plików,
- próbował dwóch podejść,
- dostał 5 failing testów,
- poprawił implementację,
- zmienił plan.
Po kilkudziesięciu minutach prosisz:
Teraz zrób niezależne review.
W tym samym context window słowo "niezależne" jest trochę życzeniowe.
Subagent może zacząć od:
requirements
+ final diff
+ project rules
+ review instructions
Bez całego bagażu implementacyjnego.
To jest jeden z najważniejszych powodów używania subagentów.
Nie parallelism.
Context isolation.
Minimalny setup: reviewer i tester
Nie zaczynaj od ośmiu ról.
Na początku wystarczą dwie.
.claude/
+-- agents/
+-- reviewer.md
+-- tester.md
Reviewer
Jego odpowiedzialność:
- przeczytać rezultat,
- znaleźć problemy,
- nie naprawiać ich.
Przykładowy kontrakt:
Review the change independently.
Focus on:
- correctness
- regressions
- error handling
- security
- unnecessary complexity
Do not edit code.
Return:
- blocking findings
- important findings
- suggestions
Tester
Odpowiedzialność:
- ocenić verification,
- znaleźć brakujące przypadki,
- uruchomić lub zaproponować relevant testy.
Verify the implemented behavior.
Check:
- existing test coverage
- missing edge cases
- integration impact
Do not redesign the implementation unless verification requires it.
Jak wygląda zadanie po level-upie?
Przed:
Claude
-> implement
-> test
-> review itself
-> fix
Po:
main Claude
-> implement
reviewer -> findings
tester -> findings
findings
-> main Claude
-> fix
Reviewer i tester mogą być uruchamiani niezależnie, jeżeli nie potrzebują wyników siebie nawzajem.
Dynamiczny subagent vs własna definicja
Claude może delegować jednorazowe zadanie do subagenta bez tworzenia stałej roli.
To dobre np. dla:
Przeanalizuj ten moduł i zwróć mi publiczne API oraz ryzyka zmiany.
Jednak gdy rola powtarza się w SDLC:
reviewer
tester
security-reviewer
warto zdefiniować ją jawnie.
Dzięki temu dostajesz:
- stałe instrukcje,
- kontrolę nad odpowiedzialnością,
- powtarzalne wyniki,
- możliwość iteracyjnego poprawiania roli.
Kiedy nie używać subagenta?
Subagent nie jest domyślnie "lepszy".
Nie deleguj:
znajdź nazwę funkcji w repo
jeżeli main Claude może zrobić grep.
Nie deleguj prostego:
uruchom test
jeśli jest to pojedynczy tool call.
Subagent ma koszt:
- osobny context,
- dodatkowe wywołania,
- konieczność przekazania zadania i odebrania wyniku.
Używaj go, kiedy przynajmniej jedno jest prawdziwe:
potrzebuję fresh context
potrzebuję niezależnej oceny
zadanie jest wyraźnie wydzielone
praca może być sensownie równoległa
Co to zmienia w SDLC?
Implementation + review
Najbardziej oczywisty upgrade.
Autor i reviewer przestają być tym samym contextem.
Research
Kilka niezależnych fragmentów systemu może być analizowanych oddzielnie.
Testing
Verification może być prowadzona bez całej historii implementacji.
Incident analysis
Jeden subagent analizuje logi, drugi deployment history, trzeci relevant code, a main agent syntetyzuje wyniki.
Nie każdy task wymaga multi-agent.
Chodzi o świadome rozdzielenie odpowiedzialności tam, gdzie daje realną korzyść.
Wdróż to dziś
1. Utwórz reviewer
Niech:
- nie edytuje kodu,
- zwraca findings,
- ma jawne kryteria review.
2. Utwórz tester
Niech:
- ocenia verification,
- znajduje missing cases,
- skupia się na zachowaniu, nie historii implementacji.
3. Użyj ich przy następnym większym tasku
Sekwencja:
main -> implementation
reviewer -> review
tester -> verification
main -> fixes
4. Nie twórz kolejnych agentów bez potrzeby
Dodaj następną rolę dopiero wtedy, gdy potrafisz powiedzieć:
Ten fragment pracy potrzebuje osobnego contextu.
Level complete
Poziom jest zaliczony, jeśli implementacja i przynajmniej jedna niezależna weryfikacja nie odbywają się już w tym samym context window.
Na następnym poziomie pojawi się inny problem: nawet mając subagentów, nadal możemy polegać na tym, że główny LLM będzie pamiętał, którego z nich uruchomić później i jakie kroki zostały jeszcze do wykonania.