Nasıl Fonksiyon Konuşmalar AI Ageni İçin

Nasıl Bir AI Konuşma Ajansı İçerisinde Fonksiyonlar?

Bir AI Konuşma Ajansı Nasıl Fonksiyonlar? Bu post, OpenClaw'un sihirli kutusunu açıyor: müşteri mesajının WhatsApp'tan agente geri yazılan metne kadar. Teker teker geçeceğiz. Teker teker geçeceğimizde teknik konulara değineceğiz. Eğer ürün mimarisi yapacaksanız, bir çözüm satın alacaksanız ve satın alma kararını değerlendirmek istiyorsanız, veya arka planda ne olup bittiğini öğrenmek istiyorsanız, bu post için değerlidir.

TL;DR: Her döngü 6 aşamadan geçer - al, bağlamı çöz, yetenekleri seç, sonraki adıma karar ver, koridorlarla yürüt, belleği sakla. Tüm döngü Cloudflare Edge'de <saniyede çalışır, sabit bir sunucuya gerek yoktur.

---

Neden Arsitektür Önemlidir

Bir demo gibi görünen ama üretim ortamında çalışmayan bir konuşma ajansı genellikle 4 farklı problemden birine sahiptir:

1. Yüksek gecikme - müşteri 8 saniye bekler, konuşma ölür.
2. Kontrolsüz alucinasyon - agente fiyat, saat, politika gibi şeyler gelir.
3. Kayıp bağlam - müşteri 2 gün sonra geri döner ve agente her şeyin unutulduğunu söyler.
4. Kontrolsüz maliyet - her uzun konuşma, prompti doldurur ve token için çok para öder.

4'ü arsitektür seçimidir, model sınırlaması değildir. OpenClaw, 4'ü önlemek için tasarlandı - ve anlama yolculuğumuz, döngüdeki bir döngüyü incelemektir.

---

Döngüdeki Bir Döngü (6 Aşama)

Müşterinin mesajı "sabah saat 10'da randevu istiyorum" gibi bir şey gönderdiğini hayal edin. Aradaki agente ne oluyor?

1. Aşama - Al (Edge Worker, <ms)

WhatsApp mesajı, Meta webhook'undan Cloudflare Worker'a direkt olarak gelir. Worker, en yakın coğrafi olarak bulunan Cloudflare Point of Presence (PoP)'da çalışır. Brezilya için bu, São Paulo veya Rio'dur, ağ gecikmesi <0ms'dir.

Worker, üç şey yapar:

1. Webhook imzasını doğrular (HMAC karşı WABA gizli anahtarı).

2. Kullanıcıyı tanımlar (multi-tenant için to_number).

3. Payload'yı normalleştirir - ses, transkribe edilir, resim, açıklama, konum, {lat,lng}, metin, metin olarak kalır.

4. aşamasında, {tenant_id, conversation_id, user_message} adlı bir nesne hazır hale gelir.

2. Aşama - Bağlamı Çöz (D1 + KV, ~80ms)

Ajan, karar vermeden önce 3 farklı bağlamı çözmelidir:

1. Kullanıcı Bilgileri - kullanıcı kimdir, ne istiyor?
2. Konuşma Bilgileri - konuşma ne hakkında, ne kadar sürüyor?
3. Güncel Bilgiler - güncellemeler, yeni bilgiler, vs.

Bu 3 bilgi, ajanın karar vermesine yardımcı olur.

3. Aşama - Yetenekleri Seç (D1 + KV, ~80ms)

Ajan, yetenekleri seçmelidir. Yetenek, neyin ne olduğunu belirler. Yetenek, neyin ne olduğunu belirler.

4. Aşama - Sonraki Adıma Karar Ver (D1 + KV, ~80ms)

Ajan, sonraki adıma karar vermelidir. Sonraki adım, neyin ne olduğunu belirler.

5. Aşama - Koridorlarla Yürüt (D1 + KV, ~80ms)

Ajan, koridorlarla yürütmelidir. Koridor, neyin ne olduğunu belirler.

6. Aşama - Belleği Sakla (D1 + KV, ~80ms)

Ajan, belleği saklamalıdır. Bellek, neyin ne olduğunu belirler.

Tüm bu 6 aşama, Cloudflare Edge'de <saniyede çalışır, sabit bir sunucuya gerek yoktur.

• Sonuçlu kurallar:
• Güncel sohbet tarihi (son N önemli döngü).
• Uzun vadeli müşteri belleği (tutumlar, alışveriş tarihi, notlar).
• Ajan durumu (kişilik, etkinleştirilen yetenekler, kurallar).

Tüm bunlar D1 (Cloudflare'ın dağıtılmış SQLite'i) tarafından gelir. D1 geleneksel Postgres/Mongo sunucusuz olarak - işlemlerden sadece birkaç ms ile çalışan bir worker'dan erişime sahiptir, multi-tenant için tenant_id kullanılır.

Anahtar nokta: Sohbeti tamamen yüklemiyoruz. OpenClaw'un Memory Manager v2'si (iç dokumentasyonumuzda açıklanmıştır) sadece ilgili döngüleri seçer (son N + N yüksek semantik öneme sahip). Bu, 100+ döngü içeren sohbetlerde bile token maliyetini öngörülebilir kılar.

3. Aşama - Yetenek seçimi (politika motoru, ~20ms)

Her ajan, yetenek seti ile gelir - çağrılabilir işlevler. Örnekler: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Verilen mesaj "quero marcar pra sábado de manhã", politika motoru:

• Keşfedilen niyet ile uyumlu yetenekleri filtreler (agendamento).
• Sohbetin bu aşamasında izin verilen yetenekleri filtreler (her yetenek her zaman kullanılabilir değildir).
• Bu kiracı tarafından etkinleştirilen yetenekleri filtreler (calendar ancak kiracı calendar'i entegre ettiğinde görünür).

Sonunda, doğru yetenekleri model ile gönderir - 50 yeteneğin yerine 4 yeteneği. Bu, modelin yanlış yeteneği çağırma olasılığını dramatik olarak azaltır.

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

Şimdi model giriyor. OpenClaw, bir sınır LLM'sine (Anthropic Claude, OpenAI GPT, Google Gemini - kiracı tarafından yapılandırılabilir) tek bir çağrı yapar:

• Sistem prompt = ajanın kişiliği + kurallar + kullanılabilir yetenekler.
• Tarih = seçilen döngüler.
• Kullanıcı mesajı = mevcut döngünün mesajı.

Model, ikişer şeyi döndürür:

• Sonuç mesajı (müşteriye direkt gönderilir).
• Tool çağrısı (belirli bir yeteneği çağırma talebi).

Örnekte "quero marcar pra sábado de manhã", model tipik olarak aşağıdaki gibi döndürür:

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

5. Aşama - Güvenlik Duvarları ile Çalışma (değişken, ~100-500ms)

Yetenek modelde çalışmaz. Yetenek, kodumuzda çalışır:

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

Yetenek, kodumuzda çalışır.

1. Parametreleri doğrula (date_range formatı doğru mu? Tenant kurallarına uymuyor mu?).
2. İzin kontrolü (bu agent bu takvimi sorgulama yetkisine sahip mi?).
3. API çağrısı (Bu durumda Google Calendar API).
4. Sistem tarafından işlenen sonuç modelin önüne gönderilir.

Neden bu önemli? Model hiç bir zaman sonuçları üretmez. Takvim [10:00, 11:00] gibi bir sonuç döndürürse, bu da sonraki çağrıya gönderilir. Skill başarısız olursa, model başarısız olduğunu bilir. Agent "9:00'da randevu var" gibi bir şey üretemez.

Gizli bilgiler içeren (fiyat, süre, müşteri adı) durumlarda, pipeline tool call kullanır - model kendi "bilgisinden" cevap vermez. Bu en yaygın alucinasyon sınıfını ortadan kaldırır.

6. Aşama - Cevap ve Kalıcılık (~50ms)

Skill sonuçlarıyla sonuçlanan model, ikinci çağrıya gider - şimdi final cevap için müşteriye gönderilir. Örnek:

"Cumartesi 10:00 ve 11:00'de randevum var. Hangisini tercih edersiniz?"

Paralel olarak, worker:

1. API üzerinden mesajı gönderir.
2. D1'de tüm döngüyü (kullanıcı + yardımcı + tool çağrıları + süre) kaydeder.
3. Daha önce üretilemeyen yeni bir faktör üretildiğinde (örneğin "müşteri cumartesi tercih eder") uzun süreli belleği günceller.
4. Görünürlik olayı (latence, token maliyeti, ölçeklenebilirlik oranı) gönderir.

Tüm bunlar paralel olarak çalışır. Kayıt mesaj gönderilmesini bloke etmez - müşteri D1 beklemiyor.

---

Alucinasyon karşıtı savunma nerede?

Üretimde alucinasyon yapan bir agentin güveni kısa sürede kaybolur. OpenClaw 4 satır savunma kullanır:

1. Doğruluk kaynağının zorlanması. Gerçek veriler (fiyat, saat, isim) her zaman skill'den gelir, modelden değil.
2. Gizli veriler için çift doğrulama. Randevu müşteri ile onaylanır önce kaydedilir. Ödeme müşteri onaylandıktan sonra erişime izin verilir.
3. Negatif kurallar. Her agentin persona'sı "X, Y, Z'yi asla üretme" içerir - model bu kurallara uymak zorundadır.
4. İnsana geri dön. Hiçbir skill soru sorulamazsa, agent "beni kontrol edelim" der ve bir ticket açar - hata yapmaz.

Son 6 ayda yaptığımız denetimlerde (gerçek konuşmalar manuel olarak incelendi), 0,3%'den az alucinasyon oranı vardı - ve neredeyse tüm durumlarda, hata modelin değil, tenant'in (relevant skilli etkinleştirmeyi unuttu) olduğu bulundu.

Arkhitektür iyi görünmez, ancak faturayı incelerken görünür. Her tur 1-2 LLM çağrısı + D1 araması yapar, bu nedenle tam bir sohbet için (10-15 tur) ortalama maliyet:

• 10 tur: 10-20 LLM çağrısı + 10-20 D1 araması
• 15 tur: 15-30 LLM çağrısı + 15-30 D1 araması