Kā Darbojas Sarunvalodas AI Agents no Iekašienes

Kā Darbojas Sarunvalodas AI Aģents Iekšpusē (OpenClaw Arhitektūra)

Kā darbojas sarunvalodas AI aģents praksē, solis pa solim? Šis ieraksts atver OpenClaw melno kasti: no brīža, kad klienta ziņojums saņemts WhatsApp, līdz tekstam, ko aģents raksta atpakaļ. Tas būs tehnisks. Tas ir vērts, ja jūs pieņemat lēmumus par produkta arhitektūru, ja plānojat iegādāties risinājumu un vēlaties novērtēt dziļāk, vai ja jums patīk zināt, kas notiek aiz sarunas.

TL;DR: katrs solis iziet cauri 6 posmiem — uzņemšana, konteksta atrisināšana, prasmju atlase, nākamās darbības lēmums, izpilde ar drošības sliežu palīdzību, atmiņas saglabāšana. Viss cikls darbojas <2 sekundēs Cloudflare malā, bez fiksēta servera.

---

Kāpēc arhitektūra ir svarīga

Sarunvalodas aģents, kas šķiet darbojas demonstrācijā, bet salūzt ražošanā, parasti ir viena no šīm 4 problēmām:

1. Augsta latentums — klients gaida 8 sekundes uz atbildi, saruna iet bojā.
2. Nekontrolētas halucinācijas — aģents izdomā cenu, laiku, politiku.
3. Zaudēts konteksts — klients atgriežas pēc 2 dienām un aģents "aizmirst" visu.
4. Nekontrolētas izmaksas — katra gara saruna piepilda uzvedni un jūs maksājat milzīgu summu par tokenem.

Visas 4 ir arhitektūras izvēles, nevis modeļa ierobežojumi. OpenClaw tika izveidots, lai izvairītos no visām 4 — un ceļš, lai to saprastu, ir apskatīt soļa ciklu.

---

Soļa cikls (6 posmi)

Iedomājieties, ka klients tikko nosūtīja ziņojumu "gribu rezervēt sestdienai no rīta". Kas notiek starp "saņemts" un aģenta atbildi?

1. posms — Uzņemšana (edge worker, <50ms)

WhatsApp ziņojums ierodas caur Meta webhook tieši Cloudflare Worker tuvākajā ģeogrāfiskajā klātbūtnes punktā (PoP). Brazīlijā tas nozīmē Sanpaulu vai Rio, tīkla latentums < 20ms.

Worker veic trīs lietas:

1. Validē parakstu webhook (HMAC pret WABA noslēpumu).

2. Identificē nomnieku pēc saņēmēja tālruņa numura (multi-tenant pēc to_number).

3. Normalizē slodzi — audio kļūst par transkripciju, attēls par aprakstu, atrašanās vieta par {lat,lng}, teksts paliek kā ir.

4. posma beigās jums ir objekts {tenant_id, conversation_id, user_message} gatavs nākamajam solim.

2. posms — Konteksta atrisināšana (D1 + KV, ~80ms)

Aģentam ir nepieciešamas 3 konteksta daļas pirms lēmuma pieņemšanas:

• Nesenie sarunu vēsture (pēdējie N atbilstošie gājieni).
• Klienta ilgtermiņa atmiņa (preferences, pirkumu vēsture, piezīmes).
• Aģenta stāvoklis (persona, iespējotas prasmes, noteikumi).

Visi nāk no D1 (Cloudflare izplatītā SQLite). D1 aizstāj tradicionālo Postgres/Mongo — nav jāuztur datu bāzes serveris, piekļuve dažu ms laikā no workera, multi-tenant ar tenant_id.

Galvenais punkts: mēs neielādējam visu sarunu promptā. OpenClaw Memory Manager v2 (aprakstīts mūsu iekšējā dokumentācijā) atlasa tikai pašreizējam gājienam atbilstošos gājienus (pēdējie N + N ar augstu semantisko atbilstību). Tas saglabā token izmaksas paredzamas pat 100+ gājienu sarunās.

3. posms — Prasmju atlase (policy engine, ~20ms)

Katram aģentam ir pieejamu prasmju kopums — funkcijas, ko tas var izsaukt. Piemēri: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Ņemot vērā ziņojumu "quero marcar pra sábado de manhã", policy engine filtrē:

• Prasmes, kas saderīgas ar noteikto nodomu (plānošana).
• Prasmes, kas atļautas šajā sarunas fāzē (ne visas prasmes ir pieejamas visu laiku).
• Prasmes, ko šis tenants ir iespējojis (calendar parādās tikai, ja tenants ir integrējis).

