AWS опубликовала руководство по переносу агентных нагрузок на Amazon Bedrock AgentCore. Материал начинается с LangGraph-агента поддержки клиентов, который классифицирует сообщения, эскалирует недовольных клиентов и отвечает остальным с помощью трех инструментов. Модельные вызовы уже идут через Amazon Bedrock, но, как отмечают авторы, это не дает большого преимущества: инференс — единственная часть, которую миграция не затрагивает.
Amazon Bedrock AgentCore — это платформа для сборки, подключения и оптимизации агентов ИИ в масштабе, работающая с любым фреймворком и моделью. Ее сервисы подключаются по отдельности, и каждый снимает определенные операционные задачи. Всего в руководстве описано десять таких задач, которые не связаны с логикой агента: изоляция сессий пользователей, хранение состояния между ходами и днями, авторизация для каждого инструмента, патчи операционной системы и другие.
| Конструкция LangGraph | Эквивалент в Strands | Функция AgentCore |
|---|---|---|
| build_graph(...), контейнер и веб-сервер | Agent(model=..., system_prompt=..., tools=...), вызываемый Runtime | Runtime: BedrockAgentCoreApp и @app.entrypoint на одной microVM на сессию |
| @tool функции с ToolNode(tools) и llm.bind_tools(tools) | Инструменты из MCPClient.list_tools_sync(), передаваемые в Agent(tools=...) | Gateway: Lambda-функция, опубликованная как MCP-инструменты supportTools___<name> |
| MemorySaver() с thread_id в конфиге invoke | AgentCoreMemorySessionManager(AgentCoreMemoryConfig(...)) | Memory: состояние, ключом которого является actor_id и сессия |
| add_conditional_edges("classify_intent", route_intent) | Нет эквивалента: модельно-управляемое планирование заменяет ветвление | Runtime размещает его без изменений |
Миграция проходит в два этапа. На первом агент переводится на AgentCore Runtime, Gateway и Memory, при этом граф остается неизменным. Runtime берет на себя вычислительные ресурсы: патчи ОС, автомасштабирование и изоляцию сессий перестают быть заботой разработчика. По умолчанию Runtime работает на управляемой инфраструктуре AWS, но его можно подключить к собственному VPC. Gateway управляет авторизацией инструментов и вызывает функции Lambda с собственной ролью выполнения. Memory хранит состояние диалога между сессиями, процессами и днями.
Миграция проходит в два этапа: сначала перенос на AgentCore Runtime, Gateway и Memory без изменения графа, затем переход на модельно-управляемое планирование.
Второй этап перестраивает цикл обработки на модельно-управляемое планирование с помощью Strands Agents. Остановившись после первого этапа, разработчик получает размещенного агента с управляемыми инструментами и устойчивым состоянием. На третьем этапе цикл передается обвязке AgentCore, которая документирована, а не создается с нуля.
Важно, что часть ответственности остается на разработчике на всех этапах: политики IAM, конфигурация VPC, правила WAF и ротация секретов. Обновление зависимостей переносится на третий этап. Три дополнительных сервиса подключаются без замены чего-либо: Identity управляет учетными данными и обновляет токены OAuth для API, которые агент вызывает от чьего-то имени, Policy принимает решения по отдельным вызовам инструментов на Gateway, а Observability отправляет логи, метрики и трейсы Runtime в Amazon CloudWatch без дополнительной настройки.
Руководство подчеркивает: AgentCore ничего не забирает у разработчика. Runtime — это место, где работает агент, а не то, что решает его следующий шаг. Отказ от рукописной ветви — это выбор, который делается на втором этапе. Для тех, кто уже использует LangGraph, миграция затрагивает всего четыре конструкции: граф, инструменты, память и цикл обработки.
