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

Това не е пускане на нов основен модел и не е съобщение за цена. Става въпрос за ВиК смяна. Но за разработчици, работещи агенти, каталози с инструменти, интеграции в стила на протокола за контекст на модела или вътрешни регистри, водопроводните промени често са тези, които първо нарушават производствените скриптове.

AWS казва, че потребителите трябва да актуализират крайни точки, IAM политики, SDK клиенти, CLI скриптове и данни от регистъра като част от преместването. Това прави това истинско миграционно събитие, а не козметично преименуване. Всяка система, която извиква директно старото пространство от имена, дава разрешения срещу него или автоматизира операции в регистъра чрез команден ред или работни потоци на SDK, може да се нуждае от промени, преди да може да работи чисто с новата самоличност на услугата.

Какво се промени в AWS Agent Registry

AWS Agent Registry е документиран като услуга за публичен преглед, свързана с Amazon Bedrock AgentCore. Регистърът има за цел да помогне на екипите да управляват и откриват агенти, включително карти на агенти и свързани метаданни, използвани в екосистемите на агенти. Досега предварителният преглед съществуваше под пространството на имената bedrock-agentcore.

Промяната от 6 август разделя регистъра на пространството от имена на agent-registry. На практика това означава, че интеграциите трябва да спрат да приемат, че регистърът е само подчаст от по-широкото пространство на имената на Bedrock AgentCore. Документацията на AWS извиква няколко области, които изискват внимание: крайни точки на услугата, политики за управление на идентичността и достъпа, SDK клиенти, CLI скриптове и данни от регистъра.

Тези категории покриват повечето от местата, където агентската инфраструктура става лепкава. Крайните точки могат да бъдат вградени в конфигурацията на услугата. Разрешенията за IAM може да се управляват от екипи по сигурността, а не от разработчици на приложения. SDK клиентите могат да бъдат фиксирани във вътрешни библиотеки. CLI скриптовете може да се изпълняват в CI канали или операционни модули. Данните в регистъра може да се нуждаят от миграция или пререгистрация в зависимост от това как даден екип използва услугата за предварителен преглед.

Защо това има значение за инструментите на агента и MCP

Времето е забележително, тъй като инфраструктурата на агентите става все по-официална. Скорошните промени на пазара отблъснаха разработчиците от еднократни демонстрации към управлявани системи: регистри, сървъри с инструменти, отчитане на употребата, контрол на достъпа и одитни пътеки. В този контекст промяна на пространството на имената на регистъра е сигнал, че AWS третира откриването и управлението на агенти като отделна инфраструктурна повърхност.

За екипи, които експериментират с агенти, това може да е малка задача за поддръжка. За компаниите, изграждащи вътрешни платформи около каталози на агенти, работата е по-широка. Обажданията в регистъра може да стоят зад портали за разработчици, системи за преглед на сигурността, слоеве за оркестрация, работни процеси за одобрение или автоматизирани внедрявания. Ако тези системи са изградени по време на периода на предварителен преглед, те може да съдържат допускания, които сега трябва да бъдат преразгледани.

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

Кой е засегнат

Най-пряко засегнатите потребители са разработчици и екипи на платформи, които вече използват AWS Agent Registry по време на публичен преглед. Те трябва да одитират всеки код или инфраструктура, които препращат към bedrock-agentcore за операции в регистъра. Това включва код на приложение, шаблони за инфраструктура като код, IAM политики, CI задания, CLI скриптове, SDK обвивки, локални инструменти за разработчици и документация, използвани от екипите за поддръжка.

Екипите за сигурност и управление на облака също са засегнати. Промените в IAM могат да отнемат повече време от корекциите на приложения, тъй като често изискват преглед, проверки с най-малко привилегии и работни процеси за одобрение. Преместване на пространство от имена може да изисква нови разрешения, актуализирани препратки към услуги и обновени шаблони за правила. Ако организациите имат вътрешни контроли, които блокират по подразбиране пространства от имена на неизвестни услуги, може да се наложи да се добави новото пространство от имена на agent-registry, преди разработчиците да могат да продължат.

Доставчиците на API шлюз и автоматизация имат различен проблем: объркване на клиентите. AWS наскоро също премести Bedrock Agents в „класически“ път за наличност на нови клиенти, насочвайки новата работа към AgentCore. Миграцията на пространството от имена на регистъра на агентите е отделна от по-ранното прекъсване на Bedrock Agents Classic, но и двете събития засягат една и съща широка категория инфраструктура на агенти. Документацията, потоците на включване и отговорите на поддръжката трябва да направят това разграничение ясно.

Практически стъпки за миграция

Екипите трябва да започнат с инвентар. Хранилища за търсене, манифести за внедряване, файлове с политики и CI скриптове за повиквания, свързани с регистъра, под старото пространство на имената на Bedrock AgentCore. След това определете кои препратки са критични за времето на изпълнение и кои са само документация или примери.

След това актуализирайте IAM правилата и ги тествайте в непроизводствен акаунт. Промените в пространството на имена често разкриват твърде широки разрешения или скрити зависимости. Контролиран тест може да покаже дали новите референции на услуги са достатъчни, преди производствените агенти или регистрите да зависят от тях.

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

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

За фирмите, използващи многомоделен API или AI API шлюз, по-големият урок е, че инфраструктурата на агента вече се нуждае от същата дисциплина за управление на промените като моделното маршрутизиране. Шлюз като Model Gate може да не участва пряко в миграцията на AWS Agent Registry, но оперативният модел е познат: повърхностите на API от страна на доставчика се променят и екипите се нуждаят от централизирана конфигурация, видимост на използването, ключови контроли и ясна собственост, за да избегнат разпръснати повреди.

Какво остава несигурно

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

Тъй като AWS Agent Registry е в публичен преглед, екипите също трябва да приемат, че са възможни повече промени в интерфейса. Услугите за визуализация са полезни за ранно приемане, но те изискват по-строги граници на абстракция от зрелите API. Ако операциите в регистъра са разпръснати в много приложения, това е добър момент да ги консолидирате зад вътрешни библиотеки или услуги на платформата, така че следващата промяна да е по-лесна за усвояване.