Hermes ile zamanlanmış işlerde asıl mesele: Görev çalıştı mı, iş bitti mi?
Hermes ile zamanlanmış işlerde asıl mesele: Görev çalıştı mı, iş bitti mi?
Sabah dokuzda bir ajan rapor hazırladı. Görev ekranında çalışma tamamlanmış görünüyor. Öğleden sonra ekip rapora bakmaya çalıştığında dosyanın eski sürüm olduğunu fark ediyor. Ajan metni üretmiş, ama depoya gönderememiş. Zamanlayıcı açısından çalışma bitmiş olabilir; operasyon açısından bitmemiştir. Ajanları düzenli işe sokarken çözülmesi gereken mesele, yalnızca onları doğru saatte uyandırmak değil, yaptığı işin gerçekten hedefe ulaştığını gösterebilmektir.
Hermes Agent, Nous Research’ün açık kaynaklı ajan çalıştırma ortamı. Terminalde ve farklı mesajlaşma yüzeylerinde araç kullanan ajanlar çalıştırabiliyor; profil, beceri, oturum ve zamanlanmış görev düzeni sağlıyor. Bir modelin cevap üretmesini, dosya okuma ve yazma, dış sistemlerle konuşma, işi tekrar deneme gibi adımlarla birleştiren katman bu. Önceki Hermes yazılarında genel mimariyi ve ajan organizasyonunu ele almıştık. Burada daha dar bir noktaya bakıyoruz: zamanlanmış bir işin sonucunu nasıl güvenilir biçimde teslim ederiz?
Saat geldiğinde ne başlar?
Hermes’in cron sistemi tek seferlik ve tekrarlayan işler çalıştırabiliyor. Göreve beceriler eklenebiliyor, sonuçlar yapılandırılmış bir hedefe iletilebiliyor. Dokümantasyonun önemli bir ayrıntısı şu: zamanlanmış işler yeni ajan oturumlarında başlıyor. Bir önceki çalışmanın sohbetini olduğu gibi devralmıyorlar. Bu, bir görevin ilk kez hangi bağlamla başladığını belirginleştiriyor; fakat dünkü kararın bugünkü oturum tarafından kendiliğinden bilineceği anlamına gelmiyor.
Örneğin bir içerik ekibi, her gün farklı bir teknik konuyu anlatan yazı yayımlatıyor olsun. Prompt yalnızca “sıradaki yazıyı yaz” diyorsa yeni oturum sıranın nerede kaldığını tahmin etmek zorunda kalır. Önceki dosyalara bakıp tahmin yürütebilir; ancak biri eski yazıyı düzeltmişse ya da yayın ile kayıt farklı zamanlarda tamamlanmışsa bu tahmin yanlış olabilir. Konu sırası açık bir durum dosyasında tutulmalı. Yeni oturum işe başlarken o dosyayı okur, yalnızca belirlenen konuyu işler ve başarılı teslimden sonra durumu ilerletir. Kalıcı hafıza tercihleri ve yöntemleri taşıyabilir; kesin işlem konumunu tutmak için ayrıca okunabilir bir kayıt gerekir.
Üç farklı başarı ölçüsü
Zamanlanmış ajan işinde birbirinden ayrı üç olay vardır. İlki ajanın çalışması: oturum açıldı, araçlar çağrıldı ve içerik üretildi. İkincisi teslim: değişiklik ilgili depoya ya da API hedefine gönderildi. Üçüncüsü hedefteki sonuç: gönderilen sürüm doğru yerde görünüyor mu, yayın sistemi onu işledi mi? Bu üç olayı tek bir “başarılı” etiketi altında toplamak, arıza anında neyin eksik kaldığını gizler.
Bir blog örneğinde yerel dosya oluşturulması ilk aşamadır. İç bağlantı denetimi ve derleme geçmesi, dosyanın mevcut sitede işlenebilir olduğuna dair güven verir. Git push ise kaynak depoya teslimi kanıtlar. Ancak push tek başına canlı sitenin güncellendiğinin kanıtı değildir; otomatik dağıtımın ayrıca tamamlanması gerekir. Raporlama dili de bunu yansıtmalı: “dosya yazıldı”, “depo güncellendi” ve “canlı sayfada görüldü” farklı cümlelerdir. Son adım kontrol edilmediyse gerçekleşmiş gibi yazılmamalı.
Bu ayrım yalnızca yayın işlerine özgü değil. Bir ajan bir destek kaydı açtığında HTTP yanıtını almak yeterli olmayabilir; kaydın hedef sistemde hangi kimlikle oluştuğunu okumak gerekebilir. Bir ajan envanter raporu hazırladığında ise dosyanın varlığını değil, verinin hangi zaman aralığını kapsadığını kontrol etmek gerekir. Harness işin araç çağrılarını yürütür. Bitmiş sayılma koşulunu ekip tanımlar.
Tekrar çalıştırınca ne olur?
Cron işleri kusursuz bir ortamda çalışmaz. Ağ kesilebilir, depo bu sırada başka bir ekip tarafından güncellenebilir, işlem birinci adımda başarılı olup ikinci adımda durabilir. “Bir daha çalıştır” refleksi, aynı yazıyı iki kez yayımlamak ya da aynı kaydı iki kez açmak gibi sonuçlar doğurabilir. Bu yüzden tekrar çalıştırılabilir görev, iş başlamadan önce bugüne ait sonucun zaten var olup olmadığını sorgulamalı.
İçerik örneğinde işlem sırası şöyle kurulabilir: önce uzak depodaki güncel sürümü al; kendi konu durumunu oku; bugünün kaydına ve hedef dosya adına bak; daha önce tamamlanmışsa yazmayı bırak. Dosya mevcut ama durum ilerlememişse ikinci bir konuya atlamadan önce tutarsızlığı bildir. Yeni dosya üretildiyse denetimlerden geçir; yalnızca kendi dosyalarını commit et ve gönder. Sonra uzak dal ile yerel dalın aynı noktada olduğunu kontrol et. Bu adımlar, ajan için süslü bir talimattan çok, yeniden başlatılabilir bir iş sözleşmesidir.
Kritik ayrıntı, durum dosyasının ne zaman değiştiğidir. Konu tamamlanmadan sırayı ilerletmek, başarısız yazıyı hiç yazılmayacak konuya dönüştürür. Konu gönderilip durum kaydı gönderilemezse de iki sistem birbirinden ayrılır. Böyle bir durumda “tamamlandı” mesajı vermek yerine hangi adımın eksik kaldığını kaydetmek ve sonraki çalışmada aynı işi ikinci kez yayımlamadan bu farkı çözmek gerekir. Ajanın kendi logu, teslimin yerine geçmez; ama bu farkı görünür kılar.
Profiller ve sınırların gerçek yeri
Hermes profilleri ayrı yapılandırma, oturum, hafıza ve zamanlanmış işler için ayrı ev dizinleri sunuyor. Bir profil günlük içerik üzerinde çalışırken diğeri destek taleplerini izleyebilir. Böylece birinin kayıtları ötekinin geçmişiyle karışmaz. Bu ayrım kullanışlıdır, fakat profil adı tek başına dış serviste yetki denetimi değildir. Bir ajanın hangi API anahtarına, depo iznine veya üretim ortamına erişebildiği ayrıca tanımlanmalıdır.
Küçük bir pilotta önce geri alınabilir, düşük riskli bir görev seçmek iyi olur. Görevin girdisi, çıktı yolu, kabul kontrolü ve başarısızlık mesajı yazılı olmalı. Ardından kasıtlı olarak bir hata durumu denenebilir: bağlantı kesilirse ikinci çalıştırma ne yapıyor, doğrulama başarısızsa durum kaydı ilerliyor mu? Bu deneme, “ajan yazı yazabiliyor mu?” sorusundan daha değerlidir. Gerçek işlerde güven, güzel görünen sonuçtan değil, aksaklık karşısındaki davranıştan doğar.
Hermes bir ajanın ne zaman, hangi araçlarla ve hangi oturum bağlamında çalışacağını düzenler; işin organizasyon içindeki sahibi ve kabul yetkisi ise ayrıca tanımlanmalıdır. Bu eksik halkayı ele almak için agentic-organization, AI ajanlarını organizasyon şemasında birinci sınıf üye olarak yönetmeye yönelik self-hosted, dosya tabanlı bir platform sunar.