Labs — iç ajan sistemleri

Problem

Yayına çıkmadan önce bir projeyi baştan sona denetlemek, tek kişilik bir ekipte en kolay atlanan iş. "Bir kez göz gezdirdim" güvenilir değil, çünkü kontrol listesi kafada duruyor ve her projede farklı maddeler düşüyor. İkinci mesele daha ince: bir dil modeline "bu siteyi denetle" demek işe yaramıyor. Ölçüme dayanmayan bulgu kendinden emin ama yanlış çıkıyor, üstelik yanlışlığı ancak düzeltmeye kalkınca anlaşılıyor. Denetimin değeri bulunan sorunun sayısında değil, bulunan her sorunun gerçek olmasında.

Mimari

Hat sırayla ilerliyor. Scout projeyi profilliyor ve koşullu auditor'ların gerekip gerekmediğini belirliyor. Ardından Playwright harness'ı paralel çalışıyor: ekran görüntüsü, üç koşumluk Lighthouse ve axe erişilebilirlik taraması. Olgunluğu production seviyesinde olan projelerde ayrıca gerçek build çıktısı alınıyor. Bu ölçümler elde olduktan sonra 13 sabit ve 1 koşullu auditor paralel koşuyor — görsel tasarım, etkileşim, dönüşüm, metin, tasarım sistemi, teknik ve içerik SEO, ön yüz ve arka uç performansı, erişilebilirlik, güvenlik, hukuki uyum, veri bütünlüğü ve tespit edilirse veri görselleştirme. Her auditor'ın çıktısı kendi QA red team'ine giriyor; oradan geçen bulgular tek bir çapraz gözden geçiriciye gidiyor. Sonuç, her bulgunun yanında onay kutusu olan bir markdown raporu. Onaylanan düzeltmeleri tek write yetkili bir ajan uyguluyor, ardından doğrulama turu koşuyor.

Kritik Kararlar

1. Denetim ölçümden sonra başlar, ölçüm yerine geçmez

   Auditor'lar konuşmaya başlamadan önce Playwright ekran görüntüsünü, üç koşumluk Lighthouse medyanını ve axe çıktısını alıyor. Bir performans bulgusu artık "sayfa yavaş görünüyor" değil, ölçülmüş bir metrik üzerinden yazılıyor. Erişilebilirlik tarafında da aynı: axe'in yakaladığı ihlal ile modelin tahmini ayrı ağırlıkta.

   ÖdünleşimHarness kurulumu her projede ek bir adım ve rota yapılandırması elle yazılıyor. Ölçüm alınamayan bir projede — yerelde ayağa kalkmayan, veritabanı gerektiren bir uygulama gibi — hat daralıyor ve denetimin bir kısmı yapılamıyor.

2. Her auditor'ın çıktısı ayrı bir red team'den geçiyor

   Tek bir ajanın kendi bulgusunu gözden geçirmesi işe yaramıyor; kendi metnini savunuyor. Bu yüzden her auditor için ayrı bir QA turu var ve o turun görevi hata bulmak: halüsinasyon, önem derecesi şişirmesi, gözden kaçan alan. Geçemeyen bulgu en fazla iki kez geri gönderiliyor.

   ÖdünleşimAjan sayısı ve dolayısıyla maliyet neredeyse ikiye katlanıyor, denetim süresi uzuyor. Küçük bir projede bu maliyet, bulunan sorunun değerini aşabiliyor — kit'i her projede değil, yayına çıkacak projede çalıştırıyorum.

3. Yazma yetkisi tek ajanda ve kapsamı önceden sabit

   Bulgu üreten ajanların hiçbiri dosya değiştiremiyor. Düzeltmeyi yalnızca fix-applier uyguluyor ve onaylanan düzeltmenin dosya listesinin dışına çıkamıyor. Böylece "denetim sırasında bir şey bozuldu" durumu, hangi ajanın ne yaptığını aramayı gerektirmiyor.

   ÖdünleşimKapsam dışında kalan bariz bir hata düzeltilmeden bırakılıyor ve ayrı bir tur gerektiriyor. Toplu düzeltmeler tek ajandan geçtiği için hat burada darboğaza giriyor.

