Az AWS olyan kompatibilitási változtatást hajt végre, amely fontos a csapatok számára, akik az Amazon Bedrock AgentCore-on felül ügynöki infrastruktúrát építenek ki. Az AWS dokumentációja szerint az AWS Agent Registry jelenleg nyilvános előnézetben van a bedrock-agentcore névtér alatt, de 2026. augusztus 6-tól a szolgáltatás átkerül az agent-registry névtérbe.

Ez nem egy új alapozó modell bevezetése, és nem egy árazási bejelentés. Ez egy vízvezeték csere. Az ügynököket, szerszámkatalógusokat, Model Context Protocol-stílusú integrációkat vagy belső nyilvántartásokat üzemeltető fejlesztők számára azonban gyakran a vízvezeték-módosítások okozzák először a termelési szkripteket.

Az AWS szerint a felhasználóknak frissíteniük kell a végpontokat, az IAM-házirendeket, az SDK-klienseket, a CLI-parancsfájlokat és a rendszerleíró adatbázis adatait az áthelyezés részeként. Ez teszi ezt a valódi migrációs eseményt, nem pedig egy kozmetikai átnevezést. Bármely rendszer, amely közvetlenül hívja a régi névteret, engedélyeket ad rá, vagy automatizálja a beállításjegyzék-műveleteket parancssori vagy SDK-munkafolyamatokon keresztül, változtatásokra szorulhat, mielőtt tisztán működhetne az új szolgáltatásazonosítóval.

Mi változott az AWS-ügynök-nyilvántartásban

Az AWS Agent Registry az Amazon Bedrock AgentCore-hoz társított nyilvános előzetes szolgáltatásként van dokumentálva. A nyilvántartás célja, hogy segítse a csapatokat az ügynökök kezelésében és felfedezésében, beleértve az ügynökkártyákat és az ügynökökoszisztémákban használt kapcsolódó metaadatokat. Eddig az előnézet a bedrock-agentcore névtér alatt működött.

Az augusztus 6-i változás a beállításjegyzéket az agent-registry névtérre választja. Gyakorlatilag ez azt jelenti, hogy az integrációknak le kell állniuk, ha feltételezzük, hogy a rendszerleíró adatbázis csak egy része a szélesebb Bedrock AgentCore névtérnek. Az AWS-dokumentáció számos figyelmet igénylő területre hív fel: szolgáltatásvégpontok, identitás- és hozzáférés-kezelési házirendek, SDK-kliensek, CLI-szkriptek és rendszerleíró adatbázis-adatok.

Ezek a kategóriák lefedik a legtöbb olyan helyet, ahol az ügynöki infrastruktúra ragadóssá válik. A végpontok beágyazhatók a szolgáltatáskonfigurációba. Az IAM-engedélyeket alkalmazásfejlesztők helyett biztonsági csapatok kezelhetik. Az SDK-ügyfelek a belső könyvtárakban rögzíthetők. A CLI-parancsfájlok futhatnak CI-folyamatokban vagy műveleti runbookokban. A regisztrációs adatok áttelepítését vagy újraregisztrációját igényelhetik attól függően, hogy egy csapat hogyan használja az előnézeti szolgáltatást.

Miért számít ez az ügynök- és MCP-eszközök esetében?

Az időzítés figyelemre méltó, mert az ügynöki infrastruktúra formálisabbá válik. A közelmúltban a piacon végbement változások a fejlesztőket az egyszeri demóktól a szabályozott rendszerek felé lökték el: nyilvántartások, eszközkiszolgálók, használati jelentések, hozzáférés-ellenőrzések és ellenőrzési nyomvonalak. Ebben az összefüggésben a regisztrációs névtér változása azt jelzi, hogy az AWS külön infrastruktúra-felületként kezeli az ügynökfelderítést és -kezelést.

Az ügynökökkel kísérletező csapatok számára ez kisebb karbantartási feladatot jelenthet. Az ügynökkatalógusok köré belső platformokat építő vállalatoknál a munka szélesebb körű. A regisztrációs hívások fejlesztői portálok, biztonsági felülvizsgálati rendszerek, hangszerelési rétegek, jóváhagyási munkafolyamatok vagy automatizált telepítések mögé kerülhetnek. Ha ezeket a rendszereket az előnézeti időszakban építették, akkor olyan feltételezéseket tartalmazhatnak, amelyeket most felül kell vizsgálni.

A változás a Model Context Protocol telepítésére és más ügynökök együttműködési mintáira is vonatkozik. Az ügynök-nyilvántartások olyan hellyé válhatnak, ahol a platformok felfedezhetik, hogy mi az ügynök, milyen eszközöket használhat, milyen végpontokat tesz közzé, és milyen bizalmi határok vonatkoznak rájuk. Ha egy átjáró, irányító vagy partnerplatform AWS-támogatású ügynököket tesz közzé az ügyfelek számára, tudnia kell, hogy az átmeneti időszakban a régi névteret, az új névteret vagy mindkettőt nézi-e.

Ki érintett

A legközvetlenebbül érintett felhasználók azok a fejlesztők és platformcsapatok, amelyek már használják az AWS Agent Registry-t a nyilvános előnézet során. Vizsgálniuk kell minden olyan kódot vagy infrastruktúrát, amely a rendszerleíró adatbázis műveleteihez a bedrock-agentcore-ra hivatkozik. Ez magában foglalja az alkalmazáskódot, az infrastruktúra-kódként sablonokat, az IAM-házirendeket, a CI-feladatokat, a CLI-szkripteket, az SDK-burkolókat, a helyi fejlesztői eszközöket és a támogatási csapatok által használt dokumentációt.

