Semantic-Kernel | The .NET Blog

Le Agent Skills in .NET sono diventate davvero flessibili

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

Questo articolo è stato tradotto automaticamente. Per la versione originale, clicca qui.

Se avete costruito agenti con il Microsoft Agent Framework, conoscete il processo: definite le skill, le collegate a un provider e lasciate che l’agente decida quale invocare. La novità è come create queste skill — e il salto in flessibilità è significativo.

L’ultimo aggiornamento introduce tre pattern di authoring per le agent skill: basate su file, basate su classi e definite in codice inline. Tutte e tre si collegano a un unico AgentSkillsProviderBuilder, il che significa che potete mescolarle senza logica di routing o codice speciale. Vi mostro ciascuna e quando usarla.

Skill basate su file: il punto di partenza

Le skill basate su file sono esattamente quello che sembrano — una directory su disco con un file SKILL.md, script opzionali e documenti di riferimento. Il modo più diretto per dare nuove capacità al vostro agente:

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

Il frontmatter di SKILL.md dichiara il nome e la descrizione, e la sezione istruzioni dice all’agente come usare script e riferimenti:

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

Poi lo collegate con SubprocessScriptRunner.RunAsync per l’esecuzione degli script:

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’agente scopre la skill automaticamente e invoca lo script di provisioning quando deve verificare lo stato degli account. Pulito e semplice.

Skill basate su classi: distribuire via NuGet

Qui diventa interessante per i team. Le skill basate su classi derivano da AgentClassSkill<T> e usano attributi come [AgentSkillResource] e [AgentSkillScript] perché il framework scopra tutto tramite reflection:

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

Il bello è che un team può impacchettarlo come pacchetto NuGet. Lo aggiungete al progetto, lo inserite nel builder e funziona accanto alle vostre skill basate su file senza coordinazione:

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

Entrambe le skill appaiono nel system prompt dell’agente. L’agente decide quale usare in base alla conversazione — nessun codice di routing necessario.

Skill inline: il ponte rapido

Conoscete quel momento in cui un altro team sta costruendo esattamente la skill di cui avete bisogno, ma non sarà pronta fino al prossimo sprint? AgentInlineSkill è il vostro ponte:

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

Aggiungetela al builder come le altre:

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

Quando il pacchetto NuGet esce finalmente, sostituite la skill inline con la versione basata su classe. L’agente non nota la differenza.

Ma le skill inline non sono solo per i ponti. Sono anche la scelta giusta quando dovete generare skill dinamicamente a runtime — pensate a una skill per unità di business caricata dalla configurazione — o quando uno script deve catturare stato locale che non appartiene a un container DI.

Approvazione degli script: umano nel loop

Per noi sviluppatori .NET che costruiamo agenti di produzione, questa è la parte che sblocca davvero le discussioni sul deployment. Alcuni script hanno conseguenze reali — iscrivere qualcuno ai benefit, interrogare l’infrastruttura di produzione. Attivate UseScriptApproval e l’agente si ferma prima di eseguire qualsiasi script:

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

Quando l’agente vuole eseguire uno script, restituisce una richiesta di approvazione. La vostra app raccoglie la decisione — approvare o rifiutare — e l’agente continua di conseguenza. Negli ambienti regolamentati, questa è la differenza tra “possiamo fare il deploy” e “l’ufficio legale dice no.”

Perché questa combinazione conta

Il vero potere non è in nessun pattern individuale — è nella composizione. Potete:

Iniziare in piccolo con una skill basata su file, iterare sulle istruzioni e pubblicarla senza scrivere C#
Distribuire skill riutilizzabili come pacchetti NuGet che altri team aggiungono con una riga
Colmare lacune con skill inline quando avete bisogno di qualcosa adesso
Filtrare directory condivise con predicati perché il vostro agente carichi solo quello che deve
Aggiungere supervisione umana per gli script che toccano sistemi di produzione

Tutto questo si compone tramite AgentSkillsProviderBuilder. Nessun routing speciale, nessuna logica condizionale, nessun controllo del tipo di skill.

Per concludere

Le agent skill in .NET ora hanno un modello di authoring genuinamente flessibile. Che siate uno sviluppatore solo che prototipa con skill basate su file o un team enterprise che distribuisce capacità impacchettate via NuGet, i pattern si adattano. E il meccanismo di approvazione degli script lo rende pronto per la produzione negli ambienti dove serve quel checkpoint umano.

Date un’occhiata all’annuncio originale, alla documentazione Agent Skills su Microsoft Learn e agli esempi .NET su GitHub per iniziare.

Microsoft Agent Framework Raggiunge la 1.0 — Ecco Cosa Conta Davvero per gli Sviluppatori .NET

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

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

Se hai seguito il percorso di Agent Framework dai primi giorni di Semantic Kernel e AutoGen, questo è significativo. Microsoft Agent Framework ha appena raggiunto la versione 1.0 — pronto per la produzione, API stabili, impegno di supporto a lungo termine. È disponibile sia per .NET che per Python, ed è genuinamente pronto per carichi di lavoro reali.

Vi taglio attraverso il rumore dell’annuncio e mi concentro su ciò che conta se state costruendo app alimentate dall’IA con .NET.

La versione breve

Agent Framework 1.0 unifica quello che erano Semantic Kernel e AutoGen in un singolo SDK open source. Un’astrazione di agente. Un motore di orchestrazione. Molteplici provider di IA. Se avete saltato tra Semantic Kernel per i pattern enterprise e AutoGen per i workflow multi-agente di livello ricerca, potete smettere. Questo è l’unico SDK ora.

Iniziare è quasi ingiustamente semplice

Ecco un agente funzionante in .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."));

Tutto qui. Una manciata di righe e hai un agente IA che gira su Azure Foundry. L’equivalente Python è altrettanto conciso. Aggiungi strumenti di funzione, conversazioni multi-turno e streaming man mano che procedi — la superficie dell’API scala senza diventare strana.

Orchestrazione multi-agente — questa è la cosa seria

Gli agenti singoli vanno bene per le demo, ma gli scenari di produzione di solito necessitano di coordinamento. Agent Framework 1.0 arriva con pattern di orchestrazione testati in battaglia direttamente da Microsoft Research e AutoGen:

Sequenziale — gli agenti elaborano in ordine (scrittore → revisore → editor)
Concorrente — distribuisci a più agenti in parallelo, convergi i risultati
Handoff — un agente delega a un altro in base all’intento
Chat di gruppo — più agenti discutono e convergono su una soluzione
Magentic-One — il pattern multi-agente di livello ricerca di MSR

Tutti supportano streaming, checkpointing, approvazioni human-in-the-loop e pausa/ripresa. La parte di checkpointing è cruciale — i workflow di lunga durata sopravvivono ai riavvii del processo. Per noi sviluppatori .NET che abbiamo costruito workflow durevoli con Azure Functions, questo è familiare.

Le funzionalità che contano di più

Ecco la mia lista di ciò che vale la pena sapere:

Hook middleware. Sapete come ASP.NET Core ha le pipeline middleware? Stesso concetto, ma per l’esecuzione degli agenti. Intercetta ogni fase — aggiungi sicurezza dei contenuti, logging, policy di conformità — senza toccare i prompt dell’agente. È così che rendi gli agenti pronti per l’enterprise.

Memoria pluggable. Storico conversazionale, stato persistente chiave-valore, recupero basato su vettori. Scegli il tuo backend: Foundry Agent Service, Mem0, Redis, Neo4j, o costruisci il tuo. La memoria è ciò che trasforma una chiamata LLM senza stato in un agente che ricorda davvero il contesto.

Agenti YAML dichiarativi. Definisci le istruzioni del tuo agente, gli strumenti, la memoria e la topologia di orchestrazione in file YAML versionati. Carica ed esegui con una singola chiamata API. Questo è un game-changer per i team che vogliono iterare sul comportamento dell’agente senza ridistribuire il codice.

Supporto A2A e MCP. MCP (Model Context Protocol) permette agli agenti di scoprire e invocare strumenti esterni dinamicamente. A2A (protocollo Agent-to-Agent) abilita la collaborazione cross-runtime — i tuoi agenti .NET possono coordinarsi con agenti in esecuzione in altri framework. Il supporto A2A 1.0 arriverà presto.

Le funzionalità in preview da tenere d’occhio

Alcune funzionalità sono state rilasciate come preview nella 1.0 — funzionali ma le API potrebbero evolvere:

DevUI — un debugger locale basato su browser per visualizzare l’esecuzione dell’agente, i flussi di messaggi e le chiamate agli strumenti in tempo reale. Pensate ad Application Insights, ma per il ragionamento dell’agente.
GitHub Copilot SDK e Claude Code SDK — usa Copilot o Claude come harness dell’agente direttamente dal tuo codice di orchestrazione. Componi un agente capace di programmare accanto ai tuoi altri agenti nello stesso workflow.
Agent Harness — un runtime locale personalizzabile che dà agli agenti accesso a shell, file system e loop di messaggistica. Pensate ad agenti di coding e pattern di automazione.
Skills — pacchetti riutilizzabili di capacità di dominio che danno agli agenti capacità strutturate pronte all’uso.

Migrazione da Semantic Kernel o AutoGen

Se avete codice Semantic Kernel o AutoGen esistente, ci sono assistenti di migrazione dedicati che analizzano il vostro codice e generano piani di migrazione passo dopo passo. La guida alla migrazione da Semantic Kernel e la guida alla migrazione da AutoGen vi accompagnano attraverso tutto.

Se siete stati sui pacchetti RC, l’aggiornamento alla 1.0 è solo un cambio di versione.

Per concludere

Agent Framework 1.0 è il traguardo di produzione che i team enterprise stavano aspettando. API stabili, supporto multi-provider, pattern di orchestrazione che funzionano davvero su scala, e percorsi di migrazione sia da Semantic Kernel che da AutoGen.

Il framework è completamente open source su GitHub, e potete iniziare oggi con dotnet add package Microsoft.Agents.AI. Date un’occhiata alla guida rapida e agli esempi per mettere le mani in pasta.

Se stavate aspettando il segnale “sicuro da usare in produzione” — eccolo.