Sposób, w jaki podagenci i systemy wieloagentowe dzielą prace oraz tokeny kosztowe.
Podagenty a systemy wieloagentowe: projekt orkiestrator-pracownik, cztery topologie, ile kosztuje każdy w tokenach oraz przypadki, gdy pojedynczy agent radzi sobie lepiej.
Źródła: Subagents vs. Multi-Agent Systems: The Complete Guide to How AI Agents Actually Work Together
Dlaczego pojedynczy agent osiąga swój limit
Każdy, kto oglądał programy Claude Code, LangGraph lub funkcję badawczą Claude, widział moment, w którym asystent przestaje samodzielnie odpowiadać i szuka pomocy. Pojawia się pomocnik do wyszukiwania plików, przeszukuje je i wraca z wynikami. Pytanie badawcze w ciągu czasu potrzebnego osobie na otwarcie dwóch kartek cicho konsultuje się z tuzinem źródeł. Model nie stał się nagle mądrzejszy – pracę tę wykonywała mała grupa.
Poniżej znajduje się prosty przegląd tego, jak powstaje taka współpraca zespołowa, obejmujący podagenty, systemy wieloagentowe, ich podstawową architekturę oraz koszty ich funkcjonowania.
Jedyny agent, czyli jeden model działający w pętli z użyciem narzędzi, jest zdolny do wykonywania zadań – czyta pliki, przegląda treści, pisze kod i rozumuje w wielu krokach. Jednak w projekcie zaimplementowano trzy ograniczenia:
- Jedno okno kontekstowe. Wszystko, co agent czyta, myśli i robi, gromadzi się w tym samym obszarze. Podczas długiego zadania eksploracyjnego wyniki działania narzędzi ostatecznie sprawiają, że początkowe pytanie traci na znaczeniu.
- Jedna linia wykonywania zadań. Prace odbywają się sekwencyjnie. Pięćdziesiąt wyszukiwań po dwie sekundy każde zajmuje ponad dziewięćdziesiąt sekund, zanim rozpocznie się jakakolwiek praca pisarska.
- Jedna perspektywa. Jeden prompt kształtuje każdą decyzję, więc agent ma trudności z jednoczesnym stosowaniem dwóch sprzecznych podejść lub z identyfikacją własnych słabych punktów.
Podagenty i systemy wieloagentowe to dwa rozwiązania tego problemu, często łączone ze sobą. Reszta tekstu opisuje, czym one są, jak są budowane oraz kiedy się opłacają.
Czym jest podagent
Podagent to narzędzie o wąskim zakresie działania uruchamiane w ramach jednej sesji. Obsługuje pojedyncze, określone zadanie w własnym oknie kontekstowym, a następnie składa raport.
Dobrym przykładem jest Claude Code. Jeśli główna sesja programistyczna musi zrozumieć jakąś nieznajomą część bazy kodu, może przekazać to zadanie podagentowi, chroniąc w ten sposób główną rozmowę. Podagent:
- rozpoczyna pracę z czystym, nowym oknem kontekstowym
- zazwyczaj posiada mniejszy, ograniczony zestaw narzędzi
- wykonywa własny cykl składający się z czytania, wyszukiwania i rozumowania
- przesyła streszczenie do sesji nadrzędnej, zachowując transkrypcję dla siebie
Wartością tutaj jest izolacja, a nie dodatkowa inteligencja. Główna rozmowa nie widzi pięćdziesięciu plików otwartych przez asystenta, tylko trzy istotne zdania, dzięki czemu główny wątek pozostaje klarowny przez całą długą sesję i nie wypełnia się szumem.
Kilka cech definiuje ten model w zależności od tego, jak implementują go narzędzia takie jak Claude Code:
- Subagenty istnieją w ramach jednej sesji. Są sposobem delegowania zadań, a nie oddzielnymi procesami działającymi równolegle.
- Zazwyczaj nie mogą one uruchamiać własnych subagentów, co sprawia, że hierarchia jest prosta i łatwa do zrozumienia.
- Definicja subagenta jest pisana raz i wykorzystywana ponownie. Jeśli subagentowi przeznaczonemu do recenzji podasz ustalony prompt systemowy oraz krótki wykaz narzędzi, będzie on działał identycznie przy każdym wezwaniu.
Czym jest system wieloagentowy
System wieloagentowy ma inną strukturę. Kilka niezależnych agentów, z których każdy posiada własny kontekst, własne narzędzia, a czasami także własny model, dąży do wspólnego celu, zazwyczaj w dłuższym lub bardziej skomplikowanym procesie niż delegowanie zadań w ramach jednej sesji.
Najbardziej znanym publicznym przykładem jest funkcja Research firmy Anthropic. Na szeroko pojęte pytanie nie udziela się bezpośredniej odpowiedzi. Zamiast tego agent prowadzący opracowuje podejście i tworzy kilka podagentów, z których każdy bada inny aspekt w tym samym momencie. Ich wyniki są łączone, sprawdzane pod kątem dokładności cytowania i zwracane jako jedna odpowiedź.
W skład tego wzorca, który obecnie stosuje większość systemów wieloagentowych produkcyjnych, wchodzą główny agent, specjaliści działający równolegle oraz etap końcowej syntezy – to właśnie taki projekt jest omawiany w dalszej części tego artykułu.
Gdzie te dwa podejścia się różnią
W internecie te terminy są używane zamiennie, co powoduje zamieszanie. Rzeczywista różnica jest tutaj przedstawiona.
Najprostszy sposób, by to zapamiętać: podagent to technika stosowana wewnątrz agenta, natomiast system wieloagentowy to architektura zaprojektowana wokół kilku agentów. W praktyce wiele systemów wieloagentowych jest budowanych na podstawie wzorca podagenta. Główny agent, który wykorzystuje podagenty, jest jednocześnie obiema tymi rzeczami.
Architektura orkiestratora i pracowników
Prawie każdy system wieloagentowy używany w produkcji, w tym funkcja Research firmy Anthropic, wzorzec nadzorczy LangGraph oraz model subagentów Claude Code, stanowi jakąś wariację jednego projektu: orchestrator i pracownicy.
Każdy komponent ma określoną rolę:
- Główny agent (orchestrator). Odczytuje zapytanie, opracowuje strategię i ocenia, ile wysiłku wymaga zadanie. Ta ocena ma większe znaczenie, niż się wydaje. W wczesnych wersjach tych systemów czasami uruchamiano pięćdziesiąt subagentów przy pytaniu, które wymagało tylko jednego.
- Pamięć lub tablica robocza. Plan jest zapisywany poza ramami rozmowy. Długotrwałe działanie agentów może przekroczyć limit kontekstu modelu, a jeśli tak się stanie w trakcie, plan musi przetrwać skrócenie i nie zniknąć wraz z nim.
W diagramie użyto dwóch rodzajów strzałek. Strzałki pełne przedstawiają zadania realizowane w dół, a strzałki przerywane – streszczone wyniki przekazywane w górę. Ta asymetria jest celowa: podagenty zwracają streszczone rezultaty, a nie całą historię swojej pracy, co zapobiega przepełnieniu kontekstu głównego agenta.
Przepływ pracy od pytania do odpowiedzi
Jeśli spojrzymy szerzej na składniki, oto kolejność zdarzeń od wpisanego przez użytkownika pytania do gotowej odpowiedzi.
Kilka kroków wymaga szczególnej uwagi:
- Krok 2 (myślenie przed planowaniem) ma większe znaczenie, niż się wydaje. To tutaj system określa, ile wysiłku wymaga dane zapytanie: szybka weryfikacja faktów może wymagać jednego agenta i kilku wywołań narzędzi, natomiast pytanie o szeroki zakres może wymagać dziesięciu lub więcej podagentów z jasno określonymi obowiązkami.
- Krok 7 (powrót w pętli) odróżnia system oparty na agentach od sztywnej ścieżki przetwarzania. Nic nie jest z góry zaprogramowane, ponieważ główny agent analizuje wyniki i decyduje, czy odpowiedzieć, czy kontynuować poszukiwania. To właśnie w tym momencie najczęściej występują problemy. Agent zbyt niechętny do powrotu w pętli daje krótkie odpowiedzi, natomiast ten zbyt chętny marnuje czas i zasoby na szukanie źródeł, których w rzeczywistości nie ma.
- Kroki 8 i 9, przy których cytowanie stanowi odrębną fazę, istnieją dlatego, że agent, który ma za zadanie napisać odpowiedź oraz ocenić źródła, często formułuje pewne twierdzenia, które nie mają podstaw. Niezależna druga weryfikacja pozwala to wykryć.
Cztery sposoby organizacji wielu agentów
Typowa struktura to orkiestrator i pracownicy, ale nie jest to jedyna możliwość. W zależności od tego, jak konkretnie dzieli się zadanie, jedna z czterech ogólnych topologii będzie lepsza od pozostałych.
Gdy nie jest jasne, co wybrać, zespoły produkcyjne zazwyczaj stosują prostą zasadę: dla wszystkiego, co trafia do produkcji, należy używać hierarchii z przełożonym, natomiast w pracach eksploracyjnych lub badawczych, gdzie przepływ nie może zostać z góry określony, lepiej stosować układy sieciowe lub siatkowe. Projektowanie w formie siatki wygląda elegancko na diagramie, ale jednocześnie jest najtrudniejsze do debugowania.
Dlaczego to działa: ekonomia tokenów
Warto precyzyjnie wyjaśnić, dlaczego systemy wieloagentowe radzą sobie lepiej niż systemy jednoagentowe w wykonywanych zadaniach – odpowiedź nie brzmi bowiem „więcej agentów oznacza większą inteligencję”.
W wewnętrznych ocenach Anthropic układ z Claude Opus 4 jako głównym agentem i Claude Sonnet 4 jako agentami pomocniczymi przewyższył pojedynczego agenta Claude Opus 4 o 90,2% w ramach wewnętrznego testu badawczego. Analizując przyczyny tego efektu, największy wpływ miał zakres możliwości systemu. W trudnym teście wyszukiwania sam użytek tokenów stanowił około 80% różnic w wydajności, natomiast liczba wywołań narzędzi i wybór modelu obejmowały resztę czynników.
Krótko mówiąc, przewaga w zadaniami wymagających szerokiego przetwarzania dużych ilości informacji wynika głównie z większego zakresu możliwości systemu. Rozdzielenie zadań na osobne okna kontekstowe daje systemowi znacznie większą przestrzeń do rozumowania niż pojedyncze okno, a każdy agent pomocniczy kompresuje przeczytane dane do krótkiego raportu.
Pojemność nie jest darmowa. Dane z produkcji wskazują, że prace z wykorzystaniem agentów zużywają mniej więcej cztery razy więcej tokenów niż zwykła rozmowa, a prace z wieloma agentami około piętnaście razy więcej. Ten współczynnik powinien decydować o tym, czy architektura ta w ogóle jest warta użycia, co prowadzi do następnego punktu.
Kiedy system wieloagentowy to niewłaściwy narzędzie
Większość tekstów na temat architektury agentów pomija tę kwestię, a to właśnie ona chroni zarówno czas, jak i budżet tokenów.
Zadanie musi być podzielone na naprawdę niezależne części. Gdy podzadania silnie od siebie zależą, ich rozdzielenie między agentami powoduje dodatkowe obciążenia związane z koordynacją i nie przynosi rzeczywistego paralelizmu. Odrębne pytania badawcze dobrze się dzielą, natomiast napisanie jednej spójnej funkcji zazwyczaj tak nie robi.
Kodowanie jest najwyraźniejszym przeciwprzykładem. Sam opis firmy Anthropic jest bezpośredni: większość zadań związanych z kodowaniem ma mniej podzadań możliwych do równoległego wykonywania niż praca badawcza, a dzisiejsze agenty nie są jeszcze w stanie niezawodnie koordynować działań i przekazywać sobie zadania w czasie rzeczywistym. Inne testy potwierdzają to. Jedna ocena akademicka wykazała, że systemy wieloagentowe zużywają od 4 razy do ponad 200 razy więcej tokenów niż porównywalny agent pojedynczy, a inne badanie branżowe pokazało, że systemy wieloagentowe radzą sobie o 39 do 70 procent gorzej niż agent pojedynczy przy zadaniach ściśle sekwencyjnych.
Błędy się rozprzestrzeniają. Błędne założenie w jednym agencie pozostaje pojedynczym błędem. W systemie skoordynowanym może on przenosić się wraz z przekazywaniem zadań i narastać. Jedna analiza oszacowała mniej więcej 4-krotny wzrost skali błędów przy centralnej koordynacji, a sytuacja jest znacznie gorsza, gdy agenci działają niezależnie bez żadnej koordynacji.
Zysk musi pokryć koszty. Dzięki współczynnikowi mnożnikowemu bliskiemu 15x, rozwiązania z wieloma agentami nadają się do zadań o wysokiej wartości i złożoności, takich jak zaawansowane badania, analiza wielodomenowa oraz duże przeróbki kodu. W przypadku czegokolwiek, co dobrze skonfigurowany pojedynczy agent z odpowiednimi narzędziami może zakończyć za jednym razem, takie rozwiązania są przesadne.
Można zastosować szybki test: jeśli nie potrafisz określić, co konkretnie powinien posiadać każdy agent, czego nie mają pozostali, prawdopodobnym rozwiązaniem jest silniejszy pojedynczy agent, a nie dodatkowe.
Lekcje z ich tworzenia
Retrospektywa Anthropic dotycząca ich systemu Research należy do najszczerszych publicznych opisów tego, co idzie nie tak, gdy działająca demonstracja przekształca się w produkcyjną konfigurację z wieloma agentami. Najważniejsze, najbardziej przenośne lekcje w skrócie:
- Pytania są głównym narzędziem sterowania. Ponieważ pytania kierują każdym agentem, niewielkie zmiany w sformułowaniach wpływające na sposób, w jaki orkiestrator przydziela zadania, mają ogromny wpływ na to, czy podagenty będą się powtarzać, czy też pozostawią luki.
- Luźna delegacja powoduje powtórzenie pracy. Instrukcja taka jak „przeprowadź badania na temat niedoboru półprzewodników” wydaje się jasna, ale tak naprawdę nie jest. W wczesnych systemach kilka podagentów badało ten sam temat, ponieważ nikt nie określił, gdzie kończy się jedno zadanie. Dobra instrukcja określa cel, oczekiwany format wyniku oraz granice zakresu działania każdego agenta.
Minimalny zarys wzorca
Poniżej znajduje się uproszczony, niezależny od konkretnego frameworka zarys elementów orkiestratora i pracownika. Pominięto mechanizmy ponawiania prób, przepływu danych oraz pamięci trwałej, aby łatwiej było dostrzec strukturę logiki; służy on jako pseudokod do przeniesienia na LangGraph, Claude Agent SDK lub prosty cykl API.
def run_research(query: str) -> str:
# 1. Lead agent plans
plan = lead_agent.think_and_plan(query)
memory.save("plan", plan) # survives context truncation
findings = []
subtasks = plan.subtasks # explicit objective + boundaries per subtask
# 2. Spawn subagents in parallel, not sequentially
results = run_in_parallel([
subagent.execute(task=subtask, tools=subtask.allowed_tools)
for subtask in subtasks
])
findings.extend(results)
# 3. Lead agent decides: enough evidence, or loop again?
while not lead_agent.has_sufficient_evidence(findings):
new_subtasks = lead_agent.refine_plan(findings)
more_results = run_in_parallel([
subagent.execute(task=t, tools=t.allowed_tools)
for t in new_subtasks
])
findings.extend(more_results)
# 4. Synthesize, then verify citations in a separate pass
draft = lead_agent.synthesize(findings)
cited_answer = citation_agent.attach_citations(draft, findings)
return cited_answer
Dwa aspekty wymagają szczególnej uwagi, a żaden z nich nie pojawia się zwykle w przykładach ilustracyjnych. Pierwszym jest run_in_parallel: wykonywanie podagentów pojedynczo sprawia, że większość korzyści wynikających z pracy równoległej znika. Drugim jest wyraźny pętla while służąca do ponownego planowania, ponieważ jedna stała seria działań podagentów nie może się dostosować, gdy pierwsza próba rozwiązania pozostawia więcej pytań niż odpowiedzi.
Kontrole przed wdrożeniem
Zanim uruchomisz podagenta lub proces pracujący z wieloma agentami, sprawdź następujące kwestie:
- Każdy podagent ma wyraźny cel, format wyjścia oraz granice zadań, a nie tylko jednozdaniową instrukcję.
- Podagenty działają równolegle tam, gdzie są rzeczywiście niezależne.
- Plan jest zapisywany w pamięci przechowawczej, a nie tylko przechowywany w rozmowie, na wypadek skrócenia kontekstu.
Literatura pokrewna
- Kiedy dwa agenci pokonują jednego: Copilot do przeglądania kodu w LangGraph dostępny w obu wersjach — Stwórz jednego recenzenta kodu jako pojedynczego agenta, a następnie jako Analyzer w połączeniu z Risk Reviewer w LangGraph, a potem dowiedz się o trzech przypadkach, gdy użycie systemu wielu agentów jest opłacalne.
- Praktyczne notatki: Jak stać się jednym z 1% najlepszych użytkowników agenta Hermes: Pełny przewodnik — Szczegółowy przewodnik po praktycznych notatkach: Jak stać się jednym z 1% najlepszych użytkowników agenta Hermes: Pełny przewodnik, zawierający informacje o kontraktach, sprawdzeniach oraz gotowych fragmentach kodu dla zespołów wdrażających ten model.