Мультиагентный фреймворк Squad, предназначенный для оркестрации команды ИИ-агентов (ревью кода, архитектура, инфраструктура, документация), показал, как стандартные механизмы повторных попыток ломают систему при масштабировании. Автор проекта запустил Squad на платформах AKS и Azure VMs, и через пару недель столкнулся с критической проблемой: 9 агентов стартовали одновременно, за 22 минуты открыли 10 пулл-реквестов, но уже на 8-й минуте GitHub начал возвращать 429 Too Many Requests. Все агенты одновременно ушли на повторную попытку, что вызвало волну отказов, и за 90 секунд исчерпали лимит в 5000 запросов в час, полностью потеряв доступ.
Анализ логов выявил три режима отказа. Первый — эффект «стада» (Thundering Herd): после 429 все агенты ждут одно и то же время из заголовка Retry-After и одновременно повторяют запрос, снова получая 429. В логах ralph-self-heal.log зафиксировано более 60 связанных отказов в одном инциденте. Второй — инверсия приоритетов: фоновый агент Ralph, опрашивающий GitHub каждые 5 минут, съедал квоту, необходимую критическому агенту Picard для архитектурных решений. У обоих был одинаковый приоритет ретраев, и система не могла сказать: «Picard идёт первым». Третий — каскадное усиление: один вторичный лимит GitHub заставил несколько агентов поставить работу в очередь; при снятии ограничения они одновременно сбросили очереди и снова упёрлись в лимит, превращая один 429 в 60-минутный простой.
| Режим отказа | Описание |
|---|---|
| Эффект «стада» (Thundering Herd) | После 429 все агенты ждут одинаковое время Retry-After и одновременно повторяют запрос, снова получая 429. В логах зафиксировано более 60 связанных отказов в одном инциденте. |
| Инверсия приоритетов (Priority Inversion) | Фоновый агент Ralph съедает квоту, необходимую критическому агенту Picard; у обоих одинаковый приоритет ретраев, и система не может расставить приоритеты. |
| Каскадное усиление (Cascade Amplification) | Один вторичный лимит GitHub заставляет несколько агентов ставить работу в очередь; при снятии лимита они одновременно сбрасывают очереди и снова упираются в ограничение, вызывая до 60 минут простоя. |
В ответ на эти проблемы автор спроектировал Rate Governor — координационный слой, с которым все агенты сверяются перед API-вызовами. В него вошли шесть паттернов, каждый из которых адресует конкретный режим отказа. Среди них — троттлинг по принципу светофора: после каждого вызова читаются заголовки x-ratelimit-remaining и x-ratelimit-reset, и если квоты осталось 15–40%, добавляются пропорциональные задержки, а ниже 15% фоновые агенты полностью приостанавливаются. Другие паттерны включают приоритетное выделение квоты для критических агентов, координацию ретраев через единый планировщик и динамические окна для сглаживания пиков.
Ограничение скорости запросов в мультиагентных системах — это проблема координации, а не повторных попыток. Существующие инструменты (Azure API Management, Resilience4j, LangGraph) рассматривают rate limiting как задачу каждого компонента в отдельности, но когда 9 агентов делят одну квоту, независимая логика ретраев активно ухудшает ситуацию. Разработанные паттерны могут быть применены к любым мультиагентным системам, использующим общие API-лимиты, и особенно актуальны для ИИ-ассистентов, которые автоматически генерируют запросы к внешним сервисам.
