¿Qué es Semantic Kernel? SDK de Microsoft para orquestación de IA

Si desarrolla software en la pila de Microsoft y desea añadir IA sin acoplar un servicio de Python, Semantic Kernel es el SDK que Microsoft construyó para usted. Es un kit de código abierto que conecta su código y APIs existentes a grandes modelos de lenguaje, y funciona en C#, Python y Java. Esta guía explica qué es, cómo encajan el kernel y los complementos, y cómo su soporte para la especificación OpenAPI convierte cualquier API REST en algo que un modelo puede llamar.

Qué es realmente Semantic Kernel

Semantic Kernel (SK) es un kit de desarrollo ligero y de código abierto de Microsoft para construir agentes de IA e integrar modelos en su base de código. Microsoft lo describe como middleware: se interpone entre su aplicación y el modelo, traduce las solicitudes del modelo en llamadas de función reales, las ejecuta y devuelve los resultados. Usted escribe código normal. El modelo decide cuándo llamarlo.

Tres cosas hacen que SK se destaque de la multitud de librerías de agentes.

Primero, es verdaderamente multi-lenguaje. SK ofrece SDKs oficiales para C#/.NET, Python y Java, con compromisos de estabilidad de la versión 1.0+ en los tres. La mayoría de los frameworks de agentes son Python-first y tratan otros lenguajes como una ocurrencia tardía. Si su backend es .NET, SK es una de las pocas opciones maduras que se siente nativa.

Segundo, es agnóstico al modelo. SK se conecta a OpenAI, Azure OpenAI y otros proveedores a través de un conjunto de conectores. Cuando desea cambiar de modelo, modifica la configuración, no toda su aplicación.

Tercero, está construido pensando en las preocupaciones empresariales. La telemetría, los "hooks" y los filtros son de primera clase, por lo que puede registrar, auditar e interceptar lo que hace la IA. Ese enfoque es la razón por la que Microsoft y varios equipos de Fortune 500 lo adoptaron.

El kernel, los complementos y las funciones

El objeto central es el kernel. Piense en él como un contenedor de inyección de dependencias para la IA. Registra sus conectores de modelo y sus complementos en el kernel, luego le pide que ejecute cosas. El kernel se encarga de la orquestación: prompt, llamada al modelo, llamada a la función, resultado, repetir.

Un complemento (plugin) es un grupo con nombre de funciones que usted expone al modelo. Una función es una única capacidad que el modelo puede invocar. Las funciones vienen en dos tipos:

