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

Si desarrolla software en la pila de Microsoft y quiere añadir IA sin acoplar un servicio de Python, Semantic Kernel es una opción práctica: un SDK open source de Microsoft que conecta su código y APIs existentes con modelos de lenguaje. Funciona en C#, Python y Java, y permite convertir una especificación OpenAPI en funciones que un modelo puede llamar.

Prueba Apidog hoy

Qué es realmente Semantic Kernel

Semantic Kernel (SK) es un SDK ligero y open source de Microsoft para integrar modelos de IA en aplicaciones existentes. Funciona como middleware entre su aplicación y el modelo:

1. Usted registra modelos, funciones y APIs en el kernel.
2. El modelo recibe descripciones de esas capacidades.
3. El modelo decide cuándo llamar una función.
4. SK ejecuta la función real y devuelve el resultado al modelo.

En la práctica, usted escribe código normal y expone partes de ese código como herramientas invocables por IA.

SK destaca por tres razones:

• Soporte multi-lenguaje: SDKs oficiales para C#/.NET, Python y Java, con compromisos de estabilidad 1.0+.
• Agnosticismo de modelo: puede conectarse a OpenAI, Azure OpenAI y otros proveedores mediante conectores.
• Enfoque empresarial: incluye telemetría, filtros, hooks e interceptores para auditar y controlar lo que hace el agente.

Si su backend principal está en .NET o Java, SK evita tener que mover la lógica de IA a un servicio Python separado.

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 IA. En él registra:

• conectores de modelo;
• complementos;
• funciones nativas;
• funciones basadas en prompts;
• configuración de ejecución.

Un complemento o plugin es un grupo de funciones con nombre. Una función es una capacidad concreta que el modelo puede invocar.

SK trabaja principalmente con dos tipos de funciones:

• Funciones nativas: métodos reales en su código, por ejemplo un método de C# o una función de Python.
• Funciones de prompt: plantillas de prompt útiles para tareas como resumir, clasificar o reescribir texto.

Ejemplo básico en C#:

var builder = Kernel.CreateBuilder();

builder.AddOpenAIChatCompletion(
    modelId: "gpt-4o",
    apiKey: apiKey
);

builder.Plugins.AddFromType<LightsPlugin>("Lights");

Kernel kernel = builder.Build();

var result = await kernel.InvokePromptAsync(
    "Turn the kitchen light blue"
);

Un plugin nativo podría verse así:

using Microsoft.SemanticKernel;
using System.ComponentModel;

public class LightsPlugin
{
    [KernelFunction("change_light_state")]
    [Description("Changes the state and color of a light")]
    public string ChangeLightState(
        [Description("The room where the light is located")] string room,
        [Description("The target color for the light")] string color
    )
    {
        // Aquí iría la llamada real a su sistema de luces
        return $"The {room} light is now {color}.";
    }
}

Cuando el modelo determina que necesita llamar change_light_state, SK ejecuta su método, captura el resultado y lo devuelve al modelo para continuar la conversación.

Ese bucle —modelo, llamada de función, resultado, nueva decisión— es el núcleo de Semantic Kernel.

El patrón de OpenAPI a complemento

La característica más útil para equipos con APIs existentes es la importación de OpenAPI.

SK puede leer una especificación OpenAPI y convertir sus operaciones en funciones invocables por el modelo. Esto evita escribir wrappers manuales para cada endpoint.

En C#, la llamada es ImportPluginFromOpenApiAsync:

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

En Python, el patrón equivalente usa add_plugin_from_openapi.

El flujo es:

1. SK descarga o lee la especificación OpenAPI.
2. Extrae operaciones, parámetros, tipos y descripciones.
3. Convierte cada operación en una función disponible para el modelo.
4. El modelo decide qué operación llamar y con qué argumentos.
5. SK construye la solicitud HTTP.
6. SK aplica autenticación si usted la configura.
7. SK envía la solicitud y devuelve la respuesta al modelo.

SK soporta OpenAPI 2.0 y 3.0, y puede degradar especificaciones 3.1 a 3.0 cuando es posible.

Cómo preparar una especificación OpenAPI para Semantic Kernel

Una especificación escrita solo para humanos puede no ser suficiente para un modelo. Para mejorar las llamadas de herramienta:

