Jak funguje konverzační AI agent zevnitř

Jak funguje konverzační AI agent zevnitř (architektura OpenClaw)

Jak funguje konverzační AI agent v praxi, krok za krokem? Tento příspěvek otevírá černou skříňku OpenClaw: od okamžiku, kdy zpráva zákazníka dorazí na WhatsApp, až po text, který agent napíše zpět. Bude to technické. Stojí to za to, pokud rozhodujete o architektuře produktu, pokud chcete koupit řešení a chcete ho zhodnotit do hloubky, nebo pokud vás prostě zajímá, co se děje za kulisami konverzace.

TL;DR: každý tah prochází 6 fázemi — příjem, vyřešení kontextu, výběr skills, rozhodnutí o další akci, provedení s guard-rails, uložení paměti. Celý cyklus běží za <2 sekundy na edge Cloudflare, bez fixního serveru.

---

Proč na architektuře záleží

Konverzační agent, který vypadá, že funguje v demu, ale v produkci selhává, má obvykle jeden z těchto 4 problémů:

1. Vysoká latence — zákazník čeká 8 sekund na odpověď, konverzace umírá.
2. Nekontrolovaná halucinace — agent si vymýšlí cenu, čas, pravidla.
3. Ztracený kontext — zákazník se vrátí po 2 dnech a agent „zapomene" všechno.
4. Nekontrolované náklady — každá dlouhá konverzace zaplní prompt a vy platíte jmění za tokeny.

Všechny 4 jsou volby architektury, ne omezení modelu. OpenClaw byl postaven tak, aby se všem 4 vyhnul — a cesta k pochopení vede přes pohled na cyklus jednoho tahu.

---

Cyklus jednoho tahu (6 fází)

Představte si, že zákazník právě poslal zprávu "quero marcar pra sábado de manhã". Co se děje mezi „received" a odpovědí agenta?

Fáze 1 — Příjem (edge worker, <50ms)

Zpráva z WhatsAppu přichází přes webhook od Meta přímo do Cloudflare Workeru v geograficky nejbližším bodě přítomnosti (PoP). V Brazílii to znamená São Paulo nebo Rio, síťová latence < 20ms.

Worker dělá tři věci:

1. Validuje podpis webhooku (HMAC proti tajnému klíči WABA).
2. Identifikuje tenanta podle telefonního čísla příjemce (multi-tenant podle to_number).
3. Normalizuje payload — audio se převede na transkripci, obrázek na popis, lokace na {lat,lng}, text zůstává tak, jak je.

Na konci fáze 1 máte objekt {tenant_id, conversation_id, user_message} připravený pro další krok.

Fáze 2 — Vyřešení kontextu (D1 + KV, ~80ms)

Agent potřebuje 3 části kontextu, než se rozhodne:

• Nedávná historie konverzace (posledních N relevantních replik).
• Dlouhodobá paměť klienta (preference, historie nákupů, poznámky).
• Stav agenta (persona, povolené skills, pravidla).

Vše pochází z D1 (distribuované SQLite od Cloudflare). D1 nahrazuje tradiční Postgres/Mongo — žádný databázový server k údržbě, přístup během několika ms z workeru, multi-tenant podle tenant_id.

Klíčový bod: my nenačítáme celou konverzaci do promptu. Memory Manager v2 od OpenClaw (popsaný v naší interní dokumentaci) vybírá pouze repliky relevantní pro aktuální repliku (posledních N + N s vysokou sémantickou relevancí). To udržuje náklady na tokeny předvídatelné i u konverzací se 100+ replikami.

Fáze 3 — Výběr skills (policy engine, ~20ms)

Každý agent má k dispozici sadu skills — funkcí, které může vyvolat. Příklady: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Na základě zprávy "quero marcar pra sábado de manhã" policy engine filtruje:

• Skills kompatibilní s detekovaným záměrem (plánování).
• Skills povolené pro tuto fázi konverzace (ne každý skill je dostupný po celou dobu).
• Skills, které tento tenant povolil (calendar se zobrazí pouze pokud tenant provedl integraci).

