Agentes empresariales con MCP: qué revisar antes de actualizar Microsoft Agent Framework

Agent Framework: actualizar con control

Actualizar un framework de agentes puede cambiar cómo se conserva una conversación, qué identidad llega a una herramienta y cómo se reanuda una operación aprobada. Las versiones .NET 1.22.0 y Python 1.19.0 de Microsoft Agent Framework, publicadas el 18 de septiembre de 2026, merecen una evaluación explícita de estos comportamientos.

Cambios relevantes en .NET 1.22.0

El release, publicado por Wes Steyn, identifica cambios incompatibles en la reproducción de aprobaciones, el alcance de sesiones MCP por invocación y la persistencia de identidad delegada de Foundry en AgentSession. También traslada AgentSessionStore a las abstracciones e incorpora mejoras de telemetría y preservación de middleware con herramientas dinámicas. Notas oficiales de .NET 1.22.0.

Cambios relevantes en Python 1.19.0

El release, publicado por Evan Mattson, hace explícita la persistencia de cookies HTTP, restringe los archivos de skills MCP a ZIP, depreca el callback de sampling MCP y cambia el alcance de claves del historial Redis. Además documenta verificaciones de integridad de skills y correcciones de identidad, sesiones y reanudación. Los cambios afectan paquetes distintos: debe revisarse el conjunto realmente instalado. Notas oficiales de Python 1.19.0.

Una matriz de regresión antes del despliegue

La siguiente matriz es una propuesta editorial de aceptación, no un resultado de pruebas de Microsoft ni una validación ejecutada por Enoiax.

Área Prueba Criterio esperado
Identidad Dos usuarios consultan recursos con permisos diferentes. Cada respuesta respeta los permisos del usuario efectivo.
MCP Ejecutar solicitudes concurrentes y cancelar una de ellas. No se comparten resultados ni estado entre invocaciones.
Aprobaciones Aprobar, rechazar y reanudar después de reiniciar. La decisión corresponde a la solicitud original y no duplica acciones.
Persistencia Restaurar conversaciones y checkpoints anteriores. La compatibilidad está demostrada o existe una migración controlada.
Observabilidad Inspeccionar trazas, errores y consumo. Los fallos son diagnosticables sin exponer datos sensibles.

Preparación y reversión

  1. Inventariar paquetes, adaptadores MCP, almacenes de sesiones y proveedor del modelo.
  2. Crear una rama aislada y fijar las versiones de todas las dependencias afectadas.
  3. Guardar una línea base con casos sintéticos, respuestas esperadas y métricas.
  4. Compilar o validar importaciones y ejecutar la matriz sobre un ambiente de prueba.
  5. Probar una reversión que incluya datos persistidos, no solamente binarios.
  6. Desplegar gradualmente tras aprobar los criterios de aceptación.

No conviene asumir que un historial escrito con un esquema nuevo podrá leerse al volver a una versión anterior. Esta compatibilidad debe comprobarse antes de habilitar sesiones reales.

Seguridad, licencias y mantenimiento

El framework se distribuye bajo licencia MIT; el consumo de modelos y los servicios conectados mantienen sus condiciones propias. Revise asimismo las licencias de las dependencias distribuidas con la solución.

La identidad delegada no sustituye los permisos del sistema destino. Las pruebas deben verificar autorización en cada herramienta, filtrado de trazas y tratamiento de documentos no confiables. Las credenciales del piloto deben tener el alcance mínimo necesario.

Esta guía complementa el artículo de Enoiax sobre almacenes vectoriales para RAG: aquí el foco es la compatibilidad operativa de una actualización.

Recomendación: probar la actualización en una rama aislada y adoptarla cuando identidad, persistencia, aprobaciones y reversión tengan evidencia. Las notas de versión aportan cambios verificables, pero no sustituyen una prueba sobre la arquitectura concreta.

Scroll al inicio