Ajanı durduran şey bütçe olmalı, fatura değil

Otonom bir ajanın en pahalı hâli, çalışmayı reddettiği an değil. Yanlış yolda ısrarla ilerlediği an.

Bir insan geliştirici üçüncü başarısız denemeden sonra duruyor ve yaklaşımı sorguluyor. Ajan durmuyor. Aynı hatayı biraz farklı yazarak on beşinci kez deniyor, her denemede bağlamı büyütüyor, ve her büyüyen bağlam bir öncekinden pahalı.

Kullanıcı kendi anahtarını getirdiği için bu maliyet doğrudan onun cebinden çıkıyor. Yani bu bir altyapı optimizasyonu değil, bir ürün sorumluluğu.

Bütçe bir sonuç değil, bir girdi

En yaygın hata maliyeti sonradan raporlamak. Görev bitiyor, kullanıcı ne harcadığını görüyor.

Bu, ısıtıcının faturasını ay sonunda göstermek gibi. Bilgi doğru ama karar anı geçmiş.

Doğrusu bütçeyi görevin girdisi yapmak. Kullanıcı işi başlatırken bir tavan belirliyor ve orchestrator bu tavanı çalışma zamanında takip ediyor. Tavana yaklaşıldığında ajan yeni worker açmıyor, mevcut işi toparlıyor ve elindekiyle duruyor.

Kritik detay şu: tavana çarpınca işi ortada bırakmamak. Yarım kalmış bir değişiklik, hiç başlamamış bir değişiklikten kötü. Bütçe sınırı bir kesme değil, bir iniş prosedürü olmak zorunda.

Bağlam maliyetin kendisi

İkincisi: token maliyeti çoğunlukla modelin ürettiğinden değil, ona gönderdiğinden geliyor.

Bir ajan turu ilerledikçe bağlam büyüyor — okunan dosyalar, komut çıktıları, önceki denemeler. Her adımda bunun tamamını göndermek, uzun bir görevde maliyeti doğrusal değil kareli büyütüyor.

Buradaki iş, bağlamı yönetmek: hangi dosyanın tamamı gerekli, hangisinin sadece ilgili bölümü. Başarısız bir denemenin çıktısı bir sonraki adımda gerçekten lazım mı, yoksa "şunu denedik olmadı" özeti yeter mi.

Bu, model seçmekten daha çok fark yaratan bir mühendislik işi. Ve ölçmesi de kolay: aynı görevi iki bağlam stratejisiyle çalıştırıp maliyeti karşılaştırıyorsun.

Ajan maliyetini düşürmenin en etkili yolu daha ucuz model değil, daha küçük soru.

Doğru işe doğru model

Üçüncüsü, tek modelle çalışmanın gereksizliği.

Bir görevi parçalara bölmek, dosya adı çıkarmak, bir çıktının başarılı olup olmadığına bakmak — bunlar en güçlü modeli gerektirmiyor. Mimari karar vermek, karmaşık bir hatayı çözmek gerektiriyor.

Aynı ajan içinde adım tipine göre farklı model kullanmak, kaliteyi düşürmeden maliyeti ciddi biçimde değiştiriyor. Ama bunu yapabilmenin şartı, hangi adımın hangi sınıfta olduğunu bilmek — yani planlayıcının adımları etiketlemesi.

Döngüyü erken kes

Dördüncüsü ve en çok işe yarayanı: tekrar tespiti.

Bir worker aynı dosyayı üçüncü kez aynı şekilde düzenlemeye çalışıyorsa, dördüncüsü de işe yaramayacak. Aynı test dördüncü kez aynı hatayla patlıyorsa, beşinci deneme para yakmaktan başka bir şey yapmıyor.

Bu döngüleri yakalayıp durmak, tek bir bütçe tavanından daha etkili. Çünkü bütçe tavanı en sonda devreye giriyor; tekrar tespiti israfın başladığı yerde.

Ve durduğunda doğru davranış sessizce başarısız olmak değil — kullanıcıya "buraya kadar geldim, şurada takıldım, şu üç şeyi denedim" demek. Yarım iş artı net bir rapor, kullanıcının devam edebileceği bir şey.

Rakam görünür olmalı

Son olarak, hepsinin görünür olması gerekiyor: bu görev şu ana kadar ne harcadı, tavan ne, hangi adım pahalıydı.

Kullanıcı kendi anahtarını getiriyorsa, harcamayı gizlemenin hiçbir savunması yok. Ve şeffaflığın bir yan faydası var — kullanıcı hangi tür isteğin pahalı olduğunu görünce, daha iyi istekler yazıyor.