Creación de un agente de Azure AI con Microsoft Agent Framework

Foundry Agent Service es el proveedor recomendado para entornos de producción creados con el marco del agente de Microsoft. Controla el historial de conversaciones persistente en el lado del servicio, admite herramientas integradas, como la ejecución de código y la búsqueda de archivos, e integra perfectamente con Azure administración de identidades. Estas características le permiten centrarse en el comportamiento del agente en lugar de en su sobrecarga de infraestructura.

Configuración de un agente de Foundry

La creación e interacción con un agente de Foundry sigue una secuencia coherente de pasos.

1. Configura tu proyecto de Foundry

Antes de escribir cualquier código, necesita un proyecto de Microsoft Foundry con un modelo implementado. Se conecta al proyecto mediante dos fragmentos de información:

• Punto de conexión del proyecto: la dirección URL de tu proyecto de Foundry.
• Nombre de implementación del modelo: el nombre de la implementación del modelo que desea usar para el agente.

2. Configuración de la autenticación

Agent Framework se conecta al proyecto foundry mediante credenciales de Azure. En la mayoría de los escenarios, DefaultAzureCredential resuelve automáticamente la credencial correcta en función de su entorno, CLI de Azure durante el desarrollo, la identidad administrada en producción. No es necesario codificar cadenas de conexión ni claves de API.

3. Inicializar el cliente de chat de Foundry

Cree un cliente de chat de Foundry proporcionando las credenciales, el punto de conexión del proyecto y el nombre del modelo. Este cliente es el puente entre tu aplicación y el servicio Foundry Agent. Controla la autenticación, el enrutamiento de solicitudes y la administración de sesiones del lado del servicio.

4. Creación del agente

Con el cliente de chat, cree un agente proporcionando un conjunto de instrucciones que definen su comportamiento:

• Instrucciones: la solicitud del sistema que define el rol, los objetivos y las restricciones del agente.
• Tools(opcional): funciones personalizadas a las que el agente puede llamar para realizar acciones o recuperar información

El marco registra las herramientas que proporcione y genera automáticamente sus esquemas, por lo que el modelo sabe cuándo y cómo invocarlos.

5. Establecer una sesión y ejecutar el agente

Para empezar a interactuar, abra una sesión a través de la instancia del agente. La sesión actúa como contenedor para el estado de la conversación. Envías mensajes de usuario al método de ejecución de la sesión, que procesa la instrucción, coordina las llamadas necesarias a herramientas y devuelve la respuesta del modelo.

Conversaciones de múltiples turnos

Una sola llamada al método de ejecución del agente controla un intercambio: un mensaje de usuario, una respuesta. Para que haya una conversación real, es necesario que el agente recuerde lo que se dijo en intervenciones anteriores. Para eso sirve una sesión.

En el caso del proveedor Foundry, las sesiones están respaldadas por el almacenamiento en el lado del servicio, el historial de conversaciones reside en el servicio Foundry Agent en lugar de en la memoria de la aplicación.

• Historial persistente: dado que el estado reside en el lado del servicio, la conversación de un usuario puede continuar en varias solicitudes, incluso si la aplicación se reinicia o se escala horizontalmente a varias instancias.

• Historial local: para los proveedores que no admiten el historial del lado del servicio, el marco mantiene el estado de conversación en la memoria dentro del objeto de sesión. El historial local es adecuado para aplicaciones de corta duración o sin estado, pero no se conserva en los reinicios del proceso.

Respuestas sin transmisión continua frente a respuestas con transmisión continua

Agent Framework admite dos modos de respuesta:

• Sin streaming (sincrónico): el método run espera a que el agente finalice el procesamiento y devuelva un objeto de respuesta completo. No streaming es el patrón más sencillo y funciona bien cuando no es necesario mostrar la salida incrementalmente.

• Transmisión en flujo (asincrónica)—el método run devuelve un flujo de respuesta sobre el que se itera de forma asincrónica, recibiendo actualizaciones parciales a medida que el modelo las genera. El streaming es más adecuado para las interfaces orientadas al usuario, donde mostrar la salida mejora progresivamente la experiencia.

En ambos casos, la respuesta expone una text propiedad que agrega todo el contenido de texto de la salida del agente, lo que facilita la extracción de la respuesta final independientemente del modo que use.