Kā Funkciona Agents IA Konversacionāls no Iekšas

Kā Funkcionē Konversācijas Agents ar Iekšēju Iekārtu (Arhitektūra OpenClaw)

Kā funkcionē konversācijas agents praktiski, gājieni pa gājieni? Šis raksts atvērs "caurbules" OpenClaw: no brīža, kad klienta ziņa ierodas WhatsApp līdz teksta, ko agents raksta atpakaļ. Būs tehniski. Vērtīgs, ja jūs izvēlētos produktu arhitektūru, vai vēlaties iegādāties risinājumu un vēlaties izvērtēt pamatu, vai jūs patīk zināt, kas notiek konversācijas laikā.

TL;DR: katrs gājiena posms ir 6 posmu cikls — iegūt, risināt kontekstu, izvēlēties kompetences, nākamās darbības, izpildīt ar aizsargām, saglabāt atmiņu. Visu ciklu veic <sekundes Cloudflare edge, bez fixa servera.

---

Kā arhitektūra ir nozīmīga

Konversācijas agents, kas izskatās darbojas demonstrācijā, bet sabrūk produkcijā, parasti ir viens no šiem 4 problemiem:

1. Augsta laikgaita — klienta vēlas 8 sekundes, lai saņemtu atbildi, konversācija mirs.
2. Nepārtraukta fantāzija — agents izdomā cenu, laiku, politiku.
3. Zudis konteksts — klienta atgriežas pēc 2 dienām un agents "nokļūst no memoriām".
4. Nepārtraukts izmaksu pieaugums — katra garā konversācija aizpilda ievadi un jūs maksājat lielu summu tokeniem.

Visi 4 ir izvēles arhitektūras, nevis ierobežojumi modelim. OpenClaw tika izveidots, lai izvairītos no 4 — un ceļš, lai to saprastu, ir skatīt ciklu viena gājiena posma.

---

Cikls viena gājiena posma (6 posmu)

Ievadīsim, ka klienta pēdējā ziņa bija "mani interesa sestdien rīt". Kā notiek starp "iegūti" un agentsa atbildi?

Posms 1 — Iegūt (edge worker, <ms)

Ziņa no WhatsApp ierodas webhook no Meta direkti Cloudflare Worker uz punktu presences (PoP) tuvākā geogrāfiski. Latīņamerikā tas nozīmē São Paulo vai Rio, laikgaita <0ms.

Worker veic trīs lietas:

1. Validē ziņas parakstu (HMAC pret WABA sekretu).
2. Identificē klientu pēc saņemtā numura (multi-tenant pēc to_number).
3. Normalizē ziņas — audio kļūst par transkripciju, attēls kļūst par aprakstu, vieta kļūst par {lat,lng}, teksts paliek kā ir.

Posma 1 beigās jūs ir objektu {tenant_id, conversation_id, user_message} gatavu nākamajam posmam.

• Jaunākais vēstures laiks (pēdējie N svarīgie posmi, kas ir nozīmīgi).
• Garīgā atmiņa klientam (preference, iepirkumu vēsture, norādes).
• Agenta stāvoklis (persona, iespējotās kompetences, noteikumi).

Visi tiek saņemti no D1 (Cloudflare distribūtā SQLite). D1 aizstāj tradicionālo Postgres/Mongo bez servera, lai nodrošinātu piekļuvi no darbinieka, multi-tenant ar tenant_id.

Svarīgais punkts: mēs nepārbaudām visu konversāciju. Atmiņas pārvaldītājs 2 no OpenClaw (apskatīts mūsu internās dokumentācijā) atlasīs tikai svarīgākos posmus, kas ir nozīmīgi šobrīd (pēdējie N + N ar augstu semantisko nozīmību). Tādā veidā tiek nodrošināta nepārtraukta tokena izmaksas prognoze, pat ja konversācija ir vairāk nekā 100 posmiem.

Posms 3 — Kompetences izvēle (policy engine, ~20ms)

Katrais agents ir pieejamas kompetences — funkcijas, ko tas var izsaukt. Piemēri: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Ja saņemtais ziņojums ir "quero marcar pra sábado de manhã", policy engine filtrē:

• Kompetences, kas ir kompatiblas ar atklāto mērķi (agendēšana).
• Kompetences, kas ir pieejamas šajā konversācijas posmā (nav visas kompetences ir pieejamas visu laiku).
• Kompetences, kas ir pieejamas šim tenantam (kalendārs parādīsies tikai tad, ja tenant ir integrējis to).

Pēc tam tiek atlasīts mazs kompetences saraksts, kas tiek pārsūtīts uz modeli — ne visu 50 iespējamo, bet tikai 4, kas ir nozīmīgi šobrīd. Tādā veidā tiek samazināta iespēja, ka modelis izsauks nepareizu kompetenci.

Posms 4 — Lēmums (LLM saukšana, 400-1200ms)

Tagad modelis tiek saucis. OpenClaw sauc vienu reizi uz frontēra LLM (Anthropic Claude, OpenAI GPT, Google Gemini — konfigurējams tenantam) ar:

