Kurumsal Çoklu Ajan Orkestrasyonu: Bağlam Sıkıştırma, AST Şablon Kalkanı ve 4xx/5xx Öz-Onarım Mimarisi

Üç dakikalık bir demo ortamında kusursuz çalışan tek katmanlı bir dil modeli sarmalayıcısı, canlı kurumsal veritabanına ve 10'dan fazla operasyonel araca bağlandığı ilk hafta içinde genellikle aynı üç arızadan biriyle durur: kontrolsüz büyüyen mesaj geçmişi nedeniyle bağlam çürümesi (context rot), geçici bir dış servis kesintisinde modelin aynı hatalı aracı defalarca çağırarak token bütçesini tüketmesi ya da bir destek biletinin içindeki zararlı metnin sistem talimatlarını ezmesi.

Kurumsal çoklu ajan orkestrasyonu nedir? Kurumsal çoklu ajan orkestrasyonu; planlama, araç yürütme, bellek özetleme ve güvenlik doğrulama sorumluluklarını tek bir monolitik istem yerine yetki alanı sınırlandırılmış uzman alt ajanlara dağıtan, deterministik şablon denetimi ve hata sınıfına duyarlı öz-onarım döngüleriyle çalışan üretim tipi yazılım mimarisidir.

Üretim ortamında Kling Digital Kurumsal Yapay Zeka Çözümleri ve çok kiracılı Özel Yazılım & SaaS Geliştirme projelerini tasarlarken en sık gördüğümüz darboğaz, model zekâsından ziyade orkestrasyon katmanındaki durum yönetimi eksikliğidir. Arama motorları ve yapay zeka yanıt motorları açısından sitenizin teknik hazırlığını AI ve GEO Arama Denetimi Aracı üzerinden ölçebileceğiniz gibi, kurum içi operasyon ajanlarınızı da aynı deterministik mühendislik disipliniyle kurgulamanız gerekir.

1. Katmanlı Bağlam Sıkıştırma ve AST Şablon Doğrulama Kalkanı

Uzun soluklu bir operasyon oturumunda her araç çıktısını (örneğin 30 günlük analitik satırlarını, finansal hareket dökümlerini ve iç bağlantı tarama raporlarını) ham JSON olarak sohbet geçmişine eklemek, yalnızca gecikmeyi (TTFB) artırmakla kalmaz; modelin ilk sistem kısıtlarına olan dikkat ağırlığını da zayıflatır. Üretim sınıfı ajan mimarilerinde ham araç çıktıları, görev adımı tamamlandığı anda epizodik özet kapsüllerine dönüştürülür ve yalnızca doğrulanmış anahtar metrikler bir sonraki tura taşınır.

İkinci kritik güvenlik katmanı, dinamik sistem istemlerinin yönetimidir. Bir yönetici panel üzerinden sistem istemini düzenlediğinde iki tehlike ortaya çıkar: şablonda kodun enjekte etmediği hayali bir {{gizliAnahtar}} değişkeninin yazılması veya dış girdileri sarmalayan güvenlik sınırının yanlışlıkla silinmesi. Kling Digital mühendislik mimarisinde her istem hem kayıt anında hem de çalışma zamanında (getResolvedSystemPrompt) dört aşamalı bir doğrulayıcıdan geçer:

1. Değişken Beyaz Listesi Denetimi: Şablondaki tüm {{...}} ifadeleri ayrıştırılır ve modülün resmi injectedVariables sözleşmesiyle karşılaştırılır; tanımsız değişken içeren kayıtlar reddedilir.
2. Güvenilmeyen Veri Sınırı () Zorunluluğu: Müşteri mesajı, destek bileti veya dış URL verisi işleyen modüllerde izolasyon kuralı silinirse kayıt engellenir.
3. Çalışma Zamanı Güvenli Geri Dönüş (Runtime Fallback): Kod şeması güncellendiğinde veritabanındaki eski bir özel istem geçerliliğini yitirirse, sistem ham yer tutucu metin sızdırmak yerine otomatik olarak fabrika doktrinine (defaultPrompt) döner.

2. Çoklu Araç Yürütme ve Hata Sınıfına Duyarlı (4xx vs 5xx) Öz-Onarım

Standart ajan örneklerinin büyük bölümü modelin döndürdüğü functionCalls dizisinin yalnızca ilk elemanını (calls[0]) çalıştırır veya herhangi bir hata alındığında hatayı olduğu gibi modele geri besleyerek 3–5 tur boyunca yeniden deneme yapar. Oysa bir yönetici tek bir komutta "Bulut altyapı giderini kaydet ve ana sayfanın dizin durumunu denetle" dediğinde model iki ayrı fonksiyon çağrısını aynı turda üretir.

Daha da önemlisi, her hata öz-onarıma uygun değildir:

• VALIDATION_4XX (Onarılabilir Şema/Argüman Hatası): Eksik URL, sıfır tutar veya eşleşmeyen görev başlığı gibi durumlarda hata mesajı (örneğin sistemdeki mevcut açık görevlerin listesiyle birlikte) modele geri verilir. Bu sırada aynı turda başarıyla tamamlanmış yazma işlemleri alreadyExecuted: true bayrağıyla işaretlenir; böylece model ikinci turda yalnızca hatalı aracı düzeltir ve finans defterine mükerrer kayıt yazmaz.
• UPSTREAM_5XX ve FORBIDDEN (Onarılamaz Altyapı/Yetki Hatası): Veritabanı bağlantı zaman aşımı, HTTP 503 kesintisi veya yetkisiz rol erişiminde modelin argüman değiştirerek sorunu çözmesi imkânsızdır. Orkestratör döngüyü anında keser ve token israfını sıfırlar.

export type ToolErrorCategory = "VALIDATION_4XX" | "UPSTREAM_5XX" | "FORBIDDEN";
export interface ToolCallOutcome {
  success: boolean;
  message: string;
  errorCategory?: ToolErrorCategory;
}
export async function executeFaultTolerantBatch(
  calls: ReadonlyArray<{ id: string; name: string; args: Record<string, unknown> }>,
  invokeTool: (name: string, args: Record<string, unknown>) => Promise<ToolCallOutcome>,
) {
  const succeededIds = new Set<string>();
  const repairFeedback: Array<{ id: string; name: string; payload: Record<string, unknown> }> = [];
  for (const call of calls) {
    const outcome = await invokeTool(call.name, call.args);
    if (outcome.success) {
      succeededIds.add(call.id);
      repairFeedback.push({
        id: call.id,
        name: call.name,
        payload: {
          output: outcome.message,
          alreadyExecuted: true,
          instruction: "STATE_MUTATED_DO_NOT_REPEAT",
        },
      });
      continue;
    }
    // Never burn LLM retry tokens when an upstream API, database, or permission boundary fails
    if (outcome.errorCategory === "UPSTREAM_5XX" || outcome.errorCategory === "FORBIDDEN") {
      return { status: "HALTED_NON_REPAIRABLE" as const, failedCall: call.name, outcome };
    }
    // Only VALIDATION_4XX schema/argument errors enter bounded LLM self-repair
    repairFeedback.push({
      id: call.id,
      name: call.name,
      payload: {
        error: outcome.message,
        errorCategory: "VALIDATION_4XX",
        instruction: "REPAIR_ARGUMENTS_WITHOUT_REPEATING_SUCCEEDED_CALLS",
      },
    });
  }
  return {
    status: succeededIds.size === calls.length ? ("COMPLETED" as const) : ("NEEDS_4XX_REPAIR" as const),
    repairFeedback,
  };
}

Tekil Sarmalayıcı ile Üretim Sınıfı Çoklu Ajan Mimarisi Karşılaştırması

3. Çift Zamanlı Bilgi Grafikleri ve 6 Dilli Çift Kanallı İzolasyon

Kurumsal ajanların yalnızca anlık veritabanı tablolarını okuması yeterli değildir; bir sunucu yapılandırmasının veya müşteri sözleşmesinin ne zaman geçerli olduğu (geçerlilik zamanı) ile sisteme ne zaman kaydedildiği (işlem zamanı) arasındaki farkı bilmesi gerekir. Çift zamanlı (bi-temporal) bilgi grafikleri, geçerliliği sona ermiş eski mimari kuralları silmek yerine zaman damgalı kenarlarla arşivler; böylece ajan geçmişe dönük denetim sorularında çelişkili yanıt üretmez.

Uluslararası ölçekte 6 dilde (tr, en, es, fr, ar, ru) hizmet veren platformlarda ise Çift Kanallı Dil Protokolü uygulanmalıdır:

• Kullanıcı Kanalı: Yönetici veya müşteri hangi dilde yazarsa (Arapça RTL dahil) nihai sentez ve açıklama o dilin doğal terminolojisiyle sunulur.
• Sistem ve Araç Kanalı: Arka plandaki fonksiyon argümanları, kategori enum değerleri (FINANCE_SUMMARY, SOFTWARE, SUBDOMAIN), denetim izi kodları ve semantik önbellek anahtarları tek bir kanonik şemada tutulur. Bu sayede İspanyolca ve Türkçe sorulan aynı operasyonel sorgu aynı önbellek katmanından ve aynı doğrulama kurallarından yararlanır.

Kurumunuzun mevcut ERP, CRM, analitik ve bulut operasyonlarını güvenilir çoklu ajan iş akışlarıyla birleştirmek için Proje Maliyet Hesaplayıcı üzerinden kapsam simülasyonu oluşturabilir veya doğrudan Kling Digital İletişim sayfasından mühendislik ekibimizle mimari değerlendirme oturumu planlayabilirsiniz.