Systemy wieloagentowe (multi-agent systems)

Czym jest system wieloagentowy?

System wieloagentowy to architektura, w której kilku agentów opartych na LLM współpracuje, aby rozwiązać zadanie, z którym pojedynczy agent sobie nie radzi. Definicja Anthropic ujmuje to w punkt: „A multi-agent system consists of multiple agents (LLMs autonomously using tools in a loop) working together.” Kluczowe jest rozgraniczenie: każdy agent ma własny prompt, własną rolę, własny zestaw narzędzi i, w ścisłym ujęciu, własne okno kontekstowe.

W 2026 roku to rozróżnienie nie jest akademickie. Prezentacje sprzedażowe dostawców rozmyły ten termin. Pojedynczy agent z wieloma integracjami narzędzi, sprzedawany jako „wieloagentowy”, bo same narzędzia nazywają się „agentami”, to coś, co określa się mianem marketingowego multi-agenta. Szeroko cytowany przykład Klarny („AI wykonuje pracę 700 pracowników”) to jednoagentowy system odciążający obsługę klienta, a nie system wieloagentowy, choć często bywa błędnie tak przedstawiany.

Prawdziwy system wieloagentowy ma co najmniej jedną cechę strukturalną: agenta wiodącego lub orkiestratora, który dynamicznie tworzy subagentów z własnym oknem kontekstowym; komunikaty między agentami przekraczające granice zaufania (np. z Agentforce do SAP Joule przez A2A); albo samodzielny podział na procesy, role lub modele z nietrywialnym współdzieleniem stanu. Allianz Project Nemo z siedmioma wyspecjalizowanymi agentami to przykład podręcznikowy.

Uczciwa interpretacja w 2026 roku: większość produkcyjnych „agentów” to nadal pojedynczy, starannie zbudowany LLM z narzędziami i pętlą. To nie wada; Anthropic sam podkreśla, że wygrywać powinien najprostszy wzorzec, który rozwiązuje problem. Dlatego pytanie architektoniczne rzadko brzmi „multi-agent: tak czy nie?”, lecz „który wzorzec pasuje i gdzie leży nasze sprzężenie stanu?”.

Wzorzec orkiestrator-wykonawcy

Wzorzec orkiestrator-wykonawcy (agent wiodący i subagenci) to kanoniczny przypadek systemu wieloagentowego. Agent wiodący działa w trybie extended thinking lub planowania, rozkłada zapytanie użytkownika na odrębne podzadania i dynamicznie tworzy subagentów za pomocą narzędzia Task. Każdy subagent ma własny prompt, własny zestaw narzędzi i, co kluczowe, własne okno kontekstowe. Subagenci zwracają skompresowane wyniki, które agent wiodący syntetyzuje.

Przypadkiem referencyjnym jest agent badawczy stojący za funkcją Research w Claude (wprowadzoną w kwietniu 2025, z architekturą ujawnioną w czerwcu 2025): agent wiodący oparty na Claude Opus 4 i subagenci oparci na Claude Sonnet 4. W wewnętrznej ewaluacji badawczej Anthropic system ten przewyższył pojedynczego agenta Opus 4 o 90,2%. Cena: według Anthropic systemy wieloagentowe zużywają około 15 razy więcej tokenów niż zwykła interakcja na czacie, a pojedynczy agent około 4 razy więcej (źródło: Anthropic, „How we built our multi-agent research system”, 13.06.2025). Anthropic postawił sprawę jasno: taki nakład tokenów opłaca się tylko przy wartościowych, szeroko zakrojonych zadaniach badawczych, które dają się zrównoleglić.

Wzorzec stosuje się przy szerokich problemach z niezależnymi podzadaniami, które dają się zrównoleglić (badania, analityka rynkowa, przegląd wielu dokumentów, szeroki triaż). Należy go unikać przy ściśle sprzężonych zadaniach zapisu (generowanie kodu w wielu plikach) oraz przy wysoce deterministycznych workflowach wymagających powtarzalności; tam właściwym rozwiązaniem jest pipeline.

Kluczowa wskazówka praktyczna z eksperymentów Anthropic: agent wiodący musi wprost nauczyć się, jak delegować. Każdy subagent potrzebuje celu, formatu wyniku, wytycznych dotyczących źródeł i narzędzi oraz jasnych granic zadania. „Mgliste” delegacje prowadziły do dublowania pracy i luk w pokryciu.

Role, przekazania i koordynacja

