Semantic-Kernel | The .NET Blog

Les Agent Skills en .NET deviennent vraiment flexibles

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

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Si vous construisez des agents avec le Microsoft Agent Framework, vous connaissez le principe : vous définissez des skills, vous les connectez à un provider et vous laissez l’agent décider lequel invoquer. Ce qui est nouveau, c’est comment vous créez ces skills — et le gain en flexibilité est significatif.

La dernière mise à jour introduit trois patterns d’authoring pour les agent skills : basées sur des fichiers, basées sur des classes et définies en code inline. Les trois se branchent sur un seul AgentSkillsProviderBuilder, ce qui veut dire que vous pouvez les mixer sans logique de routage ni code spécial. Je vous présente chacune et quand l’utiliser.

Skills basées sur des fichiers : le point de départ

Les skills basées sur des fichiers sont exactement ce que leur nom suggère — un répertoire sur disque avec un fichier SKILL.md, des scripts optionnels et des documents de référence. La façon la plus directe de donner de nouvelles capacités à votre agent :

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

Le frontmatter du SKILL.md déclare le nom et la description, et la section d’instructions dit à l’agent comment utiliser les scripts et les références :

---
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.

Ensuite vous le connectez avec SubprocessScriptRunner.RunAsync pour l’exécution des 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);

L’agent découvre la skill automatiquement et invoque le script de provisioning quand il doit vérifier le statut des comptes. Propre et simple.

Skills basées sur des classes : distribuer via NuGet

C’est là que ça devient intéressant pour les équipes. Les skills basées sur des classes dérivent de AgentClassSkill<T> et utilisent des attributs comme [AgentSkillResource] et [AgentSkillScript] pour que le framework découvre tout par réflexion :

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 });
 }
}

Le beau ici, c’est qu’une équipe peut packager ça en paquet NuGet. Vous l’ajoutez à votre projet, vous le mettez dans le builder, et ça fonctionne à côté de vos skills fichier sans coordination :

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

Les deux skills apparaissent dans le system prompt de l’agent. L’agent décide laquelle utiliser en fonction de la conversation — pas de code de routage nécessaire.

Skills inline : le pont rapide

Vous connaissez ce moment où une autre équipe construit exactement la skill dont vous avez besoin, mais elle ne sera pas prête avant le prochain sprint ? AgentInlineSkill est votre pont :

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 });
 });

Ajoutez-la au builder comme les autres :

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

Quand le paquet NuGet sort enfin, vous échangez la skill inline contre la version classe. L’agent ne voit pas la différence.

Les skills inline ne sont pas que pour les ponts. Elles sont aussi le bon choix quand vous devez générer des skills dynamiquement à l’exécution — pensez à une skill par unité métier chargée depuis la config — ou quand un script doit capturer un état local qui n’a pas sa place dans un conteneur DI.

Approbation de scripts : l’humain dans la boucle

Pour nous développeurs .NET qui construisons des agents de production, c’est la partie qui débloque vraiment les discussions de déploiement. Certains scripts ont des conséquences réelles — inscrire quelqu’un à des avantages, interroger l’infrastructure de production. Activez UseScriptApproval et l’agent se met en pause avant d’exécuter tout script :

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

Quand l’agent veut exécuter un script, il retourne une demande d’approbation à la place. Votre app collecte la décision — approuver ou rejeter — et l’agent continue en conséquence. Dans les environnements réglementés, c’est la différence entre “on peut déployer ça” et “le juridique dit non.”

Pourquoi cette combinaison compte

Le vrai pouvoir n’est pas dans un pattern individuel — c’est dans la composition. Vous pouvez :

Commencer petit avec une skill fichier, itérer sur les instructions et la publier sans écrire de C#
Distribuer des skills réutilisables comme paquets NuGet que d’autres équipes ajoutent en une ligne
Combler les lacunes avec des skills inline quand vous avez besoin de quelque chose maintenant
Filtrer les répertoires partagés avec des prédicats pour que votre agent ne charge que ce qu’il doit
Ajouter une supervision humaine pour les scripts qui touchent les systèmes de production

Tout cela se compose via AgentSkillsProviderBuilder. Pas de routage spécial, pas de logique conditionnelle, pas de vérifications de type de skill.

Pour conclure

Les agent skills en .NET ont maintenant un modèle d’authoring véritablement flexible. Que vous soyez un développeur solo qui prototype avec des skills fichier ou une équipe enterprise qui distribue des capacités packagées via NuGet, les patterns s’adaptent. Et le mécanisme d’approbation de scripts le rend prêt pour la production dans les environnements où vous avez besoin de ce checkpoint humain.

Consultez l’annonce originale, la documentation Agent Skills sur Microsoft Learn et les exemples .NET sur GitHub pour vous lancer.

Microsoft Agent Framework Atteint la 1.0 — Voici Ce Qui Compte Vraiment pour les Développeurs .NET

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

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Si vous avez suivi le parcours d’Agent Framework depuis les premiers jours de Semantic Kernel et AutoGen, celui-ci est significatif. Microsoft Agent Framework vient d’atteindre la version 1.0 — prêt pour la production, APIs stables, engagement de support à long terme. Il est disponible pour .NET et Python, et il est véritablement prêt pour les charges de travail réelles.

