¿Qué son los agentes hospedados?

Al compilar aplicaciones agente mediante marcos de código abierto, normalmente se administran muchos problemas transversales: contenedorización, configuración del servidor web, seguridad, persistencia de memoria, escalado, instrumentación y reversión de versiones. Estas tareas se vuelven aún más difíciles en entornos de nube heterogéneos.

Los agentes hospedados en Foundry Agent Service resuelven estos desafíos para los usuarios de Microsoft Foundry. Los agentes hospedados llaman a los modelos del catálogo de modelos de Foundry para realizar el razonamiento, mientras que tu código personalizado gestiona la orquestación. Mediante este uso de esta plataforma administrada, puede implementar y operar agentes de inteligencia artificial de forma segura y a gran escala. Puede usar el código de agente personalizado o un marco de agente preferido con una implementación y administración simplificadas.

Cuándo usar agentes hospedados

Elija agentes hospedados sobre agentes basados en instrucciones cuando necesite:

• Traiga su propio código: use cualquier marco (Agent Framework, LangGraph, Kernel semántico o código personalizado) en lugar de definiciones únicamente basadas en solicitudes.
• Usar protocolos personalizados: acepte webhooks o cargas que no sean de OpenAI a través del protocolo invocaciones.
• Controlar los recursos de computación : especifique la CPU y memoria para el sandbox del agente.
• Ejecuta cargas de trabajo con estado: conserva los archivos y el estado a lo largo de las transiciones a través de $HOME y el endpoint /files.

Cómo funciona

Tú empaquetas tu agente como una imagen de contenedor y lo subes al Azure Container Registry. Al implementar, Agent Service extrae la imagen, aprovisiona los recursos de cómputo, asigna un Microsoft Entra ID dedicado (identidad del agente) y expone un punto de conexión dedicado. En tiempo de ejecución, el código del agente controla las solicitudes de los clientes y puede llamar a modelos Foundry, herramientas de Foundry Toolbox y servicios de Azure de bajada mediante su identidad de agente. La plataforma controla el escalado, la persistencia del estado de sesión, la observabilidad y la administración del ciclo de vida.

Conceptos clave

Agentes hospedados

Los agentes hospedados son aplicaciones de IA en contenedores que se ejecutan en Agent Service. A diferencia de los agentes basados en mensajes, que se definen completamente a través de avisos y configuración de herramientas en el portal de Foundry, los agentes hospedados son su propio código empaquetado como una imagen de contenedor. Elija el framework, controle el comportamiento del tiempo de ejecución e implemente la imagen en la infraestructura administrada por Microsoft.

La plataforma administra automáticamente el ciclo de vida del contenedor en función de la actividad, aprovisionando recursos al crear una versión y desaprovisionando cuando se alcanza el tiempo de espera de inactividad.

Modelo de aislamiento

Los agentes hospedados se ejecutan en entornos aislados de máquina virtual por cada sesión. Cada sesión proporciona un espacio aislado dedicado con un sistema de archivos persistente ($HOME y /files), permitiendo escalar a cero con reanudar con estado y inicios en frío predecibles. Las sesiones se aíslan entre sí y el estado se restaura automáticamente cuando una sesión se reanuda después de estar inactiva.

Protocolos: respuestas e invocaciones

Los contenedores de agentes hospedados exponen uno o ambos protocolos. Cada protocolo lo proporciona una biblioteca ligera que controla el servidor HTTP, las comprobaciones de estado y la integración de OpenTelemetry.

¿Qué protocolo debo usar?

Comparación de protocolos

Protocolos adicionales

Los agentes hospedados también admiten el protocolo Activity para la integración de canales de Teams y M365 (normalmente utilizado junto con Responses) y el protocolo A2A para la delegación de agente a agente. Los cuatro protocolos (respuestas, invocaciones, actividad y A2A) se pueden combinar en un solo agente.

Identidad y punto de conexión del agente

Cada agente hospedado implementado en un proyecto Foundry obtiene su propio ID de Entra de Microsoft dedicado (identidad del agente) y endpoint dedicado, ambos creados automáticamente en el momento de la implementación. No es necesario configurar las identidades administradas ni el enrutamiento manualmente.

El punto de conexión está disponible inmediatamente después de la implementación: la publicación no es necesaria para el acceso mediante programación:

• Respuestas: {project_endpoint}/agents/{name}/endpoint/protocols/openai/v1/responses
• Invocaciones: {project_endpoint}/agents/{name}/endpoint/protocols/invocations

Los puntos de conexión que están activos dependen de los protocolos declarados en la definición de versión del agente (establecido en agent.yaml al usar azd o a través de container_protocol_versions cuando se usa el SDK).

Hay dos identidades implicadas:

Al implementar con azd, el rol RBAC necesario (Usuario de Azure AI en el ámbito de la cuenta) se asigna automáticamente al ID de Microsoft Entra del agente. En el caso de los recursos externos (por ejemplo, su propio Azure Storage), asigne RBAC manualmente al Microsoft Entra ID del agente.

Cuando se integra a través de canales de Microsoft 365 (por ejemplo, Teams), los agentes hospedados también pueden funcionar con la identidad de usuario en nombre de (OBO). El Microsoft Entra ID del agente puede intercambiar un token de usuario para llamar a servicios descendentes como usuario, sujeto a políticas de inquilino. Para obtener más información, consulte Conceptos de identidad del agente y aplicaciones del agente.

Sesiones y conversaciones

Los agentes hospedados usan sesiones y conversaciones para administrar el estado. El funcionamiento depende del protocolo.

Sesiones

Un identificador de sesión identifica una sesión lógica con estado persistente, incluidos $HOME y archivos cargados a través del punto de conexión /files. La plataforma aprovisiona recursos de computación a petición y restaura el estado persistente en dichos recursos.

• Persistencia de estado: $HOME y el contenido de /files se conservan en turnos y en períodos de inactividad. Cuando los recursos de computación quedan inactivos y se vuelven a activar (en una infraestructura nueva o existente), el estado de la sesión se restaura automáticamente.
• Aislamiento: cada sesión está aislada de otras sesiones.
• Ciclo de vida automático: las sesiones se crean en el primer uso. La plataforma aprovisiona y desaprovisiona recursos computacionales automáticamente.
• Duración de la sesión: las sesiones se conservan durante un máximo de 30 días. El tiempo de espera de inactividad es de 15 minutos; si no llega ninguna solicitud en ese período de tiempo, la plataforma desaprovisiona los recursos y persiste el estado de la sesión.
• API de administración de sesiones: enumera las sesiones, finaliza sesiones y carga o descarga de archivos por sesión.

Conversaciones

Un identificador de conversación es un registro duradero del historial de conversaciones (mensajes, llamadas a herramientas y respuestas) almacenados en Foundry.

• Persistencia: el historial de conversaciones se almacena en Foundry y se conserva independientemente del estado de proceso.
• Acceso entre canales: los usuarios pueden acceder a la misma conversación desde el área de juegos, la API, Teams u otros canales publicados.

Cómo funcionan las sesiones y las conversaciones con cada protocolo

Protocolo de respuestas: el identificador de conversación es el concepto principal. La plataforma administra automáticamente el historial de conversaciones y asocia un identificador de sesión a cada conversación. La plataforma devuelve el identificador de sesión al cliente, que puede usarlo para cargar archivos a través del punto de conexión /files, lo que hace que esos archivos estén disponibles para el proceso de la conversación.

Protocolo de invocaciones: el identificador de sesión es el concepto principal. El cliente administra el identificador de sesión directamente para mantener el estado entre interacciones. El cliente puede cargar contenido a través del punto de conexión /files mediante el identificador de sesión para que esté disponible para la sesión. No hay ningún historial de conversaciones administrado por la plataforma: administra el estado en su propio código.

Ciclo de vida de cómputo de sesión

Seguridad y control de datos

Trate un agente hospedado como el código de la aplicación de producción.

• No coloque secretos en imágenes de contenedor ni variables de entorno. Use identidades administradas y conexiones y almacene secretos en un almacén de secretos administrados. Para obtener instrucciones, consulte Set up a Key Vault connection.
• Ten cuidado con herramientas y servidores que no son de Microsoft. Si el agente llama a herramientas respaldadas por servicios no proporcionados por Microsoft, algunos datos pueden ser transferidos a esos servicios. Revise las directivas de uso compartido, retención y ubicación de datos para cualquier servicio que no sea de Microsoft que se conecte.

Detalles de la plataforma

Control de versiones

Cada llamada para crear una versión genera una versión del agente inmutable, una instantánea de la imagen de contenedor, la asignación de recursos, las variables de entorno y la configuración del protocolo. Las implementaciones hacen referencia a una versión específica. Actualiza tu agente creando una nueva versión y la plataforma la despliega. Tenga en cuenta que las solicitudes para crear la versión del agente sin ningún cambio en los parámetros de versión del agente, como la imagen de contenedor, las variables de entorno, etc., no darán lugar a que se cree una nueva versión. Puede dividir el tráfico entre versiones con despliegues ponderados para soportar implementaciones canario y azul-verde.

Las variables de entorno son el mecanismo principal para pasar la configuración al contenedor en tiempo de ejecución (por ejemplo, el punto de conexión del proyecto, el nombre de implementación del modelo y la configuración personalizada). Se establecen por versión y son inmutables una vez creada la versión.

Herramientas de Fundición

Los agentes hospedados acceden a las herramientas administradas por Foundry (Intérprete de código, Búsqueda web, Búsqueda de Azure AI, OpenAPI, conexiones MCP personalizadas, A2A) a través de un punto de conexión MCP de Toolbox aprovisionado en el proyecto foundry. El código del agente se conecta a este punto de conexión mediante bibliotecas cliente de MCP estándar; la plataforma no inserta herramientas automáticamente. Para obtener más información, consulte Curate intent-based toolbox in Foundry (Curar cuadro de herramientas basado en intenciones en Foundry).

Compatibilidad con idiomas

Los agentes hospedados admiten Python y C#. Puede usar cualquier marco de trabajo del agente: las bibliotecas de protocolos son independientes del marco de trabajo. Para obtener ejemplos con Microsoft Agent Framework, LangGraph y código personalizado, consulte el repositorio foundry-samples.

Tamaños de espacio aislado

Los espacios aislados del agente hospedado admiten asignaciones de CPU y memoria que van desde 0,25 vCPU/0,5 GiB a 2 vCPU/4 GiB.

Redes privadas

Los agentes hospedados respaldan la implementación dentro de recursos de Foundry aislados de la red. Para obtener más información, consulte Configuración de redes virtuales. Tenga en cuenta que el Azure Container Registry que contiene la imagen del agente debe permanecer accesible actualmente a través de su punto de conexión público; ACR protegido por red privada no se admite actualmente.

Límites, precios y disponibilidad (versión preliminar)

Los agentes hospedados se encuentran actualmente en versión de prueba.

Limitaciones durante la versión preliminar

Precios

La facturación del entorno de ejecución de hospedaje administrado se basa en el consumo de recursos de CPU y memoria durante las sesiones activas. Para obtener las tarifas actuales, consulte la página precios de Foundry.

Disponibilidad de regiones

Los agentes hospedados están disponibles actualmente en las siguientes regiones:

• Este de EE. UU. 2
• Centro-norte de EE. UU.
• Centro de Suecia
• Centro de Canadá
• Sudeste asiático
• Centro de Polonia
• Norte de Sudáfrica
• Centro de Corea del Sur
• Sur de la India
• Sur de Brasil
• Oeste de EE. UU.
• Oeste de EE. UU. 3
• Este de Noruega
• Este de Japón
• Centro de Francia
• Norte de Suiza
• Centro de España
• Este de Australia

Pasos siguientes

Contenido relacionado

• Componentes en tiempo de ejecución del agente
• Ciclo de vida de desarrollo del agente
• Conceptos de identidad de agente en Microsoft Foundry
• Detección de herramientas en Foundry Tools
• documentación de Azure Container Registry