Spracovanie chýb v multi-agentových systémoch: retries, fallbacky, circuit-breaker

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, retries s backoffom, fallback-agentov, circuit-breaker a priebežnú observability. Cieľom je odolnosť voči chybám – sub-agent smie zlyhať bez toho, aby chyby kaskádovali alebo sa šírili. V single-agentovom systéme je spracovanie chýb prevažne vyriešený problém; akonáhle spolupracuje viacero agentov s vlastnými kontextovými oknami, toolmi a rolami, vznikajú triedy chýb, ktoré v jedinom tool-use-loope jednoducho neexistujú.

• Oddeľte čítaciu a zápisovú cestu: Mnohí agenti smú paralelne čítať a navrhovať, ale committuje len jeden (alebo jeden stupeň pipeline) – to je najúčinnejší prostriedok proti šíreniu chýb.
• Obmedzte každú tasku: Timeout, token-cap a explicitný stav failed na každého sub-agenta zabraňujú deadlockom a explóziám nákladov.
• Verifikujte pred syntézou: Verifier-judge-agent zachytí halucinované fakty skôr, než ich lead-agent zapíše ako pravdu do odpovede.

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, vlastným toolsetom a v prísnom prípade vlastným kontextovým oknom –, ktorí spoločne riešia úlohu. Práve táto distribúcia vytvára nové povrchy chýb. Už neexistuje jediný trace, ale N trajektórií sub-agentov plus syntéza. Behy sú nedeterministické: ten istý input spawnuje rôznych sub-agentov v rôznom poradí. A systém môže vykazovať emergentné správanie, ktoré takto neplánoval žiadny jednotlivý agent.

Centrálnym 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 systémové chybné rozhodnutie. Spracovanie chýb v multi-agentových systémoch preto znamená dvojaké: urobiť jednotlivých agentov robustný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 katalóg chýb zdokumentovaný v produkcii spoločnosťami Anthropic, Cognition, Sierra, Salesforce a Microsoft. Kto nasadzuje multi-agent do produkcie, musí ho poznať.

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

Zabránenie šíreniu chýb: oddeliť čítaciu a zápisovú cestu

Najdôležitejšie architektonické rozhodnutie proti šíreniu chýb nie je tool, ale princíp. Cognition.ai ho vystihla v "Don't Build Multi-Agents" (jún 2025) a v aktualizácii "Multi-Agents: What's Actually Working" (apríl 2026): multi-agent fan-out pre čítanie je robustný, multi-agent fan-out pre zápis je krehký. Dôsledkom je pravidlo single-threaded writes:

• Single-threaded writes: Mnohí agenti čítajú, skúmajú, navrhujú – ale committuje len jeden agent alebo jeden stupeň pipeline. Chybný čítací agent dodá len fragmentový príspevok, ktorý môže lead zahodiť alebo znovu vyžiadať.
• Nezávislé writes s reconciliation: Každý sub-agent dodá fragment, lead-agent ich zladí do finálneho výstupu (vzor research-agenta od Anthropic).
• Konkurujúce writes na zdieľaný state: Špirála smrti – vyhnúť sa.

Pozorovanie Cognition za tým: "Apparent disagreements" medzi agentmi sú väčšinou symptómy fragmentácie kontextu, nie skutočnej nezhody. Tam, kde je previazanie vysoké, treba zdieľať plné traces agentov namiesto len jednotlivých správ. Pre zdieľané externé úložisko (vektorový store, Postgres, SAP HANA) platí vo väčšine produkčných systémov to isté pravidlo: jeden zapisovateľ, mnoho čitateľov.

Retries s backoffom, timeouty a circuit-breaker

Na úrovni jednotlivého volania agenta alebo toolu sa uplatňujú klasické vzory odolnosti – prevzaté zo sveta microservices:

• Retries s exponenciálnym backoffom: Tranzientné chyby (rate-limit, krátky výpadok toolu, timeout) sa opakujú s rastúcimi čakacími časmi, ideálne s jitterom, aby sa predišlo efektom thundering-herd. Dôležité: retries pomáhajú len proti tranzientným, nie proti sémantickým chybám. Opätovné volanie halucinujúceho agenta dodá tú istú halucináciu.
• Timeouty na každej tasku: Protokol A2A definuje životný cyklus tasku submitted → working → input-required → completed | failed | canceled. Timeout na každej tasku plus explicitný stav input-required sú zdokumentované protiopatrenie proti resource-deadlockom. Bez timeoutu môže čakajúci agent zablokovať celý systém.
• Circuit-breaker: Ak sa chyby sub-agenta alebo toolu nahromadia nad prahovú hodnotu, breaker sa otvorí a zablokuje ďalšie volania na isté časové okno. To zastaví explóziu nákladov a dá priestor pre fallback.
• Fallback-agenti a degradované odpovede: Ak vypadne špecializovaný agent, preberie úlohu jednoduchší fallback-agent, iný model-tier alebo vedome redukovaná odpoveď. Lepší úprimne obmedzený výstup než kaskádové chybné rozhodnutie.

