AWS предложил семислойную архитектуру для агентов: от прототипа к продакшену

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

В блоге AWS Machine Learning вышел разбор Pluggable Agentic AI Framework. Это референсная архитектура для мультиагентных приложений из семи слоёв. У каждого слоя своя зона ответственности и стабильный контракт с соседями. Конкретные сервисы в схеме — только пример реализации, а не обязательный выбор.

Семь слоёв без магии

Первый слой — данные и знания. Он принимает запрос и возвращает релевантный контекст для агента. В примере это Bedrock Knowledge Base, OpenSearch Serverless, S3 Vectors и DynamoDB.

Второй слой — модели и инференс. Выбор модели должен жить в конфигурации, а не в коде агента. Простые задачи идут на маленькую быструю модель, сложные рассуждения на большую. Между агентами и провайдерами стоит прокси вроде LiteLLM с единым интерфейсом. Сменить модель после очередной оценки можно, не трогая логику приложения.

Третий слой — оркестрация. Для простой задачи хватит одного агента. Для сложных кросс-доменных сценариев нужен супервизор и узкие специалисты, у каждого свой набор инструментов. Один универсальный агент со временем обрастает инструкциями и инструментами, контекст разбухает, задержка растёт, точность падает. Специалистов регистрируют в едином реестре, а супервизор находит их и вызывает по стандартным протоколам MCP и A2A. Реестр с описанием инструментов, навыков и владельца каждого агента нужен ещё и для governance, и чтобы не писать одно и то же дважды.

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

Пятый слой — приложение. Его советуют держать тонким: чат, API или виджет передают запрос оркестратору, и всё. Бизнес-логике здесь не место. На границе можно поставить дешёвую быструю модель-классификатор. За один вызов она оценивает, укладывается ли запрос в тематику, нужен ли человек и насколько срочно. Модель возвращает вероятности, а не текст, и обычный код по порогам решает, запускать ли полный агентный цикл.

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

Как это выглядит на примере

Референсная реализация — поддержка клиентов в ритейле, статус заказа и возможность возврата. Супервизор получает запрос на возврат и передаёт его двум специалистам. Агент заказов достаёт данные о доставке и покупке из DynamoDB. Агент возвратов берёт правила по уровням лояльности из базы знаний и считает допустимость по дате доставки, текущей дате и уровню клиента. Каждый вызов идёт через AgentCore Gateway, который проверяет права. Каждый вызов трейсится, и если расчёт ошибся, по трейсу видно, на каком слое и в каком решении.

Что с этого взять

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

Ограничения тоже стоит видеть. Статья написана вендором и ориентирована на стек AWS: AgentCore, Bedrock, CloudWatch. Заменимость компонентов заявлена, но проверять её на своей инфраструктуре придётся самим. Сами авторы оговариваются, что пример не заменяет харденинг безопасности, тестирование и ревью.

Практический вывод простой. Даже если вы не используете AWS, список из семи слоёв работает как чек-лист для планирования. Есть ли у вас реестр агентов? Права проверяются до вызова инструмента или после? Умеете ли вы доказать, что агент работает так же хорошо, как в день запуска? Если хотя бы на один вопрос ответ «нет», вы нашли, где ваш проект рискует застрять между прототипом и продакшеном.