AWS teeb ühilduvuse muudatuse, mis on oluline meeskondade jaoks, kes ehitavad Amazon Bedrock AgentCore'i peale agentide infrastruktuuri. AWS-i dokumentatsiooni kohaselt on AWS-i agendiregister praegu nimeruumi bedrock-agentcore all avalikus eelvaates, kuid alates 6. augustist 2026 liigub teenus nimeruumi agent-registry.

See ei ole uue alusmudeli turuletoomine ega hinnateade. Tegemist on torustiku vahetusega. Kuid arendajate jaoks, kes haldavad agente, tööriistakatalooge, Model Context Protocol'i stiilis integratsioone või sisemisi registreid, on torustiku muudatused sageli need, mis rikuvad tootmisskriptid kõigepealt.

AWS ütleb, et kasutajad peavad kolimise käigus värskendama lõpp-punkte, IAM-eeskirju, SDK kliente, CLI skripte ja registriandmeid. See teeb sellest pigem tõelise rändesündmuse kui kosmeetilise ümbernimetamise. Iga süsteem, mis kutsub vana nimeruumi otse välja, annab sellele õigusi või automatiseerib registritoiminguid käsurea või SDK töövoogude kaudu, võib vajada muudatusi, enne kui see saab uue teenuseidentiteediga puhtalt töötada.

Mis muutus AWS-i agendiregistris

AWS Agent Registry on dokumenteeritud Amazon Bedrock AgentCore'iga seotud avaliku eelvaateteenusena. Registri eesmärk on aidata meeskondadel agente hallata ja avastada, sealhulgas agentide kaarte ja nendega seotud metaandmeid, mida kasutatakse agentide ökosüsteemides. Seni on eelvaade elanud nimeruumi bedrock-agentcore all.

6. augusti muudatus eraldab registri agent-registry nimeruumi. Praktikas tähendab see, et integratsioonid peaksid lõppema, eeldades, et register on vaid laiema Bedrock AgentCore'i nimeruumi alamosa. AWS-i dokumentatsioon toob esile mitmed tähelepanu vajavad valdkonnad: teenuse lõpp-punktid, identiteedi- ja juurdepääsuhalduspoliitikad, SDK kliendid, CLI skriptid ja registriandmed.

Need kategooriad hõlmavad enamikku kohtadest, kus agendi infrastruktuur muutub kleepuvaks. Lõpp-punktid võivad olla teenuse konfiguratsiooni manustatud. IAM-i õigusi võivad hallata pigem turvameeskonnad kui rakenduste arendajad. SDK-kliendid võivad olla kinnitatud sisemistesse teekidesse. CLI skriptid võivad töötada CI torujuhtmetes või operatsioonide käsiraamatutes. Sõltuvalt sellest, kuidas meeskond eelvaateteenust kasutab, võivad registriandmed vajada migreerimist või uuesti registreerimist.

Miks on see agendi ja MCP tööriistade jaoks oluline

Ajastus on märkimisväärne, kuna agendi infrastruktuur muutub formaalsemaks. Hiljutised muudatused kogu turul on tõrjunud arendajad eemale ühekordsetest demodest ja juhitud süsteemide poole: registrid, tööriistaserverid, kasutusaruandlus, juurdepääsukontroll ja kontrolljäljed. Selles kontekstis on registri nimeruumi muudatus signaal, et AWS käsitleb agendi avastamist ja haldamist eraldiseisva infrastruktuuri pinnana.

Agentidega eksperimenteerivate meeskondade jaoks võib see olla väike hooldustöö. Ettevõtetel, kes loovad agentide kataloogide ümber sisemisi platvorme, on töö laiem. Registrikõned võivad asuda arendajaportaalide, turbeülevaatesüsteemide, orkestreerimiskihtide, heakskiidu töövoogude või automatiseeritud juurutuste taga. Kui need süsteemid ehitati eelvaate perioodil, võivad need sisaldada eeldusi, mis tuleb nüüd uuesti üle vaadata.

Muudatus on asjakohane ka Model Context Protocol'i juurutuste ja muude agentide koostalitlusvõime mustrite puhul. Agentide registrid võivad muutuda kohaks, kus platvormid avastavad, mis agent on, milliseid tööriistu see kasutada saab, milliseid lõpp-punkte see paljastab ja millised usalduspiirid kehtivad. Kui lüüs, orkestraator või partnerplatvorm paljastab klientidele AWS-i toega agente, peab ta teadma, kas see vaatab üleminekuperioodil vana nimeruumi, uut nimeruumi või mõlemat.

Keda see mõjutab

Kõige otsesemalt mõjutatud kasutajad on arendajad ja platvormide meeskonnad, kes juba kasutavad avaliku eelvaate ajal AWS-i agendiregistrit. Nad peaksid auditeerima iga koodi või infrastruktuuri, mis viitab registritoimingute jaoks bedrock-agentcore-le. See hõlmab rakenduse koodi, infrastruktuuri koodina malle, IAM-eeskirju, CI-töid, CLI-skripte, SDK-mähiseid, kohaliku arendaja tööriistu ja tugimeeskondade kasutatavat dokumentatsiooni.

