Cloudflare ajan altyapısında işin sahibi kim?

Bir müşteri destek talebi geliyor. Ajan önce sipariş durumunu sorguluyor, ardından iade koşullarını kontrol ediyor. Yanıt vermeden hemen önce bağlantı kopuyor. Müşteri birkaç dakika sonra yeniden yazdığında, aynı sorgular tekrar mı yapılacak? İade talebi iki kez mi açılacak? Üretimde ajan çalıştırmak, iyi bir cevap üretmekten çok bu sorulara tutarlı yanıt verebilmeyi gerektiriyor.

Bu yazıda Cloudflare OS derken ayrı bir işletim sistemi ürününü değil, Cloudflare’ın açık kaynak Agents SDK, Think ve platform hizmetlerinden oluşan ajan araç takımını kastediyorum. SDK durum ve yürütme altyapısı sağlıyor. Think ise modelin araç çağırıp sonuçları değerlendirerek yanıt üretmesini sağlayan daha belirgin bir ajan döngüsü sunuyor. Bu iki katmanı aynı şey gibi görmek, tasarım kararlarını bulanıklaştırıyor.

Ajan döngüsü ile çalıştığı yer farklı şeyler

Bir modelden yanıt almak için tek bir istek yeterli olabilir. Ajanın işi ise çoğunlukla birkaç adımdan oluşur: bir kaynağı okur, gerekirse bir araç kullanır, sonucu değerlendirir ve devam eder. Harness dediğimiz katman bu döngüyü düzenler. Fakat döngünün nerede çalışacağı, durumunun nerede saklanacağı ve bir kesintiden sonra nasıl toparlanacağı ayrıca çözülmelidir.

Cloudflare Agents SDK’nın temelindeki Agent sınıfı, Durable Object üzerinde çalışır. Bir örnek kendi kimliğine, kalıcı depolamasına ve yaşam döngüsüne sahiptir. Geliştirici, örneğin her müşteri hesabı için ayrı bir ajan kimliği tasarlayabilir. Böylece bir hesabın konuşma bağlamı başka bir hesabın bağlamından ayrılabilir. Bu ayrım kendiliğinden doğru yetkilendirme anlamına gelmez; kimlik doğrulaması ve hangi hesabın hangi ajana erişebileceği uygulamada ayrıca belirlenmelidir.

Think daha üstte durur. Mesajların tutulması, araçlarla yürüyen sohbet döngüsü, akış halinde yanıt ve kesilen akışa yeniden bağlanma gibi ihtiyaçları bir temel sınıfta bir araya getirir. Her işi sohbet olarak kurmak zorunda değilsiniz. Belirli adımları olan bir arka plan süreci için SDK ile Cloudflare Workflows kullanmak daha anlaşılır olabilir. Seçim, ürünün hangi tür durumu kalıcı tutması gerektiğine bağlıdır.

Kesinti senaryosunu baştan çizmek

İade örneğine dönelim. Ajan sipariş bilgisini okuduktan sonra müşteriyle bağlantısı kesilirse konuşmanın durumu korunabilir. Ama harici iade API’sine gönderilen isteğin sonucunu yalnızca sohbet geçmişinden çıkaramayız. Karşı sistem işlemi yaptıktan sonra yanıt kaybolmuş olabilir. İşte burada kalıcı durum ile işlemin tam bir kez yapılması arasındaki fark ortaya çıkar.

Cloudflare, ajan içindeki uzun işlerin kesintiye dayanması için fibers sunuyor. runFiber() yürüyen işi kayıt altına alabiliyor, stash() ara sonuçları saklıyor. Yeniden etkinleşme durumunda toparlama kodunu geliştirici yazıyor. Ayrı adımlara bölünmüş, kendi tekrar deneme mantığı olan süreçler için Workflows bir başka seçenek. Bir adım tamamlandıysa daha sonra oradan devam edebilmesi yararlı; fakat dış sistemdeki yan etkiler için yine de idempotency anahtarı, durum sorgusu ve açık bir uzlaştırma kuralı gerekir.

