AWS вносит изменения в совместимость, которые важны для команд, создающих инфраструктуру агентов на базе Amazon Bedrock AgentCore. Согласно документации AWS, реестр агентов AWS в настоящее время находится в общедоступной предварительной версии в пространстве имен bedrock-agentcore, но с 6 августа 2026 года сервис перемещается в пространство имен agent-registry.

Это не запуск новой модели тональной основы и не объявление цен. Это замена сантехники. Но для разработчиков операционных агентов, каталогов инструментов, интеграций в стиле Model Context Protocol или внутренних реестров именно сантехнические изменения часто первыми нарушают рабочие сценарии.

AWS заявляет, что в рамках перехода пользователи должны обновить конечные точки, политики IAM, клиенты SDK, сценарии CLI и данные реестра. Это делает это настоящим событием миграции, а не косметическим переименованием. Любая система, которая напрямую вызывает старое пространство имен, предоставляет ему разрешения или автоматизирует операции с реестром с помощью командной строки или рабочих процессов SDK, может нуждаться в изменениях, прежде чем она сможет корректно работать с новым удостоверением службы.

Что изменилось в реестре агентов AWS

Реестр агентов AWS документирован как сервис общедоступной предварительной версии, связанный с Amazon Bedrock AgentCore. Реестр призван помочь командам управлять агентами и обнаруживать их, включая карточки агентов и соответствующие метаданные, используемые в экосистемах агентов. До сих пор предварительная версия находилась в пространстве имен bedrock-agentcore.

Изменение от 6 августа разделяет реестр на пространство имен agent-registry. На практике это означает, что при интеграции следует отказаться от предположения, что реестр является лишь частью более широкого пространства имен Bedrock AgentCore. В документации AWS указано несколько областей, требующих внимания: конечные точки сервисов, политики управления идентификацией и доступом, клиенты SDK, сценарии CLI и данные реестра.

Эти категории охватывают большинство мест, где инфраструктура агентов становится нестабильной. Конечные точки могут быть встроены в конфигурацию службы. Разрешениями IAM могут управлять группы безопасности, а не разработчики приложений. Клиенты SDK могут быть закреплены во внутренних библиотеках. Сценарии CLI могут выполняться в конвейерах CI или в модулях Runbook операций. Данные реестра могут потребовать переноса или повторной регистрации в зависимости от того, как команда использует службу предварительной версии.

Почему это важно для инструментов агента и MCP

Этот момент примечателен тем, что агентская инфраструктура становится более формальной. Недавние изменения на рынке подтолкнули разработчиков от одноразовых демонстраций к управляемым системам: реестрам, серверам инструментов, отчетам об использовании, средствам контроля доступа и журналам аудита. В этом контексте изменение пространства имен реестра является сигналом о том, что AWS рассматривает обнаружение агентов и управление ими как отдельную поверхность инфраструктуры.

Для команд, экспериментирующих с агентами, это может оказаться небольшой задачей по обслуживанию. Для компаний, создающих внутренние платформы вокруг каталогов агентов, работа шире. Вызовы реестра могут осуществляться за порталами разработчиков, системами проверки безопасности, уровнями оркестрации, рабочими процессами утверждения или автоматическими развертываниями. Если эти системы были созданы в период предварительного просмотра, они могут содержать предположения, которые теперь необходимо пересмотреть.

Это изменение также актуально для развертываний протокола контекста модели и других шаблонов взаимодействия агентов. Реестры агентов могут стать местом, где платформы узнают, что такое агент, какие инструменты он может использовать, какие конечные точки он предоставляет и какие границы доверия применяются. Если шлюз, оркестратор или партнерская платформа предоставляют клиентам агенты, поддерживаемые AWS, ему необходимо знать, просматривает ли он старое пространство имен, новое пространство имен или оба в течение переходного периода.

Кто пострадал

Наиболее непосредственно затронутыми пользователями являются разработчики и команды платформ, которые уже используют реестр агентов AWS во время общедоступной предварительной версии. Им следует проверять любой код или инфраструктуру, которая ссылается на bedrock-agentcore, на предмет операций реестра. Сюда входит код приложения, шаблоны «инфраструктура как код», политики IAM, задания CI, сценарии CLI, оболочки SDK, инструменты локального разработчика и документация, используемая группами поддержки.

