--- title: "Event-driven agenti: architektura AutoGen v0.4 / AG2 vysvetlena" description: "Event-driven agenti su autonomni softverovi aktori, ktori komunikuju asynchronne prostrednictvom sprav a eventov, a nie v pevnej sekvencnej slucke. Kazdy agent reaguje na prichadzajuce eventy, spracuva ich nezavisle a publikuje vysledky - ako v AutoGen v0.4 a AG2. To umoznuje volnu vazbu, paralelizmus a dlhe behy." locale: "sk" canonical: "https://blckalpaca.at/sk/vedomosti/ai-agenti/prehlad-architektur-ai-agentov/event-driven-agent-architektur" category: "AI agenti" topic: "Prehľad architektúr AI Agentov" updated: "2026-07-29T08:52:54.952Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Event-driven agenti: architektura AutoGen v0.4 / AG2 vysvetlena Event-driven agenti su autonomni softverovi aktori, ktori komunikuju asynchronne prostrednictvom sprav a eventov, a nie v pevnej sekvencnej slucke. Kazdy agent reaguje na prichadzajuce eventy, spracuva ich nezavisle a publikuje vysledky - ako v AutoGen v0.4 a AG2. To umoznuje volnu vazbu, paralelizmus a dlhe behy. ## Klucove body - Event-driven agenti sa riadia Actor-Modelom: agenti su izolovani aktori s vlastnym stavom, ktori komunikuju vylucne prostrednictvom asynchronnych sprav (eventov) - nie cez zdielanu pamat alebo centralnu slucku. - Nova architektura AutoGen v0.4 (a komunitou riadeny fork AG2) stoji na Pub/Sub-Topic vrstve s RoutedAgents; Microsoft uviedol AutoGen (stav 2026) do maintenance rezimu a odkazuje na Microsoft Agent Framework. - Udalostami riadeny pristup skaluje lepsie pri volnej vazbe, skutocnom paralelizme a dlhych behoch; orchestrovane slucky (ReAct, Plan-and-Execute) zostavaju jednoduchsie a lepsie auditovatelne pri kratkych, sekvencnych ulohach. - Poznatok Cognition 2025/2026 plati aj tu: paralelni agenti su vhodni pre citajuce, informacie zhromazdujuce kroky; zapisujuce zmeny stavu by mali zostat single-threaded, aby sa predislo konfliktom. - Pre DACH-B2B rozhodujuce: volna vazba zvysuje komplexnost pri debuggingu, tracingu a preukazatelnosti - distribuovane event-logy musia byt pre DSGVO a EU AI Act bez medzier a zbavene PII perzistované. Event-driven agenti su autonomni softverovi aktori, ktori komunikuju asynchronne prostrednictvom sprav a eventov - nie v pevnej, sekvencnej slucke. Kazdy [agent](/sk/slovnik/agent) reaguje na prichadzajuce eventy, spracuva ich nezavisle a publikuje svoje vysledky ako nove eventy. Tato architektura, ako ju implementuju AutoGen v0.4 a komunitou riadeny fork AG2, oddeluje agentov od seba a umoznuje paralelizmus, volnu vazbu a dlhe behy. - **Jadro:** Agenti = aktori s vlastnym stavom, ktori komunikuju vylucne prostrednictvom asynchronnych sprav namiesto centralnej riadiacej slucky. - **Vyhoda:** Volna vazba, skutocny paralelizmus a vhodnost pre dlho beziace procesy (minuty az hodiny) s cakanim na externe systemy alebo ludi. - **Trade-off:** Vyssia komplexnost pri debuggingu, tracingu a preukazatelnosti - tok riadenia uz nie je linearne citatelny. ## Od orchestrovanej slucky k Event-Busu Vacsina klasickych agentnych vzorov je prisne sekvencna. Pri vzore ReAct napriklad jediny agent na baze [velkeho jazykoveho modelu (LLM)](/sk/vedomosti/ai-agenti/co-su-ai-agenti/reaktivne-vs-deliberativne-agenty) opakovane prechadza cyklus Thought -> Action -> Observation, az kym neemituje finalnu odpoved. Latencia je pritom svojou povahou seriova: zodpoveda priblizne poctu krokov vynasobenemu suctom casu odpovede [LLM](/sk/slovnik/llm) a casu odpovede toolu. Aj Plan-and-Execute alebo ReWOO sice planuju vopred, no kroky v jadre vykonavaju jeden za druhym. Event-driven architektury sa s tymto modelom rozchadzaju. Namiesto centralnej slucky, ktora diktuje dalsi krok, existuje vrstva sprav alebo topicov (Event-Bus). Agenti si predplatia urcite topicy, reaguju na publikovane eventy a sami spustaju nasledne eventy. Stav vyskumu 2026 konstatuje, ze frameworky vseobecne konverguju k spolocnemu primitivu - kombinacii State-Graph a Tool-Calling, ako ju zdielaju LangGraph, Microsoft Agent Framework Workflow a AutoGen Core. Ciste rozdiely v [prompt](/sk/slovnik/prompt)-vzoroch pritom ustupuju do pozadia; rozhodujucou sa stava kvalita middleware, observability a context engineeringu. ## Actor-Model ako teoreticky zaklad Event-driven agenti implementuju [Actor-Model znamy z konkurencneho programovania](/sk/vedomosti/ai-agenti/multi-agent-systemy-zaklady/orchestrator-worker-pattern). Aktor je izolovana vypoctova jednotka s tromi vlastnostami: - **Vlastny, zapuzdreny stav** - ziadna zdielana pamat medzi aktormi, teda ziadne klasicke race conditions cez spolocne premenne. - **Komunikacia len prostrednictvom sprav** - aktor spracuva prichadzajuce spravy typicky jednu po druhej zo svojej mailboxky. - **Dynamika za behu** - aktor moze zmenit svoj stav, vytvorit novych aktorov a posielat dalsie spravy. V AutoGen v0.4 sa to odraza v abstrakcii `RoutedAgent` a v Pub/Sub-Topic vrstve. Oficialna dokumentacia AutoGen popisuje napriklad vzor Reflection ako dvoch `RoutedAgent`s, ktori komunikuju cez Pub/Sub-topicy - `CoderAgent` a `ReviewerAgent`, ktori iteruju az do konvergencie alebo sa zastavia pri limite `max_iterations`. Prave tato logika topic-routingu je prechodom od pevne zadratovanej slucky k udalostami riadenej vazbe: o tom, ktory agent bude aktivny ako dalsi, nerozhoduje centralny controller, ale publikovany event a predplatne topicov. ## AutoGen v0.4, AG2 a kontext Microsoftu Dolezite pre DACH rozhodovatelov, ktori hodnotia Microsoft-stack: AutoGen je podla stavu research 2026 oficialne v maintenance rezime. Microsoft skonsolidoval AutoGen a Semantic Kernel do **Microsoft Agent Framework** a smeruje nove projekty tam - migration guide (`from-autogen`) je smerodajnou referenciou pre existujucich pouzivatelov AutoGen. Agent Framework navyse zavadza SPAR-cyklus (Sense -> Plan -> Act -> Reflect) ako produktizovanu variantu kombinovaneho vzoru ReAct plus reflexia. Paralelne existuje **AG2** ako komunitou riadene pokracovanie linie AutoGen. Kto dnes stavia event-driven architekturu na baze tejto myslienky, vybera teda prakticky medzi tromi moznostami: existujuci AutoGen v0.4 (funkcny, ale uz len udrziavany), komunitou nesene AG2 alebo Microsoftom odporucany Agent Framework pre nove projekty v podnikovom prostredi. ## Kedy udalostami riadeny pristup skaluje lepsie Udalostami riadeny pristup sa neoplati vzdy. Tri podmienky hovoria v jeho prospech: 1. **Volna vazba** - agenti maju byt nezavisle nasaditelni, zamenitelni a jednotlivo skalovatelni. Prieskumny agent moze byt znovu nasadeny bez toho, aby sa dotkol zapisujuceho agenta. 2. **Paralelizmus** - viacero ciastkovych uloh bezi sucasne. Zistenia Cognition z „Don't Build Multi-Agents" (jun 2025) a „Multi-Agents: What's Actually Working" (april 2026) su tu centralnym vodidlom: multi-agent setupy funguju pre **citajuce, paralelne** zhromazdovanie informacii, zatial co **zapisujuce zmeny stavu by mali zostat single-threaded**. Devin na to vyuziva manager-Devina, ktory cez interny [MCP](/sk/slovnik/mcp) vytvara child-Devinov. Prelozene pre klientov agentury: jeden silny agent s toolmi ako standard, paralelni sub-agenti len na zhromazdovanie informacii, nikdy nie na zapisove operacie alebo zmeny stavu. 3. **Dlhe behy** - procesy trvajuce minuty alebo hodiny, s cakanim na externe [API](/sk/slovnik/api), batch-systemy alebo ludi (Human-in-the-Loop). Synchronna slucka by tu blokovala; event-driven system jednoducho caka na dalsi event. ## Vyhody a nevyhody oproti orchestrovanym sluckam | Kriterium | Event-driven (Actor-Model, AutoGen v0.4 / AG2) | Orchestrovana slucka (ReAct, Plan-and-Execute) | | --- | --- | --- | | Vazba | Volna - agenti komunikuju len cez eventy/topicy | Tesna - centralna slucka riadi dalsi krok | | Paralelizmus | Nativny, viacero aktorov sucasne | Sekvencny (latencia ≈ N × (LLM + Tool)) | | Dlhe behy | Silny - neblokujuci, udalostami riadeny | Slaby - slucka blokuje pri cakani | | Skalovatelnost | Horizontalna, aktori jednotlivo skalovatelni | Vertikalne obmedzena, jeden tok riadenia | | Sledovatelnost | Tazsia - potrebne distribuovane, korelovane event-logy | Jednoduchsia - linearny Thought/Action/Observation-trace | | Debugging | Komplexny - sirenie chyb, race conditions | Prehladny - jedna cesta, jeden log | | Vhodny pre | Distribuovane, paralelne, dlho beziace procesy | Kratke, sekvencne, auditne povinne ulohy | Najvacsou slabinou je pozorovatelnost. Pri ReAct-slucke je uplny Thought/Action/Observation-trace k dispozicii linearne a je priamo auditovatelny - realna vyhoda pre regulovane DACH odvetvia. V event-driven modeli je tok riadenia rozlozeny cez mnoho aktorov; chyby sa mozu sirit a [bez staroslivého tracingu sa analyza pricin stava tazkou](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689). Observability nastroje ako LangSmith, Langfuse alebo Arize Phoenix su preto fakticky povinnostou. Pre DSGVO a [EU AI Act](/sk/slovnik/eu-ai-act) musia byt distribuovane event-trace bez medzier, korelovane a zbavene PII perzistované. ## Konkretny priklad: paralelny prieskum trhu Marketingova agentura ma pre B2B klienta vytvorit konkurencnu analyzu: pat konkurentov, kazdy tri zdroje dat (web, tlacove spravy, social media). V ReAct-slucke by to bezalo prisne za sebou: 5 × 3 = 15 sekvencnych tool-krokov. Pri predpokladanych 8 sekundach na krok (cas odpovede LLM plus toolu) by to dalo zhruba 120 sekund celkovej latencie - a kazdy krok navyse opatovne plati cely kontextovy prefix. Udalostami riadene to vyzera takto (pseudo-priebeh): \`\`\` Event: AnalyzaSpustena(konkurenti=[A,B,C,D,E]) -> [Orchestrator publikuje 5 eventov](/sk/vedomosti/ai-agenti/prehlad-architektur-ai-agentov/reflexion-pattern-agenten) "AnalyzujKonkurenta" -> 5 ResearchAgentov reaguje PARALELNE, kazdy 3 zdroje -> kazdy publikuje "CiastkovyVysledokHotovy" -> AggregatorAgent si predplati "CiastkovyVysledokHotovy" -> pri 5/5 ciastkovych vysledkoch publikuje "SpravaPripravena" -> WriterAgent (single-threaded!) vytvori finalnu spravu \`\`\` Pat prieskumnych aktorov bezi sucasne; cas na stene klesa zhruba na trvanie najpomalsej vetvy (≈ 3 × 8 = 24 sekund) plus agregacia - namiesto 120 sekund seriovo. Rozhodujuce podla principu Cognition: **citajuce** prieskumne kroky su paralelizovane, **zapisujuca** finalna sprava zostava single-threaded pri jedinom WriterAgentovi. Tak nevznikaju protichodne zapisove rozhodnutia. Dolezite: tu uvedene sekundove hodnoty su ilustrativne orientacne cisla; realne cisla silno zavisia od modelu, latencie toolu a siete a mali by sa merat na vlastnej zatazi. ## Pre agentury a B2B rozhodovatelov Event-driven agenti nie su samoucelom. Zacnite podla v praxi potvrdenej zasady s najjednoduchsim vzorom, ktory funguje - vacsinou ReAct-sluckou - a eskalujte k udalostami riadenym multi-aktorovym architekturam az vtedy, ked to ospravedlnuju namerane poziadavky (paralelizmus, dlhe behy, volna vazba). Pre marketingove agentury je typickym sweet spotom paralelne, citajuce zhromazdovanie informacii s jednym single-threaded zapisovym krokom na konci. Kto hodnoti Microsoft-stack, mal by v roku 2026 zvolit Microsoft Agent Framework namiesto AutoGen nachadzajuceho sa v maintenance rezime; AG2 je komunitou riadenou alternativou. [Blck Alpaca](/sk) podporuje DACH podniky pri vybere vhodneho architektonickeho vzoru, pri nastaveni observability pre sulad s [DSGVO a EU AI Act](https://gdpr-info.eu/) a pri skalovani agentnych workflowov mernym, nie pocitom riadenym sposobom. ## FAQ ### Cim sa lisia event-driven agenti od klasickej agentnej slucky ako ReAct? ReAct-slucka je striktne sekvencna: jediny agent prechadza Thought, Action a Observation, krok za krokom, s latenciou priblizne N krat (cas odpovede LLM plus cas odpovede toolu). Event-driven agenti naopak pracuju asynchronne: viacero aktorov reaguje nezavisle na eventy, mozu bezat paralelne a su len volne previazani cez vrstvu sprav alebo topicov. To skaluje lepsie, ale zvysuje komplexnost pri tracingu a hladani chyb. ### Je AutoGen v roku 2026 este zmysluplnou volbou? Podla stavu research 2026 je AutoGen oficialne v maintenance rezime; Microsoft presmerovava nove projekty na Microsoft Agent Framework, ktory zlucuje AutoGen a Semantic Kernel. Existujuce systemy AutoGen v0.4 zostavaju funkcne a komunitou riadeny fork AG2 pokracuje v tejto linii. Pre nove projekty v Microsoft-stacku je Agent Framework odporucanym zakladom; oficialny migration guide (from-autogen) je smerodajnou referenciou. ### Kedy event-driven architektura skaluje lepsie ako orchestrovana slucka? Udalostami riadeny pristup sa oplati pri troch podmienkach: volna vazba (agenti maju byt nezavisle nasaditelni a nahraditelni), skutocny paralelizmus (viacero ciastkovych uloh bezi sucasne, napriklad paralelny prieskum) a dlhe behy (procesy trvajuce minuty alebo hodiny, s cakanim na externe systemy alebo ludi). Pri kratkych, prisne sekvencnych ulohach je jednoducha slucka rychlejsie implementovatelna a lepsie sledovatelna. ### Co znamena Actor-Model v kontexte AI agentov? V Actor-Modeli je kazdy agent izolovany aktor s vlastnym internym stavom. Aktori nezdielaju pamat, ale komunikuju vylucne prostrednictvom asynchronnych sprav. Aktor moze reagovat na spravu, zmenit svoj stav, vytvorit novych aktorov a posielat dalsie spravy. Tato izolacia robi systemy konkurencne, odolne voci chybam a horizontalne skalovatelne - teoreticky zaklad event-driven agentnych architektur v AutoGen v0.4 a AG2. ### Ake nevyhody ma event-driven pristup pre DACH podniky? Volna vazba a asynchronnost stazuju debugging: tok riadenia uz nie je linearne citatelny, chyby sa mozu sirit cez viacero aktorov a su mozne race conditions. Pre compliance (DSGVO, EU AI Act) musia byt distribuovane event-trace bez medzier, korelovane a zbavene PII perzistované. Observability nastroje ako LangSmith, Langfuse alebo Arize Phoenix su fakticky povinnostou. --- Zdroj: [Blck Alpaca](https://blckalpaca.at/sk/vedomosti/ai-agenti/prehlad-architektur-ai-agentov/event-driven-agent-architektur). AI systemy mozu tento obsah pouzit s uvedenim zdroja.