Praktickú token-disciplínu z referencie research-agenta od Anthropic to dopĺňa: explicitne stropovať token-spend sub-agentov (podporované Bedrock AgentCore, LangGraph a Claude Agent SDK), nútiť výstupy sub-agentov do typovanej schémy (Pydantic, JSON-Schema, A2A-Artifact) a pred vrátením komprimovať – nikdy nepreposielať plný prepis sub-agenta lead-agentovi. Typovaná schéma je zároveň hranicou chýb: čo sa nezmestí do schémy, sa odmietne namiesto preposlania.

Monitoring a observability: predpoklad, nie add-on

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

• Distribuované tracing cez celý A2A-mesh, s priebežným korelačným/trace-ID v každej A2A-tasku a každom MCP-calle. OpenTelemetry je v roku 2026 prierezovým štandardom.
• Nástroje (stav 2026): LangSmith pre interné LangGraph-traces; Galileo alebo Arize Phoenix pre multi-agent-traces cez hranice vendorov; Pydantic Logfire v Python-orientovaných tímoch; Datadog/Splunk/Grafana pre SIEM-koreláciu.
• Verifier-judge-pattern: Samostatný judge-agent – často silnejší model než workeri – hodnotí každú trajektóriu podľa malej rubriky: Úloha splnená? Odpoveď grounded? Zostali agenti on-task? Dodržaný budget? To je najľahšia produkčne použiteľná odpoveď proti kaskádovým chybám.

Pre DACH je observability navyše otázkou compliance. BaFin, FMA a FINMA budú v roku 2026 čoraz viac tlačiť na end-to-end traces každého volania agenta, na reprodukovateľnosť (pinovať verzie modelov v produkcii, zaznamenávať všetky prompty sub-agentov, tool-cally a AgentCards) a na append-only audit-storage. Lehoty uchovávania sa riadia podľa sektora: BFSI 10 rokov, pharma-GxP často 25–30 rokov.

Príklad: Allianz Project Nemo

Project Nemo od Allianz – nemeckej poisťovne – je jedným z najčistejšie zdokumentovaných DACH-relevantných multi-agentových nasadení 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 beží za menej ako päť minút.

Dva princípy spracovania chýb sú tu stavebne zakotvené:

• Audit-agent ako prvok topológie: Dedikovaný agent vytvára úplné zhrnutie všetkých rozhodnutí agentov a ich zdôvodnení – kompletný audit-trail pre compliance, kontrolu kvality a ľudskú kontrolu. Auditovateľnosť je zabudovaná do topológie agentov, nie až do logovacej pipeline.
• Human-in-the-loop na kritickom stupni: Ľudský referent skontroluje audit-zhrnutie a urobí finálne rozhodnutie o výplate. Kaskádové chybné rozhodnutie sa zachytí na najdrahšom, nezvratnom bode – ako explicitná policy.

Výsledok: 80 % redukcia času spracovania a vybavenia pre oprávnené škody pod AUD 500, naživo za menej ako 100 dní (Austrália, júl 2025). Ponaučenie pre spracovanie chýb: modulárni agenti s jasnými rolami, dedikovaná audit-cesta a ľudský kontrolný bod robia systém, ktorý je rýchly a zvládnuteľný.

Praktický checklist spracovania chýb

• Zápisová cesta single-threaded? Práve jeden agent/jeden stupeň committuje; čitatelia fan-out, zapisovatelia nie.
  
• Timeout na každej tasku? Plus explicitný stav input-required proti deadlockom.
  
• Retries s backoffom + jitterom len pre tranzientné chyby, nie pre sémantické.
  
• Circuit-breaker na sub-agenta/tool s prahovou hodnotou a reset-oknom.
  
• Fallback-agent alebo degradovaná odpoveď definovaná pre každého kritického agenta.
  
• Token-capy sub-agentov nastavené; výstupy donútené do typovanej schémy a komprimované.
  
• 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-tasku a MCP-calle; OTel-export.
  
• Human-in-the-loop na nezvratných/drahých krokoch.
  
• Verzie modelov pinované, audit-trail append-only, uchovávanie v súlade so sektorom.
  

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 na pozadí: newsletterová alebo SEO-audit pipeline s research-, outline-, draft- a review-agentom stojí a padá s verifier-judgeom a single-threaded zápisovým stupňom. Pre DACH-B2B-rozhodovateľov platí: vyžadujte od každého multi-agent pitchu – interného aj od vendora – konkrétne odpovede na stratégiu timeoutov, fallbackov, verifierov a traces. Systém bez observability triedy Galileo/LangSmith sa pri otázke regulátora nedá preskúmať. Kto spracovanie chýb buduje 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é.