Claude Code ile birden fazla proje yürütünce alt ajanların sayısı sürekli arttı.
İhtiyaç duydukça birer tane oluşturdum ve sayı 22’ye ulaştı.
Geçen ay bunu 17’ye düşürdüm.
Ama kapatırken neden kapattığımı not etmemiştim.
3 ay sonra arşiv klasörünü açınca neden kapattığımı anlayamadım.
Beş taneden yalnızca birinde gerekçe yazıyordu.
Bunları yapan tek kişi ben olmama rağmen durum böyleydi.
Neden 22’ye kadar çıktı?
Artırırken gerekçe her zaman nettir. İhtiyaç olduğu için oluşturursunuz.
Sorun ters tarafta. Kapatırken “belki ileride kullanırım” düşüncesi sürekli takılır.
İşe yaramadığından emin olamadığınız için olduğu gibi bırakırsınız. Böylece sayı 22 oldu.
Şimdi geriye dönüp bakınca artışın tek bir nedeni vardı.
“Bu bir ajan değil, araç olmalı” kararını veren bir gate yoktu.
Bir iş tekrarlıysa, prosedürü sabitse ve bağlam değerlendirmesi gerektirmiyorsa, o bir ajan değildir.
Skill veya script olarak yapılabilir. Token harcamaz, %100 yeniden üretilebilirdir ve oturum değişse bile unutulmaz.
Bu gate yoksa her şey ajana dönüşür.
Kapatılan beş tane
Geriye doğru çıkarınca tasfiyenin dört türe ayrıldığını gördüm. Bu ayrım önemliydi.
Bir tanesi en baştan ajan olmamalıydı.
İçerik yazımını üstleniyordu ama prosedürü tamamen sabitti.
İki skill ile değiştirip kapattım. Bunun geri getirilmesini yasak olarak netleştirdim.
Aksi halde bir gün biri yeniden oluşturur.
Üç tanesinin rolü başka şeylerle örtüşüyordu.
Güvenlik kontrolü kod denetimiyle, cron izleme health check ile, planlama ise yürütmeyle örtüşüyordu.
Hepsi aynı alanda, aynı yetkilere sahipti.
Buradan edindiğim bir ölçüt var.
İki ajan aynı alan ve aynı yetki düzeyinde örtüşüyorsa,
ayrı tutmanın maliyeti (yönetim yükü, delege etme kararındaki gecikme) faydasını aşar.
“İkisi de gerekli aslında” hissi uzun süre ayağıma dolandı;
ama sormam gereken, gerekli olup olmadıkları değil, ayrı tutmaya değip değmedikleriydi.
Bir tanesini ise kimse kullanmıyordu.
İlgili işlevin trafiği 70 gün boyunca 0’dı.
Bunu kaldırma değil, uykuya alma olarak işledim. Servis yeniden başlarsa aynen geri getirilecek.
Sayı yazarken öğrendiklerim
22 → 17’yi dokümana yazarken bir şeyi fark ettim.
Bu sayı dosya sayısı değil. Operasyonda olan ajan sayısı.
Tanımı dizinin dışında olan bir tane de vardı; yalnızca dosyaları sayarsanız 21 ve 16 çıkıyor.
Bu yüzden dokümanın en başına, bu sayının neyi saydığını yazdım.
Ayrıca git ls-tree ile doğrulama sonucunu da ekledim.
Yoksa ileride biri dosyaları sayıp “bu tutmuyor” demekle kalır.
Sayı yazarken tanımı ve doğrulama yöntemini birlikte yazmak gerekiyormuş.
Kapatırken uymaya karar verdiklerim
Bu sefer yaşadıklarımdan dört kural çıktı.
-
Kaldırma anında gerekçeyi dosyaya yaz. Yazmazsan 3 ay sonra geriye dönük çıkarmak zorunda kalırsın. Gerçekten böyle oldu.
-
Silme; rename ile taşı. İçerik %100 korunduğu için orijinali aynen geri getirilebilir.
-
Geri getirilmesi yasak olan kalemleri açıkça belirt. Yazmazsan bir gün biri diriltir.
-
Geri getirme prosedürüne “emildiği yerdeki mükerrer rolü kaldır” maddesini ekle. Bunu atarsan geri getirildiğinde ikisi aynı işi yapar.
Birlikte düzenlediklerim
Bu vesileyle 4 yıllık kuralları derleyip yayımladım. Birkaçını yazayım.
Gizli yoldan aşmak yok
Ajan bir kısıta takıldığında onu delmek yerine raporlamasını sağlayan kural.
Haklı bir engelleme varsa yalnızca o adım beklemeye alınır, geri kalanı devam eder.
Yanlış karar gibi görünen bir engelleme olsa bile keyfi biçimde etrafından dolaşılmaz. Gerekçeler toparlanıp iletilir ve onay alınır.
Ve eğer engelleme kuralın kendisindeki bir kusuru ortaya çıkardıysa, o kusuru düzeltmek de müdahalenin parçasıdır.
Aslında bu kuralın kendisi de böyle doğdu. Bir engellemeyle karşılaştıktan sonra oluşturdum.
FAIL’i PASS gibi yazma
Talimatla kapatılan bir iş olsa bile ölçülen durumu olduğu gibi yazıp yeniden açma koşullarını bırak.
Raporlama Before/After ölçülen değerleriyle yapılır; kalan işler ve riskler başarıdan önce yazılır.
Ajanlar temelde başarılı rapor verme baskısı hisseder. Bunu kuralla engellemezseniz sürekli böyle yaparlar.
Özerkliği nicel eşiklerle tanımlama
“Değişikliğe izin var/yok” ikiliği yerine, analiz tipi ajanın kendi başına düzeltebileceği kapsamı sayılarla belirledim.
-
Yalnızca 1 dosya
-
5 satırdan az
-
Üst seviye dosya değil
-
Etki puanı eşiğinin altında
Hepsi sağlanmalı (AND); bir tanesi bile takılırsa üst onaya gönderilir.
Ve son madde kritik: belirsizse delege etme isteği gönder. Varsayılan değer muhafazakâr olmalı ki kural çökmesin.
Karar ve icranın ayrılması
Doğrulama ve inceleme işleri salt okunur alt ajanlarla paralel fan-out yapılır;
dosya ve DB icrası ise orchestrator tarafından merkezde seri olarak yürütülür.
Çünkü paylaşılan bir dosyayı birden fazla ajan aynı anda değiştirirse mutlaka bozulur.
Bunun bir bedeli var. Büyük ölçekli işlerde merkezî seri yürütme darboğazdır.
Yavaşlayacağını bile bile, çakışmadan daha iyi olduğuna karar verdim.
Depo
https://github.com/YoungChulMoon/claude-agent-harness
Birkaç Markdown dosyasından oluşuyor. Kurulacak bir şey yok.
Şablonu .claude/agents/ altına koyup yalnızca gerekli kısımları doldurmanız yeterli.
Tek doğru olmaktan çok, bu ortamda 4 yıl boyunca işe yarayan yöntem bu.
Ekip büyüklüğüne veya projenin niteliğine göre uymayabilir.
Ajanları artırma hikâyeleri çok, azaltma hikâyeleri pek yok.
Benzer şekilde ajanları çoğalan kişilere referans olmasını umarım.
Henüz yorum yok.