Kako Funkcioni Agente IA Konversacional iz Unutarnje

Kako Funkcioni Agenta za Izučavanje Intelektualne Razumevanja u Realnom Vremenu (Arhitektura OpenClaw)

Kako funkcionira agent za izučavanje intelektualne razumevanja u praksi, turn po turnu? Ovo post otvara crnu kutiju OpenClaw: od trenutka kada se poruka klijenta stigne na WhatsApp do teksta koji agent piše nazad. Bude tehnično. Vrijedi li se za vas ako ste odlučili arhitekturu proizvoda, ako ćete kupiti rješenje i želite procijeniti temelj, ili ako volite znati što se događa iza razgovora.

TL;DR: svaki turn prolazi kroz 6 faza — ingest, rješava kontekst, odabire vještine, odlučuje sljedeću akciju, izvršava s ograničenjima, čuva memoriju. Sve kolo rotira u <sekundi na kraju Cloudflare, bez fiksiranog servera.

---

Zašto arhitektura važna

Agent za izučavanje intelektualne razumevanja koji izgleda kao da funkcionira u demo-u ali se sloma u proizvodnji obično ima jedan od ovih 4 problema:

1. Visoka latentnost — klijent čeka 8 sekundi za odgovor, razgovor umire.
2. Nepokretna alucinacija — agent stvara cijene, vremena, politike.
3. Gubitak konteksta — klijent se vraća nakon 2 dana i agent "zaboravlja" sve.
4. Nedovoljna kontrola troškova — svaki dug razgovor ispunjava prompt i vi plaćate velike iznose u tokenima.

Svi 4 su izbor arhitekture, ne ograničenja modela. OpenClaw je izgrađen da bi se izbjegli 4 — i put za razumijevanje je pogledati kolo jednog turna.

---

Kolo jednog turna (6 faza)

Imajte na umu da je klijent tek poslao poruku "Želim rezervirati za subotu ujutro". Što se događa između "primljen" i odgovora agenta?

Faza 1 — Ingest (edge worker, <ms)

Poruka iz WhatsApp-a stigne putem webhook-a Meta direktno u Cloudflare Worker na najbližem geografski položaju (PoP). U Brazilu, to znači São Paulo ili Rio, latentnost mreže <0ms.

Radnik izvršava tri stvari:

1. Validira potpis webhook-a (HMAC protiv tajne WABA).
2. Identificira tenanta po broju telefona primatelja (multi-tenant po to_number).
3. Normalizira payload — audio pretvara se u transkripciju, slika u opis, lokacija u {lat,lng}, tekst ostaje kao što je.

Na kraju faze 1 imate objekt {tenant_id, conversation_id, user_message} spremnog za sljedeći korak.

Faza 2 — Rješava kontekst (D1 + KV, ~80ms)

Agent mora imati 3 komponente konteksta prije nego što odlučuje:

1. Kontekst razgovora — trenutni razgovor, njegova povijest i trenutni stanje.
2. Kontekst klijenta — informacije o klijentu, kao što su njegova lokacija i preferencije.
3. Kontekst sistema — informacije o sistemu, kao što su njegova stanja i ograničenja.

Svi ovi komponenti su potrebni da bi agent mogao učinkovito odgovoriti na klijentovu poruku.

• Svjedočanstvo nedavnih događaja u razgovoru (posljednja N relevantna razgovorna kola).
• Dugoročna memorija klijenta (preference, povijest kupovine, bilješke).
• Stanje agenata (persona, omogućene vještine, pravila).

Svi dolaze iz D1 (SQLite distribuirani od Cloudflarea). D1 zamjenjuje tradicionalni Postgres/Mongo - bez poslužitelja za upravljanje bazom, pristup u nekoliko milisekundi iz radnog procesa, multi-tenant po tenant_id.

Ključna točka: mi ne preuzimamo cijelu razgovor u prompt. Memory Manager v2 od OpenClawa (opisano u našoj internetskoj dokumentaciji) selektira samo relevantna kola za trenutno kolo (posljednja N + N visoke relevantnosti semantike). To održava predvidljivu cijenu tokena čak i u razgovorima dužim od 100 kola.

Faza 3 - Selekcija vještina (policy engine, ~20ms)

Kada je svaki agenat ima skup vještina koje su dostupne - funkcije koje može pozvati. Primjeri: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Dato je poruka "quero marcar pra sábado de manhã", policy engine filtrira:

• Vještine koje su kompatibilne s detektiranim namjerom (agendiranje).
• Vještine koje su omogućene za ovu fazu razgovora (nije svaka vještina dostupna u svakom trenutku).
• Vještine koje su omogućene za ovog korisnika (calendar će se pojaviti samo ako korisnik je integrirao).

Na kraju imate manji skup vještina koji se šalje modelu - ne 50 mogućih, već samo 4 koji su relevantni. To drastično smanjuje šansu da model pozove pogrešnu vještinu.

Faza 4 - Odluka (LLM poziv, 400-1200ms)

Sada je vrijeme za model. OpenClaw poziva jedan LLM na granici (Anthropic Claude, OpenAI GPT, Google Gemini - konfigurabilan po korisniku) s:

• Sistemski prompt = persona agenata + pravila + dostupne vještine.
• Povijest = kola selektirana u fazi 2.
• Korisnička poruka = trenutna poruka kola.

Model odgovara jednom od dvije stvari:

• Konačni odgovor (tekst direktno korisniku).
• Tool poziv (zahtjev za izvršenje specifične vještine s parametrima).

Primjer "quero marcar pra sábado de manhã", model tipično vraća:

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

Faza 5 - Izvršenje s zaštitnim zidovima (promjenjiva, ~100-500ms)

Vještina ne izvršava se u modelu. Ona izvršava se u našem kodu koji:

...

1. Validira parametri (datum_range ima ispravno format? nalazi se unutar pravila tenant-a?).
2. Provjerava dopuštenje (taj agent ima pravo pristupiti tom kalendaru?).
3. Izvodi poziv (Google Calendar API u ovom slučaju).
4. Vraća rezultat strukturiran modelu.

Zbog čega je to važno? Zbog toga što model nikada ne fabricira rezultat. Ako kalendar vraća [10h, 11h], točno je to što će se poslati na sljedeći poziv. Ako skill propali, model zna da je propao. Nema rizika da agent "stvori" da ima vrijeme u 9 sati kada ga nije.

U slučajevima koji uključuju osjetljive informacije (cijena, rok, ime klijenta), pipeline prisiljava tool call - ne dopušta modelu da odgovori samostalno "po svom znanju". To uklanja klasu alucinacije najčešće u komercijalnim agentima.

Stadijum 6 - Odgovor i trajnost (~50ms)

S rezultatom skill-a u rukama, model izvodi drugi poziv - sada da bi formirao konačni odgovor za klijenta. Na primjer:

"Imam subotu u 10 i 11 satu. Koja preferiraš?"

Paralelno, radnik:

1. Pošalje poruku natrag preko API-a za WhatsApp.
2. Sadrži kompletni turnir (korisnik + asistent + pozivi alata + trajanje) u D1.
3. Ažurira dužu memoriju ako turnir proizvede novo činjenice (npr. "klijent preferira subotu").
4. Izdvaja događaj praizvedljivosti (mjeru latencije, trošak tokena, stopu skaliranja).

Sve to radi u paralelu. Trajanje ne blokira slanje poruke - klijent ne čeka D1.

---

Gdje je odbrana protiv alucinacije

Agent koji alucinira u proizvodnji brzo gubi povjerenje. OpenClaw ima 4 linije odbrane:

1. Forced source of truth. Fakta (cijena, vrijeme, ime) uvijek dolaze iz skill-a, nikada od modela samog.
2. Dvostruka provjera u osjetljivim podacima. Agendamenti su potvrđeni s klijentom prije spremanja. Plaćanje je potvrđeno prije oslobađanja pristupa.
3. Ispisivanje negativnih pravila. Osobina svakog agenta uključuje "nigdje ne stvori X, Y, Z" - model se podređuje.
4. Povlačenje prema čovjeku. Kada nijedan skill ne pokriva pitanje, agent kaže "ostavi me da provjerim s timom" i otvori ticket - ne baciti.

U auditorijama koje smo izvršili u posljednjih 6 mjeseci (stvarne konverzacije pregledane ručno), stopa alucinacije faktičke je bila ispod 0,3% turnira - i gotovo svi slučajevi bili su zbog konfiguracije (tenant je zaboravio omogućiti relevantan skill), ne pogreška modela.

---

Trošak po konverzaciji

Arhitektura dobre je dočimbeća sve dok ne pogledate račun. Pretpostavljajući da svaki turnir izvrši 1-2 pozive LLM + pretraživanja u D1, tipičan trošak za potpunu konverzaciju (10-15 turnira) iznosi:

(Note: I've translated the text while preserving the markdown formatting exactly as requested. I've also left the URLs, code, and HTML tags unchanged.)