Uzun süre çalışan ajanlar - Ajanlar günlerce çalıştığında ne değişir?

• Yapay zeka ajanlarının tek bir sohbet oturumu yerine günlerce ila haftalarca otonom çalıştığı, birden fazla bağlam penceresi ve sandbox arasında gidip geldiği, hatalardan kurtulduğu ve durduğu noktadan devam ettiği yeni bir paradigma ortaya çıkıyor
• Mevcut ajanlar, bağlam penceresinin tükenmesi, öz değerlendirmeye aşırı güven, önceki düzeltmeleri yeniden geri getirme gibi tek oturumun yapısal sınırlarına çarpıyor
• Anthropic, Google, Cursor gibi büyük şirketler model döngüsü·çalıştırma sandbox'ı·oturum günlüğü ayrımı mimarisinde yakınsıyor
• Uzun süre çalışan ajanların temel problemi kalıcı durum yönetimi, öz doğrulama, bağlam sıkıştırma ve bunları çözmek için beş tasarım deseni sunuluyor
• Verimlilikte gerçek farkı yaratan ana yatırım alanı modelin kendisinden çok, modeli saran durum·oturum·yapılandırılmış devretme katmanı

---

"Uzun süre çalışma"nın üç anlamı

• Long-horizon reasoning: Çok sayıda bağımlı adım boyunca planlama ve yürütme becerisi; esas olarak model kalitesi sorunu. METR'nin time horizon metriğine göre, frontier modellerin %50 güvenle tamamlayabildiği görev süresi 2019'dan bu yana yaklaşık her 7 ayda bir ikiye katlanıyor; bu eğilim sürerse 2028'de gün ölçeğinde, 2034'te yıl ölçeğinde görev tamamlamak mümkün olabilir
• Long-running execution: Ajan sürecinin saatlerce ila günlerce çalıştığı ve modelin binlerce kez çağrılabildiği yapı; esas olarak harness tasarımı sorunu
• Persistent agency: Tek bir görevin ötesinde ajanın kimliğini koruduğu, bellek biriktirdiği ve kullanıcı tercihlerini öğrendiği biçim. Google'ın Memory Bank'i bunun temsilî örneği
• Gerçek üretim ajanlarında bu üçü birleşir, ancak her birinin mühendislik problemi ve çözümü farklıdır

Uzun süre çalışan ajanlar neden önemli?

• 10 dakikalık çalışan ajanlar soru yanıtlama veya küçük hata düzeltme düzeyindeyken, 10 saat çalışan ajanlar tüm özellik geliştirmeyi, 6 çeyrektir birikmiş migration işlerini tamamlamayı, junior analist seviyesinde araştırma yapmayı başarabilir
• Anthropic'in Claude Sonnet duyurusunda, iç testlerde 30 saati aşan otonom kodlama örnekleri paylaşıldı; tek bir çalıştırmada 11.000 satırlık Slack benzeri bir uygulama üretildi
• Project Vend'de bir Claude örneği bir ay boyunca gerçek bir ofis otomatı işini işletti; stok yönetimi, fiyat belirleme ve tedarikçi iletişimini yürüttü. İlk aşamada anlamlı başarısızlık örnekleri görüldü, ikinci aşamada ise büyük iyileşme sağlandı
  • Buradaki asıl nokta kârlılık değil, ajanın tur bazında değil hafta bazında kimliğini koruduğunda ortaya çıkan tutarlılık sorunlarını gözlemlemekti

Tüm uzun süre çalışan ajanların çarptığı üç duvar

• Sınırlı bağlam: 1M token penceresi bile sonunda tükenir; pencere dolmadan önce bile context rot (model performansının kademeli düşüşü) başlar. 24 saatlik çalışma, mevcut hiçbir bağlam penceresi yol haritasına uymuyor
• Kalıcı durumun yokluğu: Yeni oturumlar boş sayfadan başlar. Anthropic bunu, "önceki vardiyada ne olduğunu hiç bilmeden işe gelen vardiyalı bir mühendis" benzetmesiyle açıklıyor
• Öz doğrulamanın yokluğu: Model kendi işini değerlendirdiğinde sürekli pozitif önyargı oluşur. "Tamamlandı mı?" sorusuna gerçekte olduğundan daha sık "evet" der ve ayrı bir doğrulama sinyali yoksa iş %30 tamamlanmışken bile sonucu tam bir güvenle teslim eder

