AWS Twierdzi, że trzech agentów muzycznych może współdzielić jeden GPU — ale prawdziwym testem jest koordynacja

Amazon wdrożył trzech współpracujących agentów muzycznych w jednym środowisku opartym na GPU, wykorzystując Amazon Bedrock AgentCore Runtime Instances do utrzymania ich pracy razem podczas długiej sesji.

Agenci komponują, przygotowują do dostarczenia i oceniają utwór za pośrednictwem współdzielonego systemu plików. Zamiast przenosić każdy plik pośredni między oddzielnymi usługami, wymieniają artefakty w jednym zarządzanym środowisku wykonawczym. Taki projekt podważa znany wzorzec chmurowy: zapewnić każdemu agentowi odizolowany kontener i połączyć wszystko za pomocą API.

Przykład produkcyjny AWS nie jest istotny dlatego, że AI potrafi generować muzykę. Wiele modeli już to robi. Jego znaczenie polega na tym, jak AWS chce, aby deweloperzy obsługiwali systemy wieloagentowe potrzebujące GPU, trwałych plików i sesji dłuższych niż typowe żądanie.

To wywiera presję na bezserwerowe podejście „jeden agent na środowisko wykonawcze”. Izolacja pozostaje użyteczna, ale tworzy tarcia, gdy kilku agentów musi operować na tych samych dużych artefaktach. Alternatywa Amazona traktuje zarządzaną instancję jak tymczasowe współdzielone studio.

Demonstracja nadal jest przygotowaną przez AWS architekturą referencyjną, a nie niezależnym benchmarkiem produkcyjnym. Pokazuje technicznie spójną ścieżkę, pozostawiając jednak otwarte pytania dotyczące kosztów, współbieżności, odzyskiwania po awarii i bezpieczeństwa.

Amazon Bedrock AgentCore Runtime Instances zmieniają jednostkę wdrożenia

AWS prosi deweloperów o wdrażanie współdzielonego obszaru roboczego, a nie tylko pojedynczego agenta.

Konwencjonalne środowisko wykonawcze agenta często koncentruje się na pojedynczym żądaniu. Aplikacja wysyła prompt, agent wywołuje narzędzia, a środowisko znika po wygenerowaniu odpowiedzi. Ten wzorzec dobrze sprawdza się, gdy użytecznym wynikiem jest tekst lub niewielki obiekt strukturalny.

Produkcja muzyczna wygląda inaczej. Ścieżki audio, wygenerowane klipy, metadane, raporty i gotowe utwory mogą osiągać duże rozmiary. Kilku wyspecjalizowanych agentów może przez wiele etapów potrzebować wglądu w ten sam zestaw plików lub jego modyfikacji.

Przykład AWS umieszcza trzech agentów na jednej instancji GPU. Jeden komponuje materiał, drugi przygotowuje rezultat do dostarczenia, a agent oceniający analizuje wynik. Agenci przekazują sobie pracę za pośrednictwem współdzielonego systemu plików.

Taki układ czyni pamięć masową częścią warstwy koordynacji. Gotowy plik audio może być jednocześnie wynikiem pracy jednego agenta i wejściem dla kolejnego. Następny agent nie potrzebuje oddzielnej usługi transferowej przed rozpoczęciem zadania.

Trwały wolumin to pamięć masowa, która przetrwa poza pojedynczym procesem lub żądaniem. W tym projekcie zapewnia przepływowi pracy trwały katalog roboczy podczas sesji. Agenci mogą odczytywać wcześniejsze artefakty bez umieszczania ich w promptach ani kopiowania między odizolowanymi środowiskami.

Według AWS instancja obsługuje również sesje wielodniowe. Ma to znaczenie dla przepływów pracy wymagających oceny przez człowieka, wielokrotnych poprawek lub długich zadań GPU. Producent może wstrzymać proces bez sprowadzania całego projektu do pojedynczej rozmowy z modelem.

Szersza usługa AgentCore pozycjonuje zarządzaną infrastrukturę pod aplikacjami agentowymi. Runtime Instances rozwijają tę koncepcję w kierunku obciążeń przypominających stanowe kreatywne stacje robocze, a nie krótkotrwałe funkcje webowe.

Zmienia to granicę wdrożenia. Aplikacja nie pakuje wyłącznie agenta i jego narzędzi. Pakuje skoordynowaną grupę, jej zależności, dostęp do GPU oraz współdzielony stan potrzebny do ukończenia zadania.

Ta granica ma konsekwencje operacyjne. Agenci działający na tej samej instancji mogą korzystać z lokalności danych, co oznacza, że potrzebne dane znajdują się blisko zasobów obliczeniowych, które je przetwarzają. Mogą też wzajemnie sobie przeszkadzać z powodu rywalizacji o zasoby lub niebezpiecznego dostępu do plików.

AWS przedstawił zatem coś więcej niż demonstrację muzyczną. Zaproponował opinię na temat tego, gdzie powinna odbywać się koordynacja. Niektóre przepływy pracy wieloagentowej należą do jednego zarządzanego środowiska obliczeniowego, nawet gdy ich role logiczne pozostają odrębne.

Dlaczego współdzielony GPU ma większe znaczenie niż muzyka

Najmocniejszym argumentem za kolokacją nie jest koordynacja konwersacyjna, lecz unikanie marnotrawstwa związanego z dużymi modelami i dużymi plikami.

Obciążenia GPU wiążą się z kosztami przygotowania, które zwykłe żądania API często ukrywają. Modele trzeba załadować do pamięci, zależności programowe muszą się zainicjalizować, a pośrednie materiały muszą pozostać dostępne. Powtarzanie tej pracy w trzech odizolowanych środowiskach może wydłużyć ścieżkę krytyczną.

Kolokacja oznacza uruchamianie powiązanych komponentów w tym samym środowisku obliczeniowym. Gdy agenci są skolokowani, jedna instancja GPU może obsługiwać ich sekwencyjne przekazania pracy. Agenci mogą ponownie wykorzystywać lokalne zasoby, zamiast traktować każdy etap jak granicę zdalnej usługi.

Etap komponowania w demonstracji nadaje tej architekturze konkretny cel. Agent komponujący może generować lub składać materiał muzyczny, a następnie pozostawić jego artefakty we współdzielonym obszarze roboczym. Agent dostarczający może przygotować utwór, podczas gdy agent oceniający może analizować ten sam rezultat.

Ta sekwencja przypomina niewielki zespół produkcyjny. Role pozostają rozdzielone, ale wszyscy pracują w tym samym folderze projektu. Gotowy wynik zależy od skoordynowanego stanu, a nie wyłącznie od udanych wywołań modelu.

Architektura może także zmniejszyć narzut serializacji. Serializacja przekształca dane w format możliwy do przesłania, często zwiększając nakład przetwarzania i pracy pamięci masowej. Duże pliki audio szczególnie źle nadają się do wielokrotnego kodowania i transferu sieciowego między agentami.

Współdzielona pamięć masowa nie eliminuje komunikacji. System nadal potrzebuje mechanizmu sterującego, który decyduje, kiedy artefakt jest gotowy i który agent działa jako następny. Przekazanie może jednak odwoływać się do ścieżki pliku i manifestu, zamiast osadzać sam artefakt.

To rozróżnienie ma znaczenie także poza muzyką. Edycja wideo, symulacje, renderowanie trójwymiarowe, analiza naukowa i przetwarzanie dokumentów tworzą pliki pośrednie. Wieloagentowy przepływ pracy AgentCore mógłby utrzymywać te artefakty blisko przyspieszonych zasobów obliczeniowych.

AWS opisuje Runtime Instances jako zarządzaną infrastrukturę EC2. Daje to deweloperom znajomy model obliczeniowy bez konieczności składania każdego elementu bazowego cyklu życia. Istotne porównanie nie dotyczy wyłącznie agentów i maszyn wirtualnych.

Rzeczywiste porównanie dotyczy zarządzanej kolokacji i rozproszonej izolacji. Jedna faworyzuje lokalny dostęp i zachowany stan. Druga sprzyja wąskim granicom, niezależnemu skalowaniu i mniejszym domenom awarii.

Dokumentacja AWS dotycząca przyspieszonego przetwarzania wyjaśnia szerszą rolę GPU i innych akceleratorów w obciążeniach EC2. AgentCore dodaje do tej infrastruktury warstwę operacyjną zorientowaną na agentów.

Potok produkcji muzycznej AWS upraszcza ten wybór, ponieważ jego etapy naturalnie przebiegają sekwencyjnie. W danym momencie GPU może potrzebować tylko jeden specjalista. Współdzielenie staje się mniej atrakcyjne, jeśli wielu agentów wymaga jednoczesnego, stałego przyspieszenia.

