View a markdown version of this page

Ottimizza il tuo agente per Amazon Bedrock AgentCore Runtime V2 - Fondamento Amazon AgentCore

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Ottimizza il tuo agente per Amazon Bedrock AgentCore Runtime V2

Amazon Bedrock AgentCore Runtime V2 avvia l'agente ripristinando un'istantanea. Questo cambia il modo in cui strutturate il codice dell'agente. Il lavoro svolto dall'agente all'avvio viene acquisito nell'istantanea e condiviso da ogni istanza ripristinata. Produci invece qualsiasi valore che deve differire tra le richieste o che può scadere nel gestore delle richieste. Questo argomento descrive come strutturare l'agente in base al lavoro di avvio e al lavoro per richiesta in modo che rimanga corretto dopo ogni ripristino. Per una panoramica della versione V2 della piattaforma, consulta Versioni della piattaforma.

Il tuo agente ha due contesti di esecuzione:

Startup

Codice che viene eseguito una volta all'avvio del processo, prima che AgentCore Runtime scatti l'istantanea. AgentCore Runtime acquisisce questo codice nell'istantanea e ogni istanza ne eredita i risultati.

Gestione delle richieste

Il codice nel tuo /invocations gestore. Questo codice viene eseguito su ogni richiesta su ogni istanza.

Usa una regola per decidere a chi appartiene il codice. Calcola un valore all'avvio se rimane invariato per tutta la durata dell'istantanea. Calcolalo nel tuo gestore se varia in base alla richiesta o può scadere. AgentCore Runtime acquisisce un'istantanea per versione dell'agente e la utilizza fino alla creazione o all'aggiornamento dell'agente, quindi la durata dell'istantanea è la durata di quella versione.

Inizializza una volta all'avvio

Esegui lavori costosi e riutilizzabili all'inizio del processo, prima dell'istantanea. Ad esempio, importa le dipendenze, carica i pesi dei modelli o leggi la configurazione statica dal tuo pacchetto di distribuzione. Con l' AgentCore SDK, esegui questo lavoro nell'ambito del modulo, prima di chiamare. app.run() L'agente non ascolta sulla porta 8080 finché non app.run() viene eseguita, quindi non è /ping possibile eseguire alcuna operazione e non è possibile scattare alcuna istantanea fino al termine del lavoro di avvio. L'istantanea cattura un agente completamente inizializzato per costruzione e non è necessario eseguire il gate. /ping Inizializzazione completa entro 120 secondi dall'avvio. Se l'agente non si integra in tempo, il runtime non esegue il controllo dello stato. Per ulteriori informazioni sugli /invocations endpoint /ping e sugli endpoint, consulta Understand the AgentCore Runtime service contract.

import json, pathlib from bedrock_agentcore.runtime import BedrockAgentCoreApp # Runs once at import, before app.run() starts the server and before the # snapshot. Every restored instance inherits these objects. MODEL = load_model_weights() SETTINGS = json.loads((pathlib.Path(__file__).parent / "agent.json").read_text()) app = BedrockAgentCoreApp() @app.entrypoint def invoke(payload): # Per-request work runs here on every instance. ... app.run() # starts listening on 8080; the snapshot is taken after this

Se l'agente esegue il proprio server HTTP anziché l' AgentCore SDK, segnalate lo stato di integrità /ping solo dopo il completamento dell'inizializzazione, in modo che l'istantanea acquisisca un agente completamente inizializzato.

Dati di sola lettura all'avvio che sono uguali per ogni istanza e non scadono. Gestisci i valori sensibili al fattore tempo, come le credenziali di breve durata, nel tuo gestore.

Nota

All'avvio non calcolate nulla che modificate senza ridistribuirlo. Ad esempio, un catalogo di strumenti recuperato da AgentCore Gateway sembra un valore di avvio ideale perché è lento e costoso da caricare, ma memorizzarlo nella cache all'avvio blocca l'inventario degli strumenti dell'agente al momento dell'istantanea.

Mantieni aggiornato lo stato di ogni richiesta

