Ajan çalışmaları neden istek-yanıt modelini kırıyor
Çoğu ajan çerçevesi bir istek-yanıt döngüsü etrafında kurulur: bir prompt gönder, bir tamamlama al, bir tampona ekle, tekrarla. Bu model kısa etkileşimler için çalışır. Saatler boyunca süren, harici sistemleri çağıran, insan girdisini bekleyen ve bir şey onları kesintiye uğratmadan önce kısmen tamamlanan çalışmalar için başarısız olur.
Uzun süreli bir ajan tek bir inference değildir. Bir iş akışıdır: kararlar, tool call'lar, beklemeler ve harici sistemlere yazmalardan oluşan bir dizi. Her adım bağımsız olarak başarısız olabilir. Süreç bir deploy rollout'u tarafından yeniden başlatılabilir. Bir sağlayıcı çağrı ortasında zaman aşımına uğrayabilir. Bir worker tahliye edilebilir. Bunlardan herhangi biri gerçekleştiğinde, çalışma tutarsız bir durumda kalır: bazı yan etkiler gerçekleşmiştir, diğerleri gerçekleşmemiştir ve planı tutan konuşma tamponu kaybolmuştur.
Bir yeniden oynatma mekanizması olmadan, tek kurtarma stratejisi baştan başlamaktır. Baştan başlamak, zaten başarılı olan her harici yazmayı çoğaltır. Bu teorik bir endişe değildir. Bugün çoğu ajan yığınının varsayılan davranışıdır ve ekiplerin neden ad-hoc uzlaştırma betikleri yazdığının ya da bir çökmeden sonra durumu manuel olarak onardığının nedenidir.
Önemli olan iki özellik
Ajanlar için dayanıklı yürütme iki özelliğe dayanır. Her ikisi de dağıtık sistemlerde iyi anlaşılmıştır. Hiçbiri ajan çerçevelerinde standart değildir.
Deterministik yeniden oynatma
Aynı kaydedilmiş kararlar ve tool sonuçları verildiğinde, çalışma aynı noktada devam etmelidir. Bu, deterministik olmayan her girdinin — model çıktısı, tool yanıtı, saat okuması, rastgele tohum — yalnızca ekleme yapılan bir log'a kaydedilmesi anlamına gelir. Yeniden başlatmada, runtime log'u yeniden oynatır, iş akışının deterministik kısımlarını yeniden yürütür ve kaydedilmiş yan etkileri atlar. Çalışma, süreç öldüğünde yürürlükte olan adımdan devam eder.
Bu, bir konuşmayı checkpoint'lemekle aynı şey değildir. Bir konuşma tamponu kayıplı bir özettir. Bir yeniden oynatma log'u, çalışmanın ne karar verdiğinin ve ne gözlemlediğinin kesin bir kaydıdır. Fark, bir adım artık alınamayan bir tool sonucuna bağlı olduğunda ya da modelin yedinci adımdaki çıktısının sekizinci adımın hangi dala gideceğini belirlediği durumlarda önemlidir.
İdempotent etkiler
Her harici yazma, tekrarlanan bir denemeyi no-op yapan bir anahtar taşımalıdır. Çalışma bir ödeme API'sini çağırırsa, çağrı run ID ve step ID'den türetilen bir idempotency key içerir. API aynı anahtarı iki kez alırsa, tekrar ücretlendirmek yerine orijinal sonucu döndürür. Çalışma bir e-posta gönderirse, gönderim anahtarlanır, böylece bir yeniden deneme kopya üretmez. Çalışma bir veritabanına yazarsa, yazma run ve step üzerinde anahtarlanmış bir upsert'tir.
İdempotency ajanın bir özelliği değildir. Ajan ile dokunduğu her harici sistem arasındaki sözleşmenin bir özelliğidir. Bu sözleşmenin tasarlanması, belgelenmesi ve test edilmesi gerekir. Bir prompt'tan çıkarılamaz.
Bunun ajan tasarımını değiştirdiği yerler
Deterministik yeniden oynatma ve idempotent etkileri gereksinim olarak kabul ettiğinizde, birkaç tasarım kararı değişir.
Tool sınıflandırması
Tool call'lar üç gruba ayrılmalıdır:
- Saf: harici etki yok, tekrarlamak güvenli. Bir dosya okumak, bir hash hesaplamak, bir string biçimlendirmek.
- İdempotent: harici etki var, aynı anahtarla tekrarlamak güvenli. Upsert'ler, anahtarlanmış API çağrıları, idempotent mesaj gönderimleri.
- Tekrarlanamaz: güvenle tekrarlanamayan harici etki. Tek seferlik bir bildirim göndermek, bir işlem gerçekleştirmek, soft-delete yolu olmadan bir kaynağı silmek.
Üçüncü sınıf, yeniden oynatmada insan onayı gerektirir. Çalışma, tekrarlanamaz bir etki denendikten sonra ama onaylanmadan önce öldüyse, runtime kendi başına yeniden deneyip denemeyeceğine karar veremez. Belirsizliği ortaya koymalı ve beklemelidir. Bu gerçek bir maliyettir: kurtarmaya bir human-in-the-loop adımı ekler ve bazı çalışmaların müdahale olmadan yakınsayamayacağı anlamına gelir. Alternatif — sessizce yeniden denemek — daha kötüdür.
Dayanıklı bir depoda durum
Ajan durumu, bir konuşma tamponunda değil, açık bir şemaya sahip dayanıklı bir depoda yer almalıdır. Şema çalışmayı tanımlamalıdır: girdileri, mevcut adımı, tamamlanan adımların sonuçları, bekleyen adım ve şu ana kadar tüketilen bütçe. Konuşma, bu durum üzerinde bir görünümdür, durumun kendisi değildir.
Bunun pratik bir sonucu vardır: model değiştirilebilir, prompt yeniden yazılabilir ve çalışma yine de devam edebilir. Durum, modelin context window'una bağlı değildir.
Çalışmaya bağlı bütçe
Bütçe uygulaması bir sürece ya da oturuma değil, dayanıklı çalışmaya bağlanır. Devam eden bir çalışma aynı tavana karşı saymaya devam eder. Çalışma bir çökmeden önce token bütçesinin yüzde 60'ını tükettiyse, yüzde 40'ı kalmış olarak devam eder. Bu, her yeniden başlatmanın sayacı sıfırlaması nedeniyle bir çökme-ve-yeniden başlatma döngü
Mekanizma basittir: bütçe, dayanıklı çalışma kaydındaki bir alandır, her adımda azaltılır ve adımın yan etkisi denenmeden önce kalıcı hale getirilir. Ödünleşim, bütçe kontrollerinin her adıma bir yazma eklemesidir, bu da latency ve depolama maliyetini artırır. Çok sayıda küçük adım yapan çalışmalar için bu ek yük ölçülebilirdir. Alternatif — çökmede bütçe durumunu kaybetmek — daha kötüdür.
Değerlendirme sonuçları
Dayanıklı yürütme, ajan sistemlerinin nasıl test edildiğini değiştirir.
Standart bir test olarak crash-injection
En faydalı test crash-injection'dır: worker'ı her adımda öldür ve çalışmanın aynı terminal duruma yakınsadığını doğrula. Bu bir unit test değildir. Çalışmanın durum makinesi üzerinde bir property test'tir. Önemli olan hataları yakalar: idempotent olmayan adımlar, bir yan etkiden önce kalıcı hale getirilmeyen durum, orijinal yürütmeden sapan yeniden oynatma yolları.
Bir crash-injection harness'ı, worker'ı belirli bir adımda öldürmenin bir yoluna ihtiyaç duyar. Bu, runtime'ın adım sınırlarını hook olarak açığa çıkarması gerektiği anlamına gelir. Bu hook'ları inşa etmek iştir. Onları atlamak, başarısızlık modlarının yalnızca üretimde ortaya çıkması anlamına gelir.
Değerlendirme fixture'ları olarak yeniden oynatma log'ları
Bir yeniden oynatma log'u gerçek bir yörüngenin kaydıdır: girdiler, kararlar, tool sonuçları, yan etkiler. Bu kayıt bir değerlendirme fixture'ı olarak kullanılabilir. Bir ekip, yan etkileri yeniden yürütmeden yeni bir modele karşı bir yörüngeyi yeniden çalıştırabilir. Modelin kararları kaydedilenlerle karşılaştırılır ve farklar analiz edilir.
Bu önemli bir kaymadır. Bugün, ajan görevlerinde yeni bir modeli değerlendirmek genellikle görevi uçtan uca yeniden çalıştırmak anlamına gelir, bu da yan etkileri yeniden yürütmek anlamına gelir, bu da ya bir sandbox kullanmak ya da maliyeti kabul etmek anlamına gelir. Yeniden oynatma log'ları ekiplerin karar kalitesini etki yürütmesinden ayırmasına olanak tanır. Ödünleşim, yeniden oynatma log'larının yalnızca kayıt kadar iyi olmasıdır: orijinal çalışma, log'un yakalamadığı şekillerde deterministik değilse, yeniden oynatma modelle hiçbir ilgisi olmayan nedenlerle sapacaktır.
Önce ne inşa edilmeli
Sıra önemlidir. Yeniden oynatma log'uyla başlayın: kararların, tool sonuçlarının ve adım sınırlarının yalnızca ekleme yapılan bir kaydı. Sonra her harici yazmayı run ve step'ten türetilen bir anahtarla idempotent hale getirin. Sonra tool'ları sınıflandırın ve tekrarlanamaz sınıf için insan onayı ekleyin. Sonra bütçeyi çalışma kaydına bağlayın. Sonra crash-injection harness'ını inşa edin.
Her adım bağımsız olarak faydalıdır. Yeniden oynatma log'u tek başına hata ayıklamayı mümkün kılar. İdempotent yazmalar tek başına kopya yan etkileri önler. Tam sistem, uzun süreli ajanları işletilebilir kılar.
Prompt döngüsü zor kısım değildir. Zor kısım, bir çalışmanın onu başlatan süreçten sağ çıkmasını sağlayan altyapıdır.