Pluggable Agentic AI Framework от AWS — семиуровневая композируемая референсная архитектура, которая переводит корпоративные мультиагентные приложения из прототипа в продакшн на Amazon Bedrock AgentCore. Уровней семь: данные и знания, модель и инференс, оркестрация, безопасность и гардрейлы, приложение, наблюдаемость, агентные операции. У каждого своя зона ответственности и стабильный контракт, поэтому технологию на любом уровне можно заменить, не перепроектируя остальной стек. Описание архитектуры в блоге AWS подаёт именно сменяемость компонентов как главное свойство схемы: pluggability про замену провайдеров и технологий, а не про конкретный набор сервисов.
Демо отвечает на один вопрос: способна ли модель выполнить задачу. Масштабирование, безопасность, стоимость и надёжность остаются за кадром, потому что прототип для этого не строили.
Дальше — карта семи уровней, разбор оркестрации (супервизор, реестр агентов, протоколы MCP и A2A), чек-лист безопасности (аутентификация каждого запроса, fine-grained access control, маскирование PII, аудит-трейл, human approval gate, circuit breakers), контур наблюдаемости с непрерывной оценкой качества и критерии выбора между быстрым прототипом и архитектурой под нагрузку. Отдельно обозначу границу знания: в блоге AWS подробно раскрыты уровни данных и знаний и модели и инференса, а внутреннее устройство оркестрации, безопасности и наблюдаемости частично раскрыто в сопутствующем воркшопе AWS, который описывает архитектуру как пять слоёв (L1–L5) со сквозными безопасностью и наблюдаемостью. Уровни приложения и агентных операций в доступных материалах отдельно не детализированы, поэтому соответствующие разделы ниже построены как инженерные требования к уровню с явной пометкой.
Почему работающий прототип агента не отвечает на вопросы продакшна
Прототип собирают с одной целью: убедиться, что модель способна выполнить задачу. Вызвать инструмент, достать данные, собрать ответ. Это нормальная проверка гипотезы, и она обычно проходит, если сценарий выбран аккуратно.
Потом начинается этап, к которому PoC не готовил. Продакшн спрашивает про поведение под нагрузкой, права доступа, счёт за токены и деградацию внешних API. Ответов в блокноте нет, потому что вопросов там не задавали.
Четыре вопроса, на которые не отвечает демо
- Масштабирование. Сколько параллельных сессий держит runtime, что происходит с памятью сессии, как растёт задержка, когда супервизор вызывает трёх агентов одновременно. Демо с одним пользователем и одним запросом не показывает ни одного из этих эффектов.
- Безопасность. Кто аутентифицирует запрос, какие права получает агент на вызов инструмента, что попадает в логи, есть ли аудит-трейл. В демо агент обычно ходит в базу под одним всемогущим ключом.
- Стоимость. Сколько токенов и вызовов инструментов уходит на один диалог, сколько шагов делает агент в типичном сценарии, какая модель нужна на каждом шаге. Счёт за API становится виден только на реальном трафике.
- Надёжность. Что делать, когда внешний сервис отвечает таймаутом, сколько повторов допустимо, как выглядит корректный отказ. В демо таймаут лечится перезапуском ноутбука.
Эти четыре оси и составляют содержание перехода в продакшн. Модель в нём участвует, но результат определяет не она.
Почему проблема обычно не в модели
Разрыв между работающим прототипом и системой, которая надёжно, безопасно, экономно и ответственно работает в масштабе, — то место, где застревает большинство инициатив с агентным AI. И редко по вине модели: в описании фреймворка AWS формулирует это прямо — PoC создаётся, чтобы показать способность модели выполнить задачу, а не чтобы выжить под продакшн-трафиком, давлением по стоимости и проверкой безопасности.
Вторая половина проблемы — повторяемость. Каждая команда заново собирает одну и ту же обвязку: свою логику маршрутизации, свои гардрейлы, свою наблюдаемость. Причём постфактум, когда что-то уже сломалось на проде. Нужна общая продакшн-готовая архитектура, на которую опирается каждый агент, и семь уровней фиксируют её один раз вместо десяти одинаковых самоделок.
Что такое Pluggable Agentic AI Framework и в чём смысл pluggability
Фреймворк задаёт семь уровней и правило: единица замены — уровень, а не весь стек. Поменяли векторную базу, оркестрация и безопасность этого не заметили. Поменяли модель, логика агентов осталась на месте.
Оговорка, без которой схему легко прочитать неправильно: сервисы и технологии, показанные на каждом уровне, отражают эталонную сборку AWS, а не обязательный выбор. Организации подставляют альтернативы под свою инфраструктуру и требования. Bedrock Knowledge Base в примере не означает, что вам нужен именно он.
Контракт уровня vs конкретная технология
Уровень — это зона ответственности плюс контракт. Сервис — одна из его реализаций по части технологии. Контракт уровня данных звучит буднично: принять запрос и вернуть наиболее релевантную информацию, которая станет контекстом для агента. Всё остальное — детали: какой индекс, какая модель эмбеддингов, какая БД.
Пока контракт держится, замена компонента остаётся инженерной задачей, а не переписыванием системы. Выбор модели и инференса по той же логике задаётся конфигурацией, а не хардкодится в логике агента или приложения: смена модели превращается в правку конфига, а не в релиз кода агента.
Семь уровней архитектуры агентов на Amazon Bedrock AgentCore: карта и зоны ответственности
Ниже карта уровней с зоной ответственности и рабочей формулировкой контракта. Для данных и модели контракты зафиксированы в описании AWS, для оркестрации, безопасности и наблюдаемости опора — сопутствующий воркшоп AWS, для приложения и агентных операций в доступных материалах деталей нет, поэтому формулировки в третьей колонке — рабочие, для проектирования.
| Уровень | Зона ответственности | Контракт (рабочая формулировка) |
|---|---|---|
| Данные и знания | retrieval, эмбеддинги, доступ к структурированным и неструктурированным данным | принять запрос, вернуть релевантный контекст |
| Модель и инференс | выбор модели, маршрутизация, изоляция от провайдерских API | принять промпт и параметры, вернуть ответ модели |
| Оркестрация | декомпозиция задачи, вызов агентов и инструментов, сборка результата | принять цель, вернуть результат с трейсом шагов |
| Безопасность и гардрейлы | аутентификация, авторизация вызовов, маскирование данных, аудит | разрешить или запретить действие и оставить запись |
| Приложение | интерфейсы и сценарии для пользователя или внешней системы | принять запрос пользователя, вернуть ответ и статус |
| Наблюдаемость | трейсы, метрики, оценка качества на трафике | принять события, вернуть сигнал о деградации |
| Агентные операции | деплой, версии, конфигурация, инциденты | выкатить сборку и откатить её |
Два нижних уровня в описании AWS раскрыты подробнее остальных, им и посвящены следующие два подраздела.
Уровень данных и знаний: retrieval, эмбеддинги и доступ к данным
Уровень владеет retrieval, эмбеддингами и доступом к структурированным и неструктурированным данным. Контракт простой: принять запрос, вернуть релевантную информацию как контекст для агента. Примеры строительных блоков в эталонной сборке AWS: Amazon Bedrock Knowledge Base, Vector Engine for Amazon OpenSearch Serverless, Amazon S3 Vectors, Amazon DynamoDB.
Ставка здесь выше, чем кажется. Агент настолько хорош, насколько хороши данные, к которым он имеет доступ: проверка медицинского формуляра, отслеживание остатков на складе и разбор правила комплаенса упираются в актуальность и точность источника, а не в красоту промпта. Если retrieval возвращает мусор, дальше его не исправит никакая модель.
Уровень модели и инференса: конфигурация вместо хардкода
Правило: выбор модели и параметров инференса задаётся конфигурацией. Простая задача — меньшая и более быстрая модель, запрос с тонким рассуждением — большая. Такой выбор делают на слое маршрутизации, чтобы агент не знал, где хостится модель и какой у провайдера API.
Слой маршрутизации даёт ещё одно свойство: агенты остаются независимыми от среды хостинга моделей. Переезд на другого провайдера или на другую модель внутри того же провайдера не превращается в правку каждого агента.
Цена гибкости — необходимость измерять. AWS отдельно подчёркивает: модель нужно оценивать под конкретный сценарий, на реалистичных и репрезентативных бизнес-данных, а не на синтетических примерах из туториала. Для систематической оценки Amazon Bedrock предлагает LLM-as-a-judge и RAG-оценку для Knowledge Bases — с поддержкой ground truth и reference-free метрик, выбором моделей-оценщиков и сравнением моделей; эти возможности встраиваются в жизненный цикл разработки и позволяют масштабировать оценку на тысячи ответов.
Уровень приложения и агентные операции: что остаётся людям и процессам
Приложение — это интерфейсы и сценарии, с которыми работает человек или внешняя система: чат поддержки, кнопка в CRM, вебхук из тикетницы. Здесь живут UX-решения: как показать, что агент думает, как передать диалог оператору, что делать с частичным ответом. В доступных материалах AWS этот уровень отдельно не детализирован, поэтому перечисленное — инженерные требования, а не описание референсной реализации.
Агентные операции (AgentOps) — эксплуатация агентов как рабочей нагрузки: деплой, версии, конфигурация, реагирование на инциденты. Без явного AgentOps-уровня агенты остаются демо на ноутбуке: конфиг правится руками, версии не отслеживаются, откат делается перезапуском. Это тоже рабочая рамка, а не подтверждённое описание уровня из материалов AWS. Как выстроить политики и рабочий процесс вокруг автономных агентов, разбирали отдельно.
Оркестрация: супервизор, специализированные агенты, реестр и протоколы MCP и A2A
Один универсальный агент с десятком инструментов плохо масштабируется по двум осям: сложность промпта и права доступа. Чем больше инструментов, тем чаще модель выбирает не тот; чем шире права, тем дороже ошибка. Декомпозиция на специализированных агентов под управлением супервизора снимает обе проблемы, но добавляет свои.
Оговорка о границе знания: в блоге AWS детали супервизора, реестра и протоколов не раскрыты, но сопутствующий воркшоп AWS описывает оркестрацию как цепочку Harness → Registry → Specialist Agents: специализированные агенты развёрнуты, а оркестратор обнаруживает их динамически через централизованный реестр. Ниже — эта логика плюс инженерные требования, вытекающие из контрактов уровней.
Как супервизор раскладывает задачу на подзадачи
Цикл выглядит так: принять запрос, определить нужных специализированных агентов через реестр, вызвать их, собрать и согласовать ответы, обработать частичные отказы. Супервизор не делает работу сам, он планирует и проверяет. В воркшопе AWS супервизор-оркестратор динамически обнаруживает и делегирует задачи специализированным агентам через harness; в описании опыта построения мультиагентных систем на AgentCore супервизор также поддерживает контекст, оркестрирует многошаговые workflow и обеспечивает соблюдение политик до выполнения действия.
Декомпозиция держится на явных границах ответственности. Если агент заказов и агент возвратов оба умеют смотреть историю покупок, супервизор начнёт дублировать вызовы, платить за них дважды и получать расхождения в ответах. Границы должны быть описаны в реестре, а не подразумеваться.
Иллюстрация: запрос «где мой заказ и можно ли вернуть часть» разбивается на две подзадачи. Агент заказов тянет статус доставки, агент возвратов проверяет политику по конкретным позициям и срокам, супервизор сводит оба ответа в одно сообщение.
MCP и A2A: зачем два протокола
Протоколы решают разные задачи. MCP отвечает за доступ агента к инструментам и ресурсам: как обнаружить инструмент, как его вызвать, как описать схему аргументов. A2A — за общение агентов между собой: как один агент формулирует задачу другому и как принимает результат. В опубликованных материалах AWS эта связка встречается на практике: бизнес-логика в Lambda-функциях становится доступна агентам через MCP, а взаимодействие агентов идёт через A2A; есть и пример мультиагентной системы на AgentCore Runtime из оркестратора, анализатора OpenAPI-спецификаций и генератора документации, построенной на A2A.
Смысл протоколов в том, что они дают контракт вместо прямых вызовов внутри кода. Инструмент, подключённый через MCP, можно заменить, не трогая агента. Агента за тем же протоколом можно заменить, не трогая супервизора. Оба протокола опираются на реестр и на уровень безопасности: аутентификация и авторизация проверяются на каждом вызове, а не только при входе в приложение.
Практический пример такой связки — кейс AvioBook на AgentCore: MCP-инструменты в Gateway, запросы к Athena и S3, изоляция данных через JWT и Cognito.
Ограничения видны на тех же схемах. Супервизор — дополнительная точка задержки и отказа. Плохая декомпозиция даёт больше ошибок, чем один монолитный агент: каждая передача контекста между агентами теряет детали. Мультиагентность оправдана там, где подзадачи действительно разные по правам, данным и логике.
Безопасность и гардрейлы: что нужно агенту, который реально ходит в системы
Почему гардрейлы нельзя прикрутить постфактум
Гардрейлы обычно добавляют после того, как агент уже работает: сначала демо, потом запуск, потом проверки. В агентной системе такая последовательность дороже, чем в обычном сервисе. Права доступа и аудит встроены в каждый вызов инструмента, и если вызовы писались без них, переписывать придётся всю цепочку.
Пример архитектурной ошибки, которую не лечит промпт: агенту возвратов выдали доступ к платёжным данным, потому что он «в том же сервисе». Это решение уровня безопасности, и принимается оно при проектировании, а не при разборе инцидента.
Что должен закрывать уровень безопасности и гардрейлов. Часть пунктов подтверждена документацией AWS по безопасности AgentCore Runtime, часть — инженерные требования, вытекающие из контракта уровня:
- Аутентификация каждого запроса. AgentCore Runtime поддерживает аутентификацию IAM SigV4 и JWT bearer token, при этом один runtime поддерживает только один метод одновременно, а для разных типов аутентификации создаются отдельные версии. IAM SigV4 применяют для service-to-service вызовов внутри Amazon, JWT — когда конечные пользователи аутентифицируются напрямую через identity provider.
- Fine-grained access control для вызовов инструментов. Resource-based policies дают fine-grained access control непосредственно на ресурсах runtime; при runtime API-операциях Amazon оценивает политики и на agent runtime, и на agent endpoint — оба должны разрешать действие. Для MCP-инструментов в AgentCore Gateway доступ можно ограничивать по правам и контексту вызывающего принципала, контекстно отвечая на вызовы ListTools, InvokeTool и Search, вплоть до tenant isolation для мультитенантных инструментов.
- Принцип наименьших привилегий и защита execution roles. Документация AWS рекомендует валидировать IAM-политики на соответствие least privilege и защищать execution roles от confused deputy problem с помощью global condition context keys в trust policies.
- Единая управляемая точка входа. Распространённый паттерн — вынести AgentCore Gateway перед AgentCore Runtime, чтобы шлюз стал единственной управляемой точкой входа: policy engine контролирует, кто и какие цели может вызывать и при каких условиях, Bedrock Guardrails через policy engine проверяют запросы и ответы, а interceptor Lambda-функции инспектируют или преобразуют трафик.
- Маскирование PII. В воркшопе AWS Lambda-интерсептор на AgentCore Gateway применяет Bedrock Guardrail к каждому ответу инструмента до попадания к оркестратору и анонимизирует PII, например email-адреса и адреса доставки.
- Аудит-трейл. Требование к уровню: кто, что, каким агентом и каким инструментом вызвал. Без этого разбор инцидента превращается в археологию по логам приложения. В доступных материалах AWS аудит-трейл как отдельный элемент референсной архитектуры не описан.
- Human approval gate. Необратимые действия проходят через подтверждение человеком: возврат выше порога, удаление записи, изменение заказа. Это инженерное требование, а не подтверждённый элемент референсной архитектуры AWS.
- Circuit breakers. Внешняя зависимость деградировала, агент останавливает вызовы и отвечает по предсказуемому сценарию вместо каскада таймаутов и повторов. Также требование к уровню, в материалах AWS прямо не подтверждено.
Проверки ставятся централизованно, на уровне контрактов, а не в каждом агенте заново. Это прямое следствие pluggability: новый агент наследует политику, а не копирует её.
Бесплатным такой уровень не бывает. Каждый контроль добавляет задержку, каждое правило — повод для ложного отказа, аудит требует хранилища и ретенции. Разбор случая, когда read-only агент всё равно изменил CRM, показывает, почему проверки нужны на границе исполнения, а не в описании роли агента.
Наблюдаемость и непрерывная оценка качества в продакшне
Логи приложения отвечают на вопрос «что сломалось». Для агента этого мало. Нужен трейс всей цепочки: запрос пользователя, решение супервизора, выбранные агенты, вызовы инструментов, промежуточные ответы, финальная формулировка. Без трейса невозможно понять, где потерялось качество: в retrieval, в выборе инструмента или в генерации. В воркшопе AWS этот уровень реализован через запросы X-Ray distributed traces и CloudWatch metrics: они позволяют проследить запрос сквозь систему, посчитать стоимость сессии и найти узкие места по латентности, а GenAI Observability dashboard в CloudWatch служит для постоянного мониторинга.
Вторая часть — метрики. Практический минимум: доля успешных вызовов инструментов, число шагов и стоимость на обращение, задержка по шагам, доля обращений с эскалацией человеку, доля ответов, заблокированных гардрейлами. Пороги зависят от сценария, универсальных цифр здесь нет, и подставлять чужие значения из отчётов бессмысленно.
Третья часть — оценка качества. Проверка модели на репрезентативных бизнес-данных должна быть регулярной, а не разовым мероприятием перед запуском: меняется трафик, меняются инструменты, обновляются модели. Возможности оценки Amazon Bedrock (LLM-as-a-judge и RAG-оценка) встраиваются в жизненный цикл разработки и позволяют масштабировать оценку на тысячи ответов, принимая решения о выборе модели и развёртывании на основе данных. Важная оговорка: непрерывная оценка именно на реальном продакшн-трафике как постоянный контур в доступных материалах AWS прямо не описана — подтверждена интеграция оценки в жизненный цикл разработки и масштабирование оценки, но не мониторинг боевого трафика. Оценивать агента сложнее, чем модель, потому что итог зависит от цепочки решений, и эту цепочку нужно раскладывать на составляющие, иначе непонятно, что именно чинить.
Референсный кейс: поддержка клиентов в ритейле на супервизоре и двух агентах
Сценарий: клиент пишет в поддержку интернет-магазина. В воркшопе AWS он описан как AnyCompany, онлайн-ритейлер, где строится мультиагентная система поддержки клиентов для запросов по заказам и обработки возвратов без хардкода эндпоинтов агентов: супервизор-оркестратор динамически обнаруживает и делегирует задачи специализированным агентам через harness. В воркшопе есть отдельный Order Agent (Lambda + Runtime + Registry) и таблица CustomerOrders в DynamoDB с примерными данными. Детали агента возвратов в доступных материалах раскрыты менее подробно, поэтому часть конфигурации ниже — иллюстрация по уровням, показывающая, как они стыкуются между собой.
Данные и знания. Заказы и статусы доставки лежат в структурированной БД (в воркшопе — таблица CustomerOrders в DynamoDB), политика возвратов и FAQ — в retrieval. Агент заказов обращается к первому источнику, агент возвратов читает политику и проверяет сроки по позициям.
Модель и инференс. Классификация запроса и простые ответы уходят на меньшую быструю модель, спорные случаи с расчётом частичного возврата — на модель с более тонким рассуждением. Выбор задан конфигурацией, поэтому замена модели не трогает промпты агентов.
Оркестрация. Супервизор принимает диалог, через реестр определяет нужного агента, MCP-инструменты дают доступ к заказам и возвратам, A2A используется, когда для одного ответа нужны оба агента.
Безопасность. Агент возвратов не видит платёжные данные. Возврат выше заданного порога уходит на подтверждение оператору. PII маскируется в логах, каждый вызов инструмента попадает в аудит-трейл.
Приложение. Чат поддержки с явной кнопкой эскалации и отображением статуса обработки.
Наблюдаемость. На каждое обращение — трейс с шагами, на потоке — метрики по инструментам, стоимости и эскалациям.
Агентные операции. Версии агентов и конфигураций выкатываются отдельно от кода приложения, с возможностью откатить одну конфигурацию, не трогая остальные.
Что даёт такая разбивка: замену векторной БД или модели без переписывания оркестрации и безопасности. Плагинность проверяется простым вопросом: сколько компонентов придётся править, если завтра сменится модель или индекс. Похожий по масштабу случай с несколькими агентами и подтверждёнными цифрами — кейс Trane Technologies на AgentCore, где 20-минутная диагностика HVAC превратилась в диалог на 20 секунд.
Когда семиуровневая архитектура оправдана, а когда это оверинжиниринг
Признаки, при которых раскладка на семь уровней окупается: несколько агентов и десятки инструментов, реальные права доступа к бизнес-системам, требования аудита и разбора инцидентов, несколько команд на одном стеке, долгий жизненный цикл с заменой моделей и провайдеров.
Обратные признаки: один агент с одним-двумя инструментами, внутренний эксперимент, короткий горизонт, отсутствие требований по аудиту. Здесь контракты и инфраструктура съедят время, которое лучше потратить на проверку гипотезы.
Ограничения подхода стоит называть прямо. Накладные расходы на контракты, реестр и наблюдаемость; зависимость от зрелости команды, которая должна эти контракты поддерживать; риск построить архитектуру ради архитектуры и полгода согласовывать схемы вместо запуска. Стоимость владения такой системой выше, чем у скрипта на двести строк, и окупается только при соответствующем масштабе задач.
Практический вывод: pluggability ценна тогда, когда вы действительно собираетесь менять провайдеров по слоям и сохранить уже используемые инструменты. Если такой потребности нет, начинайте с прототипа, но зафиксируйте границы уровней хотя бы на бумаге. Расставлять их позже дороже, чем сразу.