La valutazione delle skill di Amazon Bedrock AgentCore rivela ciò che gli agenti fluenti nascondono

Amazon ha introdotto la valutazione delle skill di Amazon Bedrock AgentCore il 22 settembre, aggiungendo tre controlli che esaminano il comportamento degli agenti oltre la loro risposta finale rifinita. Il rilascio affronta un persistente punto cieco nei test. Un agente può sembrare corretto dopo aver scelto la skill sbagliata, aver saltato passaggi obbligatori o aver improvvisato attorno a una procedura aziendale.

I nuovi valutatori separano due domande che i team spesso comprimono in un unico punteggio. L'agente ha selezionato una skill appropriata e l'ha seguita dopo averla caricata? Strands Evals aggiunge un terzo controllo deterministico per i team che sanno già quale skill nominata dovrebbe essere invocata da un test.

Questa distinzione mette sotto pressione i sistemi di valutazione incentrati esclusivamente sulla qualità della risposta. Utilità, pertinenza e correttezza restano importanti, ma non possono rivelare ogni errore di instradamento o di esecuzione. Il vero confronto ora è tra il punteggio della risposta finale e le evidenze a livello di traiettoria su come un agente sia arrivato a quella risposta.

La valutazione delle skill di Amazon Bedrock AgentCore divide un errore in tre

AWS sta trasformando l'uso delle skill in una sequenza misurabile, invece di considerare la risposta finale una prova sufficiente di successo.

Una skill è un pacchetto di istruzioni riutilizzabile che insegna a un agente una procedura specializzata. Comunemente include un file SKILL.md contenente il suo scopo, indicazioni per l'attivazione e passaggi obbligatori. Un harness presenta le skill disponibili, mentre l'agente decide quale caricare per una richiesta.

Questa struttura consente agli sviluppatori di spostare procedure dettagliate fuori da un system prompt in continua crescita. Un'azienda potrebbe creare skill separate per la riconciliazione delle fatture, l'oscuramento dei contratti, l'escalation degli incidenti o la revisione delle pull request. L'agente carica le istruzioni pertinenti quando necessario, invece di portare ogni procedura in ogni interazione.

La portabilità è parte dell'attrattiva. Il formato aperto Agent Skills offre agli ambienti di agenti compatibili un modo condiviso per impacchettare istruzioni specializzate. Una skill può quindi fungere da artefatto operativo, non solo da frammento di prompt legato a una singola chiamata di modello.

Tuttavia, le istruzioni modulari introducono una catena di decisioni. L'agente deve riconoscere l'intento dell'utente, trovare una skill adatta, invocarla, leggerne il contenuto e completarne i passaggi prescritti. Un buon paragrafo finale non dimostra che questa catena abbia funzionato.

AWS e il team Strands ora suddividono questa catena tra tre valutatori, secondo il rilascio della valutazione delle skill del 22 settembre.

Skill Selection Accuracy chiede se ogni skill invocata fosse appropriata per il compito. Restituisce un risultato binario per ogni skill invocata. Questo rende visibili gli errori di instradamento quando un agente carica istruzioni destinate a un altro flusso di lavoro.

Skill Instruction Following esamina quanto completamente l'agente abbia eseguito i passaggi prescritti di una skill invocata. Le sue cinque valutazioni sono Fully Followed, Mostly Followed, Partially Followed, Minimally Followed e Not Followed. I relativi valori numerici documentati vanno da 1.0 a 0.0 con incrementi di un quarto di punto.

Skill Invoked fornisce un'asserzione più ristretta e deterministica all'interno di Strands Evals. Verifica se l'agente ha caricato con successo una skill nominata. A differenza degli altri due valutatori, non chiede a un modello di giudicare appropriatezza o aderenza.

Queste misure rispondono a domande diverse. Una skill obbligatoria per le buste paga potrebbe non essere mai caricata, producendo un errore di instradamento. Potrebbe essere caricata per una richiesta di viaggio non correlata, producendo un errore di selezione. Potrebbe essere caricata correttamente ma omettere un passaggio di approvazione, producendo un errore nel seguire le istruzioni.

Questa separazione è il cambiamento centrale. I team non devono più interpretare ogni risultato debole come un vago problema di qualità dell'agente. Possono associare ogni schema a un componente diverso e a una correzione più mirata.

Una mancata invocazione rimanda a regole di individuazione, descrizioni o logica di instradamento. Un'invocazione inappropriata suggerisce ambiti delle skill sovrapposti. Una skill selezionata correttamente ma con bassa aderenza indirizza l'attenzione verso i suoi passaggi, la struttura, gli strumenti disponibili o il modello sottostante.

Il rilascio non sostituisce la valutazione della qualità esistente. Aggiunge un ulteriore livello pensato per agenti il cui comportamento dipende da procedure caricate dinamicamente. L'accuratezza dell'output resta essenziale, ma diventa una parte di un record di test più ampio.

Le risposte fluenti non sono più prove sufficienti

L'argomento più forte a favore della valutazione della traiettoria è semplice: diversi errori interni possono produrre una prosa altrettanto convincente.

Si consideri un dipendente che chiede a un agente di oscurare un contratto prima della condivisione esterna. L'agente potrebbe rimuovere i nomi più evidenti e restituire un documento dall'aspetto pulito. Eppure, la skill approvata potrebbe anche richiedere il controllo dei metadati, dei commenti nascosti, delle modifiche rilevate e dei riferimenti agli allegati.

Un revisore che vede solo il documento finale potrebbe non rilevare questi controlli saltati. La risposta può sembrare competente pur violando l'effettiva procedura di gestione dell'organizzazione. Skill Instruction Following è progettato per confrontare il comportamento registrato con ogni passaggio prescritto.

Lo stesso problema si presenta nelle operazioni finanziarie. Un agente per la riconciliazione delle fatture potrebbe produrre il totale corretto tramite un ragionamento informale. Se la skill richiede di convalidare l'identità del fornitore e l'autorizzazione all'acquisto, il risultato rimane proceduralmente incompleto.

La conformità rende questa distinzione particolarmente importante. Le organizzazioni raramente si interessano solo al fatto che una risposta sia stata casualmente accettabile. Hanno anche bisogno di prove che controlli ripetibili siano stati applicati nell'ordine e nel contesto richiesti.

I test software tradizionali offrono aspettative esatte per funzioni deterministiche. Gli agenti si comportano diversamente perché lo stesso prompt può portare a linguaggio, chiamate di strumenti e percorsi di ragionamento variabili. AWS aveva precedentemente sostenuto che una singola esecuzione riuscita mostra ciò che può accadere, non ciò che accade di solito.

Questa variabilità rende allettanti i punteggi aggregati delle risposte. Un team può calcolare la media di correttezza o utilità su un dataset e monitorare se il numero cresce. Tuttavia, una media nasconde dove un flusso di lavoro ha fallito e se lo stesso passaggio continua a scomparire.

I risultati per skill offrono un'unità diagnostica più utile. Quando un agente invoca diverse skill durante una sessione, i valutatori restituiscono risultati per ogni invocazione. Un aggregato debole può quindi essere ricondotto alla skill specifica che lo ha abbassato.

L'approccio cambia anche il modo in cui i team scrivono le skill. Un paragrafo vago può essere comprensibile per un autore umano ma difficile da valutare in modo coerente. Passaggi numerati e osservabili forniscono al giudice evidenze più chiare e rendono più semplice identificare le omissioni.

Questo non significa che ogni pensiero interno diventi disponibile. La valutazione si basa su traiettorie e tracce registrate, inclusi messaggi visibili, azioni di caricamento delle skill e chiamate di strumenti. Il ragionamento privato del modello non è né richiesto né esposto.

Le prove rilevanti sono operative. L'agente ha caricato la skill? Quale skill ha scelto? Le azioni registrate mostrano che ha completato i controlli prescritti? Queste prove sono più azionabili della speculazione sul ragionamento nascosto.

Questo cambiamento ricorda la differenza tra verificare un calcolo completato e sottoporre a revisione i controlli che lo circondano. Entrambe le prospettive contano, ma rispondono a domande distinte. Una misura l'artefatto, mentre l'altra misura il processo che lo ha prodotto.

Per i team che costruiscono agenti interni, il processo spesso comporta il rischio organizzativo maggiore. Una risposta fluida può soddisfare un utente una volta. Un passaggio di approvazione, divulgazione o convalida saltato può compromettere il flusso di lavoro ogni volta che si ripresentano le stesse condizioni.

I nuovi valutatori rendono più facile definire questa lacuna procedurale. Creano anche pressione affinché altre piattaforme per agenti espongano traiettorie compatibili. Senza eventi delle skill osservabili, un team non può distinguere con sicurezza una mancata invocazione da un'estrazione fallita.

Strands Evals porta i controlli nello sviluppo

Strands Evals offre agli sviluppatori un livello di test locale per l'instradamento e l'esecuzione delle skill prima che il traffico di produzione diventi la suite di test.

Strands Evals è un framework open source per valutare agenti e applicazioni di modelli linguistici. Le sue funzionalità pubblicate includono punteggio dell'output, analisi della traiettoria, valutazione degli strumenti, simulazioni, esperimenti e valutazione basata su tracce.

Il repository di valutazione del progetto ora documenta tutti e tre i controlli delle skill. Gli sviluppatori possono eseguire Skill Selection Accuracy e Skill Instruction Following su una sessione registrata o su una traiettoria grezza di messaggi.

I valutatori basati su giudice leggono la traiettoria anziché rieseguire l'agente. Questo supporta l'indagine dopo un fallimento e il confronto tra sessioni salvate. Separa inoltre l'esecuzione costosa dell'agente dall'analisi ripetuta dello stesso record.

Skill Invoked soddisfa un'esigenza di test diversa. Se un caso di regressione ha un requisito di instradamento noto, gli sviluppatori possono affermare che sia stata caricata la skill prevista. Il controllo è deterministico e non richiede un modello giudice.

Questo lo rende adatto a un gate di rilascio. Una richiesta di assistenza clienti relativa alla chiusura di un account dovrebbe caricare in modo coerente la skill di chiusura approvata. Se una descrizione rivista ne impedisce l'invocazione, il test di regressione può fallire prima del deployment.

L'accuratezza della selezione resta utile quando più di una skill potrebbe ragionevolmente applicarsi. Chiede se una skill invocata sia adatta al compito invece di confrontarla solo con un unico nome fisso. Questa flessibilità accoglie cataloghi con procedure correlate e variazioni legittime nell'instradamento.

Il rispetto delle istruzioni testa poi la fase successiva. Il valutatore identifica i passaggi prescritti nella skill caricata e classifica ciascuno come completato, parziale o saltato. Utilizza questi giudizi per produrre la valutazione complessiva a cinque livelli.

La combinazione crea una matrice di test compatta.

Un alto punteggio di selezione con un debole rispetto delle istruzioni significa che l'instradamento ha funzionato, ma l'esecuzione no. L'agente ha trovato la procedura corretta e poi ha saltato o completato solo in parte i suoi requisiti.

Una selezione debole con un forte rispetto delle istruzioni significa che l'agente ha seguito la procedura caricata, ma quella procedura era sbagliata per la richiesta. Migliorare la formulazione interna della skill non risolverebbe quell'errore di instradamento.

Una mancata invocazione richiede una gestione speciale. AWS osserva che i due valutatori basati su giudice non restituiscono un punteggio quando non viene invocata alcuna skill. I team dovrebbero abbinarli a Skill Invoked quando una skill nominata è obbligatoria.

Questo comportamento evita un successo fuorviante. Un valutatore non può giudicare l'aderenza a istruzioni che non sono mai state caricate. Tuttavia, un risultato vuoto può scomparire in una dashboard a meno che la suite di test non tratti esplicitamente la mancata invocazione come un fallimento.

Strands attribuisce inoltre un onere di strumentazione all'harness. Il suo estrattore deve riconoscere le skill disponibili e selezionate dalla traiettoria. Il progetto supporta diversi ambienti noti, oltre al modello generico della lettura di un file SKILL.md.

Gli sviluppatori dovrebbero verificare l'estrazione prima di fidarsi di un punteggio. Un harness con segnali delle skill non riconosciuti può produrre risultati vuoti anche quando l'agente ha usato una skill. Si tratta di una lacuna di osservabilità, non di una prova di comportamento corretto.

Questa avvertenza è importante per i team che integrano livelli di orchestrazione personalizzati. La qualità della valutazione dipende dalla registrazione fedele degli eventi. Un attributo di traccia mancante può sembrare un'azione dell'agente mancante, a meno che i team non convalidino prima il contratto di telemetria.

Il flusso di lavoro di sviluppo prevede quindi due fasi. In primo luogo, confermare che il valutatore possa vedere il catalogo, l'invocazione, il contenuto della skill e le azioni successive. In secondo luogo, misurare se tali azioni siano adatte al compito e rispettino le istruzioni.

Per i team di ingegneria che mantengono flussi di lavoro tecnici locali, il cambiamento rafforza anche il valore di una base di conoscenza ingegneristica ricercabile. Le skill possono codificare procedure, mentre il materiale sorgente mantenuto fornisce i fatti su cui tali procedure operano.

AgentCore Porta la Valutazione delle Skill nelle Tracce di Produzione

AgentCore estende le stesse domande su instradamento e aderenza dai test curati alle sessioni in staging e al traffico live campionato.

Amazon Bedrock AgentCore Evaluations è un servizio gestito per valutare il comportamento degli agenti nello sviluppo e in produzione. Utilizza tracce OpenTelemetry, che registrano eventi strutturati come chiamate al modello, uso degli strumenti e operazioni dell'agente.

OpenTelemetry è importante perché riduce la dipendenza da un singolo framework per agenti. La documentazione di AgentCore afferma che il servizio supporta integrazioni che includono Strands e LangGraph tramite la strumentazione OpenTelemetry e OpenInference.

Questa architettura attribuisce al rilascio un ruolo più ampio di una funzionalità riservata a Strands. Strands Evals gestisce casi di test e traiettorie di sviluppo registrate. AgentCore può valutare tracce compatibili provenienti da agenti distribuiti, comprese sessioni prodotte al di fuori del framework Strands.

AWS offre tre modalità di valutazione. La valutazione on-demand esamina sessioni selezionate o convalida una modifica recente. La valutazione batch elabora più sessioni archiviate per stabilire una base di riferimento o confrontare una revisione del catalogo.

La valutazione online campiona continuamente il traffico di produzione. I team scelgono i valutatori, una sorgente dati, filtri e una frequenza di campionamento. AgentCore applica quindi tali valutazioni quando arrivano tracce corrispondenti.

Le modalità di valutazione supportano diverse domande operative. Uno sviluppatore può esaminare una singola sessione non riuscita, assegnare un punteggio a una popolazione archiviata o monitorare comportamenti che emergono solo tra gli utenti reali.

Questa progressione affronta una lacuna comune nei test degli agenti. I prompt curati riflettono ciò che i progettisti si aspettano che le persone chiedano. Le richieste in produzione contengono abbreviazioni, contesto mancante, formulazioni insolite e combinazioni che l'autore di un test non aveva previsto.

Anche i cataloghi di skill cambiano nel tempo. Una nuova skill può sovrapporsi a una descrizione più vecchia, modificando l'instradamento anche quando i passaggi interni di nessuna delle due skill sono cambiati. AWS descrive questo fenomeno come deriva del catalogo.

La valutazione online può rilevare tale deriva attraverso punteggi di selezione in calo. I team possono quindi esaminare quale skill abbia iniziato ad attrarre richieste non idonee. La correzione potrebbe richiedere di restringere una descrizione o chiarire i confini tra skill adiacenti.

Le sessioni lunghe creano un'altra preoccupazione. Un agente potrebbe seguire una skill in modo affidabile all'inizio di una conversazione, ma perdere traccia dei passaggi man mano che il contesto si accumula. Le tracce di produzione espongono queste condizioni in modo più naturale rispetto a prompt di test isolati.

Il servizio gestito supporta anche il campionamento mirato. La documentazione AWS afferma che i team possono valutare una percentuale delle sessioni o applicare filtri condizionali. Ciò consente agli operatori di concentrarsi su flussi di lavoro sensibili senza elaborare ogni interazione.

Tuttavia, il campionamento modifica il significato della dashboard. Una valutazione a basso volume o filtrata in modo ristretto potrebbe non rilevare errori rari. I team devono registrare quale traffico sia stato qualificato ed evitare di presentare un punteggio campionato come copertura completa.

Il percorso di produzione dipende anche da una telemetria corretta. AgentCore organizza le interazioni in sessioni, tracce e span. Una sessione contiene una conversazione, una traccia copre uno scambio e gli span rappresentano singole operazioni.

La valutazione delle skill richiede informazioni sufficienti per ricostruire ciò che era disponibile, ciò che è stato caricato e ciò che è accaduto in seguito. Se la strumentazione omette il contenuto della skill o il segnale di invocazione, il giudice non dispone delle prove necessarie per un risultato difendibile.

Le linee guida di AgentCore di AWS descrivono un formato di traccia unificato valutato con valutatori basati su modelli. Questa standardizzazione semplifica le operazioni, ma non può recuperare eventi che l'applicazione non ha mai registrato.

Anche i team di sicurezza dovranno esaminare il contenuto delle tracce. Il testo delle skill può contenere procedure interne e i registri delle conversazioni possono includere dati sensibili degli utenti. La valutazione aumenta il valore della telemetria, ma alza anche la posta in gioco per i controlli di accesso e le scelte di conservazione.

Il risultato è un modello di ciclo di vita anziché un singolo test. Gli sviluppatori possono stabilire gate deterministici in locale, confrontare sessioni archiviate prima del rilascio e osservare il comportamento campionato dopo la distribuzione. Ogni livello intercetta una diversa classe di errore.

I Nuovi Punteggi Necessitano Ancora di una Propria Valutazione

I giudici basati su modelli aggiungono dettagli diagnostici, ma non trasformano la conformità procedurale in un fatto oggettivo.

Skill Selection Accuracy e Skill Instruction Following si basano su un modello giudice. Il giudice legge il compito, le prove disponibili e le istruzioni della skill prima di produrre una valutazione. Il suo output rimane un'interpretazione della traiettoria registrata.

Questa interpretazione può variare in presenza di passaggi ambigui. Una skill potrebbe dire: “verifica lo stato del cliente prima di procedere”, senza definire quali prove di verifica siano accettabili. Un giudice potrebbe considerare sufficiente una ricerca nel database, mentre un altro si aspetterebbe una conferma esplicita.

La scala di aderenza a cinque livelli fornisce sfumature, ma può anche creare una falsa precisione. Una valutazione di 0,75 appare esatta anche quando la distinzione sottostante tra Mostly Followed e Partially Followed dipende dal giudizio.

I team dovrebbero quindi calibrare il valutatore rispetto a esempi revisionati da esseri umani. L'obiettivo non è un accordo perfetto su ogni caso limite. È una griglia stabile che rifletta le effettive priorità procedurali dell'organizzazione.

Le skill dovrebbero rendere osservabili i passaggi importanti. “Considera la policy pertinente” è difficile da verificare. “Recupera la policy corrente, confronta la richiesta con tre condizioni di idoneità e registra il risultato” crea prove più chiare.

I casi negativi sono importanti quanto quelli positivi. Un benchmark di selezione dovrebbe includere richieste che somigliano al dominio di una skill ma che non dovrebbero invocarla. In caso contrario, una descrizione ampia può ottenere un buon punteggio attivandosi per ogni compito vicino.

Anche i test a livello di catalogo sono essenziali. Valutare una skill in isolamento dice poco sull'instradamento quando compaiono insieme dieci opzioni simili. L'ambiente di test pertinente deve assomigliare al catalogo che gli agenti vedranno realmente.

Il controllo deterministico Skill Invoked ha un proprio limite. Dimostra che una determinata skill è stata caricata, non che il caricamento fosse appropriato o utile. Un team può ottenere un'invocazione perfetta continuando tuttavia a selezionare la skill per le richieste sbagliate.

Allo stesso modo, una forte aderenza alle istruzioni non garantisce una risposta corretta. Una skill difettosa può prescrivere i passaggi sbagliati. L'agente può eseguirli fedelmente e produrre comunque un risultato non sicuro o inaccurato.

Per questo la valutazione a livello di risposta deve restare accanto alla valutazione delle skill. I team hanno ancora bisogno di verifiche di correttezza, fedeltà, dannosità, parametri degli strumenti e convalida specifica del dominio. L'aderenza alla procedura è una dimensione dell'affidabilità.

I template di prompt ufficiali rendono ispezionabile la logica di valutazione. Mostrano che il giudice dell'aderenza identifica i passaggi, etichetta le prove a supporto e mappa il risultato su cinque valutazioni.

La trasparenza aiuta i team a comprendere il valutatore, ma non sostituisce la convalida. Le organizzazioni dovrebbero confrontare i risultati del giudice con la revisione di esperti prima di utilizzare i punteggi per decisioni di rilascio sensibili.

Anche costi e latenza influenzano l'uso in produzione. La valutazione basata su giudici richiede ulteriore elaborazione del modello dopo l'esecuzione originale dell'agente. Campionamento e filtri possono controllare questo carico, ma riducono anche la copertura.

I team dovrebbero evitare di comprimere ogni valutatore in un unico punteggio principale. Un singolo numero composito ricrea l'ambiguità che questo rilascio mira a eliminare. Selezione, invocazione, aderenza e qualità dell'output dovrebbero restare visibili come segnali separati.

Il rilascio lascia inoltre fuori dal proprio ambito le questioni di governance. Non decide chi possa creare una skill, approvare una revisione o definire una procedura obbligatoria. La valutazione può rivelare una deviazione solo dopo che un'organizzazione ha stabilito una base di riferimento autorevole.

Un flusso di lavoro maturo versionerà le skill insieme a test e modifiche alla griglia di valutazione. In caso contrario, i team non potranno capire se un punteggio sia cambiato perché è cambiato l'agente, sono cambiate le istruzioni o è cambiato il valutatore.

Amazon presenta questi controlli come strumenti diagnostici, non come prova indipendente di conformità. È il limite corretto. Rendono il comportamento degli agenti più verificabile, mentre la responsabilità continua a spettare alle persone che definiscono e convalidano il flusso di lavoro.

Tre Segnali Mostreranno se la Valutazione delle Skill Funziona

Il prossimo test è capire se i team riusciranno a trasformare le prove per singola skill in rilasci più sicuri, diagnosi più rapide e cataloghi di skill migliori.

Il primo segnale è l'adozione di gate di instradamento deterministici nello sviluppo. I team dovrebbero identificare flussi di lavoro in cui una specifica skill sia obbligatoria e aggiungere asserzioni Skill Invoked alle suite di regressione.

Se questi gate intercettano modifiche al catalogo prima della distribuzione, il motivo per adottare test consapevoli delle skill diventa più forte. Se problemi di estrazione producono frequentemente risultati vuoti, la strumentazione resterà l'ostacolo immediato.

Il secondo segnale è se i punteggi di selezione in produzione rivelino la deriva del catalogo. Le nuove skill arrivano spesso con descrizioni ampie perché gli autori desiderano che si attivino in modo affidabile. Tali descrizioni possono sottrarre richieste alle procedure esistenti.

Un sistema di produzione utile dovrebbe mostrare quali invocazioni siano diventate inappropriate dopo un aggiornamento del catalogo. I team dovrebbero quindi poter collegare il calo a una descrizione specifica, una sovrapposizione o un modello di richiesta.

La prova di una diagnosi ripetibile rafforzerebbe l'affermazione centrale di AWS. Dashboard che mostrano soltanto un aggregato inferiore senza identificare la skill interessata la indebolirebbero.

Il terzo segnale è l'accordo tra Skill Instruction Following e la revisione di esperti. Le organizzazioni devono confrontare le etichette del giudice a livello di passaggio con i giudizi di persone che comprendono la procedura.

Un accordo coerente giustificherebbe un uso più ampio nei gate di rilascio e nel monitoraggio online. Disaccordi frequenti suggerirebbero che i passaggi della skill, le prove della traccia o la griglia del valutatore necessitino di ulteriore lavoro.

I team dovrebbero iniziare con un catalogo ristretto e un insieme di test deliberatamente vario. Includere corrispondenze chiare, casi quasi corrispondenti, richieste che non richiedono alcuna skill e flussi di lavoro con più skill. Eseguire ogni scenario più di una volta perché il comportamento dell'agente rimane non deterministico.

Registrare separatamente quattro esiti: se è stata caricata la skill prevista, se ogni invocazione era appropriata, se sono stati seguiti i passaggi richiesti e se il risultato finale era corretto. Questa struttura preserva il valore diagnostico dei nuovi valutatori.

Quindi, esaminare i disaccordi anziché eliminarli tramite medie. Una risposta corretta con passaggi saltati può rivelare un rischio operativo latente. Una risposta scadente dopo un'esecuzione fedele può rivelare una skill difettosa anziché un modello debole.

Il monitoraggio in produzione dovrebbe iniziare dai flussi di lavoro sensibili o ad alto volume. Usare filtri e campionamento in modo deliberato e documentare ciò che la popolazione del punteggio esclude. Mantenere disponibile la revisione di esperti per errori gravi e valutazioni contestate.

La valutazione delle skill di Amazon Bedrock AgentCore è importante perché cambia ciò che conta come prova. Un output fluente resta prezioso, ma non determina più da solo se un agente abbia seguito la procedura dell'organizzazione.

La domanda pratica ora è la vostra: il vostro team è in grado di spiegare quale skill ha selezionato un agente, perché quella scelta era adatta e quali passaggi obbligatori la traccia dimostra che ha completato? In caso contrario, integrate queste evidenze nel prossimo ciclo di test prima di aggiungere altre skill.