Bedrock AgentCore: как устроен и когда нужен вашим ИИ-агентам

Amazon Bedrock AgentCore стоит попробовать в пилотном проекте, когда сам агент уже работает, а инфраструктура вокруг него превращается в отдельный продукт. Сейчас AWS перечисляет 13 модульных сервисов и возможностей. Подключайте те, что берут на себя конкретную работу по эксплуатации, а ответственность за поведение агента в бизнес-процессах оставляйте за собой.

Материал сверен с актуальной страницей продукта AWS и документацией 30 октября 2026 года. Список компонентов ниже взят из обзора для разработчиков, на который ссылается страница AgentCore. Какие собственные решения могут заменить эти компоненты — инженерная оценка автора статьи.

Что такое Amazon Bedrock AgentCore?

AgentCore позволяет передать AWS отдельные задачи, связанные с эксплуатацией агентов в продакшене. Агент — это программа, которая с помощью модели выбирает действия, вызывает инструменты и продвигается к выполнению задачи. Даже если этот цикл уже работает локально, остаются вопросы идентификации, выполнения, состояния, контроля доступа и отладки.

Представьте концертный зал. Поведение агента — само выступление. Runtime предоставляет сцену и обслуживающую инфраструктуру; контроль доступа определяет, кому открыты двери; память сохраняет полезный контекст; средства наблюдаемости фиксируют происходящее. При этом цель выступления и критерии его успеха по-прежнему определяете вы.

AWS прямо заявляет, что AgentCore поддерживает «Любой фреймворк. Любую модель». На странице продукта перечислены LangChain, OpenAI Agents SDK, Claude Agent SDK, Strands SDK, а также возможность использовать собственный фреймворк. Так AWS описывает область применения платформы. Это не означает, что у всех дополнительных возможностей одинаковые интеграции или что миграция не потребует усилий. Обзор продукта AWS.

Отдельный выбор — кто управляет циклом работы агента. В Runtime вы развертываете собственный код агента. В Harness описываете агента в конфигурации и используете управляемый цикл AWS на базе Strands Agents — открытого фреймворка AWS для агентов. Это различие прямо описано в документации Harness. Если у команды уже есть работающий код оркестрации, техническому руководителю стоит сначала рассмотреть Runtime.

Чем Bedrock Agents отличается от AgentCore?

Появление AgentCore само по себе не повод переносить существующее приложение с Amazon Bedrock Agents. AWS подтверждает, что нынешние пользователи Bedrock Agents могут продолжать работу с ним. Изучать AgentCore имеет смысл под конкретные требования к выполнению, интеграциям или эксплуатации. Ответы AWS на частые вопросы.

Противопоставления «управляемый цикл или инфраструктура» теперь недостаточно: у AgentCore тоже есть управляемый цикл — Harness. Сначала решите, хотите ли вы отвечать за код оркестрации, затем выбирайте подходящий вариант. Держите под рукой обзор архитектуры ИИ-агентов, чтобы выбор хостинга не обернулся незапланированной переделкой всего приложения.

Компоненты Bedrock AgentCore: какую работу они берут на себя

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

Ассистенту службы поддержки могут сразу понадобиться Runtime, Gateway и Identity, а позже — Memory, когда появится польза от контекста предыдущих обращений клиента. Payments не нужен, если ассистент никогда не покупает доступ к внешним ресурсам. Registry пригодится, когда сотрудникам станет трудно находить одобренные ресурсы внутри организации. Подключить как можно больше компонентов — не цель внедрения.

Code Interpreter и Runtime решают разные задачи. Runtime размещает самого агента, а Code Interpreter предоставляет песочницу для кода, который тот запускает. Если вам не хватает только изолированного выполнения кода, сначала сопоставьте варианты в руководстве по песочницам для кода ИИ-агентов, а уже потом решайте, переносить ли оркестрацию.

Архитектура ИИ-агентов: какие решения остаются за вами

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

Bedrock AgentCore Runtime: изоляция не определяет владельца сессии

Runtime может изолировать выполнение, не зная, какому клиенту принадлежит сессия. В документации AWS описаны выделенные среды microVM для сессий, в которых разделены вычислительные ресурсы, память и файловая система. Там же прямо сказано: AgentCore не контролирует соответствие сессий пользователям. Эту связь должен поддерживать бэкенд вашего приложения. Сессии Runtime.

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

Bedrock AgentCore Memory: сохраняйте контекст осознанно

Memory берет на себя инфраструктуру управления контекстом, а его содержимое определяете вы. AWS поддерживает краткосрочный контекст беседы и долгосрочную информацию, которая сохраняется между сессиями. Документация Memory.

Запомнить, что клиент предпочитает краткие ответы, — одно; считать память агента достоверным источником остатка к оплате по заказу — другое. Источником достоверных бизнес-данных должно оставаться ваше приложение. Определите, как агент получает актуальные записи, какие сведения из разговора может сохранять и что делать, когда запомненное предпочтение перестает быть верным. Сервис памяти не принимает эти решения за вас.

Bedrock AgentCore и MCP: Gateway связывает агента с инструментами

Gateway полезен, когда подключение инструментов превратилось в повторяющуюся инженерную работу. Model Context Protocol, или MCP, — общий интерфейс, через который инструменты становятся доступны агентам. Gateway может превращать API и функции AWS Lambda в инструменты, совместимые с MCP, и подключаться к существующим MCP-серверам. В актуальной документации также описана маршрутизация к другим агентам и моделям. Документация Gateway.

