Spracovanie chýb v multi-agentových systémoch: opakované pokusy, fallbacky, circuit-breakery

Spracovanie chýb v multi-agentových systémoch zahŕňa všetky mechanizmy, ktoré zabraňujú tomu, aby chyba jediného agenta zhodila celý systém: timeouty, opakované pokusy (retries) s backoffom, fallback-agentov, circuit-breakery a end-to-end observability. Cieľom je odolnosť voči chybám: sub-agent smie zlyhať bez toho, aby chyby kaskádovali alebo sa šírili ďalej. V single-agentovom systéme je spracovanie chýb z veľkej časti vyriešený problém; akonáhle spolupracuje viacero agentov s vlastnými kontextovými oknami, nástrojmi a rolami, vznikajú triedy chýb, ktoré v jedinom tool-use loope jednoducho neexistujú.

• Oddeľ čítaciu a zápisovú cestu: Mnohí agenti smú paralelne čítať a navrhovať, ale commit robí len jeden (alebo jeden stupeň pipeline). To je najúčinnejší prostriedok proti šíreniu chýb.
• Obmedz každú úlohu: Timeout, limit tokenov a explicitný stav failed pre každého sub-agenta zabraňujú deadlockom a explózii nákladov.
• Overuj pred syntézou: Verifier-judge-agent zachytí halucinované fakty skôr, než ich lead-agent zapíše do odpovede ako pravdu.

Prečo je spracovanie chýb v multi-agentových systémoch iné

Multi-agentový systém pozostáva z viacerých agentov založených na LLM (každý s vlastným promptom, vlastnou rolou, vlastnou sadou nástrojov a v prísnom prípade aj vlastným kontextovým oknom), ktorí spoločne riešia jednu úlohu. Práve toto rozdelenie vytvára nové zdroje chýb. Už neexistuje jeden trace, ale N trajektórií sub-agentov plus syntéza. Behy sú nedeterministické: ten istý vstup spustí rôznych sub-agentov v rôznom poradí. A systém môže vykazovať emergentné správanie, ktoré takto neplánoval žiadny jednotlivý agent.

Ústredným nebezpečenstvom je šírenie chýb. Ak sub-agent halucinuje fakt, lead-agent ho syntetizuje do finálnej odpovede a nadväzujúci agenti konajú na základe tohto nesprávneho faktu. Z lokálnej chyby sa stane chybné rozhodnutie celého systému. Spracovanie chýb v multi-agentových systémoch preto znamená dve veci: urobiť jednotlivých agentov odolnými voči tranzientným výpadkom a zabrániť tomu, aby sa chyby šírili po reťazci agentov.

Osem tried chýb, ktoré single-agentové systémy nemajú

Nasledujúci prehľad je naše zhrnutie tried chýb, ktoré Anthropic, Cognition, Sierra, Salesforce a Microsoft opísali na základe skúseností so svojimi produkčnými systémami. Kto nasadzuje multi-agentové systémy do produkcie, musí ich poznať.

Tri z týchto tried (kaskády, deadlock a fragmentácia kontextu) sú skutočnými hnacími silami šírenia chýb. Ostatných päť ich zosilňuje alebo robí neviditeľnými.

Ako zabrániť šíreniu chýb: oddeliť čítaciu a zápisovú cestu

Najdôležitejšie architektonické rozhodnutie proti šíreniu chýb nie je nástroj, ale princíp. Spoločnosť Cognition ho presne pomenovala v texte „Don't Build Multi-Agents“ (jún 2025) a v aktualizácii „Multi-Agents: What's Actually Working“ (apríl 2026): Multi-agentový fan-out na čítanie je robustný, multi-agentový fan-out na zápis je krehký. Dôsledkom je pravidlo single-threaded writes:

• Single-threaded writes: Mnohí agenti čítajú, skúmajú a navrhujú, ale commit robí len jeden agent alebo jeden stupeň pipeline. Chybný čítací agent dodá len čiastkový príspevok, ktorý môže lead-agent zahodiť alebo znovu vyžiadať.
• Nezávislé zápisy so zosúladením: Každý sub-agent dodá fragment, lead-agent ich zladí do finálneho výstupu (vzor research agenta od Anthropic).
• Súbežné zápisy do zdieľaného stavu: Špirála smrti. Za každú cenu sa jej vyhni.

