Suhbat AI Agenti Ichkaridan Qanday Ishlaydi

Sun'iy Intellekt Suhbat Agentining Ichki Ishlash Mexanizmi (OpenClaw Arxitekturasi)

Sun'iy intellekt suhbat agenti qanday ishlaydi amalda, navbatma-navbat? Ushbu post OpenClaw qora qutisini ochadi: mijozning xabari WhatsApp'ga kelgan paytdan boshlab agent qaytarib yozgan matngacha. Bu texnik bo'ladi. Agar siz mahsulot arxitekturasini hal qilsangiz, yechim sotib olmoqchi bo'lsangiz va chuqur baholashni istasangiz yoki suhbat ortida nima sodir bo'layotganini bilishni yoqtirsangiz, bunga arziydi.

TL;DR: har bir navbat 6 bosqichdan o'tadi — qabul qilish, kontekstni aniqlash, ko'nikmalarni tanlash, keyingi harakatni hal qilish, himoya to'siqlari bilan bajarish, xotirani saqlash. Butun tsikl Cloudflare edge'da <2 soniyada, qat'iy serverisiz ishlaydi.

---

Nima uchun arxitektura muhim

Demoda ishlagandek ko'rinadigan, lekin ishlab chiqarishda buziladigan suhbat agenti odatda quyidagi 4 muammodan biriga ega:

1. Yuqori kechikish — mijoz javob uchun 8 soniya kutadi, suhbat o'ladi.
2. Nazorat qilinmagan gallyutsinatsiya — agent narx, vaqt, siyosatni o'ylab topadi.
3. Yo'qolgan kontekst — mijoz 2 kundan keyin qaytadi va agent hammasini "unutadi".
4. Nazorat qilinmagan xarajat — har bir uzun suhbat promptni to'ldiradi va siz token uchun boylik to'laysiz.

Bu 4 tasi arxitektura tanlovlari, model cheklovlari emas. OpenClaw bu 4 tasini oldini olish uchun qurilgan — va tushunish yo'li navbat tsiklini ko'rishdir.

---

Navbat tsikli (6 bosqich)

Tasavvur qiling, mijoz hozirgina "shanba kuni ertalab belgilashni xohlayman" xabarini yubordi. "Qabul qilindi" va agent javobi o'rtasida nima sodir bo'ladi?

1-bosqich — Qabul qilish (edge worker, <50ms)

WhatsApp xabari Meta webhook orqali to'g'ridan-to'g'ri geografik jihatdan eng yaqin Cloudflare Worker mavjudlik nuqtasiga (PoP) keladi. Braziliyada bu San-Paulu yoki Rio degan ma'noni anglatadi, tarmoq kechikishi < 20ms.

Worker uch narsani bajaradi:

1. Webhook imzosini tekshiradi (WABA maxfiy kalitiga qarshi HMAC).
2. Qabul qiluvchining telefon raqami bo'yicha tenantni aniqlaydi (ko'p tenantli to_number orqali).
3. Payload'ni normalizatsiya qiladi — audio transkripsiyaga aylanadi, rasm tavsifga aylanadi, joylashuv {lat,lng} ga aylanadi, matn o'z holatida qoladi.

1-bosqich oxirida sizda keyingi qadam uchun tayyor {tenant_id, conversation_id, user_message} obyekti bor.

2-bosqich — Kontekstni aniqlash (D1 + KV, ~80ms)

Agent qaror qabul qilishdan oldin 3 ta kontekst qismiga muhtoj:

