Agentiya IA Konversatsionniy ichida ishlaydi

Qanday Agenti Ijtimoiy IA Konversatsionalni Ichida (Arxitektura OpenClaw)

Qanday agenti ijtimoiy IA konversatsionalni ishlaydi harakatda, harakatda? Bu post OpenClawning qora kutubini ochadi: klientning xabari WhatsAppga yetib kelganda, agentning qaytgan matni. Bu harakatda texnik bo'ladi. Agar siz mahsulot arxitekturasini ishlab chiqayotgan bo'lsangiz, yoki yuklab olishni rejalashtirayotgan bo'lsangiz, yoki konversatsiyani orqali qanday qilib ishlayotganini bilishni yaxshi ko'rasangiz, bu postga qiziqib qarayotgan bo'lsangiz, bu postga qarayotgan bo'lsangiz.

TL;DR: harakatda 6 bosqichdan o'tadi — ingerst, kontekstni hal qiladi, qobiliyatni tanlaydi, keyingi harakatni qaror qiladi, qoidalar bilan boshqaradi, xotirani saqlaydi. Barcha aylanishlar Cloudflarening edgeida, serverli emas.

---

Arxitektura nima uchun muhimdir

Ijtimoiy konversatsionalni ishlaydigan agent, ammo ishlab chiqishda ishlaydigan agent, asosan 4 muammoni uchun ishlaydigan agentdir:

1. Yuqori latentsiya — klient 8 soniyani kutib, konversatsiya o'chadi.
2. Kontrollsiz alukinatsiya — agent narx, vaqti, siyosatni yaratadi.
3. Kontekstni yo'qotish — klient 2 kun kechiktirib, agent "eskaydi" barcha narsani.
4. Koshtli deskontrol — har konversatsiya uzun bo'lib, agentga pul to'laydi.

4 ta muammo arxitekturaning tanlanganligi, modelning chegarasi emas. OpenClawning qurilishi 4 ta muammolarni oldini olish uchun qurilgan — va qurilish yo'lini tushunish uchun, aylanishni ko'ring.

---

Aylanish (6 bosqich)

