Orchestrator agent: najbardziej niezawodny wzorzec wieloagentowy

Wzorzec Orchestrator-Worker to architektura wieloagentowa, w której agent główny (orkiestrator) dzieli zadanie na podzadania, deleguje je do wyspecjalizowanych agentów wykonawczych, z których każdy ma własne okno kontekstowe, i scala ich skompresowane wyniki w ostateczną odpowiedź. Anthropic opisuje go w „Building effective agents” jako jeden z pięciu workflowów i wykorzystuje jako architekturę swojego wieloagentowego systemu badawczego. Spośród wzorców wieloagentowych uchodzi za najbardziej niezawodny, ponieważ omija najczęstsze źródło błędów rozproszonych agentów.

• Co się dzieje: orkiestrator planuje i dzieli zadanie, workerzy pracują równolegle i niezależnie, a orkiestrator agreguje wyniki i jako jedyny pisze.
• Do czego się nadaje: do zadań, które można zrównoleglić i których podzadania są ze sobą słabo powiązane, np. research, monitoring rynku, przegląd wielu dokumentów, szeroka selekcja (triage).
• Do czego się nie nadaje: do ściśle powiązanych, sekwencyjnych zadań pisania, takich jak generowanie kodu w wielu plikach czy złożone workflowy transakcyjne.

Jak działa ten wzorzec

Orkiestrator działa w trybie planowania lub w trybie rozszerzonego myślenia (Extended Thinking). Przyjmuje zapytanie, dzieli je na odrębne, niezależne od siebie podzadania i dla każdego z nich uruchamia agenta wykonawczego za pomocą narzędzia Task lub Subagent. Kluczowa jest ścisła izolacja: każdy worker ma własny prompt, własny zestaw narzędzi, a przede wszystkim własne okno kontekstowe. Workerzy wyszukują informacje, wywołują narzędzia i rozumują niezależnie od siebie. Zamiast pełnych transkryptów zwracają orkiestratorowi tylko skompresowany wynik, a on na tej podstawie syntetyzuje ostateczną odpowiedź.

Ta architektura jest dokładnym przeciwieństwem niezdyscyplinowanego roju agentów. Konteksty workerów są rozdzielone, aby w ogóle umożliwić równoległość. Ścieżka zapisu pozostaje jednak jednowątkowa: tylko orkiestrator łączy fragmenty. Właśnie to połączenie, izolowani workerzy odczytujący dane plus jednowątkowa synteza, sprawia, że wzorzec jest odporny.

Dlaczego uchodzi za najbardziej niezawodny wzorzec wieloagentowy

Niezawodność wynika z inżynierskiej debaty roku 2025. W tekście „Don't Build Multi-Agents” (12 czerwca 2025) firma Cognition dowodziła, że architektura z równoległymi subagentami jest z założenia krucha, ponieważ fragmentuje kontekst. Kilku agentów piszących jednocześnie podejmuje sprzeczne, niejawne decyzje, np. dotyczące stylu lub przypadków brzegowych (edge cases), i tworzy wyniki, których nikt nie jest już w stanie scalić. Główna teza Cognition: działania niosą ze sobą niejawne decyzje, a sprzeczne decyzje prowadzą do złych wyników („Actions carry implicit decisions, and conflicting decisions carry bad results”). Przyczyną takich konfliktów jest fragmentacja kontekstu.

Właśnie tu wkracza wzorzec Orchestrator-Worker. Całkowicie eliminuje konkurencyjne operacje zapisu. Workerzy wnoszą inteligencję, czytając, zbierając i proponując, ale tylko orkiestrator uzgadnia wyniki i pisze. W aktualizacji „Multi-Agents: What's Actually Working” (22 kwietnia 2026) Cognition potwierdziła to stanowisko: firma sama stosuje systemy wieloagentowe, ale właśnie w wariancie, „w którym kilku agentów wnosi inteligencję do zadania, a operacje zapisu pozostają jednowątkowe”. Orchestrator-Worker jest czystą implementacją tej zasady. Nie jest to najpotężniejszy wzorzec w każdej sytuacji, ale najbardziej niezawodny dla tej klasy zadań, w których podejście wieloagentowe w ogóle ma sens.

