В продакшен-агенте на базе ИИ модель — это наименее критичное решение, а выдержит ли агент наплыв реальных пользователей, определяет выстроенная вокруг нее архитектура. Большинству команд стоит начать с одного агента с инструментами и добавлять новых только там, где необходимо строгое разделение ролей.
Из чего состоит архитектура ИИ-агента для продакшена?
Архитектура ИИ-агента для продакшена состоит из паттерна оркестрации, управления контекстом, инструментов, защитных барьеров (guardrails), среды надежного исполнения (durable execution runtime) и наблюдаемости вокруг модели. Модель — это всего лишь заменяемый компонент. Большинство сбоев после демонстрации прототипа происходит именно на окружающих уровнях: бесконечные циклы, побочные эффекты инструментов при повторных попытках, разрастающийся с каждым шагом контекст и потеря состояния, когда долгая задача переживает вызвавший ее процесс.
Архитектура ИИ-агента — это структура, которая позволяет LLM планировать, вызывать инструменты, сохранять состояние и оставаться в заданных границах. Это руководство основано на опыте работы двух наших агентов: Omega, внутреннего мультиагентного ассистента по продажам в Slack, и Chatguru, нашего open-source RAG-агента для электронной коммерции. Netguru создает продакшен-агентов на базе ИИ, а также системы оркестрации, среды выполнения и средства наблюдаемости для корпоративных клиентов.
Команды, не имеющие внутренних ресурсов, могут привлечь для разработки выделенную команду AI Pod.
Какие уровни включает в себя эталонная архитектура?
Архитектура продакшен-агента на базе ИИ включает в себя четыре последовательных уровня, вертикальный слой наблюдаемости, проходящий через все уровни, и шлюз для участия человека (human-in-the-loop) на выходе из сервиса агента. Каждый уровень требует принятия отдельного решения, и эти уровни различаются тем, насколько просто изменить их впоследствии.
Описание схемы сверху вниз: наверху находится интерфейс, затем шлюз. Ниже расположен сервис агента, содержащий оркестратор, поиск данных (retrieval), вызов инструментов и guardrails. Данные и модель образуют нижний уровень. Слой наблюдаемости и оценки проходит вертикально через все уровни, а одна из стрелок ведет из сервиса агента в очередь на утверждение человеком.
Таблица читается сверху вниз и показывает, что использует Chatguru на каждом уровне:
Langfuse охватывает все четыре уровня. Провайдер LLM в Chatguru — самый легко заменяемый компонент, именно поэтому мы выбираем модель в последнюю очередь: для этого достаточно изменить конфиг и успешно пройти прогон тестов (eval run).
Шлюз — это уровень, который часто пропускают в прототипах. В Omega он должен подтверждать события Slack в пределах 3-секундного окна Slack и корректно обрабатывать повторно доставленные события. Длительные процессы затем передаются в среду выполнения, сохраняющую состояние, о которой рассказано ниже.
Наблюдаемость представляет собой сквозной слой, поскольку каждый уровень генерирует спаны. Семантические конвенции OpenTelemetry GenAI задают стандартные имена атрибутов для вызовов моделей и использования токенов. В Chatguru один трейс Langfuse охватывает поиск данных, планирование, вызов модели и первый сгенерированный токен с прикрепленными оценками качества. Во внутреннем бенчмарке весь шаг занял 840 мс: поиск данных — 88 мс, планирование агента — 36 мс, вызов GPT-4o — 704 мс на 412 токенов, а первый токен был получен через 312 мс при оценке релевантности 0.92 и фактологической точности (grounding) 0.97. Это ориентировочные значения из внутренних тестов, а не гарантия производительности, но они показывают, какую детализацию должен обеспечивать трейс.
Стоит ли начинать с одного агента с инструментами?
Начинайте с одного агента с инструментами и разделяйте роли только тогда, когда для отдельной роли действительно требуется собственный промпт, права доступа или модель. Вызов инструментов одним агентом закрывает большинство рабочих нагрузок в продакшене, а каждый добавленный агент означает еще один вызов модели и еще один промпт для поддержки.
Подробный анализ компромиссов приведен в нашем сравнении мультиагентных систем и одиночных агентов. Одного агента дешевле трейсить, оценивать и отлаживать. Мультиагентные архитектуры оправдывают себя тогда, когда обязанности агентов объективно конфликтуют между собой.
Используйте следующее правило: выносите роль в отдельного агента только при соблюдении одного из приведенных ниже условий, если тестирование на версии с одним агентом не дает нужного результата.
- Различаются права доступа. Проверьте, можно ли разграничить доступ с помощью учетных данных или областей видимости (scopes) для конкретных инструментов. Инструмент CRM только для чтения и инструмент для записи могут работать с одним агентом при раздельных scopes. Разделяйте агентов, когда ролям требуются разные цифровые личности или процессы согласования.
- Промпты конфликтуют. Прогоните тестовый набор (eval set) с единым общим промптом, а затем — с промптами для конкретных ролей. Разделяйте только в том случае, если общая версия показывает ощутимо худшие результаты для соответствующей роли.
- Различаются модели. Сопоставьте сэкономленные средства с возросшей задержкой. Небольшая модель-маршрутизатор перед более мощной моделью окупается, если большинство запросов успешно закрывается по дешевому пути.
Каждое разделение добавляет промпт, набор тестов и группу спанов трассировки, которые необходимо поддерживать в актуальном состоянии. В статье Anthropic Building effective agents рекомендуется сначала находить самое простое решение и усложнять его только тогда, когда это приносит явную пользу. Мы полностью с этим согласны.
Первые признаки того, что разделение было преждевременным:
- Сообщения для передачи контекста (handoff) постоянно увеличиваются, так как второму агенту требуется почти весь контекст первого.
- Ошибки валидации концентрируются в момент передачи задач между агентами.
- Один агент занимается исключительно переформатированием или пересылкой того, что сгенерировал другой.
Агент-критик — самый частый пример преждевременного разделения. Если проверка сводится к валидации схемы, оценке фактологичности или проверке правил политики, валидационный фильтр (eval gate) или guardrail внутри сервиса агента справятся с этим детерминированно и с меньшими затратами.
Chatguru работает как один агент с инструментами: операции с корзиной, поиск товаров и перевод диалога на живого оператора. Узкая область применения приносит плоды и в клиентских проектах. Прототип агента по обработке страховых претензий на базе GPT в Microsoft Azure для ARC Europe решал всего одну задачу и позволил сократить время рассмотрения претензии с 30 до 5 минут, будучи разработанным менее чем за 6 недель. Omega, наш ассистент по продажам в Slack, представляет собой противоположный пример мультиагентной системы и наглядно показывает, где оркестрация дает сбои.
Какой паттерн оркестрации выбрать?
Выбирайте тот паттерн оркестрации, сценарии сбоя которого вы способны обнаружить и ограничить. Omega отлично демонстрирует эту проблему: четыре подхода к координации ролевых агентов приводили к сбоям, и каждый раз к разным.
Omega начиналась как одиночный агент. Сложные запросы, такие как составление коммерческого предложения на основе заметок со звонка, данных CRM и внутренних бенчмарков, перегружали его. Поэтому мы разделили его на ролевых агентов: SalesAgent распознает намерения, DatabaseAgent извлекает контекст, PrimaryAgent выполняет работу, а CriticAgent ее проверяет. Тут-то и начались проблемы с координацией.
Вывод, который мы сделали: добавление агентов само по себе не гарантирует лучших результатов. Без жесткой маршрутизации, контроля токенов и строгого разделения ролей в системе появляется слишком много мнений и теряется фокус.
Следующим шагом стал структурированный эксперимент между двумя архитектурами (обе без «основного агента» и с критиком, низведенным до опционального инструмента обратной связи):
- Swarm: специализированные агенты передают задачи друг другу с общим контекстом и вызовами инструментов. Более естественное делегирование, но с риском возникновения «пинг-понга» и разрастания контекстного окна.
- Одиночный агент плюс инструменты: один главный агент при необходимости вызывает других агентов как инструменты. Проще, быстрее и легче в отладке, хотя и с некоторой потерей гибкости.
Для этого сравнения мы задали метрики оценки (процент успешных задач, эффективность расхода токенов и задержка) и использовали реальные отчеты об ошибках из ранних версий Omega в качестве тестовых сценариев. Какой бы паттерн вы ни выбрали, всегда ограничивайте максимальное число шагов (turn count) и закладывайте запасной ответ (fallback response), чтобы цикл прерывался штатно, а не после исчерпания лимита токенов. Полные истории ошибок описаны в статье о шести примерах сбоев ИИ, которые научили нас правильно создавать агентов.
Как мы выбирали процесс оценки стоимости?
Для процесса оценки продаж Omega мы сравнили четыре архитектуры по четырем критериям: UX в Slack, задержка, возможность повторного использования в других задачах по продажам и удобство сопровождения.
Мы объединили гибридный оркестратор и роевую модель. Оркестратор селекторного типа собирает скоординированную команду для структурированных этапов, таких как разбиение объема проекта на модули с помощью агента-архитектора модулей, критика и профильных экспертов. На исследовательских этапах, например, при уточнении допущений, агенты свободно передают управление друг другу в зависимости от уверенности и наличия необходимых данных. В любой момент агент может вернуть управление менеджеру по продажам. Полное сравнение приведено в нашей статье о потоке агентов для оценки продаж.
Подходит ли подход «планирование и выполнение» (plan-and-execute) для промышленного агента?
Подход «планирование и выполнение» подходит для промышленного агента, когда задача имеет структурированные этапы, которые можно определить заранее, и плохо подходит, когда следующий шаг зависит от результата работы предыдущего инструмента.
Планировщик выдает видимый список шагов, и этот список можно сохранять в контрольных точках. Устойчивая среда выполнения может возобновить работу с четвертого шага после сбоя, вместо того чтобы перезапускать весь процесс. Одобрение человеком также может быть встроено между планом и его первым действием, где его легко отклонить.
Существует два недостатка. Планировщик добавляет дополнительный цикл обращения к модели перед началом вызова любого инструмента, что задерживает получение первого полезного результата. Кроме того, план устаревает: если на втором шаге возвращается что-то, чего планировщик не предполагал, исполнитель продолжает следовать плану, который больше не применим. Промышленные версии требуют явного триггера для перепланирования.
Наше правило — использовать этот шаблон для многоэтапной работы с дорогими или необратимыми шагами. Пропускайте его для интерактивного чата, где один агент, перебирающий инструменты, отвечает быстрее.
Как контролировать контекст агента?
Контроль контекста — это решение о том, что попадает в промпт при каждом вызове модели, с выделением лимита токенов для каждого источника, прежде чем он вытеснит остальные.
Omega намеренно начала работу без генерации с дополненной выборкой (RAG), полагаясь на кэширование, промпт-инжиниринг и простую маршрутизацию. Проблемы возникли с резюме в Slack. Как мы задокументировали в нашем отчете о примерах сбоев ИИ, подача всей истории канала в GPT-4 приводила к переполнению контекстного окна: сообщения обрезались, а резюме длинных, фрагментированных веток неверно интерпретировали разговоры или добавляли детали, которых никто не писал.
Решением стало контролируемое контекстное окно:
- Ограничение количества начальных сообщений, загружаемых из ветки. Если разговор длиннее, сначала суммируются более ранние сообщения, и резюме вставляется перед тем, как агент продолжит работу.
- Еженощный конвейер AWS Step Functions, который проходит по каждому каналу Slack, где активна Omega, и обновляет базу данных последними действиями, чтобы DatabaseAgent читал резюме, а не необработанную историю.
На основе этих двух сборок мы используем простое правило для того, что получает каждый источник:
Chatguru с первого дня был ориентирован на поиск, потому что каждый ответ должен исходить из каталога клиента. Его поиск возвращает 8 релевантных SKU примерно за 88 мс со средним показателем релевантности 0,84 во внутренних тестах, и этот фиксированный слот найденных продуктов является приоритетным при распределении лимита токенов.
Ночные резюме могут отставать на срок до одного дня. Если вашему агенту нужно ответить по сегодняшней утренней ветке, загружайте самые последние сообщения напрямую, с ограничениями, и пусть резюме охватывает все, что было раньше. Команды с короткими, узкоспециализированными разговорами могут пропустить конвейер и хранить историю в промпте.
Как следует проектировать и связывать инструменты?
Проектируйте каждый инструмент как одно узкое действие с типизированной схемой, ограниченными правами доступа и ключом идемпотентности, а также связывайте инструменты в коде, когда последовательность известна заранее.
Инструмент вроде search_drive(query, folder_id) модели легче вызвать правильно, чем обобщенный fetch(source, params). Создание эффективных агентов рекомендует относиться к определениям инструментов с той же тщательностью, что и к промпту: явные описания параметров и форматы, которые трудно использовать неправильно.
Инструменты Omega включают API Slack, API Google Drive (пользовательские инструменты, которые читают документы с описанием области применения, извлекают списки функций и записывают результаты), Apollo для данных о компаниях и BlueDot для транскриптов звонков. Синхронизация, запускаемая вебхуком, делает файлы, загруженные в Slack, доступными для агентов через Drive. Каждая возможность представляет собой автономный модуль, поэтому можно вносить изменения, не ломая остальное.
Идемпотентность важна, потому что вызовы инструментов выполняются более одного раза. Slack повторно доставляет события, которые считает неподтвержденными, а AWS Lambda по умолчанию повторяет неудачные асинхронные вызовы. В Omega мы отключили повторные попытки Lambda, чтобы остановить дублирование сообщений. Более безопасное общее правило заключается в том, чтобы инструмент, а не модель, выводил ключ из ID события, имени инструмента и нормализованных аргументов, а затем проверял хранилище перед любым побочным эффектом. Инструменты корзины Chatguru — очевидный пример: повторная попытка добавления в корзину не должна добавлять второй товар.
Права доступа должны быть у каждого инструмента. Разделяйте инструменты для чтения и записи, а инструменты для записи помещайте за список разрешенных или требуйте одобрения человека. Вывод инструмента — это недоверенный ввод: документ Drive или транскрипт звонка может содержать внедренную инструкцию.
Качество выбора снижается по мере роста списка инструментов, потому что каждая схема занимает место в контексте, а похожие описания конкурируют друг с другом. Нам не известен универсальный порог, поэтому мы рекомендуем использовать фильтр оценки при выборе инструментов и отфильтрованный поднабор инструментов для каждой задачи. Model Context Protocol позволяет легко подключать много инструментов сразу, но он не сужает их выбор за вас.
Где должны находиться защитные барьеры и одобрение человеком?
Защитные барьеры располагаются в трех точках пути запроса: ввод, вызов инструмента и вывод. Одобрение человеком (human-in-the-loop) — это выход, который оркестратор инициирует из агентского сервиса, и промпт на это не влияет.
- Проверка ввода. Проверяйте текст пользователя и полученные документы на предмет инъекций промпта, прежде чем модель их увидит. Полученный контент — более сложный случай, потому что инструкция, скрытая в документе, выглядит как данные. В OWASP Top 10 for LLM Applications перечислены как инъекция промпта, так и чрезмерная агентность в качестве рисков.
- Проверка прав доступа к инструменту. Выполняйте ее в коде, между вызовом инструмента моделью и его исполнением. Обеспечьте список разрешенных действий для каждой роли, ограниченные учетные данные и проверку схемы. Направляйте действия записи, превышающие порог риска, на одобрение. Модель предлагает, а код принимает решение.
- Проверка вывода. Проверяйте схему, проверяйте обоснованность на основе полученных источников и редактируйте персональные данные. Второй вызов модели с узким набором правил подходит там, где правила не могут выразить качество. Это увеличивает задержку и стоимость, поэтому мы рекомендуем сначала использовать правила.
Агентский сервис Chatguru содержит политики, резервные варианты и обнаружение выхода за рамки компетенции. Поток оценки Omega определяет условия выхода: агент делает паузу, запрашивает больше данных или возвращает управление менеджеру по продажам, когда уверенность низка или информация отсутствует.
Триггеры выхода на человека должны быть явными: оценка ниже порога, действие записи, превышающее лимит прав, исчерпанные попытки повтора или повторяющийся сбой инструмента. Выход также должен корректно обрабатывать асинхронные ответы, паузы и тайм-ауты, потому что люди отвечают в Slack, когда у них появляется время. В AWS Step Functions обратный вызов с токеном задачи приостанавливает рабочий процесс до тех пор, пока рецензент не ответит. Установите для каждой паузы тайм-аут, который истекает со статусом «отклонено», если ответ не получен.
Read-only агент, обслуживающий внутренних пользователей, может обойтись без подтверждения действий, сохранив лишь проверку прав доступа. Очереди подтверждения оправдывают себя, когда агент способен изменить то, что трудно и дорого откатить назад. Подробнее об этих рисках читайте в материале о реальных подводных камнях ИИ-агентов.
Какая среда выполнения хранит состояние агента?
В продакшене состояние агента сохраняет среда надежного выполнения (durable execution runtime). Для Omega это означало перенос оркестрации с чистого AWS Lambda на AWS Step Functions в 2025 году, после того как бессерверные функции оказались неподходящим решением для диалогового агента.
Некоторые диалоги в Omega включают 20 и более внутренних итераций обмена сообщениями, поиск векторных эмбеддингов, запросы к базе данных и вызовы внешних API. Холодные старты Lambda добавляли более 3 секунд задержки, у Slack через 3 секунды срабатывал таймаут и повторная отправка, из-за чего пользователи получали дублирующиеся ответы. 15-минутный лимит выполнения в Lambda обрывал длинные мультиагентные цепочки прямо посреди диалога, а встроенного управления состоянием не было вовсе.
Одно быстрое решение помогло укладываться в три секунды: перенос импортов Python из начала файла внутрь функций, где они непосредственно требовались, чтобы при первом ответе загружалось только то, что используется. Это противоречит PEP 8 и было временной «заплаткой», а не системным архитектурным решением.
Step Functions решает оставшуюся проблему. Результат каждого шага сохраняется, поэтому неудачный вызов инструмента повторяется изолированно, без повторного прогона предшествующих вызовов модели, а выход на подтверждение человеком из предыдущего раздела ложится на паузу waitForTaskToken, которая не держит функцию активной. Для более тяжелых и длительных задач мы также тестировали инстансы EC2 и внутренние MCP-серверы. Храните большие полезные нагрузки, такие как извлеченные документы, в объектном хранилище и передавайте ссылки между состояниями, поскольку в стейт-машине действует лимит на размер полезной нагрузки за один переход. Документация AWS Step Functions and Lambda содержит перечень этих ограничений.
Когда это не требуется: если каждый запрос завершается за секунды и ни одна чат-платформа не требует мгновенного подтверждения приема, связки Lambda и таблицы диалогов в базе данных будет достаточно. Step Functions требует поддержки определений стейт-машины и влечет затраты на каждый переход между состояниями. Мы рекомендуем внедрять ее тогда, когда в сценарии есть несколько вызовов инструментов, ожидание подтверждения или время выполнения превышает лимит одного вызова функции.
Чек-лист для продакшена: от прототипа к продакшену, слой за слоем
Создавайте продакшен-версию в следующем порядке: оберните цикл прототипа в среду надежного выполнения, добавьте трассировку, настройте гейты релизов на основе eval-оценок, внедрите гардрайлы и только затем оптимизируйте контекст. Используйте одного агента с инструментами до тех пор, пока для роли не потребуются отдельные права доступа или промпты, и лишь тогда меняйте шаблон оркестрации.
Этот порядок продиктован тем, что именно сложнее переделывать задним числом. Состояние и трассировку трудно внедрить, когда диалоги уже идут в реальном времени, тогда как добавить еще одного агента позже не составит труда. Глубина оценки подробно описана в статье о тестировании ИИ-агентов.
Что касается трассировки, с первого же дня инструментируйте вызовы моделей, извлечение данных и вызовы инструментов в виде спанов. Семантические конвенции OpenTelemetry GenAI обеспечивают согласованные имена атрибутов, которые останутся актуальными даже при смене бэкенда трассировки. О том, как мы связываем Promptfoo и Langfuse, читайте в статье об оценке и наблюдаемости ИИ-чат-ботов.
FAQ
Что такое архитектура ИИ-агента?
Архитектура ИИ-агента — это набор компонентов вокруг модели, позволяющий ей планировать, вызывать инструменты и действовать автономно: шаблон оркестрации, управление контекстом, инструменты, гардрайлы, среда выполнения, сохраняющая состояние, и система наблюдаемости (observability). В продакшене именно окружающая архитектура определяет надежность, затраты и риски. Команды, у которых нет внутренних компетенций для построения всех этих слоев, часто анализируют услуги разработки агентного ИИ, прежде чем решить: создавать решение самостоятельно, покупать готовое или привлекать партнеров.
Каковы основные компоненты архитектуры ИИ-агента?
К основным компонентам относятся оркестратор, слой извлечения данных (retrieval layer), инструменты с типизированными схемами, гардрайлы, среда надежного выполнения с контрольными точками состояния, а также система наблюдаемости с трассировкой и eval-оценками. Генерация с дополненной выборкой (RAG) обеспечивает релевантный контекст, а вызов инструментов отвечает за выполнение действий. Отсутствующую среду выполнения или слой трассировки, как правило, сложнее всего внедрить уже после запуска.
Что отличает хорошую архитектуру ИИ-агента?
Хорошая архитектура ИИ-агента — это самая простая архитектура, решающая поставленную задачу: минимальное число агентов, инструменты с узкой зоной ответственности и возможность передачи управления человеку (human-in-the-loop). Она остается легко отлаживаемой, поскольку каждый шаг фиксируется в трассировке. Добавление новых агентов должно быть строго обосновано (например, разделением прав доступа), так как каждая передача контекста увеличивает задержку и создает дополнительные точки отказа.
Каковы лучшие практики архитектуры ИИ-агентов для продакшена?
Выносите гардрайлы за пределы модели: валидируйте аргументы инструментов, разграничивайте права доступа для каждого инструмента и требуйте подтверждения для необратимых действий. Делайте вызовы инструментов идемпотентными для безопасности повторных попыток, трассируйте каждый вызов модели и инструмента, а также тестируйте промпты и сценарии перед релизом — это особенно критично, когда агенты выполняют запись в мастер-системы.
Как перевести ИИ-агента из прототипа в продакшен?
Оберните цикл прототипа в среду надежного выполнения, которая сохраняет состояние между шагами, затем добавьте трассировку, гейты качества на основе eval-тестов и гардрайлы. Omega, внутренний Slack-ассистент по продажам в Netguru, перевел оркестрацию с AWS Lambda на AWS Step Functions после того, как холодные старты, повторные запросы Slack и 15-минутный лимит выполнения стали приводить к сбоям в длительных диалогах. Для коротких задач без сохранения состояния это может не потребоваться.
Что такое мультиагентная архитектура?
Мультиагентная архитектура разделяет работу между несколькими агентами, у каждого из которых есть собственный промпт, инструменты и права доступа, скоординированными с помощью шаблона оркестрации (например, супервизора или передачи управления между агентами). Каталог таких паттернов представлен в Azure Architecture Center. Добавляйте агентов только там, где необходимо строгое разделение ролей: каждая передача управления увеличивает задержку, и наш сравнительный анализ мультиагентных и одиночных агентов подробно рассматривает этот выбор.
Сначала соберите шасси, потом настраивайте двигатель
Окончательно определите архитектуру ИИ-агента до того, как начнете тонкую настройку модели, поскольку модель — это единственный компонент, который вы всегда сможете заменить позже. Шасси удерживает двигатель, рулевое управление и тормоза. Шаблон оркестрации, контроль контекста, гардрайлы и среда надежного выполнения делают то же самое для агента.
Держите количество агентов настолько малым, насколько позволяет задача, и внедрите трассировку еще до того, как придет первый пользователь. Чтобы пошагово проработать вашу собственную архитектуру вместе с нашими инженерами, запишитесь на воркшоп по ИИ-агентам или расскажите нам об агенте, которого вы хотите создать, и мы поможем спроектировать его продакшен-версию.