Beigās jums ir neliela prasmju apakškopa, kas nodota modelim — ne visas 50 iespējamās, tikai 4, kas šeit ir jēgpilnas. Tas dramatiski samazina iespēju, ka modelis izsauks nepareizu prasmi.

4. posms — Lēmums (LLM call, 400-1200ms)

Tagad iesaistās modelis. OpenClaw veic vienu izsaukumu uz robežas LLM (Anthropic Claude, OpenAI GPT, Google Gemini — konfigurējams pēc tenanta) ar:

• System prompt = aģenta persona + noteikumi + pieejamās prasmes.
• History = 2. posmā atlasītie gājieni.
• User message = pašreizējā gājiena ziņojums.

Modelis atbild ar vienu no divām lietām:

• Galīgā atbilde (tiešs teksts klientam).
• Tool call (pieprasījums izpildīt konkrētu prasmi ar parametriem).

Piemērā "quero marcar pra sábado de manhã", modelis parasti atgriež:

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

5. posms — Izpilde ar guard-rails (mainīgs, ~100-500ms)

Prasme nedarbojas modelī. Tā darbojas mūsu kodā, kas:

1. Validē parametrus (vai date_range ir pareizā formātā? vai tas atbilst nomnieka noteikumiem?).
2. Pārbauda atļauju (vai šim aģentam ir tiesības piekļūt šim kalendāram?).
3. Izpilda izsaukumu (šajā gadījumā Google Calendar API).
4. Atgriež strukturētu rezultātu modelim.

Kāpēc tas ir svarīgi? Jo modelis nekad neizdomā rezultātu. Ja kalendārs atgriež [10h, 11h], tieši tas tiek nodots nākamajam izsaukumam. Ja prasme neizdodas, modelis zina, ka tā neizdevās. Nulles risks, ka aģents "izdomās", ka ir laiks plkst. 9, kad tā nav.

Gadījumos, kas ietver sensitīvu informāciju (cena, termiņš, klienta vārds), konveijers forsē tool call — neļauj modelim atbildēt no savas "zināšanas". Tas novērš halucināciju klasi, kas ir visbiežākā komerciālajos aģentos.

6. posms — Atbilde un saglabāšana (~50ms)

Ar prasmes rezultātu rokās modelis veic otro izsaukumu — tagad, lai veidotu galīgo atbildi klientam. Piemēram:

"Man ir sestdiena plkst. 10 un 11. Kuru vēlaties?"

Paralēli workers:

1. Nosūta ziņojumu atpakaļ caur WhatsApp API.
2. Saglabā pilnu apgriezienu (user + assistant + tool calls + ilgums) D1.
3. Atjaunina ilgtermiņa atmiņu, ja apgrieziens radīja jaunu faktu (piemēram: "klients dod priekšroku sestdienai").
4. Izstaro novērojamības notikumu (latentuma metrika, tokenu izmaksas, eskalācijas līmenis).

Viss tas darbojas paralēli. Saglabāšana nebloķē ziņojuma nosūtīšanu — klients negaida D1.

---

Kur ir aizsardzība pret halucināciju

Aģents, kas halucinē ražošanā, ātri zaudē uzticību. OpenClaw ir 4 aizsardzības līnijas:

1. Piespiedu patiesības avots. Faktiski dati (cena, laiks, vārds) vienmēr nāk no prasmes, nekad tikai no modeļa.
2. Dubulta pārbaude sensitīviem datiem. Rezervācija tiek apstiprināta ar klientu pirms saglabāšanas. Maksājums tiek apstiprināts pirms piekļuves atbrīvošanas.
3. Skaidri negatīvi noteikumi. Katra aģenta persona ietver "nekad neizdomā X, Y, Z" — modelis paklausa.
4. Pāreja uz cilvēku. Kad neviena prasme nesedz jautājumu, aģents saka "ļauj man pārbaudīt ar komandu" un atver pieteikumu — nemin.

Auditos, ko veicām pēdējo 6 mēnešu laikā (reālas sarunas pārskatītas manuāli), faktiskās halucinācijas līmenis bija zem 0,3% no apgriezieniem — un gandrīz visi gadījumi bija konfigurācijas dēļ (nomnieks aizmirsa iespējot atbilstošu prasmi), nevis modeļa kļūda.

---

Izmaksas par sarunu

Laba arhitektūra ir neredzama, līdz jūs paskatāties uz rēķinu. Ņemot vērā, ka katrs gājiens veic 1-2 LLM izsaukumus + D1 meklējumus, tipiskās izmaksas par pilnu sarunu (10-15 gājieni) ir: