Otonom yapay zeka ajanı: ajanı saatlerce çalışmaya bırakıp çöp üretmesini nasıl engellersiniz

Otonom yapay zeka ajanı nedir ve sıradan istekten neyle ayrılır

Ajanla sıradan çalışma adım adımdır: prompt yazarsınız, ajan bir adım atar, sonucu görür ve sonrasını siz belirlersiniz. Otonom yapay zeka ajanı ise bir döngüde çalışır: son durumun nasıl görüneceğini bir kez tarif edersiniz, sonrasında ajan "yap — kontrol et — düzelt" adımlarını hedefe ulaşılana ya da bütçe bitene kadar kendisi tekrarlar. Başlattıktan sonra yerinizden kalkabilirsiniz.

Kulağa basit gelir, ama tipik ilk deneyim şöyledir: ajan sabah bir görev almış, akşam olduğunda bir saattir zaten düzeltilmiş bir hatayı tekrar düzelttiğini görürsünüz, çünkü bir saat önce ne yaptığını unutmuş. Kimse ona ne zaman duracağını ve ne zaman insanı çağıracağını söylemedi. Aşağıda, bunun olmasını engelleyen bir döngünün nasıl tasarlanacağı var.

Önemli bir çekince: döngü harness'in yerini tutmaz. Harness tek bir çalışmayı güvenilir kılar, döngü çalışmaları kesintisiz hale getirir. Zayıf bir harness'in üstüne kurulan döngü, çöpü sadece daha hızlı üretir.

Görev otonom ajan için uygun mu

İlk soru: işin makine tarafından kontrol edilebilen bir bitiş çizgisi var mı? "Testler/payments dizinindeki tüm testler geçiyor", "listedeki tüm özellikler passing durumunda", "metrik başlangıç çizgisine göre arttı" — uygun. "Kodu daha iyi yap" ya da "ödemeleri geliştirmeye devam et" — uygun değil: bu hedefin bitişi yoktur, döngü bütçe bitene kadar döner.

Dört tür döngüyü ayırt etmek faydalıdır:

• Adım adım — her prompt'u siz yazarsınız; bu normal etkileşimli çalışmadır.
• Hedefe göre — hedefi siz verirsiniz, durdurmayı bağımsız kontrol ya da bütçe yapar. Saatlerce çalışan otonom ajan budur.
• Zamana göre — zamanlanmış çalıştırma (örneğin sabah CI'da düşen build'lerin incelenmesi), durdurmayı elle yaparsınız.
• Olaya göre — dış tetikleyici (yeni issue, düşen deploy) başlatır; olayın işlenmesi ya da tekrar limiti durdurur.

Sık yapılan hata, zamana göre döngüyü hedefe göre döngüyle karıştırmaktır: "her 10 dakikada bir ödemeleri yapmaya devam et". Zamanlanmış döngü her seferinde talimata sıfırdan başlar ve neyin yapıldığını bilmez. Görevin bir bitişi varsa, ilerlemeyi hatırlayan hedefe göre bir döngü gerekir.

Adım 1. Kum havuzu: ajan nerede hata yapabilir

Gözetimsiz çalışan bir ajan er ya da geç yanlış bir şey yapacaktır: bir dosyayı silecek, bir migrasyonu yeniden yazacak, ağır bir komut çalıştıracaktır. Bu yüzden soru "hata yapmasın diye ne yaparım" değil, "hata olursa hiçbir şeye mal olmasın diye ne yaparım" olmalıdır.

• Ayrı çalışma kopyası. git worktree, ajana aynı depo üzerinde kendi dizinini ve dalını verir. Ana dal dokunulmaz kalır, birden çok ajan birbirini engellemez, başarısız çalışma tek komutla silinir.
• Konteyner ya da sanal makine. Ajanın komutlara tam erişimi gerekiyorsa, onu ev dizinine, anahtarlara ve prod veritabanlarına erişimi olmayan bir konteynerde çalıştırın.
• Test verisi. Yerel veritabanı, ödeme sistemlerinin sandbox'ları, sahte anahtarlar. Ajanın ortamında tek bir prod sırrı bile olmamalı.

# otonom çalışma için ayrı dal ve dizin
git worktree add ../shop-agent -b agent/f03-refunds

# çalışmadan sonra: sonucu görmek ya da atmak
git -C ../shop-agent log --oneline main..
git worktree remove ../shop-agent

Adım 2. İzinler: görev için yeterli minimum

