Führen Sie einen A/B Test mit zielbasiertem Routing durch
Verwenden Sie das zielbasierte Routingmuster, wenn die Änderung, die Sie testen, Codeänderungen, ein Framework-Upgrade oder eine völlig andere Agentenimplementierung beinhaltet. Target-based Beim Routing wird der Datenverkehr zwischen mehreren Versionen derselben AgentCore Runtime (benannte Endpunkte) oder zwischen völlig unterschiedlichen AgentCore Runtimes weitergeleitet. Das AgentCore Gateway registriert jeden Endpunkt als separates Ziel und leitet jede Sitzung auf der Grundlage der Datenverkehrsgewichte des A/B Tests an den einen oder anderen Endpunkt weiter.
Schlüsselkonfiguration für zielbasierte A/B Tests:
-
Variantenkonfiguration:
variantConfiguration.targetmit dem AgentCore Gateway-Zielnamen -
Testkonfiguration:
perVariantOnlineEvaluationConfig(eine Online-Evaluierungskonfiguration pro Variante, da jeder Endpunkt seine eigene Protokollgruppe hat) -
Gateway-Filter:
gatewayFilter.targetPathslegt fest, welche AgentCore Gateway-Pfade der A/B Test abfängt
In dieser exemplarischen Vorgehensweise werden zwei Versionen des Kundenserviceagenten bereitgestellt — eine mit Claude Sonnet (Steuerung) und eine mit Claude Opus (Behandlung). Sie erstellt benannte Endpunkte für jede Version, erstellt einen A/B Test, sendet Traffic, überprüft die Ergebnisse und stellt den Gewinner bereit.
Anmerkung
Diese exemplarische Vorgehensweise richtet sich an Agenten, die auf einer Runtime gehostet werden. AgentCore Wenn Ihr Agent außerhalb einer AgentCore Runtime ausgeführt wird (ein Agent eines Drittanbieters oder ein selbst gehosteter Agent — z. B. auf AWS Lambda), finden Sie weitere Informationen unter Führen Sie stattdessen einen A/B Test für außerhalb von AgentCore gehostete Agenten durch.
Einen ausführlichen Vergleich der A/B Testmuster finden Sie unter Ein Muster auswählen.
Schritt 1: Erstellen Sie das Projekt
Erstellen Sie das Projekt mit der AgentCore CLI:
agentcore create --name ABTestTargetBased --no-agent cd ABTestTargetBased
Schritt 2: Fügen Sie die Laufzeit hinzu
Fügen Sie die Agenten-Laufzeit hinzu. Sie werden zwei Versionen dieser Runtime bereitstellen — eine für die Steuerung und eine für die Behandlung — und dann benannte Endpunkte erstellen, um jeder Version einen Alias zu geben.
agentcore add agent \ --name csAgent \ --language Python \ --framework Strands \ --model-provider Bedrock \ --memory none \ --build CodeZip
Struktur des Projekts:
ABTestTargetBased/
├── agentcore/
│ ├── agentcore.json
│ ├── aws-targets.json
│ └── cdk/
└── app/
└── csAgent/
├── main.py
└── pyproject.toml
Schritt 3: Implementieren Sie Kontroll- und Behandlungsversionen
Durch die Kontrollversion ersetzen app/csAgent/main.py (mit Claude Sonnet):
"""Customer support agent — control variant.""" from strands import Agent, tool from strands.models.bedrock import BedrockModel from bedrock_agentcore.runtime import BedrockAgentCoreApp app = BedrockAgentCoreApp() MODEL_ID = "global.anthropic.claude-sonnet-4-5-20250929-v1:0" SYSTEM_PROMPT = "You are a helpful customer support assistant for Acme Store." @tool def lookup_order(order_id: str) -> str: """Look up an order by ID.""" orders = { "ORD-1001": {"status": "delivered", "item": "Blue T-Shirt", "total": "$29.99"}, "ORD-1002": {"status": "in_transit", "item": "Running Shoes", "est_delivery": "2026-04-05"}, "ORD-1003": {"status": "delayed", "item": "Wireless Headphones", "days_late": 5}, } return str(orders.get(order_id, {"error": f"Order {order_id} not found"})) @tool def initiate_return(order_id: str, reason: str) -> str: """Initiate a return for an order.""" return f"Return initiated for {order_id}. Reason: {reason}. Return label sent to customer email." @tool def apply_discount(order_id: str, discount_percent: int, reason: str) -> str: """Apply a discount to an order.""" return f"Applied {discount_percent}% discount to {order_id}. Reason: {reason}." agent = Agent( model=BedrockModel(model_id=MODEL_ID), tools=[lookup_order, initiate_return, apply_discount], system_prompt=SYSTEM_PROMPT, ) @app.entrypoint def invoke(payload, context): result = agent(payload.get("prompt", "Hello")) return {"response": result.message["content"][0]["text"]} if __name__ == "__main__": app.run()
app/csAgent/pyproject.tomlAbhängigkeiten aktualisieren:
dependencies = [ "aws-opentelemetry-distro", "bedrock-agentcore >= 1.8.0", "boto3", "botocore[crt] >= 1.35.0", "strands-agents[otel] >= 1.13.0", "opentelemetry-distro", "opentelemetry-instrumentation", ]
Stellen Sie die Kontrollversion bereit (dadurch wird Version 1 erstellt):
agentcore deploy
Aktualisieren Sie nunmain.py, um ein anderes Modell für die Behandlungsvariante zu verwenden, und stellen Sie es bereit (dadurch wird Version 2 erstellt):
MODEL_ID = "global.anthropic.claude-opus-4-6-v1"
agentcore deploy
Erstellen Sie benannte Endpunkte für jede Version und stellen Sie Folgendes bereit:
agentcore add runtime-endpoint \ --runtime csAgent \ --endpoint control \ --version 1 \ --description "Control variant — Claude Sonnet" agentcore add runtime-endpoint \ --runtime csAgent \ --endpoint treatment \ --version 2 \ --description "Treatment variant — Claude Opus" agentcore deploy
Sie haben jetzt:
-
Runtime-Endpunkt
control— Bereitstellung von Version 1 mit Claude Sonnet. -
Runtime-Endpunkt
treatment— Bereitstellung von Version 2 mit Claude Opus.
Stellen Sie sicher, dass die Runtime funktioniert:
agentcore invoke --runtime csAgent --prompt "What is the status of order ORD-1003?"
Sie haben jetzt:
-
Runtime-Endpunkt
control— Bereitstellung von Version 1 mit Claude Sonnet. -
Runtime-Endpunkt
treatment— Bereitstellung von Version 2 mit Claude Opus.
Schritt 4: Erstellen Sie Online-Testkonfigurationen
Jeder Endpunkt hat seine eigene Protokollgruppe (der Name der Protokollgruppe endet mit dem Endpunktnamen). Sie benötigen also eine Online-Evaluierungskonfiguration pro Variante:
agentcore add online-eval \ --name controlEvalTb \ --runtime csAgent \ --endpoint control \ --evaluator "Builtin.Helpfulness" \ --sampling-rate 100.0 \ --enable-on-create agentcore add online-eval \ --name treatmentEvalTb \ --runtime csAgent \ --endpoint treatment \ --evaluator "Builtin.Helpfulness" \ --sampling-rate 100.0 \ --enable-on-create agentcore deploy
Notieren Sie sich nach jeder Bereitstellung den ARN für die Online-Evaluierungskonfiguration — Sie benötigen beide, wenn Sie den A/B Test erstellen.
Weitere Informationen zu den Evaluator-Optionen und der Konfiguration finden Sie unter Online-Evaluierung erstellen.
Schritt 5: Erstellen Sie das Gateway und die Ziele
Ein zielbasierter A/B Test leitet den Datenverkehr über ein AgentCore Gateway, sodass das Gateway und seine beiden Ziele bereits bereitgestellt sein müssen, bevor Sie den Test starten. Fügen Sie ein Gateway hinzu und registrieren Sie jeden Runtime-Endpunkt als http-runtime Ziel. Stellen Sie dann Folgendes bereit:
agentcore add gateway --name csGateway agentcore add gateway-target \ --name customer-support-control \ --gateway csGateway \ --type http-runtime \ --runtime csAgent \ --runtime-endpoint control agentcore add gateway-target \ --name customer-support-treatment \ --gateway csGateway \ --type http-runtime \ --runtime csAgent \ --runtime-endpoint treatment agentcore deploy
Schritt 6: Erstellen Sie den A/B Test
Starten Sie den A/B Test mitagentcore run ab-test. Jede Variante verweist auf eines der Gateway-Ziele, die Sie erstellt haben, und hat ihre eigene Online-Evaluierungskonfiguration. Der Befehl initiiert den Test direkt auf dem Service für das bereits bereitgestellte Gateway.
Beispiel
Schritt 7: Senden Sie den Datenverkehr über das AgentCore Gateway
Nachdem der A/B Test ausgeführt wurde, senden Sie den Datenverkehr über den AgentCore Gateway-HTTP-Endpunkt. Das AgentCore Gateway weist jede Anfrage auf der Grundlage der Runtime-Sitzungs-ID einer Variante (Kontrolle oder Behandlung) zu.
Wie funktioniert die Variantenzuweisung
Das AgentCore Gateway verwendet den X-Amzn-Bedrock-AgentCore-Runtime-Session-Id Header, um zu bestimmen, an welches Ziel der Verkehr weitergeleitet werden soll. Dieser Header ist optional — wenn Sie ihn nicht angeben, generiert die Laufzeit automatisch eine Sitzungs-ID. Das AgentCore Gateway verwendet dann die Sitzungs-ID (unabhängig davon, ob Sie sie angegeben haben oder von der Runtime generiert wurde), um die Anfrage einer Variante zuzuweisen, die auf Ihren konfigurierten Verkehrsgewichten basiert.
Die Sitzungszuweisung ist dauerhaft: Sobald einer Variante eine Sitzungs-ID zugewiesen wurde, werden alle nachfolgenden Anfragen mit derselben Sitzungs-ID an dasselbe Ziel weitergeleitet. Auf diese Weise wird ein einheitliches Erlebnis innerhalb einer Sitzung gewährleistet und gleichzeitig neue Sitzungen entsprechend Ihrer Traffic-Verteilung auf verschiedene Varianten verteilt.
Generieren Sie Traffic zum Testen
Speichern Sie das folgende Skript unter <gateway-id> und ersetzen Sie es <target-name> mit den Werten aus Ihrer Bereitstellungsausgabe. loadgen.sh Sie können auch die vollständige Aufruf-URL kopieren vonagentcore view ab-test <ab-test-id>:
#!/bin/bash export AWS_ACCESS_KEY_ID=$(aws configure get aws_access_key_id) export AWS_SECRET_ACCESS_KEY=$(aws configure get aws_secret_access_key) export AWS_SESSION_TOKEN=$(aws configure get aws_session_token) GATEWAY_URL="https://<gateway-id>.gateway.bedrock-agentcore.us-west-2.amazonaws.com/<target-name>/invocations" PROMPTS=( "What is the status of order ORD-1003?" "I want to return order ORD-1001, it doesn't fit." "My order ORD-1003 is late. Can I get a discount?" "Where is my order ORD-1002?" "I need help with a return for order ORD-1001. The color is wrong." "Can you check on order ORD-1003? I've been waiting forever." "I'd like to cancel order ORD-1002 if it hasn't shipped yet." "Order ORD-1003 is delayed again. This is unacceptable." "What's your return policy for order ORD-1001?" "My headphones order ORD-1003 still hasn't arrived. What can you do?" ) for i in $(seq 1 30); do PROMPT="${PROMPTS[$(( (i - 1) % ${#PROMPTS[@]} ))]}" echo "=== Request $i: $PROMPT ===" curl -s --aws-sigv4 "aws:amz:us-west-2:bedrock-agentcore" \ --user "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY" \ -H "x-amz-security-token: $AWS_SESSION_TOKEN" \ -H "Content-Type: application/json" \ -H "X-Amzn-Bedrock-AgentCore-Runtime-Session-Id: $(uuidgen)" \ -d "{\"prompt\": \"$PROMPT\"}" \ -X POST \ "$GATEWAY_URL" echo "" sleep 2 done
Führen Sie das Skript aus:
bash loadgen.sh
Schritt 8: Ergebnisse erzielen
Fragen Sie den A/B Test ab, um die Ergebnisse zu überwachen, wenn die Stichprobengröße zunimmt. Umfragen haben keinen Einfluss auf die statistische Validität.
Beispiel
Anmerkung
Wie lange es dauert, bis die Ergebnisse angezeigt werden, hängt in erster Linie vom Sitzungs-Timeout ab, das in Ihren Online-Testkonfigurationen konfiguriert wurde. Eine Sitzung gilt als abgeschlossen, sobald innerhalb des Timeout-Fensters keine neuen Anfragen eintreffen. Nach dem Ende einer Sitzung werden die Ergebnisse in der Regel innerhalb von 15 Minuten angezeigt. Die Ergebnisse häufen sich, je mehr Sitzungen abgeschlossen sind — die statistische Signifikanz nimmt mit der Stichprobengröße zu.
Interpretation der Ergebnisse
-
p-Wert < 0,05 und positiv
percentChange: Die Behandlung ist deutlich besser als die Kontrollbehandlung. Erwägen Sie den Einsatz der Behandlung. -
p-Wert < 0,05 und negativ
percentChange: Die Behandlung ist deutlich schlechter. Behalte die Kontrolle. -
p-Wert >= 0,05: Es liegen nicht genügend Beweise vor, um auf einen Unterschied schließen zu können. Fahren Sie mit der Probenentnahme fort oder erhöhen Sie die Besucherzahlen zur Behandlung.
-
Überprüfen Sie alle Gutachter: Eine Behandlung kann eine Kennzahl verbessern, während eine andere zurückgeht. Überprüfen Sie alle Ergebnisse des Evaluators, bevor Sie eine Entscheidung treffen.
Schritt 9: Bestätigen Sie die Ergebnisse und beenden Sie den Test A/B
Sobald der A/B Test statistische Signifikanz erreicht hat, überprüfen Sie die Ergebnisse und beenden Sie das Experiment.
-
Signifikanz bestätigen. Vergewissern Sie sich, dass der Prüfer die Behandlungsvariante positiv
percentChangebewertet hatisSignificant: true(oder bestätigen Sie, dass die Kontrolle gewonnen hat, falls die Behandlung rückläufig ist). -
Beenden Sie den Test A/B . Führen Sie
agentcore stop ab-test -i <ab-test-id>. Das Routing des Datenverkehrs wird sofort beendet und alle Anfragen werden auf das Standardziel zurückgesetzt. Weitere Informationen finden Sie unter Anzeigen, Anhalten, Fortfahren und Beenden.
Schritt 10: Setze den Gewinner ein
Nachdem Sie den A/B Test beendet haben, leiten Sie den gesamten Traffic an die Gewinnervariante weiter.
agentcore promote ab-test -i <ab-test-id> agentcore deploy
promotestoppt den A/B Test (falls er noch läuft), aktualisiert den Kontrollendpunkt so, dass er auf die Behandlungsversion verweist (z. B. Aktualisierung control von Version 1 auf Version 2), und entfernt den Behandlungsendpunkt. Führen Sie agentcore deploy den Befehl aus, um die Änderungen zu übernehmen.
Alternativ können Sie den Gewinner manuell bereitstellen, indem Sie einen der folgenden Schritte ausführen:
-
Option A: Verwenden Sie AgentCore Gateway-Routing-Regeln, um den Verkehr von beiden Zielen zum Gewinnerziel zu leiten.
-
Option B: Entfernen Sie das unterlegene Ziel vom AgentCore Gateway und leiten Sie den gesamten Verkehr an das Gewinnerziel weiter.
-
Option C: Aktualisieren Sie das unterlegene Ziel so, dass es auf den erfolgreichen Endpunkt zeigt.
Nächste Schritte
Nach dem Einsatz des Gewinners:
-
Löschen Sie den A/B Test, um Ressourcen zu bereinigen. Siehe Einen A/B Test löschen.
-
Überwachen Sie die neue Baseline. Die Online-Evaluierung setzt die Bewertungssitzungen mit der erfolgreichen Konfiguration fort. Achten Sie auf Regressionen.
-
Starte die nächste Iteration. Neue Traces aus der erfolgreichen Konfiguration bilden die Grundlage für den nächsten Empfehlungszyklus. Erfahren Sie, wie es funktioniert.
Ergebnisse verstehen
Wenn Sie aufrufenGetABTest, enthält die Antwort ein results Objekt, sobald die Aggregationspipeline genügend Sitzungen verarbeitet hat. Die Ergebnisse enthalten Metriken pro Evaluator, aufgeschlüsselt nach Varianten.
Struktur der Ergebnisse
{ "results": { "analysisTimestamp": "2026-04-30T18:45:00Z", "evaluatorMetrics": [ { "evaluatorArn": "arn:aws:bedrock-agentcore:us-west-2:123456789012:evaluator/Builtin.Helpfulness", "controlStats": { "variantName": "C", "sampleSize": 24, "mean": 0.72 }, "variantResults": [ { "variantName": "T1", "sampleSize": 6, "mean": 0.85, "absoluteChange": 0.13, "percentChange": 18.1, "pValue": 0.032, "confidenceInterval": { "lower": 0.02, "upper": 0.24 }, "isSignificant": true } ] } ] } }
Feldreferenz
| Feld | Description |
|---|---|
|
|
Wann der Dienst zuletzt Statistiken berechnet hat. |
|
|
Ein Eintrag pro Evaluator in der Online-Evaluierungskonfiguration. |
|
|
Durchschnittliche Punktzahl des Bewerters in allen Kontrollsitzungen. |
|
|
Anzahl der bewerteten Sitzungen für die Kontrollvariante. |
|
|
Durchschnittliche Bewertung des Bewerters für alle Behandlungssitzungen. |
|
|
Anzahl der bewerteten Sitzungen für die Behandlungsvariante. |
|
|
Unterschied zwischen Behandlungsmittelwert und Kontrollmittelwert. |
|
|
Prozentuale Verbesserung (positiv) oder Regression (negativ) im Vergleich zur Kontrollgruppe. |
|
|
Wahrscheinlichkeit, dass der beobachtete Unterschied auf Zufall zurückzuführen ist. Ein Wert unter 0,05 weist auf statistische Signifikanz hin. |
|
|
95% -Konfidenzintervall für die absolute Veränderung ( |
|
|
|
Fehlerbehebung
A/B Der Test zeigt nach dem Senden von Datenverkehr keine Ergebnisse
Die Ergebnisse werden nicht sofort angezeigt. Die dafür benötigte Zeit hängt vom Sitzungs-Timeout ab, das in Ihrer Konfiguration für die Online-Evaluierung konfiguriert wurde. Eine Sitzung gilt erst dann als abgeschlossen, wenn innerhalb des Timeout-Fensters keine neuen Anfragen eintreffen. Nach Ende einer Sitzung sollten Sie innerhalb von etwa 15 Minuten mit Ergebnissen rechnen.
Wenn nach diesem Fenster immer noch keine Ergebnisse angezeigt werden:
-
Überprüfen Sie die Online-Testprotokollgruppe. Die Konfiguration der Online-Evaluierung muss auf die Ausgabeprotokollgruppe des Runtime-Agenten verweisen. Wenn die Online-Evaluierungskonfiguration auf eine andere Protokollgruppe verweist (oder auf eine, die keine Spannweiten aus Ihrer Laufzeit erhält), werden Sitzungen nicht bewertet und der A/B Test wird nie zu Ergebnissen führen.
-
Überprüfen Sie den Namen der Protokollgruppe. Beim zielbasierten Routing hat jeder Endpunkt seine eigene Protokollgruppe (der Name der Protokollgruppe endet mit dem Endpunktnamen). Stellen Sie sicher, dass jede Online-Evaluierungskonfiguration auf die Protokollgruppe des richtigen Endpunkts verweist.
-
Vergewissern Sie sich, dass die Laufzeit Spans ausgibt. Suchen Sie in den CloudWatch Protokollen nach der erwarteten Protokollgruppe. Die wichtigsten Attribute, nach denen Sie für jeden Bereich suchen:
-
aws.agentcore.gateway.routing_experiment_arn -
aws.agentcore.gateway.routing_experiment_variant_name(Werte:CoderT1) -
session.id
-
-
Überprüfen Sie die Konfiguration im CLI-created Vergleich zu manuellen Konfigurationen. Wenn Sie dies verwendet haben
agentcore add online-eval --runtime <name>, konfiguriert die CLI automatisch die richtige Protokollgruppe. Wenn Sie die Online-Evaluierungskonfiguration manuell über die API erstellt haben, stellen Sie sicher, dass die AgentCore Online-EvaluierungskonfigurationdataSourceConfig.cloudWatchLogs.logGroupNamesmit der Span-Protokollgruppe Ihrer Laufzeit übereinstimmt.