AWS wprowadza zmianę dotyczącą kompatybilności, która ma znaczenie dla zespołów budujących infrastrukturę agentów w oparciu o Amazon Bedrock AgentCore. Zgodnie z dokumentacją AWS, AWS Agent Registry jest obecnie w publicznej wersji zapoznawczej w przestrzeni nazw bedrock-agentcore, ale od 6 sierpnia 2026 r. usługa zostanie przeniesiona do przestrzeni nazw agent-registry.

Nie jest to wprowadzenie na rynek nowego podstawowego modelu ani ogłoszenie cen. Jest to zmiana instalacji wodno-kanalizacyjnej. Jednak w przypadku programistów agentów operacyjnych, katalogów narzędzi, integracji w stylu protokołu Model Context Protocol lub rejestrów wewnętrznych zmiany hydrauliczne są często tymi, które w pierwszej kolejności psują skrypty produkcyjne.

AWS twierdzi, że w ramach tej przeprowadzki użytkownicy muszą zaktualizować punkty końcowe, zasady IAM, klientów SDK, skrypty CLI i dane rejestru. To sprawia, że ​​jest to prawdziwe wydarzenie związane z migracją, a nie kosmetyczna zmiana nazwy. Każdy system, który bezpośrednio wywołuje starą przestrzeń nazw, przyznaje do niej uprawnienia lub automatyzuje operacje rejestru za pomocą wiersza poleceń lub zestawu SDK, może wymagać zmian, zanim będzie mógł poprawnie współpracować z nową tożsamością usługi.

Co się zmieniło w rejestrze agentów AWS

Rejestr agentów AWS jest udokumentowany jako usługa publicznej wersji zapoznawczej powiązana z Amazon Bedrock AgentCore. Rejestr ma pomóc zespołom w zarządzaniu agentami i ich odkrywaniu, w tym kartach agentów i powiązanych metadanych używanych w ekosystemach agentów. Do tej pory podgląd znajdował się w przestrzeni nazw bedrock-agentcore.

Zmiana z 6 sierpnia rozdziela rejestr na przestrzeń nazw agent-registry. W praktyce oznacza to, że należy zaprzestać integracji, zakładając, że rejestr jest jedynie częścią szerszej przestrzeni nazw Bedrock AgentCore. Dokumentacja AWS wymienia kilka obszarów wymagających uwagi: punkty końcowe usług, zasady zarządzania tożsamością i dostępem, klienci SDK, skrypty CLI i dane rejestru.

Te kategorie obejmują większość miejsc, w których infrastruktura agentów staje się niestabilna. Punkty końcowe mogą być osadzone w konfiguracji usługi. Uprawnieniami IAM mogą zarządzać zespoły ds. bezpieczeństwa, a nie twórcy aplikacji. Klienci SDK mogą być przypinani w bibliotekach wewnętrznych. Skrypty CLI mogą działać w potokach CI lub elementach Runbook operacji. Dane rejestru mogą wymagać migracji lub ponownej rejestracji, w zależności od tego, jak zespół korzysta z usługi wersji zapoznawczej.

Dlaczego ma to znaczenie w przypadku agentów i narzędzi MCP

Ten moment jest znaczący, ponieważ infrastruktura agentów staje się coraz bardziej formalna. Ostatnie zmiany na rynku odepchnęły programistów od jednorazowych wersji demonstracyjnych w stronę systemów zarządzanych: rejestrów, serwerów narzędzi, raportowania użytkowania, kontroli dostępu i ścieżek audytu. W tym kontekście zmiana przestrzeni nazw rejestru jest sygnałem, że AWS traktuje wykrywanie agentów i zarządzanie nimi jako odrębną powierzchnię infrastruktury.

W przypadku zespołów eksperymentujących z agentami może to być niewielkie zadanie konserwacyjne. W przypadku firm budujących platformy wewnętrzne wokół katalogów agentów praca jest szersza. Wywołania rejestru mogą znajdować się za portalami dla programistów, systemami kontroli bezpieczeństwa, warstwami orkiestracji, przepływami pracy zatwierdzania lub zautomatyzowanymi wdrożeniami. Jeśli te systemy zostały zbudowane w okresie podglądu, mogą zawierać założenia, które należy teraz ponownie sprawdzić.

Zmiana dotyczy także wdrożeń protokołu Model Context Protocol i innych wzorców współdziałania agentów. Rejestry agentów mogą stać się miejscem, w którym platformy odkrywają, czym jest agent, z jakich narzędzi może korzystać, jakie punkty końcowe udostępnia i jakie obowiązują granice zaufania. Jeśli brama, orkiestrator lub platforma partnerska udostępnia klientom agenty wspierane przez AWS, musi wiedzieć, czy w okresie przejściowym patrzy na starą, nową przestrzeń nazw, czy na obie.

Kogo dotyczy

Użytkownicy, których to dotyczy najbardziej, to programiści i zespoły platformowe korzystające już z rejestru agentów AWS w publicznej wersji zapoznawczej. Powinni przeprowadzić audyt każdego kodu lub infrastruktury odwołującej się do bedrock-agentcore w przypadku operacji na rejestrze. Obejmuje to kod aplikacji, szablony infrastruktury jako kodu, zasady IAM, zadania CI, skrypty CLI, opakowania SDK, narzędzia lokalnych programistów i dokumentację używaną przez zespoły pomocy technicznej.

