AWS izvaja spremembo združljivosti, ki je pomembna za ekipe, ki gradijo agentsko infrastrukturo na vrhu Amazon Bedrock AgentCore. Glede na dokumentacijo AWS je AWS Agent Registry trenutno v javnem predogledu pod imenskim prostorom bedrock-agentcore, vendar se od 6. avgusta 2026 storitev premakne v imenski prostor agent-registry.

To ni predstavitev novega osnovnega modela in ni obvestilo o cenah. Gre za menjavo vodovoda. Toda za razvijalce, operativne agente, kataloge orodij, integracije v slogu protokola kontekstnega modela ali notranje registre, so vodovodne spremembe pogosto tiste, ki najprej pokvarijo produkcijske skripte.

AWS pravi, da morajo uporabniki kot del selitve posodobiti končne točke, pravilnike IAM, odjemalce SDK, skripte CLI in podatke registra. Zaradi tega gre za pravi selitveni dogodek in ne za kozmetično preimenovanje. Vsak sistem, ki neposredno pokliče stari imenski prostor, dodeli dovoljenja zanj ali avtomatizira operacije registra prek ukazne vrstice ali delovnih tokov SDK, bo morda potreboval spremembe, preden bo lahko deloval čisto z novo identiteto storitve.

Kaj se je spremenilo v registru agentov AWS

AWS Agent Registry je dokumentiran kot storitev javnega predogleda, povezana z Amazon Bedrock AgentCore. Register je namenjen pomoči ekipam pri upravljanju in odkrivanju agentov, vključno s karticami agentov in povezanimi metapodatki, ki se uporabljajo v ekosistemih agentov. Do zdaj je bil predogled v imenskem prostoru bedrock-agentcore.

Sprememba z dne 6. avgusta loči register v imenski prostor agent-registry. Praktično to pomeni, da bi morale integracije prenehati predvidevati, da je register le poddel širšega imenskega prostora Bedrock AgentCore. Dokumentacija AWS opozarja na več področij, ki zahtevajo pozornost: končne točke storitve, pravilniki o upravljanju identitete in dostopa, odjemalci SDK, skripti CLI in podatki registra.

Te kategorije pokrivajo večino mest, kjer infrastruktura agentov postane lepljiva. Končne točke so lahko vdelane v konfiguracijo storitve. Dovoljenja IAM morda upravljajo varnostne ekipe in ne razvijalci aplikacij. Odjemalci SDK so lahko pripeti v notranjih knjižnicah. Skripti CLI se morda izvajajo v cevovodih CI ali operacijskih runbookih. Podatke registra bo morda treba preseliti ali ponovno registrirati, odvisno od tega, kako skupina uporablja storitev predogleda.

Zakaj je to pomembno za orodja agenta in MCP

Čas je opazen, ker infrastruktura agentov postaja bolj formalna. Nedavne spremembe na trgu so razvijalce potisnile stran od enkratnih predstavitev in usmerile k upravljanim sistemom: registri, strežniki orodij, poročanje o uporabi, nadzor dostopa in revizijske sledi. V tem kontekstu je sprememba imenskega prostora registra znak, da AWS obravnava odkrivanje in upravljanje agentov kot ločeno infrastrukturno površino.

Za ekipe, ki eksperimentirajo z agenti, je to morda manjša vzdrževalna naloga. Pri podjetjih, ki gradijo notranje platforme okoli agentskih katalogov, je delo širše. Registrski klici lahko stojijo za razvijalskimi portali, sistemi za varnostni pregled, orkestracijskimi plastmi, poteki dela za odobritev ali samodejnimi uvajanji. Če so bili ti sistemi zgrajeni v obdobju predogleda, morda vsebujejo predpostavke, ki jih je treba zdaj ponovno pregledati.

Sprememba je pomembna tudi za uvedbe protokola kontekstnega modela in druge vzorce interoperabilnosti posrednikov. Registri agentov lahko postanejo kraj, kjer platforme odkrijejo, kaj je agent, katera orodja lahko uporablja, katere končne točke izpostavi in ​​kakšne meje zaupanja veljajo. Če prehod, orkestrator ali partnerska platforma strankam izpostavi agente, ki jih podpira AWS, mora vedeti, ali med prehodnim obdobjem gleda stari imenski prostor, novi imenski prostor ali oba.

Kdo je prizadet

Najbolj neposredno prizadeti uporabniki so razvijalci in skupine platform, ki že uporabljajo AWS Agent Registry med javnim predogledom. Revidirati morajo vsako kodo ali infrastrukturo, ki se sklicuje na bedrock-agentcore za operacije registra. To vključuje aplikacijsko kodo, predloge infrastrukture kot kode, pravilnike IAM, opravila CI, skripte CLI, ovitke SDK, lokalna orodja za razvijalce in dokumentacijo, ki jo uporabljajo skupine za podporo.