Для ассистента по заказам сначала откройте узкую операцию — например, проверку статуса доставки, — а не универсальный инструмент запросов к базе данных. Gateway передаст вызов, но именно ваш API определяет смысл операции, доступные ей записи и то, не приведет ли повторный вызов к повторному побочному эффекту.

Bedrock AgentCore Identity: учетным данным нужны бизнес-правила

Identity отвечает за идентификацию действующей стороны и ее учетные данные; Policy — за допустимые действия на шлюзе. Identity предоставляет идентификацию программных компонентов и управление учетными данными для доступа к ресурсам AWS и сторонним сервисам, в том числе от имени пользователя. Документация Identity.

Прежде чем разрешить доступ к инструменту, Policy проверяет трафик, проходящий через связанный с ней AgentCore Gateway. Эта граница принципиальна: политика шлюза не обязательно распространяется на независимый прямой сетевой вызов, который может выполнить агент. Направляйте чувствительные операции через предусмотренную точку контроля и ограничивайте обходные пути. Документация Policy.

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

Bedrock AgentCore Observability: трассировка показывает ход работы, но не доказывает успех

Observability помогает восстановить ход работы агента, а Evaluations — оценить результат. AgentCore предоставляет средства просмотра выполнения и телеметрию, совместимую с OpenTelemetry — стандартным форматом трассировок и метрик, — а также панели мониторинга на базе Amazon CloudWatch. AWS разделяет встроенные метрики и дополнительные трассировки и бизнес-метаданные, сбор которых вы настраиваете в приложении. Документация Observability.

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

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

Какие ограничения влияют на архитектуру

Разделяйте время жизни вычислительных ресурсов и время, в течение которого нужно сохранять состояние. Согласно актуальной документации AWS о жизненном цикле, тайм-аут простоя по умолчанию составляет 15 минут, а максимальное время жизни вычислительной среды microVM — 8 часов. Альтернативный вариант, Instances, использует управляемые ресурсы Amazon Elastic Compute Cloud в вашем аккаунте и позволяет настроить время жизни до 14 дней с учетом параметров поставщика вычислительных ресурсов. Настройки жизненного цикла, Instances.

Логическая сессия может возобновиться на заново выделенных вычислительных ресурсах. По умолчанию состояние в оперативной памяти и локальной файловой системе живет столько же, сколько вычислительная среда. Настроенное хранилище сессий может сохранять данные файловой системы между остановкой и возобновлением. Заранее определите, что должно пережить прерывание. Жизненный цикл и хранилище сессий.

Прежде чем окончательно выбирать набор возможностей, проверьте таблицу их доступности по регионам AWS. Формулировки «доступно в AWS» недостаточно, если приложение привязано к конкретному региону.

Когда имеет смысл внедрять AgentCore

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

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

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

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

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

Если решение зависит от затрат, изучите тарифы AWS на AgentCore вместе с нашим разбором стоимости Amazon Bedrock.

Первый пилот через CLI от AWS

Начните с шаблона AWS, в котором агент задается кодом, а затем добавьте одну типичную бизнес-операцию. Этот порядок основан на актуальной инструкции по быстрому запуску Runtime и полном руководстве по CLI. Он взят из документации; развертывание по нему для этой статьи не тестировалось.

Полное руководство требует Node.js 20.12 или новее, npm, Python 3.10 или новее, менеджер зависимостей Python uv, настроенные учетные данные AWS, права на развертывание и доступ к моделям. Шаблон использует CodeZip, поэтому Docker не нужен.

1. 1

   Установите CLI и создайте проект

   Используйте аккаунт или среду AWS для разработки.

   npm install -g @aws/agentcore
   agentcore --version
   agentcore create --name MyProject --template agent-python-strands

   В шаблон входят Runtime с именем agent и ресурс AgentCore Memory. Проверьте оба в сгенерированной конфигурации.

2. 2

   Проверьте работу локально

   cd MyProject
   agentcore dev --mode browser

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

3. 3

   Соберите, разверните и вызовите агента

   agentcore build
   agentcore deploy
   agentcore status
   agentcore invoke --runtime agent --payload '{"prompt":"Hello, what can you do?"}'

   При развертывании ресурсы AWS создаются через AWS Cloud Development Kit, или CDK.

4. 4

   Изучите работу и удалите ресурсы

   agentcore logs runtime
   agentcore traces runtime list

   В каталоге этого пилотного проекта следующие команды удаляют его ресурсы и развернутый стек:

   agentcore remove all --yes
   agentcore deploy --yes

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

Какие ожидания от AgentCore завышены

Управляемая среда выполнения не гарантирует, что агент принимает верные бизнес-решения. Хостинг, трассировка, оценка и применение политик решают разные задачи. Ни один из этих механизмов не освобождает вас от выбора полезной задачи, определения допустимых действий и разбора ошибок.

«Любой фреймворк» также не означает «никаких работ по интеграции». При всей гибкости платформы вам нужно проверить зависимости, аутентификацию, инструментирование и контракты каждого подключаемого сервиса.

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

С чего начать в понедельник

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

Практические руководства по созданию и эксплуатации ИИ-систем — в нашей рассылке.