Staje się ono także mniej atrakcyjne, gdy zadania mają niepowiązane profile bezpieczeństwa. Zaufany agent komponujący i niezaufany agent analizujący pliki nie powinni automatycznie otrzymywać równoważnego dostępu do obszaru roboczego.

Przykład wskazuje więc użyteczny kształt wdrożenia, a nie uniwersalny domyślny wybór. Kolokacja działa najlepiej, gdy agenci współdzielą artefakty, granice zaufania, zależności i wspólny cykl życia.

Rzeczywista rywalizacja to kolokacja kontra izolacja

Projekt Amazona wymienia część narzutu systemów rozproszonych na większą współdzieloną granicę awarii i bezpieczeństwa.

Wiele frameworków agentowych zachęca deweloperów do reprezentowania każdego specjalisty jako niezależnej usługi. Model ten wspiera osobne wdrażanie, skalowanie, uprawnienia i obserwowalność. Awaria jednego komponentu nie musi pochłonąć całego środowiska przepływu pracy.

Kosztem jest koordynacja. Każda usługa potrzebuje mechanizmu transportu, uwierzytelniania, polityki ponawiania prób i kontraktu danych. Deweloperzy muszą zdecydować, gdzie znajdują się pliki pośrednie i jak agenci wykrywają ukończone zadanie.

Duże artefakty potęgują to obciążenie. Magazyn obiektowy może zapewnić trwałą wymianę, ale każde przekazanie nadal wymaga nazwania, przesłania, uprawnień, powiadomień i sprzątania. Kroki te są użytecznymi mechanizmami kontroli, lecz tworzą też więcej miejsc, w których zadanie może utknąć.

Amazon Bedrock AgentCore Runtime Instances ograniczają część tej rozproszonej powierzchni. Trzej agenci współdzielą jeden system plików i jedną instancję opartą na GPU. Ich rozdzielenie logiczne nie wymaga już rozdzielenia fizycznego.

Może to ułatwić zrozumienie potoku produkcji muzycznej AWS. Katalog projektu może zawierać żądanie, zasoby źródłowe, wynik kompozycji, pakiet do dostarczenia, raport oceny i finalny utwór. Każdy agent rozwija ten sam stan projektu.

Jednak współdzielony katalog nie jest silnikiem przepływu pracy. Samo istnienie pliku nie dowodzi, że zapis zakończył się pomyślnie. Agent może zaobserwować częściowy artefakt, nadpisać wynik innego agenta albo działać na nieaktualnej wersji.

Niezawodna implementacja potrzebuje jawnych przejść stanów. Manifest może rejestrować nazwy artefaktów, sumy kontrolne, właścicieli, wersje i status ukończenia. Atomowe operacje na plikach mogą zapobiec odczytywaniu przez odbiorców niedokończonych wyników.

Agenci potrzebują również kontraktu orkiestracji. Orkiestracja to logika, która przydziela zadania i przesuwa przepływ pracy naprzód. Powinna określać, który agent jest właścicielem każdego etapu, co stanowi sukces i co dzieje się po awarii.

Bez takiego kontraktu kolokacja może maskować sprzężenie jako wygodę. Przepływ pracy może odnieść sukces podczas liniowej demonstracji, lecz stać się trudny do debugowania przy ponawianiu prób, równoległych projektach lub częściowych restartach.

Izolacja rozwiązuje inne problemy. Oddzielne środowiska wykonawcze mogą skalować intensywnie używaną usługę oceny bez skalowania każdego kompozytora. Mogą wykorzystywać odrębne poświadczenia i zasady sieciowe. Ułatwiają też określenie odpowiedzialności, gdy agentów utrzymuje kilka zespołów.

Właściwa decyzja zależy od dominującego kosztu. Gdy dominują przenoszenie artefaktów i wielokrotna inicjalizacja obciążeń GPU, kolokacja zasługuje na uwagę. Gdy dominują niezależne skalowanie lub ścisłe rozdzielenie, odizolowane usługi pozostają bezpieczniejszym rozwiązaniem.

Możliwa jest także architektura hybrydowa. Ściśle powiązani agenci mogą współdzielić jedną instancję runtime, podczas gdy usługi zewnętrzne obsługują tożsamość, zdarzenia, trwałe rejestry projektów i końcowe przechowywanie artefaktów. Pozwala to zachować szybkie lokalne przekazania bez czynienia z instancji jedynego źródła prawdy.

