Ako Funguje Konverzačný AI Agent Zvnútra

Ako Funguje Konverzačný AI Agent Zvnútra (Architektúra OpenClaw)

Ako funguje konverzačný AI agent v praxi, krok za krokom? Tento príspevok otvára čiernu skrinku OpenClaw: od momentu, keď správa klienta dorazí do WhatsAppu, až po text, ktorý agent napíše späť. Bude to technické. Oplatí sa, ak rozhodujete o architektúre produktu, ak si chcete kúpiť riešenie a chcete ho dôkladne vyhodnotiť, alebo ak vás baví vedieť, čo sa deje za konverzáciou.

TL;DR: každý krok prechádza 6 fázami — ingest, riešenie kontextu, výber zručností, rozhodnutie o ďalšej akcii, vykonanie s ochranými mechanizmami, uloženie pamäte. Celý cyklus beží <2 sekundy na edge Cloudflare, bez pevného servera.

---

Prečo záleží na architektúre

Konverzačný agent, ktorý vyzerá, že funguje v deme, ale zlyhá v produkcii, má zvyčajne jeden z týchto 4 problémov:

1. Vysoká latencia — klient čaká 8 sekúnd na odpoveď, konverzácia zomiera.
2. Nekontrolované halucinácie — agent si vymýšľa cenu, čas, pravidlá.
3. Stratený kontext — klient sa vráti po 2 dňoch a agent "zabudne" všetko.
4. Nekontrolované náklady — každá dlhá konverzácia naplní prompt a platíte majetok za tokeny.

Všetky 4 sú architektonické rozhodnutia, nie obmedzenia modelu. OpenClaw bol postavený tak, aby sa vyhol všetkým 4 — a cesta k pochopeniu je pozrieť sa na cyklus jedného kroku.

---

Cyklus jedného kroku (6 fáz)

Predstavte si, že klient práve poslal správu "chcem si dohodnúť termín na sobotu ráno". Čo sa stane medzi "received" a odpoveďou agenta?

Fáza 1 — Ingest (edge worker, <50ms)

Správa z WhatsAppu prichádza cez webhook Meta priamo do Cloudflare Worker v geograficky najbližšom bode prítomnosti (PoP). V Brazílii to znamená São Paulo alebo Rio, sieťová latencia < 20ms.

Worker robí tri věci:

1. Validuje podpis webhooku (HMAC proti tajomstvu WABA).
2. Identifikuje tenant podľa telefónneho čísla príjemcu (multi-tenant podľa to_number).
3. Normalizuje payload — audio sa stáva prepisom, obrázok popisom, poloha {lat,lng}, text zostáva ako je.

Na konci fázy 1 máte objekt {tenant_id, conversation_id, user_message} pripravený na ďalší krok.

Fáza 2 — Riešenie kontextu (D1 + KV, ~80ms)

Agent potrebuje 3 časti kontextu pred rozhodnutím:

• Nedávna história konverzácie (posledných N relevantných kôl).
• Dlhodobá pamäť klienta (preferencie, história nákupov, poznámky).
• Stav agenta (persona, povolené skills, pravidlá).

Všetko pochádza z D1 (distribuovaný SQLite od Cloudflare). D1 nahrádza tradičný Postgres/Mongo — žiadny databázový server na údržbu, prístup v priebehu niekoľkých ms z workera, multi-tenant pomocou tenant_id.

Kľúčový bod: nenačítavame celú konverzáciu do promptu. Memory Manager v2 od OpenClaw (popísaný v našej internej dokumentácii) vyberá len tie kolá relevantné pre aktuálne kolo (posledných N + N s vysokou sémantickou relevanciou). To udržiava náklady na tokeny predvídateľné aj pri konverzáciách s 100+ kolami.

Etapa 3 — Výber skills (policy engine, ~20ms)

Každý agent má k dispozícii súbor skills — funkcie, ktoré môže vyvolať. Príklady: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Pri správe "quero marcar pra sábado de manhã" policy engine filtruje:

• Skills kompatibilné so zisteným zámerom (plánovanie).
• Skills povolené pre túto fázu konverzácie (nie každý skill je dostupný vždy).
• Skills, ktoré tento tenant povolil (calendar sa zobrazí len ak tenant integroval).