Klient `"sabt kuni kechasi" degan xabarni yuborganida, agentning qaytgan matni orasida qanday qilib ishlaydi?

Bosqich 1 — Ingerst (edge worker, <ms)

Xabarni WhatsAppga yetib kelganda, Cloudflare Workerda webhookning imzosi (HMAC)ni tekshiradi, tenantni aniqlaydi va payloadni normalizatsiya qiladi.

Bosqich 2 — Kontekstni hal qiladi (D1 + KV, ~80ms)

Agentga 3 ta kontekstga ega bo'lishi kerak:

1. Klientning ma'lumoti — klientning ma'lumotlari, jumladan, telefon raqami va xabarni yuborgan vaqti.
2. Kontekstni saqlash — agentga saqlangan kontekst, jumladan, muammoni hal qilganligi haqida ma'lumot.
3. Qobiliyatlar — agentga qobiliyatlar, jumladan, xabarni tushunish va javob berish uchun zarur ma'lumot.

Bosqich 2da sizga {tenant_id, conversation_id, user_message} obyekti mavjud bo'ladi.

• Tarixiy yaxshi (so'ngi N ta'riflar).
• Uzluksiz xotira (preferensiyalar, sotib olish tarixi, anotatsiyalar).
• Agent holati (persona, faollangan qobiliyatlari, qoidalar).

Barchasi D1 (Cloudflare tomonidan tarqatilgan SQLite) dan keladi. D1 klassik Postgres/Mongo serverizsiz saqlanadi — ishga kirish vaqti workerdan 10-20 ms. Multi-tenant uchun tenant_iddan foydalaniladi.

Asosiy nuqta: biz butun suhbatni promptga yuklamaymiz. OpenClaw (developers.cloudflare.com/d1/da tavsiflangan) Memory Manager v2 faqat so'ngi N + N (semantik ahamiyatga ega) ta'riflarni hozirgi turni uchun tanlaydi. Shunday qilib, token narxi 100+ turnilar suhbatlarda ham o'zgarmaydi.

3-darajali bosqich — Qobiliyatlar tanlash (siyosiy motor, ~20ms)

Har bir agentga bir qator qobiliyatlari mavjud — unga chaqiriladigan funksiyalar. Masalan: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

"Men sana kunning boshida marhaba" degan xabar berilganida, siyosiy motor quyidagilarini filtrlaydi:

• Qobiliyatlari intencion qidirilgan bilan mos keladi (agendament).
• Qobiliyatlari bu suhbatning hozirgi bosqichi uchun ruxsat etilgan (barcha qobiliyatlari har doim mavjud emas).
• Qobiliyatlari bu tenant tomonidan faollangan (calendar faqat shu tenant tomonidan integratsiyalangan bo'lsa ko'rinadi).

Natijada, sizga faqat 4 ta qobiliyat qoladi, lekin 50 ta qobiliyatdan faqat 4 ta qobiliyat faqat shu holatda ishlaydi. Shunday qilib, model qobiliyatni noto'g'ri chaqirish uchun imkoniyatlarini keskin qisqartiradi.

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

Modelga kiradi. OpenClaw bir marta frontir LLM (Anthropic Claude, OpenAI GPT, Google Gemini — tenant tomonidan sozlanadi) ga chaqiradi:

• Sistem prompt = agent persona + qoidalar + faollangan qobiliyatlari.
• Tarix = bosqich 2 da tanlangan ta'riflar.
• Foydalanuvchi xabari = hozirgi turni xabari.

Model ikki narsadan birini qaytaradi:

• Qaror (foydalanuvchiga direkt xabar).
• Tool call (qobiliyatni chaqirish uchun talab).

"Men sana kunning boshida marhaba" degan xabar berilganida, model asosan quyidagilarni qaytaradi:

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

5-darajali bosqich — Boshqaruv qoidalar bilan bajarish (muayyan, ~100-500ms)

Qobiliyat modelda bajarilmaydi. U bizning kodimizda bajariladi, u:

...

1. Validez parâmetros (date_range tem formato correto? está dentro das regras do tenant?).
2. Checa permissão (esse agente tem direito de consultar esse calendário?).
3. Executa a chamada (Google Calendar API nesse caso).
4. Retorna resultado estruturado pro modelo.

Por que isso importa? Porque o modelo nunca fabrica o resultado. Se o calendário retornar [10h, 11h], é exatamente isso que vai pra próxima chamada. Se a skill falhar, o modelo sabe que falhou. Zero risco de o agente "inventar" que tem horário às 9h quando não tem.

Pra casos que envolvem informação sensível (preço, prazo, nome do cliente), o pipeline força tool call — não deixa o modelo responder do próprio "conhecimento". Isso elimina a classe de alucinação mais comum em agentes comerciais.

Estágio 6 — Resposta e persistência (~50ms)

Com o resultado da skill em mãos, o modelo faz a segunda chamada — agora pra formar a resposta final pro cliente. Ex:

"Tenho sábado às 10h e 11h. Qual prefere?"

Paralelamente, o worker:

1. Envia a mensagem de volta pela API do WhatsApp.
2. Persiste o turno completo (user + assistant + tool calls + duração) no D1.
3. Atualiza a memória de longo prazo se o turno produziu fato novo (ex: "cliente prefere sábado").
4. Emite evento de observabilidade (métrica de latência, custo de token, taxa de escalação).

Tudo isso roda em paralelo. A persistência não bloqueia o envio da mensagem — cliente não espera o D1.

---

Onde está a defesa contra alucinação

Agente que alucina em produção perde confiança rápido. O OpenClaw tem 4 linhas de defesa:

1. Source-of-truth forçada. Dados factuais (preço, horário, nome) sempre vêm de skill, nunca do modelo sozinho.
2. Verificação dupla em dados sensíveis. Agendamento é confirmado com o cliente antes de persistir. Pagamento é confirmado antes de liberar acesso.
3. Regras negativas explícitas. Persona de cada agente inclui "nunca invente X, Y, Z" — o modelo obedece.
4. Fallback pra humano. Quando nenhuma skill cobre a pergunta, o agente diz "deixa eu checar com o time" e abre um ticket — não chuta.

Em auditorias que fizemos nos últimos 6 meses (conversas reais revistas manualmente), a taxa de alucinação factual ficou abaixo de 0,3% dos turnos — e quase todos os casos foram por config (tenant esqueceu de habilitar skill relevante), não erro do modelo.

---

O custo por conversa

Arxitetura yaxshi boʻlishi unga qarashga qodir boʻlmaydi. Har bir davr 1-2 LLM chaqiruvlariga + D1da qidiruvlariga ega boʻlganidan soʻng, toʻliq suhbat (10-15 davr) uchun oʻrtacha narx quyidagilarga toʻgʻri keladi:

• 1-2 LLM chaqiruvlari uchun 10-15 dollarga yaqin
• 10-15 D1 qidiruvlari uchun 5-10 dollarga yaqin
• Jami 15-30 dollarga yaqin

Shunday qilib, toʻliq suhbat uchun oʻrtacha narx 15-30 dollarga yaqin boʻlishi mumkin.