Condividi tramite


Esplorazione del kernel semantico BedrockAgent

Importante

Le funzionalità a agente singolo, ad esempio BedrockAgent, sono attualmente in fase sperimentale. Queste funzionalità sono in fase di sviluppo attivo e possono cambiare prima di raggiungere la disponibilità generale.

La documentazione dettagliata dell'API relativa a questa discussione è disponibile all'indirizzo:

La documentazione dell'API BedrockAgent sarà presto disponibile.

La documentazione dell'API BedrockAgent sarà presto disponibile.

Funzionalità attualmente non disponibile in Java.

Che cos'è un BedrockAgent?

L'agente Bedrock è un agente di intelligenza artificiale specializzato all'interno di Semantic Kernel progettato per l'integrazione con il servizio Agente di Amazon Bedrock. Come gli agenti OpenAI e Azure AI, un agente Bedrock consente funzionalità di conversazione avanzate a più turni con un'integrazione fluida degli strumenti (azioni), ma opera interamente nell'ecosistema AWS. Automatizza la chiamata di funzioni/strumenti (denominati gruppi di azioni in Bedrock), quindi non è necessario analizzare ed eseguire manualmente le azioni e gestisce in modo sicuro lo stato della conversazione in AWS tramite sessioni, riducendo la necessità di mantenere la cronologia delle chat nell'applicazione.

Un agente Bedrock differisce da altri tipi di agenti in alcuni modi chiave:

  • Esecuzione gestita di AWS: A differenza di OpenAI Assistant che usa il cloud di OpenAI o l'agente di Intelligenza artificiale di Azure che usa il servizio Foundry di Azure, l'agente Bedrock viene eseguito su Amazon Bedrock. Per usarlo, è necessario disporre di un account AWS con accesso a Bedrock (e autorizzazioni IAM appropriate). Il ciclo di vita dell'agente (creazione, sessioni, eliminazione) e alcune esecuzioni degli strumenti vengono gestite dai servizi AWS, mentre gli strumenti di chiamata alle funzioni vengono eseguiti localmente all'interno dell'ambiente.

  • Selezione del modello di base: Quando si crea un agente Bedrock, specificare quale modello di base (ad esempio, un modello Amazon Titan o partner) deve usare. È possibile usare solo i modelli a cui è stato concesso l'accesso. Questo è diverso dagli agenti di completamento della chat (di cui si crea un'istanza con un endpoint del modello diretto): con Bedrock, il modello viene scelto al momento della creazione dell'agente come capacità predefinita dell'agente.

  • Requisito del ruolo IAM: Gli agenti Bedrock richiedono che venga fornito un ruolo IAM ARN al momento della creazione. Questo ruolo deve disporre delle autorizzazioni per richiamare il modello scelto (ed eventuali strumenti integrati) per conto dell'utente. Ciò garantisce che l'agente disponga dei privilegi necessari per eseguire le azioni (ad esempio, l'esecuzione di codice o l'accesso ad altri servizi AWS) nell'account AWS.

  • Strumenti predefiniti (gruppi di azioni): Bedrock supporta "gruppi di azioni" predefiniti (strumenti) che possono essere collegati a un agente. Ad esempio, è possibile abilitare un gruppo di azioni Interprete codice per consentire all'agente di eseguire codice Python o un gruppo di azioni Input utente per consentire all'agente di richiedere chiarimenti. Queste funzionalità sono analoghe al plug-in Code Interpreter o alla chiamata di funzione di OpenAI, ma in AWS sono configurate in modo esplicito sull'agente. Un agente Bedrock può anche essere esteso con plugin personalizzati di Semantic Kernel (funzioni) per strumenti specifici del dominio, simili ad altri agenti.

  • Thread basati su sessione: Le conversazioni con un agente Bedrock si verificano in thread collegati a sessioni Bedrock su AWS. Ogni thread (sessione) viene identificato da un ID univoco fornito dal servizio Bedrock e la cronologia delle conversazioni viene archiviata dal servizio anziché in-process. Ciò significa che i dialoghi a più turni vengono mantenuti in AWS e si ottiene il contesto tramite l'ID sessione. La classe Semantic Kernel BedrockAgentThread astrae questo dettaglio: quando lo si usa, crea o continua una sessione Bedrock dietro le quinte dell'agente.