Systemy wieloagentowe opierają się na jasno zdefiniowanych rolach i czystych przekazaniach. Poza samą strukturą orkiestrator-wykonawcy istnieje kilka wzorców koordynacji, które systemy produkcyjne często łączą:

Mnożniki tokenów w tabeli to zgrubne szacunki. Potwierdzona jest tylko wartość dla wzorca orkiestrator-wykonawcy, wyprowadzona z pomiaru Anthropic (patrz wyżej).

Semantyka przekazań różni się w zależności od stosu technologicznego. W OpenAI Agents SDK jawne przekazania kończą turę jednego agenta i uruchamiają następnego, przekazując mu historię rozmowy. AutoGen korzysta z czatu grupowego, w którym agenci zabierają głos po kolei. Microsoft przeniósł jednak AutoGen w tryb utrzymania i dla nowych projektów zaleca następcę, Microsoft Agent Framework. LangGraph przekazuje typowany obiekt stanu przez węzły i trwale zapisuje go w checkpointach. W Claude Agent SDK od Anthropic agent wiodący tworzy przez narzędzie Task subagentów, którzy zwracają skompresowane, ustrukturyzowane wyniki.

W modelu hub-and-spoke przez A2A centralny agent deleguje zadania do wyspecjalizowanych agentów równorzędnych, potencjalnie od różnych dostawców. Protokół A2A definiuje w tym celu cykl życia zadania (submitted → working → input-required → completed | failed | canceled), wykrywanie możliwości za pomocą AgentCard (dokumentu JSON z endpointem, możliwościami, skillami, modalnościami i schematami uwierzytelniania) oraz wieloczęściowe wiadomości z artefaktami jako wynikiem. Wewnętrzna logika zdalnego agenta pozostaje przy tym nieprzejrzysta. Dzięki temu agent Salesforce może wywołać agenta SAP, a żaden z nich nie ujawnia drugiemu swoich promptów, pamięci ani modeli.

Reguła koordynacji, która wykrystalizowała się w 2026 roku, dotyczy ścieżki zapisu: wielu agentów czyta, zbiera, wnioskuje i proponuje, ale tylko jeden agent (lub jeden etap pipeline'u) wykonuje commit. Wieloagentowy fan-out przy odczycie jest odporny; fan-out przy zapisie jest kruchy; równoczesne zapisy do współdzielonego stanu to spirala śmierci.

Awarie i kumulujące się błędy

Systemy wieloagentowe mają tryby awarii, których system jednoagentowy nie zna. Każdy z poniższych został udokumentowany w środowisku produkcyjnym przez Anthropic, Cognition, Sierra, Salesforce lub Microsoft; znajomość tego katalogu jest dla każdego architekta bezwzględnie obowiązkowa:

1. Awarie kaskadowe. Subagent halucynuje fakt; agent wiodący włącza go do syntezy odpowiedzi; agenci na dalszych etapach działają na podstawie fałszywej informacji. Środek zaradczy: agent weryfikator-sędzia, ugruntowane wyszukiwanie w źródłach, obowiązkowe cytowania.
2. Komora echa. Subagenci wzmacniają błędne założenie agenta wiodącego. Środek zaradczy: zróżnicowanie modeli i promptów subagentów (w stylu MoA), wprowadzenie roli krytyka.
3. Rozmycie autorytetu. Subagent nadpisuje instrukcje agenta wiodącego albo agent wiodący traci autorytet nad rozmową. Środek zaradczy: jasne hierarchie ról, kontrakty zadań A2A z solidnymi AgentCards.
4. Zakleszczenie zasobów. Agenci czekają na siebie nawzajem (A czeka na wynik B; B na wyjaśnienie od A). Środek zaradczy: timeouty dla każdego zadania, jawny stan input-required w A2A.
5. Wzmocnienie ataków prompt injection. Każde okno kontekstowe subagenta to nowa powierzchnia ataku. EchoLeak (CVE-2025-32711, Aim Labs, czerwiec 2025) był pierwszym znanym atakiem prompt injection typu zero-click z faktyczną eksfiltracją danych w produkcyjnym systemie LLM (Microsoft 365 Copilot). Ta sama klasa ryzyka skaluje się liniowo wraz z liczbą agentów przyjmujących niezaufane treści.
6. Fragmentacja kontekstu (główny zarzut Cognition). Subagenci podejmują niezgodne ze sobą niejawne decyzje. Środek zaradczy: współdzielenie pełnych śladów tam, gdzie sprzężenie jest wysokie; jednowątkowe zapisy; jawne kontrakty decyzyjne.
7. Eksplozja kosztów. Według Anthropic systemy wieloagentowe zużywają około 15 razy więcej tokenów niż czat, a pojedynczy agent około 4 razy więcej. W porównaniu z pojedynczym agentem daje to niemal czterokrotność. Taki nakład opłaca się tylko przy wartościowych zadaniach. Środek zaradczy: limity tokenów na subagenta, poziomy QoS, routing według progu złożoności.
8. Załamanie debugowalności. Żaden pojedynczy ślad nie obejmuje całego przebiegu. Środek zaradczy: rozproszony tracing w sieci A2A, identyfikatory korelacji przekazywane w każdym zadaniu A2A i każdym wywołaniu MCP.

Koncepcyjny rdzeń kumulujących się błędów pochodzi z analizy Cognition.ai „Don't Build Multi-Agents” (Walden Yan, 12.06.2025): działania niosą ze sobą niejawne decyzje, a sprzeczne decyzje dają złe wyniki. „Pozorne różnice zdań” między agentami są zwykle objawem fragmentacji kontekstu, a nie rzeczywistego sporu. W aktualizacji z kwietnia 2026 („Multi-Agents: What's Actually Working”, 22.04.2026) firma Cognition doprecyzowała: system wieloagentowy działa, gdy wielu agentów wnosi inteligencję, ale zapisy pozostają jednowątkowe.