• Las funciones nativas son métodos regulares en su código (un método de C#, una función de Python) que usted anota para que el kernel pueda describírselas al modelo.
• Las funciones de prompt son prompts con plantilla que llaman al propio modelo, útiles para resumir, clasificar o reescribir texto.

Así es como se ve en C#. Usted construye un kernel, registra un modelo de chat, añade un complemento y deja que el modelo llame a las funciones cuando las necesite.

var builder = Kernel.CreateBuilder();
builder.AddOpenAIChatCompletion("gpt-4o", apiKey);
builder.Plugins.AddFromType<LightsPlugin>("Lights");
Kernel kernel = builder.Build();

// The model can now invoke LightsPlugin functions during a chat
var result = await kernel.InvokePromptAsync("Turn the kitchen light blue");

Cuando el modelo regresa y el kernel ve que quiere llamar a change_light_state, el kernel ejecuta su código, captura el resultado y lo devuelve al modelo. Ese bucle es el corazón de SK.

El patrón de OpenAPI a complemento

Esta es la característica más importante a conocer, y es el puente más limpio hacia sus servicios existentes. SK puede importar una especificación OpenAPI y convertir cada operación en una función invocable automáticamente. No escribe código de envoltura. Simplemente apunta SK a una especificación, y cada ruta/operación se convierte en una función que el modelo puede invocar.

En C# la llamada es ImportPluginFromOpenApiAsync. En Python es add_plugin_from_openapi. Java tiene un importador equivalente. Aquí está la versión de C# cargando una especificación desde una URL:

await kernel.ImportPluginFromOpenApiAsync(
    pluginName: "lights",
    uri: new Uri("https://example.com/v1/swagger.json"),
    executionParameters: new OpenApiFunctionExecutionParameters()
    {
        EnablePayloadNamespacing = true
    }
);

Internamente, SK analiza la especificación, extrae el nombre, la descripción, el tipo y el esquema de cada parámetro, y entrega esos metadatos al modelo. El modelo razona sobre qué operación llamar y qué argumentos pasar. SK luego construye la solicitud HTTP, aplica su callback de autenticación, la envía y lee la respuesta. SK soporta OpenAPI 2.0 y 3.0, y degrada las especificaciones 3.1 a 3.0 cuando es posible.

La cuestión es que las especificaciones escritas para humanos no siempre son claras para un modelo. La propia guía de Microsoft es añadir IDs de operación descriptivos, escribir descripciones de parámetros útiles, mantener bajo el número de endpoints y preferir enumeraciones y parámetros tipados sobre cadenas sueltas. La calidad de su especificación influye directamente en lo bien que el agente llama a su API. Eso hace que la especificación en sí sea algo que vale la pena diseñar y probar cuidadosamente, no una ocurrencia tardía.

Agentes y planificación

SK comenzó con planificadores explícitos que descomponían un objetivo en pasos. Desde entonces, el framework se ha orientado hacia la llamada de funciones, donde el propio modelo decide qué funciones invocar y en qué orden, lo cual es más fiable con los modelos modernos. Además, SK añadió una capa de Agent Framework para construir agentes y patrones multi-agente, con estado basado en sesiones, bucles de agente y soporte para el Protocolo de Contexto del Modelo (MCP) para conectar herramientas externas.

Si está comparando enfoques, así es como SK se compara con otros SDK de agentes cubiertos en este blog.

Ninguno de estos es estrictamente mejor. La elección correcta depende de su lenguaje, su proveedor de modelos y cuánto control explícito sobre la ejecución desee.

Dónde encaja Semantic Kernel con Microsoft Agent Framework

Esta parte avanza rápido, así que aquí está el estado honesto de las cosas. Microsoft introdujo el Microsoft Agent Framework (MAF), y la documentación lo describe como el sucesor directo tanto de Semantic Kernel como de AutoGen, construido por los mismos equipos. MAF combina las abstracciones de agente de AutoGen con las características empresariales de SK y añade flujos de trabajo basados en grafos para la orquestación multi-agente.

• Semantic Kernel es estable y aún cuenta con soporte. Las aplicaciones SK existentes siguen funcionando, y el compromiso de no introducir cambios drásticos a partir de la versión 1.0+ se mantiene.
• Para proyectos de agentes completamente nuevos, Microsoft le dirige hacia el Agent Framework y publica una guía de migración para trasladar el código SK.
• La idea de OpenAPI a complemento se mantiene. Dar acceso a un agente a sus APIs REST a través de una especificación es un patrón que ambos frameworks comparten.

Así que considere SK como una opción sólida y probada en producción que sigue siendo mantenida, mientras sabe que la inversión más reciente se está destinando a MAF. Si está decidiendo hoy y su código ya está en SK, no hay urgencia. Si está empezando de cero y quiere la última dirección, lea la documentación de MAF antes de comprometerse.

Cuándo usar Semantic Kernel

• Su pila es .NET o Java y desea una orquestación de IA que se sienta nativa en lugar de un "sidecar" de Python.
• Tiene un portfolio de APIs REST existentes y quiere que un modelo las llame a través de sus especificaciones OpenAPI.
• Necesita infraestructura empresarial: telemetría, filtros, "hooks" y la capacidad de auditar lo que hizo la IA.
• Quiere seguir siendo agnóstico al modelo y cambiar de proveedores sin reescribir su aplicación.

Busque otras opciones cuando su equipo sea solo de Python y desee las características multi-agente más nuevas, en cuyo caso MAF o una librería orientada a grafos podría ser más adecuada para usted.

Probando las APIs detrás de su agente Semantic Kernel

Aquí es donde las herramientas de API importan, y donde Apidog encaja perfectamente. SK no construye ni reemplaza sus APIs. Las llama. Un agente SK depende de dos tipos de endpoints: el endpoint LLM con el que se comunica, y las APIs REST que usted importa como complementos OpenAPI. Ambas necesitan ser correctas, bien descritas y fiables, o el agente hará llamadas incorrectas.

Algunas tareas prácticas:

• Diseñe y pruebe la especificación OpenAPI antes de importarla. Dado que SK convierte cada operación en una función y alimenta al modelo con sus descripciones de parámetros, una especificación descuidada produce llamadas de herramienta descuidadas. Valide la especificación, ejercite cada endpoint y confirme que las respuestas coinciden con el esquema. Contrato limpio, mejor agente.
• Simule las dependencias durante el desarrollo. Puede configurar una API simulada para un endpoint que aún no está construido, o simular el endpoint LLM para evitar gastar tokens y alcanzar límites de tasa mientras depura el bucle de orquestación. Consulte cómo simular llamadas a la API para ver el patrón.
• Asegure las formas de respuesta. Use aserciones de API para verificar que los endpoints de la herramienta que su agente llama devuelven exactamente la estructura que el modelo espera, de modo que un cambio en el backend no rompa silenciosamente el comportamiento del agente.
• Gestione las claves por entorno. Mantenga sus credenciales de LLM y API separadas entre los entornos de desarrollo, staging y producción en lugar de codificarlas directamente.

Este es un trabajo de API ordinario, realizado antes y alrededor del agente, no en su lugar. Si desea una explicación más detallada, probar las llamadas a herramientas de un agente con Apidog cubre el arnés en detalle.

Preguntas frecuentes

¿Es Semantic Kernel gratuito y de código abierto?

Sí. Semantic Kernel es de código abierto y publicado por Microsoft en GitHub bajo una licencia permisiva, con SDKs para C#/.NET, Python y Java. Usted paga por el uso del modelo (OpenAI, Azure OpenAI, etc.), no por SK en sí.

¿Qué lenguajes soporta Semantic Kernel?

C#/.NET, Python y Java, todos con compromisos de estabilidad a partir de la versión 1.0+. El SDK de C# es el más maduro, pero los SDKs de Python y Java cubren las características principales del kernel, los complementos y la importación de OpenAPI.

¿Cómo utiliza Semantic Kernel las especificaciones OpenAPI?

Usted importa una especificación con ImportPluginFromOpenApiAsync (C#) o add_plugin_from_openapi (Python). SK analiza la especificación, convierte cada operación en una función invocable con sus metadatos de parámetros, y permite que el modelo invoque esas operaciones. Dado que el modelo se basa en sus descripciones, conviene validar la especificación primero. Puede hacer esto, y probar los endpoints en vivo, con Apidog.

¿Debo usar Semantic Kernel o el Microsoft Agent Framework?

Si ya tiene una aplicación SK, siga usándola; tiene soporte y es estable. Para nuevos proyectos, Microsoft posiciona el Agent Framework como el sucesor y proporciona una guía de migración. Consulte la documentación actual de MAF antes de empezar de cero, ya que esta área está cambiando rápidamente. Para probar las APIs que cualquiera de los dos llama, consulte cómo probar la API de ChatGPT con Apidog.

Conclusión

Semantic Kernel ofrece a los equipos de la pila de Microsoft una forma limpia de orquestar la IA: un kernel que conecta modelos a su código, complementos y funciones que el modelo puede llamar, y una ruta de importación OpenAPI que expone sus APIs REST existentes como herramientas de agente. Es estable y probado en producción, con el Agent Framework ahora llevando la dirección más reciente hacia adelante. Cualquiera que elija, las APIs subyacentes aún deben ser sólidas. Para diseñar, simular y probar las especificaciones y los endpoints de los que depende su agente, descargue Apidog y construya el contrato antes de que el agente lo llame.