Migración de aplicaciones del agente al nuevo punto de conexión del agente y a la experiencia de publicación

En esta guía se explica cómo ha cambiado la experiencia de publicación del agente en Microsoft Foundry. Compara el modelo heredado (que creó un recurso de aplicación de agente independiente) con el nuevo modelo de objetos de agente y le guía a través de la migración de los agentes existentes y las aplicaciones publicadas.

Información general sobre el cambio

El nuevo modelo de objeto de agente fusiona aplicaciones de agentes e implementaciones de agentes en el objeto Agent en sí mismo. Anteriormente, la publicación creó un recurso de aplicación de agente independiente con su propia identidad, punto de conexión e implementación. Ahora, cada agente tiene estas funcionalidades desde el momento en que se crea.

Antes (modelo heredado)

1. Modelo de recursos: un agente (plano de datos), la aplicación del agente (plano de control) y la implementación (plano de control) son objetos independientes.
2. Propiedades del objeto del agente: id (identificador único para el agente), namey versions (la versión más reciente del agente).
3. Identidad: Los agentes no publicados en un proyecto Foundry comparten una identidad de agente Entra y un esquema de agente Entra. Tras la publicación, un agente recibe una identidad única y un esquema asociado con el recurso de la aplicación del agente.
4. Publicación: dos gestos. En primer lugar, la publicación de un agente crea un recurso de aplicación del agente y una implementación, donde la implementación hace referencia a la versión del agente publicada. La aplicación del agente expone un punto de conexión estable que enruta 100% de tráfico a esa versión. Una implementación admite la administración del ciclo de vida de inicio y parada. El segundo paso es que la aplicación del agente se puede publicar en Microsoft 365 y Teams.

Después (nuevo modelo)

1. Modelo de recursos: solo existen objetos del Agente (plano de datos y plano de control). Absorben las responsabilidades que anteriormente eran propiedad del Agente de Aplicaciones y Despliegue.
2. Propiedades del objeto del agente: id, name, versions, agent_endpoint (punto de conexión estable), protocols, authorization_schemesversion_selector, blueprint, , instance_identityy agent_card (expone los detalles y funcionalidades del agente a los consumidores y A2A).
3. Identidad: todos los agentes reciben una identidad única de Entra Agent Identity y Entra Agent Blueprint de forma predeterminada. Bring-your-own Entra Agent Blueprint es compatible, pero no es la opción predeterminada.
4. Publicación: Dos gestos equivalentes. En primer lugar, seleccione una versión del agente para exponer a través del punto de conexión estable. En segundo lugar, publique el punto de conexión estable del agente en M365/Teams.

El cambio de clave: la creación de un agente es el único paso necesario para obtener un punto de conexión estable y una identidad de agente única. No hay un paso de publicación separado para el punto de conexión. La publicación ahora hace referencia específicamente a la distribución del agente a través de los canales de M365 y Teams.

Tipos de agente durante la transición

Durante el período de transición, puede encontrar tres tipos de agentes:

El valor agent.identity distingue a los agentes nuevos de los agentes heredados: null significa que es heredado, distinto de null significa nuevo.

Lo que sigue funcionando

• Las aplicaciones de agente existentes siguen sirviendo tráfico a través de sus puntos de conexión.
• Los agentes publicados en Microsoft 365/Teams a través de aplicaciones de agentes siguen funcionando.
• El punto de conexión del proyecto sigue estando disponible para la compatibilidad con versiones anteriores (aunque ya no es la ruta de acceso recomendada).
• Los agentes heredados siguen siendo totalmente funcionales para el desarrollo y las pruebas en el proyecto Foundry.

Rutas de migración

Ruta de acceso 1: Nuevos agentes (sin necesidad de acción)

Si crea agentes después de la actualización del modelo de objetos, obtienen automáticamente el nuevo modelo con una identidad única, un punto de conexión estable y todas las características nuevas. No se requiere ninguna migración.

Ruta 2: Actualización de un agente legado

Los agentes heredados (creados antes de la actualización) usan la identidad del proyecto compartido y no se pueden publicar a través del nuevo modelo. Para actualizar:

1. Compruebe si el agente es un agente heredado:

   GET {endpoint}/agents/{agent_name}?api-version=2025-11-15-preview
   Authorization: Bearer {{token}}
   Foundry-Features: AgentEndpoints=V1Preview
   

   Si instance_identity es null en la respuesta, es un agente heredado.

2. Cree un agente con la misma definición:

   Nota

   Actualmente no hay ninguna manera de actualizar un agente heredado a una identidad única. Para obtener una identidad única, cree un agente con la misma definición (instrucciones, herramientas, configuración del modelo). El nuevo agente recibe automáticamente una identidad única y un punto de conexión estable. Se planea una ruta de actualización local para una actualización futura.

3. Una vez creado el nuevo agente, tiene una identidad única y puede usar todas las funcionalidades nuevas, incluida la experiencia de publicación mejorada que utiliza el punto de conexión del agente.

Ruta de acceso 3: Migración de una aplicación de agente existente

Si tiene una aplicación de agente publicada en M365/Teams y quiere migrar al nuevo modelo, siga estos pasos:

1. Cree un nuevo agente con la misma definición que el agente detrás de la aplicación del agente (instrucciones, herramientas, configuración del modelo). El nuevo agente recibe automáticamente una identidad única y un punto de conexión estable. Consulte Ruta de acceso 2 para obtener más información.

2. Publicar el nuevo agente para Microsoft 365 y Teams desde el portal de Foundry. La publicación solo está disponible a través del portal de Foundry; no hay ninguna API de publicación pública. Para conocer los pasos, consulte Publicar agentes en Microsoft 365 Copilot y Microsoft Teams.

3. Compruebe que el nuevo agente funciona en M365/Teams con el nuevo punto de conexión estable.

4. Retire la aplicación del agente anterior después de confirmar que el nuevo agente funciona:

   • Elimine el recurso de Azure de la Aplicación de Agente. La eliminación del recurso no elimina las versiones del agente.
   • Para mantener las integraciones existentes funcionando, actualice cualquier código que haga referencia a la dirección URL del punto de conexión de aplicación anterior para usar la nueva dirección URL de punto de conexión estable del agente.

Cambios en la dirección URL del punto de conexión

Al migrar, actualice cualquier código o integraciones que hagan referencia al formato del punto de conexión anterior:

Publicación de la experiencia de usuario durante la transición

Durante la transición, es posible que vea experiencias de publicación diferentes en función del tipo de agente:

• Nuevos agentes (agent.identity != null): puede ver la nueva interfaz de usuario de publicación con selección de punto de conexión estable, enrutamiento de versiones y publicación directa en Microsoft 365/Teams.
• Agentes heredados (agent.identity == null): verá la experiencia de usuario heredada de publicación de aplicaciones del agente. Un banner puede indicar que la nueva experiencia está disponible con un vínculo para actualizar.

Cronograma y deprecación

Preguntas más frecuentes

¿Necesito migrar inmediatamente?

No. Las aplicaciones del agente existentes siguen funcionando. Sin embargo, las nuevas características (división de tráfico, varios protocolos, deshabilitar o habilitar, A2A) solo están disponibles en el nuevo modelo de agente.

¿Dejará de funcionar mi aplicación del agente?

No inmediatamente. Las aplicaciones de agente están en desuso con aviso previo y un período de migración. Siguen funcionando hasta la fecha de finalización del soporte técnico.

¿Puedo tener tanto una aplicación de agente como un agente de nuevo modelo para el mismo agente subyacente?

Durante la transición, sí. La aplicación del agente y el nuevo punto de conexión del agente pueden coexistir. Sin embargo, son recursos independientes con identidades y puntos de conexión independientes.

¿Qué ocurre con los roles de control de acceso basados en roles de Azure (RBAC) que asigné en los recursos de la Aplicación del Agente?

El control de acceso basado en roles (RBAC) aplicado a los recursos de la aplicación del agente no se transfiere al objeto del agente. Debe asignar roles (como Foundry Agent Consumer) en el recurso del agente para el nuevo punto de conexión.

Mi agente usa herramientas que se autentican con la identidad del agente. ¿Qué cambios?

Con el nuevo modelo, el agente tiene una identidad única a partir de la creación, por lo que no hay ningún cambio de identidad en el momento de la publicación. Sin embargo, si migra desde un agente heredado, el agente obtiene una nueva identidad que difiere de la identidad del proyecto compartido y de cualquier identidad de aplicación del agente. Debe reasignar RBAC para los recursos de nivel inferior.

Contenido relacionado

• Aplicaciones de Agentes en Microsoft Foundry
• Publica agentes en Microsoft 365 Copilot y Teams
• Conceptos de identidad del agente en Foundry