Çift tahsilatı geri alamazsın
Agent'ları üretimde patlatan şey genelde kötü akıl yürütme değil — yan etki. Retry'da çift-post, çift-tahsilat, çift-email. Her dış aksiyonu safe-to-retry yapmak, herhangi bir model yükseltmesinden çok iş yaptı.
Bir agent'ı üretimde gerçekten yalnız bıraktığında, seni gece kaldıran hata genelde sandığın yerden gelmez. Modelin 'yanlış düşünmesi' nadir; asıl bela yan etki. Agent bir adımı tamamlar, ağ takılır, harness retry eder — ve aynı dış aksiyon ikinci kez çalışır. Çift post atılır, çift email gider, müşteri iki kez tahsil edilir. Model mükemmel akıl yürütmüş olabilir; yine de iki fatura kesilmiştir.
Buradaki asimetri her şeyin özü: kötü bir cevabı geri alabilirsin, ama gönderilmiş bir tahsilatı geri alamazsın. Bir düşünceyi 'un-think' etmek bedava; bir aksiyonu 'un-send' etmek mümkün değil. Bu yüzden bir agent'ı bırakabilir kılan şey daha akıllı model değil — her dış aksiyonun tekrar çalıştırılmaya güvenli (safe-to-retry) olması.
Sorun reasoning değil, tekrar.
Autonomous bir agent demek = otomatik retry demek. Retry'ı kaldırırsan ilk ağ hatasında agent ölür; bırakırsan her shipped adım tekrar koşma riski taşır. Yani güvenilirlik probleminin merkezi modelin zekâsı değil, aksiyonların idempotency'si. Tek bir kural her şeyi değiştirir: dışarıya dokunan her çağrı, aynı girdiyle iki kez çalıştığında bir kez çalışmış gibi davranmalı.
// Kırılgan: retry = ikinci tahsilat
await stripe.charges.create({ amount, customer });
// Güvenli: aynı key → tek tahsilat, retry zararsız
await stripe.charges.create(
{ amount, customer },
{ idempotencyKey: `charge:${orderId}` }, // iş anahtarından türet
);Anahtar, rastgele bir UUID değil — işin kimliğinden türetilmeli (sipariş no, mesaj id, randevu id). Böylece retry aynı anahtarı taşır ve sağlayıcı 'bunu zaten yaptım' der. Email, webhook, DB insert, dış API: hepsi aynı mantıkla korunur (unique constraint, upsert, dedup tablosu).
Pratikte ne yapıyorum.
- ▸Dışarıya dokunan her aksiyonu 'iki kez çalışırsa ne olur?' sorusuyla geçiriyorum — cevap 'kötü' ise idempotency-key şart.
- ▸Anahtarı iş kimliğinden türetiyorum, asla rastgele üretmiyorum.
- ▸Geri alınamaz aksiyonları (tahsilat, email gönderimi) reasoning'in en sonuna, tek ve net bir adıma topluyorum.
- ▸Her aksiyonu 'gönderildi' olarak işaretleyip bir daha tetiklenmemesini sağlayan bir dedup katmanı tutuyorum.
Bunu yapmak yeni bir model çıkmasını beklemekten çok daha az heyecan verici. Ama üretim güvenilirliğime, son birkaç model yükseltmesinin toplamından daha fazla katkı yaptı. Akıllı model işi hızlandırır; safe-to-retry aksiyonlar işi bırakılabilir kılar.
“Yanlış bir cevabı düşünmemiş sayabilirsin. Gönderilmiş bir tahsilatı geri alamazsın. Fark, agent'ı üretime alıp almayacağının tamamı.”