Jak funguje agenta IA konveračného vnutro

Aký Funkuje Agent AI Konverzácie Vnútri (Archiitektúra OpenClaw)

Ak funguje agent AI konverzácie v praxi, turnus po turnuse? Táto post otvára čiernu skrinu OpenClaw: od momentu, keď príde správa od klienta cez WhatsApp až po text, ktorý agent napíše späť. Bude to technicky. Je to v hodnote, ak sa rozhodujete architektúru produktu, ak chcete kupovať riešenie a chcete hodnotiť základy, alebo ak sa vám páči vedieť, čo sa deje za konverzáciou.

TL;DR: Každý turnus prechádza 6 štádií — ingest, rieši kontext, vyberie zručnosti, rozhoduje o ďalšej akcii, vykonáva s guard-rails, udrží pamäť. Celý cyklus beží v <sekundách na hrane Cloudflare, bez pevne nastaveného servera.

---

Prečo architektúra importuje

Agent konverzácie, ktorý funguje v demo, ale zlomí v produkčnej verzii, obvykle má jedno z týchto 4 problémov:

1. Nadmerná latencia — klient čaká 8 sekúnd na odpoveď, konverzácia umrie.
2. Nekontrolovaná alucinačná — agent vymýšľa cenu, čas, politiku.
3. Ztratenej kontextu — klient sa vráti po 2 dňoch a agent "zapomene" všetko.
4. Nekontrolovaný náklad — každá dlhá konverzácia naplní prompt a vy budete platili veľa tokenov.

Sú to 4 výbery architektúry, nie limitácie modelu. OpenClaw bol postavený, aby sa vyhnul 4 — a cestu k pochopeniu je pozrieť cyklus jedného turnusu.

---

Cyklus jedného turnusu (6 štádií)

Predstavte si, že klient len nedávno poslal správu "chcem si rezervovať na sobotu ráno". Čo sa deje medzi "prijaté" a odpoveď od agenta?

Štádium 1 — Ingest (hranový robot, <ms)

Správa z WhatsApp prišla cez webhook Meta priamo do Cloudflare Worker na najbližšom geograficky hrane. V Brazílii to znamená São Paulo alebo Rio, latencia siete <0ms.

Robot robí tri veci:

1. Validuje podpis webhook (HMAC proti tajomstvu WABA).
2. Identifikuje klienta podľa čísla telefónu odosielateľa (multi-tenant podľa to_number).
3. Normalizuje payload — zvuk sa premení na transkripciu, obrázok sa premení na popis, lokalizáciu sa premení na {lat,lng}, text zostane taký, aký je.

Na konci štádia 1 máte objekt {tenant_id, konverzácia_id, používateľská správa} pripravený pre ďalšie kroky.

• História posledných turnov (posledných N turnov relevantných).
• Dlhodobá pamäť klienta (preferencie, históriu kúpeľ, poznámky).
• Stav agenta (persona, schopnosti povolené, pravidlá).

Všetky pochádzajú z D1 (rozdelený SQLite Cloudflare). D1 nahradzuje tradičné Postgres/Mongo bez servera na údržbu, prístup v niekoľkých milisekundách z pracovného procesu, multi-tenant pomocou tenant_id.

Kľúčové: nepreberáme celú konverzáciu do promptu. Memory Manager v2 OpenClaw (popísaný v našej vnútorné dokumentácii) vyberie iba relevantné turny pre aktuálny turn (posledných N + N s vysokou relevantnosťou semantiky). Toto udržuje predvídateľný náklad na token aj v konverzáciách s viac ako 100 turnami.

Stádium 3 — Vyber schopností (policy engine, ~20ms)

Každý agent má k dispozícii schopnosti (funkcie, ktoré môže spustiť). Príklady: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Dátou správu "quero markať pre sobotu ráno", policy engine filtruje:

• Schopnosti kompatibilné s detekovanou intenciou (plánovanie).
• Schopnosti povolené pre fázu konverzácie (nie všetky schopnosti sú k dispozícii v každom štádiu).
• Schopnosti povolené pre tento tenant (kalendár sa zobrazí iba v prípade, ak tenant ho integroval).

Na konci máte malý submnožinu schopností, ktoré sú premenené na model - nie 50 možností, ale iba 4, ktoré sú relevantné v tomto kontexte. Toto dramaticky znižuje šancu, že model spustí nepodstatnú schopnosť.

Stádium 4 — Rozhodnutie (LLM volanie, 400-1200ms)

