Obsługa błędów multi agent: retry, fallbacki, circuit breakery

Obsługa błędów w systemach wieloagentowych obejmuje wszystkie mechanizmy, które zapobiegają temu, by błąd pojedynczego agenta wywrócił cały system: timeouty, ponawianie prób z backoffem, agenci zapasowi (fallback), circuit breakery i pełna obserwowalność. Celem jest odporność na błędy: subagent może zawieść, a błędy nie rozchodzą się kaskadowo ani nie propagują dalej. W systemie jednoagentowym obsługa błędów to w dużej mierze problem rozwiązany; gdy jednak współpracuje kilku agentów z własnymi oknami kontekstu, narzędziami i rolami, pojawiają się klasy błędów, które w pojedynczej pętli tool use po prostu nie występują.

• Oddziel ścieżkę odczytu od ścieżki zapisu: wielu agentów może równolegle czytać i proponować, ale commit wykonuje tylko jeden (lub jeden etap pipeline'u). To najskuteczniejszy środek przeciw propagacji błędów.
• Ogranicz każde zadanie: timeout, limit tokenów i jawny stan failed dla każdego subagenta zapobiegają zakleszczeniom i eksplozji kosztów.
• Weryfikuj przed syntezą: agent Verifier-Judge wyłapuje zhalucynowane fakty, zanim agent główny wpisze je do odpowiedzi jako prawdę.

Dlaczego obsługa błędów w systemach wieloagentowych wygląda inaczej

System wieloagentowy składa się z kilku agentów opartych na LLM (każdy z własnym promptem, własną rolą, własnym zestawem narzędzi, a w najściślejszym wariancie także własnym oknem kontekstu), którzy wspólnie rozwiązują zadanie. Właśnie to rozproszenie tworzy nowe powierzchnie błędów. Nie ma już jednego śladu, tylko N trajektorii subagentów plus synteza. Przebiegi są niedeterministyczne: to samo wejście uruchamia różnych subagentów w różnej kolejności. Do tego system może wykazywać zachowania emergentne, których żaden pojedynczy agent tak nie zaplanował.

Główne zagrożenie to propagacja błędów. Jeśli subagent zhalucynuje fakt, agent główny włączy go do ostatecznej odpowiedzi, a kolejni agenci w łańcuchu będą działać na podstawie tej fałszywej informacji. Lokalny błąd zamienia się w błędną decyzję na poziomie całego systemu. Obsługa błędów w systemach wieloagentowych oznacza więc dwie rzeczy: uodpornienie pojedynczych agentów na przejściowe awarie oraz zapobieganie rozprzestrzenianiu się błędów wzdłuż łańcucha agentów.

Osiem klas błędów, których nie mają systemy jednoagentowe

Poniższe zestawienie to nasze własne podsumowanie klas błędów, które Anthropic, Cognition, Sierra, Salesforce i Microsoft opisały na podstawie swoich systemów produkcyjnych. Kto wdraża systemy wieloagentowe na produkcję, musi je znać.

Trzy z tych klas (kaskady, deadlock i fragmentacja kontekstu) są właściwymi motorami propagacji błędów. Pozostałe pięć ją wzmacnia lub czyni niewidoczną.

Zapobieganie propagacji błędów: rozdzielenie ścieżek odczytu i zapisu

Najważniejszą decyzją architektoniczną przeciw propagacji błędów nie jest narzędzie, lecz zasada. W tekście „Don't Build Multi-Agents” (czerwiec 2025) i w aktualizacji „Multi-Agents: What's Actually Working” (kwiecień 2026) Cognition ujmuje to tak: fan-out wielu agentów do odczytu jest odporny, fan-out wielu agentów do zapisu jest kruchy. Konsekwencją jest zasada single-threaded writes:

• Single-threaded writes: wielu agentów czyta, zbiera informacje i proponuje, ale commit wykonuje tylko jeden agent lub jeden etap pipeline'u. Wadliwy agent czytający dostarcza tylko cząstkowy wkład, który agent główny może odrzucić lub zlecić ponownie.
• Niezależne zapisy z rekoncyliacją: każdy subagent dostarcza fragment, a agent główny uzgadnia je i scala w wynik końcowy (wzorzec agenta badawczego Anthropic).
• Konkurencyjne zapisy do współdzielonego stanu: spirala śmierci. Bezwzględnie tego unikaj.

Obserwacja Cognition, która za tym stoi: „apparent disagreements” między agentami to zwykle objawy fragmentacji kontekstu, a nie rzeczywistej niezgody. Tam, gdzie sprzężenie jest silne, trzeba współdzielić pełne ślady agentów zamiast pojedynczych wiadomości. Dla współdzielonej pamięci zewnętrznej (vector store, Postgres, SAP HANA) w większości systemów produkcyjnych obowiązuje ta sama zasada: jeden zapisujący, wielu czytających.

Ponawianie z backoffem, timeouty i circuit breakery

Na poziomie pojedynczego wywołania agenta lub narzędzia działają klasyczne wzorce odporności, przeniesione ze świata mikroserwisów:

• Ponawianie z wykładniczym backoffem: przy błędach przejściowych (rate limit, krótka awaria narzędzia, timeout) wywołanie jest powtarzane z coraz dłuższymi przerwami, najlepiej z jitterem, by uniknąć efektu thundering herd. Ważne: ponawianie pomaga tylko przy błędach przejściowych, nie semantycznych. Ponowne wywołanie halucynującego agenta da tę samą halucynację.
• Timeouty dla każdego zadania: protokół A2A definiuje cykl życia zadania submitted → working → input-required → completed | failed | canceled. Timeout dla każdego zadania plus jawny stan input-required to udokumentowany środek zaradczy przeciw resource deadlockom. Bez timeoutu czekający agent może zablokować cały system.
• Circuit breaker: gdy błędy subagenta lub narzędzia przekroczą próg, breaker się otwiera i blokuje kolejne wywołania na określone okno czasowe. To zatrzymuje eksplozję kosztów i daje miejsce na fallback.
• Agenci zapasowi i zdegradowane odpowiedzi: gdy wyspecjalizowany agent zawiedzie, zadanie przejmuje prostszy agent zapasowy, inny poziom modelu albo celowo ograniczona odpowiedź. Lepszy uczciwie ograniczony wynik niż kaskadowo powielona błędna decyzja.

Uzupełnia to praktyczna dyscyplina tokenowa z referencyjnego opisu agenta badawczego Anthropic: jawnie limitować zużycie tokenów przez subagentów (obsługują to Bedrock AgentCore, LangGraph i Claude Agent SDK), wymuszać na wynikach subagentów typowany schemat (Pydantic, JSON Schema, A2A Artifact) i kompresować je przed zwróceniem, nigdy nie przekazywać agentowi głównemu pełnego transkryptu subagenta. Typowany schemat jest zarazem granicą błędów: to, co nie pasuje do schematu, zostaje odrzucone, zamiast trafić dalej.

Monitoring i obserwowalność: warunek konieczny, a nie dodatek

Debuggability collapse to najbardziej podstępna klasa błędów: gdy coś pójdzie nie tak, nie ma jednego śladu, który wyjaśniałby przebieg. Dlatego obserwowalność nie jest opcjonalna w żadnym systemie wieloagentowym działającym produkcyjnie. Elementy składowe:

• Rozproszony tracing w całym meshu A2A, z ciągłym identyfikatorem korelacji/śledzenia w każdym zadaniu A2A i każdym wywołaniu MCP. W 2026 roku przekrojowym standardem jest OpenTelemetry.
• Narzędzia (stan na 2026): LangSmith do wewnętrznych śladów LangGraph; Galileo lub Arize Phoenix do śladów wieloagentowych ponad granicami dostawców; Pydantic Logfire w zespołach pracujących głównie w Pythonie; Datadog/Splunk/Grafana do korelacji w SIEM.
• Wzorzec Verifier-Judge: osobny agent-sędzia, często oparty na mocniejszym modelu niż agenci wykonawczy, ocenia każdą trajektorię według krótkiej listy kryteriów: zadanie wykonane? Odpowiedź ugruntowana w źródłach? Agenci trzymali się zadania? Budżet dotrzymany? To najlżejsza gotowa na produkcję odpowiedź na błędy kaskadowe.

W regionie DACH (Niemcy, Austria, Szwajcaria) obserwowalność jest ponadto kwestią zgodności z regulacjami. BaFin w swoich wytycznych dotyczących ryzyk ICT przy wykorzystaniu AI z grudnia 2025 roku zaleca firmom finansowym rejestrowanie wszystkich istotnych zdarzeń i działań w systemach AI, aby można je było prześledzić. Podstawą jest DORA, której przestrzeganie w Austrii nadzoruje FMA. FINMA w swoim komunikacie nadzorczym 08/2024 stwierdza, że wyników AI często nie da się prześledzić, wyjaśnić ani odtworzyć. Dla systemu agentowego oznacza to: ślady end-to-end każdego wywołania agenta, odtwarzalność (przypinanie wersji modeli na produkcji, zapisywanie wszystkich promptów subagentów, wywołań narzędzi i AgentCards) oraz magazyn audytowy typu append-only. Okresy przechowywania zależą od sektora i kraju, a przed zbudowaniem magazynu audytowego trzeba je uzgodnić z działem compliance.

Przykład: Allianz Project Nemo

Project Nemo firmy Allianz Australia, spółki zależnej monachijskiego ubezpieczyciela Allianz, to jedno z najlepiej udokumentowanych wdrożeń wieloagentowych koncernu z regionu DACH i modelowy przykład obsługi błędów. Siedmiu wyspecjalizowanych agentów (Planner, Cyber, Coverage, Weather, Fraud, Payout, Audit) obsługuje szkody związane z zepsuciem żywności po klęskach żywiołowych. Pełny workflow siedmiu agentów trwa krócej niż pięć minut.

Dwie zasady obsługi błędów są tu wbudowane w samą architekturę:

• Agent audytowy jako element topologii: wydzielony agent tworzy pełne podsumowanie wszystkich decyzji agentów wraz z uzasadnieniami, czyli kompletny ślad audytowy (audit trail) na potrzeby compliance, kontroli jakości i weryfikacji przez człowieka. Audytowalność jest wbudowana w topologię agentów, a nie dopiero w pipeline logowania.
• Human-in-the-loop na krytycznym etapie: pracownik działu likwidacji szkód sprawdza podsumowanie audytowe i podejmuje ostateczną decyzję o wypłacie. Kaskadowo powielona błędna decyzja zostaje wyłapana w najdroższym, nieodwracalnym punkcie, zgodnie z jawnie określoną polityką.

Wynik: skrócenie czasu obsługi i likwidacji uzasadnionych szkód poniżej 500 AUD o 80%, wdrożenie produkcyjne w mniej niż 100 dni (Australia, lipiec 2025). Lekcja dla obsługi błędów: modułowi agenci z jasno określonymi rolami, wydzielona ścieżka audytu i punkt kontroli przez człowieka dają system szybki i dający się kontrolować.

Praktyczna checklista obsługi błędów

• Ścieżka zapisu single-threaded? Commit wykonuje dokładnie jeden agent/jeden etap; czytający robią fan-out, zapisujący nie.
  
• Timeout dla każdego zadania? Do tego jawny stan input-required przeciw zakleszczeniom.
  
• Ponawianie z backoffem + jitterem tylko dla błędów przejściowych, nie semantycznych.
  
• Circuit breaker dla każdego subagenta/narzędzia z progiem i oknem resetu.
  
• Agent zapasowy lub zdegradowana odpowiedź zdefiniowane dla każdego krytycznego agenta.
  
• Limity tokenów dla subagentów ustawione; wyniki wymuszone w typowanym schemacie i skompresowane.
  
• Agent Verifier-Judge sprawdza trajektorie przed ostateczną syntezą.
  
• Grounded retrieval + obowiązkowe źródła przeciw kaskadom halucynacji.
  
• Współdzielone pełne ślady przy silnym sprzężeniu; jawne kontrakty decyzyjne.
  
• Identyfikator korelacji w każdym zadaniu A2A i wywołaniu MCP; eksport do OTel.
  
• Human-in-the-loop na nieodwracalnych/kosztownych etapach.
  
• Przypięte wersje modeli, ślad audytowy append-only, przechowywanie zgodne z wymogami sektora.
  

Dla agencji i decydentów B2B

Dla agencji marketingowych i dostawców AI-native obsługa błędów to cecha jakości produktu, a nie szczegół w tle: pipeline newslettera lub audytu SEO z agentami do researchu, konspektu, szkicu i recenzji zależy w całości od Verifier-Judge i etapu zapisu single-threaded. Dla decydentów B2B w Europie: wymagaj od każdej propozycji wieloagentowej, wewnętrznej czy od dostawcy, konkretnych odpowiedzi dotyczących strategii timeoutów, fallbacku, weryfikacji i śledzenia. Systemu bez obserwowalności klasy Galileo/LangSmith nie da się zbadać na żądanie regulatora. Kto od początku wbudowuje obsługę błędów w topologię agentów, według wzorca Allianz Nemo z agentem audytowym i human-in-the-loop, dostarcza systemy, które są szybkie i jednocześnie pozostają audytowalne.