Ocena Amazon Bedrock AgentCore zamienia regresje agentów w nieudane pull requesty

Amazon wdrożył ocenę Amazon Bedrock AgentCore jako działającą bramkę jakości w GitHub Actions, zastępując subiektywne kontrole agentów czterema punktowanymi testami.

Referencyjny pipeline wdraża agenta AI i chroniony przez OAuth serwer Model Context Protocol, a następnie wywołuje agenta za pomocą reprezentatywnych promptów. Ocenia wynikowe ślady i kończy pull request niepowodzeniem, gdy dowolna wymagana metryka spadnie poniżej skonfigurowanego progu.

Zmienia to dyskusję wokół testowania agentów. Bezpośrednia rywalizacja nie dotyczy AWS i innego dostawcy chmury. Chodzi o zautomatyzowaną, powtarzalną ocenę kontra ręczne, wyrywkowe kontrole, z których wiele zespołów programistycznych nadal korzysta przed scaleniem zmian agenta.

Amazon opublikował implementację 8 września 2026 r. Pipeline oceny łączy AgentCore Runtime, AgentCore Evaluations, Amazon Cognito, CloudWatch, AWS CDK i GitHub Actions.

Najważniejszym rezultatem nie jest kolejny panel testowy. Nieudana odpowiedź może teraz oznaczać nieudany build oprogramowania, zanim zmienione zachowanie agenta trafi do współdzielonego środowiska lub na produkcję.

Ocena Amazon Bedrock AgentCore staje się bramką scalania

AWS przekształcił jakość agenta z opinii wyrażanej podczas przeglądu w warunek pull requestu.

Referencyjny workflow uruchamia się, gdy pull request kierowany do głównej gałęzi zmienia kod agenta, kod serwera MCP, infrastrukturę lub skrypty oceny. Tworzy tymczasowy stos deweloperski zawierający dwa środowiska uruchomieniowe AgentCore.

Jedno środowisko uruchomieniowe hostuje agenta opartego na Strands. Drugie hostuje serwer MCP, który udostępnia narzędzia za pośrednictwem standardowego protokołu łączącego aplikacje AI z zewnętrznymi możliwościami.

Wspólna pula użytkowników Amazon Cognito chroni oba środowiska uruchomieniowe. Workflow wdraża tę infrastrukturę przez AWS Cloud Development Kit, a następnie odczytuje identyfikatory środowisk i punkty końcowe uwierzytelniania z wyników wdrożenia.

GitHub Actions uzyskuje tymczasowe poświadczenia AWS przez federację OpenID Connect. OIDC pozwala GitHub wymienić krótkotrwały token tożsamości na rolę AWS, eliminując potrzebę przechowywania stałego klucza dostępu AWS w sekretach repozytorium.

Workflow nadal przechowuje ARN roli AWS jako sekret GitHub. Powstałe w ten sposób poświadczenia AWS są jednak tymczasowe i ograniczone przez zasady zaufania oraz uprawnień roli. GitHub dokumentuje ten model bezpieczeństwa OIDC.

Po wdrożeniu pipeline czeka, aż oba środowiska uruchomieniowe będą gotowe. Ta przerwa ma znaczenie operacyjne, ponieważ nowo utworzone środowisko nie może od razu przyjmować żądań.

AWS podaje, że zbyt wczesne wywołanie zwraca odpowiedź 424 Failed Dependency. Dostarczony workflow odpytuje usługę kontrolną AgentCore i rozgrzewa serwer MCP przed rozpoczęciem testów.

Pipeline następnie pobiera token dostępu OAuth i wysyła prompty testowe do punktu końcowego HTTPS agenta. Każdy prompt otrzymuje odrębny identyfikator sesji, co pozwala procesowi oceny powiązać emitowane ślady z właściwą interakcją.

Przykładowy zbiór danych obejmuje kilka rodzajów zachowań. Prosi agenta o obliczenie prostego sumowania, zwrócenie bieżącego czasu UTC, znalezienie kursu akcji Apple oraz pobranie liczby pracowników.

Te przykłady sprawdzają więcej niż samo brzmienie odpowiedzi. Testują wbudowane możliwości, publiczne narzędzia MCP, chronione narzędzia biznesowe, wybór narzędzi oraz parametry przekazywane do każdego wybranego narzędzia.

Skrypt oceny stosuje cztery wbudowane ewaluatory:

• GoalSuccessRate pyta, czy sesja zrealizowała cel użytkownika.

• Correctness porównuje odpowiedź z dostępnymi oczekiwaniami lub kontekstem.

• ToolSelectionAccuracy sprawdza, czy agent wybrał odpowiednie narzędzie.

• ToolParameterAccuracy sprawdza, czy agent podał właściwe argumenty.

Konfiguracja referencyjna wykorzystuje 0,8 w skali od zera do jednego jako próg akceptacji. Jeśli wymagany wynik spadnie poniżej tej wartości, skrypt kończy działanie niepowodzeniem, a GitHub oznacza zadanie jako nieudane.

Workflow może również opublikować wyniki oceny w pull requeście. Recenzenci widzą zmierzoną porażkę obok zmiany w kodzie, zamiast odtwarzać zachowanie agenta na podstawie logów lub lokalnych rozmów.

Na koniec krok czyszczenia uruchamia się nawet wtedy, gdy ocena zakończy się niepowodzeniem. Niszczy tymczasowy stos CDK, dzięki czemu nieudane pull requesty nie pozostawiają środowisk deweloperskich działających bezterminowo.

Ta sekwencja tworzy zasadnicze napięcie. Testowanie ręczne może ujawnić oczywisty problem, ale rzadko zapewnia powtarzalną regułę, którą musi spełnić każdy istotny pull request.

Dlaczego ręczne testowanie agentów znajduje się teraz pod presją

Pipeline wywiera presję na zespoły, które traktują odpowiedź agenta jako coś do sprawdzenia, a nie artefakt, który proces dostarczania oprogramowania musi zweryfikować.

Tradycyjne testy aplikacji mają jasne wyniki. Funkcja zwraca oczekiwaną wartość, API odpowiada schematowi albo operacja bazy danych zachowuje niezmiennik.

Agenci AI komplikują ten model. Ich odpowiedzi mogą się różnić, a poprawne końcowe zdanie nie dowodzi, że agent obrał akceptowalną drogę.

Agent korzystający z narzędzi może wybrać niewłaściwą usługę, ujawnić nieautoryzowany wynik lub wysłać nieprawidłowo sformatowane parametry. Może też dojść do wiarygodnej odpowiedzi przez kosztowną lub niebezpieczną sekwencję wywołań.

Zmiany w promptach tworzą kolejny problem. Niewielka korekta instrukcji systemowych może zmienić wybór narzędzi, zachowanie przy odmowie, szczegółowość odpowiedzi lub realizację zadania w niepowiązanych scenariuszach.

Aktualizacje modeli i zmiany zależności wiążą się z podobnym ryzykiem. Konwencjonalne testy jednostkowe mogą potwierdzić, że aplikacja działa, jednocześnie nie wykrywając istotnego pogorszenia zachowania.

Zespoły często rekompensują to ręcznymi zestawami promptów. Programista wprowadza kilka znanych pytań, czyta odpowiedzi i scala zmiany, gdy nic nie wygląda na ewidentnie błędne.

Ta metoda zapewnia słabe pokrycie i prowadzi do niespójnych ocen. Dostarcza też niewiele dowodów na to, które zachowanie zmieniło się między dwiema wersjami.

Pipeline AWS dodaje wspólną ścieżkę oceny do każdego istotnego pull requestu. Wdraża proponowany kod, testuje go, zbiera telemetrię i stosuje te same ewaluatory.

AgentCore współpracuje ze spanami OpenTelemetry, czyli ustrukturyzowanymi zapisami wywołań modeli, aktywności narzędzi i innych operacji w ramach interakcji. AgentCore Observability wysyła te ślady do CloudWatch.

W przypadku oceny na żądanie pipeline wybiera spany z konkretnej sesji i przekazuje je do usługi oceny. Tryby oceny obejmują również monitorowanie online i asynchroniczną analizę wsadową.

To rozróżnienie ma znaczenie dla zespołów dostarczających oprogramowanie. Ocena na żądanie pasuje do pull requestu, ponieważ dotyczy niewielkiego, kontrolowanego zestawu interakcji i zwraca szczegółowe wyniki.

Ocena online służy innemu celowi. Próbkuje ruch z wdrożonego systemu i śledzi zachowanie po wydaniu, gdy rzeczywiści użytkownicy generują żądania, których zbiór testowy nie przewidział.

Ocena wsadowa przetwarza większe zbiory sesji. Lepiej nadaje się do porównań z poziomem bazowym, okresowych audytów oraz analizy stanu przed i po zmianie.

Bramka pull requestu nie zastępuje tych trybów. Przesuwa najwcześniejszy mierzalny punkt kontrolny bliżej zmiany w kodzie.

To podejście zmienia również to, kto musi reagować na regresję. Bez bramki problem często wykrywają zespoły jakościowe lub użytkownicy po wdrożeniu.

Przy wymaganej kontroli GitHub autor musi rozwiązać problematyczne zachowanie przed scaleniem. Informacja zwrotna dociera, gdy związane z nią decyzje dotyczące kodu i promptów są nadal świeże.

Jest to szczególnie przydatne dla zespołów utrzymujących współdzielonych agentów. Zmiana odpowiedzi, która wydaje się akceptowalna dla jednego programisty, może zepsuć przepływ pracy z narzędziem należącym do innej grupy.

Starannie dobrany zbiór danych oceny może zachować te oczekiwania. Staje się wykonywalnym zapisem zadań, które agent musi nadal realizować.

Programiści nadal potrzebują dostępu do kontekstu wspierającego te oczekiwania. Baza wiedzy dla zespołów inżynieryjnych może pomóc zespołom połączyć przypadki oceny ze specyfikacjami, incydentami i decyzjami projektowymi.

Szersza zmiana ma charakter organizacyjny. Jakość agenta staje się częścią definicji zmiany gotowej do scalenia, a nie opcjonalnym przeglądem przeprowadzanym wtedy, gdy ktoś ma wystarczająco dużo czasu.

OAuth sprawia, że testowanie end-to-end jest trudniejsze niż punktacja

Najtrudniejszą częścią nie jest zażądanie wyniku oceny. Jest nią odtworzenie pełnej ścieżki narzędzi chronionego agenta w bezobsługowym środowisku CI.

Architektura referencyjna umieszcza zarówno agenta, jak i serwer MCP za Cognito. Użytkownicy interaktywni uwierzytelniają się przez przepływ authorization-code i otrzymują tokeny zawierające zakresy oraz niestandardowe oświadczenia ról.

Te role określają, do których narzędzi MCP użytkownik może uzyskać dostęp. Użytkownik działu finansów i użytkownik HR nie powinni automatycznie otrzymywać tych samych możliwości biznesowych.

GitHub Actions nie ma interaktywnego użytkownika. Nie może otworzyć ekranu zgody, ukończyć logowania w przeglądarce i przenieść kontekstu roli danej osoby przez test.

AWS przedstawia trzy sposoby obsługi tej rozbieżności. Każdy z nich sprawdza inną część systemu.

Pierwsze podejście ocenia zapisane ślady. Proces stagingowy wcześniej wywołuje agenta, przechwytuje reprezentatywną telemetrię i zapisuje te ślady jako dane testowe.

Zadania pull requestu oceniają te dane bez wywoływania działającego agenta ani serwera MCP. Podejście jest przewidywalne i omija problem uwierzytelniania w CI.

Ma jednak istotne ograniczenie. Wyniki opisują wcześniej zarejestrowane zachowanie, niekoniecznie kod agenta z bieżącego pull requestu.

Zapisane ślady mogą weryfikować zmiany ewaluatorów lub zachowywać historyczny poziom bazowy. Nie mogą dowieść, że nowo zmieniony kod środowiska uruchomieniowego nadal generuje oczekiwaną trajektorię.

Drugie podejście wykorzystuje dedykowane konto usługi. Operator jednokrotnie kończy interaktywną autoryzację i zapisuje jego token odświeżania w menedżerze sekretów.

CI może wtedy działać jako znany użytkownik o zdefiniowanych rolach. Umożliwia to testowanie granic autoryzacji i dostępu do narzędzi dla konkretnej tożsamości.

Tokeny odświeżania wygasają lub tracą ważność. Zespoły potrzebują rotacji, ponownej autoryzacji i ostrożnej kontroli nad uprawnieniami konta.

Implementacja AWS wybiera trzecią drogę: uwierzytelnianie machine-to-machine. Cognito wydaje token przez przyznanie OAuth client_credentials.

Skrypt oceny wysyła identyfikator klienta, sekret klienta i żądany zakres do punktu końcowego tokenów Cognito. Następnie wywołuje AgentCore Runtime przez HTTPS z użyciem zwróconego tokena okaziciela.

Oprogramowanie pośredniczące MCP odróżnia te tokeny od tokenów użytkowników. Tokeny maszynowe mają zakresy, ale nie zawierają niestandardowych oświadczeń ról, dlatego przykład pozwala im dotrzeć do każdego narzędzia.

Tokeny interaktywne nadal zawierają role, a serwer MCP egzekwuje ograniczenia na poziomie narzędzi dla tych użytkowników. Ta sama pula Cognito obsługuje zatem zarówno dostęp CI, jak i autoryzację użytkowników.

Ten projekt umożliwia działające na żywo, kompleksowe testowanie kodu z pull requestu. Agent może wywoływać wdrożony serwer MCP i tworzyć nowe ślady do oceny.

Nie testuje jednak egzekwowania ról. Tożsamość CI celowo omija te kontrole ról.

Ta granica jest najważniejszym zastrzeżeniem tej architektury. Przechodzący pipeline pokazuje, że tożsamość maszyny może wykonać oceniane zadania. Nie pokazuje jednak, że FinanceUser i HRUser otrzymują różne, autoryzowane wyniki.

Zespoły potrzebujące obu form pewności muszą dodać osobne testy autoryzacji. Mogą korzystać z kont usługowych o określonych rolach lub z bezpośrednich testów względem warstwy pośredniej MCP.

Poświadczenie maszyny również staje się wrażliwym zasobem. AWS twierdzi, że tylko pipeline CI i środowisko uruchomieniowe agenta powinny móc je uzyskać.

To twierdzenie zależy od szczegółów implementacji. Uprawnienia repozytorium, zatwierdzanie workflow, polityki IAM, ekspozycja sekretów, zachowanie forków i redakcja logów wpływają na faktyczną granicę bezpieczeństwa.

Połączenie GitHub OIDC chroni stronę AWS przed długotrwałymi poświadczeniami repozytorium. Nie eliminuje wszystkich sekretów, ponieważ klient OAuth nadal korzysta z sekretu klienta.

Rola IAM również powinna przestrzegać zasady najmniejszych uprawnień. Szeroki dostęp wdrożeniowy do Cognito, ECR, zasobów CDK, Bedrock i AgentCore może zapewnić więcej uprawnień, niż potrzebuje rutynowe zadanie pull request.

Ochrona środowiska może ograniczyć ryzyko. Zespoły mogą ograniczyć, które gałęzie i workflow przyjmują rolę, wymagać zatwierdzenia niezaufanych zmian oraz oddzielić role wdrożeniowe od tożsamości ewaluacyjnych.

Architektura testuje więc jednocześnie zachowanie agenta i integrację CI. Poprawność autoryzacji pozostaje odrębnym celem akceptacyjnym.

Bramka jakości ocenia ślady, a nie tylko odpowiedzi

Ocena Amazon Bedrock AgentCore ma znaczenie, ponieważ może ocenić przebieg realizacji zadania przez agenta, a nie wyłącznie jego końcowy tekst.

Skrypt ewaluacyjny używa zestawu startowego AgentCore do zebrania odpowiednich śladów CloudWatch. Następnie stosuje ewaluatory do wybranej sesji.

Surowe API Evaluate przyjmuje sessionSpans, czyli kolekcję zakresów telemetrii należących do jednej sesji. AWS ostrzega, że mieszanie zakresów z wielu sesji powoduje błąd walidacji.

Ta granica sesji pozwala ewaluatorowi odtworzyć interakcję. Może on sprawdzić dane wejściowe użytkownika, wynik modelu, wybrane narzędzia, parametry narzędzi oraz wynikową odpowiedź.

GoalSuccessRate działa na poziomie sesji. Pyta, czy pełna interakcja osiągnęła to, czego zażądał użytkownik.

Correctness analizuje odpowiedź na poziomie śladu. Może użyć oczekiwanej odpowiedzi, gdy test ją udostępnia.

ToolSelectionAccuracy i ToolParameterAccuracy działają na poziomie wywołania narzędzia. Rozróżniają wybór właściwej operacji od prawidłowego wywołania tej operacji.

