Timeout bir hata anlamına gelmez: agent yeniden denemeleri neden idempotent işlem ID'lerine ihtiyaç duyar

dev.to'da yayınlanan bir yazı, agent dağıtımlarının araçları gerçek sistemlere yazmaya başladığı anda karşılaştığı bir hata modunu inceliyor: sunucu değişikliği zaten uyguladıktan sonra zaman aşımına uğrayan bir istek. Agent timeout'u görür, yeniden dener ve sonuç iki yayınlanmış doküman olur — loglar ise temiz bir kurtarma hikayesi anlatır. Yazar bunu bir kıyaslama sonucu olarak değil, bir tasarım senaryosu olarak çerçeveliyor ve bir agent'a dış durumu değiştiren araçlar verilmeden önce şu sorunun yanıtlanması gerektiğini savunuyor: sistem, bir eylemin etkili olup olmadığını belirleyemediğinde nasıl davranmalı?

Timeout belirsizlik kanıtlar, hata değil

Yazıya göre bir timeout yalnızca çağıran tarafın zamanında bir sonuç alamadığını gösterir; uzak işlemin başarısız olup olmadığı hakkında hiçbir şey söylemez. Yazar, tam olarak bu belirsizliği ve standart çözümü — yeniden denemeleri güvenli kılan, çağıran tarafından sağlanan istek tanımlayıcılarını — ele alan Amazon Builders' Library materyaline dikkat çekiyor. Agent iş akışları için bu belirsizlik modelin inisiyatifine bırakılmamalı, uygulama sözleşmesinde açıkça tanımlanmalıdır.

Belirsizliğe kendi durumu verin

Boolean bir başarı bayrağı uzak bir yazma işleminin her sonucunu tanımlayamaz. Yazı beş durum öneriyor: Ready (yetkilendirilmiş ve kalıcı olarak kaydedilmiş), In flight (bir worker tarafından üstlenilmiş ve hedefe ulaşmış olabilir), Succeeded (hedef sonucu doğrulamış), Failed (etkili olmadığına dair kesin kanıt) ve Unknown (etkili olmuş olabilir ama kanıt eksik, bu yüzden uzlaştırmaya gönderilir). Süresi dolan worker lease'leri özel dikkat gerektirir, çünkü bir worker uzak işlemin uygulanmasından sonra çökebilir. UI tarafında yazar dürüst bir ifade öneriyor — istek gönderildi ancak tamamlanma doğrulanmadı — ki bu "Tamamlandı" kadar tatmin edici değildir ama gerçeği yansıtır.

Her mantıksal işlem için tek bir kimlik

Bir tool-call ID'si tek bir denemeyi tanımlar; uygulamanın denemeler boyunca süren bir kimliğe ihtiyacı vardır. Yazı, bir işlem ID'sini, aktör ID'sini, eylemi, hedefi, içerik sürümünü ve bir istek parmak izini birleştiren, uygulama kodunda oluşturulan ve kalıcı olarak saklanan, yeniden denemeler ve yeniden başlatmalar boyunca taşınan bir kayıt taslağı çiziyor. Hedef idempotency key destekliyorsa, aynı anahtar o API'nin sözleşmesi altında aynı işlem için yeniden kullanılmalıdır. Parmak izinin ayrı bir görevi vardır: değişen parametreleri yakalamak, yani bir işlem ID'sinin farklı bir payload ile yeniden kullanılması bir çakışma doğurmalıdır. Yazar, tek başına bir hash niyeti ifade edemez diye not ediyor — iki kasıtlı işlem aynı payload'u taşıyabilir. Tanımlayıcılar aktöre veya tenant'a göre kapsamlandırılmalı, benzersizlik atomik olarak zorlanmalı ve sağlayıcının saklama penceresi kontrol edilmelidir, çünkü süresi dolmuş bir anahtar artık bir yeniden denemeyi korumaz.

Yetkilendirmeyi onaylanan eyleme bağlı tutun

Bir iş akışı onay gerektirdiğinde, tam olarak neyin onaylandığını kaydedin: eylem, hedef, payload sürümü ve geçerli limitler. Tam olarak o işlemin yeniden denemesi, politika izin veriyorsa kayıtlı yetkilendirmeyi yeniden kullanabilir, ancak payload'u değiştiren bir model farklı bir eylem önermiş olur ve eski onayı sessizce devralmamalıdır. İzinler ayrıca çalıştırma zamanında yeniden kontrol edilmelidir, çünkü kalıcı bir onay kaydı sonradan yapılan bir iptalin üzerine gitmemelidir.

Yerel bir defter uzak bir transaction'ı kapatamaz

Zor olan sıra şudur: işlemi yerel olarak kaydet, uzak yazmayı gönder, hedef uygular ve worker sonucu kaydetmeden önce çöker. Hiçbir yerel transaction bu adımları ilgisiz bir servis ile atomik yapamaz. Kurtarma o zaman hedefe bağlıdır: uygun idempotency desteği varsa, o sözleşme altında yeniden deneyin; işlem ID'sine göre yetkili bir sorgulama varsa, sorgulayın ve uzlaştırın; ikisi de yoksa, belirsiz sonucu tutun ve başka bir etkili yazma yapmadan önce incelemeye yönlendirin. Yazı iki uyarı ekliyor: eventual consistency altında boş bir arama sonucu kesin olmayabilir ve kalıcı bir kuyruk teslimatı iyileştirir ama tüketicinin yinelenen deneme sorununu ortadan kaldırmaz.

Can sıkıcı sınırı test edin

Yayına almadan önce yazar, can sıkıcı koşulları enjekte etmeyi öneriyor: uzak işlem uygulandıktan sonra kaybolan bir yanıt, aynı işlemi gönderen iki worker, farklı bir payload ile gelen aynı ID, işlemden sonra ölen bir worker, geçici olarak bayat bir sorgulama ve süresi dolmuş bir idempotency kaydı. Bunlar modelin etrafındaki uygulamayı sınar — modelin daha dikkatli olması istenen promptlar değildir.

Neden önemli

Agent'lar gerçek yan etkileri olan sistemlere bağlanıyor ve bu hata modu sessizdir: log sağlıklı görünür, yeniden deneme bir dayanıklılık gibi görünür ve yinelenme yalnızca aşağı akışta ortaya çıkar. Yazının pratik inceleme sorusu benimsenmeye değer: bir yazma uygulanır ve yanıtı kaybolursa, sonraki worker ne olduğunu karar vermek için hangi kanıtı kullanacak? Tek yanıt agent'ın bunu çözeceği ise, kurtarma protokolü tamamlanmamıştır — idempotency, açık belirsizlik durumları ve uzlaştırma uygulama sözleşmesine aittir, modelin inisiyatifine değil.