Na konci máte malou podmnožinu skills předanou modelu — ne 50 možných, ale pouze 4, které zde dávají smysl. To drasticky snižuje šanci, že model vyvolá nesprávný skill.

Fáze 4 — Rozhodnutí (LLM call, 400–1200ms)

Nyní vstupuje model. OpenClaw provede jediné volání LLM modelu na hranici (Anthropic Claude, OpenAI GPT, Google Gemini — konfigurovatelné per tenant) s:

• System prompt = persona agenta + pravidla + dostupné skills.
• History = repliky vybrané ve fázi 2.
• User message = zpráva aktuální repliky.

Model odpoví jedním ze dvou způsobů:

• Finální odpověď (text přímo pro klienta).
• Tool call (požadavek na spuštění konkrétního skillu s parametry).

V příkladu "quero marcar pra sábado de manhã" model typicky vrátí:

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

Fáze 5 — Spuštění s guard-rails (proměnlivé, ~100–500ms)

Skill neběží v modelu. Běží v našem kódu, který:

1. Validuje parametry (má date_range správný formát? je v souladu s pravidly tenanta?).
2. Kontroluje oprávnění (má tento agent právo nahlížet do tohoto kalendáře?).
3. Provede volání (v tomto případě Google Calendar API).
4. Vrací strukturovaný výsledek modelu.

Proč na tom záleží? Protože model nikdy nevymýšlí výsledek. Pokud kalendář vrátí [10h, 11h], přesně to se předá do dalšího volání. Pokud skill selže, model ví, že selhal. Nulové riziko, že si agent „vymyslí", že je volný termín v 9h, když není.

Pro případy zahrnující citlivé informace (cena, termín, jméno klienta) pipeline vynucuje tool call — nenechá model odpovídat z vlastních „znalostí". To eliminuje nejčastější třídu halucinací u komerčních agentů.

Fáze 6 — Odpověď a persistování (~50ms)

S výsledkem skillu v ruce model provede druhé volání — tentokrát pro sestavení finální odpovědi klientovi. Např.:

"Mám sobotu v 10h a 11h. Který čas preferujete?"

Paralelně worker:

1. Odešle zprávu zpět přes WhatsApp API.
2. Persistuje kompletní tah (user + assistant + tool calls + trvání) do D1.
3. Aktualizuje dlouhodobou paměť, pokud tah přinesl nový fakt (např.: „klient preferuje sobotu").
4. Emituje událost observability (metrika latence, náklady na tokeny, míra eskalace).

To vše běží paralelně. Persistování neblokuje odeslání zprávy — klient nečeká na D1.

---

Kde je obrana proti halucinacím

Agent, který v produkci halucinuje, rychle ztrácí důvěru. OpenClaw má 4 linie obrany:

1. Vynucený zdroj pravdy. Faktická data (cena, čas, jméno) vždy pocházejí ze skillu, nikdy ze samotného modelu.
2. Dvojitá verifikace u citlivých dat. Rezervace je potvrzena s klientem před persistováním. Platba je potvrzena před udělením přístupu.
3. Explicitní negativní pravidla. Persona každého agenta obsahuje „nikdy nevymýšlej X, Y, Z" — model to dodržuje.
4. Fallback na člověka. Když žádný skill nepokrývá dotaz, agent řekne "nechte mě to ověřit s týmem" a otevře ticket — nehádá.

V auditech, které jsme provedli za posledních 6 měsíců (reálné konverzace ručně revidované), míra faktických halucinací zůstala pod 0,3 % tahů — a téměř všechny případy byly způsobeny konfigurací (tenant zapomněl aktivovat relevantní skill), nikoli chybou modelu.

---

Náklady na konverzaci

Dobrá architektura je neviditelná, dokud se nepodíváte na fakturu. Vzhledem k tomu, že každý krok provádí 1–2 volání LLM + vyhledávání v D1, typické náklady na celou konverzaci (10–15 kroků) jsou: