Ana içeriğe geç

Agent Sürüleri Yalnızca Sorgu Bütçelerine Değil, Hız Bütçelerine de İhtiyaç Duyar

Uzun süre çalışan sürüler, tokenleri tüketmeden önce üçüncü taraf istek toleransını tüketir. Orkestrasyon, çıkış katmanında uygulanan hedef başına hız zarflarına göre planlama yapmalıdır.

A moody close-up of guitar controls on a wooden body, emphasizing music technology.

Olayın gerçekte tükettiği şey

Uzun süre çalışan bir agent sürüsü, açık web'i bir belge deposu olarak deneyimlemez. Onu, çok sayıda satırı olan ve bu satırların çoğu başkasına ait endpoint'lerin arkasında bulunan bir arama tablosu olarak deneyimler. Sürüden, haftalar veya aylar boyunca bilinmeyen gerçekleri çözmesi istendiğinde, tükettiği baskın kaynak inference değildir. Üçüncü taraf altyapısına yönelik istek hacmidir.

Mühendislik sonucu şudur: tek bir toplu bütçe, gerçekte önem taşıyan kısıtı ifade edemez. "Bu host dakikada N isteğe tolerans gösterir, fazlasına göstermez" hedef başına bir ifadedir. Küresel bir token tavanı veya küresel bir harcama tavanı, sürünün kendi tüketimine dair bir ifadedir ve başkasının rate limiter'ında yaşayan bir limiti temsil etme kapasitesi yapısal olarak yoktur.

Küresel bütçeler neden bir kontrol olarak başarısız olur

Token üst sınırları ve maliyet tavanları gecikmeli göstergelerdir. Sürünün hâlihazırda gerçekleştirdiği işten hesaplanırlar. Küresel bir bütçe devreye girdiğinde, dış istekler çoktan gönderilmiş, hedef bunları çoktan soğurmuş ve bunun sonucunda doğan zarar — diğer istemciler için bozulan hizmet, savunma amaçlı engelleme, bir kötüye kullanım bildirimi — çoktan gerçekleşmiş olur. Bütçe, önlemesi gereken olaydan sonra tetiklenir.

Bu bir ayar sorunu değildir. Bir kategori hatasıdır. Küresel bir bütçe "ne kadar tüketebiliriz?" sorusunu yanıtlar. Hedef başına bir hız limiti "buraya şu anda ne kadar gönderebiliriz?" sorusunu yanıtlar. Üçüncü bir tarafın aşılmasından zarar görebileceği sınırlı bir yanıtı olan tek soru ikincisidir.

Arıza, fan-out ile daha da büyür. Bir sürünün, her biri makul herhangi bir operatörün kibar sayacağı bir hızda istek gönderen çok sayıda agent çalıştırdığını varsayalım. Agent başına hız mütevazıdır. Tek bir hedefe yönelik toplu hız, agent başına hızın o hedef üzerinde çalışan agent sayısıyla çarpımıdır ve scheduler'ın bu çarpımı küçük tutmak için doğuştan gelen bir nedeni yoktur. Agent'lar tipik olarak ilerleme kaydetmek üzere optimize edilir; göremedikleri paylaşılan bir dış kaynağı korumak üzere değil. Hedefe dair paylaşılan bir görüş olmadan, her agent doğru davranır ve sistem bir bütün olarak kötü davranır.

White / light blue / purple / dark blue sail; without harness or cover bag; 18ft. 5 1/2in. leading edge long; aluminum and dacron; 1974. In

İkinci bir çoğaltıcı, yeniden deneme davranışıdır. Bir hedef istekleri reddetmeye başladığında, reddi geçici bir hata olarak ele alan agent'lar yeniden dener; çoğu zaman her agent'a yerel bir backoff ile. Çok sayıda agent arasında yerel backoff, toplu baskıyı azaltmaz; onu hedefin atması daha zor, daha yumuşak ve daha kalıcı bir yüke dönüştürür.

Hedef başına hız bütçesi tasarlamak

