Как платформа управления AI-агентами будет справляться с нагрузкой: архитектура без магии

Когда говорят про AI-агентов, обычно обсуждают качество модели, промпты, рассуждения, hallucinations, стоимость токенов и скорость ответа. Но если убрать маркетинговый шум, быстро выясняется более приземлённая проблема: как вообще такая система будет работать под нагрузкой?

Один пользователь попросил агента составить отчёт. Второй запустил проверку данных в CRM. Третий подключил агента к базе, почте и внутреннему API. Четвёртый дал агенту задачу, которая порождает ещё десять внутренних действий. И вот уже перед нами не “чат с искусственным интеллектом”, а полноценная распределённая платформа, где нужно контролировать запросы, права доступа, очереди, лимиты, ошибки, повторные попытки, логи, безопасность и стоимость выполнения.

В этой статье я разберу, как может быть устроена платформа управления AI-агентами, подобная нашей: не как один большой чат-бот, а как отдельный слой между пользователем, моделью, API, бизнес-системами и инфраструктурой. Главный вопрос статьи: за счёт чего такая платформа может выдерживать нагрузку и не превращаться в хаос при росте числа пользователей, агентов и выполняемых действий.

Почему нагрузка в AI-платформе отличается от обычного веб-сервиса

В классическом веб-сервисе пользователь делает запрос, backend обращается к базе данных, получает результат и отдаёт ответ. Да, внутри могут быть кэш, очереди, микросервисы, балансировщики и фоновые задачи, но общая логика понятна: запрос пришёл, обработался, ответ ушёл.

С AI-агентами всё сложнее. Один пользовательский запрос может превратиться в цепочку действий:

Пользователь просит: “Проверь клиентов, у которых просрочены платежи, подготовь письмо и предложи следующий шаг”.

На уровне платформы это уже не один запрос. Агенту нужно понять задачу, запросить данные из CRM, проверить права доступа, возможно обратиться к базе, классифицировать клиентов, сформировать текст, отправить действие на подтверждение, записать результат в лог, обновить статус задачи и, возможно, поставить follow-up в календарь. То есть один внешний запрос превращается в несколько внутренних операций. А если таких пользователей сотни или тысячи, нагрузка растёт не линейно. Появляется эффект размножения действий: один запрос пользователя может породить пять, десять или двадцать внутренних событий.

Именно поэтому AI-платформу нельзя проектировать как обычный “backend + LLM API”. Нужна архитектура, которая заранее учитывает асинхронность, контроль действий, лимиты, очереди и отказоустойчивость.

Главная идея: агент не должен напрямую ходить куда хочет

Первый архитектурный принцип нашей платформы простой: AI-агент не должен напрямую получать неограниченный доступ к API, базам данных и внутренним сервисам.

Если агент может сам решить, куда сходить, какие данные запросить и что изменить, то при росте нагрузки проблема становится не только технической, но и организационной. Система начинает выполнять много действий, но не всегда понятно, кто их инициировал, почему они были разрешены, какой лимит был применён и можно ли это воспроизвести.

Поэтому между агентом и внешними системами должен быть отдельный слой исполнения. Его можно условно назвать runtime-слоем или execution layer.

Агент не “ходит в CRM” напрямую. Он формирует намерение: например, “получить список клиентов с просроченным платежом”. Дальше это намерение проходит через несколько проверок:

• кто запросил действие;

• какой агент выполняет задачу;

• какие у него права;

• какой API он хочет вызвать;

• какие данные будут затронуты;

• не превышен ли лимит;

• нужно ли подтверждение человека;

• можно ли выполнить действие сейчас или его нужно поставить в очередь.

Только после этого платформа разрешает или запрещает действие. Это важно не только для безопасности, но и для управления нагрузкой. Когда все действия проходят через единый контролируемый слой, их можно ограничивать, ставить в очередь, приоритизировать, логировать и повторять при сбоях.

Базовая схема платформы

Упрощённо архитектура может выглядеть так:

Пользователь
    |
API Gateway
    |
Task Orchestrator
    |
Policy Engine
    |
Agent Runtime
    |
Queue / Event Bus
    |
Workers
    |
External APIs / Databases / CRM / Mail / Internal Services

Каждый слой сможет решать свою задачу.

• API Gateway принимает внешние запросы, проверяет авторизацию, ограничивает частоту обращений и маршрутизирует запросы дальше.

• Task Orchestrator превращает пользовательский запрос в задачу или цепочку задач. Он отвечает за состояние выполнения: что уже сделано, что ожидает подтверждения, что упало, что нужно повторить.

• Policy Engine проверяет правила. Это мозг безопасности и контроля. Он решает, может ли агент выполнить конкретное действие.

• Agent Runtime отвечает за выполнение логики агента: взаимодействие с моделью, инструментами, контекстом и промежуточными шагами.

• Queue или Event Bus принимает тяжёлые и фоновые задачи, чтобы не держать пользователя в ожидании там, где это не нужно.

• Workers выполняют реальные действия: обращаются к API, обрабатывают данные, строят отчёты, вызывают внешние сервисы.

Такой подход позволяет не держать всю нагрузку в одном монолитном процессе. Платформа может масштабировать отдельно API, отдельно воркеры, отдельно слой работы с моделями, отдельно хранилища и отдельно компоненты аудита.

Почему очередь обязательна?

В AI-платформе очередь — это не “дополнительная оптимизация”, а практически обязательный элемент.

Причина простая: задачи агентов часто непредсказуемы по длительности. Один запрос может выполниться за две секунды, другой — за минуту, третий — потребовать обращения к нескольким внешним API, которые сами могут тормозить или временно быть недоступны.

Если выполнять всё синхронно, backend быстро упрётся в таймауты, забитые соединения и нестабильное поведение. Пользователь нажал кнопку, запрос завис, сервер держит соединение, воркеры заняты, новые задачи ждут, система начинает деградировать. Очередь решает эту проблему. Быстрый API принимает задачу, проверяет базовые условия и кладёт её в очередь. Пользователь получает статус: задача принята. А дальше “воркеры” уже забирают задачи по мере доступности ресурсов.

Это даёт несколько преимуществ.

Во-первых, можно регулировать нагрузку. Если пользователей стало больше, очередь начнёт расти, но система не обязана падать сразу.

Во-вторых, можно вводить приоритеты. Например, интерактивные задачи пользователя выполняются быстрее, а тяжёлые аналитические отчёты уходят в фоновую обработку.

В-третьих, можно делать повторные попытки. Если внешний API временно недоступен, задачу можно повторить через 30 секунд, потом через минуту, потом через пять минут.

В-четвёртых, появляется прозрачность. У каждой задачи есть статус: создана, поставлена в очередь, выполняется, ждёт подтверждения, завершена, завершена с ошибкой.

Для платформы управления AI-агентами это критично. Агент не должен просто “молчать” или “зависать”. Платформа должна понимать, где именно находится задача и почему она ещё не завершена.

Горизонтальное масштабирование: что именно масштабируется

Когда говорят “платформа выдержит нагрузку”, часто подразумевают что-то абстрактное. На практике нужно понимать, какие именно части системы масштабируются.

В нашей архитектуре отдельно масштабируются:

• API-серверы;

• воркеры выполнения задач;

• воркеры для обращения к LLM;

• воркеры интеграций с внешними API;

• хранилище состояния задач;

• сервис логирования и аудита;

• сервис политик и прав доступа;

• кэш;

• очередь сообщений.

Например, если выросло количество пользователей, которые просто создают задачи, можно увеличить число API-инстансов. Если выросло количество тяжёлых фоновых операций, масштабируются workers. Если узким местом стала работа с внешними моделями, можно выделить отдельный пул LLM-workers с собственными лимитами. Если много однотипных запросов к правилам доступа, можно добавить кэширование policy-решений там, где это безопасно.

Главная ошибка — масштабировать всё целиком. Если платформа собрана как один большой монолит, то при росте нагрузки приходится поднимать ещё один такой же монолит, даже если узкое место находится только в одном компоненте. Это дорого, неудобно и плохо диагностируется. Правильнее разделить систему так, чтобы каждый слой можно было масштабировать независимо.

Rate limiting: защита от перегрузки и случайного самоуничтожения

AI-агенты опасны не только злонамеренными запросами, но и обычными ошибками.

Например, пользователь может случайно запустить задачу, которая создаёт слишком много внутренних действий. Или агент может неверно интерпретировать цель и начать делать повторяющиеся запросы. Или интеграция с внешним API начнёт возвращать ошибки, а система будет бездумно повторять попытки.

Поэтому нужны лимиты.

Лимиты могут быть разными:

• на пользователя;

• на организацию;

• на агента;

• на тип действия;

• на внешний API;

• на количество задач в очереди;

• на число параллельных выполнений;

• на стоимость LLM-запросов;

• на количество токенов;

• на глубину цепочки действий.

Например, агент может иметь право читать данные из CRM, но не чаще 100 запросов в минуту. Или пользователь может запускать не больше трёх тяжёлых аналитических задач одновременно. Или один агент не может породить цепочку глубже 10 шагов без подтверждения человека.

Это не бюрократия, а механизм выживания платформы. Без лимитов AI-система может сама создать себе нагрузку, которую потом не сможет обработать.

Backpressure: когда система честно говорит “медленнее”

Одна из важных частей устойчивой архитектуры — backpressure. Это механизм, при котором система не пытается принять бесконечное количество задач, если уже видно, что обработка не успевает.

В обычном плохом сценарии backend принимает всё подряд, очередь растёт, база начинает тормозить, воркеры захлёбываются, пользователи повторно нажимают кнопки, нагрузка становится ещё выше, и в итоге система падает.

В хорошем сценарии платформа заранее понимает, что она перегружена. Тогда она может:

• замедлить приём новых задач;

• понизить приоритет фоновых операций;

• временно отключить тяжёлые действия;

• вернуть пользователю понятный статус;

• поставить задачу в очередь с прогнозом ожидания;

• попросить повторить запрос позже;

• переключиться на более дешёвый или быстрый режим обработки.

Для AI-платформы это особенно важно, потому что часть нагрузки зависит от внешних сервисов: LLM API, CRM, почтовые системы, базы заказчика, внутренние корпоративные API. Даже если наша инфраструктура работает нормально, внешний сервис может начать отвечать медленно. Платформа должна уметь не падать вместе с ним.

Кэширование: где оно помогает, а где опасно

Кэширование в AI-платформе нужно использовать осторожно. Не всё можно кэшировать.

Можно кэшировать:

• справочники;

• публичные или неизменяемые данные;

• часто используемые настройки;

• метаданные интеграций;

• некоторые policy-решения;

• результаты дорогих вычислений;

• шаблоны промптов;

• структуру доступных инструментов.

Но опасно кэшировать данные, которые зависят от прав доступа, свежести информации или персонального контекста. Например, если агент запрашивает финансовые данные клиента, нельзя просто взять старый результат из кэша без проверки актуальности и прав. Поэтому кэширование должно быть не “везде для ускорения”, а точечным. В хорошей архитектуре у каждого кэша есть срок жизни, область применения и понимание, что произойдёт при устаревании данных.

Для платформы управления AI-агентами особенно важно кэшировать не сами опасные бизнес-данные, а технические вещи: схемы инструментов, разрешённые действия, настройки агентов, шаблоны, результаты безопасных проверок. Это снижает нагрузку, но не создаёт неконтролируемых рисков.

Разделение быстрых и долгих задач

Не все задачи должны выполняться одинаково.

Например, пользователь спрашивает: “Какие действия может выполнить этот агент?” Это быстрый запрос. Его можно обработать почти сразу.

А если пользователь просит: “Проанализируй 50 тысяч записей и подготовь отчёт”, это уже тяжёлая задача. Её нельзя обрабатывать в том же потоке, где выполняются быстрые интерактивные действия.

Поэтому в платформе задачи нужно делить на классы:

• быстрые интерактивные;

• обычные фоновые;

• тяжёлые аналитические;

• критичные действия, требующие подтверждения;

• периодические задачи;

• интеграционные задачи с внешними API.

У каждого класса должны быть свои лимиты, очереди, таймауты и правила повторов. Это позволяет не допустить ситуации, когда один пользователь запустил тяжёлый отчёт, а у всех остальных перестали открываться обычные запросы.

В зрелой архитектуре тяжёлые задачи не блокируют быстрые. Это один из главных признаков платформы, которая действительно готова к нагрузке.

Состояние задачи: почему нельзя хранить всё только в памяти

AI-агент часто выполняет задачу в несколько этапов. Он может начать работу, запросить данные, получить промежуточный результат, попросить подтверждение человека, продолжить выполнение, вызвать внешний API и завершить процесс.

Если всё состояние хранить только в памяти процесса, то при перезапуске сервера задача потеряется. Это недопустимо. Поэтому состояние задач должно храниться во внешнем хранилище: например, в базе данных. Там фиксируется:

• кто создал задачу;

• какой агент её выполняет;

• какой текущий статус;

• какие шаги уже выполнены;

• какие действия были разрешены или запрещены;

• какие данные были переданы инструментам;

• какие ошибки возникли;

• какие повторные попытки уже были сделаны;

• какой итоговый результат получен.

Это нужно не только для отказоустойчивости, но и для аудита. В случае спорной ситуации компания должна понимать, почему агент совершил действие, кто его запустил, какое правило его разрешило и какой результат был получен.

Идемпотентность: защита от повторного выполнения

В распределённых системах одна и та же задача иногда может выполниться повторно. Например, воркер отправил запрос во внешний API, но не успел записать результат из-за сбоя. Система видит, что задача не завершена, и запускает её снова.

Если не учитывать идемпотентность, можно получить дубли: два письма клиенту, два списания, два обновления записи, два созданных тикета.

Поэтому каждое важное действие должно иметь idempotency key — уникальный ключ операции. Перед выполнением действия платформа проверяет: не выполнялась ли уже такая операция раньше?

Для AI-агентов это особенно важно. Агент может генерировать похожие действия, и платформа должна отличать новое действие от повторного. Это ещё один аргумент в пользу того, что агент не должен напрямую управлять внешними системами. Все действия должны проходить через контролируемый слой исполнения.

Human-in-the-loop: подтверждение человека как часть нагрузки

В корпоративных AI-системах часть действий нельзя выполнять автоматически. Например, отправка письма клиенту, изменение финансовых данных, удаление записи, массовая рассылка, изменение прав доступа — всё это может требовать подтверждения человека.

На первый взгляд кажется, что подтверждение человека — это только вопрос безопасности. Но на самом деле это ещё и вопрос нагрузки.

Если агент дошёл до опасного действия, задача не должна занимать воркер бесконечно. Она должна перейти в состояние “ожидает подтверждения”. Воркер освобождается, задача сохраняется, пользователь или ответственный сотрудник получает запрос на подтверждение.

После подтверждения задача возвращается в очередь и продолжает выполнение.

Такой подход позволяет не держать ресурсы занятыми, пока человек думает. В масштабной системе это критично: ожидание человека может длиться минуты, часы или дни, и всё это время задача не должна висеть в оперативной памяти.

Observability: без метрик платформа слепая

Нельзя управлять нагрузкой, если её не видно.

Платформа должна собирать метрики на разных уровнях:

• количество входящих запросов;

• количество созданных задач;

• размер очередей;

• время ожидания в очереди;

• время выполнения задач;

• число ошибок;

• число повторных попыток;

• время ответа внешних API;

• число запрещённых policy-действий;

• стоимость LLM-вызовов;

• количество токенов;

• нагрузка на воркеры;

• нагрузка на базу данных;

• процент задач, завершившихся успешно.

Отдельно важны логи и трассировка. Когда пользователь говорит “агент сделал не то”, нужно восстановить цепочку событий. Не просто итоговый ответ модели, а весь путь: какой был запрос, какой агент его обрабатывал, какие инструменты были вызваны, какие правила сработали, что было разрешено, что было заблокировано, где возникла ошибка. Без этого AI-платформа превращается в чёрный ящик. А чёрный ящик нельзя безопасно масштабировать.

Политики выполнения: нагрузка должна управляться правилами

Один из ключевых компонентов нашей платформы – слой правил. Он нужен не только для безопасности, но и для управления ресурсами.

Например, правило может звучать так:

• агент может читать данные клиентов только в рабочее время;

• массовые операции выполняются только после подтверждения;

• задачи аналитики запускаются не более двух одновременно на организацию;

• при высокой нагрузке тяжёлые задачи переводятся в низкий приоритет;

• агент не может вызвать один и тот же внешний API больше N раз за короткий промежуток времени;

если стоимость выполнения превышает лимит, задача останавливается и требует подтверждения.

Такие правила должны быть описаны не в хаотичном коде внутри каждого агента, а в отдельном policy-слое. Тогда компания может менять ограничения без переписывания всей логики агентов.

Именно здесь появляется идея специализированного языка или декларативного слоя управления AI-агентами. Не обязательно давать бизнесу доступ к коду на Python или Go. Можно описывать правила более понятным способом: кто, когда, что и при каких условиях может делать.

Как платформа ведёт себя при резком росте нагрузки

Представим, что утром в систему одновременно зашли много пользователей. Кто-то запускает отчёты, кто-то просит агентов проверить сделки, кто-то подключает интеграции, кто-то тестирует новые сценарии.

Что должна делать платформа?

Первое: принять быстрые запросы и не дать им смешаться с тяжёлыми задачами.

Второе: поставить долгие операции в очереди.

Третье: применить лимиты на пользователя, организацию и тип задачи.

Четвёртое: масштабировать воркеры, если инфраструктура это позволяет.

Пятое: временно снижать приоритет задач, которые не требуют немедленного ответа.

Шестое: не выполнять опасные действия без подтверждения.

Седьмое: показывать пользователю понятный статус выполнения, а не просто крутящийся индикатор.

Восьмое: сохранять состояние задач так, чтобы при сбое можно было продолжить выполнение.

Именно эта комбинация и позволяет платформе справляться с нагрузкой. Не один “суперсервер”, не магическая модель, не бесконечный контекст, а нормальная инженерная архитектура.

Что будет узким местом

Честный ответ: узкие места будут всегда:)

В AI-платформе ими, к примеру, могут стать:

• лимиты внешней LLM-модели;

• скорость ответа внешних API;

• база данных состояния задач;

• очередь сообщений;

• сервис политик;

• стоимость токенов;

• объём логов;

• неудачно спроектированные агенты;

• слишком тяжёлые пользовательские сценарии.

Поэтому задача архитектуры не в том, чтобы “никогда не иметь узких мест”. Это невозможно. Задача в том, чтобы узкие места были видимыми, контролируемыми и изолированными.

Если тормозит внешний API, не должна падать вся платформа. Если перегружены аналитические задачи, быстрые пользовательские запросы должны продолжать работать. Если один агент ведёт себя неправильно, его можно ограничить или остановить, не отключая всех остальных.

Почему монолитный чат-бот не выдержит такую модель…

Можно сделать простого чат-бота, который принимает текст, отправляет его в LLM и возвращает ответ. Для “показушного” демо этого будет достаточно.

Но как только появляются реальные действия, интеграции и пользователи, монолитная схема начинает ломаться.

В монолите сложно отдельно масштабировать тяжёлые задачи. Сложно делать нормальные очереди. Сложно контролировать права на уровне каждого действия. Сложно вести аудит. Сложно восстанавливаться после сбоев. Сложно объяснить, почему агент что-то сделал. Сложно ограничить один сценарий, не затронув остальные.

Поэтому платформа управления AI-агентами должна быть не просто “чатом с кнопками”, а инфраструктурным слоем. По сути, это runtime для безопасного выполнения агентских действий.

Практический пример выполнения задачи

Допустим, пользователь пишет:

“Найди клиентов с просроченной оплатой, подготовь письмо и покажи мне перед отправкой”.

Платформа выполняет это не одним большим действием, а цепочкой шагов, аля: Сначала API Gateway принимает запрос и проверяет пользователя. Затем Task Orchestrator создаёт задачу и сохраняет её состояние. Policy Engine проверяет, имеет ли пользователь право запускать такого агента и работать с финансовыми данными. Agent Runtime формирует план: получить список клиентов, отфильтровать просрочки, подготовить текст письма, запросить подтверждение. Действие получения данных уходит в очередь, Worker обращается к CRM через контролируемую интеграцию. Результат сохраняется в состоянии задачи, агент сформирует письмо. Перед отправкой задача переходит в статус “ожидает подтверждения”, пользователь нажимает “подтвердить”. Только после этого отдельный worker отправляет письмо через почтовый API.

(В лог записывается вся цепочка: кто инициировал, какие данные были использованы, какое письмо сформировано, кто подтвердил, когда отправлено.)

Если на каком-то этапе внешний API недоступен, задача не исчезает. Она переходит в повторную попытку или в ошибку с понятным статусом. В Этом и есть разница между игрушечным агентом и платформой.

Как снижать стоимость нагрузки

В AI-системах нагрузка измеряется не только CPU, RAM и RPS. Есть ещё стоимость LLM-вызовов. Иногда именно она становится главным ограничением.

Чтобы не сжигать бюджет, платформа должна уметь:

• не отправлять в модель лишний контекст;

• использовать короткие промпты там, где это возможно;

• кэшировать безопасные промежуточные результаты;

• разделять простые и сложные задачи;

• использовать более дешёвые модели для простых операций;

• останавливать слишком дорогие цепочки;

• считать стоимость выполнения задачи заранее или хотя бы приблизительно;

• вводить лимиты на пользователя и организацию.

Например, не нужно каждый раз отправлять в LLM огромную историю, если задача требует только классификации одного события. Не нужно использовать самую дорогую модель для простого извлечения даты из текста. Не нужно позволять агенту бесконечно “размышлять”, если он уже превысил лимит шагов.

Управление стоимостью – это часть управления нагрузкой. Если платформа технически выдерживает запросы, но экономически каждый запрос слишком дорогой, такую архитектуру нельзя считать устойчивой.

Безопасность и нагрузка связаны сильнее, чем кажется

Часто безопасность рассматривают отдельно от производительности. Но в AI-платформах это связанные вещи.

Если нет ограничений на права, агент может запросить слишком много данных. Если нет лимитов на действия, агент может перегрузить внешний API и так далее в этой цепочке.

То есть безопасность помогает не только защищаться от атак, но и удерживать систему в управляемом состоянии. Хороший слой прав и политик снижает вероятность того, что агент случайно создаст лавину действий.

Отказоустойчивость: что происходит при сбое

Сбои неизбежны. Может упасть воркер. Может перезапуститься контейнер. Может временно пропасть соединение с внешним API. Может замедлиться база. Может истечь лимит модели.

Платформа должна быть готова к этому.

Для этого задачи не должны теряться при падении процесса. Очередь должна поддерживать повторную доставку. Действия должны быть идемпотентными. Состояние задачи должно храниться отдельно. Ошибки должны быть классифицированы: временная ошибка, постоянная ошибка, ошибка прав, ошибка данных, ошибка внешнего сервиса.

Если ошибка временная, можно повторить. Если ошибка постоянная, нужно остановить задачу и показать причину. Если ошибка связана с правами, нельзя пытаться обойти ограничение. Если внешний сервис недоступен, нужно не ронять платформу, а корректно перевести задачу в ожидание или ошибку.

Отказоустойчивость – это не отсутствие ошибок. Это способность системы переживать ошибки без потери контроля.

Как понять, что платформа действительно готова к нагрузке

Готовность к нагрузке нельзя доказывать словами. Её нужно проверять.

Минимальный набор проверок:

1) нагрузочное тестирование API;

2) тестирование роста очереди;

3) проверка поведения при падении воркера;

4) проверка повторных попыток;

5) проверка идемпотентности;

6) тестирование лимитов;

7) тестирование медленного внешнего API;

8) тестирование отказа LLM-провайдера;

9) проверка восстановления незавершённых задач;

10) проверка логов и трассировки;

11) проверка стоимости типовых сценариев.

Фух, вроде ничего не упустил….

P.S. ну а если и упустил, напишите об этом в комментариях)

Важно тестировать не только “идеальный путь”, когда всё работает. Нужно специально ломать систему и смотреть, как она себя ведёт. Если при падении одного компонента всё остальное превращается в хаос, архитектура ещё не готова.

Итог

Платформа управления AI-агентами должна справляться с нагрузкой не за счёт одной мощной модели и не за счёт бесконечного увеличения серверов. Нагрузка контролируется архитектурой.

Главная мысль простая: AI-агент в бизнес-среде — это не просто генератор текста. Это участник цифровых процессов. А значит, его действия должны выполняться в управляемой, наблюдаемой и масштабируемой среде. Именно такую роль должна играть платформа: быть не “ещё одним чат-ботом”, а инфраструктурным слоем, который позволяет агентам работать с реальными системами безопасно, прозрачно и устойчиво к нагрузке. Без этого AI-агенты останутся красивыми демо. С этим они могут стать нормальной частью корпоративной архитектуры.