Это также затронет группы безопасности и управления облаком. Изменения IAM могут занять больше времени, чем исправления приложений, поскольку они часто требуют проверки, проверок с минимальными привилегиями и рабочих процессов утверждения. Для перемещения пространства имен могут потребоваться новые разрешения, обновленные ссылки на службы и обновленные шаблоны политик. Если в организациях есть внутренние элементы управления, которые по умолчанию блокируют неизвестные пространства имен служб, возможно, потребуется добавить новое пространство имен agent-registry, прежде чем разработчики смогут продолжить работу.

У поставщиков API-шлюзов и средств автоматизации другая проблема: путаница клиентов. Недавно AWS также перевела агенты Bedrock Agent на «классический» путь для доступности новых клиентов, направляя новую работу в сторону AgentCore. Миграция пространства имен реестра агентов отличается от предыдущего отключения Bedrock Agents Classic, но оба события затрагивают одну и ту же широкую категорию инфраструктуры агентов. Документация, процедуры адаптации и ответы службы поддержки должны четко указывать это различие.

Практические шаги по миграции

Командам следует начать с инвентаризации. Выполняйте поиск в репозиториях, манифестах развертывания, файлах политики и сценариях CI для вызовов, связанных с реестром, в старом пространстве имен Bedrock AgentCore. Затем определите, какие ссылки критически важны для времени выполнения, а какие являются лишь документацией или примерами.

Затем обновите политики IAM и протестируйте их в нерабочем аккаунте. Изменения пространства имен часто выявляют слишком широкие разрешения или скрытые зависимости. Контролируемый тест может показать, достаточны ли новые ссылки на службы, прежде чем от них начнут зависеть производственные агенты или реестры.

Использование SDK и CLI следует проверять отдельно. Некоторые команды вызывают облачные сервисы через официальные клиенты SDK; другие используют команды CLI внутри конвейеров сборки. Оба пути могут потерпеть неудачу по-разному. Клиентам SDK могут потребоваться обновления версий или новые конструкторы служб. Сценариям CLI могут потребоваться новые имена команд, флаги конечных точек или предположения аутентификации.

Данные реестра заслуживают отдельного плана миграции. В документации AWS говорится, что данные реестра необходимо обновлять, но операционный эффект будет зависеть от того, как каждая команда смоделировала агентов, идентификаторы и метаданные. Команды должны проверить, остаются ли записи агентов, карточки агентов, версии или ссылки стабильными после миграции, а также кэшируют ли последующие системы эти идентификаторы.

Для компаний, использующих многомодельный API или шлюз AI API, главный урок заключается в том, что инфраструктура агентов теперь требует той же дисциплины управления изменениями, что и маршрутизация модели. Такой шлюз, как Model Gate, возможно, не участвует напрямую в миграции реестра агентов AWS, но схема работы знакома: поверхности API на стороне поставщика меняются, и командам необходима централизованная настройка, видимость использования, ключевые элементы управления и четкое право собственности, чтобы избежать разрозненных сбоев.

Что остается неясным

Доступная информация взята из документации AWS, а не из отдельного блога о запуске или более широкого объявления. Это не делает изменение менее действенным, но ограничивает общественный контекст вокруг дорожной карты AWS для реестра. Документация подтверждает миграцию пространства имен и категории необходимых обновлений; в полученных материалах он не содержит подробного объяснения позиционирования на рынке или независимого подтверждения из другого источника AWS.

Поскольку реестр агентов AWS находится в общедоступной предварительной версии, команды также должны предполагать, что возможны дополнительные изменения интерфейса. Сервисы предварительной версии полезны для раннего внедрения, но они требуют более строгих границ абстракции, чем зрелые API. Если операции с реестром разбросаны по многим приложениям, сейчас хороший момент объединить их во внутренних библиотеках или службах платформы, чтобы было легче принять следующие изменения.