Borç, linter'ların baktığı yerde değildir
Geleneksel yazılım, borcu eninde sonunda bir derleyicinin şikayet edeceği yerlerde biriktirir: yinelenen mantık, eskimiş arayüzler, belgelenmemiş invariantlar. Agent sistemleri ise borcu hiçbir şeyin şikayet etmediği yerlerde biriktirir. Prompt bir string'dir. Tool şeması bir JSON belgesidir. Hangi agent'ın hangi kararın sahibi olduğuna dair konvansiyon, ikinci sprint'ten sonra kimsenin okumadığı bir tasarım belgesinde yaşar.
Bu bir üslup sorunu değildir. Yapısaldır. Sistem davranışını belirleyen artefakt tiplenmemiş, sürümlenmemiş bir düzyazı olduğunda, her değişiklik sessiz bir değişikliktir. Hiçbir şey derlenmez. Sistem çalışmaya devam eder. Sadece farklı çalışır ve bu fark, haftalar sonra bir downstream agent makul görünen ama belirli ve tekrarlanabilir bir şekilde yanlış çıktılar üretmeye başladığında keşfedilir.
Sessiz sapmayla agent'lar arasında yinelenen prompt parçaları
Yaygın bir kalıp: "her zaman kaynak belgeyi alıntıla" gibi paylaşılan bir talimat dört agent promptuna kopyalanır. Altı hafta sonra üçü düzenlenmiştir. Biri artık "mevcut olduğunda kaynağı alıntıla" der. Bir diğeri "retrieval başarılı olduysa kaynak belgeyi alıntıla" der. Dördüncüsü değişmemiştir. Hiçbir test başarısız olmaz. Koşullu alıntı yapan agent'lar ile koşulsuz alıntı yapan agent farklı denetim izleri üretir ve bu fark yalnızca biri pipeline genelinde çıktıları uzlaştırmaya çalıştığında ortaya çıkar.
Borç, yinelemenin kendisi değildir. Yineleme ucuzdur. Borç, sapmayı tespit eden bir mekanizmanın yokluğudur. Build zamanında import edilen paylaşılan bir prompt parçası, sapmayı bir diff haline getirirdi. Kopyala-yapıştır bir parça ise onu görünmez kılar.
Sardıkları servisle artık eşleşmeyen tool şemaları
Bir tool şeması bir sözleşmedir. Altta yatan servis değiştiğinde — bir alan yeniden adlandırılır, nullable bir alan zorunlu hale gelir, bir hata 200 ve bir status alanıyla döndürülür — şema kendini güncellemez. Agent, tool'u eski şekille çağırmaya devam eder. Servis ya çağrıyı reddeder, bu durumda agent yeniden dener ve token yakar, ya da kabul eder ve agent'ın yanlış yorumladığı bir şey döndürür.
İkinci durum daha kötüdür. Yüksek sesle başarısız olan bir tool, düzeltilen bir tool'dur. Sessizce başarısız olan bir tool ise kendinden emin, yanlış çıktı üretir. Bu, agent sisteminin, throw etmek yerine null döndüren bir fonksiyonun karşılığıdır.
Hangi agent'ın hangi kararın sahibi olduğuna dair belgelenmemiş konvansiyonlar
Çok agent'lı sistemler örtük sahiplik geliştirir. Bir agent ne zaman escalate edileceğine karar verir. Bir diğeri ne zaman yeniden deneneceğine karar verir. Bir üçüncüsü ne zaman özetleneceğine karar verir. Bu kararlar nadiren tek bir yerde yazıya dökülür. Promptlardan, orkestrasyon kodundan ve agent'ların eklenme sırasından doğarlar.
Yeni bir agent eklendiğinde, bunların hiçbirini miras almaz. Kendi kararlarını verir, bazen mevcut bir agent'la çelişerek. Çelişki, iki agent'ın da bug'ı değildir. Eksik bir spesifikasyondur. Sistemin artık tek bir karar için iki sahibi vardır ve çözüm yürütme sırasına bağlıdır.
Bu, görülmesi en zor borç sınıfıdır çünkü hiçbir tek artefaktta değildir. Artefaktlar arasındaki boşluklardadır.
Görünür kılmak
Çare daha iyi promptlar yazmak değildir. Promptları, şemaları ve konvansiyonları kodla aynı disipline tabi kılmaktır.
Promptları sahipleri ve changelog'ları olan sürümlenmiş artefaktlar olarak ele almak
Bir prompt bir veritabanı satırında, bir admin panelinden düzenlenerek değil, bir repository'de yaşamalıdır. Bir sahibi olmalıdır — bir birey değil, bir ekip veya bir rol — ve neyin neden değiştiğini kaydeden bir changelog'u. Changelog, sürüm numarasından daha önemlidir. Gerekçesiz bir prompt diff'i, onu anlamayan bir sonraki kişi tarafından geri alınacak bir prompt diff'idir.
Sürümleme ayrıca rollback'i mümkün kılar. Bir prompt değişikliği çıktı kalitesini düşürdüğünde, bilinen-iyi bir sürüme dönebilme yeteneği, on beş dakikalık bir düzeltme ile çok günlük bir soruşturma arasındaki farktır.
Tool şemalarını canlı endpoint'lere karşı çalıştıran contract test'leri
Bir tool şeması, bir API client'ının test edildiği gibi test edilmelidir: gerçek endpoint'i çağırarak ve yanıtın şemaya uyduğunu doğrulayarak. Bu, mock'lu bir unit test değildir. Mock'lar, şemayı mock'un yazıldığı anda anlaşıldığı haliyle kodlar ki bu tam olarak yanlışlanması gereken varsayımdır.
Bir tool şeması için contract test'i üç şeyi doğrular: endpoint'in şemanın beyan ettiği şekli kabul ettiğini, yanıtın şemanın vaat ettiği alanları içerdiğini ve hata koşullarının agent'ın üzerine hareket edebileceği bir biçimde ortaya çıktığını. Üçüncü doğrulama en sık atlanan ve en çok önem taşıyanıdır, çünkü geçici bir hatayı kalıcı bir hatadan ayırt edemeyen bir agent, kalıcı bir hatayı bütçesini tüketene kadar yeniden dener.
Her agent'ı tool'larına, memory scope'larına ve escalation yoluna eşleyen bir registry
Registry, sahiplik için tek doğruluk kaynağıdır. Her agent için şunları kaydeder: hangi tool'ları çağırabileceğini, hangi memory scope'larını okuyup yazabileceğini ve hangi koşullarda escalate ettiğini. Registry dokümantasyon değildir. Orkestrasyon katmanının okuduğu konfigürasyondur, öyle ki bir agent sahibi olmadığı bir tool'u çağıramaz veya elinde tutmadığı bir memory scope'una yazamaz.
Bu, örtük bir konvansiyonu zorunlu kılınan bir konvansiyona dönüştürür. Ödünleşim gerçektir: bir registry bir dolaylılık katmanı ve bir bakım yükü ekler. Her yeni tool bir registry girdisi gerektirir ve her registry girdisi, koddan saptığında potansiyel bir başarısızlık noktasıdır. Alternatif — sahipliği örtük bırakmak — ilk çelişkili karara kadar daha ucuzdur; o noktada teşhis maliyeti, registry maliyetini geniş bir marjla aşar.
Refactoring kuralı
Bir davranış önemliyse, kodda veya bir şemada yer alır, bir promptun içindeki düzyazıda değil.
Kuralın tamamı budur. Söylemesi kolay, uyması zordur, çünkü promptlar en az direnç yoludur. Bir prompta bir cümle eklemek, bir şemaya bir alan eklemekten hızlıdır. Cümle anında işler. Şema ise bir migration, bir test ve bir review gerektirir.
Kural, düzyazıya bir yasak değildir. Promptların tona, çerçevelemeye ve formalize edilmeye direnen türden rehberliğe düzyazı olarak ihtiyacı vardır. Kural bir sınırdır: düzyazı, sistemi bozmadan değişebilecek şeyler içindir. Şemalar ve kod ise değişemeyecek şeyler içindir.
Faydalı bir test: davranış, bir test yazacağınız türden bir şeyse, bir prompta ait değildir. Onun için bir test yazmayacaksanız, bir prompta ait olabilir. Test, ayırıcı çizgidir.
Bunun maliyeti nedir
Dürüst ödünleşim şudur: bu disiplin ilk sürümü yavaşlatır. Sahibi ve changelog'u olan sürümlenmiş bir prompt, bir dashboard'da düzenlenen bir string'den daha uzun sürede sevk edilir. Bir contract test'i, bir mock'tan daha uzun sürede yazılır. Bir registry, bir konvansiyondan daha uzun sürede kurulur.
Getiri ilk sürümde değildir. Beşincidedir. Değiştirmesi ucuz olan agent sistemleri, değişikliğin okunabilir olduğu sistemlerdir. Okunabilirlik, diff'lenebilen, test edilebilen ve sahiplenilebilen artefaktlardan gelir. Dashboard'larda yaşayan promptlar yazması ucuz, değiştirmesi pahalıdır. Repository'lerde yaşayan promptlar yazması pahalı, değiştirmesi ucuzdur. Seçim, hangi maliyetin ne zaman ödeneceğidir.
Agent sistemlerini production'da çalıştıran ekipler için ilgili soru, borcun var olup olmadığı değildir. Vardır. Soru, görünür olup olmadığıdır. Sessizce sapmış bir prompt parçası görünmez borçtur. Bir sürümü, bir sahibi ve bir changelog'u olan bir prompt parçası görünür borçtur ki bu, ödenebilecek tek türdür.
Özet
Agent kod tabanları farklı şekilde çürür. Derleyici promptları, tool şemalarını veya sahiplik konvansiyonlarını denetlemez, dolayısıyla borç bir sinyal olmadan birikir. Onu görünür kılmak, promptları sürümlenmiş artefaktlar olarak ele almayı, tool şemalarını canlı endpoint'lere karşı test etmeyi ve agent yetenekleri ile escalation yollarının bir registry'sini tutmayı gerektirir. Refactoring kuralı basittir: bir davranış önemliyse, kodda veya bir şemada yer alır, bir promptun içindeki düzyazıda değil. Maliyet peşin ödenir; getiri sonraki her değişiklikte ödenir.