Kaip Veikia Pokalbių AI Agentas Viduje

Kaip Veikia Pokalbių AI Agentas Iš Vidaus (OpenClaw Architektūra)

Kaip veikia pokalbių AI agentas praktikoje, ėjimas po ėjimo? Šis įrašas atveria OpenClaw juodąją dėžę: nuo momento, kai kliento žinutė pasiekia WhatsApp, iki teksto, kurį agentas parašo atgal. Bus techniškai. Verta, jei sprendžiate produkto architektūrą, jei ketinate pirkti sprendimą ir norite įvertinti giliau, arba jei smagu žinoti, kas vyksta už pokalbio.

TL;DR: kiekvienas ėjimas pereina per 6 etapus — įkėlimas, konteksto nustatymas, įgūdžių pasirinkimas, kito veiksmo sprendimas, vykdymas su apsaugomis, atminties išsaugojimas. Visas ciklas vykdomas per <2 sekundes Cloudflare edge, be fiksuoto serverio.

---

Kodėl architektūra svarbi

Pokalbių agentas, kuris atrodo veikiantis demonstracijoje, bet sugenda produkcijoje, paprastai turi vieną iš šių 4 problemų:

1. Didelis vėlavimas — klientas laukia 8 sekundes atsakymo, pokalbis miršta.
2. Nekontroliuojamos haliucinacijos — agentas sugalvoja kainą, laiką, politiką.
3. Prarastas kontekstas — klientas grįžta po 2 dienų ir agentas "pamiršta" viską.
4. Nekontroliuojamos išlaidos — kiekvienas ilgas pokalbis užpildo užklausą ir mokate didelę sumą už žetonus.

Visi 4 yra architektūros pasirinkimai, ne modelio apribojimai. OpenClaw buvo sukurtas vengti visų 4 — ir kelias suprasti yra pažvelgti į ėjimo ciklą.

---

Ėjimo ciklas (6 etapai)

Įsivaizduokite, kad klientas ką tik atsiuntė žinutę "noriu užsiregistruoti šeštadienio rytui". Kas vyksta tarp "received" ir agento atsakymo?

1 etapas — Įkėlimas (edge worker, <50ms)

WhatsApp žinutė pasiekia per Meta webhook tiesiai į Cloudflare Worker artimiausią geografiškai buvimo tašką (PoP). Brazilijoje tai reiškia San Paulas arba Rio, tinklo vėlavimas < 20ms.

Worker atlieka tris dalykus:

1. Patvirtina parašą webhook (HMAC prieš WABA paslaptį).
2. Identifikuoja nuomotoją pagal gavėjo telefono numerį (multi-tenant pagal to_number).
3. Normalizuoja duomenų krūvį — garsas tampa transkripcija, vaizdas tampa aprašymu, vieta tampa {lat,lng}, tekstas lieka toks, koks yra.

1 etapo pabaigoje turite objektą {tenant_id, conversation_id, user_message} paruoštą kitam žingsniui.

2 etapas — Konteksto nustatymas (D1 + KV, ~80ms)

Agentui reikia 3 konteksto dalių prieš sprendžiant:

• Naujausia pokalbio istorija (paskutiniai N aktualių posūkių).
• Ilgalaikė kliento atmintis (pageidavimai, pirkimų istorija, pastabos).
• Agento būsena (persona, įgalintos funkcijos, taisyklės).

Visi duomenys gaunami iš D1 (Cloudflare paskirstytos SQLite). D1 pakeičia tradicinę Postgres/Mongo — nereikia prižiūrėti duomenų bazės serverio, prieiga per kelias ms iš worker, multi-tenant pagal tenant_id.

Pagrindinis dalykas: mes nekrauname viso pokalbio į užklausą. OpenClaw Memory Manager v2 (aprašytas mūsų vidinėje dokumentacijoje) pasirenka tik aktualius posūkius dabartiniam posūkiui (paskutinius N + N didelės semantinės svarbos). Tai išlaiko nuspėjamą token kainą net ir pokalbiuose su 100+ posūkių.

3 etapas — Funkcijų pasirinkimas (policy engine, ~20ms)

Kiekvienas agentas turi funkcijų rinkinį — funkcijas, kurias jis gali iškviesti. Pavyzdžiai: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Gavus pranešimą "quero marcar pra sábado de manhã", policy engine filtruoja:

• Funkcijas, suderinamas su aptikta intencija (planavimas).
• Funkcijas, leidžiamas šioje pokalbio fazėje (ne visos funkcijos prieinamos visada).
• Funkcijas, kurias šis tenant įgalino (calendar pasirodo tik jei tenant integravo).