Synteza na potrzeby decyzji architektonicznej

Jeśli zestawisz Anthropic i Cognition obok siebie i pominiesz retorykę, synteza jest jednoznaczna:

• System wieloagentowy działa przy problemach, które dają się zrównoleglić, wykazują niskie sprzężenie stanu między podproblemami i mają jednowątkową lub trywialnie uzgadnialną ścieżkę zapisu. Korzystają na tym badania, szerokie wyszukiwanie, fan-out dokumentów, triaż szkód oraz wykrywanie nadużyć z niezależnymi kontrolami.
• System wieloagentowy zawodzi przy problemach silnie sprzężonych i sekwencyjnych, w których każda „niejawna decyzja” kształtuje każdy kolejny krok. Klasycznym przykładem pozostaje programowanie: rój równolegle piszących agentów-koderów produkuje diff, którego nikt nie jest w stanie zmergować.
• W przypadku większości korporacyjnych workflowów odpowiedź leży pośrodku, a wybór wzorca liczy się bardziej niż pytanie zero-jedynkowe.

Cztery zdania, które możesz przeciwstawić każdemu pitchowi systemu wieloagentowego: współdziel kontekst tam, gdzie sprzężenie jest wysokie; izoluj kontekst tam, gdzie dominuje równoległość; nigdy nie pozwól dwóm agentom jednocześnie zapisywać tego samego stanu; ponoś dodatkowy koszt tokenów tylko wtedy, gdy zadanie ma charakter badawczy.

Kontekst europejski i wskazówki dotyczące zgodności

W Europie dochodzą zmienne strukturalne, o których amerykańskie chmurowe architektury referencyjne rzadko mówią otwarcie. Poniższe uwagi mają charakter wyłącznie informacyjny i nie stanowią porady prawnej.

Suwerenność danych. Gdy różni agenci działają u różnych dostawców mocy obliczeniowej (np. agent Salesforce wywołuje agenta SAP Joule, który przez A2A korzysta z kroku wnioskowania Anthropic Claude), przepływ danych w każdym zadaniu przekracza kilka granic rezydencji danych i podmiotów przetwarzających. Na gruncie RODO każdy dostawca agenta jest potencjalnie podmiotem przetwarzającym (art. 28); system wieloagentowy wydłuża tym samym łańcuch umów powierzenia przetwarzania. Przy transgranicznych krokach między USA a UE art. 44–49 mają zastosowanie na każdym przeskoku między agentami, który przekracza granicę: albo decyzja stwierdzająca odpowiedni stopień ochrony w ramach EU-US Data Privacy Framework (art. 45) w przypadku dostawców z USA certyfikowanych w DPF, albo standardowe klauzule umowne wraz z oceną skutków transferu (art. 46). Decyzja w sprawie DPF obowiązuje, ale przed TSUE toczy się postępowanie odwoławcze (sprawa C-703/25 P). Przy regulowanych obciążeniach wieloagentowych rozważ poważnie suwerenne opcje chmurowe, takie jak STACKIT (Grupa Schwarz), Open Telekom Cloud, IONOS czy plusserver. Prawo ich nie wymaga, ale przepisy sektorowe, takie jak DORA, mogą stawiać surowsze wymagania. Handshake A2A z niesuwerennym agentem to najczęściej przeoczane ryzyko w obszarze zgodności przy projektowaniu systemów wieloagentowych w regionie DACH.