In sintesi, BedrockAgent consente di sfruttare il potente framework agente e strumenti di Amazon Bedrock tramite il kernel semantico, fornendo un dialogo diretto con i modelli e gli strumenti ospitati in AWS. Automatizza le complessità dell'API agente di Bedrock (creazione dell'agente, gestione delle sessioni, chiamata dello strumento) in modo da poter interagire con esso in un'interfaccia SK multi-linguaggio di alto livello.

Preparazione dell'ambiente di sviluppo

Per iniziare a sviluppare con un BedrockAgent, configurare l'ambiente con i pacchetti del kernel semantico appropriati e assicurarsi che siano soddisfatti i prerequisiti di AWS.

Suggerimento

Vedere la documentazione di AWS sulla configurazione dell'ambiente per l'uso dell'API Bedrock.

Aggiungere il pacchetto Semantic Kernel Bedrock Agents al progetto .NET:

dotnet add package Microsoft.SemanticKernel.Agents.Bedrock --prerelease

In questo modo verrà fornito il supporto del Semantic Kernel SDK per Bedrock, comprese le dipendenze dall'AWS SDK per Bedrock. Potrebbe anche essere necessario configurare le credenziali AWS, ad esempio tramite variabili di ambiente o la configurazione predefinita di AWS. AWS SDK utilizzerà le credenziali configurate; assicurati di avere impostato AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY e l'area predefinita nel tuo ambiente o profilo AWS. Per altre informazioni, vedere la documentazione di AWS sulla configurazione delle credenziali.

Installare il pacchetto Semantic Kernel con le funzionalità aggiuntive di AWS:

pip install semantic-kernel[aws]

In questo modo si garantisce che le librerie AWS necessarie (ad esempio boto3) siano installate insieme al kernel semantico. Prima di usare un agente Bedrock in Python, assicurarsi che le credenziali e l'area AWS siano configurate correttamente, ad esempio impostando le variabili di ambiente o usando l'interfaccia della riga di comando di AWS. È necessario impostare AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEYe AWS_DEFAULT_REGION (o profilo AWS) in modo che boto3 possa eseguire l'autenticazione.

Funzionalità attualmente non disponibile in Java.

Creazione di un BedrockAgent

La creazione di un agente Bedrock prevede due passaggi: prima di tutto, la definizione dell'agente con Amazon Bedrock (inclusa la selezione di un modello e le istruzioni iniziali) e quindi la creazione di un'istanza dell'oggetto agente del kernel semantico per interagire con esso. Quando si crea l'agente in AWS, viene avviato in uno stato non preparato, quindi viene eseguita un'operazione aggiuntiva di "preparazione" per prepararla per l'uso.

using Amazon.Bedrock;
using Amazon.Bedrock.Model;
using Amazon.BedrockRuntime;
using Microsoft.SemanticKernel.Agents.Bedrock;

// 1. Define a new agent on the Amazon Bedrock service
IAmazonBedrock bedrockClient = new AmazonBedrockClient();  // uses default AWS credentials & region
var createRequest = new CreateAgentRequest 
{
    AgentName = "<foundation model ID>",          // e.g., "anthropic.claude-v2" or other model
    FoundationModel = "<foundation model ID>",    // the same model, or leave null if AgentName is the model
    AgentResourceArn = "<agent role ARN>",        // IAM role ARN with Bedrock permissions
    Instruction = "<agent instructions>"
};
CreateAgentResponse createResponse = await bedrockClient.CreateAgentAsync(createRequest);

// (Optional) Provide a description as needed:
// createRequest.Description = "<agent description>";

// After creation, the agent is in a "NOT_PREPARED" state.
// Prepare the agent to load tools and finalize setup:
await bedrockClient.PrepareAgentAsync(new PrepareAgentRequest 
{
    AgentId = createResponse.Agent.AgentId
});

// 2. Create a Semantic Kernel agent instance from the Bedrock agent definition
IAmazonBedrockRuntime runtimeClient = new AmazonBedrockRuntimeClient();
BedrockAgent agent = new BedrockAgent(createResponse.Agent, bedrockClient, runtimeClient);

