

# Effectuez un A/B test pour les agents hébergés en dehors de AgentCore
<a name="ab-testing-3p-agents"></a>

Vous pouvez A/B tester un agent qui s'exécute en dehors AgentCore d'un environnement d'exécution avec un agent hébergé n'importe où, par exemple sur AWS Lambda, Amazon EKS ou Amazon ECS. Pour les agents de A/B test, la AgentCore passerelle achemine le trafic entre les variantes, l'évaluation en ligne note chaque session et le service calcule la signification statistique par variante. Lorsque votre agent n'utilise pas un AgentCore Runtime, vous devez l'instrumenter pour l'observabilité, l'enregistrer vous-même en tant que cible de AgentCore passerelle, et activer le suivi de la passerelle afin que les sessions puissent être attribuées à une variante.

A/B tests prend en charge [les ensembles de configuration avec un seul environnement d'exécution d'agent](ab-testing-config-bundle.md) ainsi que le [routage basé sur la cible avec deux points de terminaison d'agent](ab-testing-target-based.md). Cette page explique comment configurer un point de terminaison d'agent accessible par HTTP en tant que cible sur une AgentCore passerelle avec le suivi activé. Ensuite, le suivi de la AgentCore passerelle fournit l'attribution des variantes, et l'observabilité sur le point de terminaison de l'agent fournit le contenu du message pour la notation.

Cette page est un addendum pour [exécuter un A/B test avec un routage basé sur des cibles](ab-testing-target-based.md). Il couvre uniquement la configuration supplémentaire dont un agent non exécutable a besoin, en utilisant un Lambda-hosted agent (derrière une URL de fonction) comme exemple ; la même approche s'applique à tout point de terminaison d' HTTP-reachable agent que vous enregistrez en tant que cible de AgentCore passerelle, puis vous renvoie à cette page pour créer et exécuter le test.

## Conditions préalables
<a name="ab-testing-3p-prereqs"></a>

Outre les conditions [générales requises pour les A/B tests](ab-testing-prereqs.md), vous devez :

1. AgentCore le suivi de passerelle est activé sur la passerelle afin que les sessions puissent être attribuées à une variante.

1. Votre agent a été ajouté en tant que cible intermédiaire sur une AgentCore passerelle à l'aide d'un protocole pris en charge.

## Étape 1 : Instrument votre agent pour l' AgentCore observabilité
<a name="ab-testing-3p-step1-observability"></a>

**Note**  
Pour la configuration complète, suivez [Activer l'observabilité AgentCore pour les agents hébergés à l'extérieur](observability-configure.md#observability-configure-3p).

Pour un Lambda-hosted agent, attachez la [couche AWS Lambda pour OpenTelemetry](https://aws-otel.github.io/docs/getting-started/lambda#adot-lambda-layer-arns) et définissez les variables d'environnement suivantes :

```
aws lambda update-function-configuration \
  --function-name <function-name> \
  --region <region> \
  --layers <adot-python-layer-arn> \
  --environment "Variables={
    AGENT_OBSERVABILITY_ENABLED=true,
    OTEL_PROPAGATORS='baggage,xray-lambda,tracecontext',
    OTEL_PYTHON_DISTRO=aws_distro,
    OTEL_PYTHON_CONFIGURATOR=aws_configurator,
    OTEL_LOGS_EXPORTER=otlp,
    OTEL_TRACES_EXPORTER=otlp,
    OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf,
    OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED=true,
    OTEL_AWS_APPLICATION_SIGNALS_ENABLED=false,
    OTEL_EXPORTER_OTLP_LOGS_HEADERS='x-aws-log-group=/aws/bedrock-agentcore/agents/<function-name>/runtime-logs,x-aws-log-stream=runtime-logs,x-aws-metric-namespace=agentcore',
    OTEL_RESOURCE_ATTRIBUTES='service.name=<function-name>',
    AWS_LAMBDA_EXEC_WRAPPER=/opt/otel-instrument
  }"
```

Un gestionnaire Lambda minimal qui analyse la demande d'URL de la fonction et définit le bagage de session :

```
import base64, json
from strands import Agent
from strands.models.bedrock import BedrockModel
from opentelemetry import baggage, context

_model = BedrockModel(model_id="global.anthropic.claude-sonnet-4-5-20250929-v1:0")


def lambda_handler(event, _context):
    # Lambda function URL payload format 2.0: JSON body is in event["body"], no httpMethod.
    raw = event.get("body")
    if raw is not None and event.get("isBase64Encoded"):
        raw = base64.b64decode(raw).decode()
    body = json.loads(raw) if isinstance(raw, str) else (raw or event)

    session_id = _session_id(event)
    token = context.attach(baggage.set_baggage("session.id", session_id))
    try:
        agent = Agent(model=_model, system_prompt="You are a helpful assistant. Be concise.")
        result = agent(body.get("prompt", "Hello"))
    finally:
        context.detach(token)
    return {"response": str(result), "sessionId": session_id}


def _session_id(event):
    return (event.get("headers") or {}).get("x-session-id") or "default"
```

Pour le routage basé sur des cibles, déployez-le deux fois (contrôle et traitement) avec la modification que vous testez, par exemple une invite différente `model_id` ou une invite du système.

## Étape 2 : Exposez votre agent via HTTP
<a name="ab-testing-3p-step2-http"></a>

L'agent doit être accessible sur un point de terminaison HTTP que la AgentCore passerelle peut appeler. Pour l'exemple Lambda, créez une URL de fonction avec authentification IAM pour chaque fonction :

```
aws lambda create-function-url-config \
  --function-name cs-agent-control \
  --auth-type AWS_IAM \
  --region us-west-2
```

Répétez l'opération pour la fonction de traitement. (Pour un conteneur ou un agent auto-hébergé, exposez plutôt un point de terminaison HTTPS et passez à l'étape 3.)

## Étape 3 : Enregistrez votre agent en tant que cible de AgentCore passerelle
<a name="ab-testing-3p-step3-target"></a>

Enregistrez chaque point de terminaison en tant que cible **de transfert** HTTP sur une AgentCore passerelle. [Pour plus de détails sur les cibles de transfert`protocolType`, y compris les options d'adhérence et d'identification, consultez la section Cibles intermédiaires HTTP.](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-http-passthrough.html)

Pour enregistrer l'URL d'une fonction Lambda en tant que cible, définissez `protocolType` `CUSTOM` et fournissez un. `iamCredentialProvider` Le fournisseur d'informations d'identification autorise la passerelle à signer chaque demande sortante sur l'URL de la fonction en tant que service : `lambda`

**Note**  
`stickinessConfiguration`Indique à la passerelle d'utiliser l'`x-session-id`en-tête pour reconnaître les demandes qui appartiennent à la même session. Le caractère permanent des sessions permet de ne pas affecter les sessions en cours lorsque vous démarrez ou arrêtez un A/B test : la passerelle continue d'acheminer les sessions en cours vers la même cible à laquelle elles ont déjà été assignées, et n'achemine que les nouvelles sessions en fonction des poids de traitement de votre A/B test pendant le test.
Pour des raisons d'observabilité, votre agent doit également définir ce même identifiant de session dans son contexte de suivi (par exemple, en tant que `session.id` bagage). Cela permet aux évaluateurs en ligne de noter les sessions et les traces des agents, et de les attribuer au traitement de A/B test approprié.

**Example**  

```
agentcore add gateway-target \
  --name customer-support-control \
  --gateway cs-3p-abtest-gw \
  --type passthrough \
  --passthrough-endpoint https://<control-id>.lambda-url.us-west-2.on.aws/ \
  --passthrough-protocol CUSTOM \
  --stickiness-identifier '$context.header.x-session-id' \
  --stickiness-timeout 28800 \
  --signing-service lambda \
  --signing-region us-west-2
```

```
aws bedrock-agentcore-control create-gateway-target \
  --gateway-identifier cs-3p-abtest-gw-abc123 \
  --name customer-support-control \
  --region us-west-2 \
  --target-configuration '{
    "http": {
      "passthrough": {
        "endpoint": "https://<control-id>.lambda-url.us-west-2.on.aws/",
        "protocolType": "CUSTOM",
        "stickinessConfiguration": {
          "identifier": "$context.header.x-session-id",
          "timeout": 28800
        }
      }
    }
  }' \
  --credential-provider-configurations '[
    {
      "credentialProviderType": "GATEWAY_IAM_ROLE",
      "credentialProvider": {
        "iamCredentialProvider": { "service": "lambda", "region": "us-west-2" }
      }
    }
  ]'
```

Pour le routage basé sur la cible, répétez l'opération pour le point final du traitement (nommez-le`customer-support-treatment`). Interrogez chaque cible avec « `get-gateway-target` until `status` is `READY` ».

**Note**  
 `iamCredentialProvider`est requis pour une IAM-authenticated cible intermédiaire. Pour une URL de fonction Lambda définie sur`service`. `lambda` Le rôle IAM de passerelle doit avoir les deux `lambda:InvokeFunctionUrl` et `lambda:InvokeFunction` sur l'ARN de chaque fonction.

## Étape 4 : activer le suivi des AgentCore passerelles
<a name="ab-testing-3p-step4-gateway-tracing"></a>

Activez le suivi de la livraison sur la AgentCore passerelle afin qu'elle émette des plages d'attribution de variantes à. `aws/spans` Pour activer le suivi depuis la console, ouvrez la page détaillée de la passerelle et choisissez **Log deliveries and tracing** **→ Tracking** → **Enable**. Pour plus d'informations, consultez la section [Configurer le suivi de la livraison à CloudWatch](observability-configure.md#observability-configure-tracing).

Une fois que le trafic commence à circuler, chaque intervalle de passerelle contient les attributs `aws.agentcore.gateway.routing_experiment_arn` et `aws.agentcore.gateway.routing_experiment_variant_name` (par exemple, `C` ou`T1`), ainsi que le `traceId` nom de la demande. Le pipeline d'évaluation en ligne relie le span de la passerelle au span de votre agent`traceId`, c'est-à-dire la façon dont chaque session notée est attribuée à sa variante. Sans suivi de passerelle, les sessions sont toujours notées, mais elles ne peuvent pas être attribuées à une variante, et le A/B test ne produit pas de résultats par variante.

## Étape 5 : Création et exécution du A/B test
<a name="ab-testing-3p-step5-run"></a>

Votre agent est désormais une cible passerelle émettant de la télémétrie. Il reste deux étapes à franchir :

1.  **Créez une configuration d'évaluation en ligne par point de terminaison de variante.** Voir [Créer une évaluation en ligne](create-online-evaluations.md). Pour chaque configuration, utilisez le groupe de journaux d'événements `service.name` et dans lequel vous l'avez configuré[Étape 1 : Instrument votre agent pour l' AgentCore observabilité](#ab-testing-3p-step1-observability).

1.  **Créez et exécutez le A/B test.** Suivez [Exécutez un A/B test avec un routage basé sur les cibles](ab-testing-target-based.md), en commençant par l'étape **Créer le A/B test** : créer le test avec`perVariantOnlineEvaluationConfig`, envoyer du trafic, sonder les résultats, arrêter et déployer le gagnant.

Lorsque vous envoyez du trafic via la passerelle, dirigez-le vers la cible de la variante de contrôle. La passerelle divise tout le trafic arrivant vers la cible de contrôle entre les cibles de contrôle (`C`) et de traitement (`T1`) en fonction de votre configuration de A/B test.

**Example**  
Ajoutez une configuration d'évaluation en ligne par variante, en utilisant le groupe du journal d'événements `service.name` et [Étape 1 : Instrument votre agent pour l' AgentCore observabilité](#ab-testing-3p-step1-observability) comme source de données, puis lancez le test en `target-based` mode :  

```
agentcore add online-eval \
  --name cs-control-eval \
  --evaluator Builtin.Correctness \
  --service-name customer-support-control \
  --log-group-name /aws/bedrock-agentcore/agents/cs-agent-control/runtime-logs \
  --enable-on-create

agentcore add online-eval \
  --name cs-treatment-eval \
  --evaluator Builtin.Correctness \
  --service-name customer-support-treatment \
  --log-group-name /aws/bedrock-agentcore/agents/cs-agent-treatment/runtime-logs \
  --enable-on-create

agentcore deploy

agentcore run ab-test \
  --name cs-3p-abtest \
  --gateway cs-3p-abtest-gw \
  --mode target-based \
  --control-target customer-support-control \
  --treatment-target customer-support-treatment \
  --control-online-eval cs-control-eval \
  --treatment-online-eval cs-treatment-eval \
  --control-weight 50 \
  --treatment-weight 50 \
  --wait
```
`agentcore status`À utiliser pour afficher les résultats par variante pendant l'exécution du test et `agentcore stop` pour y mettre fin.
Créez une configuration d'évaluation en ligne par variante avec`create_online_evaluation_config`. Défini sur `serviceNames` le groupe de journaux d'événements du point de terminaison `service.name` et `logGroupNames` sur son groupe de journaux d'événements. Créez ensuite le test avec`create_ab_test`, en utilisant`perVariantOnlineEvaluationConfig`. Pour l'exemple complet du boto3, y compris l'envoi de trafic, l'interrogation des résultats et l'arrêt du test, voir [Exécuter un A/B test avec un routage basé sur la cible](ab-testing-target-based.md), en commençant par l'étape **Créer** le test. A/B 

## Résolution des problèmes
<a name="ab-testing-3p-troubleshooting"></a>

### A/B le test ne montre aucun résultat après l'envoi de trafic
<a name="ab-testing-3p-no-results"></a>
+ Vérifiez que le suivi de la passerelle est activé ([Étape 4 : activer le suivi des AgentCore passerelles](#ab-testing-3p-step4-gateway-tracing)). Sans celui-ci, le pipeline d'agrégation ne peut pas attribuer de sessions à des variantes.
+ Vérifiez que chaque configuration d'évaluation en ligne `serviceNames` correspond à celle du point de terminaison `service.name` et qu'elle `logGroupNames` inclut le groupe de journaux d'événements du point de terminaison. L'évaluation en ligne se lit `aws/spans` automatiquement, vous ne la listez donc pas, mais le groupe du journal des événements (contenu du message) doit être répertorié.
+ Les résultats apparaissent lorsqu'une session est inactive pour le paramètre configuré`sessionTimeoutMinutes`, puis dans les 15 minutes qui suivent le cycle de notation suivant.