Pratik tasarımda iade oluşturma isteğine sipariş ve talep kimliğinden türetilmiş sabit bir işlem anahtarı verilir. Tekrar çağrı geldiğinde önceki işlemin sonucu okunur. API böyle bir anahtar desteklemiyorsa uygulama, talebin gönderildiğini ve karşı taraftaki durumunu ayrı kayıtlarla izlemek zorundadır. Harness kesintiyi daha iyi yönetir, ancak ödeme veya iade sisteminin iş kurallarını sizin yerinize belirlemez.

Onay beklerken ne kalmalı?

Her talep otomatik sonuçlanmamalı. Örneğin iade tutarı sözleşmedeki istisna sınırına yaklaşıyorsa bir insanın kararı gerekebilir. Böyle bir adımda ajanın kullanıcıya hızlı yanıt vermesi ile fiili işlemi gerçekleştirmesi birbirinden ayrılmalı. “Talebinizi aldık” demek başka, “iadeniz tamamlandı” demek başka.

Workflows, uzun süren adımlar ve insan onayının araya girdiği süreçler için kullanılabiliyor. Ama onay ekranını eklemek tek başına yeterli değil. Kararı kimin vereceği, onayın ne kadar süre geçerli olduğu, onaydan sonra koşullar değişirse hangi verinin yeniden okunacağı açıkça tanımlanmalı. Sipariş durumu onay beklerken değiştiyse ajanın eski veriye dayanarak işlem yapması engellenmeli.

Buradaki küçük ama önemli ayrıntı şu: ajanın durumunu korumak, iş kararının geçerliliğini korumaz. Kalıcı bir konuşma, doğrulanmamış bir kararın da kalıcı olmasına neden olabilir. Üretim sistemlerinde her kritik araç çağrısının öncesinde güncel veri ve yetki kontrolü yapılması bu yüzden önemlidir.

Operasyon ekibinin göreceği kayıt

Bir talep müşteri temsilcisine devredildiğinde temsilciye modelin bütün ara düşüncelerini dökmek gerekmez. Daha yararlı kayıt, talep kimliği, kullanılan sipariş verisinin zamanı, çağrılan araç, dış sistemin yanıtı ve bekleyen onay durumudur. Müşteri aynı soruyu tekrar sorduğunda ekip hangi adımda kalındığını bu kayıtlardan anlayabilir.

Cloudflare altyapısı durum, zamanlama ve gözlemlenebilirlik için yapı taşları verir. Bunların ne kadarını kullanacağını ve kayıtları hangi süreyle saklayacağını ekip belirler. Kişisel verilerin loglara gereksiz yere taşınmaması da aynı tasarımın parçasıdır. Örneğin bir destek özetine tüm adres bilgisini kopyalamak yerine sipariş kimliğini ve yetkili sistemdeki referansı tutmak çoğu zaman daha uygundur.

Başlangıç için üç soru işe yarar: Hangi işlem tekrar çağrıldığında güvenli kalır? Hangi adımda insan onayı gerekir? Bir hata sonrasında operasyon ekibi gerçekte ne olduğunu nereden görecek? Bu sorular koddan önce yanıtlanırsa, SDK’nın kalıcı durum ve zamanlama özellikleri somut bir iş akışına oturur. Yanıtlanmazsa daha dayanıklı bir altyapı üzerinde daha hızlı tekrar eden hatalar üretilebilir.

Cloudflare’ın araç takımı bir ajan örneğinin nasıl çalışacağını ve kesintiden sonra nasıl toparlanacağını çözmeye yardımcı olur; ekip içindeki rolü ve hesap verebilirliği ise ayrıca tanımlamak gerekir. Bu ilişkiyi organizasyon düzeyinde kurmak için agentic-organization, AI ajanlarını organizasyon şemasında birinci sınıf üye olarak yönetmeye odaklanan self-hosted, dosya tabanlı bir platformdur.