Çok ajanlı bir sistem yayına almak, bir chatbot yayına almakla aynı şey değildir.

GOGOGO orchestrator’ının ilk sürümünü yayına aldığımızda onu daha akıllı bir chatbot gibi ele aldık. Tek bir model, uzun bir sistem prompt’u, birkaç tool çağrısı. Demolarda işliyordu. Üretimde çöküyordu. Üç yeniden yazımdan sonra önünüzdeki şey artık bir chatbot değil — bir runtime. İşte bu ayrım, bir özellik ile bir işletim katmanı arasındaki farkı yaratan şey.

v1’de ne kırıldı

İlk orchestrator, tool erişimi olan tek bir LLM idi. Ona ‘hangi uzmanı çağıracağına karar ver’ ve ‘doğru bağlamı devret’ diye yazıyorduk. Her demo geçiyordu. Her üretim çalıştırması yazı tura atmaktan farksızdı. Model, hangi uzmanı zaten çağırdığını unutuyor, tool çağrılarını tekrarlıyor ya da daha kötüsü — konuşma grafiğinin izini kaybettiği için yan etkili çağrıları yeniden çalıştırıyordu.

Çözüm daha büyük bir bağlam penceresi değildi. Çözüm, orchestrator’ın işinin üretimsel değil, yapısal olduğunu kabul etmekti.

Hand-off’ları tipli bir sözleşme olarak ele alın

v2’de orchestrator’ın kendi hand-off yüklerini yazmasına izin vermeyi bıraktık. Artık her hand-off tipli bir şemadır ve agent’ın sınırında doğrulanır. Uzmanlar doğal dil tüketmez; yapılandırılmış girdi tüketir ve yapılandırılmış çıktı üretir. Orchestrator’ın tek görevi sıradaki uzmanı seçmek ve tipli yükü yönlendirmektir.

// Hand-offs are values, not text.
type HandOff =
  | { to: "goddo.image.generate"; input: ImageRequest }
  | { to: "govista.schedule"; input: ScheduleRequest }
  | { to: "gopeople.classify"; input: ClassifyRequest }
  | { to: "gotrack.score"; input: ScoreRequest };

const next = orchestrator.decide(state);
assertHandOff(next); // throws on shape mismatch
await runtime.run(next);

Tekrar oynatılamıyorsa, olmamıştır

Güvenilirlikteki en büyük sıçrama, her çalıştırmayı tekrar oynatılabilir kılmaktan geldi. Her adım üç şeyi kalıcı kılar: aldığı girdi, verdiği karar ve ürettiği çıktı. Bununla birlikte başarısız bir çalıştırmanın hatasını ayıklamak artık his meselesi değil — çalışan trace ile bozuk olanın diff’ini almak meselesi.

‘Replay’ aslında ne demek

• Aynı agent’ı aynı girdiyle yeniden çalıştırın ve çıktının yapısal olarak eşdeğer olduğunu doğrulayın.
• Bir uzmanı yeni bir sürümle değiştirin ve trace’i tekrar oynatarak deploy öncesinde gerilemeleri yüzeye çıkarın.
• Bir tenant’ı, son 24 saatlik çalıştırmalarını yeni grafa karşı tekrar oynatarak son ‘bilinen-iyi’ orchestrator grafına geri alın.

Tool’lar runtime’dır, model değil

Eskiden tool’ları, modelin isteğe bağlı çıkabileceği ‘yan görevler’ olarak düşünüyorduk. Yanlış çerçeve. Tool’lar runtime’dır. Model karar verir; işi tool’lar yapar. Bunu kabullendiğimiz an orchestrator state konusunda akıllı olmaya çalışmayı bıraktı ve tool’lara doğrunun kaynağı olarak güvenmeye başladı.

Vardığımız üç kural

1. Tool’lar ya idempotenttir ya da etiketlidir. Orchestrator, idempotent olmayan bir tool’u açık bir politika olmadan asla yeniden denemez.
2. Tool’lar kendi yeniden denemelerinin sahibidir. Orchestrator devreder ve bekler — kararsız transport’lar üzerinde döngü kurmaz.
3. Tool’lar yapılandırılmış event’ler yayar. Başarılı veya başarısız her çağrı, bir log satırı değil, trace’te bir satırdır.

Bir dahaki sefere neyi farklı yapardık

Bugün yeniden başlasaydık, trace ile başlardık. Önce zaman çizelgesini, sonra agent’ları, en son orchestrator’ı kurardık. Sebebi şu: çok ajanlı bir sistem yayına alan her ekip eninde sonunda observability’yi yeniden inşa eder — ama o noktaya geldiklerinde beş farklı uzmana beş farklı format pişirmiş olurlar. Önce rayı döşeyin; agent’lar onu takip edecek.

“Bir orchestrator, daha akıllı bir chatbot değildir. Agent’larınızın içinde yaşadığı runtime’dır. Onu tekrar oynatamıyorsanız, sahibi siz değilsiniz.”