Pakalpojums Amazon Web Services ir ievietojis savu sākotnējo pārvaldīto aģentu pakalpojumu Amazon Bedrock uzturēšanas režīmā jaunai ieviešanai. Pakalpojums, kas agrāk bija pazīstams kā Amazon Bedrock Agents, tagad ir dokumentēts kā Amazon Bedrock Agents Classic, un AWS saka, ka tas vairs nav pieejams jauniem klientiem, sākot no 2026. gada 30. jūlija.

Tas nenozīmē, ka esošās izvietošanas pārstāj darboties. AWS saka, ka pašreizējie klienti var turpināt izmantot Bedrock Agents Classic, un tajā atsevišķi norādīts, ka izmaiņas neietekmē Amazon Bedrock modeļus, zināšanu bāzes un Guardrails. Taču virziens jaunām aģentu darba slodzēm ir skaidrs: AWS iesaka Amazon Bedrock AgentCore kā salīdzināmu ceļu jaunām vai migrētām aģentu lietojumprogrammām.

Komandām, kas balstās uz Bedrock, tas ir vairāk nekā pakalpojuma nosaukuma maiņa. Tas maina AWS mitināto aģentu noklusējuma arhitektūru no vecās Bedrock Agents saskarnes uz jaunāku izpildlaika un rīku steks, kuras centrā ir AgentCore. Platformām, kas nodrošina AI API vārteju, LLM maršrutēšanas slāni vai uzņēmuma aģentu infrastruktūru, nogriešana rada saderības un migrācijas jautājumu, kas ir blakus parastai modeļu atlasei.

Kas mainījās 30. jūlijā

AWS dokumentācijā tagad Amazon Bedrock Agents tiek identificēts kā Amazon Bedrock Agents kā Amazon Bedrock Agents. Tie paši uzturēšanas režīma norādījumi saka, ka Bedrock Agents Classic ir slēgts jauniem klientiem no 2026. gada 30. jūlija, savukārt esošie klienti var turpināt to lietot.

Praktiskā nozīme ir atkarīga no klienta AWS konta un pašreizējā lietojuma. Esošajām ražošanas sistēmām, kas balstītas uz Classic, nevajadzētu pieņemt tūlītēju izslēgšanu, pamatojoties tikai uz publisko apkopes paziņojumu. Tomēr jaunām komandām, jauniem kontiem un organizācijām, kas standartizē nākotnes aģentu infrastruktūru, Classic jāuzskata par mantoto ceļu, nevis noklusējuma Bedrock aģenta pakalpojumu.

AWS norāda jaunus un migrējošus klientus uz Bedrock AgentCore. Uzņēmums AgentCore apraksta kā tādu, kas atbalsta pārvaldītu orķestrēšanu un plašāku ražošanas aģenta iespēju kopumu, tostarp rīku ekspozīciju, izmantojot modeļa konteksta protokolu, atmiņu, identitāti, novērojamību un izsekošanu. Šīs funkcijas liecina, ka AWS pāriet no šaurāka pārvaldīto aģentu veidotāja uz vispārīgāku aģenta izpildlaiku ilgmūžīgām, rīkus izmantojošām lietojumprogrammām.

Svarīga ir arī viena robeža: izmaiņas attiecas uz Bedrock pārvaldīto aģentu orķestrēšanas slāni, nevis visu Bedrock platformu. AWS saka, ka Bedrock modeļi, zināšanu bāzes un aizsargmargas netiek ietekmēti. Komanda joprojām var izmantot Bedrock modeļa secinājumus vai izguves un drošības komponentus, pat ja tai ir atkārtoti jāapmeklē aģentu orķestrēšanas pakalpojums.

Kāpēc tas ir svarīgi aģentu veidotājiem

Aģentu infrastruktūru ir kļuvis grūtāk uzskatīt par plānu apvalku ap modeļa zvanu. Ražošanas aģentam bieži ir nepieciešamas rīku atļaujas, atmiņas noteikumi, identitātes kartēšana, reģistrēšana, novērtēšana un izmaksu attiecinājums. Kad mainās pārvaldītais orķestrēšanas slānis, izstrādātājiem, iespējams, būs jāpārskata, kā tiek savienotas uzvednes, rīku shēmas, izguve, aizsargmargas un uzraudzība.

Tas jo īpaši attiecas uz uzņēmumiem, kas izmantojuši Bedrock Agents Classic kā pārvaldītu alternatīvu savas orķestrācijas veidošanai. Ja šie uzņēmumi tagad izveido papildu vides, ievieš jaunas biznesa vienības vai pārbūvē jaunos AWS kontos, tie var saskarties ar atšķirīgu pieejamību un ieteicamo arhitektūru, nekā tā, ko izmanto esošajos izvietojumos.

Pārtraukums ietekmē arī pārdevējus un iekšējās platformas komandas, kas vienotā saskarnē izmanto Bedrock. Vairāku mākoņu vai vairāku modeļu platforma to nevar uzskatīt vienkārši par "ceļu uz AWS modeli". Tam var būt nepieciešams zināt, vai klients izmanto vienkāršu modeļa secinājumu, zināšanu bāzes darbplūsmu, Guardrails politiku, klasisko aģentu vai AgentCore mitinātu darba slodzi. Tās ir dažādas darbības virsmas ar dažādiem migrācijas riskiem.