Laissez-moi couper à travers le bruit de l’annonce et me concentrer sur ce qui compte si vous construisez des applications alimentées par l’IA avec .NET.

La version courte

Agent Framework 1.0 unifie ce qui était auparavant Semantic Kernel et AutoGen en un seul SDK open source. Une abstraction d’agent. Un moteur d’orchestration. Plusieurs fournisseurs d’IA. Si vous avez jonglé entre Semantic Kernel pour les patterns entreprise et AutoGen pour les workflows multi-agent de niveau recherche, vous pouvez arrêter. C’est le seul SDK maintenant.

Démarrer est presque injustement simple

Voici un agent fonctionnel 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."));

C’est tout. Une poignée de lignes et vous avez un agent IA qui tourne contre Azure Foundry. L’équivalent Python est tout aussi concis. Ajoutez des outils de fonctions, des conversations multi-tours et du streaming au fur et à mesure — la surface de l’API monte en puissance sans devenir bizarre.

Orchestration multi-agent — c’est du sérieux

Les agents individuels sont bien pour les démos, mais les scénarios de production nécessitent généralement de la coordination. Agent Framework 1.0 est livré avec des patterns d’orchestration éprouvés au combat directement de Microsoft Research et AutoGen :

Séquentiel — les agents traitent dans l’ordre (rédacteur → réviseur → éditeur)
Concurrent — distribue vers plusieurs agents en parallèle, converge les résultats
Handoff — un agent délègue à un autre basé sur l’intention
Chat de groupe — plusieurs agents discutent et convergent vers une solution
Magentic-One — le pattern multi-agent de niveau recherche de MSR

Tous supportent le streaming, le checkpointing, les approbations humain-dans-la-boucle, et la pause/reprise. La partie checkpointing est cruciale — les workflows de longue durée survivent aux redémarrages de processus. Pour nous, développeurs .NET qui avons construit des workflows durables avec Azure Functions, ça nous parle.

Les fonctionnalités qui comptent le plus

Voici ma liste de ce qui vaut la peine d’être connu :

Hooks middleware. Vous savez comment ASP.NET Core a des pipelines middleware ? Même concept, mais pour l’exécution des agents. Interceptez chaque étape — ajoutez la sécurité du contenu, le logging, les politiques de conformité — sans toucher aux prompts de l’agent. C’est comme ça que vous rendez les agents prêts pour l’entreprise.

Mémoire pluggable. Historique conversationnel, état persistant clé-valeur, récupération basée sur les vecteurs. Choisissez votre backend : Foundry Agent Service, Mem0, Redis, Neo4j, ou créez le vôtre. La mémoire est ce qui transforme un appel LLM sans état en un agent qui se souvient réellement du contexte.

Agents YAML déclaratifs. Définissez les instructions de votre agent, ses outils, sa mémoire et sa topologie d’orchestration dans des fichiers YAML versionnés. Chargez et exécutez avec un seul appel API. C’est un changement de donne pour les équipes qui veulent itérer sur le comportement de l’agent sans redéployer du code.

Support A2A et MCP. MCP (Model Context Protocol) permet aux agents de découvrir et d’invoquer des outils externes dynamiquement. A2A (protocole Agent-to-Agent) permet la collaboration inter-runtime — vos agents .NET peuvent se coordonner avec des agents s’exécutant dans d’autres frameworks. Le support A2A 1.0 arrive bientôt.

Les fonctionnalités en preview à surveiller

Certaines fonctionnalités ont été livrées en preview dans la 1.0 — fonctionnelles mais les APIs peuvent évoluer :

DevUI — un débogueur local basé navigateur pour visualiser l’exécution de l’agent, les flux de messages et les appels d’outils en temps réel. Pensez Application Insights, mais pour le raisonnement de l’agent.
GitHub Copilot SDK et Claude Code SDK — utilisez Copilot ou Claude comme harness d’agent directement depuis votre code d’orchestration. Composez un agent capable de coder aux côtés de vos autres agents dans le même workflow.
Agent Harness — un runtime local personnalisable donnant aux agents l’accès au shell, au système de fichiers et aux boucles de messagerie. Pensez agents de codage et patterns d’automatisation.
Skills — des packages de capacités de domaine réutilisables qui donnent aux agents des capacités structurées prêtes à l’emploi.

Migration depuis Semantic Kernel ou AutoGen

Si vous avez du code Semantic Kernel ou AutoGen existant, il existe des assistants de migration dédiés qui analysent votre code et génèrent des plans de migration étape par étape. Le guide de migration Semantic Kernel et le guide de migration AutoGen vous accompagnent à travers tout.

Si vous étiez sur les packages RC, la mise à niveau vers 1.0 est juste un changement de version.

Pour conclure

Agent Framework 1.0 est le jalon de production que les équipes entreprise attendaient. APIs stables, support multi-fournisseur, patterns d’orchestration qui fonctionnent réellement à l’échelle, et des chemins de migration depuis Semantic Kernel et AutoGen.

Le framework est entièrement open source sur GitHub, et vous pouvez commencer dès aujourd’hui avec dotnet add package Microsoft.Agents.AI. Consultez le guide de démarrage rapide et les exemples pour mettre les mains dans le cambouis.

Si vous attendiez le signal « utilisable en production en toute sécurité » — c’est celui-ci.