Nel codice precedente viene prima usato AWS SDK (AmazonBedrockClient) per creare un agente in Bedrock, specificando il modello di base, un nome, le istruzioni e l'ARN del ruolo IAM che l'agente deve assumere. Il servizio Bedrock risponde con una definizione dell'agente (incluso un AgentId univoco). Viene quindi chiamato PrepareAgentAsync per eseguire la transizione dell'agente a uno stato pronto (l'agente passerà da uno stato CREATING a NOT_PREPARED, quindi a PREPARED una volta pronto). Infine, si costruisce un BedrockAgent oggetto usando la definizione restituita e i client AWS. Questa BedrockAgent istanza è quella che verrà usata per inviare messaggi e ricevere risposte.

import boto3
from semantic_kernel.agents import BedrockAgent

# 1. Define and prepare a new agent on Amazon Bedrock
agent = await BedrockAgent.create_and_prepare_agent(
    name="<agent name>", 
    instructions="<agent instructions>",
    foundation_model="<foundation model ID>",
    agent_resource_role_arn="<agent role ARN>"
)

Nell'esempio precedente, BedrockAgent.create_and_prepare_agent gestisce il flusso di creazione completo: usa la configurazione AWS (tramite boto3) per creare un agente in Bedrock con il nome, il modello di base e le istruzioni specificati, quindi attende automaticamente che l'agente raggiunga uno stato pronto (eseguendo il passaggio di preparazione internamente). Il risultato è un'istanza BedrockAgent pronta per l'uso. Sotto il cofano, questo metodo sta creando client AWS (per Bedrock e Bedrock Runtime) usando le credenziali predefinite, quindi accertarsi che il proprio ambiente AWS sia configurato. Se è necessaria una configurazione personalizzata, è anche possibile costruire manualmente i client AWS e passarli come parametri (ad esempio client= boto3.client("bedrock") e runtime_client= boto3.client("bedrock-runtime")) alla create_and_prepare_agent chiamata.

Funzionalità attualmente non disponibile in Java.

Recupero di un oggetto esistente BedrockAgent

Dopo aver creato un agente in Bedrock, il relativo identificatore univoco (ID agente) può essere usato per recuperarlo in un secondo momento. In questo modo è possibile ripristinare un'istanza di BedrockAgent nel Semantic Kernel senza doverla ricreare da zero.

Per .NET, l'identificatore dell'agente Bedrock è una stringa accessibile tramite agent.Id. Per recuperare un agente esistente in base all'ID, usare il client AWS Bedrock e quindi costruire un nuovo BedrockAgent:

string existingAgentId = "<your agent ID>";
var getResponse = await bedrockClient.GetAgentAsync(new GetAgentRequest { AgentId = existingAgentId });
BedrockAgent agent = new BedrockAgent(getResponse.Agent, bedrockClient, runtimeClient);

In questo caso viene chiamato GetAgentAsync sul IAmazonBedrock client con l'ID noto, che restituisce la definizione dell'agente (nome, modello, istruzioni e così via). Si inizializza quindi un nuovo BedrockAgent oggetto con tale definizione e gli stessi client. Questa istanza dell'agente verrà collegata all'agente Bedrock esistente.

In Python, è possibile recuperare in maniera simile un agente in base all'ID usando il client boto3 AWS Bedrock, quindi eseguirne il wrapping in BedrockAgent.

import asyncio, boto3
from semantic_kernel.agents import BedrockAgent

agent_id = "<your agent ID>"
bedrock_client = boto3.client("bedrock")  # Bedrock service client
# Fetch the agent's definition from AWS
agent_info = await asyncio.to_thread(bedrock_client.get_agent, AgentId=agent_id)
# Create the BedrockAgent instance from the retrieved definition
agent = BedrockAgent(agent_model=agent_info["agent"])

In questo frammento di codice, utilizziamo boto3 per chiamare get_agent sul servizio Bedrock (eseguendolo in un thread tramite asyncio.to_thread poiché boto3 è bloccante). L'oggetto restituito agent_info["agent"] contiene i dettagli dell'agente (id, nome, stato e così via), che passiamo al costruttore BedrockAgent. Poiché i client AWS non sono stati forniti in modo esplicito a BedrockAgent, verranno creati internamente nuovi client con impostazioni predefinite. Facoltativamente, è possibile fornire client= e runtime_client= per riusare i client, se disponibili.

Funzionalità attualmente non disponibile in Java.

Interazione con bedrockAgent

Dopo aver creato un'istanza di BedrockAgent, l'interazione con essa (invio di messaggi utente e ricezione di risposte di intelligenza artificiale) è semplice. L'agente usa thread per gestire il contesto della conversazione. Per un agente Bedrock, un thread corrisponde a una sessione AWS Bedrock. La classe Semantic Kernel BedrockAgentThread gestisce la creazione e il rilevamento della sessione: quando si avvia una nuova conversazione, viene avviata una nuova sessione Bedrock e durante l'invio di messaggi, Bedrock mantiene la cronologia dei messaggi alternata dell'utente/assistente. (Bedrock richiede che la cronologia delle chat si alterni tra i messaggi utente e assistente; se necessario, la logica del canale del kernel semantico inserirà segnaposto per far rispettare questo schema.) È possibile richiamare l'agente senza specificare un thread (in questo caso, il kernel semantico creerà automaticamente un nuovo BedrockAgentThread) oppure è possibile creare/gestire in modo esplicito un thread se si desidera proseguire una conversazione su più chiamate. Ogni chiamata restituisce una o più risposte ed è possibile gestire la durata del thread, ad esempio eliminandola al termine della sessione AWS.

Le specifiche del thread dell'agente Bedrock sono astratte dalla BedrockAgentThread classe (che implementa l'interfaccia comune AgentThread ). Il BedrockAgent supporta attualmente solo i thread di tipo BedrockAgentThread.

