AWS добавила в Bedrock AgentCore постоянное хранилище сессий и запуск shell-команд
AWS расширила Bedrock AgentCore двумя практичными функциями для coding-агентов: постоянным хранилищем файлов сессии и прямым запуском shell-команд. Теперь агент

AWS показала, как в Amazon Bedrock AgentCore Runtime решить две типичные проблемы агентных сред: потерю файлов после остановки сессии и запуск предсказуемых команд вроде тестов или git-операций через саму модель. Новые возможности позволяют сохранить рабочее состояние агента между перезапусками и выполнять shell-команды прямо внутри его окружения.
Что меняется
До этого сессия агента в AgentCore жила внутри отдельной microVM с изолированными ресурсами, своей памятью и файловой системой. Это хорошо для безопасности, но неудобно для практики: если агент за 20 минут установил зависимости, сгенерировал проект и изменил код, после остановки сессии всё это могло исчезнуть. На следующем запуске приходилось заново скачивать репозиторий, разворачивать окружение и повторять уже сделанную работу.
Для агентных workflow это означает потерю времени и лишние вычислительные расходы. Вторая проблема — детерминированные действия. Когда нужно просто выполнить test suite, линтер или команду git push, нет смысла гонять это через LLM.
Модель добавляет задержку, стоимость по токенам и лишнюю неопределённость там, где команда и так известна заранее. AWS предлагает разделить роли: агент занимается рассуждением и изменением кода, а платформа напрямую исполняет команды в той же сессии. Для production-сценариев такой разнос обязанностей выглядит куда практичнее.
Как это устроено Первая функция — managed session storage, пока в статусе public preview.
При создании runtime можно указать постоянную директорию, например путь внутри каталога /mnt. Всё, что агент пишет в эту папку, сохраняется между stop и resume, даже если сама microVM уже уничтожена и при следующем запуске поднимается новая вычислительная среда. При этом логика сохранения встроена в runtime, так что агенту не нужен отдельный код для checkpoint, сериализации или ручной выгрузки файлов в объектное хранилище.
AWS показывает сценарий, близкий к реальной разработке: в первый день агент скачивает проект, распаковывает его и настраивает зависимости, а на второй день продолжает работать с тем же runtime-session-id. Он видит те же исходники, папку node_modules, build-артефакты и историю .git, без повторной инициализации.
По умолчанию такие данные хранятся 14 дней простоя, а максимальный объём на одну сессию составляет 1 ГБ. Для команд, которые работают с большими кодовыми базами, этого уже достаточно для полноценного многодневного цикла.
Вчерашнее вычислительное окружение уже исчезло, но файловая система сохранилась.
Вторая функция — InvokeAgentRuntimeCommand. Она запускает shell-команды прямо внутри активной сессии AgentCore Runtime и стримит stdout и stderr по мере выполнения. Важная деталь: команда работает не в отдельном sidecar-процессе и не через внешний оркестратор, а в том же контейнере и с той же файловой системой, где работает агент. Если агент записал файл в рабочую папку, команда сразу может его прочитать, протестировать или закоммитить. При этом каждая команда стартует как отдельный bash-процесс: без общей shell-сессии, без переноса history и без сохранения переменных окружения между вызовами.
Где это пригодится
Для инженерных команд эта связка особенно полезна в сценариях, где агент не просто отвечает в чате, а реально ведёт рабочий цикл над кодовой базой. AWS отдельно подчеркивает, что shell-команды лучше использовать там, где результат должен быть строго воспроизводимым и наблюдаемым. Иначе говоря, модель рассуждает и вносит правки, а все предсказуемые шаги проверки и доставки лучше отдавать платформе без лишнего tool-calling через LLM.
- Прогон тестов после правок агента: npm test, pytest и другие проверки Git-операции: создание ветки, commit, push без логики version control внутри LLM Подготовка окружения: клонирование репозитория, установка пакетов, настройка build-инструментов Валидационные ворота: линтеры, type checkers, security scanners перед коммитом Отладка среды: проверка установленных пакетов, диска и процессов при сбоях агента Есть и ограничения. В базовой microVM нет полного набора девелоперских инструментов, поэтому git, npm, языковые рантаймы и другие зависимости нужно добавить в контейнерный образ заранее или установить во время работы. Кроме того, state между командами не сохраняется, так что переход в директорию или export переменных нужно включать прямо в саму команду. Это модель one-shot-выполнения, которая хорошо подходит для тестов и сборок, но не заменяет живую интерактивную shell-сессию.
Что это значит AWS делает
Bedrock AgentCore ближе не к чат-ботам, а к полноценной среде для агентной разработки. Если раньше агент терял контекст на уровне файлов и требовал внешней обвязки для тестов и git-команд, то теперь обе задачи закрываются внутри одного runtime. Для команд, которые строят coding-агентов, это сокращает лишнюю оркестрацию и делает цикл «агент пишет — платформа проверяет — работа сохраняется» заметно практичнее. Особенно там, где важен многодневный процесс работы над одним и тем же репозиторием.