Ścieżka audytu. Każda wiadomość między agentami jest potencjalnie istotna z punktu widzenia audytu. Ze względu na niedeterminizm odtwarzalność decyzji wieloagentowych jest trudniejsza niż w systemach jednoagentowych: przypinaj wersje modeli, rejestruj wszystkie prompty subagentów, wywołania narzędzi, pobrane konteksty i użyte AgentCards, a następnie koreluj je za pomocą jednego identyfikatora śladu. Projekt Allianz Nemo z dedykowanym agentem audytowym, który tworzy pełne podsumowanie wszystkich decyzji agentów, jest tu wzorcem istotnym dla regionu DACH; audytowalność należy do topologii agentów, a nie tylko do pipeline'u logowania.

Unijny AI Act (przegląd, informacyjnie, nie stanowi porady prawnej). W 2026 roku otwarte kwestie nie są ostatecznie rozstrzygnięte: każdy agent jest prawdopodobnie odrębnym „systemem AI” (art. 3 pkt 1), a kompozycja również jest systemem AI, potencjalnie z wyższą klasyfikacją ryzyka niż jej części. W kompozycji A2A Salesforce-SAP-Anthropic każdy producent jest zazwyczaj dostawcą własnego agenta, natomiast organizacja integrująca jest podmiotem stosującym system złożony. Obowiązki w zakresie przejrzystości z art. 50 mnożą się przy kolejnych wywołaniach między agentami.

Współdecydowanie. Workflowy wieloagentowe w HR, obsłudze klienta lub monitoringu operacyjnym mogą podlegać współdecydowaniu rady zakładowej na podstawie § 87 ust. 1 pkt 6 BetrVG (Niemcy) lub § 96 i § 96a ArbVG (Austria), i to na poziomie workflowu, a nie pojedynczego agenta. Trendem w 2026 roku są odrębne porozumienia zakładowe dotyczące AI, obejmujące kompozycje wieloagentowe (informacyjnie, nie stanowi porady prawnej).

Spójność językowa. Systemy wieloagentowe dla klientów z regionu DACH (Niemcy, Austria, Szwajcaria) potrzebują jednolitego tone of voice i spójnego rejestru Sie/Du we wszystkich agentach. Agent Salesforce, który zwraca się per „Du” i wywołuje agenta SAP używającego „Sie”, tworzy doświadczenie klienta sprawiające wrażenie „zepsutego”. Wytyczne stylistyczne trzeba egzekwować na poziomie AgentCard i szablonów promptów.

Perspektywy i wskazówka praktyczna

Dla projektów w Europie w 2026 roku racjonalne ustawienia domyślne są jasne: pojedynczy agent + narzędzia jako standard, przejście na system wieloagentowy tylko wtedy, gdy zadanie da się zrównoleglić, jest zdominowane przez odczyt lub pozwala uzgodnić zapisy, a rachunek kosztów się spina. MCP dla narzędzi, A2A dla agentów: wszystko inne to w 2026 roku świadome odejście od konwergentnego stosu. Traktuj każde okno kontekstowe subagenta jako nową powierzchnię ataku. Wbuduj audytowalność w topologię (agent audytowy Allianz jako wzorzec). Wybierz jedną warstwę orkiestracji plus jedną natywną dla platformy; trzy lub więcej frameworków na produkcji to powierzchnia inżynieryjna, nad którą nie da się zapanować. I publikuj AgentCards, bo to one są międzysystemowym kontraktem, który decyduje, czy agent uczestniczy w ekosystemie przedsiębiorstwa.

Pytanie na następnym przeglądzie architektury nie brzmi już „Czy powinniśmy zbudować system wieloagentowy?”, lecz: „Który z wzorców Anthropic pasuje do naszego obciążenia, jaka jest nasza tolerancja na sprzężenie stanu, jakie środowiska dostawców już utrzymujemy i w którym miejscu MCP oraz A2A wchodzą w obszar naszego governance?”