Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Commencez avec Amazon Bedrock Managed Agents (avec OpenAI) sur Runtime AgentCore
**Note**
Amazon Bedrock Managed Agents (avec OpenAI) est en version préliminaire. Les fonctionnalités et les API peuvent changer avant leur disponibilité générale.
Amazon Bedrock Managed Agents exécute le harnais OpenAI Codex sur. AWS Le harnais fait la boucle entre le modèle et les outils, maintient la session et compacte le contexte au fur et à mesure que la conversation prend de l'ampleur. Lorsque l'agent doit exécuter une commande ou travailler avec des fichiers, Bedrock Managed Agents envoie le travail vers un environnement. C'est vous qui décidez où s'exécute cet environnement.
Vous pouvez exécuter le serveur exécutif du Codex sur votre propre ordinateur pour le développement local. Pour les autres charges de travail, Bedrock Managed Agents invoque un AgentCore Runtime dans votre compte. Le Runtime donne à chaque session sa propre microVM. La session s'exécute sous un rôle d'exécution que vous contrôlez, et le Runtime peut se connecter à votre VPC afin que l'agent puisse accéder à des ressources privées. Les appels du modèle restent dans Bedrock Managed Agents, de sorte que le conteneur exécute uniquement les commandes envoyées par l'agent.
Dans ce didacticiel, vous allez effectuer les tâches suivantes :
+ Créez et déployez le Runtime avec la AgentCore CLI.
+ Démarrez une session avec le SDK OpenAI. L'agent utilise un exemple de compétence dans votre environnement d'exécution.
+ (Facultatif) Ajoutez vos propres compétences.
Les étapes 1 à 4 prennent environ 15 minutes.
Les AWS ressources que vous créez dans ce didacticiel peuvent entraîner des frais sur votre AWS compte. Ces ressources incluent le Runtime, les builds d' AWS CodeBuild images et les appels du modèle Bedrock Managed Agents. Pour en savoir plus, consultez [PricingAgentCore ](https://aws.amazon.com/bedrock/agentcore/pricing/) (Tarification). Pour arrêter les charges, retirez les ressources qui s'y trouvent[Étape 8 : nettoyer](#runtime-get-started-bma-clean-up).
## Conditions préalables
+ **Node.js 20 ans ou plus tard.** La AgentCore CLI est distribuée sous forme de package npm. Vérifiez auprès de`node --version`.
+ **uv.** L'exemple de client utilise [uv](https://docs.astral.sh/uv/) pour installer ses dépendances Python.
+ **Un AWS compte avec des informations d'identification configurées.** Pour créer un compte, consultez [Commencer à créer un AWS compte](https://docs.aws.amazon.com/accounts/latest/reference/getting-started.html). Pour configurer les informations d'identification, consultez [la section Configuration de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html).
+ **Autorisations IAM.** Votre identité a besoin d'autorisations pour effectuer des appels d' AgentCore API et pour assumer les rôles de démarrage du CDK utilisés lors du déploiement. Reportez-vous [à la section Utiliser la AgentCore CLI](runtime-permissions.md#runtime-permissions-cli). L'exemple de client a également besoin d'autorisations IAM. Consultez [Le rôle de session](#runtime-get-started-bma-session-role).
+ **Accès aux modèles.** Votre compte doit accéder au modèle `openai.gpt-5.6-luna` Bedrock Managed Agents.
La CLI crée l'image du conteneur AWS CodeBuild dans votre compte.
## Étape 1 : Création du projet
Installez la AgentCore CLI et définissez vos informations d'identification et votre région :
```
npm install -g @aws/agentcore
agentcore --version
export AWS_PROFILE=your-profile
export AWS_REGION=us-east-1
```
Créez le projet avec le `BedrockManagedAgents` framework. Vous pouvez également courir `agentcore create` sans drapeaux. Sélectionnez **Agent**, puis sélectionnez **Bedrock Managed Agents** comme framework.
```
agentcore create --name MyManagedAgent --framework BedrockManagedAgents
cd MyManagedAgent
```
Le projet contient la configuration d'exécution `agentcore/agentcore.json` et la source du conteneur`app/MyManagedAgent/`. Le conteneur s'exécute`codex exec-server`, qui se connecte aux agents gérés par Bedrock et exécute les commandes de l'agent.
Le projet configure le Runtime avec les valeurs par défaut suivantes :
+ Un délai d'inactivité de 30 minutes et une durée de vie maximale de 8 heures. Voir [Configurer les paramètres du cycle de vie](runtime-lifecycle-settings.md).
+ Un rôle d'exécution dont les autorisations sont entrées dans`policies/bma-acr-policy.json`.
### Structure du projet
```
MyManagedAgent/
├── agentcore/
│ ├── agentcore.json
│ └── cdk/
└── app/MyManagedAgent/
├── Dockerfile
├── lifecycle/server.py
├── otel/collector.yaml
├── plugins/acr-report/
├── policies/
│ ├── bma-acr-policy.json
│ ├── bma-session-trust.json
│ └── bma-session-policy.json
├── pyproject.toml
├── client.py
└── README.md
```
Fichiers clés :
+ `lifecycle/server.py`- Le serveur Lifecycle. Bedrock Managed Agents l'appelle pour démarrer `codex exec-server` dans votre session Runtime. Ne modifiez pas ce fichier.
+ `Dockerfile`- Installe Codex, l' CloudWatch agent et Python, puis copie `lifecycle/``otel/`, et `plugins/` vers. `/opt/bma`
+ `otel/collector.yaml`- Envoie les spans et les journaux du serveur exécutif à. CloudWatch
+ `plugins/acr-report/`- Un exemple de plugin avec une compétence. La compétence est enregistrée `acr-report.txt` dans l'espace de travail.
+ `policies/bma-acr-policy.json`- La politique du rôle d'exécution Runtime. Autorise `bedrock-mantle:RegisterEnvironment` et `bedrock-mantle:ConnectEnvironment`. Pour le limiter à un seul projet, passez `Resource` à`arn:aws:bedrock-mantle:::project/`.
+ `pyproject.toml`- Les dépendances de Python. Le `dev` groupe est réservé `client.py` uniquement.
+ `policies/bma-session-trust.json`et `policies/bma-session-policy.json` - La politique de confiance et les autorisations associées au rôle de session. Consultez [Le rôle de session](#runtime-get-started-bma-session-role).
+ `client.py`- Un exemple de client qui démarre une session. Vous l'exécutez à l'étape 3.
### Déployer le Runtime dans un VPC
Ajoutez les options réseau à `agentcore create` :
```
agentcore create --name MyManagedAgent --framework BedrockManagedAgents \
--network-mode VPC --vpc-id --subnets \
--security-groups
```
Le VPC doit avoir une route vers le point de terminaison Bedrock Managed Agents, car le serveur exécutif s'y connecte. La version de l'image télécharge Codex et Python, elle a donc également besoin d'un itinéraire vers Internet. Voir [Configuration AgentCore pour VPC](agentcore-vpc.md).
### Exécuter le Runtime sur les instances
Le même projet s'exécute sur le type de calcul **Instances**. Ajoutez un fournisseur de capacité au projet, puis ajoutez l'agent avec le fournisseur de capacité :
```
agentcore create --name MyManagedAgent --no-agent
cd MyManagedAgent
agentcore add capacity-provider --name MyCapacityProvider \
--subnets --security-groups \
--os LINUX_ARM64 --instance-types c7g.large
agentcore add agent --name MyManagedAgent --framework BedrockManagedAgents \
--capacity-provider MyCapacityProvider
```
Continuez ensuite avec[Étape 2 : Déploiement](#runtime-get-started-bma-deploy). `agentcore deploy`crée également le fournisseur de capacité et son rôle d'opérateur.
+ Types d'instance Use `LINUX_ARM64` et Graviton, car la construction de l'image crée une image ARM64.
+ Le fournisseur de capacité fournit le réseau. Les sous-réseaux doivent avoir une route vers le point de terminaison Bedrock Managed Agents.
Pour associer un fournisseur de capacité qui ne figure pas dans le projet, attribuez son ARN à`agentcore create --framework BedrockManagedAgents --capacity-provider `. Voir [Instances d'exécution et fournisseurs de capacité](runtime-instances.md).
## Étape 2 : Déploiement
```
agentcore deploy
agentcore status
```
La CLI crée l'image AWS CodeBuild dans votre compte et déploie le Runtime et son rôle d'exécution. Bedrock Managed Agents invoque le Runtime pour vous.
Enregistrez l'ARN d'exécution à partir de la sortie de `agentcore status` :
```
arn:aws:bedrock-agentcore:us-east-1::runtime/
```
## Étape 3 : Lancer une session
Bedrock Managed Agents utilise un rôle de session pour appeler le modèle et appeler votre Runtime. Le rôle de session n'est pas le rôle d'exécution Runtime. **Lorsque vous exécutez`client.py`, le rôle de session est créé dans votre compte.** `agentcore deploy`ne crée pas le rôle de session et `agentcore remove` ne le supprime pas. Consultez [Le rôle de session](#runtime-get-started-bma-session-role).
Exécutez le client depuis le répertoire de l'agent :
```
cd app/MyManagedAgent
uv run client.py --runtime
```
Le client crée une session et imprime l'ID de session, chaque commande avec sa sortie et la réponse de l'agent. Par défaut, l'agent utilise la `acr-report` compétence pour enregistrer des données `acr-report.txt` dans l'espace de travail.
La section suivante explique comment le client gère le rôle de session et les autorisations IAM dont vous avez besoin pour exécuter le client.
### Le rôle de session
Le rôle de session n'est pas le rôle d'exécution Runtime. `agentcore deploy`crée le rôle d'exécution avec`policies/bma-acr-policy.json`. Le client donne le rôle de session aux agents gérés de Bedrock `role_arn` sur le terrain lorsqu'il crée une session.
Lorsque vous démarrez une nouvelle session et que vous ne donnez pas`--role-arn`, le client effectue les étapes suivantes :
1. Si le rôle `BmaSessionRole-` n'existe pas, le client le crée.
1. Le client compare la politique de confiance et la politique en ligne `BmaSession` du rôle avec `policies/bma-session-trust.json` et`policies/bma-session-policy.json`. Si une politique n'est pas la même, le client écrit le fichier dans le rôle. Les fichiers sont limités au compte et à la région du Runtime.
1. Si le client change de rôle, il attend 15 secondes. IAM a besoin de ce temps avant que les agents gérés de Bedrock puissent utiliser le changement.
Pour modifier le rôle, modifiez les fichiers. Le client ne supprime pas les autres politiques que quelqu'un ajoute au rôle. Il ne vérifie pas le rôle lorsque vous donnez`--session-id`, et cela ne change pas le rôle avec lequel vous donnez`--role-arn`.
Pour la production, attribuez au client un rôle pour un Runtime et une passerelle avec`--role-arn`. Pour créer le rôle, utilisez les deux fichiers dans`policies/`. Entrez votre partition, votre région et votre identifiant de compte, puis remplacez-les ` ` par votre identifiant d'exécution et votre identifiant de passerelle. `runtime/` `gateway/*` Ne modifiez pas les fichiers du projet, car tous les projets de la région sont partagés`BmaSessionRole-`.
L'identité qui gère le client nécessite les autorisations du client Bedrock Managed `bedrock-mantle:CallWithBearerToken` Agents et `iam:PassRole` le rôle de session. Pour permettre au client de créer et de réparer le rôle, indiquez également`iam:GetRole`,,`iam:CreateRole`, `iam:UpdateAssumeRolePolicy``iam:GetRolePolicy`, et ainsi de `iam:PutRolePolicy` suite`arn:aws:iam:::role/BmaSessionRole-*`. Si vous les donnez`--role-arn`, le client n'a pas besoin de ces cinq autorisations.
Pour la politique de confiance, les autorisations associées au rôle de session et les autorisations du client, consultez la section [Rôles de sécurité et IAM](https://docs.aws.amazon.com/bedrock/latest/userguide/bedrock-managed-agents-openai-security.html) dans le guide de l'*utilisateur d'Amazon Bedrock*.
### Comment fonctionne le client
Le client utilise les `client.beta.agents` ressources du `openai` package. Bedrock Managed Agents exécute la boucle des agents.
Lorsque le client crée la session, il définit les valeurs suivantes dans `environment` :
+ `type`-`aws_bedrock_agentcore`, qui indique aux agents gérés par Bedrock d'utiliser un AgentCore Runtime.
+ `runtime_arn`- Votre temps d'exécution. La session s'exécute dans la région du Runtime.
+ `workspace_directory`- Le répertoire dans lequel l'agent exécute ses commandes. Le client utilise`/home/app/workspace`. Le serveur de cycle de vie crée le répertoire.
+ `runtime_qualifier`- Le point final du Runtime. Le client utilise`DEFAULT`.
+ `capability_directories`- Les annuaires où Bedrock Managed Agents trouve des compétences. Le client utilise`/opt/bma/plugins`.
Le client définit également `role_arn` `extra_body` le rôle de session. Le `openai` package ne contient aucun paramètre pour ce champ.
L'`provide_token`assistant utilise vos AWS informations d'identification pour obtenir un jeton porteur Amazon Bedrock de courte durée pour chaque demande.
Si vous ajoutez une passerelle au projet, indiquez son ARN à partir de la sortie de `agentcore deploy` with`--gateway`. Utilisez le drapeau uniquement pour une nouvelle session. Le client ajoute la passerelle en tant qu'`mcp`outil avec l'ARN`connector_id`. Bedrock Managed Agents appelle la passerelle avec le rôle de session. La passerelle doit prendre en charge la version `2025-03-26` MCP. Si ce n'est pas le cas, l'agent n'obtient aucun outil de passerelle et Bedrock Managed Agents n'affiche aucune erreur.
```
"""Send an input to a Bedrock Managed Agents session that uses this project's ACR."""
import argparse
import json
import time
from pathlib import Path
from typing import Any
import boto3
from aws_bedrock_token_generator import provide_token
from botocore.exceptions import ClientError
from openai import NotFoundError, OpenAI
BMA_MODEL_ID = "openai.gpt-5.6-luna"
# The agent runs its commands in this directory. The lifecycle server creates it.
WORKSPACE_DIRECTORY = "/home/app/workspace"
# Plugins and skills that the agent can use. The image has the acr-report plugin
# at this path. Add the path of an S3 Files mount to use the skills in a bucket.
CAPABILITY_DIRECTORIES = ["/opt/bma/plugins"]
TURN_END = ("completed", "failed", "cancelled")
TOOL_CALLS = ("mcp_call", "function_call", "web_search_call")
POLICIES = Path(__file__).parent / "policies"
SESSION_ROLE = "BmaSessionRole-{region}"
SESSION_POLICY = "BmaSession"
def show(data: dict[str, Any]) -> None:
"""Prints the session ID, the commands, the tool calls, and the answer."""
kind = data["type"].removeprefix("agent.session.")
item = data.get("item") or {}
if kind == "created":
print(f"Session {data['session']['id']}")
elif kind == "turn.output_text.delta":
print(data["delta"], end="", flush=True)
elif kind == "turn.item.done" and item.get("type") == "command_execution":
print(f"\n$ {item['command']}\n{item.get('output') or ''}".rstrip())
elif kind == "turn.item.done" and item.get("type") in TOOL_CALLS:
print(f"\nTool {item.get('name') or item['type']} {item.get('status')}")
elif kind == "error" or kind.split(".")[-1] in TURN_END:
source = data.get("turn") or data.get("environment") or data.get("session")
print(f"\n{kind} {(source or data).get('error') or ''}".rstrip())
def load_policy(name: str, partition: str, region: str, account: str) -> str:
"""Reads a policy file and puts in the partition, the Region, and the account."""
text = (POLICIES / name).read_text()
for key, value in (("Partition", partition), ("Region", region), ("AccountId", account)):
text = text.replace("${AWS::" + key + "}", value)
return text
def session_role(runtime_arn: str) -> str:
"""Creates or repairs the session role, and returns its ARN.
If the trust policy or the policy of the role is not the same as the file in `policies/`,
the client writes the file to the role.
"""
_, partition, _, region, account = runtime_arn.split(":")[:5]
name = SESSION_ROLE.format(region=region)
trust = load_policy("bma-session-trust.json", partition, region, account)
policy = load_policy("bma-session-policy.json", partition, region, account)
iam = boto3.client("iam")
changed = False
try:
role = iam.get_role(RoleName=name)["Role"]
except iam.exceptions.NoSuchEntityException:
role = iam.create_role(RoleName=name, AssumeRolePolicyDocument=trust)["Role"]
print(f"Created the session role {name}")
changed = True
else:
if role["AssumeRolePolicyDocument"] != json.loads(trust):
iam.update_assume_role_policy(RoleName=name, PolicyDocument=trust)
print(f"Updated the trust policy of {name}")
changed = True
try:
current = iam.get_role_policy(RoleName=name, PolicyName=SESSION_POLICY)["PolicyDocument"]
except iam.exceptions.NoSuchEntityException:
current = None
if current != json.loads(policy):
iam.put_role_policy(RoleName=name, PolicyName=SESSION_POLICY, PolicyDocument=policy)
if not changed:
print(f"Updated the policy of {name}")
changed = True
if changed:
# IAM needs some seconds before Bedrock Managed Agents can use a new or changed role.
time.sleep(15)
return role["Arn"]
def main() -> None:
parser = argparse.ArgumentParser(description=__doc__)
parser.add_argument("--runtime", required=True, help="The ACR ARN.")
parser.add_argument(
"--session-id",
help="The BMA session ID. If it does not exist, the client creates a session.",
)
parser.add_argument(
"--input",
default="Use the acr-report skill to save an ACR report in the workspace.",
)
parser.add_argument(
"--gateway",
help="The Gateway ARN from the output of `agentcore deploy`.",
)
parser.add_argument(
"--role-arn",
help="The session role that BMA assumes. If you do not give it, the client creates a role.",
)
parser.add_argument("--delete", action="store_true", help="Delete the session.")
parser.add_argument("--raw", action="store_true", help="Print events as JSON.")
args = parser.parse_args()
# BMA must run in the Region of the ACR.
region = args.runtime.split(":")[3]
with OpenAI(
api_key=lambda: provide_token(region=region),
base_url=f"https://bedrock-mantle.{region}.api.aws/openai/v1",
) as client:
sessions = client.beta.agents.sessions
session_id = args.session_id
if session_id:
try:
session = sessions.retrieve(session_id).model_dump(warnings=False)
except NotFoundError:
print(f"Session {session_id} does not exist.")
session_id = None
else:
if session["environment"].get("runtime_arn") != args.runtime:
raise ValueError(f"Session {session_id} uses another ACR.")
if not session_id and not args.role_arn:
try:
args.role_arn = session_role(args.runtime)
except ClientError as error:
parser.error(
f"The client cannot create or check the session role: {error}. "
"Get the IAM permissions in README.md, or give --role-arn."
)
print(f"Session role {args.role_arn}")
if session_id:
# BMA opens the stream only with stream=true, and the SDK does not send it.
events = sessions.events.stream(session_id, extra_query={"stream": "true"})
message = {
"role": "user",
"content": [{"type": "input_text", "text": args.input}],
}
sessions.events.create(
session_id,
events=[{"type": "agent.session.input.message", "input": [message]}],
)
else:
agent: dict[str, Any] = {
"model": BMA_MODEL_ID,
"instructions": "Use the available tools to complete the task.",
}
if args.gateway:
# Bedrock Managed Agents calls Gateway with the session role from the service side.
agent["tools"] = [
{"type": "mcp", "server_label": "team_tools", "connector_id": args.gateway}
]
args.input += " Then list the tools that the Gateway gives you."
events = sessions.create(
agent=agent,
environment={
"type": "aws_bedrock_agentcore",
"runtime_arn": args.runtime,
"runtime_qualifier": "DEFAULT",
"workspace_directory": WORKSPACE_DIRECTORY,
"capability_directories": CAPABILITY_DIRECTORIES,
},
input=args.input,
stream=True,
# The SDK has no role_arn parameter. BMA assumes this role to call the ACR.
extra_body={"role_arn": args.role_arn},
)
with events:
for event in events:
data = event.model_dump(mode="json", warnings=False)
session_id = session_id or (data.get("session") or {}).get("id")
if args.raw:
print(json.dumps(data), flush=True)
else:
show(data)
if data["type"].removeprefix("agent.session.turn.") in TURN_END:
break
if args.delete:
sessions.delete(session_id)
print(f"\nDeleted session {session_id}")
if __name__ == "__main__":
main()
```
## Étape 4 : Poursuivre la session
Pour envoyer une autre entrée à la même session, ajoutez l'ID de session. Le tour utilise le même espace de travail. Pour conserver l'espace de travail après un arrêt d'inactivité, ajoutez le stockage de session tel qu'il figure dans[Conserver les fichiers après un arrêt d'inactivité](#runtime-get-started-bma-keep-files).
```
uv run client.py --runtime --session-id \
--input "Run cat acr-report.txt and show the output."
```
Si la session n'existe pas, le client en crée une nouvelle. Ajoutez `--delete` pour supprimer la session après le tour ou `--raw` pour imprimer chaque événement au format JSON.
### Conserver les fichiers après un arrêt d'inactivité
Sur un environnement d'exécution MicroVM, placez le répertoire personnel du serveur exécutif sur le stockage de session. Ensuite, l'espace de travail, l'état de connexion et le `CODEX_HOME` séjour après un arrêt d'inactivité.
1. Au lieu de la commande de l'étape 1, créez le projet avec le stockage de session :
```
agentcore create --name MyManagedAgent --framework BedrockManagedAgents \
--session-storage-mount-path /mnt/home
cd MyManagedAgent
```
1. Dans`agentcore/agentcore.json`, ajoutez cette variable à l'entrée pour le Runtime :
```
"envVars": [{ "name": "BMA_HOME_DIR", "value": "/mnt/home" }]
```
1. À l'`client.py`intérieur, prêt`WORKSPACE_DIRECTORY = "/mnt/home/workspace"`.
1. Déployez et exécutez le client.
Pour plus d'informations sur le stockage de session, consultez la section [Configurations du système de fichiers pour AgentCore Runtime](runtime-filesystem-configurations.md).
## Étape 5 : (Facultatif) Ajouter des compétences
Pour ajouter une compétence à l'image, ajoutez un plugin en dessous `plugins/` et déployez-le. Un plugin possède un `.codex-plugin/plugin.json` fichier et un `skills/` répertoire. Le `skills/` répertoire contient un sous-répertoire pour chaque compétence, contenant un `SKILL.md` fichier. L'image le copie`/opt/bma/plugins`, que le client donne déjà à Bedrock Managed Agents.
Pour démarrer`plugins/acr-report/`, copier et renommer le répertoire du plugin, ainsi `skills/acr-report/` que le nom de votre plugin et de votre compétence. Dans`plugin.json`, set `name``version`,`description`, et`"skills": "./skills/"`. Chacun `SKILL.md` commence par une matière première qui a `name` et`description`. Après le déploiement, démarrez une nouvelle session avec`--input "Use the skill to …"`.
### Partagez les compétences depuis un compartiment Amazon S3
Montez un point d'accès S3 Files dans le Runtime. Ensuite, les compétences changent lorsque le compartiment change, et l'image reste la même. Pour le système de fichiers S3 Files, le point d'accès et les règles du groupe de sécurité, consultez la section [Configurations du système de fichiers pour AgentCore Runtime](runtime-filesystem-configurations.md).
Un montage S3 Files nécessite un environnement d'exécution en mode réseau VPC. Créez le projet avec les options réseau dans[Déployer le Runtime dans un VPC](#runtime-get-started-bma-vpc).
Dans le compartiment, placez chaque plugin dans son propre répertoire sous le répertoire racine du point d'accès. Utilisez la même mise en page que `plugins/acr-report/` : `/.codex-plugin/plugin.json` et`/skills//SKILL.md`.
Ajoutez le montage à l'entrée pour le Runtime dans `agentcore/agentcore.json` :
```
{
"filesystemConfigurations": [
{
"s3FilesAccessPoint": {
"accessPointArn": "arn:aws:s3files:us-east-1:111122223333:file-system/fs-0123456789abcdef0/access-point/fsap-0123456789abcdef0",
"mountPath": "/mnt/skills"
}
}
]
}
```
Ensuite, `client.py` configurez `CAPABILITY_DIRECTORIES` `["/opt/bma/plugins", "/mnt/skills"]` et déployez.
## Étape 6 : Afficher les journaux et les traces
```
agentcore logs --since 15m
```
Le premier déploiement active la recherche de CloudWatch transactions dans votre compte. Les traces apparaissent au bout de 10 minutes environ. Pour voir les traces, ouvrez la CloudWatch console et choisissez **GenAI Observability**. Chaque appel des agents gérés de Bedrock au serveur de gestion du cycle de vie a une `bma.invocation` durée. Pour plus d'informations, consultez [Afficher les données d'observabilité de vos agents Amazon Bedrock AgentCore ](observability-view.md).
**Les paramètres de recherche de transactions s'appliquent à l'ensemble du compte**
Transaction Search et son indexation de la durée s'appliquent à l'ensemble du compte dans la région, et des frais supplémentaires peuvent s'appliquer. Pour conserver vos paramètres actuels, ajoutez-les `~/.agentcore/config.json` avant `"disableTransactionSearch": true` de procéder au déploiement.
## Étape 7 : mise à jour et redéploiement
Modifiez les paramètres d'exécution dans `agentcore/agentcore.json` ou dans les fichiers de l'image, puis déployez à nouveau. Par exemple, ce paramètre arrête une session inactive au bout de 10 minutes. Les valeurs sont exprimées en secondes.
```
{
"lifecycleConfiguration": {
"idleRuntimeSessionTimeout": 600,
"maxLifetime": 28800
}
}
```
```
agentcore deploy
```
Les modifications s'appliquent aux nouvelles sessions.
### Variables d'environnement du serveur de cycle de vie
Ajoutez une variable à `envVars` dans l'entrée pour le Runtime, par exemple`{ "name": "DISABLE_ADOT_OBSERVABILITY", "value": "true" }`.
| Variable | Par défaut | Description |
| --- | --- | --- |
| `DISABLE_ADOT_OBSERVABILITY` | Non défini | Définissez sur `true` pour désactiver les traces et les journaux du serveur exécutif. Le serveur de cycle de vie écrit toujours ses propres journaux dans le groupe de journaux du Runtime. |
| `BMA_HOME_DIR` | `/home/app` | `HOME`du serveur exécutif. |
| `BMA_STATE_DIR` | `.bma` dans `BMA_HOME_DIR` | Le répertoire de`state.json`, qui conserve l'état de connexion de la session. |
| `BMA_CODEX_HOME` | `.codex` dans `BMA_HOME_DIR` | `CODEX_HOME`du serveur exécutif. |
| `BMA_CODEX_BINARY` | `/opt/bma/bin/codex` | Le binaire du Codex. |
| `BMA_MAX_TURN_LEASE` | `300` | Le bail de tour le plus long, en secondes. |
Chaque compilation d'image installe la dernière version du Codex. Le serveur de cycle de vie nécessite Codex 0.154.0 ou version ultérieure. Pour épingler une version, `CODEX_RELEASE=` ajoutez-la à côté `CODEX_NON_INTERACTIVE=1` dans le`Dockerfile`.
## Étape 8 : nettoyer
Pour supprimer une session, ajoutez-la `--delete` à la dernière exécution du client pour cette session. Supprimez ensuite les ressources du projet et déployez-le pour supprimer le Runtime, son rôle d'exécution et la pile.
```
agentcore remove all
agentcore deploy
```
Le déploiement ne supprime pas les ressources suivantes :
+ Les CloudWatch journaux enregistrent les groupes du Runtime, du CodeBuild projet qui crée l'image et de la fonction Lambda qui lance la génération.
+ La clé AWS KMS du référentiel Amazon ECR. La clé reste dans l'état **En attente de suppression** pendant 30 jours, puis AWS KMS la supprime.
+ La `CDKToolkit` pile, si le premier déploiement a amorcé le compte et la région. D'autres applications AWS CDK peuvent utiliser cette pile. Supprimez-le uniquement si aucune autre application ne l'utilise.
+ Les paramètres de recherche de transactions de l'étape 6.
+ Rôle de session `client.py` créé à l'étape 3.
Pour supprimer le rôle de session, exécutez les commandes suivantes :
```
aws iam delete-role-policy --role-name BmaSessionRole- --policy-name BmaSession
aws iam delete-role --role-name BmaSessionRole-
```
Pour rechercher les groupes de journaux, exécutez ces commandes. Supprimez ensuite chaque groupe de journaux.
```
aws logs describe-log-groups --log-group-name-prefix /aws/bedrock-agentcore/runtimes/_- --query 'logGroups[].logGroupName'
aws logs describe-log-groups --log-group-name-prefix /aws/codebuild/AgentCore--- --query 'logGroups[].logGroupName'
aws logs describe-log-groups --log-group-name-prefix /aws/lambda/AgentCore- --query 'logGroups[].logGroupName'
aws logs delete-log-group --log-group-name
```
Remplacez les valeurs suivantes :
+ ``- Le nom du projet. À l'étape 1, c'est le cas`MyManagedAgent`.
+ ``- Le nom de l'agent. À l'étape 1, c'est également le cas`MyManagedAgent`.
+ ``- Le nom de la cible de déploiement dans`agentcore/aws-targets.json`. La valeur par défaut est `default`. Dans les CodeBuild noms, chaque trait de soulignement (`_`) du nom du projet et du nom de la cible est remplacé par un trait d'union ()`-`.
Le nom du groupe de logs Lambda est raccourci, comme dans cet exemple :
```
/aws/lambda/AgentCore-MyManagedAgent--ApplicationAgentMyManage-
```
La commande répertorie les groupes de journaux Lambda de tous les projets AgentCore CLI de la région. Supprimez uniquement les groupes de journaux de votre projet.
Si vous avez ajouté d'autres ressources au projet, telles qu'une passerelle ou une mémoire, vérifiez que le déploiement les a supprimées.
## Ressources connexes
+ [Utiliser la AgentCore CLI](runtime-permissions.md#runtime-permissions-cli)
+ [Configuration des paramètres du cycle de vie](runtime-lifecycle-settings.md)
+ [Configurations du système de fichiers pour AgentCore Runtime](runtime-filesystem-configurations.md)
+ [Configuration AgentCore pour VPC](agentcore-vpc.md)
+ [Instances d'exécution et fournisseurs de capacité](runtime-instances.md)
+ [Afficher les données d'observabilité de vos agents Amazon Bedrock AgentCore ](observability-view.md)