Суть проблемы
Девять AI-агентов работают параллельно и обращаются к одному внешнему API. Квота у них общая — но каждый агент об этом «не знает»: он видит только свои запросы и свои ответы. Когда нагрузка достигает лимита и первый агент получает 429, остальные восемь продолжают давить на API в штатном режиме.
Именно в этот момент один сбой превращается в каскадный отказ. Чем больше агентов в системе — тем быстрее квота исчерпывается окончательно, и тем глубже уходит система в ступор.
Почему jitter только усугубляет
Классический ответ на rate limiting — exponential backoff с jitter: между повторными попытками добавляется случайная задержка, чтобы «развести» запросы по времени и не создавать пиковую нагрузку. Механизм разработан для изолированных клиентов и в этом сценарии работает хорошо.
При общей квоте картина иная: каждый из девяти агентов применяет jitter самостоятельно, не зная о действиях остальных. В итоге возникают девять независимых волн повторных запросов — немного сдвинутых по времени, но по-прежнему конкурирующих за одну квоту. Стандартные ретраи в таких условиях не стабилизируют систему, а добивают остаток квоты.
Архитектура Rate Governor
Решение строится на координации между агентами вместо их изоляции. Архитектура Rate Governor включает четыре ключевых элемента: общий пул токенов (shared token pool), который отражает актуальное состояние квоты сразу для всех агентов; систему приоритетов, определяющую очерёдность доступа; предиктивный Circuit Breaker; и механизм явной координации между агентами.
Предиктивный Circuit Breaker — принципиальное отличие от классического реактивного варианта. Реактивный срабатывает уже после сбоя; предиктивный отслеживает тренд расходования квоты и превентивно притормаживает низкоприоритетные запросы до того, как лимит исчерпан. Координация между агентами даёт всем участникам единое представление о состоянии квоты и позволяет избежать эффекта «грозди» — когда все агенты одновременно бьются об одну стену.
