Yapay zeka ajanları artık e-posta yanıtlamaktan müşteri taleplerini yönetmeye kadar pek çok işi üstleniyor. Ancak tam otonom çalışan bir ajanın kritik bir kararı yanlış vermesi, dakikalar içinde zincirleme sorunlara yol açabilir. İşte tam bu noktada ajan otomasyonunda gözden geçirme (review) süreci devreye giriyor. Bu süreç, ajanın belirli aksiyonları gerçekleştirmeden önce bir insanın onayını almasını sağlar—sektörde buna “Human-in-the-Loop” (HITL) deniyor.
Kilit Çıkarım: Tam otonom ajanlar hız kazandırır, ancak yüksek riskli işlemlerde insan onayı olmadan çalışmak ciddi hatalara kapı açar. Doğru kurulmuş bir review süreci, hız ile güvenlik arasındaki dengeyi kurar.
Başlamadan Önce
Review sürecini entegre etmek için bazı temel bileşenlere ve ön koşullara ihtiyacınız var. Eksik bir parçayla başlamak, ileride sizi geriye döndürür.
Gerekenler
- Bir ajan framework’ü (LangChain, CrewAI, AutoGen veya özel geliştirme)
- Bildirim kanalı (Slack, e-posta, webhook veya dashboard)
- Durum yönetimi için veritabanı veya state store
- API erişimi olan bir LLM (GPT-4, Claude, Gemini vb.)
Ön Koşullar
- Ajanınızın temel iş akışı çalışır durumda olmalı
- Hangi aksiyonların onay gerektireceğini belirlemiş olmalısınız
- Onay verecek kişi/kişilerin rolleri tanımlanmış olmalı
- Timeout senaryoları için varsayılan davranış kararlaştırılmış olmalı
Review Sürecinin Temel Mimarisi
Gözden geçirme süreci, ajanın normal akışına bir “checkpoint” eklemek anlamına gelir. Ajan kritik bir noktaya geldiğinde durur, insana bildirim gönderir ve yanıt bekler. Bu mimari üç ana bileşenden oluşur:
- Tetikleyici (Trigger): Hangi aksiyonların review gerektirdiğini belirleyen kurallar
- Bekleme Mekanizması (Pause State): Ajanın onay beklerken durumunu koruması
- Yanıt İşleyici (Response Handler): Onay, red veya değişiklik taleplerini işleyen mantık
Güncel framework’lerde bu yapı genellikle “human-as-a-tool” pattern’i ile implemente ediliyor. Yani ajan, insan onayını sanki bir araç çağırıyormuş gibi kullanıyor.
Adım Adım Kurulum
- Kritik aksiyonları tanımla: Tüm ajan aksiyonlarını listele. Hangilerinin geri dönüşü zor veya maliyetli? Bunları “review gerektiren” olarak işaretle. Örneğin: ödeme işlemleri, veri silme, dış sistemlere yazma.
- Review tetikleyicisini konfigüre et: Framework’üne göre değişir. LangChain’de HumanApprovalCallbackHandler, CrewAI’da human_input=True parametresi kullanılır. Özel sistemlerde ise aksiyondan önce bir kontrol fonksiyonu çağır.
- Bildirim kanalını entegre et: Onay bekleyen işlem hakkında detaylı bilgi gönder. Mesajda şunlar olmalı: ne yapılmak isteniyor, neden, beklenen sonuç ve onay/red butonları veya komutları.
- State persistence ekle: Ajan onay beklerken durumunu kaybetmemeli. Redis, PostgreSQL veya dosya tabanlı bir state store kullan. Sunucu yeniden başlasa bile ajanın kaldığı yerden devam edebilmesi şart.
- Timeout ve fallback tanımla: Onay gelmezse ne olacak? Üç seçenek var: işlemi iptal et, varsayılan güvenli aksiyonu al veya escalation yap. Timeout süresini iş kritikliğine göre ayarla (genellikle 15 dakika–24 saat arası).
- Yanıt işleme mantığını yaz: Üç temel yanıt tipi için handler oluştur: Onay (proceed), Red (abort + log), Değişiklik talebi (modify parameters + retry).
- Loglama ve audit trail ekle: Her review kararını, kimin ne zaman verdiğini ve gerekçesini kaydet. Bu hem debugging hem de compliance için kritik.
Pro İpucu: İlk kurulumda çok fazla aksiyonu review kapsamına alma. Başlangıçta sadece en riskli 2-3 aksiyonla başla, sistemi test et, sonra kapsamı genişlet. Aksi halde onay kuyruğu tıkanır ve insanlar “otomatik onayla” refleksine girer.
Framework’lere Göre Uygulama Detayları
| Framework | HITL Yöntemi | Kurulum Zorluğu | Esneklik |
|---|---|---|---|
| LangChain | HumanApprovalCallbackHandler, interrupt_before | Orta | Yüksek |
| CrewAI | human_input parametresi, HumanLayer entegrasyonu | Düşük | Orta |
| AutoGen | UserProxyAgent ile human_input_mode | Düşük | Orta |
| Özel Geliştirme | Webhook + State Machine | Yüksek | Çok Yüksek |
Hazır framework kullanıyorsan, yerleşik HITL özelliklerini tercih et. Özel ihtiyaçların varsa veya mevcut sistemlerle derin entegrasyon gerekiyorsa, kendi state machine’ini yazmak daha mantıklı olabilir.
Yaygın Hatalar ve Kaçınılması Gerekenler
- Her şeyi review’a sokmak: Onay yorgunluğu yaratır, insanlar düşünmeden onaylamaya başlar
- Belirsiz bildirimler göndermek: “Onay bekliyor” yerine “X müşterisine 500₺ iade yapılacak, onaylıyor musunuz?” gibi net mesajlar kullan
- Timeout tanımlamamak: Onay gelmezse ajan sonsuza kadar bekler, iş akışı durur
- Audit log tutmamak: Sorun çıktığında kimin neyi onayladığını bulamazsın
- Tek onaylayıcıya bağımlı kalmak: O kişi tatildeyken sistem kilitlenir
Mini Senaryo: Şu Durumda Ne Yaparsın?
Diyelim ki bir e-ticaret ajanın var ve müşteri şikayetlerini otomatik çözüyor. Ajan, bir müşteriye 1.000₺’lik iade yapmaya karar verdi ama şirket politikası 500₺ üzeri iadelerde yönetici onayı gerektiriyor.
Doğru akış şöyle işlemeli:
- Ajan iade tutarını hesaplar (1.000₺)
- Tetikleyici kuralı kontrol eder: 1.000₺ > 500₺ → review gerekli
- Slack’e bildirim gider: “Müşteri #4521’e 1.000₺ iade öneriliyor. Sebep: Kargo hasarı. Onaylıyor musunuz?”
- Yönetici “Onayla” butonuna tıklar
- Ajan işlemi tamamlar ve sonucu loglar
Yönetici 2 saat içinde yanıt vermezse? Sistem otomatik olarak müşteriye “Talebiniz inceleniyor” mesajı gönderir ve işlemi bir üst yöneticiye escale eder.
Sıkça Sorulan Sorular
Review süreci ajanın hızını ne kadar etkiler?
Tamamen insan yanıt süresine bağlı. Kritik olmayan işlemleri review dışında tutarak ortalama işlem süresini makul seviyede tutabilirsin. Acil işlemler için daha kısa timeout ve paralel onaylayıcı havuzu kullan.
Birden fazla onaylayıcı nasıl yönetilir?
İki yaygın model var: “herhangi biri onaylarsa yeter” veya “belirli sayıda onay gerekli”. İkincisi yüksek riskli finansal işlemler için tercih edilir. Rol bazlı yetkilendirme ile hangi işlemin kimi gerektirdiğini tanımlayabilirsin.
Ajan onay beklerken başka işlem yapabilir mi?
Asenkron tasarımda evet. Ajan bir işlem için onay beklerken diğer bağımsız görevlere devam edebilir. Bunun için her görevi ayrı bir “task” olarak yönetmen ve state’leri izole tutman gerekir.
Hangi durumlarda tam otonom çalışmak mantıklı?
Düşük riskli, geri dönüşü kolay ve sık tekrarlanan işlemlerde. Örneğin: SSS yanıtlama, randevu hatırlatma, basit bilgi sorgulama. Finansal işlemler, veri değişiklikleri ve dış sistem entegrasyonlarında ise review şart.
Sonuç
Ajan otomasyonunda gözden geçirme süreci kurmak, başlangıçta ekstra iş gibi görünse de uzun vadede sizi ciddi hatalardan korur. Kritik aksiyonları belirle, uygun bir bildirim kanalı seç, state yönetimini sağla ve timeout senaryolarını planla. Başlangıçta dar kapsamlı tut, sistemi test et, sonra genişlet.
Unutma: En iyi otomasyon, insanı tamamen devre dışı bırakan değil, insanın müdahale edeceği noktaları akıllıca seçen otomasyondur. Human-in-the-loop yaklaşımı, yapay zeka ajanlarının güvenilirliğini artırırken esnekliğini de korumanın en pratik yolu olmaya devam ediyor.