Bedrock Agents Classic i przejście na AgentCore

Bedrock Agents Classic i przejście na AgentCore

Amazon Bedrock Agents pozwalał zbudować agenta w konsoli chmury: wskazywałeś model, opisywałeś akcje wywołujące Twoje funkcje, podpinałeś bazę wiedzy i dostawałeś działającego asystenta bez pisania pętli.

Ta usługa nosi dziś nazwę Amazon Bedrock Agents Classic i nie przyjmuje nowych klientów. Dotychczasowi mogą z niej korzystać dalej, a dla nowych wdrożeń dostawca kieruje do Amazon Bedrock AgentCore.

To jest najważniejsza informacja w całym tekście, więc jeśli szukasz, od czego zacząć budowę agenta na tej chmurze, odpowiedź brzmi: nie od tego produktu.

Co dokładnie oznacza tryb utrzymania

Warto rozłożyć to na części, bo określenie brzmi groźnie i wymaga doprecyzowania.

Usługa działa. Agenci już zbudowani odpowiadają, wywołują akcje i sięgają do baz wiedzy tak jak wcześniej. Nikt niczego nie wyłącza z dnia na dzień, a dostawca deklaruje kontynuację obsługi dotychczasowych klientów.

Nowych kont nie da się jednak podłączyć od 30 lipca 2026 roku, więc przy zakładaniu projektu w świeżym środowisku ta droga jest zamknięta niezależnie od tego, jak bardzo pasuje.

Dostęp rozstrzyga się przy tym na poziomie pojedynczego konta. Konto z aktywnością w tej usłudze w ciągu ostatnich dwunastu miesięcy zostało wpisane na listę i działa dalej, a pozostałe dostają odmowę uprawnień przy zakładaniu agenta, bez procedury wyjątku. Blokada obejmuje wyłącznie tworzenie agentów, bo pozostałe wywołania interfejsu zostały nietknięte.

Czego nie będzie: nowych funkcji. Produkt zatrzymał się w miejscu, w którym był, a rozwój przeniósł się gdzie indziej. Dotyczy to również katalogu modeli, zamrożonego w dniu wejścia w tryb utrzymania: modele wydane później są dostępne w następcy, a tutaj już nie. Przy narzędziu, którego wartość zależy od nadążania za modelami i protokołami, to jest realny czynnik.

Praktyczny wniosek dla obecnych użytkowników jest spokojny: dostawca nie wyznaczył ani daty wygaszenia, ani terminu migracji, a rachunek się nie zmienia, bo za samą warstwę agentową i tak nie płaciłeś. Presja bierze się więc nie z terminu, tylko z zamrożonego katalogu modeli, i to ona wyznacza moment, w którym migracja przestaje być opcjonalna.

Czym był ten produkt

Warto to opisać, bo pojęcia z niego przenoszą się do następcy i pomagają zrozumieć różnicę.

Agent składał się z kilku elementów. Grupa akcji opisywała, co agent potrafi zrobić, przez wskazanie schematu interfejsu i funkcji, która go obsługuje. Baza wiedzy podłączała zbiór dokumentów, z których agent mógł czerpać odpowiedzi. Szablony promptów pozwalały zmienić zachowanie na czterech etapach: przetwarzania wstępnego, orkiestracji, generowania odpowiedzi z bazy wiedzy i przetwarzania końcowego.

Wdrożenie odbywało się przez wersje i aliasy. Agenta testowałeś na aliasie testowym, potem tworzyłeś wersję i alias produkcyjny, a aplikacja wywoływała alias, nie samego agenta. To rozwiązanie było dobre i warto je odnotować, bo daje wdrożenie z możliwością cofnięcia bez zmiany kodu aplikacji.

Zaletą całości było to, że nie pisałeś pętli. Dostawca zajmował się rozbiciem zadania na kroki, wywoływaniem funkcji, pamięcią i szyfrowaniem, a Ty opisywałeś, co agent ma umieć.

Wadą było to samo z drugiej strony. Kształt przepływu był ustalony, a wyjście poza niego wymagało obchodzenia usługi albo rezygnacji z niej. To jest zresztą powód, dla którego następca wygląda inaczej.

AgentCore, czyli następca

Nowa usługa stała się ogólnie dostępna w październiku 2025 roku i jest zbudowana na innej zasadzie.

Zamiast jednego produktu składającego agenta za Ciebie dostajesz zestaw usług składanych: zarządzaną pętlę agenta, środowisko uruchomieniowe, bramę do narzędzi, pamięć, przeglądarkę, wykonywanie kodu, tożsamość, obserwowalność, reguły dostępu, ocenę jakości, optymalizację, płatności i katalog zasobów. Każdą można użyć osobno albo razem z pozostałymi, a lista rośnie z kwartału na kwartał.

Zmiana filozofii jest tu wyraźna, choć nie polega na odebraniu gotowej pętli. Poprzednik mówił: opisz agenta, a my go uruchomimy. Następca daje dwie drogi: konfigurujesz agenta w zarządzanej pętli albo piszesz go samodzielnie, a infrastruktura wokół jest w obu przypadkach ta sama.

Ta zarządzana pętla, ogólnie dostępna od czerwca 2026 roku, jest najbliższym odpowiednikiem starej usługi i to ją dostawca wskazuje jako domyślną ścieżkę migracji. Deklarujesz model, instrukcję i narzędzia, a usługa prowadzi orkiestrację, wywołuje narzędzia, pilnuje okna kontekstu, utrwala stan między turami i izoluje sesje. Konfigurację starego agenta można wczytać narzędziem wiersza poleceń dostawcy, zamiast przepisywać ją ręcznie.

Trzy elementy warto znać, bo rozwiązują problemy, które przy własnym wdrożeniu są kosztowne.

Środowisko uruchomieniowe daje sesje trwające do ośmiu godzin z pełną izolacją między nimi. To jest różnica wobec zwykłych funkcji bezserwerowych, gdzie limit czasu wykonania kończy długie zadanie w połowie.

Brama zamienia istniejące interfejsy i funkcje w narzędzia dostępne dla agenta, a także łączy się z serwerami zgodnymi z protokołem opisanym w rejestrze MCP. To oszczędza pisania warstwy pośredniczącej dla każdego systemu osobno.

Pamięć daje warstwę trwałą z możliwością sterowania sposobem wyciągania i konsolidowania faktów, co przy własnej implementacji jest kilkoma dniami pracy.

Co to znaczy dla Twojego kodu

Różnica praktyczna sprowadza się do jednego pytania: kto pisze pętlę agenta.

W poprzedniku nie pisałeś jej wcale. W następcy masz wybór: zarządzana pętla dalej pisze ją za Ciebie, a gdy potrzebujesz czegoś poza nią, piszesz ją sam albo bierzesz gotowy zestaw, na przykład Strands Agents od tego samego dostawcy albo agentów LangChaina, a usługi dokładają infrastrukturę wokół.

Podział jest prosty. Agent, który mieścił się w kształcie narzuconym przez poprzednika, przechodzi na zarządzaną pętlę i pozostaje konfiguracją. Agent, który się nie mieścił i był obchodzony, idzie na własny kod: to więcej pracy na starcie, za to migracja usuwa obejścia. Granica przebiega przy nadpisaniach promptów na poszczególnych etapach i przy współpracy wielu agentów, bo tego zarządzana pętla nie odtwarza wprost.

Warto też zauważyć, że nowe podejście nie wiąże Cię z jednym zestawem agentowym. Środowisko uruchomieniowe przyjmuje kod, więc możesz uruchomić w nim agenta napisanego dowolną biblioteką, a nawet własną pętlą.

Cena to większa liczba elementów do zrozumienia. Kilkanaście usług składanych daje elastyczność i wymaga decyzji, których wcześniej nie musiałeś podejmować.

Z czego składa się następca

Skoro następca jest zestawem składanym, warto wiedzieć, co dokładnie dostajesz, bo połowy z tego zwykle nie potrzebujesz na start. Poniżej części, od których zaczyna się w praktyce; reszta katalogu, jak reguły dostępu, ocena jakości czy płatności agenta, dokłada się później.

Zarządzana pętla zdejmuje z Ciebie orkiestrację. Podajesz model, instrukcję i listę narzędzi, a wykonanie, obsługa pamięci i izolacja sesji dzieją się po stronie usługi. Każda sesja dostaje własną maszynę wirtualną z systemem plików i powłoką, więc mieszczą się w niej zadania wymagające uruchomienia czegoś, a nie tylko odpowiedzenia.

Środowisko uruchomieniowe to miejsce, w którym działa Twój kod agenta. Wartość leży w długości sesji i izolacji: każda rozmowa dostaje własne, odizolowane środowisko, więc dane jednego użytkownika nie mogą trafić do drugiego przez wspólny stan procesu.

