AWS подробно описывает путь миграции AgentCore по мере переноса агентных нагрузок в продакшн

AWS объясняет, как команды могут переводить экспериментальных агентов в продакшн с помощью Amazon Bedrock AgentCore, используя две публикации Machine Learning Blog, чтобы показать как поэтапный путь миграции, так и уже работающий в продакшне корпоративный рабочий процесс.

В первом руководстве агент поддержки клиентов LangGraph переносится на AgentCore Runtime, Gateway и Memory, а затем при желании его цикл планирования пересобирается с помощью Strands Agents. Во втором описывается автоматизированный конвейер документирования архитектуры для глобального междилерского брокера, который анализирует код .NET, генерирует диаграммы и публикует доступную для поиска документацию через Amazon Bedrock Knowledge Bases и AWS CodePipeline.

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

Поэтапный путь AWS от прототипа к размещённому агенту

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

На первом этапе граф агента остаётся без изменений. AgentCore Runtime размещает процесс, Gateway обрабатывает выбранные подключения к инструментам, а Memory хранит состояние беседы между ходами, процессами и днями. AWS говорит, что этот этап снимает несколько операционных задач, не меняя того, как агент принимает решения.

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

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

Операционные задачи, на которые нацелен AgentCore

AWS соотносит сервисы AgentCore с работой, которая обычно накапливается вокруг производственных агентов. Runtime берёт на себя управляемые вычисления, изоляцию сессий и масштабирование на инфраструктуре AWS. Команды могут подключить runtime к виртуальному частному облаку, хотя AWS отмечает, что проектирование сети, защита на границе, авторизация, политики IAM, правила веб-application firewall и ротация секретов остаются ответственностью клиента.

Gateway управляет доступом к инструментам и вызывает целевые сервисы, такие как AWS Lambda, под своей собственной ролью выполнения. В примере из руководства вызовы подписываются учётными данными AWS IAM, а не сторонними токенами. AgentCore также включает идентификационную возможность для посредничества в получении учётных данных и обновления OAuth access tokens, когда агенту нужно вызвать API от имени пользователя, хотя эта возможность в walkthrough не задействуется.

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

Наблюдаемость — ещё одна область, которую AWS выделяет. Логи, метрики и трассировки Runtime отправляются в Amazon CloudWatch без необходимости настраивать базовый конвейер. Однако руководство не утверждает, что AgentCore устраняет все операции. Управление зависимостями остаётся обязанностью клиента до более позднего этапа harness, а управляемая AWS инфраструктура не устраняет необходимость в решениях по безопасности на уровне приложения.

Пример продакшн-использования за пределами клиентской поддержки

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

Рабочий процесс начинается, когда изменения кода попадают в репозиторий AWS CodeCommit. AWS CodeBuild извлекает код .NET, упаковывает его и вызывает агента Strands, размещённого на AgentCore. Агент фокусируется на production-коде, исключая тесты, артефакты сборки и сгенерированные файлы, после чего анализирует интерфейсы, абстрактные классы, реализации и зависимости.

Агент генерирует синтаксис диаграмм Mermaid, проверяет диаграммы, преобразует их в SVG и может повторять цикл при возникновении ошибок валидации. Полученные SVG-файлы, исходный код Mermaid и метаданные сохраняются в Amazon S3. Затем Amazon Bedrock Knowledge Bases загружает эти артефакты, используя Amazon Titan Text Embeddings v2 для поддержки семантического поиска и retrieval-augmented generation.

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

Доказательства, заявления и ограничения

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

Публикация о миграции даёт необычно конкретные детали реализации. AWS сообщает, что в её зафиксированном примере внутри агента было изменено 45 строк, добавлено 22 строки вспомогательного кода и 85 строк остались без изменений. Эти цифры относятся только к данному примеру; их не следует воспринимать как общую оценку миграции для производственных систем с другими моделями состояния, инструментами, средствами безопасности или схемами сети.

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

Технические требования также существенны. В walkthrough нужен аккаунт AWS с доступом к моделям Amazon Bedrock, Python 3.12, учётные данные AWS CLI, способные создавать ресурсы AgentCore, Lambda, Amazon S3 и IAM, а также включённый CloudWatch Transaction Search для просмотра трассировок. Эти требования чётко помещают миграцию в рамки AWS по безопасности, разрешениям и региональной доступности моделей.

Что AgentCore означает для разработчиков и предприятий

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

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

Корпоративным покупателям следует сосредоточиться на границах, которые AgentCore оставляет на месте. IAM, конфигурация VPC, правила WAF, секреты и политики авторизации по-прежнему требуют проектирования и управления. Amazon Bedrock Guardrails, по словам AWS, может фильтровать вредоносный контент, проверять обоснование по исходным документам и блокировать попытки prompt injection, но эти меры не заменяют тестирование приложений или специфичные для рабочего процесса правила утверждения.

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

На что смотреть дальше

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

Командам также стоит следить за тем, как AgentCore интегрируется с провайдерами моделей не из AWS, внешними системами идентификации и существующими стеками наблюдаемости. В руководстве говорится, что платформа поддерживает любой фреймворк или модель, но продемонстрированный путь сильно опирается на сервисы AWS, IAM, Lambda, CloudWatch, S3 и Bedrock.

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

Взгляд Creati.ai

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

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