AWS veic saderības izmaiņas, kas ir svarīgas komandām, kas veido aģentu infrastruktūru papildus Amazon Bedrock AgentCore. Saskaņā ar AWS dokumentāciju AWS aģentu reģistrs pašlaik ir pieejams publiskajā priekšskatījumā bedrock-agentcore nosaukumvietā, taču no 2026. gada 6. augusta pakalpojums tiek pārvietots uz nosaukumvietu agent-registry.

Šis nav jauna pamata modeļa izlaišana, un tas nav paziņojums par cenām. Tā ir santehnikas maiņa. Taču izstrādātājiem, kas izmanto aģentus, rīku katalogus, modeļa konteksta protokola stila integrācijas vai iekšējos reģistrus, santehnikas izmaiņas bieži vien ir tās, kas vispirms pārtrauc ražošanas skriptus.

AWS saka, ka lietotājiem ir jāatjaunina galapunkti, IAM politikas, SDK klienti, CLI skripti un reģistra dati. Tas padara to par īstu migrācijas notikumu, nevis kosmētisku pārdēvēšanu. Jebkurai sistēmai, kas tieši izsauc veco nosaukumvietu, piešķir tai atļaujas vai automatizē reģistra darbības, izmantojot komandrindas vai SDK darbplūsmas, var būt nepieciešamas izmaiņas, lai tā varētu tīri darboties ar jauno pakalpojuma identitāti.

Kas mainījās AWS aģentu reģistrā

AWS aģentu reģistrs ir dokumentēts kā publiska priekšskatījuma pakalpojums, kas saistīts ar Amazon Bedrock AgentCore. Reģistrs ir paredzēts, lai palīdzētu komandām pārvaldīt un atklāt aģentus, tostarp aģentu kartes un saistītos metadatus, ko izmanto aģentu ekosistēmās. Līdz šim priekšskatījums atradās zem nosaukumvietas bedrock-agentcore.

6. augustā veiktās izmaiņas atdala reģistru agent-registry nosaukumvietā. Praktiski tas nozīmē, ka integrācijas jāpārtrauc, pieņemot, ka reģistrs ir tikai plašākas Bedrock AgentCore nosaukumvietas apakšdaļa. AWS dokumentācijā ir norādītas vairākas jomas, kurām jāpievērš uzmanība: pakalpojuma galapunkti, identitātes un piekļuves pārvaldības politikas, SDK klienti, CLI skripti un reģistra dati.

Šīs kategorijas aptver lielāko daļu vietu, kur aģentu infrastruktūra kļūst lipīga. Galapunkti var būt iegulti pakalpojuma konfigurācijā. IAM atļaujas var pārvaldīt drošības komandas, nevis lietojumprogrammu izstrādātāji. SDK klienti var būt piesprausti iekšējās bibliotēkās. CLI skripti var darboties CI konveijeros vai operāciju izpildgrāmatās. Reģistra datiem var būt nepieciešama migrācija vai pārreģistrācija atkarībā no tā, kā komanda izmanto priekšskatījuma pakalpojumu.

Kāpēc tas ir svarīgi aģentiem un MCP rīkiem

Laiks ir ievērojams, jo aģentu infrastruktūra kļūst formālāka. Nesenās izmaiņas tirgū ir pamudinājušas izstrādātājus no vienreizējām demonstrācijām un virzīties uz pārvaldītām sistēmām: reģistriem, rīku serveriem, lietojuma ziņojumiem, piekļuves kontroli un audita pēdām. Šajā kontekstā reģistra nosaukumvietas izmaiņas ir signāls, ka AWS aģentu atklāšanu un pārvaldību uzskata par atsevišķu infrastruktūras virsmu.

Komandām, kuras eksperimentē ar aģentiem, tas var būt neliels uzturēšanas uzdevums. Uzņēmumiem, kas veido iekšējās platformas ap aģentu katalogiem, darbs ir plašāks. Reģistra izsaukumi var būt aiz izstrādātāju portāliem, drošības pārskatīšanas sistēmām, orķestrēšanas slāņiem, apstiprināšanas darbplūsmām vai automatizētām izvietošanām. Ja šīs sistēmas tika izveidotas priekšskatījuma periodā, tajās var būt ietverti pieņēmumi, kas tagad ir jāpārskata.

Izmaiņas attiecas arī uz modeļa konteksta protokola izvietošanu un citiem aģentu sadarbspējas modeļiem. Aģentu reģistri var kļūt par vietu, kur platformas atklāj, kas ir aģents, kādus rīkus tas var izmantot, kādus galapunktus tas atklāj un kādas uzticības robežas tiek piemērotas. Ja vārteja, orķestrētājs vai partneru platforma klientiem atklāj ar AWS nodrošinātos aģentus, tai ir jāzina, vai pārejas periodā tiek aplūkota vecā nosaukumvieta, jaunā nosaukumvieta vai abas.

Kas tiek ietekmēts

Vistiešāk ietekmētie lietotāji ir izstrādātāji un platformu komandas, kas jau izmanto AWS aģentu reģistru publiskās priekšskatīšanas laikā. Viņiem jāpārbauda jebkurš kods vai infrastruktūra, kas atsaucas uz pamatiežu aģents reģistra darbībām. Tas ietver lietojumprogrammas kodu, infrastruktūras kā koda veidnes, IAM politikas, CI darbus, CLI skriptus, SDK ietvari, vietējo izstrādātāju rīkus un atbalsta komandu izmantoto dokumentāciju.