Galiausiai gaunate mažą funkcijų pogrupį, perduotą modeliui — ne visas 50 galimų, tik 4, kurios čia turi prasmę. Tai drastiškai sumažina tikimybę, kad modelis iškviestų neteisingą funkciją.

4 etapas — Sprendimas (LLM call, 400-1200ms)

Dabar įsijungia modelis. OpenClaw atlieka vieną iškvietimą į pažangų LLM (Anthropic Claude, OpenAI GPT, Google Gemini — konfigūruojama pagal tenant) su:

• System prompt = agento persona + taisyklės + prieinamos funkcijos.
• History = pasirinkti posūkiai 2 etape.
• User message = dabartinio posūkio pranešimas.

Modelis atsako vienu iš dviejų dalykų:

• Galutinis atsakymas (tiesioginis tekstas klientui).
• Tool call (prašymas vykdyti konkrečią funkciją su parametrais).

Pavyzdyje "quero marcar pra sábado de manhã", modelis paprastai grąžina:

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

5 etapas — Vykdymas su apsaugomis (kintamas, ~100-500ms)

Funkcija nevykdoma modelyje. Ji vykdoma mūsų kode, kuris:

1. Patikrina parametrus (ar date_range formatas teisingas? ar atitinka nuomininko taisykles?).
2. Tikrina leidimą (ar šis agentas turi teisę pasiekti šį kalendorių?).
3. Vykdo užklausą (šiuo atveju Google Calendar API).
4. Grąžina struktūrizuotą rezultatą modeliui.

Kodėl tai svarbu? Nes modelis niekada nesugalvoja rezultato. Jei kalendorius grąžina [10h, 11h], tai būtent tai ir perduodama kitam iškvietimui. Jei įgūdis nepavyksta, modelis žino, kad nepavyko. Nulis rizikos, kad agentas "sugalvos" laisvą laiką 9h, kai jo nėra.

Atvejams, kurie apima jautrią informaciją (kaina, terminas, kliento vardas), konvejeris priverstinai naudoja tool call — neleidžia modeliui atsakyti iš savo "žinių". Tai pašalina dažniausią haliucinacijų klasę komerciniuose agentuose.

6 etapas — Atsakymas ir išsaugojimas (~50ms)

Turėdamas įgūdžio rezultatą, modelis atlieka antrą iškvietimą — dabar formuoja galutinį atsakymą klientui. Pvz.:

"Turiu šeštadienį 10h ir 11h. Kurį labiausiai tinka?"

Lygiagrečiai darbuotojas:

1. Siunčia žinutę atgal per WhatsApp API.
2. Išsaugo visą pokalbio eilę (user + assistant + tool calls + trukmė) D1.
3. Atnaujina ilgalaikę atmintį, jei pokalbio eilė sukūrė naują faktą (pvz.: "klientas teikia pirmenybę šeštadieniui").
4. Išsiunčia stebėjimo įvykį (laukimo laiko metrika, žetonų kaina, eskalavimo dažnis).

Visa tai vykdoma lygiagrečiai. Išsaugojimas neblokuoja žinutės siuntimo — klientas nelaukia D1.

---

Kur yra apsauga nuo haliucinacijų

Agentas, kuris haliucinuoja produkcijoje, greitai praranda pasitikėjimą. OpenClaw turi 4 gynybos linijas:

1. Priverstinis tiesos šaltinis. Faktiniai duomenys (kaina, laikas, vardas) visada ateina iš įgūdžio, niekada ne iš modelio vieno.
2. Dvigubas jautrių duomenų patikrinimas. Susitikimas patvirtinamas su klientu prieš išsaugant. Mokėjimas patvirtinamas prieš suteikiant prieigą.
3. Aiškios neigiamos taisyklės. Kiekvieno agento persona apima "niekada nesugalvok X, Y, Z" — modelis paklūsta.
4. Atsarginė žmogui. Kai joks įgūdis neapima klausimo, agentas sako "leisk man pasitikrinti su komanda" ir atidaro bilietą — nespėlioja.

Auditų, kuriuos atlikome per pastaruosius 6 mėnesius (realūs pokalbiai peržiūrėti rankiniu būdu), metu faktinių haliucinacijų dažnis buvo mažesnis nei 0,3% pokalbio eilių — ir beveik visi atvejai buvo dėl konfigūracijos (nuomininkas pamiršo įjungti atitinkamą įgūdį), o ne modelio klaidos.

---

Kaina už pokalbį

Gera architektūra yra nematoma, kol nepažiūri į sąskaitą. Atsižvelgiant į tai, kad kiekvienas ėjimas atlieka 1-2 LLM iškvietimus + paieškos D1, tipinė pilno pokalbio (10-15 ėjimų) kaina yra: