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

Amazon Web Services добавила в AgentCore runtime функцию Session endpoints. AgentCore runtime запускает каждую сессию ИИ-агента в собственной изолированной микровиртуальной машине. Раньше всё, что агент поднимал внутри неё, например сайт, снаружи было не видно. Теперь у сессии есть защищённый URL: открываете его в браузере и смотрите, как кодинг-агент собирает веб-приложение. Каждая правка появляется на странице через секунды, ещё до того, как кто-то успел что-то выкладывать на хостинг.

Зачем смотреть на сайт, пока агент пишет код

Кодинг-агенты уже собирают рабочие дашборды, страницы товаров и прототипы. Проверять такую работу проще всего руками: открыть приложение, потыкать, попросить изменить, посмотреть результат. Цикл быстрый, пока приложение крутится там же, где агент редактирует файлы. Если же его надо сначала скопировать и задеплоить в другое место, каждая правка ждёт деплоя, и ревью замедляется до его скорости.

Session endpoints убирают этот шаг. Это не замена продакшен-хостингу: AWS прямо советует отдавать приложение пользователям через сервис вроде AWS Amplify Hosting. Endpoint нужен, чтобы строить, тестировать и принимать то, что сделал агент.

Как устроен демо-стенд

В образце из репозитория agentcore-samples четыре части:

• Кодинг-агент работает в сессии на порту 8080 и правит файлы сайта четырьмя инструментами: list, read, write и edit.
• Dev-сервер Vite слушает порт 8090, отдаёт сайт и по WebSocket сообщает браузеру о каждом сохранённом файле.
• На вашей машине приложение PreviewApp показывает страницу: чат слева, живой сайт справа. Оно отправляет ваши запросы в InvokeAgentRuntime и открывает локальную точку входа для сайта.
• Для решений агент вызывает модель Claude Haiku 5.5 в Amazon Bedrock.

Первый вызов InvokeAgentRuntime запускает сессию, а в заголовке ответа приходит адрес Session endpoint. Дальше всё просто. Вы просите переключить сайт на тёмную кофейную тему. Агент читает src/main.js, src/style.css и index.html, сохраняет стили, и сайт меняется без обновления страницы. Шаги агента стримятся в чат как server-sent events. Следующая просьба, сделать кнопку «Order ahead» зелёной, проходит так же: агент меняет только style.css.

Шесть деталей, которые надо знать при настройке

• Порты выбираете вы. В параметре allowedPorts при создании рантайма указываются от 1 до 5 портов или диапазонов в пределах 8000–12000, без зарезервированных платформенных. Разрешённый порт сам сервер не запускает: приложение должно слушать его на 0.0.0.0.
• URL приходит вместе с сессией, в заголовке X-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url.
• Каждый запрос аутентифицируется. Для рантайма с IAM нужна подпись SigV4 и право bedrock-agentcore:InvokeAgentRuntimeProxy, для рантайма с JWT-авторайзером нужен bearer-токен. Знать адрес недостаточно.
• Порт выбирает префикс в имени хоста, например 8090--<id>.runtime.bedrock-agentcore.<region>.on.aws. Клиент всегда подключается к 443.
• Проходят HTTP/1.1, HTTP/2, server-sent events, gRPC и WebSocket.
• Endpoint привязан к одной сессии и умирает вместе с ней.

Браузер сам не умеет подписывать запросы страницы SigV4. Поэтому SDK bedrock-agentcore открывает на вашей машине локальную точку на localhost:8088, и она добавляет учётные данные к каждому запросу и WebSocket-рукопожатию. Она слушает только 127.0.0.1 и отклоняет WebSocket-соединения со страниц чужих источников.

Отдельно в сессии сидит порт 8081: агент отдаёт на нём маршрут /status со списком запросов и изменённых файлов. Через тот же endpoint меняется только номер порта. Порта 8080 в списке нет намеренно: InvokeAgentRuntime доходит до агента и без Session endpoint.

Что endpoint отвергает и о чём помнить

Отказы рантайма приходят с HTTP-статусом, пустым телом и кодом ошибки в заголовке, поэтому их легко отличить от ошибок вашего приложения:

• порт вне allowedPorts: 403 AccessDenied;
• запрос без валидных учётных данных: 403 AccessDenied или 401 AuthenticationRequired;
• разрешённый порт, где никто не слушает: 502 PortNotReachable;
• URL уже закрытой сессии: 404 SessionNotFound.

Все запросы попадают в AWS CloudTrail как события InvokeAgentRuntimeProxy. Свои заголовки аутентификации рантайм перед пересылкой удаляет, так что сайт подпись не видит.

Ограничения тоже есть. Работает только с microVM-рантаймами, не с типом вычислений Instances. URL доступен по публичному HTTPS, а AWS PrivateLink для входящих соединений не поддерживается. Если рантайм заменит вычислительный узел сессии, соединения закроются, а правки агента могут пропасть без постоянного хранилища. Сайт и агент живут в одной сессии и не разделены правами, поэтому роли исполнения стоит давать только нужные разрешения. Файловые инструменты агента не выходят за папку сайта. Если промпты могут присылать посторонние, AWS советует Amazon Bedrock Guardrails и ручной просмотр изменений перед публикацией.

Образец разворачивается без Docker: агент уходит zip-файлом в Amazon S3 через direct code deployment для Node.js 22. Нужны Python 3.10+, bedrock-agentcore 1.25.2+ и boto3 1.43.122+. После экспериментов запустите cleanup.py, он удалит рантайм, код и IAM-роль.

Для команд, которые строят агентов-разработчиков, это практичный способ сократить цикл «попросил, посмотрел, поправил». Только не оставляйте preview включённым дольше, чем нужно: локальная точка работает с вашими учётными данными.