AWS предложила переносить LangGraph-агента в production без переписывания логики

Миграция начинается не с нового агента

AWS показала поэтапный перенос LangGraph-агента поддержки в Amazon Bedrock AgentCore. Исходная система определяет намерение клиента, отдельно эскалирует недовольного пользователя и вызывает три инструмента для поиска заказа, возврата и ответа по базе знаний. Модель уже работает через Amazon Bedrock, но контейнер, web server и состояние диалога остаются обязанностью команды. Именно эти эксплуатационные границы меняются первыми.

На первом этапе исходный `StateGraph`, router, prompts и тела инструментов импортируются без изменения. Runtime принимает процесс и изоляцию сессий, Gateway публикует два общих инструмента как MCP tools, а Memory заменяет внутрипроцессный `MemorySaver`. Лишь на втором этапе ручное ветвление можно заменить model-driven planning в Strands Agents. AWS подчёркивает: Runtime размещает reasoning loop, но не диктует, как агент выбирает следующий шаг.

Stage 1 отделяет инфраструктурный риск от поведенческого

Порядок выбран так, чтобы менять одну переменную за раз. Перед миграцией команда записывает baseline: какие tools были вызваны и какое финальное сообщение осталось в состоянии графа. Затем LangGraph оборачивается в `BedrockAgentCoreApp`, а идентификатор сессии приходит из `RequestContext`. По расчёту авторов примера, внутри агента меняются 45 строк, добавляются 22 строки адаптера и импортируются без правок 85 строк существующей логики.

Runtime запускает одну microVM на сессию и снимает с команды patching операционной системы, autoscaling и базовую session isolation. Но сеть, edge protection и authorization по-прежнему нужно проектировать владельцу приложения. AWS IAM policies, VPC configuration, WAF rules и rotation секретов не исчезают ни на одном из показанных этапов.

Не каждый инструмент нужно превращать в удалённый сервис

В примере `lookup_order` и `process_return` выносятся в Lambda и регистрируются в AgentCore Gateway, потому что им нужна общая authentication boundary и потенциальное повторное использование другими агентами. Gateway вызывает функцию под собственной execution role, а агент подписывает MCP-запросы через SigV4. Имена опубликованных tools получают префикс target, поэтому адаптер сопоставляет их с прежними локальными именами.

`search_faq` остаётся обычной Python-функцией. AWS называет это нормальным выбором: если tool не нужен другим агентам и не требует отдельной policy gate, удалённый вызов добавит сложность без очевидной пользы. Такая выборочность защищает архитектуру от механического превращения каждого helper в сетевой микросервис.

Durable memory — отдельная часть, а не побочный эффект hosting

Исходный `MemorySaver` хранит checkpoints в словаре процесса: при рестарте история исчезает, а второй replica её не видит. AgentCore Memory переносит состояние в управляемое хранилище и ключует его по `actor_id` и session. Срок `event_expiry_days` задаётся явно. First-party checkpointer получает идентификаторы на каждом вызове через `RunnableConfig`, поэтому один экземпляр приложения может обслуживать разных пользователей, не смешивая контекст.

На втором этапе Strands agent получает те же Gateway tools и session manager, но сам планирует их последовательность. Ручная ветка `classify_intent → route_intent` исчезает. Это функциональное изменение, а не обязательная часть hosting, поэтому его проверяют только после подтверждения инфраструктурного переноса. Stage 3 с AgentCore harness в публикации описан, но не реализован в sample repository — его нельзя считать готовой демонстрацией.

Что migration не решает

AgentCore уменьшает объём операционной работы, но не превращает proof of concept в безопасный продукт автоматически. AWS отдельно требует Guardrails для фильтрации вредного контента, проверки grounding и защиты от prompt injection. Identity может выдавать и обновлять OAuth credentials для внешних API, Policy — контролировать отдельные tool calls, Observability — отправлять traces и metrics в CloudWatch; walkthrough не демонстрирует все эти возможности как завершённую систему.

Сильная сторона подхода — обратимость. Команда может остановиться после Stage 1 и получить hosted LangGraph с управляемыми инструментами и долговременным состоянием, не отдавая модели маршрутизацию. Это полезный шаблон для любой миграции агента: сначала зафиксировать поведение, затем вынести compute, credentials и state, и только после этого обсуждать изменение reasoning loop.