Söhbət AI Agentinin Daxili İşləmə Prinsipi

Söhbət AI Agentinin Daxili İşləmə Prinsipi (OpenClaw Arxitekturası)

Söhbət AI agenti necə işləyir praktikada, növbə-növbə? Bu yazı OpenClaw-ın qara qutusunu açır: müştərinin mesajının WhatsApp-a çatdığı andan agentin geri yazdığı mətnə qədər. Texniki olacaq. Məhsul arxitekturasına qərar verirsinizsə, həll yolu almaq və dərinliyinə qiymətləndirmək istəyirsinizsə və ya söhbətin arxasında nə baş verdiyini bilmək istəyirsinizsə, dəyər.

TL;DR: hər növbə 6 mərhələdən keçir — qəbul, konteksti həll et, bacarıqları seç, növbəti hərəkətə qərar ver, mühafizə mexanizmləri ilə icra et, yaddaşı saxla. Bütün tsikl Cloudflare-in edge-ində <2 saniyədə işləyir, sabit server olmadan.

---

Arxitektura niyə vacibdir

Demo-da işləyir kimi görünən, lakin istehsalda sındırılan söhbət agenti adətən bu 4 problemdən birinə malikdir:

1. Yüksək gecikmə — müştəri cavab üçün 8 saniyə gözləyir, söhbət ölür.
2. Nəzarətsiz halüsinasiya — agent qiyməti, vaxtı, siyasəti uydurur.
3. İtirilmiş kontekst — müştəri 2 gündən sonra qayıdır və agent hər şeyi "unudur".
4. Nəzarətsiz xərc — hər uzun söhbət prompt-u doldurur və siz token üçün sərvət ödəyirsiniz.

Bu 4-ü modelin məhdudiyyətləri deyil, arxitektura seçimləridir. OpenClaw bu 4-dən qaçmaq üçün qurulub — və başa düşmək yolu bir növbənin tsiklinə baxmaqdır.

---

Bir növbənin tsikli (6 mərhələ)

Təsəvvür edin ki, müştəri indicə "şənbə səhəri üçün təyin etmək istəyirəm" mesajını göndərib. "Received" ilə agentin cavabı arasında nə baş verir?

Mərhələ 1 — Qəbul (edge worker, <50ms)

WhatsApp mesajı Meta-dan webhook vasitəsilə birbaşa coğrafi olaraq ən yaxın olan Cloudflare Worker nöqtəsinə (PoP) çatır. Braziliyada bu, San-Paulu və ya Rio deməkdir, şəbəkə gecikməsi < 20ms.

Worker üç şey edir:

1. Webhook-un imzasını yoxlayır (WABA sirrə qarşı HMAC).
2. Qəbul edən telefon nömrəsi ilə tenant-i müəyyənləşdirir (multi-tenant to_number üzrə).
3. Payload-u normallaşdırır — audio transkripsiyaya çevrilir, şəkil təsvirə çevrilir, məkan {lat,lng} olur, mətn olduğu kimi qalır.

Mərhələ 1-in sonunda növbəti addım üçün hazır {tenant_id, conversation_id, user_message} obyekti əldə edirsiniz.

Mərhələ 2 — Konteksti həll et (D1 + KV, ~80ms)

Agent qərar verməzdən əvvəl 3 kontekst parçasına ehtiyac duyur:

• Söhbətin son tarixçəsi (son N müvafiq növbə).
• Müştərinin uzunmüddətli yaddaşı (seçimlər, alış tarixçəsi, qeydlər).
• Agent vəziyyəti (persona, aktiv bacarıqlar, qaydalar).

Hamısı D1-dən gəlir (Cloudflare-in paylanmış SQLite). D1 ənənəvi Postgres/Mongo-nu əvəz edir — saxlanılacaq verilənlər bazası serveri yoxdur, worker-dən bir neçə ms-də giriş, tenant_id üzrə multi-tenant.

Əsas məqam: biz bütün söhbəti prompt-a yükləmirik. OpenClaw-un Memory Manager v2 (bizim daxili sənədləşməmizdə təsvir edilmişdir) cari növbə üçün yalnız müvafiq növbələri seçir (son N + yüksək semantik uyğunluğa malik N). Bu, 100+ növbəli söhbətlərdə belə token xərcini proqnozlaşdırıla bilən saxlayır.

Mərhələ 3 — Bacarıqların seçilməsi (policy engine, ~20ms)

Hər agentin çağıra biləcəyi bacarıqlar toplusu var — funksiyalar. Nümunələr: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

"quero marcar pra sábado de manhã" mesajı verildikdə, policy engine filtr edir:

• Aşkar edilmiş niyyətlə uyğun bacarıqlar (planlaşdırma).
• Söhbətin bu mərhələsi üçün icazə verilən bacarıqlar (hər bacarıq hər zaman əlçatan deyil).
• Bu tenant-ın aktivləşdirdiyi bacarıqlar (calendar yalnız tenant inteqrasiya etdikdə görünür).

