Skill, subagent czy multi-agent? Jak dobrać architekturę do zadania
Skill, subagent i multi-agent rozwiązują różne problemy. Porównuję ich rolę, koszt handoffów i sytuacje, w których naprawdę pomagają.
Skill, subagent i system multi-agent rozwiązują różne problemy. Skill dostarcza jednej instancji agenta instrukcje i procedurę. Subagent dostaje osobny kontekst do wykonania wydzielonej części pracy. System multi-agent koordynuje wielu wykonawców, ich stan i komunikację. Wybór nie powinien zależeć od tego, co brzmi najbardziej zaawansowanie, lecz od tego, gdzie naprawdę potrzebna jest izolacja lub równoległość.
Kiedy wystarczy skill
Skill jest dobry, gdy zadanie ma powtarzalny sposób wykonania: audyt SEO, przygotowanie release notes, analiza danych według ustalonego schematu. Przechowuje zasady, checklistę, szablony i czasem skrypty.
Najważniejsza zaleta to spójność bez kosztu dodatkowej koordynacji. Agent nadal pracuje w jednym kontekście, widzi bieżące decyzje i może wykonać procedurę od początku do końca.
Skill nie zwiększa sam z siebie pamięci ani mocy modelu. Porządkuje pracę. Jeśli problemem jest brak instrukcji lub powtarzalny błąd procesu, zacznij właśnie tutaj.
Kiedy subagent ma sens
Subagent otrzymuje osobne zadanie i kontekst. Warto go użyć, gdy część pracy jest:
- niezależna od głównego toku,
- wystarczająco duża, by uzasadnić przekazanie,
- łatwa do opisania przez wynik i kryterium weryfikacji,
- korzystna do wykonania równolegle albo jako zimny przegląd.
Przykładem może być techniczny audyt integracji wykonywany równolegle z przygotowaniem treści. Każdy ma własny zakres, a koordynator później sprawdza i łączy rezultaty.
Subagent nie jest dobrym sposobem na uniknięcie myślenia o zadaniu. Jeśli delegacja wymaga przekazania całej historii, dziesięciu niejawnych założeń i ciągłych pytań, narzut może być większy niż korzyść.
Kiedy powstaje system multi-agent
Multi-agent ma sens, gdy wielu wykonawców musi współpracować dłużej, dzielić stan albo reagować na swoje wyniki. Wtedy potrzebne są dodatkowe mechanizmy:
- przydział pracy i właścicielstwo,
- format przekazywania wyników,
- kontrola konfliktów,
- budżet czasu i tokenów,
- obserwowalność,
- zasady przerwania i odzyskiwania.
To już system rozproszony. Pojawiają się problemy duplikacji, niespójnego stanu i błędów komunikacji. Więcej agentów nie oznacza automatycznie lepszego wyniku.
Najważniejszy jest koszt koordynacji
Badanie porównujące skills i subagents sugeruje, że wynik zależy od rodzaju zadania oraz kosztu przełączania i przekazywania kontekstu. To preprint, więc nie należy traktować go jako ostatecznej reguły. Dobrze jednak nazywa praktyczny problem: delegacja ma cenę.
Każdy dodatkowy agent potrzebuje briefu, danych wejściowych, kryterium ukończenia i weryfikacji. Jeśli dwóch agentów edytuje ten sam plik lub podejmuje tę samą decyzję, koordynator musi rozwiązać konflikt. Równoległość pomaga tylko przy rzeczywiście rozłącznych strumieniach.
Prosta drabina decyzji
Zacznij od najmniejszej architektury:
- jedno zadanie i powtarzalna procedura — skill,
- duży, samodzielny fragment lub niezależna kontrola — subagent,
- kilka trwałych ról z zależnościami — system multi-agent.
Jeżeli jeden agent z dobrym kontekstem i narzędziami może wykonać pracę, dodatkowy orkiestrator nie jest potrzebny.
Jak dobrze delegować
Brief dla subagenta powinien zawierać wynik, zakres własności, ograniczenia i test ukończenia. Zamiast „sprawdź backend” lepiej napisać: „Oceń tylko integrację Search Console, nie zmieniaj treści; wynik to lista ryzyk i test połączenia na wskazanej właściwości”.
Koordynator nadal odpowiada za integrację. Nie powinien bez sprawdzenia kopiować wniosku subagenta do produkcji. Niezależna praca daje wartość dopiero wtedy, gdy jej wynik można zweryfikować.
Wybieraj prostotę
Skill skaluje procedurę. Subagent skaluje uwagę. Multi-agent skaluje organizację pracy, ale dodaje organizacyjny koszt. Najlepsza architektura to najmniejsza, która usuwa rzeczywiste ograniczenie.
Źródła: