Kuidas vestlusliku AI-agendi sisemus töötab

Kuidas Vestluslik Tehisintellekti Agent Seestpoolt Töötab (OpenClaw Arhitektuur)

Kuidas vestluslik tehisintellekti agent praktikas töötab, voor voorult? See postitus avab OpenClaw musta kasti: hetkest, mil kliendi sõnum WhatsAppi jõuab, kuni tekstini, mille agent vastuseks kirjutab. See saab olema tehniline. Tasub lugeda, kui otsustate tootearhitektuuri üle, kui kavatsete lahendust osta ja soovite seda põhjalikult hinnata, või kui teile lihtsalt meeldib teada, mis vestluse taga toimub.

TL;DR: iga voor läbib 6 etappi — vastuvõtt, konteksti lahendamine, oskuste valimine, järgmise tegevuse otsustamine, täitmine koos kaitsepiirangutega, mälu salvestamine. Kogu tsükkel töötab <2 sekundiga Cloudflare'i edge'il, ilma fikseeritud serverita.

---

Miks arhitektuur on oluline

Vestlusagent, mis näib demos töötavat, kuid tootmises puruneb, omab tavaliselt ühte neist 4 probleemist:

1. Kõrge latentsus — klient ootab vastust 8 sekundit, vestlus sureb.
2. Kontrollimatu hallutsinatsioon — agent leiutab hinna, kellaaja, poliitika.
3. Kadunud kontekst — klient tuleb 2 päeva pärast tagasi ja agent "unustab" kõik.
4. Kontrollimatud kulud — iga pikk vestlus täidab prompti ja maksate tokenite eest varanduse.

Kõik 4 on arhitektuurivalikud, mitte mudeli piirangud. OpenClaw ehitati kõigi 4 vältimiseks — ja selle mõistmiseks tuleb vaadata ühe vooru tsüklit.

---

Ühe vooru tsükkel (6 etappi)

Kujutage ette, et klient saatis just sõnumi "tahan aja broneerida laupäeva hommikuks". Mis toimub "vastu võetud" ja agendi vastuse vahel?

Etapp 1 — Vastuvõtt (edge worker, <50ms)

WhatsAppi sõnum jõuab Meta webhooki kaudu otse Cloudflare Workerisse geograafiliselt lähimas kohalolekupunktis (PoP). Brasiilias tähendab see São Paulot või Riot, võrgu latentsus < 20ms.

Worker teeb kolm asja:

1. Valideerib webhooki allkirja (HMAC WABA saladuse vastu).
2. Tuvastab tenandi vastuvõtja telefoninumbri järgi (multi-tenant to_number alusel).
3. Normaliseerib sisu — heli muudetakse transkriptsiooniks, pilt kirjelduseks, asukoht muudetakse {lat,lng} kujule, tekst jääb nagu on.

Etapi 1 lõpus on teil objekt {tenant_id, conversation_id, user_message}, mis on järgmiseks sammuks valmis.

Etapp 2 — Konteksti lahendamine (D1 + KV, ~80ms)

Agent vajab enne otsustamist 3 kontekstitükki:

• Hiljutine ajalugu vestlusest (viimased N asjakohast vooru).
• Pikaajaline mälu kliendi kohta (eelistused, ostuajalugu, märkmed).
• Agendi olek (persona, lubatud oskused, reeglid).

Kõik pärinevad D1-st (Cloudflare'i hajutatud SQLite). D1 asendab traditsioonilist Postgres/Mongo — pole vaja andmebaasiserverit hallata, juurdepääs mõne ms-ga workerist, multi-tenant tenant_id alusel.

Võtmepunkt: me ei laadi kogu vestlust prompti. OpenClaw Memory Manager v2 (kirjeldatud meie sisemises dokumentatsioonis) valib ainult praeguse vooru jaoks asjakohased voorud (viimased N + N semantiliselt kõrge asjakohasusega). See hoiab tokenikulu prognoositavana isegi 100+ vooruga vestlustes.

Etapp 3 — Oskuste valik (policy engine, ~20ms)

Igal agendil on saadaval oskuste komplekt — funktsioonid, mida ta saab käivitada. Näited: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Sõnumi "quero marcar pra sábado de manhã" korral filtreerib policy engine:

• Oskused, mis sobivad tuvastatud kavatsusega (ajakava).
• Oskused, mis on lubatud selles vestluse faasis (mitte kõik oskused pole kogu aeg saadaval).
• Oskused, mille see tenant on lubanud (kalender ilmub ainult siis, kui tenant on selle integreerinud).

Lõpuks on teil väike oskuste alamhulk, mis edastatakse mudelile — mitte 50 võimalikku, vaid ainult 4, mis siin mõtet omavad. See vähendab drastiliselt tõenäosust, et mudel käivitab vale oskuse.

Etapp 4 — Otsus (LLM-i väljakutse, 400-1200ms)

Nüüd astub mudel mängu. OpenClaw teeb ühe väljakutse piiri-LLM-ile (Anthropic Claude, OpenAI GPT, Google Gemini — tenanti kaupa konfigureeritav) järgmisega:

• System prompt = agendi persona + reeglid + saadaolevad oskused.
• History = etapis 2 valitud voorud.
• User message = praeguse vooru sõnum.

Mudel vastab ühega kahest:

• Lõplik vastus (otsetekst kliendile).
• Tool call (päring konkreetse oskuse käivitamiseks parameetritega).

Näite "quero marcar pra sábado de manhã" puhul tagastab mudel tavaliselt:

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

Etapp 5 — Käivitamine kaitsepiirangutega (muutuv, ~100-500ms)

Oskus ei käivitu mudelis. See käivitub meie koodis, mis:

1. Valideerib parameetrid (kas date_range on õiges formaadis? kas see on rentniku reeglite piires?).
2. Kontrollib õigusi (kas sellel agendil on õigus seda kalendrit pärida?).
3. Teostab päringu (antud juhul Google Calendar API).
4. Tagastab struktureeritud tulemuse mudelile.

Miks see on oluline? Sest mudel ei fabritseeri kunagi tulemust. Kui kalender tagastab [10h, 11h], siis täpselt see läheb järgmisesse päringukutsesse. Kui oskus ebaõnnestub, teab mudel, et see ebaõnnestus. Null riski, et agent "mõtleb välja", et kell 9 on aeg vaba, kui seda pole.

Juhtudel, mis hõlmavad tundlikku teavet (hind, tähtaeg, kliendi nimi), sunnib pipeline kasutama tool call — ei lase mudelil vastata oma "teadmiste" põhjal. See kõrvaldab hallutsinatsioonide klassi, mis on kõige levinum kaubandusagentide puhul.

Etapp 6 — Vastus ja salvestamine (~50ms)

Kui oskuse tulemus on käes, teeb mudel teise päringu — seekord lõpliku vastuse vormistamiseks kliendile. Nt:

"Mul on laupäeval kell 10 ja 11 vabad. Kumba eelistate?"

Samal ajal worker:

1. Saadab sõnumi tagasi WhatsAppi API kaudu.
2. Salvestab täieliku vooru (user + assistant + tool calls + kestus) D1-sse.
3. Uuendab pikaajalise mälu, kui voor tootis uue fakti (nt: "klient eelistab laupäeva").
4. Saadab jälgitavuse sündmuse (latentsuse mõõdik, tokeni kulu, eskalatsiooni määr).

Kõik see töötab paralleelselt. Salvestamine ei blokeeri sõnumi saatmist — klient ei oota D1 järel.

---

Kus on kaitse hallutsinatsioonide vastu

Agent, mis hallutsineerib tootmiskeskkonnas, kaotab usalduse kiiresti. OpenClaw'il on 4 kaitseliini:

1. Sunditud tõeallikas. Faktilised andmed (hind, kellaaeg, nimi) tulevad alati oskusest, mitte kunagi mudelist üksi.
2. Topeltkontroll tundlike andmete puhul. Broneering kinnitatakse kliendiga enne salvestamist. Makse kinnitatakse enne juurdepääsu avamist.
3. Selgesõnalised keelud. Iga agendi persona sisaldab "ära kunagi mõtle välja X, Y, Z" — mudel kuuletub.
4. Tagavaraks inimene. Kui ükski oskus ei kata küsimust, ütleb agent "lubage mul meeskonnaga kontrollida" ja avab pileti — ei paku oletusi.

Viimase 6 kuu jooksul tehtud auditites (käsitsi üle vaadatud reaalsed vestlused) jäi faktiline hallutsinatsioonimäär alla 0,3% voorudest — ja peaaegu kõik juhtumid olid seadistusest tingitud (rentnik unustas asjakohase oskuse aktiveerida), mitte mudeli veast.

---

Kulu vestluse kohta

Hea arhitektuur on nähtamatu, kuni vaatate arvet. Arvestades, et iga voor teeb 1-2 LLM-i kutset + D1 päringut, on tüüpiline kulu täieliku vestluse kohta (10-15 vooru):