Prizadete so tudi ekipe za varnost in upravljanje v oblaku. Spremembe IAM lahko trajajo dlje kot popravki aplikacij, ker pogosto zahtevajo pregled, preverjanje najmanjših privilegijev in poteke dela za odobritev. Premik imenskega prostora lahko zahteva nova dovoljenja, posodobljene reference storitev in osvežene predloge pravilnika. Če imajo organizacije notranji nadzor, ki privzeto blokira imenske prostore neznanih storitev, bo morda treba dodati nov imenski prostor agent-registry, preden lahko razvijalci nadaljujejo.

Proizvajalci prehodov API in avtomatizacije imajo drugačno težavo: zmedo strank. AWS je pred kratkim tudi Bedrock Agents premaknil na »klasično« pot za razpoložljivost novih strank in usmerjal novo delo k AgentCore. Selitev imenskega prostora registra agentov je ločena od prejšnjega izklopa Bedrock Agents Classic, vendar oba dogodka vplivata na isto široko kategorijo infrastrukture agentov. Dokumentacija, tokovi vkrcanja in odgovori podpore bi morali to razliko jasno razjasniti.

Praktični koraki selitve

Ekipe bi morale začeti z inventarjem. Preiščite repozitorije, manifeste uvajanja, datoteke pravilnikov in skripte CI za klice, povezane z registrom, pod starim imenskim prostorom Bedrock AgentCore. Nato ugotovite, katere reference so kritične za čas izvajanja in katere so le dokumentacija ali primeri.

Nato posodobite pravilnike IAM in jih preizkusite v neprodukcijskem računu. Spremembe imenskega prostora pogosto razkrijejo preširoka dovoljenja ali skrite odvisnosti. Nadzorovan preizkus lahko pokaže, ali nove reference storitev zadostujejo, preden postanejo proizvodni agenti ali registri odvisni od njih.

Uporabo SDK in CLI je treba preveriti ločeno. Nekatere ekipe kličejo storitve v oblaku prek uradnih odjemalcev SDK; drugi uporabljajo ukaze CLI znotraj cevovodov za gradnjo. Obe poti lahko različno spodletita. Odjemalci SDK morda potrebujejo posodobitve različic ali nove konstruktorje storitev. Skripti CLI bodo morda potrebovali nova imena ukazov, zastavice končne točke ali predpostavke avtentikacije.

Podatki registra si zaslužijo svoj načrt selitve. Dokumentacija AWS pravi, da je treba podatke registra posodobiti, vendar bo operativni učinek odvisen od tega, kako je vsaka ekipa modelirala agente, identifikatorje in metapodatke. Ekipe bi morale preveriti, ali zapisi agentov, kartice agentov, različice ali reference po selitvi ostanejo stabilni in ali nadaljnji sistemi te identifikatorje predpomnijo.

Za podjetja, ki uporabljajo večmodelni API ali prehod AI API, je večja lekcija ta, da agentska infrastruktura zdaj potrebuje enako disciplino upravljanja sprememb kot modelno usmerjanje. Prehod, kot je Model Gate, morda ni neposredno vključen v migracijo AWS Agent Registry, vendar je operativni vzorec znan: površine API-ja na strani ponudnika se spremenijo in ekipe potrebujejo centralizirano konfiguracijo, preglednost uporabe, ključne kontrole in jasno lastništvo, da se izognejo razpršenim zlomom.

Kaj ostaja negotovo

Razpoložljive informacije izhajajo iz dokumentacije AWS in ne iz ločenega bloga o predstavitvi ali širše objave. Zaradi tega sprememba ni manj izvedljiva, vendar omejuje javni kontekst okoli načrta AWS za register. Dokumentacija potrjuje selitev imenskega prostora in kategorije potrebnih posodobitev; v pridobljenem gradivu ne zagotavlja podrobne razlage tržnega pozicioniranja ali neodvisne potrditve iz drugega vira AWS.

Ker je AWS Agent Registry v javnem predogledu, bi morale ekipe domnevati tudi, da je možnih več sprememb vmesnika. Storitve predogleda so uporabne za zgodnjo uporabo, vendar zahtevajo močnejše meje abstrakcije kot zreli API-ji. Če so operacije registra razpršene po številnih aplikacijah, je to pravi trenutek, da jih združite za notranjimi knjižnicami ali storitvami platforme, da bo naslednjo spremembo lažje sprejeti.