Agent otomasyonu ölçek büyüdükçe aniden bozuluyorsa sorun çoğu zaman modelde veya betikte değil, tarayıcı ortamı katmanındadır. Bu yazı dört yaygın hata modelini, gözlemlenebilir belirtilerini ve bunlara karşı uygulanabilecek mühendislik yaklaşımlarını açıklar.
LangChain, AutoGen veya CrewAI ile bir Agent kurup Playwright ya da Puppeteer üzerinden web sitelerini kullanmasını sağlamak çok zor değildir. Asıl zor olan, onun kesintisiz şekilde çalışmaya devam etmesini sağlamaktır.
İlk kullanıma alındığında sorunlar genellikle hemen görünmez. Görev hacmi arttıkça anormallikler yoğunlaşır: siteler görevleri engeller, hesap oturumları aniden geçersiz olur veya aynı anda çalışan birkaç Agent birbirinin durumuna müdahale eder. İlk tepki çoğu zaman koda dönüp bakmaktır; incelemenin sonunda ise kodda sorun olmadığı anlaşılır.
Sorun çoğu kez tarayıcı ortamı katmanında ortaya çıkar. Yoğun çalışan projelerde hatalar aslında birkaç tekrarlayan biçime ayrılır. Bunları tanıdıktan sonra yönetmek çok karmaşık değildir.
Ortam hazır olmadan işe başlamak
Yeni oluşturulan bir tarayıcı ortamı ilk iş olarak doğrudan bir görevde kullanılırsa girişin başarısız olması, sayfa öğelerinin eksik yüklenmesi veya daha ilk adımda doğrulama çıkması sık görülen sonuçlardır. Nedeni basittir: bu ortamın ziyaret geçmişi, çerezleri veya herhangi bir gezinme izi yoktur. Platform açısından tamamen yabancı bir cihaz gibi görünür ve bu nedenle güven seviyesi doğal olarak düşüktür.
Gözlemlenebilir işaret şudur: hatalar ortam oluşturulduktan sonraki ilk birkaç görevde yoğunlaşır. Aynı görev bir süredir kullanılan başka bir ortama taşındığında çoğu zaman normal biçimde tamamlanır.
Doğru yaklaşım, ortamın hazır olmasını varsayılan bir kabul yerine açık bir durum olarak ele almaktır. Ortam oluşturulduktan sonra bir süre düşük yoğunluklu gezinme yapmasına izin verin ve durumu kararlı hale geldikten sonra gerçek görevleri atayın. Zamanlayıcı da görevi göndermeden önce bu hazırlık adımını kontrol etmeli, yeni ortamı hemen kullanmamalıdır.
Birden fazla görev aynı ortam için yarışıyor
Eşzamanlılık arttığında en belirgin belirti süreçlerin birikmesi, belleğin dolması ve sistemin yavaşlamasıdır. Daha zor olan gizli hatalardır: iki görev aynı çerezleri ve yerel depolamayı sırayla kullanır, A'nın oturum durumu B'ninkini devre dışı bırakır ve günlüklerde rastgele bir görevin ara sıra başarısız olduğu görülür. Sorunun yerini bulmak zordur.
Bu noktada tarayıcı ortamlarını tahsis edilebilen ve serbest bırakılabilen kaynaklar gibi ele almak gerekir. Görev başladığında bir ortam alır, bittiğinde bırakır ve görev ile ortam arasında bire bir ilişki kurulur. Ortamların depolama alanları birbirine görünmez, böylece bir görevin oturum durumu diğerine sızmaz. Onlarca Agent paralel çalıştığında bunun “betik içinde çok sayıda tarayıcı süreci açmak” yaklaşımından farkı çok net hale gelir.
Senaryo birden fazla hesap içeriyorsa izolasyon daha da sıkı olmalıdır: her hesap sabit bir ortama bağlanmalı, parmak izi parametreleri ve depolama alanı diğer hesaplarla çakışmamalıdır. PurpleMark burada ortam izolasyonu ve merkezi zamanlama katmanını sağlayarak hesaplarla ortamlar arasında kararlı bir bire bir ilişki kurulmasına yardımcı olur.
Oturumun sona erdiğini kimse fark etmiyor
Bu hata türü kolayca gözden kaçar çünkü mutlaka hata üretmez. Görev çalışmaya devam eder ve günlükler yazılır, ancak aslında dönen sayfa giriş ekranıdır veya veri boştur. Sorun ancak sonuç veri hattına girdikten sonra görülür ve hata ayıklama aşağı akıştan geriye doğru yapılmak zorunda kalır; bunun maliyeti yüksektir.
Çözüm, oturum açma durumunu açık bir önkoşul olarak kontrol etmektir. Görev başlamadan önce mevcut oturumun hâlâ geçerli olduğunu doğrulayın. Süresi dolmuşsa görevin geçersiz durumla devam etmesine izin vermek yerine tam bir giriş akışı çalıştırın. Durumun kendisi ortam katmanında tutulmalıdır: çerezler, yerel depolama ve gezinme geçmişi ortamda saklanır ve ortam yeniden başlatıldığında tamamen geri yüklenebilir; böylece hesap görevleri her seferinde yeniden başlatılmaz.
Pratik bir gözlem: uzun süre çalışan hesaplarda oturum durumunun sık sık değişmesi platform tarafından başlı başına olağandışı bir sinyal olarak görülebilir ve ek doğrulama tetikleyebilir. Gereksiz yeniden girişlerden mümkün olduğunca kaçının.
Bir engelleme tüm grubu durduruyor
Başka bir hata türü bir anda toplu halde ortaya çıkar ve çok sayıda görev aynı anda sonuç üretemez. Site her zaman açık bir ret vermeyebilir; daha sık olarak azaltılmış içerik veya boş sayfa döndürür. Agent anlamsız verilerle ilerlemeye devam eder ve sorun ancak veri aşamasında ortaya çıkar.
Böyle bir durumda ilk iş engellemeyi sıradan bir hatadan ayırmaktır. Aynı grup ortam benzer zamanlarda topluca anormal davranıyorsa sorunun ortam katmanında olması kuvvetle muhtemeldir. Yeniden denemeye devam etmek yalnızca etki alanını büyütür; bu nedenle önce bu ortamları durdurup izole etmek, ardından tetikleyiciyi araştırmak gerekir.
Yaygın tetikleyiciler üç yönde toplanır: birden fazla ortam neredeyse aynı WebGL, Canvas, yazı tipi listesi veya motor sürümü gibi aşırı benzer parmak izi yapılandırmaları kullanır; çıkış IP'si, saat dilimi ve dil birbirine uymaz, örneğin ABD IP'si Asya saat dilimiyle eşleştirilir; ya da işlem aralıkları fazla düzenlidir ve ritmin kendisi ayırt edici bir özelliğe dönüşür. Yapılandırmayı tutarlı hale getirin, ritmi kontrol edin ve hem ortam durumunu hem görev sonuçlarını günlükleyin ki toplu hata ortaya çıkmadan önce belirtiler görülebilsin.
Bu katmanı ayrı ele almak
Olgun projeler genellikle tarayıcı ortamını Agent'tan ayırıp bağımsız bir katman olarak yönetir: Agent planlama ve karar vermeden, ortam katmanı kimlik ve durumdan, yürütme katmanı ise yine Playwright veya Puppeteer'dan sorumludur. Bu ayrım yapıldığında kimliğin tutarlı olup olmadığı, durumun geri yüklenip yüklenemediği ve görevlerin birbirinden izole edilip edilmediği için net bir yönetim alanı oluşur.
Geriye dönüp bakıldığında yukarıdaki dört hata türünün ortak bir noktası vardır: sorun modelde de betik mantığında da değildir. Model ve kod elbette geliştirilmeye devam etmelidir, ancak otomasyonun uzun süre kararlı çalışıp çalışmayacağını çoğu zaman daha alttaki bu katman belirler.
Bu içerik teknik araştırma ve geliştirme uygulamalarını paylaşmak amacıyla hazırlanmıştır. Otomasyon yöntemleri yasal ve kurallara uygun biçimde, hedef platformun hizmet koşullarına ve geçerli yerel yasa ve düzenlemelere uyularak kullanılmalıdır.