BedrockAgent agent = /* (your BedrockAgent instance, as created above) */;

// Start a new conversation thread for the agent
AgentThread agentThread = new BedrockAgentThread(runtimeClient);
try
{
    // Send a user message and iterate over the response(s)
    var userMessage = new ChatMessageContent(AuthorRole.User, "<your user input>");
    await foreach (ChatMessageContent response in agent.InvokeAsync(userMessage, agentThread))
    {
        Console.WriteLine(response.Content);
    }
}
finally
{
    // Clean up the thread and (optionally) the agent when done
    await agentThread.DeleteAsync();
    await agent.Client.DeleteAgentAsync(new DeleteAgentRequest { AgentId = agent.Id });
}

In questo esempio, creiamo esplicitamente un BedrockAgentThread (passando il runtimeClient, che utilizza per comunicare con il servizio di runtime Bedrock). Quindi chiamiamo agent.InvokeAsync(...) con un ChatMessageContent che rappresenta il messaggio di un utente. InvokeAsync restituisce un flusso asincrono di risposte: in pratica, un agente Bedrock restituisce in genere una risposta finale per ogni chiamata (poiché le azioni intermedie degli strumenti vengono gestite separatamente), quindi in genere si otterrà un singolo ChatMessageContent dal ciclo. Stampamo la risposta dell'assistente (response.Content). Nel blocco finally si elimina il thread, che termina la sessione Bedrock su AWS. In questo caso si elimina anche l'agente stesso (poiché è stato creato solo per questo esempio): questo passaggio è facoltativo e necessario solo se non si intende riutilizzare nuovamente l'agente (vedere Eliminazione di un BedrockAgent di seguito).

È possibile continuare una conversazione esistente riutilizzando la stessa agentThread per le chiamate successive. Ad esempio, è possibile eseguire un ciclo di lettura dell'input dell'utente e chiamare InvokeAsync ogni volta con lo stesso thread per eseguire una finestra di dialogo a più turni. È anche possibile creare un BedrockAgentThread con un ID sessione noto per riprendere una conversazione salvata in precedenza:

string sessionId = "<existing Bedrock session ID>";
AgentThread thread = new BedrockAgentThread(runtimeClient, sessionId);
// Now `InvokeAsync` using this thread will continue the conversation from that session

L'uso di un agente Bedrock in Python è simile, con la BedrockAgentThread che gestisce la sessione. È possibile avviare un nuovo thread o passarne uno esistente per continuare una conversazione:

from semantic_kernel.agents import BedrockAgentThread

# Assume `agent` is your BedrockAgent instance
USER_INPUTS = ["Hello", "What's your name?"]

thread = BedrockAgentThread()  # start a new conversation thread (session)
try:
    for user_input in USER_INPUTS:
        response = await agent.get_response(messages=user_input, thread=thread)
        print(response)  # print the assistant's reply
        thread = response.thread  # update thread (BedrockAgentThread) for next turn
finally:
    await thread.delete() if thread else None

In questo codice scorriamo un paio di input dell'utente. In ogni iterazione viene chiamato agent.get_response(...) con il messaggio utente e il thread corrente. La prima chiamata avvia la sessione Bedrock e restituisce un AgentResponseItem (o ChatMessageContent) contenente la risposta dell'assistente. La risposta viene stampata, quindi si prende response.thread – che è lo stesso BedrockAgentThread aggiornato con il nuovo contesto del messaggio – da utilizzare nel turno successivo. Dopo la conversazione (in questo esempio, due turni), si elimina il thread per terminare la sessione in AWS.

Se ometti il parametro thread nella chiamata, agent.get_response o agent.invoke creeranno automaticamente un nuovo thread per quell'invocazione e lo includeranno nella risposta.

Facoltativamente, è anche possibile inviare un batch di messaggi contemporaneamente passando un elenco di messaggi a get_response o usando la chiamata di streaming asincrona. Ad esempio, per trasmettere in streaming la risposta dell'assistente (token per token) per una singola richiesta:

# Streaming a single response from the Bedrock agent
async for partial in agent.invoke_stream(messages="Tell me a joke.", thread=thread):
    print(partial.content, end="")

Il invoke_stream(...) metodo restituisce ChatMessageContent oggetti durante la generazione della risposta. Eseguendo l'iterazione su di esso, è possibile restituire la risposta dell'assistente in modo incrementale (qui si stampano caratteri senza una nuova riga per formare la risposta completa).

Funzionalità attualmente non disponibile in Java.

Eliminazione di un oggetto BedrockAgent

Gli agenti Bedrock sono risorse persistenti nell'account AWS, che rimarranno (e potrebbero comportare costi o conteggi rispetto ai limiti del servizio) fino all'eliminazione. Se non è più necessario un agente creato, è necessario eliminarlo tramite l'API del servizio Bedrock.

Usare il client Bedrock per eliminare in base all'ID agente. Per esempio:

await bedrockAgent.Client.DeleteAgentAsync(new() { AgentId = bedrockAgent.Id });

Dopo questa chiamata, lo stato dell'agente cambierà e non sarà più utilizzabile. Il tentativo di richiamare un agente eliminato genererà un errore.

Chiamare il metodo di eliminazione dell'agente. Per esempio:

await agent.delete_agent()

Verrà chiamato il servizio Bedrock per eliminare l'agente (e contrassegnare internamente l'oggetto BedrockAgent come eliminato). È possibile verificare controllando agent.id o un flag se specificato (ad esempio, _is_deleted).

Nota: L'eliminazione di un agente Bedrock non termina automaticamente le sessioni in corso. Se hai sessioni a esecuzione prolungata (thread), dovresti terminarle eliminando i thread (che chiamano internamente EndSession e DeleteSession di Bedrock). In pratica, l'eliminazione di un thread (come illustrato negli esempi precedenti) termina la sessione.

Funzionalità attualmente non disponibile in Java.

Gestione dei messaggi intermedi con un BedrockAgent

Quando un agente Bedrock richiama strumenti (gruppi di azioni) per arrivare a una risposta, tali passaggi intermedi (chiamate di funzione e risultati) vengono gestiti internamente per impostazione predefinita. La risposta finale dell'agente farà riferimento al risultato di tali strumenti, ma non includerà automaticamente dettagli dettagliati. Tuttavia, il kernel semantico consente di accedere a tali messaggi intermedi per la registrazione o la gestione personalizzata fornendo un callback.

Durante agent.invoke(...) o agent.invoke_stream(...), è possibile fornire una on_intermediate_message funzione di callback. Questo callback verrà richiamato per ogni messaggio intermedio generato nel processo di simulazione della risposta finale. I messaggi intermedi possono includere FunctionCallContent (quando l'agente decide di chiamare una funzione/strumento) e FunctionResultContent (quando uno strumento restituisce un risultato).

Si supponga, ad esempio, che l'agente Bedrock abbia accesso a un semplice plug-in (o strumento predefinito) per informazioni sul menu, analogamente agli esempi usati con OpenAI Assistant:

from semantic_kernel.contents import ChatMessageContent, FunctionCallContent, FunctionResultContent
from semantic_kernel.functions import kernel_function

# Define a sample plugin with two functions
class MenuPlugin:
    @kernel_function(description="Provides a list of specials from the menu.")
    def get_specials(self) -> str:
        return "Soup: Clam Chowder; Salad: Cobb Salad; Drink: Chai Tea"

    @kernel_function(description="Provides the price of a menu item.")
    def get_item_price(self, menu_item: str) -> str:
        return "$9.99"

# Callback to handle intermediate messages
async def handle_intermediate_steps(message: ChatMessageContent) -> None:
    for item in (message.items or []):
        if isinstance(item, FunctionCallContent):
            print(f"Function Call:> {item.name} with arguments: {item.arguments}")
        elif isinstance(item, FunctionResultContent):
            print(f"Function Result:> {item.result} for function: {item.name}")
        else:
            print(f"[Intermediate] {item}")

# Create the BedrockAgent with the plugin (assuming agent is not yet created above)
agent = await BedrockAgent.create_and_prepare_agent(
    name="MenuAgent",
    instructions="You are a restaurant assistant.",
    foundation_model="<model ID>",
    agent_resource_role_arn="<role ARN>",
    plugins=[MenuPlugin()]  # include our custom plugin
)

# Start a conversation with intermediate callback
thread = BedrockAgentThread()
user_queries = [
    "Hello!",
    "What are the specials today?",
    "What is the special drink?",
    "How much is that?"
]
try:
    for query in user_queries:
        print(f"# User: {query}")
        async for response in agent.invoke(messages=query, thread=thread, on_intermediate_message=handle_intermediate_steps):
            print(f"# Assistant: {response}")
            thread = response.thread
finally:
    await thread.delete() if thread else None
    await agent.delete_agent()

In questo codice, ogni volta che l'agente deve chiamare una funzione da MenuPlugin (ad esempio, get_specials o get_item_price), il handle_intermediate_steps callback stampa una riga per la chiamata di funzione e un'altra per il risultato della funzione. La risposta dell'assistente finale per ogni query utente viene quindi stampata normalmente. Osservando il contenuto intermedio, è possibile tracciare il modo in cui l'agente è arrivato alla risposta (quale strumento è stato usato, ciò che ha restituito e così via).

Ad esempio, l'output potrebbe essere simile al seguente:

# User: Hello!
# Assistant: Hello! How can I assist you today?
# User: What are the specials today?
Function Call:> MenuPlugin-get_specials with arguments: {}
Function Result:> Soup: Clam Chowder; Salad: Cobb Salad; Drink: Chai Tea for function: MenuPlugin-get_specials
# Assistant: The specials today include Clam Chowder for the soup, Cobb Salad, and Chai Tea as a special drink.
# User: What is the special drink?
# Assistant: The special drink is Chai Tea.
# User: How much is that?
Function Call:> MenuPlugin-get_item_price with arguments: {"menu_item": "Chai Tea"}
Function Result:> $9.99 for function: MenuPlugin-get_item_price
# Assistant: The special drink (Chai Tea) costs $9.99.

Nell'interazione precedente, le stampe intermedie mostrano che l'agente ha chiamato MenuPlugin.get_specials correttamente e MenuPlugin.get_item_price nei momenti appropriati e ha usato i risultati per rispondere all'utente. Questi dettagli intermedi possono essere registrati o usati nella logica dell'applicazione in base alle esigenze, ad esempio per visualizzare i passaggi impiegato dall'agente.

Il supporto del callback per i messaggi intermedi in BedrockAgent (C#) segue un modello simile, ma l'API esatta è in fase di sviluppo. Le versioni future consentiranno di registrare un delegato da gestire FunctionCallContent e FunctionResultContent durante InvokeAsync.)

Funzionalità attualmente non disponibile in Java.

Uso di YAML dichiarativo per definire un agente Bedrock

Il framework agente del kernel semantico supporta uno schema dichiarativo per la definizione degli agenti tramite YAML (o JSON). In questo modo è possibile specificare la configurazione di un agente, ovvero il tipo, i modelli, gli strumenti e così via, in un file e quindi caricare la definizione dell'agente in fase di esecuzione senza scrivere codice imperativo per crearlo.

Nota: Le definizioni degli agenti basati su YAML sono una funzionalità emergente e possono essere sperimentali. Assicurarsi di usare una versione semantica del kernel che supporti il caricamento dell'agente YAML e fare riferimento alla documentazione più recente per eventuali modifiche al formato.

L'uso di una specifica dichiarativa può semplificare la configurazione, soprattutto se si vuole cambiare facilmente le configurazioni dell'agente o usare un approccio ai file di configurazione. Per un agente Bedrock, una definizione YAML potrebbe essere simile alla seguente:

type: bedrock_agent
name: MenuAgent
description: Agent that answers questions about a restaurant menu
instructions: You are a restaurant assistant that provides daily specials and prices.
model:
  id: anthropic.claude-v2
agent_resource_role_arn: arn:aws:iam::123456789012:role/BedrockAgentRole
tools:
  - type: code_interpreter
  - type: user_input
  - name: MenuPlugin
    type: kernel_function

In questo YAML (ipotetico) viene definito un agente di tipo bedrock_agent, si assegnano un nome e istruzioni, si specifica il modello di base in base all'ID e si specifica l'ARN del ruolo che deve usare. Dichiariamo anche un paio di strumenti: uno che abilita l'interprete di codice predefinito, un altro abilitando lo strumento input utente predefinito e un menuPlugin personalizzato (che verrebbe definito separatamente nel codice e registrato come funzione kernel). Un file di questo tipo incapsula la configurazione dell'agente in un formato leggibile.

Per creare un'istanza di un agente da YAML, usare il loader statico con una factory appropriata. Per esempio:

string yamlText = File.ReadAllText("bedrock-agent.yaml");
var factory = new BedrockAgentFactory();  // or an AggregatorAgentFactory if multiple types are used
Agent myAgent = await KernelAgentYaml.FromAgentYamlAsync(kernel, yamlText, factory);

Il file YAML verrà analizzato e, usando il kernel e la factory forniti, verrà generata un'istanza BedrockAgent (o un altro tipo basato sul campo type).

La gestione di BedrockAgent Declarative Spec sarà presto disponibile.

Funzionalità attualmente non disponibile in Java.

L'uso di uno schema dichiarativo può essere particolarmente potente per la configurazione e il test dello scenario, in quanto è possibile scambiare modelli o istruzioni modificando un file di configurazione anziché modificando il codice. Tenere d'occhio la documentazione e gli esempi del kernel semantico per altre informazioni sulle definizioni degli agenti YAML man mano che la funzionalità si evolve.

Altre risorse

  • Documentazione di AWS Bedrock: per altre informazioni sulle funzionalità dell'agente di Amazon Bedrock, vedere Amazon Bedrock Agents nella documentazione di AWS (ad esempio, come configurare l'accesso al modello di base e i ruoli IAM). Comprendere il servizio sottostante consentirà di impostare le autorizzazioni corrette e di sfruttare al meglio gli strumenti predefiniti.
  • Esempi del kernel semantico: il repository del kernel semantico contiene esempi di concetti per gli agenti Bedrock. Ad esempio, l'esempio di chat di base di Bedrock Agent negli esempi python illustra la semplice Q&A con un BedrockAgente l'esempio bedrock Agent with Code Interpreter illustra come abilitare e usare lo strumento Interprete del codice. Questi esempi possono essere un ottimo punto di partenza per vedere BedrockAgent in azione.

Grazie all'integrazione dell'agente Amazon Bedrock, Semantic Kernel consente soluzioni di intelligenza artificiale multipiattaforma, indipendentemente dal fatto che si usi OpenAI, Azure OpenAI o AWS Bedrock, è possibile creare applicazioni di conversazione avanzate con l'integrazione degli strumenti usando un framework coerente. L'apertura di BedrockAgent offre la possibilità di sfruttare gli ultimi modelli fondamentali di AWS e il paradigma dell'agente estendibile sicuro per i tuoi progetti Semantic Kernel.

Passaggi successivi