To rozdzielenie dało pouczający wynik w celowym teście regresji AWS. Autorzy zmienili prompt systemowy tak, aby agent zawsze zwracał niepomocną odmowę.

GoalSuccessRate spadł do 0.0. Correctness również uzyskał wynik 0.0, a ToolParameterAccuracy 0.0.

ToolSelectionAccuracy nadal uzyskał wynik 1.0. Agent najwyraźniej potrafił wskazać odpowiednie narzędzie, nawet gdy nie realizował całego żądania.

Dlatego pojedyncza miara zbiorcza może ukrywać problemy. Różne ewaluatory mierzą niezależne wymiary, a jeden pozytywny wynik nie może zniwelować każdego nieudanego zachowania.

Po przywróceniu przez autorów zamierzonego promptu systemowego GoalSuccessRate wrócił do 1.0. Correctness osiągnął 0.9, a obie miary narzędziowe osiągnęły 1.0.

Wszystkie cztery przekroczyły następnie przykładowy próg 0.8. GitHub odblokował pull request.

AgentCore przyjmuje również dane referencyjne dla testów wymagających oczekiwanego zachowania. Mogą one obejmować oczekiwaną odpowiedź, asercje w języku naturalnym lub oczekiwaną trajektorię narzędzi.

Trajektoria opisuje sekwencję narzędzi, które agent powinien wywołać. AWS oferuje ewaluatory dokładnej kolejności, kolejności zachowanej i dowolnej kolejności dla różnych ograniczeń workflow.

Test dokładnej kolejności pasuje do procesu, w którym każdy krok zależy od poprzedniego. Test dowolnej kolejności pasuje do niezależnych operacji pobierania, których sekwencja nie wpływa na poprawność.

Usługa obsługuje również niestandardowe ewaluatory. Zespoły mogą zdefiniować własne instrukcje, model oceniający i skalę punktacji dla wymagań specyficznych dla danej domeny.

Ewaluatory oparte na kodzie zapewniają bardziej deterministyczną opcję. Wywołują funkcję AWS Lambda, która może sprawdzać schematy, wzorce, słowa kluczowe lub reguły biznesowe.

To połączenie ma znaczenie, ponieważ nie każde wymaganie potrzebuje oceny modelu. Poprawność JSON, zakazane pola, maksymalna liczba wywołań i dokładne identyfikatory często można sprawdzić zwykłym kodem.

Zgodnie z przewodnikiem po niestandardowych ewaluatorach, ewaluatory mogą działać na poziomie sesji, śladu lub wywołania narzędzia. Niestandardowa logika może wykorzystywać model lub funkcję Lambda.

Praktyczna bramka powinna dopasowywać typ ewaluatora do wymagania. Punktacja oparta na modelu sprawdza się dla jakości semantycznych, takich jak trafność, powodzenie zadania czy wierność.

Deterministyczny kod sprawdza się dla binarnych ograniczeń. Kontrole trajektorii narzędzi pasują do oczekiwanej struktury workflow.

Najlepszy sygnał wynika z połączenia tych metod. Odpowiedź może być semantycznie poprawna, a jednocześnie naruszać schemat, natomiast poprawny schemat może nadal zawierać nieistotną odpowiedź.

Dane referencyjne również wymagają ostrożnego użycia. Nie każda akceptowalna odpowiedź ma jedno dokładne brzmienie, zwłaszcza w przypadku streszczania lub otwartej analizy.

Asercje mogą wyrażać fakty lub zachowania, które muszą się pojawić, bez wymuszania jednej odpowiedzi. Oczekiwane trajektorie mogą określać zachowanie narzędzi niezależnie od stylu prozy.

Dzięki temu zestaw testowy staje się czymś więcej niż zbiorem promptów. Każdy scenariusz może określać, co oznacza sukces na poziomie odpowiedzi, zadania i narzędzi.

Pozytywny wynik nadal ma martwe pola

Bramka wykrywa zdefiniowane regresje, ale jej wiarygodność zależy od pokrycia testami, stabilności wyników, projektu tożsamości i czasu operacyjnego.

AWS podaje, że pełny pipeline trwa około 10 minut. Wdrożenie, uruchomienie środowiska wykonawczego, propagacja śladów i ewaluacja oparta na modelu składają się na ten czas.

Taki czas jest akceptowalny dla wielu pull requestów. Jest zbyt długi dla lokalnej kontroli przed commitem i może stać się kosztowny w repozytoriach z częstymi aktualizacjami.

Dostępność śladów zwiększa niepewność. AWS zaobserwował opóźnienia propagacji od 30 do 90 sekund po wywołaniu agenta.

Skrypt referencyjny ponawia próbę co 30 sekund przez maksymalnie 10 minut. Natychmiastowe odpytywanie CloudWatch może więc dać pozorną porażkę, zanim ślad jeszcze istnieje.

Architektura środowiska wykonawczego tworzy kolejną przeszkodę implementacyjną. AgentCore Runtime wymaga obrazów kontenerów ARM64, podczas gdy standardowe hostowane przez GitHub runnery używają procesorów x86-64.

Workflow używa QEMU i Docker Buildx do budowania obrazów wieloplatformowych. Wymóg ten wydłuża czas kompilacji i wprowadza kolejny możliwy punkt awarii niezwiązany z jakością agenta.

Najistotniejsze ograniczenie wynika z oceny opartej na modelu. Ewaluator LLM może przydzielić nieznacznie różne wyniki, gdy ocenia ten sam ślad więcej niż raz.

Rygorystyczny próg może zatem powodować niestabilne pull requesty blisko granicy. Jeden przebieg może przejść z wynikiem 0.81, a inny zakończyć się niepowodzeniem przy 0.79 bez istotnej różnicy w kodzie.

AWS zaleca pozostawienie marginesu między progiem akceptacji a docelowym poziomem niezawodności. Zespoły powinny również zmierzyć wariancję ewaluatora, zanim kontrola stanie się obowiązkowa.

Powtarzane uruchomienia mogą oszacować tę wariancję, ale zwiększają też zużycie ewaluacji. Przykład referencyjny używa czterech ewaluatorów dla pięciu promptów, co daje 20 wywołań modelu oceniającego dla jednego pull requestu.

Źródło nie przypisuje ceny tym wywołaniom. Zaleca jednak zespołom monitorowanie wykorzystania Bedrock w miarę rozwoju repozytoriów i zbiorów danych.

Pokrycie testami stwarza znany, lecz bardziej wyraźny problem. Bramka jakości mierzy wyłącznie scenariusze uwzględnione w jej zbiorze danych.

Cztery lub pięć wygodnych promptów nie może reprezentować każdego żądania produkcyjnego, stanu autoryzacji, trybu awarii, języka ani danych wejściowych o charakterze adwersarialnym.

Token maszyny w przykładzie może uzyskać dostęp do każdego narzędzia. W rezultacie uruchomienie end-to-end nie dowodzi, że narzędzia ograniczone rolami pozostają chronione przed zwykłymi użytkownikami.

Szeroki wynik może również ukryć nierówną wydajność. Ogólna średnia może przejść, podczas gdy jeden krytyczny scenariusz zawodzi.

Zadania wysokiego ryzyka powinny mieć wymagania na poziomie scenariusza. Operacja płacowa, usunięcie konta lub wyszukiwanie danych osobowych nie powinny czerpać sukcesu z kilku łatwych promptów arytmetycznych.

Metryki również potrzebują właściciela. Programiści muszą wiedzieć, kto zatwierdza zmiany progów, dodaje nowe scenariusze i bada rozbieżności między ewaluatorami.

W przeciwnym razie nieudana bramka może wywołać presję na obniżenie progu. Organizacja zachowuje wtedy tempo dostarczania przez osłabienie pomiaru.

Kolejnym ryzykiem jest fałszywa pewność. Zielona kontrola pokazuje, że testowana wersja w jednym momencie spełniła określone kryteria.

Nie poświadcza każdej odpowiedzi, nie eliminuje prompt injection ani nie waliduje infrastruktury poza wdrożonym stosem testowym. Nie zastępuje też przeglądu bezpieczeństwa.

Telemetria produkcyjna pozostaje niezbędna, ponieważ użytkownicy znajdą kombinacje pominięte przez kuratorowany zbiór danych. Ewaluacja online AgentCore może próbkować sesje na żywo i publikować wyniki w CloudWatch.

Dokumentacja wyników podaje, że wyniki online pojawiają się jako metryki CloudWatch. Szczegółowe zdarzenia ewaluacyjne są przechowywane w dedykowanych grupach logów.

Ewaluacja wsadowa może następnie porównać większe przedziały przed i po zmianach modelu, promptu lub narzędzi. Takie porównanie zapewnia silniejszy punkt odniesienia niż jedno uruchomienie pull requestu.

Dojrzały system powinien łączyć te etapy. Błędy produkcyjne powinny stawać się nowymi scenariuszami ewaluacyjnymi, a powtarzające się awarie CI powinny wpływać na projekt agenta.

Bramka jakości jest najbardziej wiarygodna, gdy jej zbiór danych ewoluuje wraz z incydentami. Statyczny benchmark z czasem nagradza znajomość testu zamiast niezawodnego zachowania.

Co obserwować po pierwszej bramce GitHub Actions

Kolejnym testem jest to, czy zespoły potrafią uczynić te bramki wystarczająco stabilnymi, świadomymi bezpieczeństwa i reprezentatywnymi, aby stały się wymaganymi kontrolami.

Pierwszym sygnałem jest wdrażanie ewaluacji danych referencyjnych i deterministycznych w workflow pull requestów. Cztery wbudowane metryki stanowią użyteczny punkt wyjścia, ale nie wyrażają każdej reguły biznesowej.

Warto obserwować, czy zespoły dodają oczekiwane odpowiedzi, asercje i trajektorie narzędzi dla scenariuszy o wysokiej wartości. Rosnące użycie kontroli opartych na Lambda wskazywałoby, że ewaluacja agentów staje się zwykłą weryfikacją oprogramowania.

Taki rozwój wzmocniłby argumenty za ewaluacją Amazon Bedrock AgentCore. Zmniejszyłby zależność od jednego modelu oceniającego i ułatwił odtwarzanie części błędów.

Drugim sygnałem jest pokrycie CI uwzględniające role. AWS otwarcie wskazuje ograniczenie tokena maszyny, ponieważ wybrany przez niego przepływ omija kontrole ról użytkownika.

Zespoły powinny publikować wzorce testowania odrębnych tożsamości użytkowników bez tworzenia kruchych operacji odświeżania tokenów. Konta usługowe, bezpośrednie testy autoryzacji i izolowani najemcy testowi są prawdopodobnymi drogami.

Jeśli kontrole specyficzne dla ról staną się powszechne, architektura zbliży się do pełnej pewności end-to-end. Jeśli pozostaną odrębne lub nieobecne, zielony wynik agenta będzie niewiele mówił o poprawności autoryzacji.

Trzecim sygnałem jest połączenie bramek pull requestów z wynikami produkcyjnymi. Mały zbiór danych rozwojowych nie może pozostać reprezentatywny bez informacji zwrotnej z rzeczywistych sesji.

Warto obserwować workflow, które przekształcają nisko ocenione ślady produkcyjne w sprawdzone przypadki regresji. Monitorowanie online powinno wykrywać błędy, podczas gdy kuratorowane testy CI powinny zapobiegać ich powrotowi.

Narzędzia AWS do ewaluacji zbiorów danych to kolejny istotny kierunek rozwoju. Ich uruchamiacze zbiorów danych mogą wywoływać agentów, czekać na telemetrię i oceniać scenariusze w ramach skoordynowanego procesu.

Szersze zastosowanie ograniczyłoby niestandardową orkiestrację widoczną obecnie w referencyjnym workflow. Ułatwiłoby również utrzymanie większych, wersjonowanych zestawów ewaluacyjnych.

Dla deweloperów praktyczne pytanie nie brzmi już, czy odpowiedzi agentów należy testować. Chodzi o to, które zachowania muszą blokować scalanie zmian, które wymagają monitorowania, a które należy egzekwować deterministycznie.

Zacznij od błędów, które prowadziłyby do wycofania wdrożenia, incydentu bezpieczeństwa lub zakłócenia kluczowego procesu biznesowego. Każdemu przypisz konkretny scenariusz i metodę oceny adekwatną do jego ryzyka.

Następnie celowo zepsuj działanie agenta i potwierdź, że bramka nie przechodzi z oczekiwanego powodu. Kontrola staje się wiarygodna dopiero wtedy, gdy wykryje znaną regresję.

Amazon przedstawił wiarygodną ścieżkę od testów promptów do wymaganych kontroli statusu GitHub. Kolejny krok należy do zespołów inżynieryjnych: zdefiniować zachowania, których nie zamierzają wdrażać, zakodować je i stale aktualizować tę definicję.