A biztonsági és a felhőalapú irányítási csapatokat is érinti. Az IAM-módosítások hosszabb időt vehetnek igénybe, mint az alkalmazásjavítások, mert gyakran felülvizsgálatot, a legkevesebb jogosultságot biztosító ellenőrzéseket és jóváhagyási munkafolyamatokat igényelnek. A névtér-áthelyezéshez új engedélyekre, frissített szolgáltatási hivatkozásokra és frissített házirend-sablonokra lehet szükség. Ha a szervezetek olyan belső vezérlőkkel rendelkeznek, amelyek alapértelmezés szerint blokkolják az ismeretlen szolgáltatásnévtereket, előfordulhat, hogy az új agent-registry névteret hozzá kell adni ahhoz, hogy a fejlesztők továbbléphessenek.

Az API-átjárók és az automatizálási szállítók más problémával küzdenek: az ügyfelek összezavarodásával. Az AWS a közelmúltban a Bedrock Agents-et is a „klasszikus” útra állította az új ügyfelek számára elérhetőség érdekében, és az új munkát az AgentCore felé terelte. Az Agent Registry névtér áttelepítése elkülönül a korábbi Bedrock Agents Classic vágástól, de mindkét esemény az ügynök-infrastruktúra ugyanazt a széles kategóriáját érinti. A dokumentációnak, a bevezetési folyamatoknak és a támogatási válaszoknak egyértelművé kell tenniük ezt a különbséget.

Gyakorlati migrációs lépések

A csapatoknak leltárral kell kezdeniük. Keressen lerakatokat, telepítési jegyzékeket, házirend-fájlokat és CI-parancsfájlokat a rendszerleíró adatbázissal kapcsolatos hívásokhoz a régi Bedrock AgentCore névtérben. Ezután határozza meg, hogy mely hivatkozások kritikusak a futásidőben, és melyek csak dokumentációk vagy példák.

Ezután frissítse az IAM-házirendeket, és tesztelje azokat egy nem éles fiókban. A névtér módosításai gyakran túlságosan tág engedélyeket vagy rejtett függőségeket tárnak fel. Egy ellenőrzött teszt megmutathatja, hogy az új szolgáltatási hivatkozások elegendőek-e, mielőtt az éles ügynökök vagy a nyilvántartások függnének tőlük.

Az SDK és a CLI használatát külön kell ellenőrizni. Egyes csapatok hivatalos SDK-klienseken keresztül hívják a felhőszolgáltatásokat; mások a CLI-parancsokat dolgozzák ki a build folyamatokon belül. Mindkét út másképp kudarcot vallahat. Az SDK-ügyfeleknek verziófrissítésekre vagy új szolgáltatáskonstruktorokra lehet szükségük. A CLI-szkripteknek új parancsnevekre, végpontjelzőkre vagy hitelesítési feltételezésekre lehet szükségük.

A nyilvántartási adatok megérdemlik a saját migrációs tervet. Az AWS dokumentációja szerint a rendszerleíró adatbázis adatait frissíteni kell, de a működési hatás attól függ, hogy az egyes csapatok hogyan modellezték az ügynököket, azonosítókat és metaadatokat. A csapatoknak ellenőrizniük kell, hogy az ügynökrekordok, ügynökkártyák, verziók vagy hivatkozások stabilak maradnak-e az áttelepítés után, és hogy a későbbi rendszerek gyorsítótárazzák-e ezeket az azonosítókat.

A többmodelles API-t vagy AI API-átjárót használó vállalkozások számára a nagyobb tanulság az, hogy az ügynök-infrastruktúrának ma már ugyanolyan változáskezelési fegyelemre van szüksége, mint a modell-útválasztásnak. Előfordulhat, hogy az olyan átjárók, mint a Model Gate, nem vesznek részt közvetlenül az AWS-ügynök-nyilvántartás migrációjában, de a működési minta ismerős: a szolgáltatóoldali API felületek változnak, és a csapatoknak központosított konfigurációra, a használat láthatóságára, kulcsvezérlőkre és egyértelmű tulajdonjogra van szükségük, hogy elkerüljék a szétszórt töréseket.

Ami továbbra is bizonytalan

A rendelkezésre álló információk az AWS-dokumentációból származnak, nem pedig egy külön bevezetési blogból vagy szélesebb körű bejelentésből. Ez nem teszi kevésbé végrehajthatóvá a változtatást, de korlátozza az AWS regisztrációs ütemtervének nyilvános környezetét. A dokumentáció megerősíti a névtér áttelepítését és a szükséges frissítések kategóriáit; a visszakeresett anyagban nem ad részletes piaci pozicionálási magyarázatot vagy független megerősítést más AWS-forrástól.

Mivel az AWS Agent Registry nyilvános előnézetben van, a csapatoknak azt is feltételezniük kell, hogy több felületmódosítás lehetséges. Az előnézeti szolgáltatások hasznosak a korai alkalmazáshoz, de erősebb absztrakciós határokat igényelnek, mint a kiforrott API-k. Ha a rendszerleíróadatbázis-műveletek sok alkalmazásban szétszórtan találhatók, ez egy jó pillanat arra, hogy egyesítse őket belső könyvtárak vagy platformszolgáltatások mögé, így a következő változtatást könnyebben át lehet venni.