• Suhbatning yaqinda tarixi (oxirgi N ta tegishli navbat).
• Mijozning uzoq muddatli xotirasi (afzalliklar, xarid tarixi, eslatmalar).
• Agent holati (persona, yoqilgan ko'nikmalar, qoidalar).

Barchasi D1 (Cloudflare'ning tarqatilgan SQLite) dan keladi. D1 an'anaviy Postgres/Mongo'ni almashtiradi — saqlash uchun ma'lumotlar bazasi serveri yo'q, worker'dan bir necha ms ichida kirish, tenant_id bo'yicha multi-tenant.

Asosiy nuqta: biz promptga butun suhbatni yuklamaymiz. OpenClaw'ning Memory Manager v2 (bizning ichki hujjatlarimizda tasvirlangan) joriy navbat uchun faqat tegishli navbatlarni tanlaydi (oxirgi N + semantik jihatdan yuqori ahamiyatga ega N ta). Bu 100+ navbatli suhbatlarda ham token xarajatlarini bashorat qilinadigan darajada ushlab turadi.

3-bosqich — Ko'nikmalarni tanlash (policy engine, ~20ms)

Har bir agentda mavjud ko'nikmalar to'plami bor — u chaqirishi mumkin bo'lgan funksiyalar. Misollar: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

"quero marcar pra sábado de manhã" xabari berilganda, policy engine filtrlaydi:

• Aniqlangan niyat bilan mos keladigan ko'nikmalar (rejalashtirish).
• Suhbatning ushbu bosqichi uchun ruxsat etilgan ko'nikmalar (har bir ko'nikma doim mavjud emas).
• Ushbu tenant yoqilgan ko'nikmalar (calendar faqat tenant integratsiya qilgan bo'lsa paydo bo'ladi).

Oxirida modelga uzatiladigan ko'nikmalarning kichik to'plami qoladi — mumkin bo'lgan 50 tasi emas, faqat bu yerda mantiqiy bo'lgan 4 tasi. Bu modelning noto'g'ri ko'nikmani chaqirish ehtimolini keskin kamaytiradi.

4-bosqich — Qaror (LLM chaqiruvi, 400-1200ms)

Endi model kiradi. OpenClaw frontline LLM ga (Anthropic Claude, OpenAI GPT, Google Gemini — tenant bo'yicha sozlanadi) bitta chaqiruv amalga oshiradi:

• System prompt = agent personasi + qoidalar + mavjud ko'nikmalar.
• History = 2-bosqichda tanlangan navbatlar.
• User message = joriy navbat xabari.

Model ikki narsadan birini javob beradi:

• Yakuniy javob (mijoz uchun to'g'ridan-to'g'ri matn).
• Tool call (parametrlar bilan ma'lum bir ko'nikmani bajarish so'rovi).

"quero marcar pra sábado de manhã" misolida model odatda quyidagini qaytaradi:

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

5-bosqich — Guard-rails bilan bajarish (o'zgaruvchan, ~100-500ms)

Ko'nikma modelda ishlamaydi. U bizning kodimizda ishlaydi, bu:

1. Parametrlarni tekshiradi (date_range to'g'ri formatda? tenant qoidalariga mos keladimi?).
2. Ruxsatni tekshiradi (bu agent ushbu taqvimni ko'rish huquqiga egami?).
3. Chaqiruvni bajaradi (bu holatda Google Calendar API).
4. Tuzilgan natijani modelga qaytaradi.

Nima uchun bu muhim? Chunki model hech qachon natijani o'ylab topmaydi. Agar taqvim [10h, 11h] qaytarsa, keyingi chaqiruvga aynan shu narsa o'tadi. Agar skill muvaffaqiyatsiz bo'lsa, model muvaffaqiyatsiz bo'lganini biladi. Agent soat 9 da vaqt borligini "o'ylab topishi" xavfi nolga teng.

Maxfiy ma'lumotlarni (narx, muddat, mijoz nomi) o'z ichiga olgan holatlar uchun pipeline tool callni majbur qiladi — modelga o'z "bilimi"dan javob berishga ruxsat bermaydi. Bu tijorat agentlarida eng keng tarqalgan gallyutsinatsiya sinfini yo'q qiladi.

6-bosqich — Javob va saqlash (~50ms)

Skill natijasi qo'lida bo'lganda, model ikkinchi chaqiruvni amalga oshiradi — endi mijoz uchun yakuniy javobni shakllantirish uchun. Masalan:

"Shanba kuni soat 10 va 11 da vaqtim bor. Qaysi birini afzal ko'rasiz?"

Parallel ravishda worker:

1. Xabarni WhatsApp API orqali yuboradi.
2. To'liq navbatni (user + assistant + tool calls + davomiyligi) D1 da saqlaydi.
3. Agar navbat yangi fakt yaratgan bo'lsa (masalan: "mijoz shanbani afzal ko'radi"), uzoq muddatli xotirani yangilaydi.
4. Kuzatuvchanlik hodisasini chiqaradi (kechikish ko'rsatkichi, token narxi, eskalatsiya darajasi).

Bularning barchasi parallel ishlaydi. Saqlash xabar yuborishni bloklamaydi — mijoz D1 ni kutmaydi.

---

Gallyutsinatsiyaga qarshi himoya qayerda

Ishlab chiqarishda gallyutsinatsiya qiluvchi agent tezda ishonchni yo'qotadi. OpenClaw 4 ta himoya chizig'iga ega:

1. Majburiy haqiqat manbai. Faktik ma'lumotlar (narx, vaqt, ism) har doim skilldan keladi, hech qachon modelning o'zidan emas.
2. Maxfiy ma'lumotlarda ikki marta tekshirish. Rejalashtirish saqlanishdan oldin mijoz bilan tasdiqlanadi. To'lov kirishni berishdan oldin tasdiqlanadi.
3. Aniq salbiy qoidalar. Har bir agent personasi "hech qachon X, Y, Z ni o'ylab topma" ni o'z ichiga oladi — model bo'ysunadi.
4. Insonga qaytish. Hech bir skill savolni qamrab olmasa, agent "jamoadan tekshirib ko'ray" deydi va tiket ochadi — taxmin qilmaydi.

So'nggi 6 oyda o'tkazgan auditlarimizda (haqiqiy suhbatlar qo'lda ko'rib chiqilgan), faktik gallyutsinatsiya darajasi navbatlarning 0,3% dan past bo'ldi — va deyarli barcha holatlar konfiguratsiya tufayli bo'ldi (tenant tegishli skillni yoqishni unutdi), model xatosi emas.

---

Suhbat uchun xarajat

Yaxshi arxitektura siz hisob-fakturani ko'rmaguncha ko'rinmas bo'ladi. Har bir navbat 1-2 ta LLM chaqiruvi + D1 da qidiruvlarni hisobga olsak, to'liq suhbat uchun odatiy xarajat (10-15 navbat):