Brama zamienia to, co już masz, w narzędzia dla agenta. Zamiast pisać opakowanie dla każdego interfejsu osobno, wskazujesz schemat albo funkcję, a brama wystawia to w postaci, którą agent rozumie.

Pamięć obsługuje wątki rozmów i fakty przechowywane dłużej. Wariant sterowany samodzielnie pozwala określić, jak fakty są wyciągane i konsolidowane, co ma znaczenie przy dziedzinie, w której reguły ogólne zawodzą.

Przeglądarka i wykonywanie kodu dają agentowi możliwość klikania po stronach i uruchamiania obliczeń w izolowanym środowisku. To są elementy potrzebne przy zadaniach badawczych i analitycznych, a zbędne przy asystencie odpowiadającym z bazy wiedzy.

Tożsamość zajmuje się tym, w czyim imieniu agent działa, i przechowywaniem żetonów odświeżających w sejfie. To jest część, którą przy własnym wdrożeniu robi się źle najczęściej, bo wygląda na drobiazg, a dotyczy uprawnień.

Obserwowalność zamyka listę i jest tym, bez czego reszta jest nieprzejrzysta. Ślady pokazujące, co poszło do modelu i które narzędzie zostało wywołane, są warunkiem diagnozowania czegokolwiek.

Praktyczna rada: zacznij od zarządzanej pętli albo od środowiska uruchomieniowego z obserwowalnością, resztę dokładaj wtedy, gdy pojawi się potrzeba. Wzięcie całego katalogu naraz daje kilkanaście rzeczy do skonfigurowania przed pierwszą odpowiedzią.

Koszty i co się liczy inaczej

Model rozliczeniowy zmienia się razem z architekturą i warto to policzyć przed migracją.

W starej usłudze płaciłeś głównie za wywołania modelu, bo orkiestracja była wliczona. W nowej płacisz osobno za czas działania środowiska uruchomieniowego, za wywołania modelu i za te usługi, których użyjesz.

Konsekwencja jest taka, że długie sesje mają teraz cenę. Agent, który czeka na odpowiedź użytkownika przez pół godziny, w starym modelu nie kosztował nic w tym czasie, a w nowym trzyma zasoby. Warto sprawdzić, czy Twój przypadek zakłada rozmowy ciągłe, czy odpowiedzi na pojedyncze pytania, bo różnica w rachunku bywa znacząca.

Druga rzecz to liczba kroków agenta. Ten czynnik jest wspólny dla obu podejść i zwykle dominuje: przebieg z sześcioma wywołaniami narzędzi to sześć wywołań modelu o rosnącym koszcie, bo kontekst przyrasta z każdym krokiem.

Trzecia to pamięć. Wyciąganie faktów z rozmowy wymaga wywołań modelu, więc koszt rośnie z liczbą zapisywanych zdarzeń, a nie z liczbą pytań. To jest miejsce, w którym decyzja o tym, co trafia do pamięci, wpływa na rachunek bardziej niż wybór usługi.

Warto policzyć jeden realny przebieg przed decyzją, bo rozkład kosztu zwykle zaskakuje i rzadko wygląda tak, jak zakładał zespół.

Bedrock Agents kontra alternatywy

Pierwszy wiersz warto traktować wyłącznie jako opis stanu obecnego, a nie jako opcję. Nowe wdrożenie tam nie powstanie, a istniejące działa bez zapowiedzianej daty końca, tyle że z zamrożonym katalogiem modeli.

Drugi i trzeci wiersz nie wykluczają się, bo są na różnych poziomach: jeden to infrastruktura, drugi to biblioteka do pisania agenta, którą na tej infrastrukturze uruchamiasz. Mylenie ich jest częstym nieporozumieniem przy czytaniu materiałów dostawcy.

Czwarty wiersz jest wyborem na innej osi. Agent napisany biblioteką niezwiązaną z dostawcą chmury da się przenieść gdzie indziej, kosztem samodzielnego zapewnienia rzeczy, które usługi dokładają: izolacji sesji, trwałej pamięci i tożsamości.

Jak zaplanować przejście

Kolejność, która ogranicza ryzyko, gdy masz działającego agenta w starej usłudze.

Zacznij od inwentaryzacji tego, co faktycznie robi. Wypisz grupy akcji z ich schematami, podłączone bazy wiedzy oraz wszystkie miejsca, w których zmieniałeś szablony promptów. To ostatnie jest najczęściej pomijane, a właśnie tam siedzi zachowanie, którego nikt nie pamięta, że zostało dostrojone.

Potem odtwórz agenta w następcy. Najpierw sprawdź, czy mieści się w zarządzanej pętli, bo wtedy wystarczy konfiguracja i wczytanie starych ustawień poleceniem dostawcy, a po własny kod z wybraną biblioteką sięgaj dopiero przy odpowiedzi przeczącej. Wyniki porównaj na tym samym zestawie zapytań. Kilkadziesiąt realnych pytań z odpowiedziami wystarczy, żeby zobaczyć różnice, a różnice będą, bo prompty orkiestrujące w starej usłudze są jej własne.

Trzeci krok to infrastruktura. Bazy wiedzy działają niezależnie od agenta, więc zwykle nie wymagają odtwarzania. Pamięć, izolacja sesji i tożsamość to elementy, które w starej usłudze były wliczone, a teraz trzeba je świadomie wybrać.

Czwarty to uruchomienie równoległe. Stary agent obsługuje ruch, nowy dostaje kopię tych samych zapytań bez odpowiadania użytkownikom, a Ty porównujesz. Przełączenie następuje po tygodniu bez niespodzianek.

Zabezpieczenia warto przenieść świadomie, bo są osobną warstwą. Filtry treści i weryfikacja reguł, opisane w tekście o Bedrock Guardrails, da się wywołać niezależnie od tego, gdzie działa agent.

Typowe błędy

Pierwszy to rozpoczynanie nowego projektu od tej usługi. Nie przyjmuje nowych klientów, więc czas spędzony na czytaniu jej dokumentacji jest stracony.

Drugi to opieranie się na poradnikach bez sprawdzenia daty. Materiały opisujące budowę agenta w tej usłudze jako bieżące podejście pochodzą sprzed zmiany i wprowadzają w błąd.

Trzeci to założenie, że w nowej usłudze trzeba samodzielnie napisać pętlę. Zarządzana pętla przyjmuje agenta opisanego konfiguracją, a grupy akcji odpowiadają w niej narzędziom wystawionym przez bramę, więc dawne pytanie o opisanie akcji ma odpowiedź, tylko w innym miejscu.

Czwarty to migracja bez porównania wyników. Prompty orkiestrujące starej usługi są jej własne, więc odtworzony agent zachowuje się inaczej, a bez zestawu testowego zobaczysz to dopiero ze zgłoszeń.

Piąty to pominięcie zmienionych szablonów promptów przy inwentaryzacji. To tam zwykle siedzi dostrojone zachowanie, o którym zespół zapomniał.

Szósty to odkładanie migracji bez terminu. Brak publicznej daty wygaszenia nie znaczy, że jej nie będzie, a przeniesienie agenta pod presją jest droższe niż zaplanowane.

FAQ

Czy Bedrock Agents nadal działa?

Tak, pod nazwą Amazon Bedrock Agents Classic i w trybie utrzymania. Dotychczasowi klienci mogą korzystać dalej, natomiast od 30 lipca 2026 roku usługa nie przyjmuje nowych i nie dostaje ani nowych funkcji, ani nowych modeli, a dostawca kieruje nowe wdrożenia do AgentCore.

Czym jest AgentCore?

Zestawem usług składanych do budowania i uruchamiania agentów: zarządzaną pętlą agenta, środowiskiem uruchomieniowym z długimi sesjami, bramą zamieniającą interfejsy w narzędzia, pamięcią, tożsamością i obserwowalnością. Stał się ogólnie dostępny w październiku 2025 roku, a zarządzana pętla w czerwcu 2026.

Czy muszę migrować od razu?

Nie ma ani publicznej daty wygaszenia, ani terminu migracji, więc pośpiech nie jest konieczny. Rozsądna droga to zaplanowanie migracji na kwartał, w którym jest miejsce, z uruchomieniem równoległym i porównaniem wyników, zamiast przenoszenia pod presją terminu.

Czym różni się AgentCore od Strands Agents?

Poziomem. AgentCore to infrastruktura: uruchamianie, pamięć, tożsamość, narzędzia oraz zarządzana pętla dla agentów opisanych konfiguracją. Strands Agents to biblioteka do napisania samego agenta, którą na tej infrastrukturze uruchamiasz. Nie konkurują ze sobą, tylko się uzupełniają.

Co z bazami wiedzy?

Działają niezależnie od agenta, więc przy migracji zwykle nie wymagają odtwarzania. To jest ta część, która przechodzi najłatwiej, w odróżnieniu od grup akcji i zmienionych szablonów promptów.

Informacja o trybie utrzymania stoi w dokumentacji usługi, a opis następcy w dokumentacji AgentCore.