OpenClaw (Moltbot/Clawdbot) Kalıcı Bellek Nasıl Çalışır?

OpenClaw (önceden Moltbot/Clawdbot), aracı kullanıcı deneyimindeki (UX) acı verici bir boşluğu, yani sürekliliği çözdüğü için gündemde. Çoğu asistan etkileşim katmanında hala durumsuz olduğundan, her oturum sıfırlaması bağlamın kaybolması gibi hissettiriyor. OpenClaw'un kalıcı bellek tasarımı tam tersi bir yönde ilerliyor: faydalı uzun vadeli durumu koruyun, ancak kontrolsüz token maliyetlerinden ve güvensiz saklamadan kaçının.

Bunu, heartbeat döngüleri ("önce ucuz kontroller, yalnızca gerektiğinde model"), nono gibi güvenli aracı sanal alanları ve Nanobot gibi ultra hafif alternatiflerle yapılan karşılaştırmalar etrafındaki topluluk tartışmalarında görebilirsiniz. Merkezi mühendislik sorusu aynıdır:

Aracınızı yavaş, pahalı, gizlilik riski taşıyan bir kara kutuya dönüştürmeden kalıcı, faydalı belleği nasıl korursunuz?

Bu makale, OpenClaw tarzı kalıcı belleğin üretim sistemlerinde tipik olarak nasıl çalıştığını, uygulama detaylarını, ödünleşimleri ve Apidog ile bellek API'lerinin nasıl test edileceğini açıklıyor.

OpenClaw'da Bellek: Pratik Bir Zihinsel Model

Sistem düzeyinde, OpenClaw belleği genellikle dört katmana ayrılır:

Geçici Bağlam (istem penceresi)
Mevcut konuşma dönüşleri ve araç çıktıları. Hızlı, geçici, token sınırına bağlı.

Oturum Belleği (kısa vadeli)
Devam eden görev/oturum için yapılandırılmış durum (hedefler, aktif varlıklar, geçici tercihler).

Kalıcı Kullanıcı Belleği (uzun vadeli)
Yeniden başlatmalardan sonra da kalması beklenen gerçekler ve tercihler (örn. tercih edilen kodlama yığını, saat dilimi, bildirim alışkanlıkları).

Bilgi Belleği (belge/görev kümesi)
Alım için indekslenmiş notlar, yapıtlar ve önceki çalışma ürünleri (gömme + meta veri filtreleri).

Temel ayrıntı: her şey kalıcı hale getirilmez. OpenClaw, yalnızca yüksek değerli, kararlı bilgilerin kalıcı bellek haline gelmesi için çıkarma ve sıralama kullanır.

Çekirdek mimari: yazma yolu ve okuma yolu

Yazma yolu (bellek nasıl oluşturulur)

Sağlam bir OpenClaw bellek hattı genellikle şu sırayı takip eder:

Olay Yakalama
Sohbet dönüşlerinden, araç sonuçlarından, dosya düzenlemelerinden, takvim etkinliklerinden ve görev sonuçlarından aday sinyalleri toplar.

Aday Çıkarma
Hafif bir çıkarıcı, "belleğe değer" iddiaları tanımlar. Örnek sınıflar:

• kalıcı tercih
• kimlik/profil detayı
• tekrarlayan iş akışı deseni
• çözülmemiş taahhüt/hatırlatıcı

Önce Ucuz Doğrulama
Heartbeat deseninden esinlenilmiştir: model çıkarımından önce düşük maliyetli kontrolleri çalıştırın.

• regex/sezgisel yöntemler
• tekrarlanan hash kontrolleri
• şema geçerlilik kontrolleri
• önceki sınıflandırıcıdan alınan güven eşiği

Model Doğrulama (yalnızca gerektiğinde)
Belirsizlik devam ederse, kalıcılık değerini ve hassasiyet riskini puanlamak için bir LLM sınıflandırıcısını çağırın.

Normalleştirme + Şema Eşleme
Serbest metni yazılı bellek kayıtlarına dönüştürün.