Przewodnik po AgentCore Runtime stanowi oficjalny punkt wyjścia do jego modelu wykonawczego. Zespoły powinny porównać te mechanizmy kontroli z własnymi wymaganiami dotyczącymi odzyskiwania, audytu i izolacji.

Kluczowe pytanie architektoniczne jest proste: który stan musi być lokalny, aby zadanie działało wydajnie? Wszystko pozostałe powinno znajdować się poza współdzieloną granicą, chyba że kolokacja przynosi mierzalną korzyść.

Wielodniowe sesje tworzą pytania o stan, koszty i odzyskiwanie

Dłużej działające środowisko wykonawcze umożliwia zaawansowane przepływy pracy, ale zarządzanie cyklem życia staje się również wymogiem produktowym.

Wielodniowe sesje pasują do pracy kreatywnej, ponieważ produkcja rzadko przebiega jako jedno nieprzerwane żądanie. Osoba może przejrzeć wersję roboczą, poprosić o zmiany, zastąpić dane wejściowe lub czekać na innego interesariusza. Środowisko wykonawcze potrzebuje wystarczającej ciągłości, aby wznowić użyteczną pracę.

Trwałe pliki pomagają, ale wznowienie pracy wymaga czegoś więcej niż samych plików. Warstwa orkiestracji musi wiedzieć, które kroki zostały ukończone, jakie parametry wygenerowały każdy artefakt oraz czy bieżące środowisko odpowiada temu wcześniejszemu.

Ponownie uruchomiony proces nie powinien przypadkowo odtwarzać zatwierdzonej kompozycji. Nie powinien też zakładać, że wynik pozostaje prawidłowy po zmianie materiału źródłowego. Takie decyzje wymagają wersjonowanego stanu i operacji idempotentnych.

Operacja idempotentna daje ten sam zamierzony rezultat, gdy zostaje bezpiecznie powtórzona. Przepływy pracy agentów potrzebują tej właściwości, ponieważ wywołania modeli, narzędzia lub infrastruktura mogą zawieść po wykonaniu części pracy.

Tworzenie punktów kontrolnych może rejestrować postęp na ustalonych granicach. Punkt kontrolny to zapisany stan przepływu pracy, który umożliwia późniejsze odzyskanie. W tym potoku sensowne punkty kontrolne mogłyby następować po kompozycji, przygotowaniu dostarczenia i kontroli.

Współdzielony wolumen nie powinien stać się jedynym trwałym zapisem. Zespoły potrzebują zewnętrznego rejestru projektu, który dokumentuje decyzje, tożsamości artefaktów, wersje agentów i wyniki wykonania. Taki rejestr może pomóc odtworzyć przepływ pracy, jeśli instancja stanie się niedostępna.

Utrzymywanie aktywnego środowiska obsługiwanego przez GPU rodzi również pytania o wykorzystanie zasobów. Przykład AWS pokazuje, że wielodniowa sesja jest technicznie obsługiwana, ale nie dostarcza niezależnych dowodów na efektywność ekonomiczną w rzeczywistych obciążeniach.

Sesja oczekująca na wkład człowieka nie tworzy takiej samej wartości jak sesja generująca dźwięk. Zespoły muszą mierzyć, jaka część zarezerwowanego czasu działania wykonuje użyteczną pracę. Okresy bezczynności mogą osłabić finansowe uzasadnienie trwałej kolokacji.

Współbieżność dodaje kolejną niewiadomą. Jedna instancja może sprawnie obsłużyć jeden projekt, ale kilka jednoczesnych projektów może rywalizować o pamięć GPU, czas obliczeniowy, przepustowość dysku i pamięć tymczasową. Bez limitów wydajność może stać się nieprzewidywalna.

Polityki planowania powinny określać, który agent otrzymuje akcelerator i na jak długo. Przepływ pracy potrzebuje też mechanizmu backpressure, który spowalnia napływającą pracę, gdy zasoby są nasycone.

Bezpieczeństwo zasługuje na równie dużą uwagę. Trzech agentów współdzielących system plików dziedziczy możliwość odczytywania, modyfikowania lub usuwania artefaktów innych. Przejęte narzędzie lub nieprawidłowo sformatowany plik mogą rozszerzyć wpływ problemu poza jedną rolę logiczną.

Model współdzielonej odpowiedzialności AWS pozostaje istotny nawet wtedy, gdy infrastruktura jest zarządzana. AWS zabezpiecza bazową warstwę chmury, podczas gdy klienci nadal kontrolują swoje aplikacje, tożsamości, dane i konfigurację.

Zespoły powinny przyznawać każdemu agentowi najwęższy praktyczny zakres uprawnień. Oddzielne katalogi robocze, zweryfikowane manifesty, kontrole typów plików i niezmienne zatwierdzone wyniki mogą ograniczyć przypadkową ingerencję. Wrażliwe media źródłowe mogą wymagać dodatkowego szyfrowania i mechanizmów kontroli retencji.

Obserwowalność to kolejne wyzwanie. Pojedyncza pomyślna odpowiedź końcowa nie wyjaśnia, który model, narzędzie lub artefakt zmienił utwór. Dzienniki potrzebują identyfikatorów korelacyjnych, które śledzą projekt przez każdego agenta i każde przekazanie.

Demonstracja nie potwierdza niezależnie niezawodności w warunkach nieprawidłowych danych wejściowych, awarii procesów, presji na dysk lub współbieżnych użytkowników. Te luki nie podważają architektury. Definiują testy wymagane przed wdrożeniem produkcyjnym.

Potok muzyczny jest wzorcem dla agentów skoncentrowanych na artefaktach

Architektura referencyjna ma największe znaczenie wtedy, gdy produktem pracy agentów jest trwały artefakt, a nie kolejna wiadomość.

Większość publicznych przykładów agentów kładzie nacisk na rozmowę. Agent odczytuje prośbę, korzysta z narzędzi i zwraca tekst. Model ten niedostatecznie przedstawia przepływy pracy w inżynierii, mediach, badaniach i operacjach.

Przepływ pracy skoncentrowany na artefaktach tworzy pliki niosące stan projektu. Mogą one obejmować kod, dźwięk, wideo, diagramy, zbiory danych, raporty lub pakiety projektowe. Agenci współpracują, przekształcając i oceniając te zasoby.

Potok produkcji muzycznej AWS uwidacznia ten wzorzec. Agent kompozycyjny tworzy materiał. Agent dostarczający przekształca go w użyteczny pakiet. Agent kontrolujący ocenia ukończoną pracę i tworzy raporty.

Taki podział przypomina ludzką specjalizację, nie udając jednak, że agenci tworzą autonomiczną firmę. Każda rola ma ograniczoną odpowiedzialność, a współdzielony system plików zapewnia konkretną powierzchnię przekazania.

Programiści powinni opierać się pokusie dodawania agentów wyłącznie po to, by naśladować schemat organizacyjny. Każda granica wprowadza kolejny prompt, politykę, tryb awarii i problem ewaluacyjny. Pojedynczy agent z kilkoma narzędziami może być lepszym rozwiązaniem, gdy zakresy odpowiedzialności mocno się pokrywają.

Wielu agentów ma uzasadnienie, gdy etapy wymagają odrębnych modeli, uprawnień, kryteriów oceny lub stosów zależności. Agent kontrolujący powinien na przykład oceniać wynik według jawnych standardów, zamiast odtwarzać rozumowanie kompozytora.

Potok podkreśla także różnicę między pamięcią przepływu pracy a kontekstem modelu. Okno kontekstowe modelu zawiera informacje dostarczone dla pojedynczego wnioskowania. Nie jest niezawodną bazą danych projektu.

Pliki audio nie powinny być przedstawiane jako pamięć konwersacyjna, gdy system plików może przechowywać je bezpośrednio. Podobnie ustrukturyzowane decyzje powinny znajdować się w manifestach lub rekordach, które narzędzia mogą weryfikować.

Zasada ta dotyczy agentów tworzących oprogramowanie. Agent programujący, agent testujący i recenzent bezpieczeństwa mogą współdzielić repozytorium, zachowując odrębne obowiązki. Repozytorium staje się przestrzenią roboczą artefaktów, a kontrola wersji rejestruje trwałe zmiany.

Zespoły badające ten wzorzec mogą połączyć telemetrię działania z bazą wiedzy inżynierskiej. Celem jest zachowanie decyzji i dowodów poza pojedynczą sesją agenta.

Przepływy naukowe stanowią kolejne dobre zastosowanie. Jeden agent może przygotować dane, drugi przeprowadzić analizę na GPU, a trzeci zweryfikować wyniki. Współdzielona pamięć lokalna może ograniczyć wielokrotne przesyłanie dużych zbiorów danych podczas ściśle powiązanych etapów.

Obowiązuje jednak to samo ostrzeżenie. Współdzielona przestrzeń robocza jest wartościowa, gdy odzwierciedla rzeczywistą zależność między etapami. Staje się długiem technicznym, gdy zespoły używają jej, aby uniknąć definiowania interfejsów lub własności danych.

Najlepszy wniosek jest zatem węższy niż „umieść każdego agenta na jednej instancji”. Zidentyfikuj najmniejszą grupę agentów, która rzeczywiście potrzebuje współdzielonych przyspieszonych zasobów obliczeniowych i lokalnych artefaktów. Zapewnij tej grupie jedno ograniczone środowisko.

Długoterminowe zapisy, uprawnienia użytkowników i końcowe zasoby należy przechowywać w systemach zaprojektowanych z myślą o trwałym nadzorze. Traktuj środowisko uruchomieniowe jako aktywny warsztat, a nie trwałą pamięć instytucjonalną.

Trzy sygnały pokażą, czy ten model się sprawdzi

Kolejne dowody muszą wynikać z zachowania operacyjnego, a nie z następnej dopracowanej demonstracji.

Pierwszym sygnałem jest wsparcie dla powtarzalnego odzyskiwania. Programiści potrzebują jasnych przykładów pokazujących, jak przepływ pracy wznawia się po awarii agenta, procesu lub instancji. Odzyskiwanie powinno zachowywać zatwierdzone artefakty, uruchamiając ponownie wyłącznie nieukończoną pracę.

Jeśli AWS udokumentuje niezawodne wzorce tworzenia punktów kontrolnych i wznawiania, argument za wielodniowymi kreatywnymi i inżynierskimi przepływami pracy stanie się silniejszy. Jeśli odzyskiwanie pozostanie specyficzne dla aplikacji i kruche, zespoły będą potrzebować znacznej orkiestracji poza środowiskiem uruchomieniowym.

Drugim sygnałem jest izolacja zasobów przy współbieżności. Rzeczywiste wdrożenia potrzebują mechanizmów kontroli pamięci GPU, harmonogramowania obliczeń, wykorzystania dysku i separacji projektów. Benchmarki powinny obejmować kilka przepływów pracy współdzielących instancję, a nie tylko trzech agentów wykonujących jedno liniowe zadanie.

Silna izolacja i przewidywalne planowanie wsparłyby tezę o zarządzanej kolokacji. Niestabilne opóźnienia lub efekty „hałaśliwego sąsiada” skłoniłyby większe wdrożenia do korzystania z oddzielnych środowisk uruchomieniowych lub dedykowanych instancji.

Trzecim sygnałem jest adopcja wykraczająca poza demonstracje przygotowane przez AWS. Studia przypadków z produkcji powinny raportować czas trwania zadań, wskaźniki awarii, wykorzystanie GPU, wolumen artefaktów oraz nakład pracy operacyjnej wymagany wokół AgentCore.

Dowody z potoków wideo, inżynierii, badań lub dokumentów pokazałyby, że wzorzec uogólnia się poza muzykę. Ograniczona adopcja sugerowałaby, że architektura rozwiązuje węższą klasę obciążeń.

Amazon Bedrock AgentCore Runtime Instances zapewniają programistom wiarygodny sposób umieszczenia współpracujących agentów, trwałych plików i przyspieszonych zasobów obliczeniowych w jednej zarządzanej granicy. Przykład muzyczny czyni tę granicę łatwą do dostrzeżenia.

Nie rozstrzyga jednak, czy kolokacja kosztuje mniej, skaluje się lepiej lub zawodzi bezpieczniej niż izolowane usługi. Odpowiedzi zależą od pomiarów obciążenia i kontroli operacyjnych, których potok referencyjny nie może zapewnić.

Dla zespołów oceniających wieloagentowy przepływ pracy AgentCore natychmiastowym działaniem jest przetestowanie jednego procesu intensywnie wykorzystującego artefakty, z jawnymi punktami kontrolnymi i uprawnieniami. Mierz transfery, czas inicjalizacji, wykorzystanie GPU, ponowienia i odzyskiwanie. Następnie zapytaj, czy współdzielone środowisko usunęło więcej złożoności, niż wprowadziło.