• Use operationId claros y descriptivos.
• Escriba descripciones útiles para parámetros y cuerpos de solicitud.
• Evite nombres genéricos como data, payload o value.
• Use enums cuando el conjunto de valores sea cerrado.
• Defina tipos estrictos en lugar de cadenas libres.
• Mantenga bajo el número de endpoints expuestos al agente.
• No exponga operaciones peligrosas si el modelo no debe ejecutarlas directamente.

Ejemplo de operación más fácil de interpretar por un modelo:

paths:
  /lights/{room}/state:
    patch:
      operationId: changeLightState
      summary: Change the color and power state of a room light
      parameters:
        - name: room
          in: path
          required: true
          schema:
            type: string
          description: Room where the light is installed, such as kitchen or bedroom
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required:
                - color
                - isOn
              properties:
                color:
                  type: string
                  enum: [red, blue, green, white, yellow]
                  description: Target light color
                isOn:
                  type: boolean
                  description: Whether the light should be turned on
      responses:
        "200":
          description: Light state updated successfully

La calidad de la especificación afecta directamente la calidad del agente.

Agentes y planificación

Semantic Kernel comenzó con planificadores explícitos que descomponían un objetivo en pasos. Con los modelos modernos, el enfoque principal pasó a ser la llamada de funciones, donde el modelo decide qué funciones invocar y en qué orden.

SK también añadió una capa de Agent Framework para construir agentes y patrones multi-agente, con:

• estado basado en sesiones;
• bucles de agente;
• soporte para herramientas externas;
• integración con el Protocolo de Contexto del Modelo (MCP).

Si está comparando frameworks, esta es una vista práctica:

Framework	Lenguajes principales	Modelo de orquestación	Mejor ajuste
Semantic Kernel	C#/.NET, Python, Java	Llamada de función + agentes	Equipos .NET y empresariales
LangGraph	Python, JS	Grafo de estado explícito	Flujos de agente complejos y ramificados
Google ADK	Python	Modelo de agente + herramienta	Pilas de Google Cloud y Gemini
OpenAI Agents SDK	Python, JS	Agentes + traspasos	Aplicaciones centradas en OpenAI

Ninguno es universalmente mejor. Elija según:

• lenguaje principal de su backend;
• proveedor de modelo;
• necesidad de control explícito;
• complejidad del flujo de agente;
• requisitos de observabilidad y auditoría.

Dónde encaja Semantic Kernel con Microsoft Agent Framework

Microsoft introdujo Microsoft Agent Framework (MAF), descrito en su documentación como sucesor directo de Semantic Kernel y AutoGen. MAF combina abstracciones de agente de AutoGen con características empresariales de SK y añade flujos de trabajo basados en grafos para orquestación multi-agente.

Estado práctico:

• Semantic Kernel sigue siendo estable y soportado. Las aplicaciones existentes continúan funcionando.
• Los compromisos de estabilidad 1.0+ se mantienen.
• Para proyectos nuevos de agentes, Microsoft dirige la atención hacia Agent Framework.
• El patrón OpenAPI a herramienta sigue siendo relevante en ambos enfoques.

Recomendación:

• Si ya tiene una aplicación en SK, no hay urgencia por migrar.
• Si empieza un proyecto nuevo desde cero, revise primero la documentación actual de MAF.
• Si su prioridad inmediata es conectar APIs REST existentes a un modelo desde .NET, SK sigue siendo una opción sólida.

Cuándo usar Semantic Kernel

Use Semantic Kernel cuando:

• su pila principal sea .NET o Java;
• quiera evitar un servicio Python adicional solo para IA;
• tenga APIs REST existentes con especificaciones OpenAPI;
• necesite telemetría, filtros, hooks y auditoría;
• quiera cambiar de proveedor de modelo sin reescribir la aplicación;
• quiera exponer funciones internas como herramientas para un modelo.

Considere otras opciones cuando:

• su equipo trabaje exclusivamente en Python;
• necesite patrones multi-agente más nuevos;
• quiera modelar flujos como grafos explícitos;
• esté empezando desde cero y prefiera alinearse con la dirección más reciente de Microsoft.

Implementación mínima: Semantic Kernel + OpenAPI

Un flujo inicial razonable para probar SK con una API existente sería:

1. Crear o validar su especificación OpenAPI.
2. Registrar el modelo de chat.
3. Importar la especificación como plugin.
4. Activar llamadas automáticas de función.
5. Ejecutar un prompt de prueba.
6. Revisar qué endpoint llamó el modelo y con qué argumentos.

Ejemplo simplificado en C#:

using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Connectors.OpenAI;
using Microsoft.SemanticKernel.Plugins.OpenApi;

var builder = Kernel.CreateBuilder();

builder.AddOpenAIChatCompletion(
    modelId: "gpt-4o",
    apiKey: Environment.GetEnvironmentVariable("OPENAI_API_KEY")!
);

Kernel kernel = builder.Build();

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

var settings = new OpenAIPromptExecutionSettings
{
    ToolCallBehavior = ToolCallBehavior.AutoInvokeKernelFunctions
};

var response = await kernel.InvokePromptAsync(
    "Busca el estado del pedido 12345",
    new KernelArguments(settings)
);

Console.WriteLine(response);

En producción, añada:

• autenticación para las llamadas HTTP;
• logging de tool calls;
• validación de entradas;
• límites sobre operaciones sensibles;
• pruebas contractuales para los endpoints;
• separación de credenciales por entorno.

Probando las APIs detrás de su agente Semantic Kernel

Aquí es donde las herramientas de API importan. Apidog encaja en el flujo porque SK no reemplaza sus APIs: las llama.

Un agente SK depende de dos tipos de endpoints:

• el endpoint LLM;
• las APIs REST importadas como complementos OpenAPI.

Si esas APIs están mal documentadas, cambian sin control o devuelven respuestas inesperadas, el agente hará llamadas incorrectas.

Checklist práctico antes de importar una API en SK

1. Valide la especificación OpenAPI

Confirme que la especificación tiene tipos correctos, parámetros requeridos, respuestas esperadas y operationId claros.

1. Ejecute cada endpoint manualmente

No importe una especificación que no haya probado. Ejecute los endpoints reales y revise códigos de estado, headers y cuerpos de respuesta.

1. Use mocks durante el desarrollo

Puede configurar una API simulada para endpoints que aún no existen, o simular dependencias mientras depura la orquestación. El patrón se explica en cómo simular llamadas a la API.

1. Asegure las formas de respuesta

Use aserciones de API para verificar que el backend devuelve la estructura que el agente espera.

1. Gestione credenciales por entorno

Mantenga claves de LLM y APIs separadas para desarrollo, staging y producción. No las codifique en el repositorio.

1. Pruebe cambios antes de desplegar

Si cambia una respuesta o renombra un campo, el agente puede seguir ejecutando la llamada pero interpretar mal el resultado.

Si quiere una guía más detallada, probar las llamadas a herramientas de un agente con Apidog cubre el arnés de pruebas.

Preguntas frecuentes

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

Sí. Semantic Kernel es open source y Microsoft lo publica en GitHub bajo una licencia permisiva. Usted paga por el uso del modelo, como OpenAI o Azure OpenAI, no por SK en sí.

¿Qué lenguajes soporta Semantic Kernel?

Soporta C#/.NET, Python y Java. Los tres tienen compromisos de estabilidad desde la versión 1.0+. El SDK de C# es el más maduro, pero Python y Java cubren las características principales de kernel, plugins e importación de OpenAPI.

¿Cómo utiliza Semantic Kernel las especificaciones OpenAPI?

Usted importa una especificación con ImportPluginFromOpenApiAsync en C# o add_plugin_from_openapi en Python. SK analiza la especificación, convierte cada operación en una función invocable y entrega al modelo los metadatos de parámetros y descripciones.

Como el modelo depende de esas descripciones, conviene validar la especificación antes. Puede hacerlo y probar los endpoints en vivo con Apidog.

¿Debo usar Semantic Kernel o Microsoft Agent Framework?

Si ya tiene una aplicación SK, siga usándola: es estable y cuenta con soporte. Para proyectos nuevos, Microsoft posiciona Agent Framework como sucesor y proporciona una guía de migración. Revise la documentación actual de MAF antes de empezar desde cero.

Para probar las APIs que cualquiera de los dos llama, consulte cómo probar la API de ChatGPT con Apidog.

Conclusión

Semantic Kernel permite a equipos .NET, Java y Python conectar modelos de IA con código existente, funciones nativas y APIs REST. Su importación de OpenAPI es especialmente útil: convierte endpoints existentes en herramientas que el modelo puede invocar.

La parte crítica no es solo registrar la API en SK. Es diseñar, validar y probar bien el contrato antes de exponerlo al agente. Para diseñar, simular y probar las especificaciones y endpoints de los que depende su agente, descargue Apidog y construya el contrato antes de que el modelo lo llame.