Что такое Amazon Bedrock AgentCore runtime и зачем мигрировать с ECS с Fargate
AgentCore runtime - управляемая возможность развёртывания внутри Amazon Bedrock AgentCore. Она берёт на себя жизненный цикл контейнеров, масштабирование, идентификацию и наблюдаемость, а команде оставляет код агента (описание кейса AWS).
До миграции мультимодельный медицинский агент работал на Amazon ECS с AWS Fargate. Оркестрацию контейнеров, масштабирование, идентификацию и наблюдаемость там настраивала команда: заметный объём работы, который не имеет отношения ни к медицине, ни к логике ответов.
Переезд не требует переписывать агента. Существующий код оборачивают в паттерн декоратора AgentCore: BedrockAgentCoreApp, @app.entrypoint, app.run(). Дальше операционные задачи закрывает рантайм.
Выгода здесь в объёме инфраструктурной рутины, а не в скорости самого агента. Качество и задержку ответов определяют модели, логика оркестрации и векторный поиск; рантайм на них не влияет.
Amazon Bedrock AgentCore - платформа для создания агентов, подключения их к внешним системам и тонкой настройки их работы в масштабе, с любым фреймворком или моделью.
Какие задачи AgentCore runtime забирает у команды
Управляемый рантайм закрывает четыре зоны.
- Жизненный цикл контейнеров. На ECS с Fargate это task definitions, обновление сервиса, перезапуск упавших задач, контроль версий образа. Рантайм занимается этим сам.
- Масштабирование. Раньше приходилось настраивать auto scaling policies, выбирать метрики и следить за прогревом. Теперь масштабирование входит в рантайм.
- Идентификация. Раньше: роли для задач и распределение прав на вызовы Amazon SageMaker AI, Amazon Bedrock и Amazon OpenSearch Service. Теперь идентификация на стороне рантайма.
- Наблюдаемость. Раньше логи, метрики и трейсы собирали и связывали вручную. Теперь наблюдаемость входит в управляемую возможность.
Одна оговорка: идентификация на стороне рантайма не отменяет проектирования политик доступа. Кто из пользователей и сервисов видит какие данные, вы решаете сами.
Когда миграция оправдана, а когда нет
Признак, что идти стоит: агент уже контейнеризован, а время команды уходит на инфраструктуру, а не на логику. В кейсе AWS миграция сохранила возможности агента, включая тройную оркестрацию моделей и векторно-дополненный поиск знаний.
Сначала проверьте ограничения, если у вас:
- нестандартная сетевая топология или специфичные sidecar-контейнеры;
- привязка к собственному оркестратору, своему механизму секретов или нестандартной схеме деплоя;
- требования к окружению, которые управляемый рантайм не покрывает.
Такие вещи дешевле выяснить до переезда. Заодно посмотрите, как развивается платформа: в обзоре обновлений Amazon Bedrock и AgentCore за август 2026 собраны изменения, которые влияют на выбор архитектуры и на бюджет.
Если агента ещё нет, мигрировать нечего: сначала пригодится разбор архитектуры агента с кодом на Python.
Паттерн не привязан к медицине. Тот же путь подходит финансовому сектору и производству: меняются модели и источники данных, схема переезда остаётся.
Архитектура агента до миграции: три модели, векторный поиск и ECS с Fargate
Агент обрабатывает медицинские запросы через три модельных бэкенда и векторно-дополненный поиск знаний. Всё это работает внутри одного контейнера, развёрнутого на Amazon ECS с AWS Fargate.
Роль каждого модельного бэкенда
| Бэкенд | Где работает | Задача |
|---|---|---|
| BioM-ELECTRA-Large-SQuAD2 | Amazon SageMaker AI | специализированные биомедицинские запросы |
| Llama 3.1 70B Instruct от Meta | Amazon Bedrock | более широкие медицинские рассуждения |
| Контейнерный сервер модели | внутри контейнера агента | третий бэкенд оркестрации |
Логика разделения простая: не каждая формулировка требует одной и той же модели. Узкая биомедицинская модель закрывает свой класс вопросов, большая языковая модель берёт на себя рассуждения общего медицинского характера.
Оркестрация живёт в коде агента. Маршрутизация между бэкендами при миграции не меняется: вы переносите тот же код, рантайм не вмешивается в выбор модели.
Как устроен векторный поиск на Amazon OpenSearch Service
База знаний лежит в векторном хранилище на Amazon OpenSearch Service. Из него агент достаёт фрагменты, близкие к запросу, и подмешивает их в контекст перед вызовом модели. Поиск остаётся частью логики агента и переезжает вместе с ней.
Что продумать заранее: разграничение доступа к индексам, правила цитирования источников и оценку качества найденных фрагментов. Подробнее про маршрутизацию между базами знаний и контроль ответов через CloudWatch, X-Ray и OpenTelemetry - в разборе агентного поиска на Amazon Bedrock.
Референсная реализация кейса построена на Hugging Face smolagents - открытой Python-библиотеке, которая позволяет собирать и запускать агентов в несколько строк кода.
Что меняется при переходе на AgentCore runtime: сравнение с ECS с Fargate
Разница между подходами сводится к тому, кто отвечает за операционные задачи.
| Зона | Amazon ECS с AWS Fargate | AgentCore runtime |
|---|---|---|
| Оркестрация контейнеров | task definitions, обновление сервиса, перезапуск задач настраивает команда | берёт на себя рантайм |
| Масштабирование | auto scaling policies и метрики настраивает команда | берёт на себя рантайм |
| Идентификация | роли и права распределяет команда | берёт на себя рантайм |
| Наблюдаемость | логи, метрики и трейсы собирает команда | входит в рантайм |
Чего в таблице нет: сравнения по цене и по задержке. Таких данных в разборе AWS не приводится, поэтому обещать экономию или ускорение было бы гаданием. Считайте сами на своём профиле нагрузки.
Оркестрация и масштабирование: что уходит из вашей ответственности
На ECS с Fargate минимальный набор работы выглядел так: описать task definition, настроить сервис, задать политику масштабирования, продумать обновление без простоя. Всё это требует поддержки при каждом изменении образа или окружения.
После миграции расписание контейнеров и масштабирование под нагрузку закрывает рантайм. Возможности агента при этом сохраняются: тройная оркестрация моделей и векторно-дополненный поиск знаний работают как раньше.
Идентификация и наблюдаемость без ручной обвязки
Идентификация и наблюдаемость входят в управляемый рантайм. Практический эффект: меньше ручной конфигурации, а значит меньше мест, где можно ошибиться в правах или потерять логи.
Ответственность это не снимает. Политики доступа к чувствительным данным, сроки хранения логов и состав метрик остаются вашей задачей, просто описываются они декларативно, а не собираются из десятка сервисов вручную.
Пошаговая миграция: оборачиваем существующий код в декоратор AgentCore
Порядок шагов в кейсе AWS такой.
- Установить AgentCore CLI. Инструмент командной строки нужен для создания проекта и деплоя.
- Создать проект. Каркас задаёт структуру каталогов и конфигурацию.
- Добавить BYO-агента. Подход bring-your-own позволяет развернуть существующий код агента в AgentCore runtime без переписывания и без адаптации под конкретный фреймворк.
- Подготовить
pyproject.toml. В файле описаны зависимости и метаданные Python-проекта. - Подготовить
Dockerfile. Контейнер остаётся единицей развёртывания, только его жизненным циклом управляет рантайм. - Задеплоить одной командой. Сборка и выкладка в несколько шагов вручную не нужны.
- Проверить работу. Два способа: через CLI и через boto3.
Установка AgentCore CLI и создание проекта
Первые два шага задают каркас: CLI создаёт проект, в который дальше добавляется ваш агент. До этого момента исходный код агента не трогают.
Подготовка pyproject.toml и Dockerfile
pyproject.toml отвечает за зависимости и метаданные проекта: без него сборка не соберёт нужное окружение. Dockerfile описывает образ, который поедет в рантайм.
Если у вас уже есть рабочий Dockerfile для ECS, его логика переносится почти без изменений. Меняется не содержимое образа, а то, кто им управляет.
Деплой одной командой и тестирование через CLI или boto3
Суть миграции в одной детали: логика агента не меняется, меняется способ запуска и управления. Обёртка выглядит так:
app = BedrockAgentCoreApp()
@app.entrypoint
def invoke(payload):
# здесь вызывается существующая логика агента
return handle_query(payload)
app.run()
Имена модулей и сигнатуру обработчика сверяйте с документацией AgentCore: в разборе AWS акцент сделан на самом паттерне, а не на деталях импорта.
Тестирование через CLI удобно для быстрой проверки после деплоя. boto3 нужен, когда вызов агента встраивается в существующий код или в pipeline проверок.
Ограничения решения и что нужно для продакшена с медицинскими данными
Решение из разбора AWS - демонстрационный пример. Это не готовый продакшен-сервис, и относиться к нему стоит соответственно.
Почему демо не равно продакшен
В демонстрационном кейсе нет того, что появляется при реальной эксплуатации медицинского ассистента: политик обработки чувствительных данных, аудита доступа, процедур реагирования на инциденты, проверок на соответствие отраслевым требованиям. Ничего из этого управляемый рантайм не добавляет автоматически.
Отдельно про код: подстановка реальных данных в демо-пример требует пересмотра прав доступа, маскирования и логирования. Рантайм снимает инфраструктурную нагрузку, ответственность за безопасность и соответствие остаётся на команде.
Роль Amazon Bedrock Guardrails
Для продакшена с чувствительными медицинскими запросами AWS рекомендует Amazon Bedrock Guardrails (рекомендация из разбора). Guardrails - дополнительный слой контроля поверх модели и агента, а не замена продумывания политик доступа.
Рекомендация в источнике сформулирована общо. Конкретный набор правил под медицинский домен придётся проектировать самому: какие темы блокировать, что маскировать в ответах, как логировать срабатывания. Для медицинского агента этот слой планируют на этапе архитектуры, а не после запуска.
Полезный ориентир - кейс Included Health с федеративными агентами для навигации по медицине: там видно, какие вопросы вокруг медицинского ассистента остаются открытыми даже в зрелых проектах.
Переносимость паттерна: другие фреймворки и отрасли
Кейс ценен не медицинской спецификой, а схемой переезда.
Почему smolagents - только пример, а не требование
Hugging Face smolagents выбран как референсная реализация, чтобы показать: AgentCore runtime поддерживает любой агентный фреймворк. Это не требование. BYO-подход позволяет развернуть существующий код агента без переписывания и без адаптации под конкретную библиотеку.
Проверить это на другом стеке можно по кейсу AvioBook на Amazon Bedrock AgentCore: другой домен, другая логика, другая схема доступа к данным, а рантайм используется тот же.
Как адаптировать подход под финансы и производство
Паттерн работает и за пределами медицины: финансовый сектор и производство укладываются в ту же схему. Меняются три вещи: набор моделей, источники знаний и требования к контролю. Порядок работы остаётся прежним: обернуть код в декоратор, подготовить pyproject.toml и Dockerfile, задеплоить, проверить.
В финансах обычно добавляется больше требований к аудиту вызовов, на производстве - к связке с промышленными системами. На схему миграции это не влияет.
Чек-лист перед стартом: агент контейнеризован; код можно обернуть в декоратор без переписывания; требования к безопасности и доступу к данным сформулированы; инфраструктурные ограничения проверены.
Итоги: кому подходит миграция на AgentCore runtime
AgentCore runtime снимает инфраструктурную нагрузку: жизненный цикл контейнеров, масштабирование, идентификацию и наблюдаемость закрывает управляемый слой, а команда занимается логикой агента.
Миграция сохраняет возможности агента. Тройная оркестрация моделей, векторный поиск по базе знаний и маршрутизация запросов остаются в коде, который вы уже написали; добавляется обёртка BedrockAgentCoreApp, @app.entrypoint, app.run().
Для продакшена с чувствительными медицинскими запросами демонстрационного примера мало: AWS рекомендует Amazon Bedrock Guardrails, а политики обработки данных и аудита проектируются отдельно.
Решать просто. Если агент уже контейнеризован и вы тратите время на task definitions, auto scaling и сбор логов, миграция того стоит. Если в основе нестандартная сетевая схема или жёсткие требования к окружению, сначала проверьте, покрывает ли их управляемый рантайм. Ошибка обойдётся неделями работы, которые уйдут на откат.