Nəticədə modelə ötürülən kiçik bir bacarıqlar alt toplusu əldə edirsiniz — mümkün olan 50 deyil, yalnız burada məna kəsb edən 4. Bu, modelin səhv bacarıq çağırma ehtimalını kəskin şəkildə azaldır.

Mərhələ 4 — Qərar (LLM çağırışı, 400-1200ms)

İndi model daxil olur. OpenClaw tenant üzrə konfiqurasiya olunan ön cərgə LLM-ə (Anthropic Claude, OpenAI GPT, Google Gemini) tək çağırış edir:

• System prompt = agentin personası + qaydalar + mövcud bacarıqlar.
• History = mərhələ 2-də seçilmiş növbələr.
• User message = cari növbənin mesajı.

Model iki şeydən birini cavab verir:

• Son cavab (müştəriyə birbaşa mətn).
• Tool call (parametrlərlə xüsusi bacarığı icra etmək üçün sorğu).

"quero marcar pra sábado de manhã" nümunəsində model adətən bunu qaytarır:

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

Mərhələ 5 — Guard-rails ilə icra (dəyişən, ~100-500ms)

Bacarıq modeldə işləmir. O, bizim kodumuzda işləyir ki:

1. Parametrləri yoxlayır (date_range düzgün formatdadır? tenant qaydalarına uyğundur?).
2. İcazəni yoxlayır (bu agentin bu təqvimə müraciət etmək hüququ varmı?).
3. Çağırışı icra edir (bu halda Google Calendar API).
4. Strukturlaşdırılmış nəticəni modelə qaytarır.

Bu niyə vacibdir? Çünki model heç vaxt nəticəni uydurmur. Əgər təqvim [10h, 11h] qaytarırsa, növbəti çağırışa gedən məhz budur. Əgər skill uğursuz olarsa, model bunun uğursuz olduğunu bilir. Agentin olmayan saat 9-da vaxt olduğunu "uydurması" riski sıfırdır.

Həssas məlumat (qiymət, müddət, müştəri adı) ehtiva edən hallar üçün pipeline tool call tələb edir — modelin öz "bilikləri"ndən cavab verməsinə icazə vermir. Bu, kommersiya agentlərində ən çox rast gəlinən halüsinasiya sinfini aradan qaldırır.

Mərhələ 6 — Cavab və saxlama (~50ms)

Skill nəticəsi əldə olunduqdan sonra model ikinci çağırış edir — indi müştəri üçün yekun cavab formalaşdırmaq üçün. Məsələn:

"Şənbə günü saat 10 və 11-də vaxtım var. Hansını üstün tutursunuz?"

Paralel olaraq worker:

1. Mesajı WhatsApp API vasitəsilə geri göndərir.
2. Tam dövrü (user + assistant + tool calls + müddət) D1-də saxlayır.
3. Əgər dövr yeni fakt yaratmışsa (məs: "müştəri şənbəni üstün tutur"), uzunmüddətli yaddaşı yeniləyir.
4. Müşahidə edilə bilənlik hadisəsi yayır (gecikmə metrikası, token dəyəri, eskalasiya dərəcəsi).

Bütün bunlar paralel işləyir. Saxlama mesajın göndərilməsini bloklamır — müştəri D1-i gözləmir.

---

Halüsinasiyaya qarşı müdafiə haradadır

İstehsalda halüsinasiya edən agent tez etibarını itirir. OpenClaw-un 4 müdafiə xətti var:

1. Məcburi həqiqət mənbəyi. Faktiki məlumatlar (qiymət, vaxt, ad) həmişə skill-dən gəlir, heç vaxt tək modeldən deyil.
2. Həssas məlumatlar üçün ikiqat yoxlama. Planlaşdırma saxlanmazdan əvvəl müştəri ilə təsdiqlənir. Ödəniş girişə icazə verilməzdən əvvəl təsdiqlənir.
3. Açıq mənfi qaydalar. Hər agentin personası "heç vaxt X, Y, Z uydurma" daxildir — model tabe olur.
4. İnsana keçid. Heç bir skill sualı əhatə etmədikdə, agent "qoy komanda ilə yoxlayım" deyir və tiket açır — təxmin etmir.

Son 6 ayda apardığımız auditlərdə (əl ilə nəzərdən keçirilmiş real söhbətlər) faktiki halüsinasiya dərəcəsi dövrlərin 0,3%-dən aşağı oldu — və halların demək olar ki hamısı konfiqurasiya səbəbindən idi (tenant müvafiq skill-i aktivləşdirməyi unutdu), model xətası deyil.

---

Söhbət başına xərc

Yaxşı arxitektura fakturaya baxana qədər görünməzdir. Hər növbənin 1-2 LLM çağırışı + D1-də axtarış etdiyini nəzərə alsaq, tam söhbət üçün tipik xərc (10-15 növbə) təşkil edir: