Kimi Agent Swarm: что происходит, когда 100 параллельных sub-agent одновременно обращаются к вашему API gateway

У модели с единственным agent есть структурный потолок. Когда задача требует анализа 100 компаний, синтеза 40 исследовательских статей или параллельного запуска нескольких экспертных ролей, одиночный agent упирается в ограничения context window и начинает деградировать. Kimi Agent Swarm — ответ Moonshot AI на эту проблему: самоорганизующаяся система, которая разворачивает до 100 параллельных sub-agent на одну задачу, выполняет более 1 500 вызовов инструментов и выдаёт результат в 4,5 раза быстрее последовательного выполнения.

Для команд, работающих с Kimi API или проектирующих multi-agent архитектуры на любом provider, это не просто продуктовая функция. Это сигнал, который заставляет пересмотреть routing-политику, бюджеты rate limit и логику атрибуции затрат на уровне задачи.

Что произошло

Moonshot AI запустила Kimi Agent Swarm как ранний исследовательский preview, изначально доступный подписчикам высшего уровня. Система работает на базе Kimi K2.5 и вводит самоорганизующийся слой оркестрации: получив сложную задачу, система порождает иерархию sub-agent — «CEO»-agent нанимает специализированных исполнителей, распределяет объём работ и агрегирует результаты.

Ключевые цифры из официального анонса:

• До 100 sub-agent работают параллельно в рамках одной задачи
• Более 1 500 вызовов инструментов за одно выполнение задачи
• В 4,5 раза быстрее последовательного выполнения одним agent

Архитектура устраняет проблему деградации из-за сжатия context, характерную для одиночных agent на длинных задачах. Вместо того чтобы сворачивать историю в сужающееся context window, система распределяет работу между изолированными agent, каждый из которых получает свежий context-бюджет.

Почему это важно для AI engineering команд

Переход от одиночного agent к swarm-архитектуре разрушает несколько базовых допущений, на которых строится большинство API routing-решений.

Пики concurrency становятся первоклассной проблемой. Один пользовательский запрос теперь может породить 100 параллельных API-вызовов. Если ваш routing-слой или аккаунт у provider настроен под последовательные нагрузки, одна swarm-задача мгновенно исчерпает лимиты. Команды должны моделировать пиковую concurrency на уровне задачи, а не только на уровне пользователя.

Атрибуция затрат усложняется. Когда 100 sub-agent потребляют токены независимо, стоимость одной пользовательской задачи перестаёт быть единственной записью в billing-журнале. Без тегирования запросов по agent или агрегации затрат на уровне job вы теряете видимость: какие типы задач дорогие, а какие нет.

Изоляция rate limit по provider становится критичной. Если sub-agent используют один API key и попадают в один rate-limit bucket, одна swarm-задача способна «заморить голодом» остальные workload. Стандартная практика — отдельные API keys для разных классов нагрузки — из рекомендуемой превращается в обязательную.

Паттерн универсален. Agent Swarm — реализация Kimi, но архитектурный паттерн «оркестратор порождает параллельных worker через API» уже встречается в OpenAI Codex, Claude Managed Agents и кастомных LangGraph/CrewAI-деплоях. Независимо от provider, любая команда, строящая multi-agent системы, сталкивается с теми же routing и billing-вызовами.

Взгляд router/operator

Multi-agent архитектуры обнажают три routing-проблемы, которые редко возникают в одиночных agent-сценариях:

1. Routing при burst concurrency. Swarm-задача — это burst-событие. Ваш routing-слой должен за долю секунды обработать fan-out из 10–100 запросов, направить их к нужному provider и соблюсти его лимиты concurrency. Если вы маршрутизируете к provider с лимитом 10 RPM, swarm из 100 agent немедленно упадёт без очереди или логики fan-out на уровне provider.

2. Учёт затрат по задаче. Каждый вызов sub-agent должен нести общий идентификатор задачи, чтобы можно было агрегировать потребление токенов, latency и стоимость на уровне job. Без этого billing-дашборд покажет 1 500 отдельных запросов без возможности связать их с исходной пользовательской задачей. Routing gateway с поддержкой тегирования запросов или передачи кастомных метаданных делает эту задачу решаемой.

3. Fallback-стратегия при частичных сбоях. В swarm из 100 agent часть sub-agent неизбежно завершится с ошибкой — rate limit, timeout, ошибка provider. Оркестратору нужна fallback-стратегия: повторить попытку на другом provider, деградировать gracefully или прервать задачу. Это зона ответственности routing-слоя, а не только прикладного уровня. Если ваш gateway прозрачно обрабатывает retry, оркестратору не нужно реализовывать provider-специфичную fallback-логику самостоятельно.

Фреймворк принятия решений для команд, переходящих на swarm-архитектуру:

• Проверьте текущий запас rate limit у каждого provider. Swarm из 100 agent требует минимум 100 RPM устойчивой пропускной способности.
• Добавьте task/job ID в каждый заголовок запроса или поле метаданных. Это минимальная инструментация для атрибуции затрат.
• Выделите отдельные API keys (или routing-пространства имён) для swarm-нагрузок и интерактивных workload. Swarm-задачи не должны вытеснять запросы реального времени.
• Установите потолок стоимости на задачу. Без бюджетного ограничения один некорректно настроенный swarm способен израсходовать дневной бюджет токенов за несколько минут.

Что стоит отслеживать пользователям TheRouter

Команды, маршрутизирующие трафик Kimi API через TheRouter, могут использовать метаданные запросов для тегирования swarm-задач идентификатором задачи — это позволяет агрегировать затраты по задаче в billing-журнале. Если вы строите multi-agent систему на любом provider, тот же паттерн применим: передавайте стабильный идентификатор задачи через routing-слой, чтобы данные о стоимости и latency агрегировались на уровне задачи, а не отдельного запроса.

Более широкий сигнал: multi-agent архитектуры переходят из исследовательских демо в production-нагрузки. Routing и billing-инфраструктура, рассчитанная на одиночные последовательные API-вызовы, потребует пересмотра по мере того, как swarm-стиль выполнения становится стандартом для сложных задач.

Следите за тем, когда Kimi расширит доступ к Agent Swarm за пределы высшего тарифа и откроет ли Swarm-оркестрацию через Kimi API — именно тогда описанные выше последствия для concurrency и billing станут напрямую актуальны для всех команд, маршрутизирующих трафик на api.moonshot.cn.