Semantic-Kernel | The .NET Blog

Las Agent Skills en .NET se volvieron muy flexibles

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

Este artículo fue traducido automáticamente. Para la versión original, haz clic aquí.

Si has estado construyendo agentes con el Microsoft Agent Framework, ya conoces la dinámica: defines skills, las conectas a un provider y dejas que el agente decida cuál invocar. Lo nuevo es cómo creas esas skills — y el salto en flexibilidad es importante.

La última actualización introduce tres patrones de autoría para agent skills: basadas en archivos, basadas en clases y definidas en código inline. Las tres se conectan a un único AgentSkillsProviderBuilder, lo que significa que puedes mezclar y combinar sin lógica de enrutamiento ni código especial. Te explico cada una y cuándo usarla.

Skills basadas en archivos: el punto de partida

Las skills basadas en archivos son exactamente lo que suenan — un directorio en disco con un archivo SKILL.md, scripts opcionales y documentos de referencia. Es la forma más directa de darle nuevas capacidades a tu agente:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

El frontmatter del SKILL.md declara el nombre y descripción, y la sección de instrucciones le dice al agente cómo usar los scripts y referencias:

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

Luego lo conectas con SubprocessScriptRunner.RunAsync para la ejecución de scripts:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

El agente descubre la skill automáticamente e invoca el script de provisión cuando necesita verificar el estado de las cuentas. Limpio y simple.

Skills basadas en clases: distribuir vía NuGet

Aquí es donde se pone interesante para los equipos. Las skills basadas en clases derivan de AgentClassSkill<T> y usan atributos como [AgentSkillResource] y [AgentSkillScript] para que el framework descubra todo por reflexión:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

Lo mejor es que un equipo puede empaquetar esto como un paquete NuGet. Lo agregas a tu proyecto, lo metes en el builder y funciona junto a tus skills basadas en archivos sin coordinación:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Ambas skills aparecen en el system prompt del agente. El agente decide cuál usar según la conversación — sin código de enrutamiento.

Skills inline: el puente rápido

¿Conoces ese momento cuando otro equipo está construyendo exactamente la skill que necesitas, pero no la tendrán lista hasta el próximo sprint? AgentInlineSkill es tu puente:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

Agrégala al builder igual que las demás:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Cuando el paquete NuGet finalmente salga, intercambias la skill inline por la basada en clases. El agente no nota la diferencia.

Pero las skills inline no son solo para puentes. También son la opción correcta cuando necesitas generar skills dinámicamente en runtime — piensa en una skill por unidad de negocio cargada desde configuración — o cuando un script necesita capturar estado local que no pertenece a un contenedor DI.

Aprobación de scripts: humano en el bucle

Para los que construimos agentes de producción en .NET, esta es la parte que realmente desbloquea las conversaciones de despliegue. Algunos scripts tienen consecuencias reales — inscribir a alguien en beneficios, consultar infraestructura de producción. Activa UseScriptApproval y el agente se pausa antes de ejecutar cualquier script:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

Cuando el agente quiere ejecutar un script, devuelve una solicitud de aprobación. Tu app recoge la decisión — aprobar o rechazar — y el agente continúa. En entornos regulados, esta es la diferencia entre “podemos desplegar esto” y “legal dice que no.”

Por qué esta combinación importa

El verdadero poder no está en ningún patrón individual — está en la composición. Puedes:

Empezar pequeño con una skill basada en archivos, iterar en las instrucciones y publicarla sin escribir C#
Distribuir skills reutilizables como paquetes NuGet que otros equipos pueden agregar con una línea
Cubrir huecos con skills inline cuando necesitas algo ya
Filtrar directorios compartidos con predicados para que tu agente solo cargue lo que debe
Agregar supervisión humana para scripts que tocan sistemas de producción

Todo esto se compone a través de AgentSkillsProviderBuilder. Sin enrutamiento especial, sin lógica condicional, sin verificaciones de tipo de skill.

Para cerrar

Las agent skills en .NET ahora tienen un modelo de autoría genuinamente flexible. Ya sea que seas un desarrollador solo prototipando con skills basadas en archivos o un equipo enterprise distribuyendo capacidades empaquetadas vía NuGet, los patrones encajan. Y el mecanismo de aprobación de scripts lo hace listo para producción en entornos donde necesitas ese checkpoint humano.

Echa un vistazo al anuncio original, la documentación de Agent Skills en Microsoft Learn y los ejemplos en .NET en GitHub para ponerte manos a la obra.

Microsoft Agent Framework Llega a 1.0 — Esto Es Lo Que Realmente Importa para Desarrolladores .NET

Emiliano Montesdeoca — Fri, 03 Apr 2026 00:00:00 +0000

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Si has estado siguiendo el camino de Agent Framework desde los primeros días de Semantic Kernel y AutoGen, esto es importante. Microsoft Agent Framework acaba de llegar a la versión 1.0 — listo para producción, APIs estables, compromiso de soporte a largo plazo. Está disponible tanto para .NET como para Python, y está genuinamente preparado para cargas de trabajo reales.

Voy a cortar el ruido del anuncio y centrarme en lo que importa si estás construyendo apps con IA usando .NET.

La versión corta

Agent Framework 1.0 unifica lo que solían ser Semantic Kernel y AutoGen en un único SDK de código abierto. Una abstracción de agente. Un motor de orquestación. Múltiples proveedores de IA. Si has estado saltando entre Semantic Kernel para patrones empresariales y AutoGen para flujos de trabajo multi-agente de nivel investigación, puedes parar. Este es el único SDK ahora.

Empezar es casi injustamente simple

Aquí tienes un agente funcional en .NET:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

Eso es todo. Un puñado de líneas y tienes un agente de IA ejecutándose contra Azure Foundry. El equivalente en Python es igual de conciso. Añade herramientas de funciones, conversaciones multi-turno y streaming a medida que avanzas — la superficie de la API escala sin volverse rara.

Orquestación multi-agente — esto va en serio

Los agentes individuales están bien para demos, pero los escenarios de producción generalmente necesitan coordinación. Agent Framework 1.0 viene con patrones de orquestación probados en batalla directamente de Microsoft Research y AutoGen:

Secuencial — los agentes procesan en orden (escritor → revisor → editor)
Concurrente — distribuye a múltiples agentes en paralelo, converge resultados
Handoff — un agente delega a otro basándose en la intención
Chat grupal — múltiples agentes discuten y convergen en una solución
Magentic-One — el patrón multi-agente de nivel investigación de MSR

Todos soportan streaming, checkpointing, aprobaciones con humano en el bucle, y pausa/reanudación. La parte de checkpointing es crucial — los flujos de trabajo de larga duración sobreviven a reinicios de proceso. Para nosotros los desarrolladores .NET que hemos construido flujos de trabajo durables con Azure Functions, esto se siente familiar.

Las funcionalidades que más importan

Aquí va mi lista de lo que vale la pena saber:

Hooks de middleware. ¿Sabes cómo ASP.NET Core tiene pipelines de middleware? Mismo concepto, pero para la ejecución de agentes. Intercepta cada etapa — añade seguridad de contenido, logging, políticas de cumplimiento — sin tocar los prompts del agente. Así es como haces que los agentes estén listos para empresa.

Memoria conectable. Historial conversacional, estado persistente clave-valor, recuperación basada en vectores. Elige tu backend: Foundry Agent Service, Mem0, Redis, Neo4j, o crea el tuyo propio. La memoria es lo que convierte una llamada LLM sin estado en un agente que realmente recuerda el contexto.

Agentes declarativos en YAML. Define las instrucciones de tu agente, herramientas, memoria y topología de orquestación en archivos YAML versionados. Carga y ejecuta con una sola llamada a la API. Esto es un cambio radical para equipos que quieren iterar en el comportamiento del agente sin redesplegar código.

Soporte A2A y MCP. MCP (Model Context Protocol) permite a los agentes descubrir e invocar herramientas externas dinámicamente. A2A (protocolo Agent-to-Agent) habilita la colaboración entre runtimes — tus agentes .NET pueden coordinarse con agentes ejecutándose en otros frameworks. El soporte para A2A 1.0 llegará pronto.

Las funcionalidades en preview que vale la pena seguir

Algunas funcionalidades se lanzaron como preview en 1.0 — funcionales pero las APIs pueden evolucionar:

DevUI — un depurador local basado en navegador para visualizar la ejecución del agente, flujos de mensajes y llamadas a herramientas en tiempo real. Piensa en Application Insights, pero para el razonamiento del agente.
GitHub Copilot SDK y Claude Code SDK — usa Copilot o Claude como un harness de agente directamente desde tu código de orquestación. Compón un agente capaz de programar junto a tus otros agentes en el mismo flujo de trabajo.
Agent Harness — un runtime local personalizable que da a los agentes acceso a shell, sistema de archivos y bucles de mensajería. Piensa en agentes de programación y patrones de automatización.
Skills — paquetes reutilizables de capacidades de dominio que dan a los agentes capacidades estructuradas listas para usar.

Migrando desde Semantic Kernel o AutoGen

Si tienes código existente de Semantic Kernel o AutoGen, hay asistentes de migración dedicados que analizan tu código y generan planes de migración paso a paso. La guía de migración de Semantic Kernel y la guía de migración de AutoGen te guían a través de todo.

Si has estado en los paquetes RC, actualizar a 1.0 es solo un cambio de versión.

Para cerrar

Agent Framework 1.0 es el hito de producción que los equipos empresariales han estado esperando. APIs estables, soporte multi-proveedor, patrones de orquestación que realmente funcionan a escala, y rutas de migración desde tanto Semantic Kernel como AutoGen.

El framework es completamente open source en GitHub, y puedes empezar hoy con dotnet add package Microsoft.Agents.AI. Echa un vistazo a la guía de inicio rápido y los ejemplos para ponerte manos a la obra.

Si has estado esperando la señal de “seguro para usar en producción” — esta es.