Ajanlarda görev durumu nasıl saklanır?

Bir ajanın görev durumunu güvenilir biçimde saklamak için konuşma geçmişini tek başına yeterli görmeyin; her görev için kalıcı bir kayıt oluşturun ve ajanın her adım sonunda bu kaydı güncellemesini sağlayın. En azından görev kimliği, mevcut durum, tamamlanan adımlar, bekleyen işlem, kullanılan girdiler, hata bilgisi ve son güncelleme zamanı tutulmalıdır. Böylece işlem kesilirse ajan kaldığı adımdan devam edebilir; aynı adımı ikinci kez çalıştırmamak için de idempotency kontrolü yapılabilir.

Görev durumu neyi ifade eder?​

Görev durumu, ajanın yalnızca ne konuştuğunu değil, işi hangi aşamada bıraktığını gösteren yapılandırılmış veridir. Örneğin bir müşteri destek ajanı için durum kaydı şöyle düşünülebilir:


Buradaki status ajanın hangi aşamada olduğunu, completed_steps daha önce ne yaptığını, pending_action ise sıradaki işi gösterir. Bu kayıt, modelin belleği değildir. Model her çağrıda bu veriyi okuyarak karar verir; kalıcılığı sağlayan bölüm veritabanı, dosya, anahtar-değer deposu veya iş akışı aracıdır.

Hangi bilgiyi nerede saklamalısınız?​

Kısa süreli bağlam ile kalıcı görev kaydını ayırın. Modelin mevcut yanıtı üretmesi için gereken son mesajlar veya geçici araç çıktıları çalışma belleğinde tutulabilir. Görevin yeniden başlatılabilmesi için gereken bilgiler ise kalıcı depoya yazılmalıdır.
Görev durumunu uzun bir metin özeti olarak saklamak yerine alanları belirli bir şemaya bağlamak daha güvenlidir. Özet metni okunabilir olsa da ajanın hangi adımı tamamladığını veya hangi aracın başarıyla çalıştığını kesin olarak ayırt etmek zorlaşır.

Kalıcı durum akışı nasıl kurulmalıdır?​

Görev kaydını okuyun; dış yan etkiden önce kararlı işlem anahtarını ve işlem niyetini kalıcı kayda yazıp yürütmeyi atomik olarak ayırın. Sonucu doğruladıktan sonra tamamlanma durumunu kaydedin. Dış sistemde başarı ile yerel tamamlanma kaydı arasındaki çökme, sırf yerel atomik yazmayla çözülmez: destekleniyorsa dış servise aynı idempotency anahtarını iletin; belirsiz sonucu durum sorgusuyla uzlaştırmadan işlemi yeniden başlatmayın.

1. Görevi benzersiz bir kimlikle başlatın. Her iş için task_id üretin; örneğin aynı kullanıcının iki farklı talebi birbirine karışmamalıdır.
2. Mevcut durumu depodan okuyun. Kayıt yoksa created veya pending gibi başlangıç durumu oluşturun; kayıt varsa ajana son durum, bekleyen işlem ve gerekli girdileri verin.
3. Ajanın çalışabileceği tek sonraki adımı belirleyin. Ajanın aynı çağrıda kontrolsüz biçimde çok sayıda dış işlem yapması yerine, görev kaydındaki bekleyen işlem üzerinden ilerleyin.
4. Araç sonucunu doğrulayın. Bir API başarılı HTTP yanıtı döndürse bile iş kuralının gerçekten gerçekleştiğini kontrol edin; örneğin sipariş numarasının ve işlem durumunun beklenen değerleri taşıdığını doğrulayın.
5. Durumu atomik biçimde güncelleyin. Araç sonucu başarılıysa completed_steps alanını ve pending_action değerini birlikte değiştirin. Eski ve yeni durumun karışmaması için atomik veritabanı işlemi kullanın. Birden fazla çalışan varsa sürümü yalnız saklamakla yetinmeyin; beklenen sürümle koşullu güncelleme yaparak çakışan geçişi reddedin.
6. İşlem kimliğini kaydedin. Idempotency anahtarını dış çağrıdan önce saklayın; dış sistemin döndürdüğü operation_id değerini alındığında aynı kayda ekleyin. Anahtarı yalnız kaydetmek yeterli değildir; yürütücü veya dış servis tekrarı gerçekten tekilleştirmelidir.
7. Son durumu kontrol edin. Görev tamamlandıysa completed, kullanıcı yanıtı bekleniyorsa waiting_for_input, geçici hata varsa retryable_error gibi açık bir durum yazın. Ardından kaydı yeniden okuyarak beklenen değerin gerçekten depolandığını doğrulayın.

Durum ile konuşma geçmişini karıştırmayın​

Konuşma geçmişi, ajanın önceki mesajları görmesini sağlar; fakat tek başına güvenilir bir işlem kaydı değildir. Bir mesajda “e-posta gönderildi” yazması, e-postanın gerçekten gönderildiğini kanıtlamaz. Bunun için araç yanıtı, dış sistemdeki doğrulama sonucu ve işlem kimliği ayrıca saklanmalıdır.

Benzer şekilde, uzun süreli kullanıcı tercihi ile tek bir görevin durumu aynı tabloda tutulmamalıdır. “Kullanıcı HTML e-postaları tercih ediyor” kalıcı profil bilgisidir; “bu kampanyanın taslağı onay bekliyor” ise görev durumudur. Ayrı tutulmaları, bir görevin silinmesi veya arşivlenmesinin kullanıcı profilini etkilemesini önler.

Örnek: kesintiden sonra devam etme​

Varsayımsal bir rapor ajanı üç adım çalıştırsın: veriyi alacak, raporu oluşturacak ve raporu gönderecek. Veri alma tamamlandıktan sonra şu durum kaydedilir:


Rapor oluşturmayı sürdürebilmek için alınan veriyi veya erişilebilir kalıcı anlık görüntü bağlantısını da saklayın; fetch-913 kimliği tek başına verinin yerini tutmaz. Veri kalıcı ve erişilebilir durumdaysa ajan pending_action: generate_report adımından devam edebilir. Ancak bu kayıt yalnızca verinin alındığını kanıtlar; raporun e-posta ile gönderildiğini kanıtlamaz. Gönderim için ayrı bir araç sonucu ve operation_id tutulmalıdır.

Hatalı veya eksik durum kaydı nasıl yorumlanır?​

waiting_for_input durumu, ajanın bozulduğu anlamına gelmez; insan yanıtı veya eksik bilgi beklediğini gösterir. retryable_error, aynı işlemin güvenli koşullarda yeniden denenebileceğini belirtir; fakat dış işlemin gerçekten yapılmadığı doğrulanmadan otomatik tekrar başlatılmamalıdır. failed ise yeniden denemeden önce hata nedeni ve son başarılı adım incelenmelidir.

Bir görev beklenmedik biçimde tekrar başlıyorsa önce aynı task_id ile birden fazla kayıt oluşup oluşmadığını, son durumun araç çağrısından önce mi sonra mı yazıldığını ve işlem kimliğinin saklanıp saklanmadığını kontrol edin. Durum kaydı ile dış sistem sonucu çelişiyorsa ajanın tahminine güvenmek yerine dış sistemden gerçek durumu okuyup görevi güvenli bir ara duruma alın.