Mõjutatud on ka turvalisuse ja pilvehalduse meeskonnad. IAM-i muudatused võivad võtta kauem aega kui rakenduste paigad, kuna need nõuavad sageli ülevaatamist, vähimate privileegide kontrollimist ja kinnitamise töövooge. Nimeruumi teisaldamine võib nõuda uusi õigusi, värskendatud teenuseviiteid ja värskendatud poliitikamalle. Kui organisatsioonidel on sisemised juhtelemendid, mis blokeerivad vaikimisi tundmatuid teenusenimeruume, võib olla vaja lisada uus agent-registry nimeruum, enne kui arendajad saavad jätkata.

API lüüsi ja automatiseerimise tarnijatel on erinev probleem: klientide segadus. AWS viis hiljuti ka Bedrock Agentsi "klassikalisele" teele, et tagada uute klientide kättesaadavus, suunates uut tööd AgentCore'i poole. Agendiregistri nimeruumi migreerimine erineb varasemast Bedrock Agents Classicu piirist, kuid mõlemad sündmused mõjutavad sama laia agendi infrastruktuuri kategooriat. Dokumentatsioon, kasutuselevõtu vood ja tugivastused peaksid selle vahe selgeks tegema.

Praktilised migratsioonietapid

Meeskonnad peaksid alustama inventuuriga. Otsige hoidlaid, juurutusmanifeste, poliitikafaile ja CI-skripte registriga seotud kõnede jaoks vana Bedrock AgentCore'i nimeruumi alt. Seejärel tehke kindlaks, millised viited on käitusaja jaoks kriitilised ja millised on ainult dokumentatsioon või näited.

Järgmisena värskendage IAM-i eeskirju ja testige neid mittetootmiskontol. Nimeruumi muudatused paljastavad sageli liiga laiad õigused või peidetud sõltuvused. Kontrollitud test võib näidata, kas uued teenuseviited on piisavad, enne kui tootmisagendid või registrid neist sõltuvad.

SDK ja CLI kasutamist tuleks eraldi kontrollida. Mõned meeskonnad helistavad pilveteenustele ametlike SDK klientide kaudu; teised kasutavad CLI käske ehituskonveierites. Mõlemad teed võivad ebaõnnestuda erinevalt. SDK kliendid võivad vajada versioonivärskendusi või uusi teenusekonstruktoreid. CLI-skriptid võivad vajada uusi käsunimesid, lõpp-punkti lippe või autentimiseeldusi.

Registriandmed väärivad oma migratsiooniplaani. AWS-i dokumentatsioon ütleb, et registriandmeid tuleb värskendada, kuid tegevuse mõju sõltub sellest, kuidas iga meeskond on agente, identifikaatoreid ja metaandmeid modelleerinud. Meeskonnad peaksid kontrollima, kas agendikirjed, agendikaardid, versioonid või viited jäävad pärast migreerimist stabiilseks ja kas allavoolusüsteemid salvestavad need identifikaatorid vahemällu.

Mitme mudeliga API-t või AI API lüüsi kasutavate ettevõtete jaoks on suurem õppetund see, et agendi infrastruktuur vajab nüüd sama muudatuste haldamise distsipliini kui mudeli marsruutimine. Lüüs, nagu Model Gate, ei pruugi olla AWS-i agendiregistri migreerimisega otseselt seotud, kuid töömuster on tuttav: teenusepakkujapoolsed API-pinnad muutuvad ja meeskonnad vajavad tsentraliseeritud konfigureerimist, kasutuse nähtavust, võtme juhtelemente ja selget omandiõigust, et vältida hajali purunemist.

Mis jääb ebaselgeks

Saadaolev teave pärineb pigem AWS-i dokumentatsioonist kui eraldi käivitamisblogist või laiemast teadaandest. See ei muuda muudatust vähem rakendatavaks, kuid piirab avalikku konteksti AWS-i registri tegevuskava ümber. Dokumentatsioon kinnitab nimeruumi migratsiooni ja vajalike värskenduste kategooriaid; see ei sisalda otsitud materjalis üksikasjalikku turupositsiooni selgitust ega sõltumatut kinnitust teisest AWS-i allikast.

Kuna AWS-i agendiregister on avalikus eelvaates, peaksid meeskonnad eeldama, et liidese muudatusi on võimalik teha rohkem. Eelvaateteenused on varajaseks kasutuselevõtuks kasulikud, kuid nõuavad tugevamaid abstraktsioonipiire kui täiskasvanud API-d. Kui registritoimingud on paljudes rakendustes hajutatud, on praegu hea hetk koondada need sisemiste teekide või platvormiteenuste taha, et järgmine muudatus oleks lihtsam vastu võtta.