AWS открыла предпросмотр сайтов в AgentCore
30 октября AWS опубликовала описание предпросмотра веб-приложения, которое coding-агент меняет прямо во время своей сессии в Amazon Bedrock AgentCore. Session endpoint дает браузеру авторизованный доступ к разрешенным портам внутри изолированной microVM. В демонстрационном сценарии агент редактирует файлы Vite-сайта, а разработчик видит результат в соседней панели без повторной публикации приложения. В статье отдельно описаны ограничения по портам, аутентификация и срок жизни URL. Это инструмент для просмотра работы агента в сессии, не публичный production-хостинг.
Что изменилось
Просмотр связывает работу агента с реальным интерфейсом
Обычный кодовый агент может показать diff или текстовое описание, но человеку приходится отдельно запускать страницу, чтобы оценить расположение элементов и поведение. В примере AWS рядом открыты чат с агентом и окно сайта; когда агент сохраняет измененный файл, веб-сервер разработки передает обновление браузеру по WebSocket. Это уменьшает цикл обратной связи для дизайна и прототипов. Важно, что такой предпросмотр демонстрирует приложение в рабочей сессии, а не проверяет автоматически безопасность, доступность или функциональную корректность результата.
Session endpoint доступен через выбранные порты
Владелец runtime заранее задает allowedPorts, к которым endpoint может проксировать HTTP, HTTP/2 или WebSocket запросы. Само разрешение порта не запускает сервер: приложение должно слушать его внутри сессии. AWS описывает адрес, полученный из ответа вызова runtime, и отдельный клиентский способ подписывать запросы. Для IAM-сценария применяется SigV4; для режима с JWT запросы несут bearer-токен. Знание URL не открывает доступ без правильной аутентификации.
Адрес ограничен сессией и не предназначен для публикации пользователям
AWS подчеркивает, что Session endpoint живет только пока существует сессия и требует учетные данные при каждом запросе. Когда команда завершает работу агента, адрес перестает быть рабочей точкой доступа. Для предоставления сайта пользователям компания указывает на обычный сервис размещения, например AWS Amplify Hosting. Значит, endpoint служит для разработческого просмотра и проверки, а не заменяет релизный конвейер, домен, мониторинг и эксплуатационные меры.
Доступ к приложению и самому агенту нужно разделять
В демонстрации coding agent и сервер сайта работают внутри одной сессии, но достигаются через разные механизмы. Runtime endpoint вызывает агента, а Session endpoint направляет браузер к выбранным портам приложения. Такое разделение упрощает сценарий предпросмотра, однако роли и разрешения нужно проектировать внимательно: обе части могут зависеть от полномочий runtime. Статья отмечает, что не следует давать агенту больше прав, чем требуется для работы, и что изменения стоит проверять до публикации.
Что это дает пользователю
Разработчику прототипов механизм позволяет быстрее проверять визуальные изменения в браузере без отдельной публикации каждой версии. Это особенно полезно, когда задача агента включает несколько последовательных правок и специалист оценивает каждую итерацию.
Команде платформы важно контролировать список портов и то, какие приложения на них слушают. Сессионный предпросмотр полезно рассматривать как временную разработческую поверхность с правами, журналами и сроком жизни, а не как универсальный публичный адрес.
Публикация полезна как архитектурный пример: она объясняет, что URL авторизован, доступ ограничен портами и прекращается вместе с сессией. Это конкретные свойства, которые нужно учитывать при построении аналогичных workflow в корпоративной среде.
Перед внутренним пилотом зафиксируйте разрешенные порты, владельца runtime, срок существования сессии и допустимый тип тестовых данных. Проверьте отказ для неподписанного запроса, порта вне списка и уже закрытой сессии, а также журналы вызовов через CloudTrail. Разделите право агента редактировать проект и право пользователя публиковать его. Предпросмотр ускоряет обратную связь, но эти границы помогают не превратить временную среду разработки в незаметный канал выкладки.
В демонстрационном сценарии локальный клиент помогает браузеру добавлять подпись к запросам, потому что сам обычный браузер не формирует SigV4. Для собственной архитектуры это дополнительный компонент, которому нужно назначить адрес прослушивания и ограничить локальное использование. Команда должна оценить срок жизни сессии, очистку файлов, закрытие процессов и возможную стоимость оставленных ресурсов. При просмотре прототипа используйте тестовые данные, если сессия или журналы не предназначены для конфиденциальной информации.
Что нужно учитывать
Описание и пример опубликованы AWS и основаны на ее сервисе и образце кода. Это не независимая оценка надежности для всех архитектур.
Session endpoint не заменяет размещение production-приложения, управление релизом и пользовательскую аутентификацию самого сайта.
Образец требует корректных ролей, IAM-разрешений, разрешенных портов и безопасного обращения с кодом и данными внутри runtime.
Коротко
Нововведение AWS нацелено на короткий цикл разработки: агент редактирует сайт в своей сессии, а человек наблюдает изменения сразу в браузере. Практическая ценность здесь в контролируемом предпросмотре, который авторизуется, ограничивается разрешенными портами и исчезает вместе с сессией. Эти свойства отличают его от публикации сайта. Командам стоит оценивать endpoint как временную среду проверки и отдельно решать вопрос безопасного деплоя. Перед использованием проверьте IAM-права, содержимое runtime и границы между инструментами агента и доступными портами приложения.