Systemy multi-agentowe w firmie: kiedy warto i jak je spiąć

Firma produkcyjna zbudowała jednego agenta, który miał robić wszystko: odpowiadać na pytania klientów, generować wyceny, umawiać spotkania handlowe i tworzyć tygodniowe raporty sprzedażowe. Po trzech miesiącach agent działał, ale coraz gorzej. Wyceny były mniej precyzyjne, bo kontekst zajmował okno na pytania klientów. Raporty wychodziły po czasie, bo koordynacja z CRM kolidowała z kolejką obsługową. Koszt jednego zapytania wzrósł trzykrotnie względem pilota. Rozwiązaniem nie był lepszy model, lecz rozbicie na cztery wyspecjalizowane jednostki z agentem-routerem na czele.

To typowy scenariusz przeciążenia pojedynczego agenta. Nie każdy jednak wymaga architektury multi-agent.

Orkiestracja to mechanizm, który przydziela zadania do agentów, zbiera ich wyniki i scala je w spójny efekt. Wyróżniamy trzy wzorce:

Router (klasyfikator + dispatch). Agent-koordynator analizuje wejście i kieruje je do odpowiedniego agenta specjalisty. Klient pyta o fakturę? Trafia do agenta finansowego. Pyta o status dostawy? Trafia do agenta logistycznego. Router nie scala wyników, tylko przekierowuje. Prosty, tani, łatwy do debugowania.

Pipeline (sekwencja). Zadanie przechodzi przez kolejnych agentów jak przez linię montażową: agent A zbiera dane, agent B analizuje, agent C formatuje raport. Każdy agent dostaje wynik poprzedniego jako wejście. Działa dobrze przy przetwarzaniu dokumentów, generowaniu ofert, multi-step research.

Sieć (mesh). Agenci mogą wywoływać siebie nawzajem w dowolnej kolejności, zależnie od potrzeb zadania. Najbardziej elastyczny wzorzec, ale też najtrudniejszy do monitorowania. Ryzyko pętli jest realne, jeśli brakuje twardych limitów wywołań i mechanizmu human-handoff.

Większość wdrożeń biznesowych zaczyna od routera lub pipeline. Sieć zostawiamy na etap, gdy dwa prostsze wzorce wyraźnie nie wystarczają.

Nie ma tu jednej granicy. Są sygnały, które wskazują, że czas na rozbicie:

Kontekst jest za mały na wszystkie role. Gdy agent musi jednocześnie trzymać w kontekście politykę cenową, historię klienta, zasady reklamacji i format raportu, okno kontekstowe (context window) staje się wąskim gardłem. Specjalizacja oznacza mniejszy prompt systemowy i bardziej trafne odpowiedzi.

Zadania mogą przebiegać równolegle. Pipeline sekwencyjny dla dziesięciu niezależnych klientów zajmuje dziesięć razy tyle co jedno zadanie. Równoległe wywołania wyspecjalizowanych agentów skracają latencję nawet o 60-70%, jeśli zadania nie mają między sobą zależności.

Różne zadania wymagają różnych modeli. Klasyfikacja intencji to zadanie dla małego, taniego modelu (odpowiedź w 200 ms). Synteza wielostronicowej oferty wymaga większego modelu z dłuższym kontekstem. LLM router między agentami dobiera model do zadania, co obniża koszty inferencji o 30-50% przy zachowaniu jakości.

Granice odpowiedzialności mają znaczenie prawne. Gdy część procesu dotyczy danych osobowych (RODO, DPIA), a część nie, izolacja agentów z osobnymi guardrails i osobnymi logami ułatwia dokumentację zgodności wymaganą przez AI Act.

Koordynator (orchestrator) to serce systemu. Jego jedyna odpowiedzialność to: przyjąć zadanie, zdecydować kto je obsłuży, zebrać wynik, zwrócić odpowiedź lub eskalować. Koordynator nie powinien sam realizować zadań domenowych, bo wtedy staje się tym samym przeciążonym agentem, od którego uciekaliśmy.

Praktyczne zasady spięcia:

Kontrakty między agentami. Każdy agent-specjalista ma udokumentowany schemat wejść i wyjść (structured output). Koordynator nie zakłada, że zna format — czyta schemat i waliduje wynik przed przekazaniem dalej. Brak walidacji to źródło cichych błędów w pipeline.

Limit wywołań i timeout per agent. Każde wywołanie ma twardy timeout (np. 30 sekund) i limit prób (np. 2 retry z exponential backoff). Po przekroczeniu limitu agent zwraca wynik błędu z kontekstem, a koordynator decyduje: eskalacja do człowieka czy fallback do prostszej ścieżki.

Wspólny rejestr logów. Każdy agent pisze do jednego systemu logowania z identyfikatorem sesji i identyfikatorem wywołania. Bez tego debug zdarzenia, które przeszło przez trzy agenty, zamienia się w kilkugodzinne śledztwo. To wymóg observability i jednocześnie podstawa śladu audytowego zgodnego z AI Act.

Human-gate na akcjach nieodwracalnych. Niezależnie od tego, który agent wykonuje akcję (wyślij mail, wystaw fakturę, zmień status w ERP), jeśli akcja jest nieodwracalna, zatrzymuje się i czeka na potwierdzenie operatora. Dotyczy to każdego agenta w sieci, nie tylko koordynatora.

Więcej o architekturze narzędzi i pętli znajdziesz w artykule o agentach wielokrokowych i w opisie agentów, które wykonują pracę.

Architektura wieloagentowa ma realne koszty. Warto je znać przed wdrożeniem:

Pętle i zakleszczenia. Agent A wywołuje agent B, który wywołuje agent A z innym kontekstem. Bez twardego grafu zależności i licznika głębokości wywołań system może zapętlić się w sposób trudny do wykrycia. Symptom: gwałtowny wzrost kosztów inferencji bez proporcjonalnego wzrostu wartości.

Wyższy koszt monitoringu. Każdy dodatkowy agent to osobny punkt metryk, alertów i logów. Monitoring systemu pięciu agentów kosztuje proporcjonalnie więcej niż monitoring jednego. Przed wdrożeniem oceń TCO przez kalkulator inference i kalkulator ROI.

Trudniejszy debug. Błąd na końcu pipeline trzeba prześledzić wstecz przez każdy agent. Bez dobrego systemu trace (ID sesji propagowany przez cały pipeline) diagnoza zajmuje wielokrotnie więcej czasu niż w systemie jednoagentowym.

Opóźnienia sieciowe sumują się. Każde wywołanie między agentami (szczególnie w architekturze chmurowej) dodaje latencję. W pipeline pięciu agentów sekwencyjnych sumaryczny czas odpowiedzi może przekroczyć próg akceptowalny dla użytkownika, nawet jeśli każdy agent z osobna jest szybki.

Multi-agent to inwestycja, nie skrót. Jeśli problem można rozwiązać lepszym promptem, rozszerzoną bazą RAG lub rozbiciem na dwa niezależne procesy zamiast spiętej sieci, zrób to najpierw. Sprawdź też koszty utrzymania agenta AI i artykuł o bezpieczeństwie agentów AI, bo każdy dodatkowy agent rozszerza powierzchnię ataku.

Dla większości firm 2-4 agenty specjalistyczne plus jeden koordynator to dobry punkt startowy. Tyle wystarczy do obsługi kilku domenowo odrębnych procesów, a złożoność operacyjna pozostaje zarządzalna. Systemy powyżej 8-10 agentów mają sens w bardzo dużych organizacjach z rozbudowanym zapleczem DevOps pod AI.

Nie. To jedna z głównych zalet architektury multi-agent. Klasyfikator intencji może działać na małym, szybkim modelu (7B, lokalny), agent syntezy raportów na większym modelu chmurowym. Dobór modelu per zadanie obniża koszty inferencji o 30-50% bez utraty jakości na krytycznych krokach.

Kluczem jest propagacja jednego identyfikatora sesji przez cały pipeline. Każdy agent loguje wejście, wyjście i czas przetworzenia z tym samym ID. Przy incydencie filtrujesz logi po ID i rekonstruujesz sekwencję wywołań. Bez tego nawet prosty pipeline staje się czarną skrzynką.

Zależy od klasyfikacji ryzyka. Jeśli którykolwiek agent w sieci podejmuje decyzje zaliczone do kategorii wysokiego ryzyka (np. scoring kredytowy, selekcja kandydatów do pracy), cały system podlega wymogom AI Act jako system wysokiego ryzyka. Izolacja agentów nie zwalnia z obowiązku dokumentacji i audytowalności całego procesu.

Zawsze. Jeden agent to szybszy pilotaż, prostszy debug i niższy koszt wdrożenia. Wzorce podziału i kontrakty między agentami najlepiej projektować na bazie realnych danych z działającego systemu, nie z teorii. Po 4-8 tygodniach pilota widzisz, gdzie jeden agent faktycznie się nie sprawdza i jak podzielić odpowiedzialności.