Amazon Bedrock AgentCore Evaluation macht Agenten-Regressionen zu fehlgeschlagenen Pull Requests
Amazon hat Amazon Bedrock AgentCore evaluation in eine funktionierende Qualitätskontrolle für GitHub Actions integriert und ersetzt subjektive Agentenprüfungen durch vier bewertete Tests.
Die Referenzpipeline stellt einen KI-Agenten und einen OAuth-geschützten Model Context Protocol-Server bereit und ruft den Agenten anschließend mit repräsentativen Prompts auf. Sie bewertet die daraus resultierenden Traces und lässt den Pull Request fehlschlagen, wenn eine erforderliche Metrik unter einen konfigurierten Schwellenwert fällt.
Das verändert die Diskussion über Agententests. Der unmittelbare Wettbewerb lautet nicht AWS gegen einen anderen Cloud-Anbieter. Es geht um automatisierte, wiederholbare Bewertungen gegenüber den manuellen Stichproben, die viele Entwicklungsteams vor dem Zusammenführen von Agentenänderungen noch einsetzen.
Amazon veröffentlichte die Implementierung am 8. September 2026. Die Bewertungspipeline verbindet AgentCore Runtime, AgentCore Evaluations, Amazon Cognito, CloudWatch, AWS CDK und GitHub Actions.
Das entscheidende Ergebnis ist nicht ein weiteres Test-Dashboard. Eine fehlgeschlagene Antwort kann nun zu einem fehlgeschlagenen Software-Build werden, bevor verändertes Agentenverhalten eine gemeinsame Umgebung oder die Produktion erreicht.
Amazon Bedrock AgentCore Evaluation wird zur Merge-Schranke
AWS hat die Qualität von Agenten von einer Einschätzung während der Prüfung zu einer Bedingung für Pull Requests gemacht.
Der Referenz-Workflow wird ausgeführt, wenn ein Pull Request mit Zielbranch main Agentencode, MCP-Servercode, Infrastruktur oder Bewertungsskripte verändert. Er erstellt einen temporären Entwicklungs-Stack mit zwei AgentCore-Runtimes.
Eine Runtime hostet einen auf Strands basierenden Agenten. Die andere hostet einen MCP-Server, der Tools über ein Standardprotokoll bereitstellt, das KI-Anwendungen mit externen Funktionen verbindet.
Ein gemeinsamer Amazon-Cognito-Benutzerpool schützt beide Runtimes. Der Workflow stellt diese Infrastruktur über AWS Cloud Development Kit bereit und liest anschließend Runtime-Kennungen sowie Authentifizierungsendpunkte aus den Bereitstellungsoutputs.
GitHub Actions erhält temporäre AWS-Anmeldedaten über OpenID Connect Federation. OIDC erlaubt GitHub, einen kurzlebigen Identitätstoken gegen eine AWS-Rolle auszutauschen, wodurch ein permanenter AWS-Zugriffsschlüssel in Repository-Secrets vermieden wird.
Der Workflow speichert die AWS-Rollen-ARN weiterhin als GitHub-Secret. Die resultierenden AWS-Anmeldedaten sind jedoch temporär und durch die Vertrauens- und Berechtigungsrichtlinien der Rolle eingeschränkt. GitHub dokumentiert dieses OIDC-Sicherheitsmodell.
Nach der Bereitstellung wartet die Pipeline, bis beide Runtimes bereit sind. Diese Pause ist operativ relevant, weil eine neu erstellte Runtime nicht sofort Anfragen annehmen kann.
AWS zufolge liefert ein früher Aufruf eine 424 Failed Dependency-Antwort. Der bereitgestellte Workflow fragt den AgentCore-Control-Service wiederholt ab und wärmt den MCP-Server auf, bevor der Testlauf beginnt.
Anschließend ruft die Pipeline einen OAuth-Zugriffstoken ab und sendet Testprompts an den HTTPS-Endpunkt des Agenten. Jeder Prompt erhält eine eigene Sitzungskennung, sodass der Bewertungsprozess emittierte Traces der richtigen Interaktion zuordnen kann.
Der Beispieldatensatz deckt mehrere Arten von Verhalten ab. Er fordert den Agenten auf, eine einfache Summe zu berechnen, die aktuelle UTC-Zeit zurückzugeben, einen Apple-Aktienkurs zu finden und eine Mitarbeiterzahl abzurufen.
Diese Beispiele prüfen mehr als die Formulierung der Antwort. Sie testen integrierte Fähigkeiten, öffentliche MCP-Tools, geschützte Geschäftstools, die Tool-Auswahl und die an jedes ausgewählte Tool übergebenen Parameter.
Das Bewertungsskript verwendet vier integrierte Evaluatoren:
GoalSuccessRate fragt, ob die Sitzung das Ziel des Nutzers erfüllt hat.
Correctness vergleicht die Antwort mit verfügbaren Erwartungen oder Kontext.
ToolSelectionAccuracy prüft, ob der Agent ein geeignetes Tool gewählt hat.
ToolParameterAccuracy prüft, ob der Agent passende Argumente übergeben hat.
Die Referenzkonfiguration verwendet 0,8 auf einer Skala von null bis eins als Akzeptanzschwelle. Fällt ein erforderlicher Wert darunter, wird das Skript mit einem Fehler beendet und GitHub markiert den Job als fehlgeschlagen.
Der Workflow kann Bewertungsergebnisse auch im Pull Request veröffentlichen. Reviewer sehen den gemessenen Fehler neben der Codeänderung, statt das Agentenverhalten aus Logs oder lokalen Gesprächen rekonstruieren zu müssen.
Abschließend wird der Bereinigungsschritt auch bei einer fehlgeschlagenen Bewertung ausgeführt. Er zerstört den temporären CDK-Stack, damit fehlgeschlagene Pull Requests nicht auf unbestimmte Zeit laufende Entwicklungs-Runtimes hinterlassen.
Diese Abfolge schafft die zentrale Spannung. Manuelle Tests können ein offensichtliches Problem aufdecken, liefern jedoch selten eine reproduzierbare Regel, die jeder relevante Pull Request erfüllen muss.
Warum manueller Agententest nun unter Druck steht
Die Pipeline setzt Teams unter Druck, die eine Agentenantwort als etwas betrachten, das geprüft werden sollte, statt als Artefakt, das die Softwareauslieferung validieren muss.
Herkömmliche Anwendungstests haben klare Ausgaben. Eine Funktion liefert den erwarteten Wert, eine API entspricht einem Schema oder eine Datenbankoperation wahrt eine Invariante.
KI-Agenten verkomplizieren dieses Modell. Ihre Antworten können variieren, und ein korrekter Abschlusssatz beweist nicht, dass der Agent einen akzeptablen Weg genommen hat.
Ein Tool-nutzender Agent könnte den falschen Dienst auswählen, ein nicht autorisiertes Ergebnis offenlegen oder fehlerhafte Parameter senden. Er könnte zudem über eine teure oder unsichere Aufrufsequenz zu einer plausiblen Antwort gelangen.
Prompt-Änderungen schaffen ein weiteres Problem. Eine kleine Anpassung der Systemanweisungen kann Tool-Auswahl, Ablehnungsverhalten, Detailgrad der Antwort oder Aufgabenerfüllung in nicht zusammenhängenden Szenarien verändern.
Modellaktualisierungen und Änderungen von Abhängigkeiten führen ähnliche Risiken ein. Herkömmliche Unit-Tests können bestätigen, dass die Anwendung läuft, während sie einen bedeutenden Qualitätsrückgang im Verhalten übersehen.
Teams gleichen dies oft mit manuellen Prompt-Sets aus. Ein Entwickler gibt mehrere vertraute Fragen ein, liest die Antworten und führt zusammen, wenn nichts offensichtlich falsch aussieht.
Diese Methode bietet schwache Abdeckung und uneinheitliche Beurteilung. Sie liefert zudem kaum Belege dafür, welches Verhalten sich zwischen zwei Revisionen geändert hat.
Die AWS-Pipeline fügt jedem relevanten Pull Request einen gemeinsamen Bewertungspfad hinzu. Sie stellt den vorgeschlagenen Code bereit, testet diesen Code, sammelt Telemetrie und wendet dieselben Evaluatoren an.
AgentCore arbeitet mit OpenTelemetry-Spans, strukturierten Aufzeichnungen von Modellaufrufen, Tool-Aktivität und anderen Vorgängen innerhalb einer Interaktion. AgentCore Observability sendet diese Traces an CloudWatch.
Für die bedarfsgesteuerte Bewertung wählt die Pipeline Spans aus einer bestimmten Sitzung aus und übergibt sie an den Bewertungsservice. Die Bewertungsmodi umfassen außerdem Online-Monitoring und asynchrone Batch-Analysen.
Diese Unterscheidung ist für Auslieferungsteams wichtig. Die bedarfsgesteuerte Bewertung eignet sich für einen Pull Request, weil sie eine kleine, kontrollierte Menge von Interaktionen adressiert und detaillierte Bewertungen zurückgibt.
Die Online-Bewertung erfüllt einen anderen Zweck. Sie nimmt Stichproben des bereitgestellten Datenverkehrs und verfolgt das Verhalten nach der Veröffentlichung, wenn echte Nutzer Anfragen stellen, die ein Testdatensatz nicht vorhergesehen hat.
Die Batch-Bewertung verarbeitet größere Sitzungsmengen. Sie eignet sich besser für Basislinienvergleiche, regelmäßige Audits und Analysen vor gegenüber nach einer Änderung.
Die Pull-Request-Schranke ersetzt diese Modi nicht. Sie verlagert den frühesten messbaren Kontrollpunkt näher an die Codeänderung.
Dieser Ansatz verändert auch, wer auf eine Regression reagieren muss. Ohne Schranke finden Qualitätsteams oder Nutzer das Problem oft erst nach der Bereitstellung.
Mit einem erforderlichen GitHub-Check muss der Autor das fehlgeschlagene Verhalten vor dem Zusammenführen beheben. Das Feedback trifft ein, während die relevanten Code- und Prompt-Entscheidungen noch präsent sind.
Dies ist besonders nützlich für Teams, die gemeinsame Agenten pflegen. Eine Antwortänderung, die für einen Entwickler akzeptabel aussieht, kann einen Tool-Workflow einer anderen Gruppe beeinträchtigen.
Ein kuratierter Bewertungsdatensatz kann diese Erwartungen bewahren. Er wird zu einer ausführbaren Aufzeichnung der Aufgaben, die der Agent weiterhin erfüllen muss.
Entwickler benötigen weiterhin Zugriff auf den unterstützenden Kontext hinter diesen Erwartungen. Eine Engineering-Wissensdatenbank kann Teams helfen, Bewertungsfälle mit Spezifikationen, Vorfällen und Designentscheidungen zu verbinden.
Der größere Wandel ist organisatorisch. Agentenqualität wird Teil der Definition einer zusammenführbaren Änderung, statt einer optionalen Prüfung, die erfolgt, wenn jemand genügend Zeit hat.
OAuth macht End-to-End-Tests schwieriger als die Bewertung
Der schwierige Teil besteht nicht darin, eine Bewertungsnote anzufordern. Es geht darum, den vollständigen Tool-Pfad eines geschützten Agenten in einem Headless-CI-Runner nachzubilden.
Die Referenzarchitektur platziert sowohl den Agenten als auch den MCP-Server hinter Cognito. Interaktive Nutzer authentifizieren sich über einen Authorization-Code-Flow und erhalten Tokens mit Scopes und benutzerdefinierten Rollen-Claims.
Diese Rollen bestimmen, auf welche MCP-Tools ein Nutzer zugreifen kann. Ein Finanznutzer und ein HR-Nutzer sollten nicht automatisch dieselben Geschäftsfunktionen erhalten.
GitHub Actions hat keinen interaktiven Nutzer. Es kann keinen Zustimmungsbildschirm öffnen, keinen Browser-Login abschließen und keinen Rollenkontext einer Person durch den Test tragen.
AWS stellt drei Möglichkeiten vor, mit dieser Diskrepanz umzugehen. Jede validiert einen anderen Teil des Systems.
Der erste Ansatz bewertet gespeicherte Traces. Ein Staging-Prozess ruft den Agenten im Voraus auf, erfasst repräsentative Telemetrie und speichert diese Traces als Test-Fixtures.
Pull-Request-Jobs bewerten die Fixtures, ohne einen Live-Agenten oder MCP-Server aufzurufen. Dieser Ansatz ist vorhersehbar und vermeidet das Authentifizierungsproblem in CI.
Er hat jedoch eine erhebliche Einschränkung. Die Bewertungen beschreiben zuvor erfasstes Verhalten, nicht zwingend den Agentencode im aktuellen Pull Request.
Gespeicherte Traces können Änderungen an Evaluatoren validieren oder eine historische Basislinie erhalten. Sie können nicht beweisen, dass neu geänderter Runtime-Code weiterhin die erwartete Ausführung erzeugt.
Der zweite Ansatz verwendet ein dediziertes Servicekonto. Ein Operator schließt die interaktive Autorisierung einmal ab und speichert dessen Refresh-Token in einem Secrets Manager.
CI kann dann als bekannter Nutzer mit definierten Rollen agieren. Damit lassen sich Autorisierungsgrenzen und Tool-Zugriff für eine bestimmte Identität testen.
Refresh-Tokens laufen ab oder werden ungültig. Teams benötigen Rotation, erneute Autorisierung und eine sorgfältige Kontrolle über die Berechtigungen des Kontos.
Die AWS-Implementierung wählt einen dritten Weg: Machine-to-Machine-Authentifizierung. Cognito stellt über den OAuth-Grant client_credentials einen Token aus.
Das Bewertungsskript sendet die Client-ID, das Client-Secret und den angeforderten Scope an den Token-Endpunkt von Cognito. Anschließend ruft es AgentCore Runtime über HTTPS mit dem zurückgegebenen Bearer-Token auf.
Die MCP-Middleware unterscheidet diese Tokens von Nutzertokens. Machine-Tokens haben Scopes, aber keine benutzerdefinierten Rollen-Claims; daher erlaubt das Beispiel ihnen den Zugriff auf jedes Tool.
Interaktive Tokens enthalten weiterhin Rollen, und der MCP-Server erzwingt für diese Nutzer Einschränkungen auf Tool-Ebene. Derselbe Cognito-Pool unterstützt somit sowohl CI-Zugriff als auch menschliche Autorisierung.
Dieses Design ermöglicht Live-End-to-End-Tests des Codes im Pull Request. Der Agent kann den bereitgestellten MCP-Server aufrufen und neue Traces zur Bewertung erzeugen.
Es testet jedoch nicht die Durchsetzung von Rollen. Die CI-Identität umgeht diese Rollenprüfungen absichtlich.
Diese Grenze ist die wichtigste Einschränkung der Architektur. Eine erfolgreiche Pipeline zeigt, dass die Maschinenidentität die bewerteten Aufgaben abschließen kann. Sie zeigt nicht, dass FinanceUser und HRUser unterschiedliche autorisierte Ergebnisse erhalten.
Teams, die beide Formen der Absicherung benötigen, müssen separate Autorisierungstests ergänzen. Sie können Service Accounts mit spezifischen Rollen oder direkte Tests gegen die MCP-Middleware verwenden.
Die Maschinenanmeldedaten werden damit ebenfalls zu einem sensiblen Asset. AWS zufolge sollten sie ausschließlich von der CI-Pipeline und der Agenten-Laufzeitumgebung abgerufen werden können.
Diese Aussage hängt von Implementierungsdetails ab. Repository-Berechtigungen, Workflow-Freigaben, IAM-Richtlinien, Offenlegung von Secrets, Fork-Verhalten und Log-Redaktion beeinflussen allesamt die tatsächliche Sicherheitsgrenze.
Die OIDC-Verbindung von GitHub schützt die AWS-Seite vor langlebigen Repository-Anmeldedaten. Sie beseitigt jedoch nicht jedes Secret, weil der OAuth-Client weiterhin ein Client Secret verwendet.
Auch die IAM-Rolle sollte dem Prinzip der geringsten Berechtigung folgen. Weitreichender Bereitstellungszugriff auf Cognito, ECR, CDK-Ressourcen, Bedrock und AgentCore kann mehr Befugnisse schaffen, als ein gewöhnlicher Pull-Request-Job benötigt.
Umgebungsschutzmaßnahmen können das Risiko begrenzen. Teams können einschränken, welche Branches und Workflows die Rolle übernehmen dürfen, für nicht vertrauenswürdige Änderungen eine Freigabe verlangen und Bereitstellungsrollen von Evaluierungsidentitäten trennen.
Die Architektur testet somit Agentenverhalten und CI-Integration gemeinsam. Die Korrektheit der Autorisierung bleibt ein separates Abnahmeziel.
Das Quality Gate bewertet Traces, nicht nur Antworten
Die Evaluation mit Amazon Bedrock AgentCore ist relevant, weil sie den Weg eines Agenten durch eine Aufgabe beurteilen kann, nicht nur dessen finalen Text.
Das Evaluierungsskript verwendet das AgentCore-Starter-Toolkit, um die relevanten CloudWatch-Traces zu erfassen. Anschließend wendet es Evaluatoren auf die ausgewählte Session an.
Die rohe Evaluate API akzeptiert sessionSpans, eine Sammlung von Telemetrie-Spans, die zu einer Session gehören. AWS warnt, dass das Vermischen von Spans aus mehreren Sessions einen Validierungsfehler erzeugt.
Diese Session-Grenze erlaubt es dem Evaluator, eine Interaktion zu rekonstruieren. Er kann Nutzereingaben, Modellausgaben, ausgewählte Tools, Tool-Parameter und die daraus resultierende Antwort prüfen.
GoalSuccessRate arbeitet auf Session-Ebene. Die Metrik fragt, ob die gesamte Interaktion das erreicht hat, was der Nutzer angefordert hat.
Correctness untersucht die Antwort auf Trace-Ebene. Sie kann eine erwartete Antwort verwenden, wenn der Test eine solche bereitstellt.
ToolSelectionAccuracy und ToolParameterAccuracy arbeiten auf Tool-Call-Ebene. Sie unterscheiden zwischen der Auswahl der richtigen Operation und deren korrektem Aufruf.
Diese Trennung führte in AWS’ absichtlichem Regressionstest zu einem aufschlussreichen Ergebnis. Die Autoren änderten den System Prompt so, dass der Agent stets eine wenig hilfreiche Ablehnung zurückgab.
GoalSuccessRate fiel auf 0.0. Correctness erhielt ebenfalls 0.0, und ToolParameterAccuracy lag bei 0.0.
ToolSelectionAccuracy erreichte weiterhin 1.0. Offenbar konnte der Agent ein geeignetes Tool identifizieren, obwohl er an der Gesamtanfrage scheiterte.
Deshalb kann eine einzelne aggregierte Kennzahl Probleme verschleiern. Verschiedene Evaluatoren erfassen unabhängige Dimensionen, und ein bestandener Wert kann nicht jedes fehlgeschlagene Verhalten ausgleichen.
Nachdem die Autoren den vorgesehenen System Prompt wiederhergestellt hatten, kehrte GoalSuccessRate auf 1.0 zurück. Correctness erreichte 0.9, während beide Tool-Metriken 1.0 erzielten.
Damit überschritten alle vier den Beispiel-Schwellenwert von 0.8. GitHub gab den Pull Request frei.
AgentCore akzeptiert außerdem Referenzeingaben für Tests, die ein erwartetes Verhalten erfordern. Diese Eingaben können eine erwartete Antwort, natürlichsprachliche Assertions oder eine erwartete Tool-Trajektorie enthalten.
Eine Trajektorie beschreibt die Abfolge der Tools, die ein Agent aufrufen sollte. AWS bietet Evaluatoren für exakte Reihenfolge, richtige Reihenfolge und beliebige Reihenfolge für unterschiedliche Workflow-Anforderungen.
Ein Test mit exakter Reihenfolge passt zu einem Prozess, bei dem jeder Schritt vom vorherigen abhängt. Ein Test mit beliebiger Reihenfolge eignet sich für unabhängige Abrufoperationen, deren Abfolge die Korrektheit nicht beeinflusst.
Der Dienst unterstützt auch benutzerdefinierte Evaluatoren. Teams können eigene Anweisungen, ein Bewertungsmodell und eine Bewertungsskala für domänenspezifische Anforderungen festlegen.
Codebasierte Evaluatoren bieten eine deterministischere Option. Sie rufen eine AWS Lambda-Funktion auf, die Schemas, Muster, Schlüsselwörter oder Geschäftsregeln prüfen kann.
Diese Kombination ist wichtig, weil nicht jede Anforderung eine Modellbewertung benötigt. JSON-Validität, verbotene Felder, maximale Aufrufzahlen und exakte Kennungen lassen sich häufig mit gewöhnlichem Code prüfen.
Laut dem Leitfaden für benutzerdefinierte Evaluatoren können Evaluatoren auf Session-, Trace- oder Tool-Call-Ebene arbeiten. Benutzerdefinierte Logik kann ein Modell oder eine Lambda-Funktion verwenden.
Ein praktisches Gate sollte den Evaluatortyp auf die jeweilige Anforderung abstimmen. Modellbasierte Bewertungen eignen sich für semantische Eigenschaften wie Relevanz, Aufgabenerfolg oder Faktentreue.
Deterministischer Code eignet sich für binäre Einschränkungen. Tool-Trajektorienprüfungen passen zu der erwarteten Workflow-Struktur.
Das beste Signal entsteht durch die Kombination dieser Methoden. Eine Antwort kann semantisch korrekt sein und dennoch ein Schema verletzen, und ein gültiges Schema kann weiterhin eine irrelevante Antwort enthalten.
Auch Ground Truth verdient einen sorgfältigen Einsatz. Nicht jede akzeptable Antwort hat genau eine korrekte Formulierung, insbesondere bei Zusammenfassungen oder offenen Analysen.
Assertions können die Fakten oder Verhaltensweisen ausdrücken, die enthalten sein müssen, ohne eine einzige Antwort vorzuschreiben. Erwartete Trajektorien können Tool-Verhalten unabhängig vom Prosa-Stil festlegen.
Dadurch wird der Testsatz zu mehr als einer Sammlung von Prompts. Jedes Szenario kann definieren, was Erfolg auf Antwort-, Aufgaben- und Tool-Ebene bedeutet.
Auch ein bestandener Wert hat blinde Flecken
Das Gate erkennt definierte Regressionen, doch seine Zuverlässigkeit hängt von Testabdeckung, Bewertungsstabilität, Identitätsdesign und operativem Timing ab.
AWS zufolge dauert die vollständige Pipeline etwa 10 Minuten. Bereitstellung, Start der Laufzeitumgebung, Trace-Propagation und modellbasierte Evaluation tragen zu dieser Dauer bei.
Dieses Timing ist für viele Pull Requests akzeptabel. Für einen lokalen Pre-Commit-Check ist es zu langsam und in Repositories mit häufigen Updates möglicherweise kostspielig.
Die Verfügbarkeit von Traces bringt zusätzliche Unsicherheit. AWS beobachtete nach der Agenteninvokation Propagation-Verzögerungen von 30 bis 90 Sekunden.
Das Referenzskript versucht es alle 30 Sekunden erneut, bis zu 10 Minuten lang. Eine sofortige CloudWatch-Abfrage kann daher einen scheinbaren Fehler erzeugen, bevor der Trace vorhanden ist.
Die Laufzeitarchitektur schafft eine weitere Implementierungshürde. AgentCore Runtime erfordert ARM64-Container-Images, während standardmäßige von GitHub gehostete Runner x86-64-Prozessoren verwenden.
Der Workflow nutzt QEMU und Docker Buildx für die plattformübergreifende Image-Erstellung. Diese Anforderung verlängert die Build-Zeit und führt einen weiteren möglichen Fehlerpunkt ein, der nichts mit der Agentenqualität zu tun hat.
Die folgenreichste Einschränkung ergibt sich aus modellbasierten Bewertungen. Ein LLM-Evaluator kann leicht unterschiedliche Werte vergeben, wenn er denselben Trace mehrfach beurteilt.
Ein strenger Grenzwert kann daher bei Pull Requests nahe dem Schwellenwert zu instabilen Ergebnissen führen. Ein Durchlauf kann mit 0.81 bestehen, während ein anderer mit 0.79 scheitert, ohne dass es einen bedeutenden Codeunterschied gibt.
AWS empfiehlt, zwischen dem Abnahmeschwellenwert und dem gewünschten Zuverlässigkeitsziel einen Puffer zu lassen. Teams sollten außerdem die Varianz der Evaluatoren messen, bevor sie eine Prüfung verpflichtend machen.
Wiederholte Durchläufe können diese Varianz schätzen, erhöhen aber zugleich die Nutzung der Evaluation. Das Referenzbeispiel verwendet vier Evaluatoren für fünf Prompts und erzeugt damit 20 Aufrufe des Bewertungsmodells pro Pull Request.
Die Quelle nennt keinen Preis für diese Aufrufe. Sie empfiehlt Teams jedoch, die Bedrock-Nutzung zu überwachen, wenn Repositories und Datensätze wachsen.
Die Testabdeckung stellt ein vertrautes, aber schärferes Problem dar. Ein Quality Gate misst nur Szenarien, die in seinem Datensatz enthalten sind.
Vier oder fünf praktische Prompts können nicht jede Produktionsanfrage, jeden Autorisierungsstatus, jeden Fehlermodus, jede Sprache oder jede adversarielle Eingabe abbilden.
Das Machine Token des Beispiels kann auf jedes Tool zugreifen. Daher beweist der End-to-End-Durchlauf nicht, dass rollenbeschränkte Tools gegenüber gewöhnlichen Nutzern geschützt bleiben.
Ein breiter Score kann zudem ungleichmäßige Leistung verbergen. Ein Gesamtdurchschnitt kann bestehen, während ein kritisches Szenario scheitert.
Aufgaben mit hohem Risiko sollten Anforderungen auf Szenarioebene haben. Eine Gehaltsabrechnungsaktion, Kontolöschung oder Abfrage personenbezogener Daten sollte sich keinen Erfolg von mehreren einfachen Rechenaufgaben leihen.
Auch Metriken benötigen Verantwortliche. Entwickler müssen wissen, wer Änderungen an Schwellenwerten genehmigt, neue Szenarien ergänzt und Unstimmigkeiten zwischen Evaluatoren untersucht.
Andernfalls kann ein fehlschlagendes Gate Druck erzeugen, den Schwellenwert zu senken. Die Organisation erhält dann die Auslieferungsgeschwindigkeit, indem sie die Messung schwächt.
Falsche Sicherheit ist ein weiteres Risiko. Ein grüner Check zeigt, dass die getestete Version zu einem Zeitpunkt bestimmte Kriterien erfüllt hat.
Er zertifiziert nicht jede Antwort, beseitigt keine Prompt Injection und validiert keine Infrastruktur außerhalb des bereitgestellten Test-Stacks. Er ersetzt auch keine Sicherheitsprüfung.
Produktions-Telemetrie bleibt unverzichtbar, weil Nutzer Kombinationen finden werden, die einem kuratierten Datensatz entgangen sind. Die Online-Evaluation von AgentCore kann Live-Sessions stichprobenartig erfassen und Ergebnisse in CloudWatch veröffentlichen.
Die Ergebnisdokumentation besagt, dass Online-Scores als CloudWatch-Metriken erscheinen. Detaillierte Evaluierungsereignisse werden in dedizierten Log-Gruppen gespeichert.
Die Batch-Evaluation kann anschließend größere Zeiträume vor und nach Änderungen an Modell, Prompt oder Tools vergleichen. Dieser Vergleich liefert eine stärkere Ausgangsbasis als ein einzelner Pull-Request-Durchlauf.
Ein ausgereiftes System sollte diese Phasen verbinden. Produktionsfehler sollten zu neuen Evaluierungsszenarien werden, und wiederholte CI-Fehler sollten das Agentendesign beeinflussen.
Das Quality Gate ist am glaubwürdigsten, wenn sein Datensatz sich mit den Vorfällen weiterentwickelt. Ein statischer Benchmark belohnt irgendwann Vertrautheit mit dem Test statt verlässlichen Verhaltens.
Worauf nach dem ersten GitHub-Actions-Gate zu achten ist
Der nächste Test besteht darin, ob Teams diese Gates stabil, sicherheitsbewusst und repräsentativ genug gestalten können, damit sie zu verpflichtenden Checks werden.
Das erste Signal ist die Einführung von Ground-Truth- und deterministischen Evaluierungen in Pull-Request-Workflows. Die vier integrierten Metriken bieten einen nützlichen Ausgangspunkt, drücken jedoch nicht jede Geschäftsregel aus.
Beobachten Sie, ob Teams erwartete Antworten, Assertions und Tool-Trajektorien für besonders wertvolle Szenarien ergänzen. Eine verstärkte Nutzung Lambda-basierter Prüfungen würde zeigen, dass die Agentenevaluation zu gewöhnlicher Softwareverifikation wird.
Diese Entwicklung würde die Argumente für die Evaluation mit Amazon Bedrock AgentCore stärken. Sie würde die Abhängigkeit von einem einzelnen Bewertungsmodell verringern und manche Fehler leichter reproduzierbar machen.
Das zweite Signal ist rollenbewusste CI-Abdeckung. AWS benennt die Einschränkung des Machine Tokens offen, da der gewählte Ablauf Prüfungen von Nutzerrollen umgeht.
Teams sollten Muster veröffentlichen, die unterschiedliche Nutzeridentitäten testen, ohne fragile Refresh-Token-Operationen zu erzeugen. Service Accounts, direkte Autorisierungstests und isolierte Test-Tenants sind plausible Wege.
Wenn rollenspezifische Prüfungen üblich werden, wird die Architektur einer vollständigen End-to-End-Absicherung näherkommen. Wenn sie getrennt bleiben oder fehlen, sagt ein grüner Agenten-Score wenig über die Korrektheit der Autorisierung aus.
Das dritte Signal ist die Verbindung zwischen Pull-Request-Gates und Produktionsergebnissen. Ein kleiner Entwicklungsdatensatz kann ohne Rückmeldungen aus realen Sessions nicht repräsentativ bleiben.
Achten Sie auf Workflows, die niedrig bewertete Produktions-Traces in überprüfte Regressionsfälle überführen. Online-Monitoring sollte Fehler entdecken, während kuratierte CI-Tests verhindern, dass diese Fehler zurückkehren.
Auch die Tools von AWS zur Datensatz-Evaluation sind eine relevante Entwicklung. Ihre Dataset Runner können Agenten aufrufen, auf Telemetrie warten und Szenarien über einen koordinierten Prozess evaluieren.
Eine breitere Einführung würde die maßgeschneiderte Orchestrierung reduzieren, die derzeit im Referenz-Workflow sichtbar ist. Zudem würden sich größere, versionierte Evaluierungssätze leichter pflegen lassen.
Für Entwickler lautet die praktische Frage nicht mehr, ob Agentenantworten getestet werden sollten. Entscheidend ist, welche Verhaltensweisen einen Merge blockieren müssen, welche überwacht werden sollten und welche eine deterministische Durchsetzung erfordern.
Beginnen Sie mit Fehlern, die einen Rollback, einen Sicherheitsvorfall oder einen unterbrochenen Geschäftsprozess verursachen würden. Geben Sie jedem einen konkreten Anwendungsfall und eine Evaluierungsmethode, die seinem Risiko entspricht.
Bringen Sie den Agenten anschließend gezielt zum Scheitern und bestätigen Sie, dass die Sperre aus dem erwarteten Grund greift. Eine Prüfung wird erst dann vertrauenswürdig, wenn sie eine bekannte Regression erkennt.
Amazon hat einen glaubwürdigen Weg von Prompt-Tests zu verpflichtenden GitHub-Statusprüfungen aufgezeigt. Der nächste Schritt liegt bei den Engineering-Teams: Definieren Sie das Verhalten, das sie nicht ausliefern wollen, kodieren Sie es und halten Sie diese Definition aktuell.