Przykład wzorcowy: agent badawczy Anthropic

Kanonicznym studium przypadku jest wieloagentowy system badawczy Anthropic, opisany w „How we built our multi-agent research system” (13 czerwca 2025) i działający produkcyjnie w funkcji Research w Claude. Budowa:

• Orkiestrator główny: Claude Opus 4 w trybie Extended Thinking, który dzieli zapytanie użytkownika na części i deleguje zadania. Swój plan zapisuje w pamięci, ponieważ jego kontekst jest przycinany powyżej 200 000 tokenów.
• Workerzy: N równoległych subagentów Claude Sonnet 4, których agent główny tworzy za pomocą narzędzia. Każdy worker ma własne okno kontekstowe i niezależnie korzysta z narzędzi wyszukiwania i pobierania (fetch).
• Zwrot wyników: każdy worker dostarcza skompresowane podsumowanie, a nie pełny transkrypt. Orkiestrator syntetyzuje z nich odpowiedź.

Najczęściej cytowane liczby ze studium przypadku Anthropic:

Według Anthropic taki nakład tokenów opłaca się tylko wtedy, gdy wartość zadania uzasadnia dodatkowe koszty, np. przy szeroko zakrojonych badaniach, które dobrze dają się zrównoleglić. Do ściśle powiązanych workflowów programistycznych wzorzec według oceny Anthropic na razie słabo pasuje, ponieważ większość zadań programistycznych ma mniej podzadań, które naprawdę da się wykonywać równolegle, niż research (wszystkie dane: stan na czerwiec 2025).

Role we wzorcu Orchestrator-Worker

Kiedy wzorzec pasuje, a kiedy nie

Pasuje do szerokich problemów, które można zrównoleglić i których podzadania są niezależne: research, analiza rynku (market intelligence), przegląd wielu dokumentów, szeroka selekcja, wyszukiwanie porównywalnych dokumentów. Te zadania mają słabe powiązanie stanu między podproblemami, a ścieżkę zapisu łatwo utrzymać jako jednowątkową.

Nie pasuje do ściśle powiązanych zadań pisania (generowanie kodu w wielu plikach, złożone workflowy transakcyjne) ani do workflowów o wysokim determinizmie z obowiązkiem odtwarzalności. Tam lepszym wyborem jest deterministyczny pipeline.

Na potrzeby wyboru wzorca Orchestrator-Worker można opisać tak: wysoka możliwość zrównoleglenia, niska do średniej tolerowana zależność stanu, średnia tolerancja na opóźnienia, średnia łatwość ewaluacji (wymaga narzędzi do śledzenia przebiegów, tzw. trace tooling), gotowość produkcyjna już dziś w Anthropic, AWS Bedrock i Agentforce (stan na 2026).

Zalety, wady i koszty

Zalety: ogromny wzrost jakości przy szerokich zadaniach, prawdziwa równoległość dzięki izolowanym kontekstom workerów, brak fragmentacji kontekstu dzięki jednowątkowej syntezie, gotowość produkcyjna w kilku stackach.

Wady i koszty: głównym zarzutem jest zużycie tokenów. Pomiary Anthropic pokazują, że systemy wieloagentowe zużywają około 15 razy więcej tokenów niż interakcja na czacie, a pojedynczy agent około 4 razy więcej. Koszt w porównaniu z pojedynczym agentem jest więc mniej więcej 3–4 razy wyższy. Do tego dochodzą typowe źródła błędów:

• Niejasne delegowanie. We wczesnych eksperymentach Anthropic nieprecyzyjne briefy zadań prowadziły do dublowania pracy i luk w pokryciu. Orkiestrator musi wprost nauczyć się, jak delegować.
• Dryf orkiestratora. Podczas długich przebiegów agent główny gubi swój plan i ponownie uruchamia workerów do zadań, które zostały już wykonane.
• Wzmocnienie prompt injection. Każde nowe okno kontekstowe workera to nowa powierzchnia ataku. Gdy workerzy przetwarzają niezaufane treści, ryzyko wstrzyknięcia rośnie wraz z liczbą agentów.

Praktyczna recepta dla zespołów z ograniczonym budżetem:

1. Wyraźnie ograniczyć budżet tokenów workerów (obsługują to Bedrock AgentCore, LangGraph i Claude Agent SDK).
2. Wymusić typowany schemat dla wyjść workerów (Pydantic, JSON Schema lub artefakt A2A).
3. Kompresować przed zwróceniem wyników, nigdy nie przekazywać orkiestratorowi pełnego transkryptu workera.
4. Dawać orkiestratorowi precyzyjne instrukcje: każdy worker otrzymuje cel (objective), format wyjścia, wskazówki dotyczące narzędzi i źródeł oraz jasne granice zadania.

Przykład z obliczeniami

Załóżmy analizę konkurencji obejmującą 30 uczestników rynku. Pojedynczy agent zużywa na nią szacunkowo 200 000 tokenów w jednym sekwencyjnym przebiegu. W architekturze Orchestrator-Worker agent główny dzieli zadanie między dziesięciu równoległych workerów, z których każdy analizuje trzech konkurentów. Pomiary Anthropic pokazują, że agenci zużywają około 4 razy, a systemy wieloagentowe około 15 razy więcej tokenów niż interakcja na czacie. W porównaniu z pojedynczym agentem daje to mniej więcej współczynnik 3–4, więc łączne zużycie wynosi około 600 000–800 000 tokenów. W wewnętrznej ewaluacji badawczej Anthropic system wieloagentowy wypadł o 90,2% lepiej niż pojedynczy agent Claude Opus 4. Reguła decyzyjna jest więc jasna: czy trzy- do czterokrotnie wyższa cena w tokenach jest warta wyniku ewaluacji lepszego o około 90%? Przy jednorazowym, krytycznym dla biznesu badaniu rynku tak, przy codziennym rutynowym raporcie niemal zawsze nie. (Wartości tokenów w przykładzie to szacunki poglądowe. Udokumentowane są współczynniki 4 i 15 względem czatu oraz 90,2% z systemu badawczego Anthropic; współczynnik 3–4 względem pojedynczego agenta został z nich wyprowadzony.)

Produkcyjnym dowodem z Australii dla blisko spokrewnionej, hierarchicznej konfiguracji jest Allianz Project Nemo: siedmiu wyspecjalizowanych agentów (Planner, Cyber, Coverage, Weather, Fraud, Payout, Audit) do obsługi szkód związanych z zepsutą żywnością po klęskach żywiołowych. Cały workflow trwa poniżej pięciu minut, a likwidator szkód (człowiek) sprawdza podsumowanie audytu i podejmuje decyzję (Human-in-the-Loop jako wyraźna polityka). Udokumentowany wynik: o 80% krótszy czas obsługi i likwidacji szkód w uzasadnionych przypadkach poniżej 500 AUD; system uruchomiono w lipcu 2025 i wdrożono w niecałe 100 dni.

Dla agencji i decydentów B2B

Dla agencji marketingowych Orchestrator-Worker to właściwy wzorzec wszędzie tam, gdzie liczy się szerokość: równoległy research wielu konkurentów, audyty treści obejmujące duże zbiory stron, analiza wielu źródeł na potrzeby raportu. Świadomie nie stosuj go do finalnego pisania tekstów przez kilku agentów równolegle: tu obowiązuje jednowątkowe pisanie. Dla decydentów B2B praktyczna reguła, którą można przedstawić na komitecie sterującym, brzmi: wieloagentowość w stylu Orchestrator-Worker wtedy, gdy zadanie da się zrównoleglić, podzadania są ze sobą słabo powiązane, a ścieżka zapisu pozostaje jednowątkowa. Rozsądne ustawienia domyślne dla projektów w Europie to n8n lub LangGraph jako warstwa orkiestracji, MCP do narzędzi i A2A do przekazań między platformami. Jeśli chcesz dobrze zrozumieć i wdrożyć najbardziej niezawodny wzorzec wieloagentowy, zacznij od jasnego podziału zadań i twardych limitów tokenów, a nie od liczby agentów.