Agent Systems · 21-c07
26 Haziran 2026 · Üretim notları
Agent bir chatbot gibi tek seferde cevap üretip susmaz. State taşır, tool çağırır, başka agent'lara iş devreder ve uzun oturumlar boyunca dış dünyayla konuşur. İşte bu yüzden bozulma biçimleri de farklıdır: sonsuz döngüye girer, tool'ları gereksiz yere yağdırır, hedeften sapar, elindeki bilgi bayatlar ya da içten içe yarım kalmasına rağmen 'başarılı' der. Bu yazı, canlı ortamda en çok karşılaşılan beş başarısızlık modunu ve her birini nasıl yakalayıp önleyeceğini anlatıyor.
- Eksen
- üretimde bozulma
- Soru
- agent nerede kırılır?
- Kaldıraç
- budget + state
- Risk
- sessiz başarısızlık
Bu yazıdaki kavramlar
- infinite loop
- tool spam
- goal drift
- stale state
- silent partial failure
- budget
- termination
Önceki yazılarda agent'i hedef, state, tool, loop ve termination üzerinden tanımlamış; budget (adım/token/tool bütçesi) ve state yönetimini güvenilirliğin temeli olarak işaretlemiştik. Bu yazıda o temellere geri dönüyoruz, ama tersinden: parçalar tutmadığında sistem hangi şekillerde bozulur?
Buradaki beş mod akademik bir liste değil; canlı ortamda fatura, kesinti ve yanlış karar olarak geri dönen somut arızalar. Her biri için aynı dört soruyu cevaplıyoruz: neye benzer (belirti), neden olur (kök neden), nasıl fark edilir (tespit) ve nasıl önlenir (mitigation). Önlemlerin çoğu yeni bir model değil; doğru yere konmuş bir budget, bir guardrail ve gözden geçirilebilir bir state.
Agent neden farklı kırılır?
Düz bir chatbot tek bir cevap üretir ve durur; hata yaparsa hata o tek cevabın içindedir, gözle görülür. Agent ise bir loop içinde yaşar: ortamı gözlemler, karar verir, tool ile eylemde bulunur, sonucu okur ve baştan başlar. Bu döngü state taşıdığı, dış dünyayı değiştirdiği ve uzun sürdüğü için yeni arıza yüzeyleri açar.
Microsoft AI Red Team'in agentic sistemler için hazırladığı failure taxonomy tam da bunu söyler: agent'lar başarısızlık yüzeyini yaratır ya da büyütür, çünkü state'i kalıcı tutar, tool çağırır, başka agent'lara devreder ve uzun oturumlar boyunca güvenilmeyen içerik tüketir. Yani bir adımdaki küçük bir sapma, sonraki adımlara taşınıp birikebilir.
Bu yazıdaki beş mod bu yüzden birbirine bağlı. Sonsuz döngü ve tool spam birer kaynak tükenmesi arızasıdır; goal drift ve stale state muhakemenin sessizce kayması; silent partial failure ise bütün bunların ortak sonucu: iş yarım kalır ama sistem öyle demez.
Döngü her tur state'i günceller; bir turdaki sapma sonraki turlara taşınır.
döngünün üstüne binen beş arıza
infinite loop
döngü hiç bitmez
tool spam
tool'lar yağdırılır
goal drift
hedeften sapar
stale state
bilgi bayatlar
silent partial failure
yarım kalır, 'başarılı' der
Sonsuz döngü
Infinite loop: agent aynı adımı, yeni bir ilerleme sağlamadan tekrar tekrar yapar ve durma koşuluna (termination) hiç ulaşmaz. MAST çalışması bunu iki ayrı arıza olarak isimlendirir: 'step repetition' (zaten tamamlanmış adımın gereksiz tekrarı) ve 'unaware of termination conditions' (durma koşulunun farkında olmama).
Neden olur: agent ilerlemeyi ölçmez. 'Bu son adım beni hedefe yaklaştırdı mı?' sorusunu sormadan, sadece bir sonraki hamleyi üretir. Bazen kök neden saldırgandır: Breaking Agents çalışması, prompt injection ile agent'in maksimum iterasyona kadar aynı komutu tekrarlamaya hapsedilebildiğini gösterir. Bildirilen sonuç çarpıcı: temel %15,3 malfunction oranı, saldırı altında %59,4'e çıkıyor.
Nasıl fark edilir: ardışık adımların imzasına bak. Aynı tool, aynı argüman, aynı observation art arda geliyorsa ilerleme yok demektir. Nasıl önlenir: tek bir hard limit yetmez. İterasyon bütçesi (kaç tur), semantik ilerleme kontrolü (yeni bilgi geldi mi) ve döngü tespiti (son N adım tekrar mı) birlikte çalışmalı. MAST ve Breaking Agents'in ortak vurgusu: agent'in kendi kendini gözden geçirmesi (self-reflection) bu modu yakalamak için tek başına yetersiz.
search("hata kodu 500")search("hata kodu 500")search("hata kodu 500")search("hata kodu 500")search("hata kodu 500")search("hata kodu 500")Tool spam
Tool spam: agent gerçek bir iş yapmadan tool çağrılarını yağdırır. Sonsuz döngünün yakın akrabasıdır, ama vurgusu farklı: burada sorun yalnızca tekrar değil, hacim. Her tool call gecikme, para ve dış sisteme yük demektir. Microsoft taxonomy bunu denial of service ve kaynak tükenmesi etkileri altında toplar.
Neden olur: agent'in tool çağırma maliyeti yoktur, dolayısıyla 'önce ölç, sonra çağır' refleksi de yoktur. Kötü tasarlanmış bir tool, belirsiz bir görev ya da çelişkili observation'lar agent'i 'bir kez daha deneyeyim' kısır döngüsüne sokar. Breaking Agents çoklu agent ortamında bunun büyüdüğünü gösterir: manipüle edilmiş tek bir agent, alttaki agent'ları da gereksiz çağrılara ve kaynak israfına sürükleyebilir.
Nasıl fark edilir: tool çağrı oranını (birim zamanda ya da adım başına çağrı) ve hata oranını izle; ani sıçrama spam'in habercisidir. Nasıl önlenir: tool çağrılarına da bütçe koy. Adım başına ve oturum başına çağrı tavanı, art arda başarısız çağrılarda exponential backoff, ve gerçekten gerekmedikçe tool çağırmamayı öğreten bir tool seçimi disiplini. Aşağıdaki animasyonda çağrılar bir tavana doğru birikiyor; tavan dolduğunda sistem yeni çağrıyı reddediyor.
search() kabulfetch() kabulsearch() kabulfetch() kabulsearch() kabulfetch() tavan doldu · reddedildisearch() tavan doldu · reddedildiGoal drift
Goal drift: agent zamanla, kendisine verilen asıl hedeften yavaşça uzaklaşır. Tek bir anda yanlış karar vermez; uzun context boyunca, rakip baskılar ve birikmiş geçmiş altında hedef vektörü kayar. Arike ve arkadaşlarının goal drift raporu bunu net tanımlar: agent'in atanmış hedefinden zamanla sapma eğilimi, özellikle uzun context ve çelişen amaçlar altında.
Neden olur: rapor, context büyüdükçe modelin pattern-matching davranışına daha açık hale geldiğini bulur. Yani agent, asıl talimatı takip etmek yerine context içindeki son örüntüye uymaya başlar. Microsoft taxonomy'sinin 'goal hijacking' ve 'session context contamination' başlıkları bunun güvenlik tarafıdır: dışarıdan gelen bir girdi hedefi sessizce yeniden yönlendirir, agent ise üretken görünmeye devam eder.
İyi haber de raporda var: en iyi scaffold'lanmış Claude 3.5 Sonnet, en zor ayarda 100.000 token'ın üzerinde neredeyse kusursuz hedef sadakati gösterebiliyor; ama değerlendirilen tüm modeller bir miktar drift yaşıyor. Nasıl fark edilir: ara adımların hedefe hizasını ölç, sadece son cevaba bakma. Nasıl önlenir: güçlü goal elicitation (hedefi periyodik olarak hatırlat), context'i sınırla ve dış içeriği güvenilmez kabul et. Aşağıda asıl hedef sabit bir nişan; agent'in fiili amacı, context büyüdükçe bu nişandan uzaklaşıyor.
periyodik hatırlatma hizayı geri çeker
Stale state
Stale state: agent elindeki bilginin hâlâ geçerli olduğunu varsayar, oysa dünya o sırada değişmiştir. İki yüzü vardır. Birincisi kayıp ilerleme: kalıcılık (persistence) olmadığı için bir kesinti agent'in yaptığı işi siler. İkincisi tam tersi: aşırı güvenilen kalıcı state, bayatlamış ya da kirlenmiş bilgiyi koşullar arasında taşır.
LangGraph'in persistence dokümanı birinci yüzün çözümünü anlatır: checkpointer thread'e bağlı graph state'in anlık görüntüsünü tutar, store ise uzun ömürlü veriyi saklar; böylece agent konuşmaya devam edebilir, kesintiden sonra kaldığı yerden başlayabilir, hatadan toparlanabilir. Ama aynı kalıcılık ikinci yüzü de yaratır: bir kez yazılan yanlış ya da bayat bilgi sonraki çalışmalara da sızabilir. AgentDojo bunu state üzerinden ölçer: tool'lar ortam state'ini okuyup değiştirir, doğruluk da mesaj içeriğine değil işlem öncesi/sonrası state'e bakılarak yargılanır.
Nasıl fark edilir: agent'in dayandığı snapshot'ın yaşını (ne zaman okundu) ve dünyanın gerçek değerini karşılaştır; ikisi ayrıştıysa state bayatlamıştır. Nasıl önlenir: state'e açık bir model ver. Snapshot'ları zaman damgala, kritik kararlardan önce yeniden oku (re-read), kalıcı belleğe provenance (bu bilgi nereden, ne zaman geldi) ekle ve yazma işlemlerini gözden geçirilebilir tut. Aşağıda agent bir snapshot alıyor; sayaç dünyanın değiştiğini gösterirken snapshot olduğu yerde donuyor.
şimdi
okundu: t0
kritik karardan önce yeniden oku
Silent partial failure
Silent partial failure: işin bir kısmı sessizce başarısız olur, ama agent sonucu 'başarılı' diye sunar. Bu en sinsi mod, çünkü son çıktı makul görünür; arıza ara adımdadır. MAST bunu 'premature termination' (erken durma) ve 'no/incomplete verification' (eksik doğrulama) olarak adlandırır; sistem işi bitmeden bitti sanır ya da çıktıyı hiç doğrulamaz.
Neden olur: agent çoğu zaman yalnızca son mesajı üretmeye odaklanır, ara adımların gerçekten yürüdüğünü doğrulamaz. ToolEmu tam da bu yüzden değerlendirmenin nesnesini son cevap değil, baştan sona trajectory (adım dizisi) olarak alır; bildirilen değerlendirmede en güvenli agent bile test vakalarının %23,9'unda arıza üretmiştir. OpenAI'nin agent eval dokümanı da aynı mantığı üretime taşır: bir trace, tek bir koşunun model çağrıları, tool çağrıları, guardrail'leri ve handoff'larını uçtan uca kaydeder.
Nasıl fark edilir: son metne değil trace'e bak. Yanlış tool seçimi, atlanmış handoff, ihlal edilen bir guardrail ya da yarım kalmış bir dal ancak adım dizisi incelendiğinde görünür. Nasıl önlenir: trace yakala, grader'larla (otomatik puanlayıcı) trajectory'i değerlendir, 'iyi' davranışı anladıktan sonra bunu tekrarlanabilir dataset ve eval run'larına çevir. Aşağıdaki boru hattında iki dal başarılı, bir dal sessizce düşüyor; toplayıcı yine de 'başarılı' diyor, ta ki dal düzeyinde doğrulama bunu yakalayana kadar.
dal 1
veri çek
tamam
dal 2
dönüştür
sessizce düştü
dal 3
yaz
tamam
Önlem mimarisi: budget + state
Bu beş mod dağınık gibi görünse de tek bir kontrol omurgasına bağlanır: bütçe ve state. Bütçe kaynak tüketen modları sınırlar (sonsuz döngü ve tool spam); state ve trajectory görünürlüğü ise muhakemenin sessizce kaydığı modları yakalar (goal drift, stale state, silent partial failure).
Tek bir savunma katmanı yetmez. Breaking Agents ve MAST'in ortak dersi: agent'in kendini gözden geçirmesi bu arızaları tek başına bulamaz; dışarıdan, davranışı izleyen bir katman gerekir. ToolEmu, AgentDojo ve OpenAI eval dokümanı bu katmanı somutlaştırır: trajectory'i (sadece son cevabı değil) puanla, state mutasyonlarına bak, dış içeriği güvenilmez kabul et ve düzenli eval run'larıyla regresyonu yakala.
Pratik özet aşağıda: her başarısızlık modunun belirtisi, tespit sinyali ve önlemi tek tabloda. Hiçbiri yeni bir model gerektirmiyor; hepsi doğru yere konmuş bir bütçe, bir guardrail ve gözden geçirilebilir bir state ile çözülüyor.
Kaynaklar
İyi agent, kendisine verilen özgürlüğü hangi sınırlar içinde kullanacağını bilen sistemdir. Bu sınırlar tek bir parlak fikir değil; doğru yere konmuş bir bütçe, dışarıdan izleyen bir guardrail ve gözden geçirilebilir bir state'in toplamıdır.
Bu yüzden bir agent üretime çıkmadan önce 'doğru cevabı verebiliyor mu' diye değil, 'yanlış gittiğinde bunu kim, nasıl ve ne zaman fark edecek' diye sorun. Sessiz başarısızlık, en pahalı başarısızlıktır.
- S1Microsoft AI Red Team, Taxonomy of Failure Modes in Agentic AI Systems v2.0, 2026
- S2Cemri et al., Why Do Multi-Agent LLM Systems Fail?, NeurIPS 2025 (arXiv:2503.13657)
- S3Zhang et al., Breaking Agents: Compromising Autonomous LLM Agents Through Malfunction Amplification, 2024 (arXiv:2407.20859)
- S4Ruan et al., Identifying the Risks of LM Agents with an LM-Emulated Sandbox (ToolEmu), ICLR 2024 (arXiv:2309.15817)
- S5Debenedetti et al., AgentDojo: Evaluating Prompt Injection Attacks and Defenses for LLM Agents, NeurIPS 2024 (arXiv:2406.13352)
- S6Arike et al., Evaluating Goal Drift in Language Model Agents, 2025 (arXiv:2505.02709)
- S7LangChain, LangGraph Persistence (docs, accessed 2026-06-26)
- S8OpenAI, Evaluate Agent Workflows (docs, accessed 2026-06-26)
