Dlaczego systemy multi-agent zawodzą: to nie model, to schemat organizacyjny

Postawiliśmy już optymistyczną tezę. W Orkiestrze agentów kodu argumentowaliśmy, że prawdziwa zmiana 2026 to nie mądrzejsze agenty, lecz ich większa liczba, pracująca równolegle, dająca 2–4x przyspieszenia, gdy dobrze zorkiestrowana. Tamten post był o tym, co sprawia, że orkiestra gra muzykę. Ten jest jego uczciwym odpowiednikiem i dotyczy drugiego wyniku: hałasu. Bo gdy spinasz kilka agentów razem, nie mnożysz tylko ich zdolności — mnożysz ich powierzchnię porażki, a nowe porażki nie wyglądają jak cokolwiek, co produkuje pojedynczy agent.

Gdy system multi-agent rozczarowuje, instynkt każe obwiniać model. Wstaw mocniejszy, przepisz prompty i spróbuj ponownie. Dwa staranne badania z 2026 roku mówią, że ten instynkt jest w większości błędny — a dane za nimi to najbardziej przydatna rzecz, jaka spotkała inżynierię multi-agent w tym roku.

Ktoś wreszcie policzył porażki

Pierwsze badanie nosi dosadny tytuł Why Do Multi-Agent LLM Systems Fail? (arXiv 2503.13657) i wykonało nieefektowną pracę, której nikt inny nie podjął. Badacze ręcznie zaanotowali ponad 1600 traces egzekucji w 7 popularnych frameworkach multi-agent, budując taksonomię z początkowych 150 traces przy silnej zgodności między anotatorami (κ Cohena = 0,88 — co znaczy, że dwoje ludzi czytających ten sam trace zgadzało się co do tego, co poszło nie tak). Wynikiem jest MAST: 14 odrębnych trybów porażki pogrupowanych w 3 kategorie. Te kategorie warto zapamiętać, bo to anatomia tego, jak zespół agentów się rozpada:

Specyfikacja i projekt systemu — porażka jest wpisana, zanim agenty w ogóle ruszą: niejednoznaczne definicje zadań, źle wykreślone granice ról, wadliwa struktura konwersacji. Orkiestrze wręczono złą partyturę.
Niedopasowanie między agentami — agenty są indywidualnie kompetentne, ale mówią do siebie obok siebie: jeden ignoruje wkład drugiego, resetują kontekst i gubią wątek, negocjują się w róg. Każdy muzyk umie grać, ale nie słuchają się nawzajem.
Weryfikacja i zakończenie zadania — nikt nie sprawdza pracy, albo sprawdzenie jest zbyt płytkie, by wyłapać błąd, albo system zatrzymuje się za wcześnie i ogłasza skończonym zadanie ledwie w połowie zrobione. Występ się kończy i wszyscy biją brawo niewłaściwym nutom.

Oto odkrycie, które powinno przeformułować twoje myślenie o tym: żadna pojedyncza kategoria nie dominuje. Porażki rozkładają się mniej więcej równo na wszystkie trzy. I o to właśnie chodzi. Gdyby porażki skupiały się w jednym miejscu, miałbyś jedną rzecz do naprawienia. Zamiast tego system multi-agent może rozpaść się na specyfikacji, w konwersacji albo na mecie z porównywalnym prawdopodobieństwem — a tylko jedna z tych trzech jest choćby blisko „model nie jest wystarczająco mądry”. Pozostałe dwie to czysta porażka organizacyjna. To nie model. To schemat organizacyjny.

Drugie badanie zgadza się z zupełnie innej strony

Sceptyk mógłby odrzucić jeden artykuł jako artefakt metody. Dlatego ma znaczenie, że drugie badanie z 2026 roku, Characterizing Faults in Agentic AI (arXiv 2603.06847), doszło do zgodnego wniosku, robiąc niemal coś przeciwnego. Zamiast ręcznie czytać wyselekcjonowane traces, poszło tam, gdzie oprogramowanie agentowe naprawdę żyje i pęka: 13 602 zamknięte zgłoszenia i scalone pull requesty w 40 otwartoźródłowych projektach agentowych. Z nich autorzy pobrali warstwowaną próbę 385 prawdziwych usterek i zastosowali teorię ugruntowaną, by wyprowadzić taksonomię 5 architektonicznych wymiarów usterek, 13 klas symptomów i 12 kategorii przyczyn źródłowych — a potem zwalidowali całość z 145 praktykującymi programistami.

Symptomy, na które programiści faktycznie zgłaszali bugi, są wymowne: pokiereszowany ustrukturyzowany output, wywołania narzędzi, które chybiają, wysadzająca się egzekucja w runtime, wyjątki połykane zamiast obsługiwane. A przyczyny źródłowe pod nimi — niezgodności schematów, dryf zależności, sama złożoność zarządzania stanem w systemie, niestabilne interfejsy modeli — to znów, w przeważającej mierze, problemy inżynieryjne, nie problemy inteligencji. Artykuł użył nawet eksploracji reguł asocjacyjnych, by prześledzić, jak jedna usterka propaguje się w drugą: drobne potknięcie u góry strumienia staje się kaskadą w dole. To podatek multi-agent w jednym zdaniu. W pojedynczym agencie mały błąd to mały błąd. W skoordynowanym systemie mały błąd to ziarno.

Dwa badania, dwie metody — jedno anotujące traces ręcznie, drugie wydobywające realne raporty o bugach — zbiegają się na tej samej niewygodnej prawdzie: dominujące tryby porażki systemów multi-agent są strukturalne, organizacyjne i przekrojowe. Nie dotyczą, w większości, tego, jak sprytny jest model pod spodem.

Dlaczego „po prostu użyj lepszego modelu” cię nie ratuje

Gdyby porażki były problemem zdolności, mocniejszy model by je rozpuścił. Autorzy MAST przetestowali to wprost i wynik jest najważniejszym praktycznym odkryciem w którymkolwiek z tych artykułów. Zastosowali oczywiste taktyczne łatki — lepsze prompty, dopracowaną logikę orkiestracji — i zmierzyli zysk. Był skromny: rzędu 3–5 punktów procentowych, a ich własnymi słowami interwencje „nie stanowią istotnych ulepszeń”. Ich wniosek jest dosadny: zidentyfikowane porażki „wymagają bardziej złożonych rozwiązań” — strukturalnego przeprojektowania, nie łatania promptów.

Zatrzymaj się przy tym, bo to uderza w cały odruch dziedziny. Gdy twój zespół agentów produkuje śmieci, tani ruch to dłubanie przy promptach i sięganie po najnowszy model. Dane mówią, że ten ruch kupuje ci kilka punktów i zostawia prawdziwe tryby porażki nietknięte. Niejasna specyfikacja zostaje niejasna, niezależnie od tego, jak mocny model ją czyta; dwa agenty niedopasowane co do tego, kto za co odpowiada, zostają niedopasowane; brakujący krok weryfikacji zostaje nieobecny. Nie wypromptujesz się z brakującego schematu organizacyjnego.

To ta sama lekcja, do której wciąż dochodzimy z każdej strony. Dlatego argumentujemy, że harness jest produktem — trwała wartość to nie model w środku, lecz struktura wokół niego. Dlatego zła pętla wypuszcza zły kod szybciej: dodanie równoległości do zepsutego procesu nie naprawia procesu, lecz skaluje uszkodzenie. I łączy się to wprost z jednoagentową wersją tej historii w Luce niezawodności: tam najzdolniejszy model topił się najbardziej przy długich zadaniach, bo sięgał po ambitne plany, które wymykały się spod kontroli. Tutaj najzdolniejsze agenty mówią do siebie obok siebie i pomijają weryfikację równie ochoczo co słabsze. Zdolność i niezawodność nigdy nie były tą samą właściwością — a na poziomie systemu luka jest jeszcze szersza.

Co taksonomia porażek każe ci budować

Przydatne w taksonomii porażek jest to, że odwraca się w listę rzeczy do zbudowania. Każda kategoria to dyscyplina, którą musisz dostarczyć, bo model tego nie zrobi:

Przeciw porażkom specyfikacji: zainwestuj w specyfikację, zanim agenty ruszą. Ostre granice ról, jednoznaczne definicje zadań, jawna struktura konwersacji. To najtańsza dźwignia, jaką masz, a dane mówią, że tam rodzi się jedna trzecia porażek. Plan przejrzany przez człowieka kosztuje minuty; zły plan wykonany przez pięć agentów równolegle kosztuje dzień.
Przeciw niedopasowaniu między agentami: uczyń koordynację jawną, zamiast liczyć, że się wyłoni. Współdzielone listy zadań ze śledzeniem zależności, blokowanie plików, by agenty nie deptały sobie nawzajem, ustrukturyzowane przekazania zamiast swobodnego czatu. Traktuj protokół między agentami jako zaprojektowany artefakt, nie efekt uboczny.
Przeciw porażkom weryfikacji: zbuduj sprawdzającego jako obywatela pierwszej klasy, nie dodatek po fakcie. Automatyczne bramki uruchamiające testy, zanim zadanie zostanie zaliczone, warunek zakończenia oznaczający „zweryfikowane jako kompletne”, a nie „agent przestał mówić”. To problem kto sądzi sędziego, a w systemie multi-agent jest nośny: nic innego się nie utrzyma, jeśli końcowe sprawdzenie nie działa.

Żadna z tych trzech rzeczy nie jest upgradem modelu. Wszystkie trzy to inżynieria i osąd — dokładnie ta strukturalna praca, której zdaniem badań brakuje.

Dlaczego sprzyja to Azji Południowo-Wschodniej

Oto część, która liczy się dla tego regionu, i wynika wprost z danych. Gdyby dominujące porażki systemów multi-agent były problemem zdolności, przewaga płynęłaby do tego, kto potrafi wytrenować albo wynająć największy model — a to gra kapitałowa, której Azja Południowo-Wschodnia nie wygrywa. Ale badania mówią coś przeciwnego: porażki to specyfikacja, koordynacja i weryfikacja — dyscypliny projektowania i osądu, nie mocy. Ta praca działa na laptopie. Nie kosztuje GPU. Nie potrzebuje frontierowego laboratorium.

I to prawdziwa przewaga właśnie dlatego, że większość rynku robi niewłaściwą rzecz. Domyślnym ruchem wszędzie jest chwycenie najmocniejszego modelu, spięcie roju, podkręcenie promptów i wypuszczenie — co, jak pokazują dane, zostawia faktyczne tryby porażki nietknięte. Mały, zdyscyplinowany zespół w Phnom Penh albo Da Nang, który zamiast tego traktuje schemat organizacyjny jako produkt — ostre specyfikacje, jawne protokoły koordynacji, prawdziwe bramki weryfikacji — wypuści systemy multi-agent, które się trzymają, podczas gdy lepiej finansowani konkurenci wciąż wymieniają modele i zastanawiają się, czemu orkiestra dalej brzmi jak hałas.

Post o orkiestrze był o korzyściach, i korzyści są prawdziwe. Ale ta sama asymetria przebiega przez stronę negatywną: rzeczy, które sprawiają, że system multi-agent zawodzi, to rzeczy, których frontierowe laboratorium nie może ci sprzedać. Chętnie wynajmie ci pięćdziesiąt agentów. Nie może wynająć ci schematu organizacyjnego, który zamienia je w zespół. To jest praca warta posiadania — i dostępna każdemu, kto zechce uczciwie policzyć porażki i budować pod nie.