Ajan ne kadar uzun tek başına çalışırsa, izinleri o kadar dar olmalıdır. Claude Code'da izinler settings.json içinde ayarlanır (araçlar ve komutlar için allow ve deny listeleri): görevin ihtiyacı olanı açıkça izin verin — testleri çalıştırma, linter, çalışma kopyasında dosya düzenleme — ve tehlikeliyi yasaklayın: ana dala push, sırlarla çalışma, ihtiyaç yoksa ağ komutları.

Ajanın onay istemeden her şeyi yaptığı mod yalnızca izole bir kum havuzunda kabul edilebilir; en kötü sonuç atılan bir konteyner olmalıdır. Anahtarlarınıza ve depolarınıza erişimi olan iş makinesinde bunu yapmayın.

Asla çiğnenmemesi gereken yasakları metinle değil mekanizmayla destekleyin. Talimattaki "migrations/ dizinine dokunma" bir dilektir; bu dizine yazmayı engelleyen bir hook ya da dosya sistemi hakları ise garantidir.

Adım 3. Hedef, doğrulama, durdurma — başlamadan üç satır

En basit çalışan döngü üç şeye dayanır ve bunları çalıştırmadan önce yazmak gerekir, sonradan değil:

1. Hedef — son durumun nasıl göründüğü.
2. Doğrulama — hedefe ulaşıldığını makinenin kontrol edebileceği yol: başarı ya da hata döndüren bir komut.
3. Durdurma koşulu — hedef sağlanmasa bile döngünün durduğu deneme, zaman ya da para sınırı.

Bunları ayrı bir yöntem dosyasında tutmak iyidir; bu dosyayı yalnızca insan düzenler. Ödeme backend'i için bir örnek:

# program.md — otonom çalışmanın yöntemi

## Hedef
.agent/feature_list.json içindeki tüm özellikler passing durumunda.

## Metrik
Passing özellik sayısı. Monoton artar. Gerileme = hemen geri alma.

## Kısıtlar
- Aynı anda tek özellik üzerinde çalışılır.
- migrations/ ve infra/ dizinlerine dokunulmaz.
- Kayıt olmadan bağımlılıklara dokunulmaz.

## Çalışma sırası
1. passing olmayan ilk özelliği al.
2. Uygula, pytest ve linter'ı çalıştır.
3. Yeşilse — commit ve .agent/progress.md'ye kayıt. Kırmızıysa — düzelt.

## Durdurma ve eskalasyon
- Tek özellikte 3 başarısız deneme — blocked olarak işaretle, sonrakine geç.
- Kalan tüm özellikler blocked ise — dur ve rapor yaz.
- Müşteri parasıyla, erişim haklarıyla, veri silmeyle ilgili her görev — yapma, eskale et.

Adım 4. Deneme-düzeltme döngüsü ve diskteki hafıza

Bağlam penceresi uzun işi taşımaz: dolar, sıkıştırılır, oturum yeniden başlar. Bu yüzden ilerleme ajanın "kafasında" değil dosyalarda yaşamalıdır: durumlarıyla birlikte görev listesi, neyin yapıldığını ve neyin işe yaramadığını tutan bir günlük, git geçmişi.

İyi bir model, Andrej Karpathy'nin autoresearch projesindeki "yalnızca ileri giden çarkı" fikridir; burada ajan gecede yüzlerce ML deneyi yürütür. Her iterasyon şöyledir: yöntemi oku, bir hipotez öne sür, değişikliği yap, sabit bir zaman bütçesiyle deneyi çalıştır, temel çizgiyle karşılaştır. İşe yaradıysa commit, yaramadıysa geri al. Sonuç günlüğe yazılır, sonra bir sonraki hipotez gelir.

Bu şemadan iki karar alınmalıdır:

• Deneme başına sabit bütçe. Denemeler karşılaştırılabilir hale gelir ve tek bir başarısız hipotez tüm geceyi yemez.
• Ana dalda yalnızca iyileştirmeler. Çalışmayan her şey geri alınır, yan yana yığılmaz. git log, sabah okuması kolay, doğrulanmış bir çalışma günlüğü haline gelir.

Aynı şemada dosya bazında rol ayrımı da görülür: altyapıyı ve değerlendirmeyi kimse değiştirmez, deney kodunu yalnızca ajan değiştirir, yöntemi yalnızca insan. Ajan, ölçüm yolunu kurcalayarak sonucu "iyileştiremez".

Adım 5. Kimin hazır olduğuna karar verir: ayrı değerlendirici

İnsan döngüde yoksa, ajanın öz değerlendirmesi tek fren olur — ve bu fren çalışmaz. Kodu az önce yazmış bir ajan, kodun doğru olduğunu düşünmeye meyillidir: kendi akıl yürütmesini görür ve ne yapmak istediğini "bildiğini" sanır.

Üretici ile değerlendiriciyi ayırmanın kuralları:

• Değerlendirmeyi işi yapan oturum yapmaz. Claude Code'da bunun için alt ajanlar uygundur: her birinin kendi bağlamı vardır.
• Değerlendirici temiz bağlam alır: gereksinim, diff ve test sonuçları — icracının akıl yürütmesinden hiçbir şey yok.
• Mümkünse değerlendirici farklı bir model, en azından farklı bir rol promptu ile çalışır.
• Karar bir rubrikle verilir ve her madde kanıta bağlanır: test satırına, komut çıktısına, diff'teki yere.

Makine kontrolleri yine de birincildir. Değerlendirici, testlerin yakalayamadığı şeyler için gerekir: gereksinimin yanlış anlaşılması, testin koda göre uydurulması, değişikliğin göreve sınırın ötesine taşması.

Durdurma kriterleri: ajan ne zaman pes etmeli

Durdurma koşulu olmayan bir döngü er ya da geç kendi kendine döner. Asgari set:

İlerlemeyi deneme sayısıyla değil özle kontrol edin: "40 iterasyon yapıldı" hiçbir şey söylemez, "yeşil özellik sayısı 5'ten 9'a çıktı" bir şey söyler. Görev takılıyorsa, döngüyü bir kez daha çalıştırmak yerine işi bir insana devretmek gerekir.

Otonom ajanın hemen görünmeyen riskleri

Bariz riskler — silinen dosyalar ve bozulan derleme — kum havuzu ve izinlerle kapatılır. Daha tehlikeli olanlar, haftalar içinde birikip sessizce büyüyen maliyetlerdir:

• Doğrulama borcu. "Normal görünüyor" yerine "makine tarafından doğrulandı". Panzehir, istisnasız yalnızca makine tarafından doğrulanabilir durdurma koşullarıdır.
• Anlayış erozyonu. Kendi kodunuzu giderek daha az bilirsiniz. Panzehir, diff'lerin zorunlu okunmasıdır: döngünün hızı sizin okuma hızınızı geçmemeli.
• Bilişsel teslimiyet. Sonuç hakkında görüşünüz kalmaz ve her şeyi olduğu gibi kabul edersiniz. "Sonra bakarım" diyip bakmadığınız durumları dürüstçe saymak faydalıdır.
• Bağlam şişmesi. Uzun çalışma geçmişi biriktirir; her sonraki adım daha pahalı ve daha kötü olur. Bağlam sıkıştırma ve harici hafıza ilk döngüden itibaren gerekir, her şey kaydığında değil.

İlk otonom döngüyü bir akşamda nasıl çalıştırırsınız

"Ajan görevleri kendisi bulup yapsın" ile başlamayın. Otonomi basamak basamak büyür: önce hedef ve durdurma koşulu olan tek bir görev, sonra zamanlanmış tek bir otomasyon, sonra izole bir çalışma kopyasında ayrılmış icracı ve doğrulayıcı, ve ancak ondan sonra kendi işini bulan ve paralel çalışan döngüler.

1. Haftada en az iki kez elle yaptığınız ve bitişi doğrulanabilir bir görev bulun.
2. Hedefi, doğrulamayı ve durdurma koşulunu yazın — üç satır.
3. Ayrı bir worktree açın ve izinleri ayarlayın: testler ve dosya düzenleme serbest, push ve sırlar yasak.
4. Bir ilerleme dosyası açın ve ajandan her iterasyondan sonra güncellemesini isteyin.
5. Rolleri ayırın: icracı yazar, doğrulayıcı diff'i ayrı bağlamda değerlendirir.
6. Genel bir limit koyun ve ilk seferde sonucu sabaha değil, bir saat sonra kontrol edin.

Sonuç

Otonom yapay zeka ajanı, ancak çerçevesi kadar güvenilirdir: hatanın bir şeye mal olmadığı kum havuzu, minimum izinler, makine tarafından doğrulanabilir hedef, diskte hafıza, ayrı bir değerlendirici ve insana eskalasyonlu sert durdurma koşulları. Bunlar olmadan uzun bir çalışma zaman kazandırmaz, ertelenmiş bir enkaz temizliğine dönüşür. Böyle bir döngünün gerçek bir proje üzerinde, program.md'den bağımsız değerlendiriciye kadar nasıl kurulacağı harness engineering kursunda uygulamalı olarak anlatılır.