Keď sme prvýkrát nasadzovali AI agenta pre klienta z výroby — úloha: automatizovať zostavovanie správ z viacerých systémov — naivne sme spustili jednoduchú slučku s jedným LLM a sériou nástrojov. Fungovalo to... pokiaľ nič nešlo inak, ako malo. Akonáhle jeden nástroj vrátil neočakávaný výstup, agent sa dostal do slučky a 40 minút generoval tokeny, kým sme to manuálne zastavili. Problémom nebol model. Problémom bola architektúra — nepremyslená pre reálne podmienky.
Dnes existujú tri prevládajúce vzory pre architektúry AI agentov: ReAct, Plan-and-Execute a reflexia. Každý má svoje miesto, každý má limity. Tento článok je rozhodovací rámec — kedy ktorý vzor zvoliť, čo od neho čakať a kde vás dostane do problémov.
Prečo záleží na výbere architektúry
Výber architektúry nie je len technický detail. Priamo ovplyvňuje štyri metriky, na ktorých záleží v produkcii:
- Spoľahlivosť — ako agent reaguje na neočakávané výstupy nástrojov alebo chyby
- Náklady — koľko tokenov spotrebuje na jednu úlohu
- Latencia — ako rýchlo dostane používateľ výsledok
- Debugovateľnosť — ako ľahko nájdete, kde a prečo agent zlyhal
Dôležité upozornenie: ReAct, Plan-and-Execute aj Reflexion sú akademické vzory z rokov 2022–2023 (Yao et al. 2022 pre ReAct). LangGraph, AutoGen, CrewAI a iné frameworky tieto vzory *implementujú* — ale nevymysleli ich. Výber frameworku je sekundárne rozhodnutie. Primárne je výber vzoru.
ReAct: Reason-Act-Observe slučka
ReAct (Reasoning + Acting) je najjednoduchší a najrozšírenejší vzor. Agent pracuje v slučke:
- 1.Reason — na základe aktuálneho stavu a histórie LLM „premýšľa" (generuje text popisujúci uvažovanie)
- 2.Act — vyberie a zavolá nástroj s konkrétnymi parametrami
- 3.Observe — dostane výstup nástroja, vloží ho do kontextu
- 4.Opakuje, kým nedosiahne cieľ alebo sa nedostane k finálnej odpovedi
Silná stránka ReAct je adaptabilita. Ak sa niečo zmení počas behu — nástroj vráti neočakávaný výsledok, API zmení formát — agent to vidí v Observe fáze a môže zmeniť postup. Nie podľa vopred napísaného plánu, ale reaktívne.
Kde ReAct funguje dobre
- Úlohy s 2–4 krokmi a jasným cieľom (vyhľadaj X, spracuj Y, zapíš Z)
- Interaktívne nástroje, kde sa kontext mení v reálnom čase
- Prototypovanie — ReAct je najrýchlejší na implementáciu
- Keď chcete čo najjednoduchší audit log (každý Reason-Act-Observe krok je viditeľný)
Kde ReAct zlyháva
- Dlhé úlohy s mnohými krokmi — každý nový krok pridáva do kontextu celú históriu, náklady rastú kvadraticky
- Paralelné úlohy — ReAct je sekvenčný, nemôže súčasne vykonávať viac vetví
- Bez `max_steps` limitu je nebezpečný — to nie je nadsázka. Agent bez nastaveného limitu krokov môže cez noc uviaznuť v slučke a vygenerovať tisíce zbytočných API volaní — a s nimi účet rádovo v tisícoch eur. Vídame to v praxi, nie je to hypotetické riziko.
Dôležitá korekcia rozšíreného mýtu: slovo „Reason" v ReAct *neznamená*, že agent skutočne uvažuje správne. Reason krok je jazykový výstup — LLM generuje text, ktorý vyzerá ako uvažovanie. Môže byť plný chýb, a model to nijako nesignalizuje. Neverifikovateľné „myslenie" je jedna z najčastejších príčin tichého zlyhania ReAct agentov.
Nákladový profil ReAct
Typická ReAct úloha spotrebuje 2 000–3 000 tokenov pri 3–4 krokoch. Pri 8+ krokoch môže byť spotreba 10 000–20 000 tokenov na jednu úlohu, pretože celá história sa opakuje v každom kontextovom okne. Na produkčnej záťaži si toto všimnete na faktúre.
Plan-and-Execute: Najprv plán, potom kroky
Plan-and-Execute (P&E) rozdeľuje agenta na dve fázy:
- 1.Plánovač — dostane cieľ a vygeneruje explicitný plán krokov (napr. „krok 1: načítaj dáta z API, krok 2: transformuj formát, krok 3: uložiť do databázy, krok 4: odošli report")
- 2.Exekútor — vykonáva kroky podľa plánu, jeden po druhom, bez opätovného plánovania
Kľúčová výhoda: plánovač a exekútor nemusia byť ten istý model. Toto je ekonomicky zaujímavé — drahý silný model (napr. model triedy Claude Opus alebo GPT) robí plánovanie, kde záleží na kvalite. Lacný rýchly model robí execution, kde záleží na rýchlosti a cene. Pre dlhé úlohy s N krokmi to môže byť lacnejšie ako čistý ReAct.
Kde P&E funguje dobre
- Dlhé, štruktúrované úlohy (5+ krokov s jasnou logikou)
- Dávkové spracovania — keď musíte spracovať 1 000 dokumentov rovnakým postupom
- Auditovateľné pipeline — plán je explicitný dokument, klient ho vidí pred spustením
- Odolnosť voči prompt injection — výskum naznačuje, že P&E má istú inherentnú výhodu: exekútor nemá prístup k plánovacím inštrukciám, útočník v dátach ho teda ťažšie presmeruje (nie je to však úplná ochrana)
Kde P&E zlyháva
Základný P&E má fixný plán. Keď sa podmienky počas behu zmenia — API vráti iný formát, krok 3 zlyhá — agent pokračuje podľa starého plánu alebo sa zasekne. Dynamic replanning (opätovné plánovanie po chybe) je rozšírenie, nie základná vlastnosť P&E. Musíte ho explicitne implementovať.
Ďalší mýtus na opravu: P&E *nie je vždy presnejší* ako ReAct. Pre dynamické prostredie, kde sa podmienky menia počas behu, je ReAct adaptabilnejší. P&E je lepší tam, kde je prostredie predvídateľné a plán zostane platný do konca.
Nákladový profil P&E
Typická P&E úloha spotrebuje 3 000–4 500 tokenov (vrátane planning fázy). Na prvý pohľad drahšie ako ReAct. Ale pre úlohy s 8+ krokmi je celková spotreba nižšia — exekútor pracuje s kratším kontextom ako ReAct slučka, ktorá akumuluje celú históriu. Odporúčanie: pre krátke úlohy (2–4 kroky) zvoľte ReAct, pre dlhé (6+ kroky) zvážte P&E.
Reflexia a self-critique
Reflexia (Reflexion, Shinn et al. 2023) pridáva nad ReAct alebo P&E vrstvu sebahodnotenia:
- 1.Agent vykoná úlohu (ReAct alebo P&E)
- 2.Reflexia modul zhodnotí výsledok — „bol cieľ dosiahnutý? Kde nastali chyby?"
- 3.Na základe reflexie sa agentovi aktualizuje pamäť alebo sa opakuje krok s upraveným prístupom
Príklad výsledkov: na úlohách z CodeContests sa GPT-4 dostal z približne 19 % úspešnosti pri jednoduchom prompte na okolo 44 % s iteratívnym test-driven prístupom (publikovaný flow AlphaCodium). To je reálny nárast — práve pri úlohách s deterministickou verifikáciou.
Kde reflexia pomáha
- Kódovacie úlohy s deterministickou verifikáciou (kód buď prešiel testami, alebo nie)
- Iteratívne výstupy — keď prvá verzia nikdy nie je dostatočná a chcete automatické zlepšovanie
- Komplexné analýzy, kde potrebujete druhý pohľad na výsledok
Limity reflexie
Kritický limit: keď ten istý model generuje výstup aj kritiku, reflexia má tendenciu opakovať rovnaké chyby. Model nevidí medzery vo vlastnom uvažovaní. Replikačné štúdie z roku 2025 to potvrdili — single-agent Reflexion v iteratívnych cykloch konverguje k rovnakej (nesprávnej) odpovedi. Riešenie je buď iný model pre verifikáciu, alebo externý deterministický verifikátor (testy, linter, validácia schémy).
Viac o tom, ako guardrails pre AI agentov pomáhajú zachytiť tieto zlyhania ešte pred tým, ako sa prejavia používateľovi.
Kedy stačí jedno volanie LLM
Pred výberom architektúry agenta je potrebné položiť otázku: *naozaj potrebujem agenta?*
Odhadujeme, že 40–50 % use-casov, pri ktorých klienti prichádzajú s požiadavkou na agenta, zvládne jedno alebo dve volania LLM bez akejkoľvek slučky. Príklady:
- Klasifikácia dokumentu (jedno volanie, structured output)
- Extrakcia polí z faktúry (jedno volanie + JSON mode)
- Generovanie reportu z pripravených dát (jedno volanie, dlhý prompt)
- Sumarizácia s citáciami (jedno volanie + agentic RAG pipeline)
Pravidlo: ak viete vopred presne definovať vstupy, výstupy a transformáciu — agent nepotrebujete. Agent pridáva hodnotu, keď kroky nie sú vopred známe alebo prostredie je dynamické.
Súvisiace rozhodnutie: chatbot vs copilot vs agent — kde sú presné hranice medzi týmito pojmami.
Rozhodovací rámec
Namiesto tabuľky (ktorá by zjednodušovala trade-off) ponúkame sériu otázok:
1. Koľko krokov má úloha? - 1–3 kroky → jedno LLM volanie alebo jednoduchý ReAct - 4–7 krokov, predvídateľné prostredie → Plan-and-Execute - 8+ krokov s paralelnou logikou → P&E + DAG exekútor alebo multi-agent
2. Mení sa prostredie počas behu? - Nie (dávkové spracovanie, deterministický postup) → P&E - Áno (interaktívne, real-time dáta, nepredvídateľné API) → ReAct
3. Potrebujete auditovateľný výstup? - Áno, klient chce vidieť plán pred spustením → P&E - Nie, dôležitý je výsledok → ReAct (kratší čas na spustenie)
4. Aká je cena chyby? - Nízka (interný nástroj, ľahko opraviteľné) → ReAct s max_steps limitom - Vysoká (zákazník, regulovaná oblasť) → P&E + reflexia + human-in-the-loop
5. Máte dedikovaný tím na údržbu? - Nie → Čo najjednoduchší vzor. ReAct s jasným max_steps, logging každého kroku. - Áno → Môžete si dovoliť P&E + dynamic replanning + reflexia.
Hybridné architektúry v praxi
V produkcii takmer nikdy nevidíme čistý ReAct ani čistý P&E. Bežné kombinácie:
- P&E + ReAct exekútor — plánovač vygeneruje kroky, každý krok vykonáva mini-ReAct agent s prístupom k nástrojom
- ReAct + reflexia — po dokončení ReAct slučky sa spustí reflexia modul, ktorý posúdi kvalitu výstupu
- P&E + dynamic replanning — pri zlyhaní kroku sa celý plán prehodnotí, nie iba daný krok
LangGraph je dnes de facto štandardom pre implementáciu týchto hybridných vzorov v Pythone. Alternatívy ako AutoGen (Microsoft) alebo CrewAI sú silné pre multi-agent koordináciu, ale LangGraph má najväčší ekosystém a produkčnú stabilitu.
Väčšiu perspektívu na to, koľko stojí agent v produkcii, vrátane cenotvorby per-volanie a spôsobov optimalizácie, nájdete v samostatnom článku.
Debugovateľnosť — podceňovaný rozmer
Architektúra ovplyvňuje aj to, ako ľahko nájdete chybu. Z praxe:
ReAct: Každý Reason-Act-Observe krok je viditeľný v trace logu. Keď agent zlyhá pri kroku 7, vidíte presne, aký Observe vstup dostal a aký Reason vygeneroval. Dobre debugovateľný — ak máte správne logovaný každý krok.
P&E: Plán je explicitný dokument — ľahko vidíte, kde exekútor odchýlil od plánu. Ale chyby v samotnom pláne (nesprávna logika plánovača) sú ťažšie odhaliteľné, pretože plánovač beží raz a jeho rozhodnutia nie sú inkrementálne.
Reflexia: Najhoršie debugovateľná. Iteratívne cykly produkujú veľa logov, a keď model opakuje rovnakú chybu v každom cykle, môže byť ťažké určiť, kde je koreňová príčina.
Viac o tom, ako nastaviť observability pre AI agentov — tracing, logging a alerty — v produkčnom nasadení.
Časté otázky
Čo je ReAct architektúra a kde vznikla?
ReAct (Reasoning + Acting) je vzor pre AI agentov navrhnutý Yao et al. v roku 2022 (akademická publikácia). Agent pracuje v slučke Reason–Act–Observe: LLM premýšľa, vyberie nástroj, dostane výsledok a opakuje. LangGraph, LangChain a iné frameworky tento vzor implementujú, ale nevymysleli ho.
Kedy zvoliť Plan-and-Execute namiesto ReAct?
Plan-and-Execute je vhodný pre dlhé, štruktúrované úlohy (6+ krokov) s predvídateľným prostredím, kde chcete auditovateľný plán pred spustením. ReAct je lepší pre krátke, dynamické úlohy, kde sa podmienky menia počas behu. Pre 1–3 kroky zvážte, či agent vôbec potrebujete.
Je Plan-and-Execute vždy presnejší ako ReAct?
Nie. P&E má výhodu pri štruktúrovaných, predvídateľných úlohách. Pre dynamické prostredie, kde sa podmienky menia počas behu, P&E zlyhá — agent pokračuje podľa zastaraného plánu. ReAct je adaptabilnejší, pretože reaguje na každý Observe výstup.
Prečo je nebezpečné spustiť ReAct agenta bez max_steps limitu?
Bez nastaveného limitu krokov sa agent môže dostať do slučky (napr. opakovane volá nástroj, ktorý vracia chybu, ale agent to nevyhodnotí ako terminálny stav). Takýto nekontrolovaný agent dokáže cez noc vygenerovať tisíce volaní a účet rádovo v tisícoch eur. Každý produkčný agent musí mať nastavený explicitný max_steps alebo max_iterations parameter.
Môžem kombinovať ReAct a reflexiu?
Áno, hybridné architektúry sú v produkcii bežné. Typická kombinácia: ReAct slučka pre vykonávanie krokov, reflexia modul po dokončení pre posúdenie kvality výstupu. Dôležité upozornenie: reflexia funguje spoľahlivo len vtedy, keď výstup hodnotí iný model alebo externý deterministický verifikátor (testy, validácia schémy) — nie ten istý model, ktorý output generoval.
*Ak zvažujete nasadenie AI agenta vo vašej firme a nie ste si istí, ktorá architektúra je pre váš use-case vhodná, radi posúdime konkrétnu situáciu. V MP Industrial Solutions pomáhame klientom vybrať prístup, ktorý zodpovedá ich reálnym požiadavkám na spoľahlivosť, náklady a tímové kapacity — nie ten, ktorý vyzerá najimpresívnejšie na demo.*