4. Hiçbir düzeltme onaysız uygulanmıyor

   Rapor markdown onay kutularıyla geliyor: uygula, ertele, yapılmayacak. Karar bende kalıyor çünkü bulguların bir kısmı doğru ama o proje için yanlış — erken bir prototipte hukuki uyum bulgusu teknik olarak haklı, pratikte sıradaki iş değil.

   ÖdünleşimYüz maddelik bir raporda onay adımı, işin kendisi kadar zaman alabiliyor. Toplu onay kısayolları bunu hafifletiyor ama ortadan kaldırmıyor; tam otomatik bir hat değil, olmasını da istemiyorum.

Performans

Lighthouse üç kez koşuyor ve metrik başına medyan alınıyor — tek koşum, özellikle soğuk başlangıçta, gerçeği temsil etmiyor. Auditor'lar paralel çalışıyor; hattın toplam süresi en yavaş auditor'a değil, en uzun zincire bağlı.

Sonuçlar

Ajan

18 ajan · 5 slash komut · 5 TypeScript harness script'i

Denetim kapsamı

13 sabit auditor + 1 koşullu (dashboard veya grafik kütüphanesi tespit edilirse)

Doğrulama katmanı

Ajan başına red team + tek çapraz gözden geçirici

Mimari garanti

Yazma yetkisi tek ajanda; o da onaylanmış dosya listesinin dışına çıkamıyor

Bugün Ne Farklı Yapardım

Çapraz gözden geçiriciyi baştan koymalıydım. İlk sürümde her auditor kendi başına rapor yazıyordu ve aynı sorun üç farklı ajandan üç farklı önem derecesiyle geliyordu; raporu okuyan kişi hangisine bakacağını bilmiyordu. Aynı desen portfolyodaki kod tarafında da var: Bergaz Operasyon'da garantiyi uygulama katmanında bırakmak, her yeni yolun aynı kuralı yeniden kurmasını gerektiriyordu. Burada da tekilleştirme kuralı tek bir yere taşınana kadar her auditor kendi tekilleştirmesini yapıyordu.

Problem

Akademik bir tez veya makale için istatistiksel analiz hizmeti veriyorum, ama istatistik benim uzmanlık alanım değil; kod tarafı öyle. Bu iki gerçek bir arada, sistemin nasıl kurulacağını belirledi. Bir dil modeline p değeri hesaplatmak, sayının doğru görünmesine ama doğru olmamasına yol açıyor; üstelik yanlışlığı jüri masasında ortaya çıkıyor. İkinci mesele metin: sistemin ürettiği her cümle özgün olmak zorunda, çünkü çıktı intihal denetiminden geçiriliyor ve kopya bir paragraf teslimi reddettiriyor.

Mimari

Sekiz numaralı ajan sırayla çalışıyor: ölçek kütüphanecisi, veri profilleyici, skor üretici, tasarım yorumlayıcı, test seçici, analiz koşucusu, raporlayıcı ve gözden geçirici. Bunların yanında görev bazlı ajanlar var — grafik üretici, akademik yorumlayıcı, tartışma yazarı, sunum üretici ve bir QA kapısı. Sayısal işin tamamı Python tarafında: veri işleme, hipotez testleri, normallik, güvenilirlik katsayısı, regresyon tanılamaları ve etki büyüklüğü. Model yalnızca dört iş yapıyor — orkestrasyon, test seçimi ve gerekçesi, sonuç yorumu, rapor metni. Hat üç noktada duruyor ve insan onayı bekliyor: ölçek eşlemesinin doğrulanması, hipotezin doğrulanması ve final raporun kabulü.

Kritik Kararlar

1. Hesaplamayı asla model yapmaz

   p değeri, F, t, güvenilirlik katsayısı, korelasyon ve regresyon çıktılarının tamamı gerçek istatistik kütüphaneleriyle hesaplanıyor. Modelin ürettiği bir sayı, kaynağı gösterilemediği için savunulamaz; hesabı kütüphaneye vermek, çıktının her rakamını yeniden üretilebilir kılıyor.

   ÖdünleşimModel ile hesap arasındaki her geçiş bir şema gerektiriyor: ajanın ne isteyeceği ve Python'un ne döndüreceği önceden tanımlı olmak zorunda. Bu, yeni bir test eklemenin iki tarafta birden iş çıkarması demek — serbest metinle iş gören bir hattan belirgin biçimde daha yavaş ilerliyor.

2. Üç onay kapısı ve kapıların yeri sabit

   Kapılar hattın en pahalı hatalarının hemen öncesine konuldu. Ölçek eşlemesi yanlışsa sonraki her hesap yanlış; hipotez yanlışsa doğru hesap yanlış soruya cevap veriyor; rapor kabul edilmeden teslim edilirse düzeltme maliyeti en yükseğe çıkıyor. Alan kararları müşteride, istatistiksel test seçimi sistemde — bu ayrım da kapılarda görünür hâle geliyor.

   ÖdünleşimHat tam otomatik değil ve olamıyor: üç noktada dışarıdan cevap bekliyor. Cevap gecikirse iş duruyor, ve müşteri bu üç kararı verebilecek durumda değilse hat hiç ilerlemiyor.

3. Özgünlük bir stil tercihi değil, sert bir kural

   Kaynak makaleden, ölçek geliştirme çalışmasından veya şablon bir tezden cümle yapısı taşımak yasak; atıfın doğru olması yeterli değil, çevresindeki metnin de kopya olmaması gerekiyor. Kural, bir teslimde bir bölümün tamamen kopya çıkması üzerine yazıldı — yani gözlemden doğdu, ihtiyattan değil.

   ÖdünleşimDerinlemesine yeniden yazma, doğrudan alıntılamaya göre daha yavaş ve her turda kontrol listesi gerektiriyor. Sayılar ve künye bilgileri değişmeden kalmak zorunda olduğu için, özgünleştirme yalnız dil üzerinde çalışabiliyor — hareket alanı dar.

4. Raporlama konvansiyonları ilk üretimden itibaren geçerli

   Bir teslimde hesaplar doğru çıktı ama rapor, biçim kuralları yüzünden revizyona gitti. Bu kurallar artık hattın içinde tanımlı ve ilk taslaktan itibaren uygulanıyor — sonradan düzeltilecek bir cila olarak değil.

   ÖdünleşimKurallar tek bir jüri değerlendirmesinden geldi ve her kurumda birebir aynı olmayabilir. Farklı bir kurumla çalışıldığında kural setinin gözden geçirilmesi gerekiyor; bugün bu elle yapılıyor.

Performans

Hattın süresi hesaptan değil, onay kapılarından geliyor: analiz koşusu dakikalarla, onay bekleme günlerle ölçülüyor. Bu yüzden hat, bir kapıda beklerken sonraki adımın hazırlığını yapabilecek şekilde bölündü.

Sonuçlar

Ajan

8 sıralı hat ajanı + 12 görev ajanı

Aktif geliştirme

22 commit

Mimari garanti

Sayısal sonuçların tamamı Python kütüphanelerinden gelir; model aritmetik yapmaz

Mimari garanti

Üç onay kapısı geçilmeden rapor teslim edilmez

Bugün Ne Farklı Yapardım

Özgünlük kuralını ve raporlama konvansiyonlarını baştan yazmadım; ikisi de bir teslimde sorun çıktıktan sonra eklendi. Bugün bir hattı kurarken "çıktı nerede reddedilir" sorusunu, "çıktı nasıl üretilir" sorusundan önce sorardım — reddedilme kriterleri hattın şeklini belirliyor. Aynı ders Launch Audit Kit'te de çıktı: orada da doğrulama katmanı sonradan eklendi ve eklenene kadar üretilen bulguların bir kısmı kullanılamazdı.