Model Gate lietotājiem un līdzīgiem vārtejas klientiem ir jāmācās, ka LLM API maršrutēšana vairs nav saistīta tikai ar cenu, latentumu un modeļa kvalitāti. Svarīgi ir arī aģentu izvietojums. Vārteja var palīdzēt centralizēt API atslēgas pārvaldību, lietojuma analīzi, komandas kontroli un tēriņu redzamību, taču tai joprojām ir jāievēro pamata nodrošinātāja pakalpojumu iespējas un dzīves cikla statuss.

Ietekmētie lietotāji

Vistiešāk skartā grupa ir AWS klienti, kuri plāno jaunu pārvaldīto aģentu būvniecību uz Bedrock. Ja viņi iepriekš nav izmantojuši Bedrock Agents Classic, viņiem vajadzētu sagaidīt, ka ieteicamais ceļš ir AgentCore. Komandas, kurās jau darbojas klasiskie aģenti, var turpināt to izmantošanu saskaņā ar AWS, taču tām ir jāplāno pakalpojuma uzturēšanas pozīcija, pieņemot ilgtermiņa lēmumus par ceļvedi.

Mākoņu arhitekti tiek ietekmēti, jo atsauces arhitektūras var būt jāatjaunina.Dokumentācija, Terraform moduļi, iekšējie zelta ceļi un drošības pārskati, kuros Bedrock Agents Classic tika pieņemts kā standarta pārvaldīto aģentu slānis, ir jāpārbauda, ​​salīdzinot ar AgentCore API, identitātes modeli, novērojamības līdzekļiem un darbības prasībām.

Ietver arī drošības un pārvaldības komandas. AgentCore uzsvars uz identitāti, rīku ekspozīciju, novērojamību un izsekošanu atspoguļo problēmas, kuras uzņēmumi tagad cenšas atrisināt: kurš lietotājs vai pakalpojums darbojas, kādus rīkus aģents var izsaukt, kādus datus tas var izgūt, kā var tikt pārbaudīts lēmums un kā tiek atklātas izplūdušas rīku cilpas vai dārgi modeļu izsaukumi.

Programmatūras pārdevējiem, iespējams, būs jāveido Bedroal-support periods. Esošie klienti joprojām var izmantot Classic, savukārt jauniem klientiem var būt nepieciešams AgentCore. Tas var nozīmēt papildu testēšanu, līdzekļu karogus, klientam specifisku izvietošanas loģiku un skaidrāku dokumentāciju par to, kurš Bedrock aģenta ceļš tiek atbalstīts.

Praktiskās sekas un atklātie jautājumi

Pirmais praktiskais solis ir inventarizācija. Komandām ir jānoskaidro, vai tās izmanto Bedrock Agents Classic, vienkāršas Bedrock modeļu API, zināšanu bāzes, aizsargmargas vai pielāgotu orķestrēšanu ārpus Bedrokas. Uzturēšanas režīma paziņojums šīs kategorijas ietekmē atšķirīgi.

Otrais solis ir kartēt migrācijas atkarības, nevis pieņemt tiešu pacelšanas un maiņas procesu. Aģenta darba slodze var būt atkarīga no rīku definīcijām, izguves konfigurācijas, uzvedņu veidnēm, IAM atļaujām, audita žurnāliem un lietojumprogrammas kļūdu apstrādes. Pāreja uz AgentCore var būt iespēja uzlabot novērojamību un identitātes vadīklas, taču joprojām var būt nepieciešams integrācijas darbs.

Trešais solis ir izmaksu un pārvaldības pārskatīšana. Jauni aģenta izpildlaiki bieži vien atvieglo vairāk rīku pievienošanu un autonomāku darbplūsmu palaišanu. Tas palielina lietojuma analīzes, pieprasījuma līmeņa attiecinājuma un budžeta vadīklu vērtību. Vārtejas vidē komandām jāizlemj, kuri izsaukumi plūst caur centrālo politikas slāni un kuri paliek AWS pārvaldītajā orķestrēšanā.

Daļa informācija ir atkarīga no konta. Neatkarīgi komentāri liecina, ka piemērotība var būt atkarīga no iepriekšēja konta lietojuma un ka daži nesen izlaisti modeļi pēc pārtraukšanas var nebūt pieejami, izmantojot Classic. Šie punkti ir jāpārbauda, ​​salīdzinot ar klienta AWS kontu un AWS pašreizējo uzturēšanas režīma dokumentāciju, pirms tie tiek uzskatīti par politiku.

Lielāks signāls ir pietiekami skaidrs: AWS neiziet no Bedrock aģentiem, taču tas novirza jaunu aģentu darbu no sākotnējās Bedrock Agents saskarnes. Izstrādātājiem un platformu komandām ir drošs pieņēmums, ka turpmākie AWS aģentu ieguldījumi koncentrēsies uz AgentCore, savukārt Bedrock Agents Classic kļūst par saderības problēmu esošajiem izvietojumiem.