Ietekmē arī drošības un mākoņa pārvaldības komandas. IAM izmaiņas var aizņemt ilgāku laiku nekā lietojumprogrammu ielāpi, jo tām bieži ir nepieciešama pārskatīšana, vismazāko privilēģiju pārbaudes un apstiprināšanas darbplūsmas. Nosaukumvietas pārvietošanai var būt nepieciešamas jaunas atļaujas, atjauninātas pakalpojumu atsauces un atsvaidzinātas politikas veidnes. Ja organizācijām ir iekšējās kontroles, kas pēc noklusējuma bloķē nezināmas pakalpojuma nosaukumvietas, iespējams, būs jāpievieno jaunā agent-registry nosaukumvieta, lai izstrādātāji varētu turpināt darbu.

API vārtejas un automatizācijas piegādātājiem ir cita problēma: klientu apjukums. AWS nesen arī pārcēla Bedrock Agents uz “klasisko” ceļu, lai nodrošinātu pieejamību jauniem klientiem, virzot jaunu darbu AgentCore virzienā. Aģentu reģistra nosaukumvietas migrācija ir nošķirta no iepriekšējā Bedrock Agents Classic nogriezuma, taču abi notikumi ietekmē to pašu plašo aģentu infrastruktūras kategoriju. Dokumentācijai, iekļaušanas plūsmām un atbalsta atbildēm ir skaidri jānorāda šī atšķirība.

Praktiskas migrācijas darbības

Komandām jāsāk ar inventarizāciju. Meklējiet repozitorijus, izvietošanas manifestus, politikas failus un CI skriptus ar reģistru saistītiem izsaukumiem vecajā Bedrock AgentCore nosaukumvietā. Pēc tam nosakiet, kuras atsauces ir svarīgas izpildlaikam un kuras ir tikai dokumentācija vai piemēri.

Pēc tam atjauniniet IAM politikas un pārbaudiet tās kontā, kas nav ražots. Vārdtelpas izmaiņas bieži atklāj pārāk plašas atļaujas vai slēptas atkarības. Kontrolēta pārbaude var parādīt, vai jaunās pakalpojumu atsauces ir pietiekamas, pirms ražošanas aģenti vai reģistri ir atkarīgi no tiem.

SDK un CLI lietojums ir jāpārbauda atsevišķi. Dažas komandas izsauc mākoņpakalpojumus, izmantojot oficiālus SDK klientus; citi izmanto CLI komandas build cauruļvados. Abi ceļi var neizdoties atšķirīgi. SDK klientiem var būt nepieciešami versiju atjauninājumi vai jauni pakalpojumu konstruktori. CLI skriptiem var būt nepieciešami jauni komandu nosaukumi, galapunkta karodziņi vai autentifikācijas pieņēmumi.

Reģistra dati ir pelnījuši savu migrācijas plānu. AWS dokumentācijā teikts, ka reģistra dati ir jāatjaunina, taču darbības ietekme būs atkarīga no tā, kā katra komanda ir modelējusi aģentus, identifikatorus un metadatus. Grupām ir jāpārbauda, vai aģentu ieraksti, aģenta kartes, versijas vai atsauces pēc migrācijas paliek stabilas un vai pakārtotās sistēmas šos identifikatorus saglabā kešatmiņā.

Uzņēmumiem, kas izmanto vairāku modeļu API vai AI API vārteju, lielākā mācība ir tāda, ka aģentu infrastruktūrai tagad ir nepieciešama tāda pati izmaiņu pārvaldības disciplīna kā modeļa maršrutēšanai. Vārteja, piemēram, Model Gate, var nebūt tieši iesaistīta AWS aģentu reģistra migrēšanā, taču darbības modelis ir pazīstams: pakalpojumu sniedzēja puses API virsmas mainās, un komandām ir nepieciešama centralizēta konfigurācija, lietojuma redzamība, galvenās vadīklas un skaidras īpašumtiesības, lai izvairītos no izkliedētām bojājumiem.

Kas paliek neskaidrs

Pieejamā informācija tiek iegūta no AWS dokumentācijas, nevis no atsevišķa palaišanas emuāra vai plašāka paziņojuma. Tas nepadara izmaiņas mazāk īstenojamas, taču ierobežo publisko kontekstu saistībā ar AWS reģistra ceļvedi. Dokumentācija apstiprina nosaukumu telpas migrāciju un nepieciešamo atjauninājumu kategorijas; tas izgūtajā materiālā nesniedz detalizētu tirgus pozicionēšanas skaidrojumu vai neatkarīgu apstiprinājumu no cita AWS avota.

Tā kā AWS aģentu reģistrs ir pieejams publiskajā priekšskatījumā, komandām arī jāpieņem, ka ir iespējamas vairāk saskarnes izmaiņu. Priekšskatījuma pakalpojumi ir noderīgi agrīnai ieviešanai, taču tiem ir nepieciešamas stingrākas abstrakcijas robežas nekā nobriedušām API. Ja reģistra darbības ir izkaisītas daudzās lietojumprogrammās, šis ir piemērots brīdis, lai tās apvienotu aiz iekšējām bibliotēkām vai platformas pakalpojumiem, lai nākamās izmaiņas būtu vieglāk uztveramas.