Teraz vstupuje model. OpenClaw vykoná jedinou volanie na LLM na hranici (Anthropic Claude, OpenAI GPT, Google Gemini - konfigurovateľné pre tenanta) s:

• Systémový prompt = persona agenta + pravidlá + dostupné schopnosti.
• História = vybrané turny v štádiu 2.
• Správa používateľa = správa aktuálneho turnu.

Model odpovedá jednou z dvoch vecí:

• Konečná odpoveď (textový vstup pre klienta).
• Nástrojové volanie (požiadanie na spustenie konkrétnej schopnosti s parametrami).

V príklade "quero markať pre sobotu ráno", model typicky vráti:

{
  "tool": "consultar_calendario",
  "args": { "date_range": "2026-04-19 06:00 to 12:00" }
}

Stádium 5 — Spustenie s ochrannými rĺžami (premenlivé, ~100-500ms)

Schopnosť nie spúšťa model. Spúšťa sa v našom kóde, ktorý:

Translated markdown (sk-SK):

1. Overenie parametrov (je datumový rozsah v správnom formáte? Je v súlade s pravidlami tenantu?).
2. Overenie oprávnenia (tento agent má právo na prístup k tomuto kalendáru?).
3. Spustenie volania (Google Calendar API v tomto prípade).
4. Vrátenie výsledku v štruktúrnom forme pre model.

Prečo to je dôležité? Pretože model nikdy neprodukuje výsledok sám. Ak kalendár vráti [10h, 11h], je to presne to, čo sa dostane do ďalšej volania. Ak skil selí, model vie, že selí. Žiadny riziko, že agent "vymýšľa", že má čas na 9h, keď ho nemá.

Pre prípady, ktoré súvia s citlivou informáciou (cena, termín, meno zákazníka), pipeline núti tool call — neopustí model, aby odpovedal sám. Toto eliminuje najčastejší typ alucinačného správania v komerčných agentoch.

Stádium 6 — Odpoveď a persistencia (~50ms)

S výsledkom skilu v rukách model spustí druhú volanie — teraz na formovanie konečnej odpovede pre zákazníka. Napríklad:

"Mám sobotu na 10h a 11h. Ktoré preferujete?"

Paralelne worker:

1. Odosla správu späť cez API WhatsApp.
2. Uloži celý turnus (zákazník + asistent + volania nástroja + dĺžka) do D1.
3. Aktualizuje dlhodobú pamäť ak turnus produkoval nový fakt (napríklad "zákazník preferuje sobotu").
4. Vydá udalosť pozorovateľnosti (metrika odstupnosti, náklad na tokeny, skutočná škála).

Všetko to beží paralelne. Persistencia neblokuje odoslanie správy — zákazník nečaká na D1.

---

Kde je obrana proti alucinačnému správaniu

Agent, ktorý alucina v produkčnej fáze, stráca dôveru rýchlo. OpenClaw má 4 linie obrany:

1. Forcené zdroje pravdy. Fakčné údaje (cena, čas, meno) ** vždy** prichádzajú z skilu, nikdy z modelu sám.
2. Dvojité overenie citlivých údajov. Agendovanie je potvrdené s zákazníkom pred uložením. Platba je potvrdená pred oslobodením prístupu.
3. Explicitné záväzky. Osobnosť každého agenta obsahuje "niekedy nepredelaj X, Y, Z" — model sa riadi.
4. Fallback na človeka. Keď žiadna skila neobsahuje otázku, agent povie "Dej mi overiť s tím" a otvorí ticket — nešle.

V auditoch, ktoré sme robili v posledných 6 mesiacoch (skutočné konverzacie, preverené ručne), sa podiel alucinačného správania fakticky dostal pod 0,3% turnusov — a väčšina prípadov bola spôsobená konfiguráciou (tenant si zapomene na skilu relevantného), nie chybou modelu.

Arquitetura dobráka je neviditeľná až keď si pozrieš faktúru. Podmienkou je, že každý turn je 1-2 volaní LLM + vyhľadávanie v D1, takto sa típicky vyzerá náklad na úplnú konverzáciu (10-15 turnov):

• 1-2 volania LLM * 10-15 turnov = 10-30 volaní LLM
• 1-2 vyhľadávania v D1 * 10-15 turnov = 10-30 vyhľadávaní v D1
• Celkový náklad na úplnú konverzáciu: 20-60 volaní LLM + 20-60 vyhľadávaní v D1