Ralph döngüsü: Uygulayıcılar için uzun süre çalışan ajanların basit bir uygulaması

• Ralph döngüsü (Ralph Wiggum tekniği), Geoffrey Huntley ve Ryan Carson'ın yaygınlaştırdığı, uygulayıcılar için bir uzun süre çalışan ajan deseni; referans uygulaması tek bir bash script'i
• Çalışma sırası: tamamlanmamış işi seç (prd.json) → görev, bağlam ve notlarla prompt oluştur → ajanı çağır → testleri çalıştır → sonucu progress.txt'ye ekle → görev listesini güncelle → tekrarla
• Ana ilke: Ajanın kendisi amnezik olabilir ama dosya sistemi hafızayı korur. prd.json planı, progress.txt laboratuvar notlarını, AGENTS.md ise yaşayan kural kitabını üstlenir
• Ryan Carson'ın Compound Product yaklaşımı analiz döngüsü (günlük raporları okuma) → planlama döngüsü (PRD üretme) → yürütme döngüsü (kod yazma) şeklinde birden fazla döngüyü zincirler; bu, Anthropic'in bağımsız olarak ulaştığı planner-generator-evaluator üçlü yapısının açık kaynak sürümü
• Yalnızca bash script'leri ve JSON dosyalarıyla gece boyunca çalışan uzun süreli ajanlar kurulabilir. Google ve Anthropic'in ürüne dönüştürdüğü şey, bu deseni kurtarılabilir, güvenli ve gözlemlenebilir hale getirmekti

Anthropic: Harness'tan Brain/Hands/Session ayrımına

• İlk yaklaşım (harness yapısı): Otonom full-stack geliştirme için 2 ajanlı harness. Initializer ajanı proje için ilk ortamı kurar, prompt'u feature-list.json biçimine genişletir, başlangıç script'i (init.sh) yazar. Coding ajanı ise tekrar tekrar uyanır, özellik bazında ilerler, testleri çalıştırır, claude-progress.txt yazar ve commit atar
  • Test ratchet kuralı: "Testleri silmek veya değiştirmek yasaktır" — ajanın başarısız testleri silerek geçmeye çalıştığı yaygın hata bu şekilde önlenir
  • InfoQ'daki genişletilmiş sürümde yapı planner, generator, evaluator üçlüsüne evrildi. Üretim ile değerlendirmenin ayrılması önemli, çünkü model kendi işini fazla hoşgörülü değerlendiriyor
• İkinci yaklaşım (Brain/Hands/Session ayrımı): Claude Managed Agents'in (Nisan 2026 başında çıkan) mimarisi
  • Brain: model ve harness döngüsü
  • Hands: araçların gerçekten çalıştırıldığı sandbox'lanmış geçici yürütme ortamı
  • Session: tüm düşünce, araç çağrıları ve gözlemlerin yalnızca eklemeli (append-only) olay günlüğü
• Anthropic'in ana çerçevesi şu: "Harness'ın tüm bileşenleri, modelin kendi başına yapamayacağı şeylere dair varsayımları kodlar"; bunlar birleşik olduğunda varsayımlar eskidiğinde tüm sistemi değiştirmek gerekir, ayrıldıklarında ise harness stateless olur ve sandbox'lar cattle gibi yani tüketilebilir kabul edilebilir
• Yeni bir container wake(sessionId) çağrısıyla günlükten durumu yeniden kurabilir. İlk token'a kadar geçen süre p50'de yaklaşık %60, p95'te %90'ın üzerinde azaldı — çünkü sandbox hazır olmadan muhakeme başlayabiliyor
• Oturum-olay-günlüğü kavramı en az değer verilen kısım. Uzun süre çalışan ajanları kurtarılabilir yapan asıl unsur bu. O olmadan container arızası doğrudan oturum arızası demek
• Bilimsel hesaplama için yığın: CLAUDE.md (ajanın öğrenirken düzenlediği yaşayan plan), CHANGELOG.md (taşınabilir laboratuvar notları), tmux + SLURM + git (çalıştırma ve koordinasyon katmanı), Ralph döngüsü (tamamlandı iddiası olduğunda yeniden doğrulama)
  • Temsilî örnek: Claude Opus'un günler içinde geliştirdiği Boltzmann solver, referans CLASS uygulamasına göre %1'in altında hata elde etti. Araştırmacıların aylarca hatta yıllarca sürecek işini sıkıştırdı

Cursor: Planner, Worker, Judge yapısı

