Araç “kabul edildi” dediğinde AI ajanının işi bitmiş midir?

İlk olumlu yanıt hangi sözü veriyor?

Bir rapor hazırlama aracı isteğinizi alıyor ve hemen olumlu yanıt dönüyor. Ajan da kullanıcıya “Rapor hazır” diyor. Oysa arka plandaki iş henüz sırada bekliyor olabilir. Buradaki sorun yalnızca yavaş çalışma değildir: Kullanıcıya verilen söz, aracın gerçekten bildirdiği durumun önüne geçmiştir. Doğru takip için isteğin kabulünü, işin yürütülmesini ve çıktının doğrulanmasını ayrı kaydetmek gerekir.

HTTP 202 Accepted, isteğin işlenmek üzere kabul edildiğini, işlemenin tamamlanmadığını ifade eder. Bu yanıt, işin sonunda başarıyla sonuçlanacağına dair kesin bir söz de vermez. Ajanın ilk yanıtı bu sınıra uymalıdır. “İstek alındı; sonuç bekleniyor” demek, henüz elde olmayan bir çıktının hazır olduğunu söylemekten farklı bir kullanıcı beklentisi oluşturur.Kaynak: RFC Editor — RFC 9110 HTTP Semantics, 202 Accepted

Aşağıdaki örnek bütünüyle sentetiktir. J9 işi, R9 raporu ve adresler açıklama amacıyla hazırlanmıştır; gerçek bir servise istek gönderilmez. Amacımız bir HTTP durum kodunu ezberlemekten çok, hangi kanıtın hangi kullanıcı mesajına izin verdiğini belirlemektir. Örneği bir araç sözleşmesi incelemesi veya masa başı ajan testi olarak uygulayabilirsiniz.

Başlatma ve izleme sözleşmesini önce yazın

Örneğimizde POST /jobs bir rapor işini yalnızca bir kez başlatır. Kabul yanıtı jobId: J9, durum adresi /jobs/J9 ve iki saniyelik önerilen sorgu aralığı içerir. Durum gövdesindeki state alanı queued, running, succeeded, failed veya cancelled olabilir. Bunlar bu eğitim için seçilmiş değerlerdir; başka bir araçta aynı adların bulunacağını varsaymayın.

Microsoft’un asenkron istek ve yanıt deseni, uzun süren işi ayrı bir durum adresinden izlemeyi anlatır. Durum adresinin HTTP 200 dönmesi, sorgunun başarılı olduğunu gösterebilir; gövdedeki iş hâlâ sürüyor olabilir. Bu nedenle iki bilgiyi ayrı okuyacağız: HTTP sonucu durum sorgusunun yanıtıdır, state ise izlediğimiz işin durumudur.Kaynak: Microsoft — Asynchronous Request-Reply pattern

• İlk başlatma isteği bir adettir. Beklemek veya durum sorgulamak yeni bir başlatma isteği gerektirmez.
• Bu denemede en fazla üç durum sorgusu yapılır. Önerilen iki saniyelik aralık uygulanır; bekleme sınırsız değildir.
• succeeded görüldüğünde resultId alınır. İlgili çıktı okunup iş kimliği, çıktı kimliği ve gerekli alanlar doğrulanmadan kullanıcıya tamamlandı denmez.
• Sorgu bütçesi tükenirse son bilinen durum ve iş kimliği korunur. Beklemenin sona ermesi, işin iptal edildiğini göstermez.

Gerçek bir uygulama süre sınırını, aralık üst sınırını ve kesintiden sonra nasıl devam edileceğini ayrıca tanımlar. Buradaki üç sorguluk sınır bir ürün önerisi değildir. Küçük örneğin sonsuza kadar beklememesini sağlayan açık bir eğitim kuralıdır. İptal gerekiyorsa bunun ayrı bir araç işlemi ve doğrulanmış sonucu olmalıdır.

Dört adımlı izi okuyun

