Sorun: Ajan uzun çalıştıkça çökme ihtimali artıyor
Bir kodlama ajanını terminalde çalıştırırken süreç ölürse dert değil. Ekrana bakarsın, ne olduğunu görürsün, “devam et” dersin. Ama ajan bir sunucuda, kimse başında değilken çalışıyorsa durum değişiyor. Konteyner yeniden dağıtılır, makinenin belleği biter, laptop uykuya geçer. Ajan o an yarım bir dosya düzenlemesinin ya da bir API çağrısının ortasında olabilir.
Bunu çözmek için çoğu ekip kendi altyapısını yazıyor: mesajları saklayan tablolar, kuyruklar, arayüze canlı akış, yeniden deneme mantığı. Syntax’ın videosundaki örnekte bu özel kod yaklaşık 8.000 satır tutmuş. Videoya göre ajan Pi Durable’a taşınınca bu kodun hepsi silinebilmiş.
Dayanıklı ajan ne demek?
Fikir, pg_durable yazısında anlattığımız dayanıklı çalıştırma (durable execution) ile aynı: Her adımı yapmadan önce kaydet. Süreç ölürse yeni süreç kaydı açsın, yarım kalan işleri bulsun ve son kayıt noktasından sürdürsün.
Pi Durable bunu ajanlara uyguluyor. Model isteği, araç çağrısı, eski mesajları özetleme (compaction), hepsi birer görev (task). Her görev ilerlemeden önce depoya bir kayıt noktası yazıyor. Depo olarak bellek, SQLite ya da JSONL dosyası hazır geliyor. Arayüz küçük, yani Postgres ya da bir anahtar-değer deposu üstüne kendin de yazabiliyorsun.
Zor kısım: Hangi adım tekrar çalışabilir?
Yarıda kesilen bir model isteğini tekrar göndermek sorun değil. Yarım cevap konuşma kaydında “iptal edildi” diye işaretli kalıyor. Araçlarda iş daha hassas. Bir dosyayı okumak iki kez yapılabilir, bir faturayı kesmek yapılamaz.
Pi Durable bu yüzden her araçtan açıkça söylemesini istiyor. Bir araç replay: "safe" diye işaretlenmişse çökmeden sonra baştan çalışıyor. İşaretli değilse çalıştırılmıyor; model “bu çağrı yarıda kesildi” bilgisini, o ana kadarki çıktıyla birlikte alıyor ve ne yapacağına kendisi karar veriyor. Buna idempotency deniyor: Bir işlemi iki kez yapmanın, bir kez yapmakla aynı sonucu vermesi.
Aynı fikir gelen mesajlar için de var. Bir mesaja requestId verirsen, çökmeden sonra aynı mesajı tekrar gönderen istemci yeni bir iş başlatmıyor, ilk gönderimin cevabını geri alıyor.
Başka neler var?
- Çok istemci: Aynı konuşmaya birden fazla ekran bağlanabiliyor. Geç katılan istemci önce konuşmanın son hâlini, sonra sadece değişiklikleri alıyor. Herhangi biri çalışan ajanı yönlendirebiliyor.
- Çatallanma (fork): Bir konuşma, kaydının herhangi bir noktasından dallanabiliyor. Earendil’in örneği bir Slack kanalı: Kanal bir konuşma, içindeki bir thread onun çatalı. İkisi aynı anda çalışıyor.
- Uygulama durumu: Yapılacaklar listesi ya da plan gibi veriler, konuşma kaydıyla aynı işlemde kaydediliyor. Böylece kaydedilen durum, ajanın yaptıklarıyla hiçbir zaman çelişmiyor.
- Çalışırken kod değiştirme: Bir eklentiyi yenisiyle değiştirdiğinde çalışan araç çağrısı eski kodla bitiyor, sonraki çağrı yeni kodu kullanıyor.
Pi Durable, Pi 1.0 ile birlikte 1 Ekim’de çıktı. Önce Pi 1.0 yazısında kısaca bahsetmiştik. Kodlama ajanı Pi’nin yerini almıyor, her türlü ajan uygulaması için bir çatı. MIT lisanslı, TypeScript ile yazılmış ve hâlâ deneysel: README, API’nin sürümler arasında haber vermeden değişebileceğini söylüyor.
Videodaki örnek
Videoda bir hata takip servisi olan Sentry’ye bir hata düşüyor ve bu, kimse bir şey yazmadan ajanı başlatıyor. Ajan düzeltmenin ortasında durduruluyor, sonra tam kaldığı yerden devam ediyor ve tek bir pull request açıyor. Açıklamada bir de hazır istem var: Ajanına Pi Durable’ın README’sini ve otuzdan fazla örneğini okutup, kendi projende neyin yerine geçeceğini, hangi araçlarının iki kez çalıştırılmasının güvenli olduğunu ve geçişin risklerini sormak. Kod değiştirmeden, sadece analiz.
Düşün
- Senin projende bir ajan ya da arka plan işi yarıda kesilse hangi adım iki kez çalışınca zarar verir?
- Uzun süren işleri bugün nasıl takip ediyorsun? Süreç ölünce elinde ne kalıyor?
Videoyu izle
Kaynaklar (5, İngilizce)
Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.