Dotyczy to również zespołów ds. bezpieczeństwa i zarządzania chmurą. Zmiany uprawnień mogą zająć więcej czasu niż poprawki aplikacji, ponieważ często wymagają przeglądu, kontroli najniższych uprawnień i przepływów pracy zatwierdzania. Przeniesienie przestrzeni nazw może wymagać nowych uprawnień, zaktualizowanych referencji usług i odświeżonych szablonów zasad. Jeśli organizacje mają wewnętrzne mechanizmy kontroli, które domyślnie blokują nieznane przestrzenie nazw usług, konieczne może być dodanie nowej przestrzeni nazw agent-registry, zanim programiści będą mogli kontynuować.

Dostawcy bram API i automatyzacji mają inny problem: dezorientację klientów. Niedawno firma AWS przeniosła także Bedrock Agents na „klasyczną” ścieżkę zapewniającą dostępność dla nowych klientów, kierując nowe prace w stronę AgentCore. Migracja przestrzeni nazw Agent Registry jest odrębna od wcześniejszej migracji Bedrock Agents Classic, ale oba zdarzenia dotyczą tej samej szerokiej kategorii infrastruktury agentów. Dokumentacja, procesy wdrażania i reakcje wsparcia powinny wyraźnie wyjaśniać to rozróżnienie.

Praktyczne etapy migracji

Zespoły powinny zacząć od inwentarza. Przeszukuj repozytoria, manifesty wdrożenia, pliki zasad i skrypty CI pod kątem wywołań związanych z rejestrem w starej przestrzeni nazw Bedrock AgentCore. Następnie określ, które odniesienia są krytyczne dla środowiska wykonawczego, a które stanowią jedynie dokumentację lub przykłady.

Następnie zaktualizuj zasady uprawnień i przetestuj je na koncie innym niż produkcyjne. Zmiany przestrzeni nazw często ujawniają zbyt szerokie uprawnienia lub ukryte zależności. Kontrolowany test może wykazać, czy nowe referencje na usługi są wystarczające, zanim agenci produkcyjni lub rejestry będą od nich zależni.

Wykorzystanie SDK i CLI należy sprawdzić osobno. Niektóre zespoły dzwonią do usług w chmurze za pośrednictwem oficjalnych klientów SDK; inne wykonują polecenia CLI wewnątrz potoków kompilacji. Obie ścieżki mogą zawieść w różny sposób. Klienci SDK mogą potrzebować aktualizacji wersji lub nowych konstruktorów usług. Skrypty CLI mogą wymagać nowych nazw poleceń, flag punktów końcowych lub założeń dotyczących uwierzytelniania.

Dane rejestru zasługują na własny plan migracji. Dokumentacja AWS mówi, że dane rejestru muszą zostać zaktualizowane, ale wpływ operacyjny będzie zależał od tego, w jaki sposób każdy zespół wymodelował agentów, identyfikatory i metadane. Zespoły powinny sprawdzić, czy rekordy agentów, karty agentów, wersje lub odniesienia pozostają stabilne po migracji i czy systemy niższego szczebla przechowują te identyfikatory w pamięci podręcznej.

Dla firm korzystających z wielomodelowego interfejsu API lub bramy AI API najważniejszym wnioskiem jest to, że infrastruktura agentów wymaga teraz tej samej dyscypliny zarządzania zmianami, co routing modeli. Brama taka jak Model Gate może nie być bezpośrednio zaangażowana w migrację rejestru agentów AWS, ale schemat działania jest znany: powierzchnie API po stronie dostawcy zmieniają się, a zespoły potrzebują scentralizowanej konfiguracji, widoczności użycia, kluczowych kontroli i jasnej własności, aby uniknąć rozproszonych awarii.

Co pozostaje niepewne

Dostępne informacje pochodzą z dokumentacji AWS, a nie z osobnego bloga o premierze lub szerszego ogłoszenia. Nie sprawia to, że zmiana jest mniej praktyczna, ale ogranicza kontekst publiczny wokół planu działania AWS dotyczącego rejestru. Dokumentacja potwierdza migrację przestrzeni nazw i kategorie wymaganych aktualizacji; w pobranym materiale nie zawiera szczegółowego wyjaśnienia dotyczącego pozycjonowania na rynku ani niezależnego potwierdzenia z innego źródła AWS.

Ponieważ rejestr agentów AWS jest dostępny w publicznej wersji zapoznawczej, zespoły powinny również założyć, że możliwych jest więcej zmian w interfejsie. Usługi podglądu są przydatne do wczesnego wdrożenia, ale wymagają silniejszych granic abstrakcji niż dojrzałe interfejsy API. Jeśli operacje rejestru są rozproszone po wielu aplikacjach, jest to dobry moment na skonsolidowanie ich za wewnętrznymi bibliotekami lub usługami platformy, aby łatwiej było wchłonąć kolejną zmianę.