Bir Konuşmacı Yapay Zeka Ajanı İçeriden Nasıl Çalışır

Bir Yapay Zeka Sohbet Ajanı İçeriden Nasıl Çalışır (OpenClaw Mimarisi)

Bir yapay zeka sohbet ajanı nasıl çalışır pratikte, turno turno? Bu yazı OpenClaw'ın kara kutusunu açıyor: müşterinin mesajının WhatsApp'a ulaştığı andan ajanın geri yazdığı metne kadar. Teknik olacak. Ürün mimarisi kararları alıyorsanız, bir çözüm satın alacaksanız ve derinlemesine değerlendirmek istiyorsanız veya konuşmanın arkasında neler olduğunu merak ediyorsanız buna değer.

TL;DR: her turno 6 aşamadan geçer — ingest, bağlam çözümleme, skill seçimi, sonraki eylem kararı, guard-rail'lerle yürütme, bellek kalıcılığı. Tüm döngü Cloudflare edge'inde <2 saniyede çalışır, sabit sunucu olmadan.

---

Mimari neden önemlidir

Bir demoda çalışıyor gibi görünen ama üretimde bozulan sohbet ajanı genellikle şu 4 sorundan birine sahiptir:

1. Yüksek gecikme — müşteri yanıt için 8 saniye bekler, konuşma ölür.
2. Kontrolsüz halüsinasyon — ajan fiyat, saat, politika uydurur.
3. Kayıp bağlam — müşteri 2 gün sonra döner ve ajan her şeyi "unutur".
4. Kontrolsüz maliyet — her uzun konuşma prompt'u doldurur ve token'a servet ödersiniz.

Bu 4'ü de mimari tercihleridir, modelin sınırlamaları değil. OpenClaw bu 4'ünü de önlemek için inşa edildi — ve bunu anlamanın yolu bir turnonun döngüsüne bakmaktır.

---

Bir turnonun döngüsü (6 aşama)

Müşterinin az önce "cumartesi sabahı için randevu almak istiyorum" mesajını gönderdiğini düşünün. "Alındı" ile ajanın yanıtı arasında ne olur?

Aşama 1 — Ingest (edge worker, <50ms)

WhatsApp mesajı Meta'nın webhook'u aracılığıyla doğrudan coğrafi olarak en yakın varlık noktasındaki (PoP) bir Cloudflare Worker'a ulaşır. Brezilya'da bu São Paulo veya Rio demektir, ağ gecikmesi < 20ms.

Worker üç şey yapar:

1. Webhook imzasını doğrular (WABA secret'ına karşı HMAC).
2. Alıcının telefon numarasına göre tenant'ı tanımlar (to_number ile multi-tenant).
3. Payload'ı normalleştirir — ses transkripsiyona, görsel açıklamaya, konum {lat,lng}'ye dönüşür, metin olduğu gibi kalır.

Aşama 1'in sonunda bir sonraki adım için hazır bir {tenant_id, conversation_id, user_message} nesneniz olur.

Aşama 2 — Bağlam çözümleme (D1 + KV, ~80ms)

Ajanın karar vermeden önce 3 bağlam parçasına ihtiyacı vardır:

• Yakın geçmiş konuşma geçmişi (son N ilgili tur).
• Uzun süreli bellek müşteri bilgileri (tercihler, satın alma geçmişi, notlar).
• Ajan durumu (persona, etkinleştirilmiş beceriler, kurallar).

Tümü D1'den (Cloudflare'in dağıtık SQLite'ı) gelir. D1, geleneksel Postgres/Mongo'nun yerini alır — bakım gerektiren veritabanı sunucusu yok, worker'dan birkaç ms'de erişim, tenant_id ile çoklu kiracı desteği.

Kilit nokta: biz prompt'a tüm konuşmayı yüklemiyoruz. OpenClaw'ın Memory Manager v2'si (dahili dokümantasyonumuzda açıklanmıştır) mevcut tur için yalnızca ilgili turları seçer (son N + anlamsal olarak yüksek ilgiye sahip N tur). Bu, 100+ turlu konuşmalarda bile token maliyetini öngörülebilir tutar.

Aşama 3 — Beceri seçimi (policy engine, ~20ms)

Her ajanın kullanılabilir bir beceri seti vardır — çağırabileceği fonksiyonlar. Örnekler: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

"cumartesi sabahına randevu almak istiyorum" mesajı verildiğinde, policy engine şunları filtreler:

• Algılanan niyetle (randevu alma) uyumlu beceriler.
• Konuşmanın bu aşaması için izin verilen beceriler (her beceri her zaman kullanılabilir değildir).
• Bu kiracının etkinleştirdiği beceriler (takvim yalnızca kiracı entegrasyon yaptıysa görünür).

Sonuçta modele küçük bir beceri alt kümesi iletilir — olası 50 beceri değil, yalnızca burada anlamlı olan 4 tanesi. Bu, modelin yanlış beceri çağırma olasılığını büyük ölçüde azaltır.

Aşama 4 — Karar (LLM çağrısı, 400-1200ms)

Şimdi model devreye girer. OpenClaw, bir sınır LLM'e (Anthropic Claude, OpenAI GPT, Google Gemini — kiracı bazında yapılandırılabilir) tek bir çağrı yapar:

• System prompt = ajanın personası + kurallar + kullanılabilir beceriler.
• History = aşama 2'de seçilen turlar.
• User message = mevcut turun mesajı.

Model iki şeyden birini yanıtlar:

• Son yanıt (müşteriye doğrudan metin).
• Tool call (belirli bir beceriyi parametrelerle çalıştırma talebi).

"cumartesi sabahına randevu almak istiyorum" örneğinde, model tipik olarak şunu döndürür:

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

Aşama 5 — Koruma mekanizmalarıyla yürütme (değişken, ~100-500ms)

Beceri modelde çalışmaz. Bizim kodumuzda çalışır ve bu kod:

1. Parametreleri doğrular (date_range doğru formatta mı? Tenant kuralları dahilinde mi?).
2. İzni kontrol eder (bu ajanın bu takvimi sorgulamaya hakkı var mı?).
3. Çağrıyı yürütür (bu durumda Google Calendar API).
4. Yapılandırılmış sonucu modele döndürür.

Bu neden önemli? Çünkü model asla sonucu uydurmaz. Takvim [10h, 11h] döndürürse, bir sonraki çağrıya giden tam olarak budur. Skill başarısız olursa, model başarısız olduğunu bilir. Ajanın olmayan bir 9h randevusunu "uydurmak" riski sıfırdır.

Hassas bilgi içeren durumlar için (fiyat, süre, müşteri adı), pipeline tool call kullanmaya zorlar — modelin kendi "bilgisinden" yanıt vermesine izin vermez. Bu, ticari ajanlarda en yaygın olan halüsinasyon sınıfını ortadan kaldırır.

Aşama 6 — Yanıt ve kalıcılık (~50ms)

Skill sonucu elinde olan model, ikinci çağrıyı yapar — bu sefer müşteriye son yanıtı oluşturmak için. Örn:

"Cumartesi 10h ve 11h müsait. Hangisini tercih edersiniz?"

Eş zamanlı olarak worker:

1. Mesajı WhatsApp API üzerinden geri gönderir.
2. Tam turu (user + assistant + tool calls + süre) D1'de kalıcı hale getirir.
3. Tur yeni bir bilgi ürettiyse uzun süreli belleği günceller (örn: "müşteri cumartesiyi tercih ediyor").
4. Gözlemlenebilirlik olayı yayar (gecikme metriği, token maliyeti, eskalasyon oranı).

Tüm bunlar paralel çalışır. Kalıcılık mesaj gönderimini engellemez — müşteri D1'i beklemez.

---

Halüsinasyona karşı savunma nerede

Üretimde halüsinasyon yapan ajan güveni hızla kaybeder. OpenClaw'un 4 savunma hattı vardır:

1. Zorunlu doğruluk kaynağı. Olgusal veriler (fiyat, saat, isim) her zaman skill'den gelir, asla modelden tek başına gelmez.
2. Hassas verilerde çift doğrulama. Randevu, kalıcı hale getirilmeden önce müşteriyle onaylanır. Ödeme, erişim açılmadan önce onaylanır.
3. Açık negatif kurallar. Her ajanın personası "asla X, Y, Z uydurmayın" içerir — model buna uyar.
4. İnsana yönlendirme. Hiçbir skill soruyu karşılamadığında, ajan "ekiple kontrol edeyim" der ve bir ticket açar — tahmin yürütmez.

Son 6 ayda yaptığımız denetimlerde (manuel olarak incelenen gerçek konuşmalar), olgusal halüsinasyon oranı turnların %0,3'ünün altında kaldı — ve neredeyse tüm vakalar yapılandırma kaynaklıydı (tenant ilgili skill'i etkinleştirmeyi unutmuş), model hatası değil.

---

Konuşma başına maliyet

İyi mimari, faturaya bakana kadar görünmezdir. Her turda 1-2 LLM çağrısı + D1 sorgusu yapıldığı göz önüne alındığında, tam bir konuşma (10-15 tur) başına tipik maliyet şu şekildedir: