Yapay zeka ajanı nasıl güvenilir yapılır: ölçümden özerk çalışmaya adım adım yol haritası

Model güçlü olsa bile ajan neden güvenilir değildir

Güvenilirlik modelin değil, tüm sistemin özelliğidir. Uzun bir görev onlarca adımdan oluşur ve hatalar birikir: her adım %95 doğruysa, on adımlık bir zincirin hiç hata yapmadan tamamlanma olasılığı yaklaşık %60'tır (0.95^10 ≈ 0.60), elli adımlıkta ise %10'un altındadır. Modelin doğruluğunu siz artıramazsınız, ama hatayı aynı adımda yakalayıp ucuz hale getirebilirsiniz. Harness'in yaptığı tam olarak budur: talimatlar, araçlar, ortam, durum ve geri bildirim modelin etrafında.

Aşağıdaki plan, "hisle" değerlendirmeden ölçülebilir güvenilirliğe, oradan da özerk çalışmaya götürür. Adımlar etki sırasına göredir: her sonraki adım bir öncekine dayanır.

Adım 1. "Hisle" değerlendirmeyi bırakın

Bir mühendis yeni prompt'un her şeyi değiştirdiğine inanır, bir diğeri fark görmez, ama kimse bir metrik ölçmemiştir. Hata günlüğüyle başlayın: ajan takıldığında, bir şeyi bozduğunda veya çalışmayan bir özelliği tamamlandı diye bildirdiğinde bir satır yazın.

| tarih | görev            | ne oldu                        | bileşen        |
|-------|------------------|--------------------------------|----------------|
| 10.10 | sepette indirim  | "hazır", e2e çalıştırılmadı    | geri bildirim  |
| 10.10 | ödeme webhook'u  | veritabanı kaldırılamadı       | ortam          |
| 11.10 | API refactoring  | reddedilmiş çözümü tekrarladı  | durum          |

"Bileşen" sütunu en önemlisidir. Bir hafta sonra darboğazın nerede olduğu görünür ve her şeyi değil yalnızca onu düzeltirsiniz. Güvenilirliği yalnızca başarılı çalıştırmalarla ölçmek bir hatadır: ajanın nerede düştüğünü yalnızca tıkanma günlüğü gösterir.

Adım 2. İki metrik getirin: MTBF ve MTTR

Güvenilirlik iki sayıyla ölçülür. Ajan için MTBF (arızalar arası ortalama süre), ajanın takılmadan kaç adım gittiğidir. MTTR (ortalama onarım süresi) ise bir arızadan sonra çalışır duruma dönmek için geçen süredir. Erişilebilirlik her iki sayıdan da etkilenir: birincisi artar, ikincisi azalır.

Hiç hata yapmayan bir ajan peşinde koşmak bitmeyen bir yarıştır. MTTR'yi düşürmek genellikle bir günde mümkündür. Bu yüzden ikinci sayıdan başlayın.

Adım 3. Hatayı ucuz hale getirin

Ajana özerklik, ajan hata yapmayı bıraktığında değil, hatanın maliyeti neredeyse sıfıra indiğinde verilebilir. Bunun için üç şey gerekir:

• Küçük ve temiz commit'ler — her değişiklik tek bir komutla geri alınabilsin.
• İzolasyon — ajan ayrı bir branch'te veya çalışma kopyasında, örneğin git worktree ile, üretime erişimi olmayan bir sandbox içinde çalışsın.
• Ortam sıfırlama betiği — veritabanı, bağımlılıklar ve servisler tek komutla başlangıç durumuna dönsün.

git worktree add ../shop-agent -b agent/discount
cd ../shop-agent
make reset   # veritabanını yeniden kur, migration'ları uygula, fixture'ları yükle

Tam geri dönüşün ne kadar sürdüğünü kronometreyle ölçün. Bu sizin MTTR'nizdir. Ayrıca hasar alanını sınırlayın: tek bir görevin değişiklik boyutuna üst sınır koyun ve görev kapsamı dışındaki dosyaların değiştirilmesini yasaklayın.

Adım 4. Geri bildirim döngüsünü kapatın

Kontrol olmadan ajan kendi tek hakimidir ve işin bittiğine samimiyetle inanır. Ona kendini kontrol edeceği komutlar verin ve bunları zorunlu kılın.

• Fail-fast: kontrol ilk hatada, anlaşılır bir mesajla durur; yüz satırlık gürültü üretmez.
• Her değişiklikten sonra hızlı kontroller: ajanın hook'uyla linter ve tip kontrolü.
• Fazlalık: aynı özelliği ikinci, bağımsız bir kontrolle doğrulayın: unit testlerin üstünde bir E2E senaryosu. Yeşil unit testler, özelliğin kullanıcıda çalıştığını kanıtlamaz.

"Hazır" ölçütünü kontrol edilebilir bir koşul olarak yazın: "promosyon kodlu sipariş akışının E2E senaryosu geçer", "indirim uygulandı" değil.

Adım 5. Hafızayı dosyalara taşıyın

Ajan önceki oturumu hatırlamaz. İşe devam etmek için gereken her şey depoda olmalıdır: hedef, yapılanlar ve nasıl doğrulandığı, kararlar ve gerekçeleri, çıkmaz yollar ve sonraki adım. İyi bir işaret: yalnızca depoyu ve "devam et" kelimesini alan yeni bir oturum hemen faydalı işe başlıyorsa, hafıza doğru yerde demektir.

Uzun ve sıkıştırılmış bir konuşma geçmişi süreklilik hissi verir, ama en değerli şeyi kaybeder: reddedilen kararların gerekçelerini. Tam bir yazılı durumla bilinçli olarak oturumu sıfırlamak genellikle daha ucuzdur.

Adım 6. Her seferinde tek görev

Little yasası: aynı anda işte olan görev sayısı, geliş hızının görevin sistemdeki süresiyle çarpımına eşittir. Sabit kapasitede paralel görevler işi hızlandırmaz, her birini uzatır. Ajan için bu daha da serttir: üç özellik demek, aynı context penceresinde üç alan modeli demektir.

• WIP=1 tutun: doğrulanmış sonuca ulaşana kadar tek bir özellik.
• Görevleri küçük parçalara bölün: tek bir doğrulanabilir kullanıcı yeteneği, 1 ila 3 dosya, bir dakikadan kısa kontrol.
• BACKLOG.md tutun — "yan iş" için bir supap. Yan bir eksiklik fark ederse ajan bunu backlog'a bir satır olarak yazar, kendiliğinden düzeltmez.

Adım 7. Yapanla denetleyeni ayırın

Ajanın kendi değerlendirmesi zayıf bir frendir: kodu yazan oturum, onun doğru olduğuna eğilim gösterir. Sonucu ayrı bir subagent veya ayrı bir oturum değerlendirsin; bu oturum yalnızca gereksinimi, diff'i ve kontrol sonuçlarını alsın, yapanın gerekçelerini değil. Denetçinin kararı makine kontrollerine dayansın, "iyi görünüyor" değerlendirmesine değil.

Adım 8. Ajanı özerk döngüye bırakın

Harness tek bir çalıştırmayı güvenilir yapar, döngü çalıştırmalar dizisini özerk yapar. Kötü bir harness üzerine kurulan döngü hataları yalnızca daha hızlı çoğaltır, bu yüzden bu adım sonda gelir. En basit döngü üç satırla yazılabilir:

Hedef:       promosyon kodlu e2e ödeme senaryosu geçer
Kontrol:     make lint && make test && make e2e
Dur:         hedef tamam VEYA 15 deneme VEYA 2 saat → insanı çağır

Döngü türünü işe göre seçin. Görevin bir bitiş çizgisi varsa hedef odaklı bir döngü gerekir: ilerleme hafızası, bağımsız bir denetçi ve adım bütçesi. Bitişi yoksa (sabah CI kontrolü, yeni hataların incelenmesi) zamanlanmış bir döngü uygundur. Sık yapılan hata, bitişi olan bir işi zamanlamaktır: her çalıştırma işe sıfırdan başlar.

Güvenli özerklik kuralları

• Durma koşulu yalnızca makinenin doğrulayabileceği bir şey olsun, yanında deneme ve bütçe sınırı ile.
• Eskalasyon: döngüye neye güvenilmediğini önceden yazın (üretim migration'ları, para, veri silme).
• Görev takılıp ilerleme gerçekte artmıyorsa bu, işi insana devretme işaretidir, döngüyü daha fazla döndürme işareti değil.
• Diff'leri okuyun. Döngünün hızı sizin okuma hızınızı geçmesin; yoksa kendi kod tabanınızı anlamayı bırakırsınız.

Bu yolda sık yapılan hatalar

Talimatları yeniden yazarak başlamak

Bir ajan arızasına en popüler tepki, AGENTS.md dosyasına bir kural daha eklemektir. Birkaç ayda dosya yüzlerce satıra çıkar ve önemli kurallar içinde kaybolur. Hata günlüğü ajanın kontrolleri çalıştırmadığını gösteriyorsa, geri bildirimi düzeltin: kontrol komutu ve hook, bir paragraf daha metin değil.

Her şeyi aynı anda düzeltmek

Harness'in beş bileşenini bir arada iyileştirme isteği güçlüdür. Ama o zaman neyin gerçekten yardımcı olduğu belli olmaz. Her bileşeni 1 ile 5 arasında puanlayın, en zayıfına yarım saat ayırın ve aynı beş tipik görevi öncesinde ve sonrasında çalıştırın. Hata günlüğündeki fark, etkinin olup olmadığını gösterecektir.

"Testler yeşil" ile "özellik çalışıyor"u karıştırmak

Ajan kendi implementasyonunu kontrol eden, gereksinimi değil, bir test yazabilir. Böyle bir test her zaman yeşil kalır. Korunma yolu, implementasyondan önce veya bağımsız bir denetçi tarafından yazılmış kullanıcı düzeyi bir kontroldür (E2E senaryosu) ve ajanın testi geçmek için testi değiştirmemesi kuralıdır.

Hız uğruna kontrolü atlamak

Yavaş kontroller "bu sefer atlayalım" cazibesi yaratır. Bunları ayırmak daha iyidir: hızlı linter ve tip kontrolü her değişiklikten sonra, tam test seti ve E2E ise "hazır" demeden önce. Böylece geri bildirim döngüsü kısa kalır ve işi engellemez.

Ablasyonu ilk adım sanmak

Harness bileşenlerini teker teker kapatıp kaliteye etkisine bakmak mümkündür. Bu faydalı bir kontroldür, ama pahalıdır ve ilk adım değildir: önce hata günlüğü darboğazı gösterir, ablasyon yalnızca hipotezi doğrular. Bir bileşen kapatıldığında düşüş sıfırsa, bileşenin gereksiz olduğu anlamına gelmez; seçilen görevler onu kullanmamış olabilir.

Olgunluk merdiveni

Sonuç

Yapay zeka ajanını güvenilir yapmak şöyle işler: ölçün, hata günlüğünden zayıf bileşeni bulun, hatayı ucuz hale getirin, geri bildirim döngüsünü kapatın, hafızayı dosyalara taşıyın, her seferinde tek görev tutun ve yapanla denetleyeni ayırın. Ancak bundan sonra makinenin doğrulayabildiği bir bitiş koşuluyla özerk döngü güvenli olur. Bu planın her adımı, gerçek bir proje üzerinde uygulamalı bir kursta gösterilmektedir.