Veri kümesinin gösterdikleri
Üretimdeki agent'lar hakkındaki kurumsal yazılar dar bir başarısızlık kümesinde birleşiyor ve bunların çoğu model başarısızlığı değil. Bunlar arayüz başarısızlıkları. Aynı sürtünme, birbiriyle ilgisiz görünen dağıtımlarda da ortaya çıkıyor:
- Araçlar yapılandırılmamış başarı döndürüyor.
{"status": "ok"}gibi bir yanıt ya da insan tarafından okunabilir bir gövdeyle gelen çıplak bir HTTP 200, agent'ı amaçlanan etkinin gerçekten gerçekleşip gerçekleşmediğini çıkarsamaya bırakıyor. - Kısmi başarısızlık gizleniyor. Bazı öğeleri işleyip bazılarını atlayan bir toplu işlem, taşıma katmanı başarılı olduğu için başarı bildiriyor.
- Tek bir niyet, çok çağrılı bir ritüel gerektiriyor. Bir kaynak oluşturmak, bir create endpoint'ini çağırmak, ardından bir status endpoint'ini yoklamak ve sonra bir finalise endpoint'ini çağırmak anlamına geliyor. Her çağrı yarı yolda durma şansıdır ve ara durumlar araç tanımının hiçbir yerinde modellenmemiştir.
- Yeniden denemeler, hiçbir zaman terminal bir durum bildirmeyen endpoint'lere karşı çalışıyor. Olay raporları, sürekli geçici görünen bir hata döndüren bir çağrı üzerinde döngüye giren agent'ları anlatıyor, çünkü yanıttaki hiçbir şey "tekrar dene" ile "bu asla işe yaramayacak" arasındaki farkı ayırt etmiyor.
Örüntü tutarlı: araç yüzeyinden, hiçbir zaman ifade etmek üzere tasarlanmadığı bir semantiği taşıması isteniyor. Agent kötü davranmıyor; arayüzün izin verdiği tek yorumu tamamlıyor.
Sarmalayıcı yanılgısı
Mevcut bir insan API'sini bir JSON şemasıyla sarmalamak bir araç yüzeyi üretmez. İnce bir açıklamaya sahip bir uzak yordam çağrısı üretir. Şema, modele hangi alanları göndereceğini söyler; çağrının ne anlama geldiği, ne zaman geçerli olduğu ya da belirli bir yanıtın dünya hakkında ne ima ettiği konusunda neredeyse hiçbir şey söylemez.
İnsan API'leri, eksik bilgiyi telafi edebilen bir okuyucu için tasarlanmıştır. Bu okuyucu, çevredeki bağlamdan niyeti çıkarsayabilir, bir iş arkadaşına bir durum kodunun ne anlama geldiğini sorabilir ya da bir sonucun eskimiş göründüğünü fark edip araştırabilir. Bir döngü içinde çalışan bir agent için bu kurtarma yollarının hiçbiri yoktur. Arayüz belirsiz olduğunda, agent'ın kullanabileceği tek strateji tahmin etmek, yeniden denemek ya da vazgeçmektir ve üçü de üretimde pahalıdır.
Sarmalayıcı yaklaşımı ayrıca çeviriden sağ çıkmayan varsayımları da içeri taşır. Bir insan API'si, hata gövdesi içeren bir 200'ü ekipteki herkesin bildiği bir gelenek olarak görebilir. Boş bir listeyi, bir insan kontrol edeceği için, hem "sonuç yok" hem de "sorgu hatalı biçimlendirilmişti" olarak görebilir. Bir insan düğmeye iki kez tıklamayacağı için yıkıcı işlemleri idempotent olmayan biçimde bırakabilir. Bunların her biri, bir insan çağıran için makul bir tasarım kararı ve bir makine çağıran için bir kusurdur.
Agent'ların bunun yerine ihtiyaç duyduğu şey, açık ön koşullara, açık son koşullara ve terminal bir hata taksonomisine sahip bir yüzeydir. Bir ön koşul, çağrı geçerli olmadan önce neyin doğru olması gerektiğini belirtir. Bir son koşul, başarılı bir çağrıdan sonra neyin doğru olacağını belirtir. Terminal bir hata taksonomisi, hangi başarısızlıkların yeniden denenebilir, hangilerinin kalıcı ve hangilerinin tamamen farklı bir çağrı gerektirdiğini belirtir.
Bir araç çağrısı, bir niyet
Bir araç çağrısı tek bir niyeti ifade etmelidir. Tek bir hedefe ulaşmak, devam ettirilemeyen bir çağrı dizisi gerektiriyorsa, yüzey kısmi tamamlanmayı ve belirsiz yeniden denemeleri davet eder. Çok adımlı bir süreç kaçınılmaz olduğunda, ara durumları açıkça modelleyin ve her geçişi, çağıranın doğru biçimde gerçekleştirmesi beklenen bir ritüelin arkasına saklamak yerine kendi ön koşullarına sahip birinci sınıf bir işlem haline getirin.
Her yanıt üç şeyden biridir
Her yanıt başarı, yeniden denenebilir başarısızlık ya da terminal başarısızlık olarak sınıflandırılabilmelidir. Dördüncü bir durum yoktur. Belirsiz bir yanıt, çağıranı bir politika icat etmeye zorlar ve icat edilmiş politikalar, yeniden deneme fırtınalarının çıktığı yerdir. Somut olarak bu, küçük ve kapalı bir sonuç türleri kümesine sahip bir yanıt zarfı ve bilinmeyen sonuç türlerinin yeniden denenmek yerine terminal başarısızlık olarak ele alınması kuralı anlamına gelir.
Kullanışlı bir mekanizma, açık bir sonuç ayırt edicisi ve sınırlı bir yeniden deneme ipucu içeren bir yanıt zarfıdır:
{
"outcome": "retryable_failure",
"reason": "upstream_unavailable",
"retry_after_ms": 2000,
"observed_state": null
}
Önemli olan özellik, belirli alan adları değil, çağıranın yorum yapmadan dallanabilmesidir. terminal_failure dur ve hatayı yüzeye çıkar demektir. retryable_failure belirtilen sınır içinde yeniden dene demektir. success son koşulun geçerli olduğu anlamına gelir.
Yıkıcı işlemler anahtara göre idempotenttir
Yıkıcı işlemler anahtara göre idempotent olmalıdır, böylece yeniden denemeler tasarım gereği güvenli olur. Çağıran, niyetten türetilen kararlı bir idempotency anahtarı sağlar ve yüzey, tekrarlanan bir anahtar için etkiyi iki kez gerçekleştirmek yerine aynı sonucu döndürür. Bu, agent'ın önceki bir denemenin yerine oturup oturmadığını akıl yürütmesi ihtiyacını ortadan kaldırır ki bu, en kötü olduğu akıl yürütme türüdür.
Bir yanıt, çağıranın güvenmek yerine doğrulayabilmesi için iddia edilen sonucun yanında gözlemlenen durumu da döndürmelidir. Araç bir kaynağın oluşturulduğunu iddia ediyorsa, kaynağın mevcut gözlemlenebilir durumunu döndürmelidir. Böylece doğrulama, agent'ın sahip olması gereken bir inanç yerine gerçekleştirebileceği bir karşılaştırma haline gelir. Eskimiş veriyle gelen başarının tespit edilebilir olmasını sağlayan da budur: iddia edilen sonuç ile gözlemlenen durum birbiriyle çelişir.
Dürüst ödünleşimler
Bu kurallar bedava değil. Açık sonuç zarfları yanıtları büyütür, bu da context tüketir ve bir araç tanımını, bir modelin güvenilir biçimde dikkat gösterdiği noktanın ötesine itebilir. Idempotency anahtarları sunucu tarafı durum ve bir saklama penceresi gerektirir; bu, daha önce hiç buna sahip olmayan ekipler için operasyonel bir yüktür. Bir ritüeli açık, devam ettirilebilir işlemlere bölmek daha fazla araç üretir ve daha fazla araç, çağıran için daha fazla seçim belirsizliği demektir. Tasarım sorusu, bu maliyetlerin ödenip ödenmeyeceği değil, bunlar olmadan başarısızlık modunun nerede daha kötü olduğudur. Çoğu üretim sisteminde, belirsiz bir yeniden deneme daha büyük bir yanıttan daha pahalıdır.
Değerlendirme çıkarımları
Sorun araç yüzeyleriyse, o zaman araç çağrısı doğruluğu, yalnızca görev tamamlama üzerinden puanlanacak yanlış şeydir. Bir görevi terminal bir başarısızlık boyunca yeniden deneyerek tamamlayan bir çalışma doğru bir çalışma değildir; iletişim kurmakta başarısız olan bir yüzeye karşı şansı yaver gitmiş bir çalışmadır. Puanlama iki boyutu ayırmalıdır:
- Niyetten çağrıya eşleme. Agent, belirtilen niyet için doğru aracı doğru argümanlarla seçti mi, doğru davranışın hiçbir şey çağırmamak olduğu durumlar dahil?
- Başarısızlık sınıfı işleme. Yüzeyin yayabileceği her başarısızlık sınıfı için agent doğru politikayla mı yanıt verdi: sınır içinde yeniden dene, dur ve yüzeye çıkar ya da farklı bir çağrıya geç?
Bu, regresyon paketlerinin düzensiz kaos deneyleri olarak değil, birinci sınıf fixture'lar olarak düşmanca araç yanıtlarına ihtiyaç duyduğu anlamına gelir. En çok önem taşıyan dört tanesi yavaş başarı, kısmi başarı, sessiz başarısızlık ve eskimiş veriyle gelen başarıdır. Her biri farklı bir varsayımı yoklar:
- Yavaş başarı, agent'ın timeout politikasının gecikmeyi başarısızlıktan ayırt edip etmediğini test eder.
- Kısmi başarı, iddia edilen sonuç yerine gözlemlenen durumu okuyup okumadığını test eder.
- Sessiz başarısızlık, son koşulları hiç doğrulayıp doğrulamadığını test eder.
- Eskimiş veriyle gelen başarı, yanıta güvenmek yerine zaman damgalarını ya da sürümleri karşılaştırıp karşılaştırmadığını test eder.
Bu yanıtları bir test düzeneğinde üretemeyen bir yüzey, başarısızlık modları üretimde ortaya çıkana kadar bilinmeyen bir yüzeydir. Fixture'ları inşa etmek, arayüzü inşa etmenin bir parçasıdır.
Kapanış
Araç yüzeyleri bir arayüz tasarımı sorunudur. Sarmalayıcı yaklaşımı, arayüzü mevcut bir insan API'si üzerinde bir çeviri katmanı olarak ele alır ve o API'nin, telafi edebilen bir okuyucu hakkında yaptığı her varsayımı devralır. Bir makine çağıran için tasarlamak; ön koşulları, son koşulları ve terminal hata semantiğini açık hale getirmek ve bununla gelen maliyetleri kabul etmek anlamına gelir. Alternatif, başarısızlıkları biri logları okuyana kadar başarılarından ayırt edilemeyen bir sistemdir.