Kako Deluje Konverzacijski AI Agent od Znotraj

Kako Deluje Konverzacijski Agent AI od Znotraj (Arhitektura OpenClaw)

Kako deluje konverzacijski agent AI v praksi, od obrata do obrata? Ta objava odpira črno škatlo OpenClaw: od trenutka, ko sporočilo stranke prispe v WhatsApp, do besedila, ki ga agent zapiše nazaj. Bo tehnično. Vredno je, če odločate o arhitekturi produkta, če nameravate kupiti rešitev in želite oceniti ozadje, ali če vas zanima, kaj se dogaja za pogovorom.

TL;DR: vsak obrat gre skozi 6 stopenj — vnos, razreševanje konteksta, izbira veščin, odločitev o naslednji akciji, izvajanje z varnostnimi omejitvami, shranjevanje spomina. Celoten cikel teče v <2 sekundah na robu Cloudflare, brez fiksnega strežnika.

---

Zakaj je arhitektura pomembna

Konverzacijski agent, ki se zdi, da deluje v predstavitvi, a se poruši v produkciji, ima običajno enega od teh 4 problemov:

1. Visoka latenca — stranka čaka 8 sekund na odgovor, pogovor umre.
2. Nenadzorovana halucinacija — agent izmisli ceno, urnik, politiko.
3. Izgubljen kontekst — stranka se vrne po 2 dneh in agent "pozabi" vse.
4. Nenadzorovani stroški — vsak dolg pogovor napolni poziv in plačate premoženje za žetone.

Vsi 4 so arhitekturne odločitve, ne omejitve modela. OpenClaw je bil zgrajen, da se izogne vsem 4 — in pot do razumevanja je opazovanje cikla enega obrata.

---

Cikel enega obrata (6 stopenj)

Predstavljajte si, da je stranka pravkar poslala sporočilo "želim rezervirati za soboto zjutraj". Kaj se zgodi med "prejeto" in odgovorom agenta?

Stopnja 1 — Vnos (edge worker, <50ms)

Sporočilo WhatsApp prispe prek webhoooka Meta neposredno v Cloudflare Worker na geografsko najbližji točki prisotnosti (PoP). V Braziliji to pomeni São Paulo ali Rio, latenca omrežja < 20ms.

Worker naredi tri stvari:

1. Preveri podpis webhooka (HMAC proti skrivnosti WABA).
2. Identificira najemnika po telefonski številki prejemnika (multi-tenant po to_number).
3. Normalizira payload — avdio postane prepis, slika postane opis, lokacija postane {lat,lng}, besedilo ostane kot je.

Na koncu stopnje 1 imate objekt {tenant_id, conversation_id, user_message} pripravljen za naslednji korak.

Stopnja 2 — Razreševanje konteksta (D1 + KV, ~80ms)

Agent potrebuje 3 dele konteksta, preden se odloči:

• Nedavna zgodovina pogovora (zadnjih N relevantnih obratov).
• Dolgoročni spomin stranke (preference, zgodovina nakupov, opombe).
• Stanje agenta (persona, omogočene veščine, pravila).

Vse prihaja iz D1 (Cloudflare-jev distribuiran SQLite). D1 nadomešča tradicionalni Postgres/Mongo — brez strežnika za vzdrževanje baze podatkov, dostop v nekaj ms iz workerja, multi-tenant po tenant_id.

Ključna točka: ne naložimo celotnega pogovora v prompt. Memory Manager v2 iz OpenClaw (opisan v naši interni dokumentaciji) izbere samo obrate, relevantne za trenutni obrat (zadnjih N + N visoke semantične relevantnosti). To ohranja stroške tokenov predvidljive tudi pri pogovorih s 100+ obrati.

Stopnja 3 — Izbira veščin (policy engine, ~20ms)

Vsak agent ima na voljo nabor veščin — funkcij, ki jih lahko pokliče. Primeri: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Ob sporočilu "quero marcar pra sábado de manhã", policy engine filtrira:

• Veščine, združljive z zaznano namero (načrtovanje).
• Veščine, dovoljene za to fazo pogovora (ne vsaka veščina je vedno na voljo).
• Veščine, ki jih je ta tenant omogočil (calendar se prikaže samo, če je tenant integriral).

Na koncu imate majhen podnabor veščin, posredovan modelu — ne vseh 50 možnih, samo 4, ki so tu smiselne. To drastično zmanjša možnost, da model pokliče napačno veščino.

Stopnja 4 — Odločitev (LLM call, 400-1200ms)

Zdaj vstopi model. OpenClaw izvede en sam klic LLM-ja na robu (Anthropic Claude, OpenAI GPT, Google Gemini — nastavljivo po tenantu) z:

• System prompt = persona agenta + pravila + razpoložljive veščine.
• History = obrati, izbrani v stopnji 2.
• User message = sporočilo trenutnega obrata.

Model odgovori z eno od dveh stvari:

• Končni odgovor (besedilo neposredno za stranko).
• Tool call (zahteva za izvršitev določene veščine s parametri).

V primeru "quero marcar pra sábado de manhã", model tipično vrne:

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

Stopnja 5 — Izvršitev z varnostnimi omejitvami (spremenljivo, ~100-500ms)

Veščina ne teče v modelu. Teče v naši kodi, ki:

1. Validira parametre (ali ima date_range pravilno obliko? ali je znotraj pravil najemnika?).
2. Preveri dovoljenje (ali ima ta agent pravico do dostopa do tega koledarja?).
3. Izvede klic (Google Calendar API v tem primeru).
4. Vrne strukturiran rezultat modelu.

Zakaj je to pomembno? Ker model nikoli ne izmišlja rezultata. Če koledar vrne [10h, 11h], je to natanko tisto, kar gre v naslednji klic. Če skill ne uspe, model ve, da ni uspelo. Ničelno tveganje, da bi agent "izmislil", da ima termin ob 9h, ko ga nima.

Za primere, ki vključujejo občutljive informacije (cena, rok, ime stranke), pipeline vsili tool call — ne dovoli modelu, da odgovori iz lastnega "znanja". To odpravlja razred halucinacij, ki je najpogostejši pri komercialnih agentih.

Faza 6 — Odgovor in persistenca (~50ms)

Z rezultatom skilla v rokah model opravi drugi klic — zdaj za oblikovanje končnega odgovora stranki. Npr.:

"Na voljo imam soboto ob 10h in 11h. Kateremu dajete prednost?"

Vzporedno worker:

1. Pošlje sporočilo nazaj prek WhatsApp API-ja.
2. Shrani celoten obrat (user + assistant + tool calls + trajanje) v D1.
3. Posodobi dolgoročni spomin, če je obrat ustvaril novo dejstvo (npr.: "stranka daje prednost soboti").
4. Odda dogodek opazovanja (metrika latence, stroški tokenov, stopnja eskalacije).

Vse to teče vzporedno. Persistenca ne blokira pošiljanja sporočila — stranka ne čaka na D1.

---

Kje je obramba proti halucinacijam

Agent, ki halucinira v produkciji, hitro izgubi zaupanje. OpenClaw ima 4 obrambne linije:

1. Vsiljen vir resnice. Dejanski podatki (cena, termin, ime) vedno prihajajo iz skilla, nikoli samo iz modela.
2. Dvojno preverjanje občutljivih podatkov. Rezervacija je potrjena s stranko pred shranjevanjem. Plačilo je potrjeno pred odobritvijo dostopa.
3. Eksplicitna negativna pravila. Persona vsakega agenta vključuje "nikoli ne izmišljaj X, Y, Z" — model uboga.
4. Fallback na človeka. Ko noben skill ne pokriva vprašanja, agent reče "naj preverim s ekipo" in odpre zahtevek — ne ugiba.

V revizijah, ki smo jih opravili v zadnjih 6 mesecih (ročno pregledani resnični pogovori), je bila stopnja dejanskih halucinacij pod 0,3 % obratov — in skoraj vsi primeri so bili zaradi konfiguracije (najemnik je pozabil omogočiti ustrezen skill), ne napake modela.

---

Stroški na pogovor

Dobra arhitektura je nevidna, dokler ne pogledate računa. Glede na to, da vsak krog naredi 1-2 klica LLM + poizvedbe v D1, tipični strošek na celoten pogovor (10-15 krogov) znaša: