Kako Funkcioni Um Agenta IA Konversacional Po Dentru

Kako Deluje Agent Ia Konversacijski V Notranjosti (Arhitektura OpenClaw)

Kako deluje agent Ia konversacijski v praksi, turn po turnu? Ta članek odpre črno kopico OpenClaw: od trenutka, ko se sporočila stranke prikaže na WhatsApp do besed, ki jih agent napiše nazaj. Bodo tehnični. Vredno je, če se odločite za arhitekturo proizvoda, če boste kupili rešitev in želite oceniti temelj ali če se zanima, kaj se dogaja za ozadja konversacije.

TL;DR: vsak turn se izvaja v 6 stopnjah — vstavljanje, reševanje konteksta, izbira zmožnosti, odločitev za naslednjo dejanje, izvedba z varnostnimi ovirami, shranjevanje spomina. Vse cikel obratuje na <sekund v robovih Cloudflare, brez fiksne strežnike.

---

Kaj pomeni arhitektura

Konversacijski agent, ki deluje v demo, a se razboli v proizvodnji, običajno ima enega izmed 4 problemov:

1. Visoka latenca — stranka čaka 8 sekund za odgovor, konverzacija umre.
2. Nepredvidljiva alucinacija — agent izmišlja ceno, čas, politiko.
3. Izgubljeno vedenje — stranka se vrne po 2 dneh in agent "zapomni" vse.
4. Nedržljiva cena — vsaka dolga konverzacija napolni prompt in se plača veliko v tokenih.

4 so izbire arhitekture, ne omejitve modela. OpenClaw je bil zgrajen, da bi preprečil 4 — in pot za razumevanje je pogledati cikel enega turna.

---

Cikel enega turna (6 stopnji)

Predstavitve, da je stranka samo poslala sporočilo "Želim rezervirati za soboto zjutraj". Kaj se dogaja med "prejeto" in odgovorom agenta?

Stopnja 1 — Vstavljanje (robovski delavec, <ms)

Sporočilo iz WhatsApp prikaže prek webhooka Meta direktno v robovski delavec Cloudflare na najbližji geografski točki prisotnosti (PoP). V Braziliji pomeni to São Paulo ali Rio, latenca v mreži <0ms.

Delavec izvaja tri stvari:

1. Validira podpis webhooka (HMAC proti skrivnostjo WABA).
2. Identificira podjetje po številki telefona prejemnika (multi-podjetje po to_number).
3. Normalizira payload — zvok se pretvori v transkripcijo, slika se pretvori v opis, lokacija se pretvori v {lat,lng}, tekst ostane kot je.

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

• Zgodovina zadnjih N sprememb (zadnjih N relevantnih sprememb).
• Dolgoročna spominska baza stranke (preference, zgodovina nakupov, zapiske).
• Stanje agenta (persona, omrežene zmožnosti, pravila).

Vsi prihajajo iz D1 (razporejen SQLite Cloudflare). D1 nadomešča tradicionalno Postgres/Mongo - brez strežnika za bazo, dostop v nekaj ms iz delavca, multi-tenant po tenant_id.

Ključna točka: ne prenašamo celotne zgodovine v spremembe. Memory Manager v2 OpenClaw (opisano v naših notranjih dokumentih) izbere samo relevantne spremembe za trenutni spremembi (zadnjih N + N visoko relevantne semantične). To vzdržuje predvidljiv strošek tokenov tudi pri spremembah več kot 100.

Stopnja 3 - Izbor zmožnosti (policy engine, ~20ms)

Vsak agent ima na voljo zmožnosti - funkcije, ki jih lahko pokliče. Primeri: consultar_calendario, crearevento, gerarlinkpagamento, consultarpedido, chamahumano.

Dana sprememba "quero marcar pra sábado de manhã", policy engine filtri:

• Zmožnosti, ki so kompatibilne z detektirano namero (agendiranje).
• Zmožnosti, ki so dovoljene za to fazo spremembe (ne vse zmožnosti so vedno na voljo).
• Zmožnosti, ki so omrežene za ta tenant (calendar se pojavi samo, če je tenant integriral).

Na koncu ste prejeli majhen podmnožico zmožnosti, ki so prenesene v model - ne 50, ampak samo 4, ki so tu, kjer jih potrebujete. To drastično zmanjša možnost, da model pokliče zmožnost napačno.

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

Sedaj se model vključi. OpenClaw izvede enkratni klic na LLM na robu (Anthropic Claude, OpenAI GPT, Google Gemini - nastavljiv po strankah) z:

• Sistemski prompt = persona agenta + pravila + zmožnosti, ki so na voljo.
• Zgodovina = izbrane spremembe v stopnji 2.
• Uporabniški sporočilo = trenutna sprememba.

Model odgovori enega izmed dveh stvari:

• Konecno odgovor (tekst neposredno stranki).
• Tool klic (zahtevek za izvedbo specifične zmožnosti z parametrimi).

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

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

Stopnja 5 - Izvedba z varnostnimi ovirami (različna, ~100-500ms)

Zmožnost ne izvede model. Izvede se v našem kodu, ki:

Translated markdown (sl-SI) ends here.

1. Prever parametre (je lah datumsko obdobje v pravilnem formatu? Je v skladu z pravili poslodovca?).
2. Prever dovoljenje (ta agent ima dovoljenje za pregled tega koledarja?).
3. Izvedi klic (Google Calendar API v tem primeru).
4. Pridi rezultat strukturiran modelu.

Zakaj je to pomembno? Ker model nikoli ne ustvari rezultat. Če koledar vrne [10h, 11h], je to pravzaprav tisto, kar bo prešlo v naslednjo klic. Če je bila skilja neuspešna, model ve, da je bila neuspešna. Ni mize za to, da bi agent "izumil", da ima čas na 9h, če ga ni.

V primerih, ki vključujejo občutljive informacije (cena, rok, ime stranke), se je pipeline prisilil tool call - ni dovolilo modelu, da bi odgovarjal iz lastnega "znanja". To izbriše najpogostejšo vrsto iluzije v komercialnih agentih.

Stopnja 6 - Odgovor in vzdrževanje (~50ms)

Z rezultatom skilje v rokah, model izvede drug klic - zdaj za oblikovanje končnega odgovora za stranko. Na primer:

"Imam soboto ob 10h in 11h. Katero si izbral?"

Paralelno z tem se delavec:

1. Pošlje sporočilo nazaj po API-ju za WhatsApp.
2. Vzdrži celoten turn (uporabnik + asistent + klici orodja + trajanje) v D1.
3. Posodobi dolgoročno spomin če je turn ustvaril novo dejstvo (npr. "stranka izbere soboto").
4. Izda dogodek za opazovanje (merilo za zgodovje, strošek za token, stopnja širjenja).

Vse to teče v paralelni načrtovanju. Vzdrževanje ne zadrži pošiljanje sporočila - stranka ne čaka D1.

---

Kje je obramba proti iluziji

Agent, ki iluzije v proizvodnji, izgubi zanesljivost hitro. OpenClaw ima 4 vrste obrambe:

1. Vir resnice prisiljen. Fakta (cena, čas, ime) vselej prihajajo iz skilje, nikoli samo iz modela.
2. Dvojna preverjanje v občutljivih podatkih. Dogodki se potrdijo z uporabnikom pred vzdrževanjem. Plačilo se potrdi pred osvoboditvijo dostopa.
3. Izrazite negativne pravil. Persona vsakega agenta vključuje "nikoli izmišljaj X, Y, Z" - model se zanaša.
4. Povrat v človeka. Ko nobena skilja ne pokriva vprašanja, agent reče "dejavaj, da preverim z mojim timom" in odpre ticket - ne zanemari.

V auditih, ki smo jih opravili v zadnjih 6 mesecih (stvarne razprave, preverjene ročno), je stopnja iluzije faktov ostala pod 0,3% turnov - in skoraj vse primeri so bili zaradi konfiguracije (poslodovca je pozabil aktivirati relevantno skiljo), ne napake modela.

Arhitektura dobre arhitektura je nevidna, dokler se ne ogledete račun. Zato, ker vsak obrat izvaja 1-2 klicov LLM + iskanja v D1, je tipična cena za celoten dialog (10-15 obratov) v tem:

• 1-2 klici LLM + iskanja v D1 za vsak obrat
• 10-15 obratov v celotnem dialogu
• Celotna cena za dialog je torej: 10-15 obratov × (1-2 klici LLM + iskanja v D1/obrat)