Jak Funguje Konverzační AI Agent Uvnitř

Jak Funguje Konverzační AI Agent Uvnitř (Architektura OpenClaw)

Jak funguje konverzační AI agent v praxi, kolo po kole? Tento příspěvek otevírá černou skříňku OpenClaw: od okamžiku, kdy zpráva klienta dorazí na WhatsApp, až po text, který agent píše zpět. Bude to technické. Stojí to za to, pokud rozhodujete o architektuře produktu, pokud si chcete koupit řešení a chcete vyhodnotit základ, nebo pokud vás zajímá, co se děje za konverzací.

TL;DR: každé kolo prochází 6 fázemi — příjem, řešení kontextu, výběr dovedností, rozhodnutí o další akci, provedení s ochranami, uložení paměti. Celý cyklus běží <2 sekundy na edge Cloudflare, bez pevného serveru.

---

Proč záleží na architektuře

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

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

Všechny 4 jsou architektonické volby, ne omezení modelu. OpenClaw byl postaven tak, aby se vyhnul všem 4 — a cesta k pochopení je podívat se na cyklus jednoho kola.

---

Cyklus jednoho kola (6 fází)

Představte si, že klient právě poslal zprávu "chci si domluvit na sobotu ráno". Co se stane mezi "received" a odpovědí agenta?

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

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

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

1. Validuje podpis webhooku (HMAC proti tajemství WABA).
2. Identifikuje tenant podle telefonního čísla příjemce (multi-tenant podle to_number).
3. Normalizuje payload — audio se stává transkripcí, obrázek se stává popisem, poloha se stává {lat,lng}, text zůstává, jak je.

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

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

Agent potřebuje 3 části kontextu před rozhodnutím:

• Nedávná historie konverzace (posledních N relevantních kol).
• Dlouhodobá paměť klienta (preference, historie nákupů, poznámky).
• Stav agenta (persona, povolené dovednosti, 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 pomocí tenant_id.

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

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

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

Při zprávě "quero marcar pra sábado de manhã" policy engine filtruje:

• Dovednosti kompatibilní s detekovaným záměrem (plánování).
• Dovednosti povolené pro tuto fázi konverzace (ne každá dovednost je dostupná neustále).
• Dovednosti, které tento tenant povolil (kalendář se zobrazí pouze pokud tenant integroval).

Nakonec máte malou podmnožinu dovedností předanou modelu — ne všech 50 možných, pouze 4, které zde dávají smysl. To drasticky snižuje pravděpodobnost, že model vyvolá nesprávnou dovednost.

Fáze 4 — Rozhodnutí (LLM volání, 400-1200ms)

Nyní vstupuje model. OpenClaw provede jediné volání hraničního LLM (Anthropic Claude, OpenAI GPT, Google Gemini — konfigurovatelné podle tenanta) s:

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

Model odpovídá jednou ze dvou věcí:

• Finální odpověď (text přímo pro klienta).
• Tool call (požadavek na provedení konkrétní dovednosti s parametry).

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

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

Fáze 5 — Provedení s ochranami (variabilní, ~100-500ms)

Dovednost 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 dotazovat se na tento kalendář?).
3. Provádí 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], je to přesně to, co jde do dalšího volání. Pokud skill selže, model ví, že selhal. Nulové riziko, že by agent "vymyslel", že má termín v 9h, když ho nemá.

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

Fáze 6 — Odpověď a perzistence (~50ms)

S výsledkem skillu v ruce model provádí druhé volání — nyní k vytvoření finální odpovědi pro klienta. Např.:

"Mám v sobotu v 10h a 11h. Kterou preferujete?"

Paralelně worker:

1. Odesílá zprávu zpět přes WhatsApp API.
2. Ukládá kompletní kolo (user + assistant + tool calls + trvání) do D1.
3. Aktualizuje dlouhodobou paměť, pokud kolo vytvořilo nový fakt (např.: "klient preferuje sobotu").
4. Vysílá událost observability (metrika latence, náklady na tokeny, míra eskalace).

To vše běží paralelně. Perzistence 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ý source-of-truth. Faktická data (cena, čas, jméno) vždy pocházejí ze skillu, nikdy ne pouze z modelu.
2. Dvojitá kontrola citlivých dat. Rezervace je potvrzena s klientem před uložením. Platba je potvrzena před udělením přístupu.
3. Explicitní negativní pravidla. Persona každého agenta zahrnuje "nikdy nevymýšlej X, Y, Z" — model to dodržuje.
4. Fallback na člověka. Když žádný skill nepokrývá otázku, agent říká "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ů (skutečné konverzace ručně zkontrolované), byla míra faktických halucinací pod 0,3 % kol — a téměř všechny případy byly kvůli konfiguraci (tenant zapomněl povolit relevantní skill), ne chybě modelu.

---

Náklady na konverzaci

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