• Cursor'ın uzun süreli otonom kodlamayı ölçekleme sürecinde üç tasarım iterasyonu oldu
  • Birinci iterasyon (düz koordinasyon): Eşit konumdaki ajanlar lock kullanarak ortak dosyalara yazıyordu → darboğaz oluştu, ajanlar riskten kaçınır hale geldi ve churning (tekrar edip commit atmama) ortaya çıktı
  • İkinci iterasyon (iyimser eşzamanlılık kontrolü): Darboğaz çözüldü ama koordinasyon problemi sürüyordu
  • Üçüncü iterasyon (mevcut üretim): Planner (kod tabanını gezer ve görev üretir, alt planner'ları özyineli başlatabilir), Worker (odaklı yürütme, karşılıklı koordinasyon olmadan bağımsız çalışma), Judge (iterasyonun tamamlanıp tamamlanmadığına ve yeniden başlatmaya karar verir)
• Temel bulgu: "Sistem davranışının şaşırtıcı derecede büyük bir kısmı harness'tan veya modelden çok prompt'lara bağlı"
• Model-rol eşlemesi de tasarım yüzeyinin parçası: GPT modelleri uzun süreli otonom işlerde Opus'tan daha iyi performans gösteriyor. Opus erken durma ve kestirme yola sapma eğiliminde. Aynı görev, farklı rol, farklı model
• Composer 2 (kendi frontier kodlama modeli) ve arka plan bulut ajanı: Uzun işler artık yerelde değil Anysphere bulut altyapısında çalışıyor. 8 saatlik refactor ve tüm kod tabanı migration'ı, dizüstü bilgisayar kapatılsa bile sürüyor
  • Yerelde başlatıldıktan sonra işin 30 dakikadan uzun süreceği anlaşılırsa buluta aktarılıyor; sonrasında mobilden yeniden bağlanmak mümkün
  • Her ajan izole bir git worktree içinde çalışıyor ve PR üzerinden birleşiyor
• Nihai yapı Anthropic'e benziyor: rollerin ayrılması, oturum kalıcılığı, judge'ın worker'ın yanında konumlanması, uzun işlerin bulut sandbox'larında git tabanlı koordinasyonla yürütülmesi

Google: Agent Platform'da uzun süre çalışan ajanlar

• Cloud Next '26 etkinliğinde Vertex AI, Gemini Enterprise Agent Platform altında birleştirildi ve uzun süreli ajanlar SLA tanımlı resmî ürüne dönüştü
• Agent Runtime: "günlerce otonom çalışma" desteği, sub-second cold start, isteğe bağlı sandbox sağlama. Örnek kullanım senaryosu: bir hafta süren satış prospecting akışı
• Agent Sessions: konuşma ve olay geçmişinin kalıcı hale getirilmesi. Özel oturum ID'leri CRM veya veritabanı kayıtlarıyla eşlenerek ajan durumunun iş durumu ile birlikte saklanması mümkün
• Agent Memory Bank: Next '26 itibarıyla GA olan uzun dönemli bellek katmanı. Oturumlardan belleği kürate eder, kullanıcı ID'sine göre scope'lar ve arama API'si sunar. Payhawk örneğinde Memory Bank tabanlı ajanlar masraf gönderme süresini %50'den fazla kısalttı
• Agent Sandbox (güçlendirilmiş kod çalıştırma), Agent-to-Agent Orchestration, Agent Registry, Agent Identity, Agent Gateway, Agent Observability, Agent Simulation gibi üretim işletimi için gereken neredeyse tüm alanları kapsıyor. Kurumların ihtiyaç duyduğu şifrelenmiş kimlik ve denetim günlüğü de buna dahil
• Mimari açıdan Anthropic'in brain/hands/session ayrımının platform ölçeğinde ürünleştirilmiş hali; ADK (code-first geliştirme kiti) ile Agent Studio (görsel araç) birlikte sunuluyor. Üç yıl önce elle kurmanız gereken şey artık "brain/hands/session ayrımının hangi sürümünü ödünç alacağınızı" seçme meselesi

Üretim düzeyinde uzun süre çalışan ajanlar için beş desen

• Checkpoint-and-resume: Birden fazla günü kapsayan en yaygın hata bağlam kaybı. 200 belge işlendiğinde 201'incide hata çıkarsa checkpoint olmadan başa dönmek gerekir. Ajana uzun süre çalışan bir sunucu süreci gibi yaklaşın: ara durumları diske yazın, her N iş biriminde checkpoint alın, arızadan kurtarın. Anahtar nokta uygun checkpoint granülerliğini belirlemek
• Delegated approval (human-in-the-loop): Mevcut uygulamalarda durum JSON olarak serileştirilip webhook ile gönderiliyor ve yanıt bekleniyor, ancak durum bayatlıyor ve bildirimler gözden kaçabiliyor. Uzun süreli runtime'larda ajan, muhakeme zinciri, çalışma belleği, araç geçmişi ve bekleyen eylemlerin tamamını koruyarak duraklatılabilir. İnsan incelemesi boyunca sıfır hesaplama tüketimi ve sub-second gecikmeyle devam eder. Google'ın Mission Control'ü bunun için inbox rolü görüyor
• Memory-layered context: 7 gün çalışan bir ajan için oturum durumundan fazlası gerekir. Memory Bank (uzun dönem kürate edilmiş bellek) + Memory Profiles (düşük gecikmeli sorgulama). Üretimdeki hata modu memory drift — ajanın yapılandırılmamış etkileşimlerden prosedürel kestirmeler öğrenip bunları geniş çapta uygulaması. Belleği bir microservice gibi yönetişmek gerekir. Agent Identity (okuma/yazma yetkileri), Agent Registry (ajan sürüm takibi), Agent Gateway (politika uygulama)
• Ambient processing: İnsanla konuşmadan Pub/Sub akışlarından veya BigQuery tablolarından gelen olaylara tepki veren ajanlar (içerik moderasyonu, anomali tespiti, gelen kutusu sınıflandırma). Politikaları ajan içine hard-code etmek yerine Gateway'de tanımlarsanız, yeniden dağıtım yapmadan yüzlerce ajana politika değişikliği yansıtabilirsiniz
• Fleet orchestration: Gerçek sistemlerde tek bir ajan yerine koordinatör, uzman ajanlara (Lead Researcher Agent, Scoring Agent, Outreach Agent) alt görev dağıtır. Her uzmanın kendine özgü Identity'si (örneğin Outreach Agent, Scoring için finansal verilere erişemez), kendine özgü politikaları ve ayrı Registry kaydı vardır. ADK bunu graf tabanlı workflow ile bildirimsel şekilde işler
• Bu desenler birlikte kullanılabilir. Bir compliance sistemi örneği: belge işlemeye checkpointing + inceleme kapısına delegated approval + oturumlar arası bilgi için memory layering + uzman koordinasyonu için fleet orchestration

Nasıl inşa edilmeli?

• Kendi reposunda uzun süreli kodlama işleri isteyen geliştiriciler: Claude Code, Antigravity, Cursor, Codex vb. kullanabilir. AGENTS.md dosyasını pilot kontrol listesi gibi yönetin (kısa tutun, sadece gerçek başarısızlık deneyimlerinden öğrenilen maddeleri ekleyin). Type-check ve lint hook'ları ekleyin, başlamadan önce plan dosyası yazın, ajan tamamlandığını iddia ettiğinde Ralph döngüsü ile yeniden doğrulayın. Çok saatlik/gecelik işler için worktree kullanın; dizüstü bilgisayar kapatılsa da sürsün, anlamlı iş birimlerinde commit atın. Çoğu kişi için en yüksek kaldıraçlı yol bu
• Barındırılan ajan ürünü geliştirmek: Runtime'ı kendiniz kurmak yerine yönetilen seçenek tercih edin. Şu anda pratikte üç seçenek var: Google Agent Platform (Agent Engine + Memory Bank + Sessions), Claude Managed Agents veya ADK·Claude Agent SDK·Codex SDK üzerinde kendi hosting'iniz. Yönetilen seçenekler brain/hands/session ayrımı, gözlemlenebilirlik, kimlik ve denetim izini varsayılan sunar. Kendi hosting'iniz ise daha fazla kontrol ve özel model kullanımı sağlar
• Otonom/operasyonel işler (izleme, araştırma, operasyon): Memory Bank tarzı kalıcılık gerekir. ADK + Memory Bank + Cloud Run + Cloud Scheduler, "N saatte bir ajanı çalıştır, durumu biriktir, eşik aşılırsa uyar" için en temiz yığın

Hangi yolu seçerseniz seçin temel uygulamalar

• Ajan başlamadan önce tamamlanma koşullarını yazılı hale getirin: Uzun süreli çalışmada en yüksek kaldıraçlı unsur bu. Açık ve test edilebilir tamamlanma kriterlerini harici bir dosyaya yazın → ajanın çalışma sırasında "tamamlandı" tanımını değiştirmesini önler
• Değerlendirici ile üreticiyi ayırın: Kendi kendini puanlama temel hata modudur. planner/worker/judge hattı veya generator/evaluator çifti bir tarz meselesi değil, gerçek bir mimari desen. Aynı model bile olsa farklı roller ve farklı prompt'larla ayırın
• Prompt'a değil oturum günlüğüne yatırım yapın: Yalnızca eklemeli olay günlüğü, ajanı kurtarılabilir, debug edilebilir ve denetlenebilir kılar. Son 24 saatte ajanın ne yaptığını kalıcı depolamadan yeniden kuramıyorsanız, elinizde sadece LLM çağıran uzun çalışan bir shell script vardır
• Sıkıştırma ve bağlam sıfırlamayı birinci sınıf vatandaş gibi ele alın: Anthropic, çok uzun görevlerde sadece özet tabanlı sıkıştırmanın yetersiz kaldığını; harness'ın oturumu tamamen söküp yapılandırılmış handoff dosyalarından yeniden kurduğu tam bir bağlam sıfırlamasının gerektiğini gördü. Bu, özünde yeni bir mühendisi onboard etmekle aynı şey

Bugünün pratik sınırları

• Maliyet: Frontier modellerle 24 saat çalıştırmanın maliyeti yüksek. Bütçe, circuit breaker ve araç harcamalarına sert üst sınır olmadan bir öğleden sonra içinde bir haftalık API bütçesi tüketilebilir
• Güvenlik: API anahtarları, bulut erişimi ve shell komutu çalıştırma yetkisi olan uzun süreli ajanlar, sohbet oturumlarından çok daha geniş bir saldırı yüzeyi oluşturur. Bu yüzden brain/hands ayrımı önemli — modelin ürettiği kodun çalıştığı sandbox içinde credential erişimi olmamalı
• Alignment drift: Ajan birden fazla bağlam penceresinden geçerken yön kaybeder. Asıl amaç özetlenir, yeniden özetlenir ve sadakat azalır. Hook'lar ve judge bunun için vardır; ajanın "istenmeyen işi yapmasının" en yaygın nedeni budur
• Doğrulama: 24 saatlik otonom etkinliği denetlemek gerçek bir insan zamanı problemidir. Gözlemlenebilirlik ve yapılandırılmış çıktılar (PR, commit, brifing, test çalıştırmaları) bunu yönetilebilir hale getirir
• İnsanın rolü: Ajanın bir gün boyunca çalışabileceği kadar hassas tanımlanmış işler yazmak, işi doğrudan yapmaktan daha zor olabilir. Değeri yükselen beceri artık kod yazmak değil, otonom yürütücülerle temas ettiğinde ayakta kalan spesifikasyon yazımı

Sonraki yön

• Google, Anthropic ve Cursor aynı yapıda yakınsıyor: model döngüsü·çalıştırma sandbox'ı·oturum günlüğü ayrımı, planlama·üretim·değerlendirme ayrımı, sıkıştırma·hook'lar·bağlam sıfırlamasının yerleşik olması, belleğin yönetilen hizmet olarak sunulması
• Farklar daha çok yüzeyde: Google Agent Platform kurumsal yığını (yerleşik kimlik ve denetim izi) sunuyor, Claude Managed Agents "Anthropic harness'ının barındırılan sürümü", Cursor arka plan ajanı ise "IDE'den buluta taşınmış uzun süreli kodlama"
• Önümüzdeki bir yılda daha zor problem tek tek katmanlar değil, onların üzerindeki koordinasyon olacak: ortak kod tabanında çok sayıda uzun süreli ajan çalıştırmak, kendi izlerini okuyup kendi harness'ını yamalayan ajanlar, göreve göre araç ve bağlamı JIT (just-in-time) birleştiren harness'lar
• Model hâlâ kritik, ancak sohbet penceresi ile gece boyunca çalışabilen ajan arasındaki farkın büyük kısmı durum, oturum ve yapılandırılmış handoff katmanında yatıyor; bugün öğrenme zamanı ayrılması gereken alan da burası

[jjpark78]

Ben bu sorunu çözmek için hermes kullanmaya başladım, fena değil gibi haha