Nakoniec máte malú podmnožinu skills odovzdanú modelu — nie všetkých 50 možných, len 4, ktoré tu dávajú zmysel. To drasticky znižuje pravdepodobnosť, že model vyvolá nesprávny skill.

Etapa 4 — Rozhodnutie (LLM call, 400-1200ms)

Teraz vstupuje model. OpenClaw vykoná jedno volanie na hraničný LLM (Anthropic Claude, OpenAI GPT, Google Gemini — konfigurovateľné podľa tenanta) s:

• System prompt = persona agenta + pravidlá + dostupné skills.
• History = kolá vybrané v etape 2.
• User message = správa aktuálneho kola.

Model odpovedá jednou z dvoch vecí:

• Finálna odpoveď (priamy text pre klienta).
• Tool call (požiadavka na vykonanie konkrétneho skillu s parametrami).

V príklade "quero marcar pra sábado de manhã" model typicky vráti:

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

Etapa 5 — Vykonanie s guard-rails (variabilné, ~100-500ms)

Skill nebeží v modeli. Beží v našom kóde, ktorý:

1. Validuje parametre (má date_range správny formát? je v rámci pravidiel tenanta?).
2. Kontroluje oprávnenie (má tento agent právo konzultovať tento kalendár?).
3. Vykoná volanie (Google Calendar API v tomto prípade).
4. Vráti štruktúrovaný výsledok modelu.

Prečo na tom záleží? Pretože model nikdy nevymýšľa výsledok. Ak kalendár vráti [10h, 11h], je to presne to, co ide do ďalšieho volania. Ak skill zlyhá, model vie, že zlyhal. Nulové riziko, že agent "vymyslí", že má termín o 9h, keď ho nemá.

Pre prípady, ktoré zahŕňajú citlivé informácie (cena, termín, meno klienta), pipeline vynucuje tool call — nedovolí modelu odpovedať z vlastnej "znalosti". To eliminuje triedu halucinácie, ktorá je najbežnejšia u komerčných agentov.

Fáza 6 — Odpoveď a perzistencia (~50ms)

S výsledkom skillu v rukách model vykoná druhé volanie — teraz na vytvorenie finálnej odpovede pre klienta. Napr.:

"Mám sobotu o 10h a 11h. Ktorú preferujete?"

Paralelne worker:

1. Odošle správu späť cez WhatsApp API.
2. Uloží celý turn (user + assistant + tool calls + trvanie) do D1.
3. Aktualizuje dlhodobú pamäť, ak turn vytvoril nový fakt (napr.: "klient preferuje sobotu").
4. Emituje udalosť pozorovateľnosti (metrika latencie, náklady na token, miera eskalácie).

Toto všetko beží paralelne. Perzistencia neblokuje odoslanie správy — klient nečaká na D1.

---

Kde je obrana proti halucináciám

Agent, ktorý halucinuje v produkcii, rýchlo stráca dôveru. OpenClaw má 4 línie obrany:

1. Vynútený source-of-truth. Faktické údaje (cena, čas, meno) vždy pochádzajú zo skillu, nikdy nie z modelu samotného.
2. Dvojitá verifikácia citlivých údajov. Plánovanie je potvrdené s klientom pred uložením. Platba je potvrdená pred uvoľnením prístupu.
3. Explicitné negatívne pravidlá. Persona každého agenta zahŕňa "nikdy nevymýšľaj X, Y, Z" — model poslúcha.
4. Fallback na človeka. Keď žiadny skill nepokrýva otázku, agent povie "nechajte ma to overiť s tímom" a otvorí ticket — nehádže.

V auditoch, ktoré sme vykonali za posledných 6 mesiacov (skutočné konverzácie manuálne preskúmané), miera faktických halucinácie zostala pod 0,3 % turnov — a takmer všetky prípady boli kvôli konfigurácii (tenant zabudol povoliť relevantný skill), nie chybe modelu.

---

Náklady na konverzáciu

Dobrá architektúra je neviditeľná, kým sa nepozriete na faktúru. Vzhľadom na to, že každý ťah vykoná 1-2 volania LLM + vyhľadávania v D1, typické náklady na celú konverzáciu (10-15 ťahov) sú: