Alt ajanlar basitçe yanlış

Polylane’in otomatik düzeltme ajanı başlangıçta, her biri tek bir görevden sorumlu birden fazla alt ajandan oluşan bir iş akışı olarak tasarlanmıştı:

• binlerce uyarı ve sinyali ayıklayan bir triyaj
• alt ajanları yöneten bir koordinatör
• sorun için olası tüm hipotezleri inceleyen, sayısı on beşe kadar çıkan alt ajanlar
• ve sonunda bir pull request gönderen bir kodlama ajanı

Doğrulanmış bir sorun, inceleme ve düzeltme için 18’e kadar ajan ve alt ajanın devreye girmesine yol açabiliyordu. Bugün aynı iş tek bir ajan tarafından yapılıyor.

Bu iş akışı, o zaman bildiklerimize dayanan mantıklı bir tasarımdı: küçük promptlar, küçük araç setleri, uzmanlar arasında sonuçları taşıyan bir orkestratör. Ancak işletmesi ve üzerine akıl yürütmesi son derece pahalı ve zordu.

Sorun nedir?

Polylane, bağlı her sağlayıcıdaki her bulut kaynağının (Lambda fonksiyonu, Cloudflare Worker, Vercel projesi vb.) günlüklerini, metriklerini ve izlerini tarar. Her kaynak için, verideki mevsimselliği yakalayabilmek amacıyla birden fazla zaman ufkunda taban çizgileri tutarız. Ardından bulut kaynağının mevcut durumunu değerlendirir ve geçmiş verilerle karşılaştırırız. Taban çizgisini bozan değerler sorun olarak kaydedilir.

Sorunlar, gözlemlenebilirlik ve hata izleme çözümlerinden aldığımız uyarılarla da oluşturulabilir.

Sorunları nasıl çözüyoruz?

Bir sorunu çözmek için şunları yapmamız gerekir:

1. Triyaj: Sorunu doğrulamak veya reddetmek için veri toplamak.
2. İnceleme: Birden fazla hipotezi değerlendirmek ve kök nedeni belirlemek.
3. Pull request açmak veya yükseltmek. Sorunu çözmek için bir pull request yazmak, düzeltme bir kod değişikliği değilse bir mühendise yükseltmek ya da bulguları öne çıkaran bir rapor yazıp durmak.

Çalıştırmaların büyük çoğunluğu, Polylane sorunun ya yanlış pozitif ya da zararsız olduğu sonucuna vardığında, bir pull request veya yükseltmeden önce sona erer.

Alt ajan mimarisi

İlk mimarimiz birden fazla alt ajana dayanıyordu.

Birden fazla alt ajan arasındaki işi koordine etmek için bir orkestratör ajan kullanıyorduk. Alt ajanlar, her hipotezi farklı başlangıç noktalarından (örneğin önce günlüklere bakarak ya da önce kod tabanından başlayarak) kanıtlamaya veya çürütmeye çalışarak hipotezleri incelemek üzere oluşturuluyordu.

Alt ajanların bulguları basit aritmetikle oylanıyor ve koordinatör ajana aktarılmadan önce başka bir ajan tarafından özetleniyordu.

Her hipotezin kararı, geçişleri boyunca güvene göre ağırlıklandırılmış bir oylamaydı.

const CONFIDENCE_RANK = { definitive: 4, strong: 3, moderate: 2, weak: 1, speculative: 0 };

function aggregatePassVerdicts(passes: PassResult[]): Verdict {
  const weights: Record<string, number> = {};
  const counts: Record<string, number> = {};
  for (const p of passes) {
    weights[p.verdict] = (weights[p.verdict] ?? 0) + CONFIDENCE_RANK[p.confidence];
    counts[p.verdict] = (counts[p.verdict] ?? 0) + 1;
  }
  const totalWeight = Object.values(weights).reduce((a, b) => a + b, 0);
  const [winner, winnerWeight] = Object.entries(weights).sort((a, b) => b[1] - a[1])[0];

  const countMajority = counts[winner] > passes.length / 2;
  const weightMajority = winnerWeight > totalWeight / 2;
  if (!countMajority && !weightMajority) {
    return { verdict: "inconclusive", confidence: "weak", summary: `No consensus across ${passes.length} passes.` };
  }

  const majority = passes.filter((p) => p.verdict === winner);
  const confidence = majority.reduce((min, p) => (CONFIDENCE_RANK[p.confidence] < CONFIDENCE_RANK[min] ? p.confidence : min), majority[0].confidence);
  const lead = majority.reduce((best, p) => (CONFIDENCE_RANK[p.confidence] > CONFIDENCE_RANK[best.confidence] ? p : best));
  return { verdict: winner, confidence, summary: lead.summary };
}

Tüm hipotezler incelendikten sonra bir kök neden belirlenmişse koordinatör, ya bir mühendise yükseltir ya da düzeltme için bir plan yazardı. Bu plan, düzeltmeyi uygulaması ve pull request’i göndermesi için bir kodlama alt ajanına devredilirdi.

Bu mimarideki temel sorun, alt ajanlar arasındaki bağlam kaybıydı. Her ajan, özetleme yoluyla bağlamının yalnızca bir kısmını yukarı veya aşağı aktarıyordu ve hem yukarı akıştaki hem de aşağı akıştaki ajanlar düzenli olarak aynı işi tekrarlamak zorunda kalıyordu.

Üstelik düzeltmeyi yazan ajanın elinde yalnızca plan vardı; orijinal sorun ya da inceleme sırasında toplanan kanıtlar hakkında bağlamı yoktu. Bu da genellikle kök neden yerine belirtilere odaklanan, yetersiz pull request’lere yol açıyordu.

Bu mimariyi seçmemizin başlıca nedeni, Mart 2026’da ilk tasarladığımızda öncü modellerin, düzeltmeyi yazmak da dahil olmak üzere bir incelemeyi uçtan uca yürütmede her zaman yeterli olmamasıydı; açıkçası harness’ımız da o kadar iyi değildi.

Bu temel üzerine inşa etmek giderek zorlaştı, çünkü:

• Hata ayıklama çok sayıda iz gerektiriyordu. Uçtan uca bir inceleme üzerine akıl yürütmek, bazen düzinelerce ize bakmayı gerektiriyordu
• Değerlendirme aşama bazındaydı. Her alt ajan tek başına değerlendirilip geçebiliyordu, ama nihai sonuç zayıftı çünkü hatalar devir noktalarında yaşanıyordu.

Bu mimari üzerinde aylarca yineleme yaptık; her ajanı ayrı ayrı geliştirdik, promptları ve devirleri ince ayarladık, ama sonuçlar hiçbir zaman harcanan emeğe denk gelmedi. Pahalıydı, hata ayıklaması zordu ve pull request’ler yeterince iyi değildi.

Tek ajan

3 Eylül’de alt ajan iş akışını, triyajdan pull request’e kadar her şeyi yapan tek bir ajanla değiştirdik. Aynı ajan kanıtları topluyor, tüm hipotezleri inceliyor ve pull request’i gönderiyor.

Triyaj ajanını, koordinatörü, hipotez ajanlarını ve otomatik düzeltme ajanını, aralarında sonuç taşıyan iş akışlarıyla ve pull request’in önünde duran kapılarla birlikte kaldırdık. Operasyonel faydalar hemen ortaya çıktı: değerlendirilecek tek bir iz ve alt ajanlar arasında özet yok.

Daha da önemlisi, pull request’lerin kalitesi arttı ve bir sorunu tespit etmekle onu düzelten pull request’i açmak arasındaki süre kısaldı. Geçiş civarındaki ay boyunca medyan 2.2 saatten 35 dakikaya, p90 ise dokuz günden iki saatin altına indi. Pipeline altında bir bulgu, her biri bir öncekini bekleyen bir iş akışları zincirinde tipik olarak saatlerce bekliyordu. Tek ajan altında ise pull request, sorun tespit edildikten sadece birkaç dakika sonra açılıyor.

Artık çok daha fazla pull request de açıyoruz. Alt ajanları kullanırken tespit edilen sorunların %0.6’sı bir pull request ile sonuçlanıyordu. Tek ajan altında bu oran %4.2 ve yükseliyor. Fark, hata modlarında yatıyor. Birden fazla alt ajanlı bir pipeline’ın her devri atlatması gerekir: triyajın bulguyu ilerletmesi, koordinatörün hipotezler üretmesi, fan-out’un bir karara varması vb. Her devir, olası bir hata modudur.

Pull request başına maliyet de düştü. Artık her çalıştırma daha güçlü modelle başlıyor, bu yüzden reddedilen bir bulgu pipeline altındakinden daha pahalıya mal oluyor. Ancak pull request başına ortalama maliyet, tek ajanın ilk dokuz gününde $111’den yaklaşık $18’e düştü. Bu düşüş yalnızca mimari değişikliğin sonucu değil, çünkü Polylane’in her yönü üzerinde aktif olarak yineleme yapıyoruz. Bunun bir kısmı, sürekli yinelenen bir sistemin olağan sürüklenmesidir.

Alt ajan inşa etme

• Devirler, kazandırdığından fazlasını kaybettirir. Ajanlar arasında geçen her özet, bir sonraki ajanın asla sahip olamayacağı bağlamdır. Kanıtları toplayan ajan, onlara göre hareket eden ajan olmalıdır.
• Ajanları değil, çalıştırmayı değerlendir. Ajan bazlı değerlendirmeler geçer ama sistem başarısız olur, çünkü hatalar ajanlar arasında yaşanır.
• Çalıştırma başına tek bir iz tut. Bir düzine ize yayılmış yanlış bir karar, açıklamak için bir öğleden sonra alır. Tek bir izde ise bir kaydırma yeter.