Üretimde Multi-Agent Sistemlerin Gizli Maliyeti: Döngü Kilitleri, Token İflası ve Hata İzolasyonu Mimarisi Nasıl Olmalı?

Saat 02.14. Araştırma ajanı fiyat aracından boş sonuç alıyor. Planlayıcı daha dar sorgu istiyor; araştırmacı aynı sorguları farklı kelime sırasıyla çalıştırıyor. Denetleyici kanıtı yetersiz bulup görevi geri veriyor. Exception yok, pod ayakta, model 200 dönüyor. Yine de iş bitmiyor. Otuz yedi dakika sonra tek run 6,8 milyon token tüketmiş ve tenant bütçesini bitirmiş durumda.

Multi-agent sistemlerin pahalı arızası çoğu zaman crash değil, geçerli görünen adımların ilerleme üretmeden sürmesidir. LangGraph, CrewAI veya özel orchestrator grafiği kurmayı kolaylaştırır. Üretim güvenliği ayrı bir sözleşmedir: hangi değişim ilerleme sayılır, bir run ne kadar tüketebilir, aynı karar kaç kez tekrarlanabilir, delegasyon ne kadar büyüyebilir ve bir arıza ne kadar yayılabilir?

1. Sonsuz döngü graph cycle ile aynı şey değildir

A → B → A kenarı hata değildir; eleştiri ve düzeltme döngü ister. Tehlike aynı semantik state’e dönüp pahalı etkiyi yeniden üretmektir. Prompt birkaç kelime değişse bile normalize tool, argümanlar, kanıt kümesi ve karar aynıysa ilerleme yoktur. Bu durum crash değil livelock’tur.

LangGraph recursion limit son emniyet kemeridir. CrewAI tarafında max_iter, max_execution_time, max_rpm ve retry/guardrail limitleri sert tavan sağlar. Fakat limit 100 ise kötü run 99 pahalı çağrı yapabilir; limit 5 ise meşru görev erken kesilebilir. Step cap, bütçe ve ilerleme sinyali birlikte çalışmalıdır.

planner -> researcher -> reviewer -> planner

Mesru dongu: acik soru azalir, yeni otoriter kanit gelir,
validation error kapanir veya gercekten farkli action secilir.
Ilerleme yok + pahali action tekrari = livelock.

2. Deterministik state: sohbet geçmişi state değildir

Kontrol akışı yalnız messages listesindeyse sistem modelin serbest metnini yeniden yorumlar. Production state typed ve versioned olmalıdır. LLM öneri üretir; deterministic policy geçişi doğrular. Aynı checkpoint, policy sürümü ve kayıtlı tool sonuçları replay edildiğinde aynı node seçilmelidir. Modeli tekrar çağırmak replay değil yeni nondeterministic attempt’tir.

class RunState(BaseModel):
    run_id: UUID
    state_version: int
    policy_version: str
    current_node: str
    status: str
    step_count: int
    llm_calls: int
    tool_calls: int
    input_tokens: int
    output_tokens: int
    cost_micros: int
    deadline_at: datetime
    delegation_depth: int
    open_children: int
    progress_digest: str | None
    no_progress_streak: int
    pending_effects: list[EffectIntent]

State bounded kalmalıdır. Yüzlerce tool cevabını her prompt’a eklemek token iflasının ikinci nedenidir. Ham sonuç object store referansı, digest, provenance ve kısa structured summary ile taşınır. Summary kayıplı cache’tir; kimlik, para, izin ve kanıt otoritesi değildir.

3. Paralel ajanlarda state yarışı

İki sub-agent aynı snapshot’ı okuyabilir. Biri on iki kaynak eklerken diğeri eski sürümden kanıt yok yazarsa last-write-wins doğru sonucu kaybeder. Her sonuç expected_version ile commit edilir. Çakışan çıktı, alan bazında deterministic reducer yoksa stale kabul edilir.

UPDATE agent_runs
SET state=:next_state, state_version=state_version+1,
    step_count=step_count+1
WHERE run_id=:run_id AND state_version=:expected_version
  AND status='RUNNING'
RETURNING state_version;
-- 0 rows: stale writer, lost lease veya terminal run.

4. Çok katmanlı loop circuit breaker

Tek sayaç yeterli değildir. Hard limit en kötü durumu sınırlar; no-progress detector erken yakalar; token ve maliyet budgetı model boyutunu kapsar; deadline yavaş tool’u keser; delegation depth ve fan-out üstel child üretimini önler; tenant budgetı ayrı ayrı geçerli run’ların toplam iflasını durdurur.

def admit_next(s, action, estimate):
    signature = hash_canonical(action.tool, normalize(action.args), action.evidence_ids)
    return all([
      s.step_count + 1 <= 40,
      s.tokens + estimate.tokens <= 180_000,
      s.cost_micros + estimate.cost_micros <= 2_500_000,
      now() + estimate.p95_duration < s.deadline_at,
      s.open_children < 8,
      repeated(signature,s) < 3,
      s.no_progress_streak < 4])

Kullanım çağrıdan önce ihtiyatlı rezerve edilir, sonra actual usage ile uzlaştırılır. Timeout olan çağrı ücretsiz sayılmaz; sağlayıcı işi tamamlamış olabilir. Stream iptalinin faturayı durdurduğu da sağlayıcı sözleşmesi olmadan varsayılmaz.

5. İlerleme digest’i nasıl kurulur?

Tüm state’i hash’lemek işe yaramaz; timestamp ve yeni cümle hash’i değiştirir. Domain projection gerekir. Araştırmada açık soru, canonical kaynak, doğrulanmış iddia ve çelişki; kod ajanında failing test, patch digest ve build sonucu kullanılır. Trace ID, süre ve açıklama dışarıda kalır.

def progress_projection(s):
    return {
      'unresolved': sorted(s.unresolved_ids),
      'evidence': sorted(e.canonical_id for e in s.evidence if e.accepted),
      'validated': sorted(s.validated_claim_ids),
      'conflicts': sorted(s.open_conflict_ids),
      'artifact': s.artifact_digest,
    }

Aynı digest her zaman hata değildir: transient 429 sonrası bir bounded retry doğru olabilir. Digest, attempt sonucu ve retry sınıfıyla yorumlanır. Durable scheduler available_at zamanına kadar bekler; modele sınırsız başka yol dene demez.

6. Token iflası: görünmeyen yüzde 1 nasıl 400 dolar yakar?

Temsili senaryoda günde 1.000 run var. Yüzde 1 loop’a giriyor; her runaway 22 gereksiz çağrı yapıyor. Çağrı 14.000 input ve 1.200 output token. Yalnız denklem için input 3 USD/milyon, output 15 USD/milyon varsayalım. Çağrı 0,060 USD, runaway 1,32 USD, otuz gün 396 USD olur. Bu güncel sağlayıcı fiyat iddiası değil, hata oranının matematiğidir.

cost/call = 14,000/1M x $3 + 1,200/1M x $15 = $0.060
monthly = 1,000 x 1% x 22 x $0.060 x 30 = $396

Arama, API, CPU, trace, checkpoint ve bloke kapasite dahil degil.

Alarm faturadan önce run içinde çalışır. Reserved ve actual token/maliyet ile breaker’ın kestiği no-progress segmentindeki wasted token tutulur. Tenant, workflow sürümü, model, node ve tool kırılımı olmadan prompt büyümesi, loop ve retry ayrıştırılamaz.

7. p99 gecikme maliyeti

Adım p99 değerleri toplanarak uçtan uca p99 bulunmaz. Korelasyon, retry ve branch join dağılımı gerekir. Trace corpus replay veya ortak bağımlılıkları koruyan Monte Carlo modeli kullanılır. Kritik yol uzayıp retry arttıkça tail hızla büyür.

Model 8 vCPU orchestrator, 100 in-flight run, aynı sentetik trace ve 20 dakikalık pencere varsayar; gerçek benchmark değildir. Güvenlik kontrolleri p50’ye küçük maliyet eklerken p99’u yaklaşık yüzde 74 azaltır. Milisaniyelik CAS, checkpoint ve admission dakikalık patolojik kuyruğu önler.

8. Hata izolasyonu ve idempotent yan etkiler

Search sağlayıcısı bozulduğunda writer, ödeme tool’u veya başka tenant etkilenmemelidir. Bulkhead agent adına değil kıt kaynağa göre kurulur: model quota, browser, database pool, code sandbox ve outbound domain. Her havuzun ayrı concurrency, queue ve deadline bütçesi olur.

Tool çağrısı ile state commit atomik değildir. Önce effect intent ve idempotency key yazılır; çağrı transaction dışında yapılır; sonuç SUCCEEDED, FAILED veya UNKNOWN olarak uzlaştırılır; state conditional commit edilir. Framework checkpoint’i dış yan etkiyi exactly-once yapmaz.

9. LangGraph ve CrewAI’ye uygulama

LangGraph’te recursion limit hard cap olarak kalır; state’e budget sayaçları ve progress digest eklenir; pahalı node öncesi deterministic admission çalışır. Checkpointer recovery sağlar, effect node’ları yine idempotent olmalıdır. Interrupt human review için, reducer paralel merge semantiği için kullanılır.

CrewAI’de max_iter, max_execution_time, max_rpm ve retry limitleri ilk katmandır. Task guardrail ve Pydantic output geçersiz sonucu durdurur. Flow state run kimliği ve typed kontrol alanlarını taşır; listener/router kenarlarına budget ve progress kontrolü eklenir. Delegation açılırsa depth ve child sayısı ayrıca sınırlanır.

10. Operasyon ve chaos testleri

• Step count, no-progress streak ve action tekrar sayısı.
• Reserved/actual token, cost ve wasted token.
• Node/model/tool/tenant p50-p95-p99.
• Delegation depth, fan-out ve join wait.
• Checkpoint süresi, state conflict ve stale completion.
• PENDING yaşı ve UNKNOWN effect.
• Breaker reason dağılımı.

Alarm oran ve süreye dayanır: aynı workflow sürümünde no-progress breaker 15 dakikada yüzde 0,5’i aşarsa, p99 üç pencere SLO dışındaysa veya UNKNOWN effect beş dakikadan eskiyse müdahale edilir. Kill switch model, tool, workflow version ve tenant kapsamlarında ayrı olur.

Chaos testi; timeout olup tamamlanan tool, checkpoint sonrası crash, aynı version’a paralel yazma, yeniden sıralanmış tool argümanı, uzun 429 ve human interrupt sonrası resume senaryolarını enjekte eder. Kabul ölçütü yalnız doğru cevap değil; bütçe içinde terminal state, duplicate etki olmaması ve replay’de aynı kontrol kararıdır.

Sonuç: otonomi sınırsızlık değildir

Production multi-agent sistem persona koleksiyonu değil, pahalı nondeterministic çalışanları yöneten dağıtık workflow’dur. Step, token, para, süre, fan-out ve effect bütçeleri state’e yazılır; ilerleme domain digest ile ölçülür; state optimistic version ile korunur; dış etkiler idempotency ve reconciliation’dan geçer; arızalar resource ve tenant bulkhead’lerinde tutulur.

Çok ajanlı mimari sınırları, event-driven LLM worker tasarımı ve GIL/p99 kapasite analizi bu protokolün tamamlayıcı parçalarıdır.

11. Retry bütçesi ile loop bütçesini ayırmak

Retry aynı node’un transient arıza sonrası yeniden yürütülmesidir; loop ise policy’nin yeniden aynı veya başka node’a dönmesidir. İkisini tek attempt sayacına koymak gözlemi bozar. Her tool invocation için attempt_no, error_class, available_at ve result_certainty; run için transition_count ve semantic_action_count tutulur. Bir 429 retry’si progress streak’i artırmaz, fakat token veya wall-clock bütçesini tüketmeye devam eder.

Backoff process belleğinde sleep değildir. Sonraki deneme zamanı kalıcı yazılır, worker lease’i bırakır ve kapasite başka tenant’a geçer. Retry-after varsa alt sınır kabul edilir; exponential backoff full jitter ile yayılır. Job deadline yeni attempt’in p95 süresi ve commit payını karşılamıyorsa retry planlanmaz. Bu ayrım retry fırtınasının agent loop’u gibi görünmesini ve worker slotlarını sessizce tutmasını önler.

12. State şeması ve policy sürümü nasıl migrate edilir?

Saatler veya günler bekleyen human-interrupt run’ları varken state şemasını yerinde değiştirmek risklidir. Checkpoint schema_version, policy_version, prompt_version ve tool_contract_version taşır. Resume sırasında migrator eski state’i yeni şemaya deterministic dönüştürür veya run’ı eski worker revision’a yönlendirir. Eksik alanı modelden tahmin etmek migration değildir. Yan etki üretmiş eski run için yeni policy geçmiş kararı geriye dönük değiştiremez.

Blue-green agent deployment’ında yeni run’lar revision B’ye gider, revision A yalnız kendi açık run’larını bitirir. Metrikler revision etiketiyle ayrılır. Breaker eşiğini prompt değişikliğiyle aynı anda değiştirmeyiz; aksi hâlde kalite, maliyet ve kontrol politikasının etkileri ayrıştırılamaz. Rollback yalnız kodu değil uyumlu checkpoint reader, tool contract ve effect reconciler’ı da kapsar.

13. İnsan incelemesi de bounded bir queue olmalıdır

Breaker açıldığında her run’ı insana atmak güvenli görünür, fakat yeni bir kuyruk iflası yaratır. Human review reason, risk, harcanan bütçe, son progress projection ve önerilen seçeneklerle gelir. Tenant ve risk sınıfına göre SLA, maksimum bekleme süresi ve queue kotası uygulanır. Süresi dolan düşük riskli iş kontrollü başarısız olur; finansal veya geri döndürülemez iş otomatik onaylanmaz.

İnsan kararı da versioned command’dir. Reviewer gördüğü state_version’ı gönderir; arada state değişmişse eski onay uygulanmaz. Approve, edit, reject ve retry farklı event tipleridir. Kimlik, zaman, gerekçe ve uygulanan policy audit log’a yazılır. Böylece human-in-the-loop, belirsizliği başka bir ekrana taşımak yerine yürütme protokolünün denetlenebilir parçası olur.