Birinci sorguyu kabulden iki saniye sonra, ikinciyi bundan iki saniye sonra yaptığımızı varsayın. Dördüncü adımda okunan raporun bu örnekte dört satır içermesi bekleniyor. jobId, resultId, boş olmayan başlık ve dört satır koşulu birlikte kontrol edilir. Gerçek raporun doğruluğu için gerekli içerik kontrolleri ayrıca tanımlanmalıdır; yalnızca bir dosyanın bulunması her işte yeterli değildir.

Yukarıdaki sentetik araç sözleşmesini ve dört adımlı izi kullan. Her adım için HTTP sonucunu, iş durumunu, elimizdeki kanıtı ve kullanıcıya söylenebilecek cümleyi ayrı yaz. Toplam başlatma, durum sorgusu ve çıktı okuma sayısını hesapla. Yeni POST üretme. succeeded durumunu tek başına kapanış sayma; J9/R9 ve çıktı alanlarını doğrula. Eksik kanıtı varsayımla tamamlama.

Başlatma: 1 POST. Durum sorgusu: 2 GET. Çıktı okuma: 1 GET. Toplam: 4 HTTP isteği.
1: İstek J9 olarak alındı; sonuç bekleniyor.
2: J9 işleniyor; rapor henüz doğrulanmadı.
3: Araç tamamlandığını bildirdi; R9 kontrol ediliyor.
4: R9, J9 ile eşleşiyor; başlık ve dört satır koşulu sağlandı. Deneme raporu tamamlandı.

Bu çıktı bir model denemesinin kaydı değildir; karşılaştırma için yazılmış cevap anahtarıdır. Ajan farklı cümleler kullanabilir. Değişmemesi gereken şey, ilk üç adımda doğrulanmış rapor varmış gibi davranmaması ve başlatma sayısını birde tutmasıdır. Kullanıcıya ara durum bildirmek de işi yeniden başlatmayı gerektirmez.

Kapanış kararını ters örneklerle sınayın

Yalnızca başarılı izi okumak yeterli olmaz. İkinci adım HTTP 200 ile state=running verdiğinde “200 gördüm, bitti” kuralı hatalıdır. Üçüncü durum sorgusuna rağmen running sürüyorsa sorgu bütçesi dolmuştur; kayda “izleme sınırına ulaşıldı, son durum running” yazılır. İşin arka planda ne yaptığını bilmeden failed veya cancelled sonucu üretilmez.

Tanımadığınız bir state değeri geldiğinde de onu otomatik başarıya veya hataya çevirmeyin. Sözleşme dışı yanıt olarak ayırın ve sorumluya yönlendirin. Kullanıcı metni ile iç durum kaydı tutarlı kalmalıdır. Kullanıcıya bekleniyor derken arka kayıtta tamamlandı yazmak, sonraki adımın yanlış karar vermesine yol açabilir.

İki yanıtı değiştirin

Önce üçüncü adımı HTTP 200 ve state=failed olacak şekilde değiştirin. Sonra başarılı özgün izi geri alın, fakat dördüncü adımda jobId=J8 olduğunu varsayın. Her senaryoda işi başarıyla kapatıp kapatamayacağınızı ve kaç yeni başlatma isteği gerektiğini yazın. İlk yanıt kodunun olumlu görünmesi ile işin sonucunu ayrı değerlendirin.

Senaryo A: Durum sorgusu başarılı yanıtlandı, fakat araç J9 işinin başarısız olduğunu bildirdi. Kullanıcıya rapor hazır denmez.
Senaryo B: R9 başka iş kimliği taşıyor; sonuç eşleşmesi doğrulanamadı. J9 başarıyla kapatılmaz, uyuşmazlık incelemeye gider.
İki senaryoda da kendiliğinden yeni POST: 0. Yeniden başlatma kararı bu gözlemlerden otomatik türetilmez.

Kendi aracınıza uyarlarken önce gerçek durum adlarını ve kapanış için gerekli kanıtları çıkarın. Ardından başarılı iz, sürmekte olan iş, terminal hata ve yanlış çıktı eşleşmesi için ayrı kayıtlar hazırlayın. Böylece ajanın kullanıcıya verdiği son söz, aracın ilk olumlu yanıtına değil doğrulanmış iş sonucuna dayanır.