İşleyen kontrol, sürünün tamamına değil, her dış kaynak tanımlayıcısına — scheme, host ve ilgili olduğunda bir path veya sorgu sınıfı — bağlı bir hız zarfıdır.

Prompt'larda değil, çıkış katmanında uygulayın. Bir system prompt'taki talimatlar tavsiye niteliğindedir. Yörüngesinin ortasında olan, bir teslim tarihi baskısı altında bulunan ya da talimatla uyumsuz kalan bir agent isteği yine de gönderir. Uygulama, çıkış katmanına aittir: her giden isteğin geçtiği, hedef başına bir token bucket tutan ve zarfı aşacak istekleri reddeden veya kuyruğa alan tek bir darboğaz. Prompt'lar niyeti tanımlayabilir; kararı çıkış katmanı verir.

Somut bir mekanizma: normalleştirilmiş hedef tanımlayıcısıyla anahtarlanan, hedefin tolere edilen hızında yeniden doldurulan ve burst izni sürünün iştahına göre değil hedefin gözlemlenen toleransına göre boyutlandırılan bir token bucket tutun. Her giden HTTP çağrısı, süreçten çıkmadan önce bir token alır. Token yoksa, çağrı sessizce başarısız olmaz ve dönmez; çağırana yapılandırılmış bir erteleme döndürür.

Scheduler'a kalan bütçe görünürlüğü verin. Bir erteleme ancak orchestrator ona göre hareket edebiliyorsa işe yarar. Scheduler, hedef başına kalan token'ları sorgulayabilmeli ve bunu işi yeniden sıralamak için kullanabilmelidir: kısıtlanmamış hedeflere dokunan yörünge adımlarını şimdi çalıştırın, tükenmiş bir hedefe yönelik adımları sonraya itin. Bu, hız sınırlamayı bir duraklamadan bir planlama girdisine dönüştürür. Bu görünürlük olmadan, tükenmiş bir zarf bozuk bir hedefle aynı görünür ve agent'lar kalan bütçelerini onu yoklayarak yakarlar.

Backoff'u birinci sınıf bir planlama durumu olarak ele alın. Çoğu sistem backoff'u bir hata yolu olarak modeller: bir şeyler ters gitti, bekle, yeniden dene. Bu çerçeveleme paylaşılan bir dış kaynak için yanlıştır. Backoff'taki bir hedef başarısız olmuyor; zarfı şu anda boş olan bir hedeftir ve doğru yanıt, zarf yeniden dolana kadar ona yönelik tüm işi önceliksizleştirmektir. Backoff'u scheduler'da — queued, running ve complete ile birlikte — bir durum olarak modellemek, orchestrator'ın ona yönelik yeniden denemeleri biriktirmek yerine etrafından dolaşmasını sağlar.

Dürüst ödünleşim, verimdir. Hedef başına bir zarf, bir hedef anlık olarak tükenmişken ama sürünün yapılabilecek işi varken kapasiteyi kullanılmadan bırakacaktır. Küresel bir bütçe o kapasiteyi harcardı; zarf bunu bilinçli olarak yapmaz. Bu tasarımı benimseyen ekipler, başkasının toleransı içinde kalmak için kendi agent'larını eksik kullanmayı seçiyor ve bu seçimin uzun ufuklu görevlerde gerçek bir duvar saati maliyeti vardır. Ödünleşimi ortadan kaldıran bir yapılandırma yoktur;

Robotic hand with articulated fingers reaching towards the sky on a blue background.

İkinci bir ödünleşim, koordinasyon yüküdür. Hedef başına bucket'lar tüm agent'lar ve süreçler arasında paylaşılmalıdır; bu da kendi tutarlılık ve gecikme özelliklerine sahip paylaşılan bir depo anlamına gelir. Agent başına yerel bir bucket daha ucuzdur ve yanlıştır; fan-out sorununu limiter'ın kendi düzeyinde yeniden ortaya çıkarır.

Denetlenebilir kılan enstrümantasyon

Bir hız bütçesi, ancak tüketimi olaydan sonra gözlemlenebiliyorsa bir kontroldür.

Pencere başına hedef başına istek sayılarını loglayın ve bunları her isteği üreten yörünge adımıyla birleştirin. Logu faydalı kılan bu birleştirmedir. Bir host'a yönelik istek sayısı size baskının oluştuğunu söyler; yörünge adımı ise hangi agent'ın, hangi hedefin ve hangi akıl yürütme adımının bunu ürettiğini söyler — davranışı yalnızca gözlemlemek yerine değiştirmek için ihtiyacınız olan da budur.

Toplam harcamada değil, zarf tükenmesinde alarm verin. Bir toplam harcama alarmı, sürü pahalı olduğunda tetiklenir; bu tamamen meşru olabilir. Bir tükenme alarmı, belirli bir hedef tolere edilen hızında veya ona yakın olduğunda tetiklenir; dış zararın öncesindeki koşul budur. İkinci alarm eyleme geçirilebilirdir; birincisi bir faturalama sinyalidir.

Ertelemeleri birinci sınıf bir metrik olarak izleyin. Bir hedefe yönelik artan erteleme oranı, sürünün o hedefe olan talebinin hedefin tolere edeceğini aştığının erken bir göstergesidir — hedefin kendisi redlerle yanıt vermesinden önce ve herhangi bir küresel bütçenin devreye girmesinden çok önce görünür. Ertelemeler ayrıca planlama kalitesini de ortaya koyar: bir hedefe yoğun erteleme yaparken diğer hedeflerin boş durduğu bir sürü iyi planlama yapmıyor demektir ve metrik bunu görünür kılar.

Son olarak, zarfın kendisini trafiğin yanında kaydedin. Bir hedefin toleransı revize edildiğinde — operatörle iletişime geçildiği için ya da gözlemlenen davranış değiştiği için — geçmiş istek sayıları ancak o sırada yürürlükte olan zarfa göre yorumlanabilir. Bu olmadan, olay sonrası bir inceleme, bütçesine saygı gösteren bir sürüyü hiçbir zaman doğru olmayan bir bütçe altında çalışan bir sürüden ayırt edemez.

Daha geniş nokta şudur: uzun ufuklarda çalışan agent sürüleri öncelikli olarak kendi hesaplamalarının tüketicileri değildir. Başkalarının hizmetlerinin tüketicileridir ve kıt kaynak, o hizmetlerin istekleri kabul etme hızıdır. Küresel tavanlara göre planlama yapan orkestrasyon yanlış niceliği optimize ediyor demektir. Çıkış katmanında uygulanan ve scheduler'a görünür olan hedef başına hız bütçelerine göre planlama yapmak, gerçek kısıtla örtüşen kontroldür.

İlgili okumalar

Bunun yanıtladığı sorular

Why is a global token or cost budget insufficient for a long-running agent swarm?

A global budget measures the swarm's own consumption and fires after requests have already been issued, so it cannot prevent harm to a third-party target. It also cannot express a per-target constraint such as a tolerated requests-per-minute rate, which is the limit that actually governs whether an external endpoint is harmed.

Where should a per-target rate budget be enforced?

At the egress layer, as a single chokepoint every outbound request passes through, using a token bucket keyed by normalised target identifier. Instructions in prompts are advisory and are not reliable under mid-trajectory pressure; the egress layer is the only place enforcement is deterministic.

How should an orchestrator respond when a target's rate envelope is exhausted?

It should treat exhaustion as a scheduling state rather than an error. The scheduler queries remaining tokens per target, reorders work toward unconstrained targets, and deprioritises all work against the exhausted target until the envelope refills, rather than accumulating retries against it.

What should be instrumented to make rate budgets auditable?

Log request counts per target per window, joined to the trajectory step that produced each request, and track deferrals as a first-class metric. Alert on envelope exhaustion rather than on total spend, and record the envelope in force alongside the traffic so historical counts remain interpretable.