L'istantanea viene acquisita una volta e condivisa da ogni istanza ripristinata, quindi qualsiasi valore generato dall'agente all'avvio è identico tra le istanze e corretto al momento dell'istantanea. Gestisci i valori che l'istantanea non può contenere nel tuo gestore. /invocations La tabella seguente descrive i valori da calcolare nel gestore anziché all'avvio.

Per farlo Fatelo nel gestore Motivo

Genera valori, identificatori o token casuali

Chiama os.urandom()secrets, o uuid.uuid4() su ogni richiesta

os.urandom()restituisce una nuova entropia solo ogni volta che la richiami dopo un ripristino. Un valore letto all'avvio viene copiato nell'istantanea ed è identico in ogni istanza, indipendentemente dalla qualità della fonte di entropia al momento della lettura. Allo stesso modo, il random modulo viene preimpostato all'avvio, quindi le istanze ripristinate ripetono la stessa sequenza.

Leggi l'ora corrente

Calcolalo per ogni richiesta

Un timestamp acquisito all'avvio viene fissato al momento dell'istantanea.

Misura il tempo trascorso

Prendi il timestamp di riferimento nel tuo gestore

time.monotonic()non avanza nel corso di un ripristino, quindi una durata misurata a partire da un riferimento di avvio è errata senza apparire errata.

Usa credenziali o token

Aggiornali quando scadono

Le credenziali caricate all'avvio possono scadere prima dell'avvio di un'istanza.

Identifica l'istanza o il lavoratore

Genera un ID per richiesta; non derivarlo dall'host

Ogni istanza ripristinata riporta gli stessi hostname (localhost) e PID (1), quindi l'utilizzo di entrambi come ID comprime le metriche, i flussi di log e i proprietari dei blocchi in tutta la flotta.

Crea client riutilizzabili all'avvio e calcola i valori per richiesta su ogni chiamata.

import os, time # Build reusable clients at startup, before the snapshot. Exercise them here too # (for example, with a warm-up call) so the setup the client caches — endpoint and # credential resolution, connection pool — is captured in the snapshot. client = build_client() warm_up(client) @app.entrypoint def invoke(payload): creds = get_credentials() # refreshed when expired, not read at startup request_id = os.urandom(16).hex() # unique per request now = time.time() # current time, not snapshot time # Handle the request.

Usa librerie crittografiche sicure per le istantanee

Quando AgentCore Runtime ripristina un'istanza da un'istantanea, una libreria crittografica che memorizza nella cache lo stato casuale all'avvio può riutilizzare tale stato tra le istanze. Le librerie crittografiche devono utilizzare una build snapshot-safe (snapsafe) che si risemina dopo un ripristino.

Distribuzioni dirette del codice

L'immagine di base gestita dal servizio include già una versione sicura per le istantanee delle relative librerie crittografiche, quindi non è necessario intraprendere alcuna azione al riguardo.

Bring-your-own librerie crittografiche

Se utilizzate le vostre librerie crittografiche, ad esempio in un container agent, utilizzate le build snapshot-safe in modo che vengano reinstallate dopo un ripristino. Su Amazon Linux 2023, usa. openssl-snapsafe-libs

Rete

Crea clienti all'avvio e aspettati una riconnessione trasparente

Il socket che apri all'avvio non sopravvive a un ripristino, ma la configurazione che la libreria client memorizza nella cache (analisi del modello di servizio, risoluzione degli endpoint, risoluzione delle credenziali e pool di connessioni) sì. Costruisci ed esercita i tuoi client all'avvio e aspettati che la prima chiamata dopo un ripristino ristabilisca la connessione in modo trasparente.

Non utilizzare il nome host o il PID come identificatore univoco di istanza

Ogni istanza ripristinata parte dalla stessa istantanea e riporta lo stesso nome host e ID di processo. Genera un identificatore univoco in ogni richiesta.

Evita il collegamento a una porta di origine fissa

Dopo un ripristino, la connessione mantenuta in fase di istantanea viene ristabilita e una porta di origine fissa può entrare in collisione con quella sostitutiva all'interno dell'istanza. Le istanze ripristinate sono MicroVM separate con i propri namespace di rete, quindi il conflitto è all'interno di un'istanza, non tra di esse.