Çakışma Politikası ile Güncelleme veya Ekleme (Upsert)
Mevcut kayıtlarla güncelliği, güven puanını ve kaynak önceliğini kullanarak birleştirin.

Denetim Ekleme
Açıklanabilirlik ve geri alma için değişmez denetim olaylarını saklayın.

Okuma yolu (bellek nasıl alınır)

Yanıt zamanında:

1. Mevcut kullanıcı dönüşü + aktif görev durumundan sorgu amacını oluşturun.
2. Yapılandırılmış depodan + vektör depodan adayları alın.
3. Alaka düzeyi, tazelik, güven ve politika kısıtlamalarına göre yeniden sıralayın.
4. Bütçeyi (token + gecikme) uygulayın. Gerekirse sıkıştırın.
5. Seçilen belleği sistem/geliştirici bağlamına enjekte edin.

Bu ayrım çok önemlidir: yazma yolu kaliteyi ve güvenliği optimize eder; okuma yolu alaka düzeyini ve hızı optimize eder.

Veri modeli: bir bellek kaydı ne içermelidir

Pratik bir bellek varlığı genellikle şöyle görünür:

{
  "memory_id": "mem_8f3c...",
  "user_id": "usr_123",
  "type": "preference",
  "key": "editor.theme",
  "value": "dark",
  "confidence": 0.91,
  "source": {
    "kind": "chat_turn",
    "ref": "msg_9981",
    "observed_at": "2026-01-10T09:20:11Z"
  },
  "sensitivity": "low",
  "ttl": null,
  "last_confirmed_at": "2026-01-10T09:20:11Z",
  "version": 4,
  "embedding_ref": "vec_77ad...",
  "created_at": "2026-01-01T10:00:00Z",
  "updated_at": "2026-01-10T09:20:11Z"
}

Önemli alanlar:

• güven: zayıf çıkarımlardan kaynaklanan kırılgan davranışları önler.
• hassasiyet: saklama ve erişim kontrollerini yönlendirir.
• ttl: ölümsüz bayat gerçekleri önler.
• sürüm: iyimser eşzamanlılığı ve denetlenebilirliği destekler.

Depolama stratejisi: tasarımla çok dilli (polyglot)

OpenClaw belleği genellikle birden fazla depodan faydalanır:

• İlişkisel Veritabanı (Postgres/MySQL) kanonik tipli kayıtlar, kısıtlamalar, işlemler için.
• Vektör Veritabanı notlar/mesajlar/yapıtlar arasında anlamsal geri çağırma için.
• Nesne Deposu ham yapıtlar ve anlık görüntüler için.
• Olay Günlüğü yalnızca eklemeli geçmiş ve tekrar oynatma için.

Neden tek bir depo değil? Çünkü iş yükleri farklılık gösterir:

• nokta aramaları + politika filtreleme ilişkisel garantiler gerektirir
• anlamsal geri çağırma ANN indeksleme gerektirir
• uyumluluk ve hata ayıklama değişmez olay geçmişi gerektirir

Yaygın bir desen şudur: SQL'e kaydet, eşzamansız olarak göm, sonra embedding_ref aracılığıyla bağla.

Heartbeat'ler ve bellek tazeliği

Heartbeat modeli, son OpenClaw konuşmalarındaki en pratik fikirlerden biridir.

Sürekli ağır mantık yürütmek yerine, periyodik döngüler şunları yapar:

1. ucuz canlılık kontrolleri
2. bayat bellek tespiti
3. pahalı model kontrollerini yalnızca anormalliklerde tetikler

Örnek heartbeat görevleri:

• vadesi geçmiş çözülmemiş hatırlatıcıları tespit etme
• onaylanmamış tercihler için güveni azaltma
• yüksek etkili bellekleri yeniden doğrulama (faturalandırma, kimlik bilgileri kapsamı)
• gereksiz bellek kümelerini sıkıştırma

Bu mimari, kaliteyi korurken maliyeti önemli ölçüde düşürür. Ayrıca, gözlemlenebilirliğe ve SLO yönetimine yardımcı olan öngörülebilir zamanlama sınırları oluşturur.

Geri alma sıralaması: alaka düzeyi yeterli değil

Güçlü bir OpenClaw geri alıcısı, yalnızca gömme benzerliğinden daha fazlasıyla puanlamalıdır:

Nihai puan = anlamsal_alaka_düzeyi × w1 + güncellik × w2 + güven × w3 + kaynak_güveni × w4 − politika_cezası

Burada:

• güncellik eski ama benzer kirliliği önler
• güven halüsinasyon gören "gerçeklerin" istem gerçekliğine dönüşmesini engeller
• kaynak_güveni doğrulanmış araç çıktılarını sıradan bahislere tercih eder
• politika_cezası haklı olmadığı sürece hassas belleği bastırır

Ele alınacak uç durum: yüksek alaka düzeyine sahip iki çakışan bellek.
Çözüm: her ikisini de belirsizlik açıklamasıyla dahil etmek veya açıklayıcı bir soru tetiklemek.

Güvenlik sınırları: saklama, rıza ve sanal alan

Kalıcı bellek bir saldırı yüzeyidir. Koruyucu önlemlere ihtiyacınız var:

Açık politikaya sahip bellek sınıfları

• izin verilen
• maskelenmiş
• hiçbir zaman depolanmayan

Kullanıcı tarafından görülebilen bellek kontrolleri

• incele
• düzenle
• sil
• "son N günü unut"

Kapsamlı yürütme sanal alanıBelleği güvenli araç yürütmeyle eşleştirin (nono gibi aracı sanal alan projelerinde tartışıldığı gibi). Bellek, örtülü geniş araç izinleri vermemelidir.

İstem enjeksiyonu direnciDoğrulanmadan asla ham harici talimatları güvenilir kullanıcı tercihi olarak kalıcı hale getirmeyin.

Şifreleme + erişim günlüğüVerileri durağan halde şifreleyin, hassas bellek güncellemelerini imzalayın ve okuma/yazma denetim izlerini tutun.

Uygulama planı (referans API)

Tipik bellek hizmeti uç noktaları:

• POST /memory/extract — aday olayları gönder
• POST /memory/upsert — normalleştirilmiş bellek yaz
• POST /memory/query — ilgili bellekleri al
• POST /memory/confirm — açık kullanıcı onayı
• DELETE /memory/{id} — belleği kaldır
• POST /memory/forget — politika tabanlı toplu silme

Apidog ile OpenClaw bellek API'lerini test etme

Bellek sistemleri hassas şekillerde başarısız olur: eski durum, yarış koşulları, politika sızıntıları, sıralama regresyonları. İşte Apidog bu noktada doğal olarak devreye girer.

Apidog ile tasarım, hata ayıklama, otomatik test, alay etme (mocking) ve dokümanları tek bir iş akışında tutabilirsiniz.

1) Önce sözleşmeyi tasarlayın

Bellek uç noktalarını ve kısıtlamalarını (enum türleri, hassasiyet seviyeleri, TTL kuralları) tanımlamak için OpenAPI şema-öncelikli bir iş akışı kullanın. Bu, aracı mantığı ile bellek arka ucu arasındaki kaymayı önler.

2) Bellek davranışı için senaryo testleri oluşturun

Şunlar için otomatik test senaryoları oluşturun:

• yinelenen güncelleme/ekleme (upsert) idempotanlığı
• çakışma çözümü (eski yüksek güvenliğe karşı yeni düşük güvenliğe sahip)
• politika uygulama (asla depolanmayan alanlar reddedilir)
• unutma API'sinin kalıcı silme ve mezar taşı davranışı
• token kısıtlamaları altında sorgu bütçesi kırpması

3) Sıralama çıktıları için görsel doğrulamalar kullanın

Yalnızca durum kodlarını kontrol etmek yerine, sıralanmış alanları ve puan sıralamasını doğrulayın. Bellek hataları genellikle "doğru yanıt, yanlış öncelik" içinde gizlenir.

4) Bağımlı araçları sahteleyin (mock)