Pozorovanie spoločnosti Cognition, ktoré za tým stojí: „Apparent disagreements“ medzi agentmi sú väčšinou symptómami fragmentácie kontextu, nie skutočnej nezhody. Kde je previazanie vysoké, treba zdieľať úplné traces agentov, nie len jednotlivé správy. Pre zdieľané externé úložisko (vektorová databáza, Postgres, SAP HANA) platí vo väčšine produkčných systémov to isté pravidlo: zapisuje jeden, čítajú mnohí.

Opakované pokusy s backoffom, timeouty a circuit-breakery

Na úrovni jednotlivého volania agenta alebo nástroja sa uplatňujú klasické vzory odolnosti, prevzaté zo sveta mikroslužieb:

• Opakované pokusy s exponenciálnym backoffom: Pri tranzientných chybách (rate limit, krátky výpadok nástroja, timeout) sa volanie opakuje s rastúcimi čakacími intervalmi, ideálne s jitterom, aby nevznikol efekt thundering herd. Dôležité: opakované pokusy pomáhajú len proti tranzientným chybám, nie proti sémantickým. Opätovné volanie halucinujúceho agenta prinesie tú istú halucináciu.
• Timeouty pre každú úlohu: Protokol A2A definuje životný cyklus úlohy submitted → working → input-required → completed | failed | canceled. Timeout pre každú úlohu plus explicitný stav input-required sú zdokumentovaným protiopatrením proti resource-deadlockom. Bez timeoutu môže jeden čakajúci agent zablokovať celý systém.
• Circuit-breaker: Ak počet chýb sub-agenta alebo nástroja prekročí prahovú hodnotu, breaker sa otvorí a na určité časové okno zablokuje ďalšie volania. To zastaví explóziu nákladov a vytvorí priestor na fallback.
• Fallback-agenti a degradované odpovede: Ak vypadne špecializovaný agent, prevezme to jednoduchší fallback-agent, iná úroveň modelu alebo zámerne zúžená odpoveď. Lepšie poctivo obmedzený výstup ako kaskádové chybné rozhodnutie.

Dopĺňa to praktická disciplína pri tokenoch z referenčného research agenta od Anthropic: spotrebu tokenov sub-agentov explicitne zastropovať (podporujú to Bedrock AgentCore, LangGraph a Claude Agent SDK), vynútiť, aby výstupy sub-agentov zodpovedali typovanej schéme (Pydantic, JSON Schema, A2A Artifact), a pred vrátením ich skomprimovať, nikdy neposielať lead-agentovi celý prepis sub-agenta. Typovaná schéma je zároveň hranicou pre chyby: čo sa do schémy nezmestí, sa odmietne, namiesto toho, aby sa to posunulo ďalej.

Monitoring a observability: predpoklad, nie doplnok

Debuggability-collapse je najzákernejšia trieda chýb: keď sa niečo pokazí, neexistuje jeden trace, ktorý by beh vysvetlil. Observability preto nie je pre žiadny multi-agentový systém v produkcii voliteľná. Stavebné kamene:

• Distribuovaný tracing naprieč celým A2A meshom, s jednotným korelačným/trace ID v každej A2A úlohe a každom volaní MCP. OpenTelemetry je v roku 2026 prierezovým štandardom.
• Nástroje (stav 2026): LangSmith pre interné traces v LangGraph; Galileo alebo Arize Phoenix pre multi-agentové traces naprieč dodávateľmi; Pydantic Logfire v tímoch, ktoré pracujú hlavne v Pythone; Datadog/Splunk/Grafana pre koreláciu v SIEM.
• Vzor verifier-judge: Samostatný judge-agent, často silnejší model ako workeri, hodnotí každú trajektóriu podľa krátkeho súboru kritérií: Úloha splnená? Odpoveď podložená zdrojmi? Zostali agenti pri úlohe? Rozpočet dodržaný? To je najjednoduchšia produkčne použiteľná odpoveď na kaskádové chyby.

Pre DACH je observability navyše otázkou compliance. BaFin vo svojej orientačnej pomôcke k rizikám IKT pri nasadení AI z decembra 2025 odporúča finančným spoločnostiam zaznamenávať všetky relevantné udalosti a aktivity v systémoch AI, aby boli dohľadateľné. Základom je DORA, na ktorej dodržiavanie v Rakúsku dohliada FMA. FINMA vo svojom oznámení o dohľade 08/2024 konštatuje, že výsledky AI často nemožno dohľadať, vysvetliť ani reprodukovať. Pre agentový systém to znamená: end-to-end traces každého volania agenta, reprodukovateľnosť (v produkcii zafixovať verzie modelov, zaznamenávať všetky prompty sub-agentov, volania nástrojov a AgentCards) a auditné úložisko typu append-only. Lehoty uchovávania závisia od sektora a krajiny a pred budovaním auditného úložiska ich treba dohodnúť s compliance.