• Sistēmas aicinājumu = agents persona + noteikumi + pieejamās kompetences.
• Vēsturi = atlasītie posmi no posma 2.
• Lietotāja ziņojumu = šobrīdējā posma ziņojums.

Modelis atbild vienu no diviem:

• Finālā atbilde (teksts tieši klientam).
• Tools saukšana (prasība izpildīt konkrētu kompetenci ar parametriem).

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

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

Posms 5 — Izpildīšana ar guard-rails (daudzveidīgs, ~100-500ms)

Kompetence nepārbaudās modelī. Tā tiek izpildīta mūsu koda, kas:

...

1. Validē parametri (datu rīkija ir pareizs formāts? atbilst klienta noteikumiem?).
2. Pārbauda atļauju (šis agents ir tiesīgs piekļūt šim kalendāram?).
3. Iesniedz saiti (Google Kalendāra API šajā gadījumā).
4. Atgriež strukturētu rezultātu modelim.

Kāpēc tas ir nozīmīgs? Tāpēc models nekonstrē rezultātu. Ja kalendārs atgriež [10h, 11h], tas ir tikai tas, kas tiek nosūtīts nākamajai saiti. Ja komanda iztrūkst, models zina, ka iztrūkst. Noklusuma riska nav, ka agents "izdomātu", ka ir laiks 9h, kad tas nav.

Ja šajā gadījumā ir jāsaskaita sensibru informācija (cena, laiks, klienta vārds), tada pipelines spēja tool call — neļauj modelim atbildēt no savas "zināšanām". Tādā veidā izbeidzas visbiežākais klases alucinācijas gadījums, kas notiek ar komerciāliem agentiem.

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

Ar rezultātu no komandas, models veic otru saiti — šoreiz, lai formētu finālo atbildei klientam. Piemēram:

"Esu sestdienās 10h un 11h. Kādu vēlies?"

Paralēli, darbinieks:

1. Nosūta ziņojumu atpakaļ ar WhatsApp API.
2. Saglabā visu ciklu (lietotājs + komanda + saites + ilgumu) D1.
3. Atjauno ilgtermiņa atmiņu ja cikls radīja jaunu faktu (piemēram, "klients vēlas sestdienās").
4. Izveido observējamās notikumu (latitūdas metrika, tokena izmaksu, skalēšanas ātrumu).

Visas šīs darbības notiek paralēli. Saglabāšana nebloķē ziņojuma nosūtīšanu — klientam nav jāgaida D1.

---

Kur ir aizsardzība pret alucināciju

Agents, kas alucinē, zaudē savu uzticību ātri. OpenClaw ir 4 līnijas aizsardzība:

1. Forcēta faktiskās ziņas. Faktiski dati (cena, laiks, vārds) visu reizi tiek saņemti no komandas, nevis no modela vienīgi.
2. Dubla pārbaude sensibru datiem. Agendamenti tiek apstiprināti ar klientu pirms saglabāšanas. Izdevumi tiek apstiprināti pirms piekļuves.
3. Izrakstītas negatīvas noteikumi. Kāda persona katram agentam iekļauj "nepieciešams neizdomāt X, Y, Z" — models pilda.
4. Fails uz cilvēku. Ja neviens komandas neapklašina jautājumu, agents saka "lai es pārbaudītu ar komandu" un atver tiketu — neizdomās.

Auditorijās, ko esmu veikušas pēdējos 6 mēnešos (reālas konversācijas, kas ir pārbaudītas manuāli), alucinācijas faktiskās daudzības ir zem 0,3% no ciklu — un visi gadījumi bija dēļ konfigurācijas (klients ir aizmirsis ieslēgt komandu), nevis dēļ modela kļūdas.

---

Konversācijas izmaksas

Translated markdown (lv-LV) beidzas.

Arhitektūra laba ir redzama tik tad, kad skatīsies par faktūru. Tā kā katrs posms veic 1-2 saites uz LLM + meklējumus D1, tipisks izdevums par pilnu konversāciju (10-15 posmi) ir:

• 1-2 saites uz LLM: $X (kas tiek precizēts nākamās rindas teksta)
• 1 meklējums D1: $Y (kas tiek precizēts nākamās rindas teksta)
• Kopējais izdevums par konversāciju: $Z (kas tiek precizēts nākamās rindas teksta)

Lai izskaidrotu, kā tiek aprēķināts $Z, uzskatiet, ka katrs posms veic 1-2 saites uz LLM un 1 meklējumu D1. Ja konversācija sastāv no 10-15 posmiem, tad:

• 10-15 posmi * 1-2 saites uz LLM = 10-30 saites uz LLM
• 10-15 posmi * 1 meklējums D1 = 10-15 meklējumi D1

Kopējais izdevums par konversāciju var būt:

• 10-30 saites uz LLM * $X = $10X - $30X
• 10-15 meklējumi D1 * $Y = $10Y - $15Y

Kopējais izdevums par konversāciju ir:

• $10X - $30X + $10Y - $15Y = $10X + $10Y - $30X - $15Y = $-20X - $5Y

Tātad, tipisks izdevums par pilnu konversāciju (10-15 posmi) ir $-20X - $5Y.