Çıkarma yollarını belirleyici bir şekilde yeniden üretebilmek için yukarı akış sinyalleri (takvim/görev araçları) için akıllı sahte yanıtlar kullanın.

5) CI/CD kalite geçitleri ekleyin

Her bellek puanlamasında veya politika değişikliğinde regresyon testleri çalıştırın. Sıralama kalitesi düşerse veya politika kontrolleri başarısız olursa, dağıtımı engelleyin.

6) Dahili bellek API dokümanlarını otomatik oluşturun

Kalıcı bellek; arka uç, QA, güvenlik ve ürün ekiplerini etkiler. Etkileşimli dokümanlar, koordinasyon yükünü azaltır ve beklenen davranışı hızla netleştirir.

Yaygın hata modları ve bunları nasıl ayıklayacağınız

1. Bellek şişkinliği

Belirti: Gecikme ve token kullanımı haftalar içinde artar.
Düzeltme: TTL varsayılanları, sıkıştırma işleri, daha katı çıkarma eşikleri.

2. Tercih değişkenliği

Belirti: Asistan, çakışan kullanıcı tercihleri arasında gidip gelir.
Düzeltme: Yüksek etkili güncellemeler için onay isteyin; kararlı belleği değiştirmeden önce histerezis ekleyin.

3. Sessiz politika ihlalleri

Belirti: Hassas veriler geri alma bağlamında görünür.
Düzeltme: Kalıcılıktan önce ve geri almadan önce tekrar politika motoru; kırmızı ekip testleri ekleyin.

4. Geri alma alakasızlığı

Belirti: Anlamsal olarak benzer ancak görevle ilgisiz bellek bağlama hakim olur.
Düzeltme: Görev odaklı yeniden sıralama özelliklerini ve meta veri filtrelemesini artırın.

5. Eşzamanlı yazma yarışları

Belirti: Aynı kullanıcı akışını birden fazla işçi işlediğinde kaybolan güncellemeler.
Düzeltme: İyimser kilitleme (version), belirleyici birleştirme anahtarları ve idempotanlık tokenları.

OpenClaw ile hafif alternatifler: bellek ödünleşim özeti

Nanobot gibi projeler geçerli bir ödünleşimi vurgular: daha küçük sistemler daha hızlıdır ve üzerinde akıl yürütmek daha kolaydır, ancak genellikle kalıcı kişiselleştirme derinliğinden feragat ederler.

OpenClaw'un değer teklifi, zaman içinde daha güçlü süreklilik ve aracı kullanışlılığıdır. Maliyeti daha fazla karmaşıklıktır:

• daha zengin depolama mimarisi
• politika yönetimi yükü
• daha katı test disiplini

Kullanım durumunuz kısa ömürlü otomasyon ise, hafif çözümler kazanabilir. Biriken uzun vadeli asistan davranışına ihtiyacınız varsa, kalıcı bellek mimarisi mühendislik yatırımına değerdir.

Son çıkarımlar

OpenClaw kalıcı belleği, üç ilke dengede kaldığında çalışır:

1. Seçici kalıcılık (daha az depola, daha iyi depola)
2. Maliyet bilincine sahip orkestrasyon (önce ucuz kontroller, gerektiğinde model çağrıları)
3. Politika öncelikli güvenlik (rıza, saklama kontrolleri, denetlenebilir erişim)

Belleği bir istem hilesi olarak değil, birinci sınıf bir alt sistem olarak ele alın. Sözleşmeleri tanımlayın, sıralama davranışını test edin, politika geçitlerini uygulayın ve zaman içindeki kaymayı gözlemleyin.

Bu yığını uyguluyorsanız, Apidog bellek API'lerini standartlaştırmanıza, senaryo tabanlı regresyon testleri çalıştırmanıza, yukarı akış araçlarını taklit etmenize ve dahili dokümanları aynı doğru kaynaktan yayınlamanıza yardımcı olur. Ücretsiz deneyin—kredi kartı gerekmez—ve bellek hizmetinizi üretim kullanıcılarına ulaşmadan önce doğrulayın.