Príklad: Allianz Project Nemo

Project Nemo od Allianz Australia, dcérskej spoločnosti mníchovskej poisťovne Allianz, je jedným z najdôkladnejšie zdokumentovaných multi-agentových nasadení koncernu z regiónu DACH a učebnicovým príkladom spracovania chýb. Sedem špecializovaných agentov (Planner, Cyber, Coverage, Weather, Fraud, Payout, Audit) spracúva škody zo skazenia potravín po prírodných katastrofách. Kompletný workflow siedmich agentov prebehne za menej ako päť minút.

Dva princípy spracovania chýb sú tu zabudované priamo do architektúry:

• Audit-agent ako prvok topológie: Vyhradený agent vytvára úplné zhrnutie všetkých rozhodnutí agentov a ich zdôvodnení, teda kompletný audit trail pre compliance, kontrolu kvality a posúdenie človekom. Auditovateľnosť je zabudovaná do topológie agentov, nie až do logovacej pipeline.
• Human-in-the-loop na kritickom stupni: Likvidátor poistných udalostí, teda človek, skontroluje audit-zhrnutie a s konečnou platnosťou rozhodne o výplate. Kaskádové chybné rozhodnutie sa zachytí v najdrahšom, nezvratnom bode, ako výslovné pravidlo.

Výsledok: čas spracovania a vybavenia oprávnených škôd pod AUD 500 sa skrátil o 80 %, riešenie bolo v prevádzke za menej ako 100 dní (Austrália, júl 2025). Ponaučenie pre spracovanie chýb: modulárni agenti s jasnými rolami, vyhradená audit-cesta a ľudský kontrolný bod vytvárajú systém, ktorý je rýchly a zvládnuteľný.

Praktický checklist spracovania chýb

• Zápisová cesta single-threaded? Commit robí práve jeden agent/jeden stupeň; čítajúci agenti robia fan-out, zapisujúci nie.
  
• Timeout pre každú úlohu? Plus explicitný stav input-required proti deadlockom.
  
• Opakované pokusy s backoffom + jitterom len pre tranzientné chyby, nie pre sémantické.
  
• Circuit-breaker pre každého sub-agenta/nástroj s prahovou hodnotou a oknom na reset.
  
• Fallback-agent alebo degradovaná odpoveď definovaná pre každého kritického agenta.
  
• Limity tokenov sub-agentov nastavené; výstupy viazané na typovanú schému a skomprimované.
  
• Verifier-judge-agent kontroluje trajektórie pred finálnou syntézou.
  
• Grounded retrieval + povinné zdroje proti halucinačným kaskádam.
  
• Zdieľané úplné traces pri vysokom previazaní; kontrakty rozhodnutí explicitne.
  
• Korelačné ID v každej A2A úlohe a každom volaní MCP; export do OTel.
  
• Human-in-the-loop pri nezvratných/drahých krokoch.
  
• Verzie modelov zafixované, audit trail append-only, uchovávanie podľa pravidiel sektora.
  

Pre agentúry a B2B rozhodovateľov

Pre marketingové agentúry a AI-native poskytovateľov je spracovanie chýb znakom kvality produktu, nie detailom v pozadí: pipeline pre newsletter alebo SEO audit s agentmi na rešerš, osnovu, koncept a kontrolu stojí a padá s verifier-judgeom a single-threaded zápisovým stupňom. Pre B2B rozhodovateľov v DACH platí: vyžaduj od každého multi-agentového pitchu, či už interného, alebo od externého dodávateľa, konkrétne odpovede na stratégiu timeoutov, fallbackov, verifierov a traces. Systém bez observability na úrovni Galileo či LangSmith sa pri požiadavke regulátora nedá preskúmať. Kto zabuduje spracovanie chýb do topológie agentov od začiatku, podľa vzoru Allianz Nemo s audit-agentom a human-in-the-loop, dodáva systémy, ktoré sú rýchle a zároveň zostávajú preskúmateľné.