Semantic-Kernel | The .NET Blog

As Agent Skills no .NET ficaram realmente flexíveis

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

Este artigo foi traduzido automaticamente. Para a versão original, clique aqui.

Se você tem construído agentes com o Microsoft Agent Framework, já conhece o processo: define skills, conecta a um provider e deixa o agente decidir qual invocar. O que há de novo é como você cria essas skills — e o salto em flexibilidade é significativo.

A última atualização introduz três padrões de autoria para agent skills: baseadas em arquivos, baseadas em classes e definidas em código inline. As três se conectam a um único AgentSkillsProviderBuilder, o que significa que você pode misturar e combinar sem lógica de roteamento nem código especial. Vou te mostrar cada uma e quando usar.

Skills baseadas em arquivos: o ponto de partida

Skills baseadas em arquivos são exatamente o que parecem — um diretório no disco com um arquivo SKILL.md, scripts opcionais e documentos de referência. A forma mais direta de dar novas capacidades ao seu agente:

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

O frontmatter do SKILL.md declara o nome e descrição, e a seção de instruções diz ao agente como usar os scripts e referências:

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

Depois você conecta com SubprocessScriptRunner.RunAsync para execução 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);

O agente descobre a skill automaticamente e invoca o script de provisioning quando precisa verificar o status das contas. Limpo e simples.

Skills baseadas em classes: distribuir via NuGet

Aqui é onde fica interessante para times. Skills baseadas em classes derivam de AgentClassSkill<T> e usam atributos como [AgentSkillResource] e [AgentSkillScript] para que o framework descubra tudo por reflexão:

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

O legal é que um time pode empacotar isso como pacote NuGet. Você adiciona ao projeto, coloca no builder e funciona junto com suas skills de arquivo sem coordenação:

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

Ambas as skills aparecem no system prompt do agente. O agente decide qual usar baseado na conversa — sem código de roteamento.

Skills inline: a ponte rápida

Sabe aquele momento quando outro time está construindo exatamente a skill que você precisa, mas só vai ficar pronta no próximo sprint? AgentInlineSkill é sua 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 });
 });

Adicione ao builder assim como as outras:

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

Quando o pacote NuGet finalmente sair, você troca a skill inline pela versão baseada em classe. O agente não percebe a diferença.

Mas skills inline não são só para pontes. Também são a escolha certa quando você precisa gerar skills dinamicamente em runtime — pense em uma skill por unidade de negócio carregada de configuração — ou quando um script precisa capturar estado local que não pertence a um contêiner DI.

Aprovação de scripts: humano no loop

Para nós desenvolvedores .NET construindo agentes de produção, essa é a parte que realmente desbloqueia conversas de deploy. Alguns scripts têm consequências reais — inscrever alguém em benefícios, consultar infraestrutura de produção. Ative UseScriptApproval e o agente pausa antes de executar qualquer script:

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

Quando o agente quer executar um script, retorna um pedido de aprovação. Seu app coleta a decisão — aprovar ou rejeitar — e o agente continua. Em ambientes regulados, essa é a diferença entre “podemos fazer deploy disso” e “o jurídico disse não.”

Por que essa combinação importa

O verdadeiro poder não está em nenhum padrão individual — está na composição. Você pode:

Começar pequeno com uma skill de arquivo, iterar nas instruções e publicar sem escrever C#
Distribuir skills reutilizáveis como pacotes NuGet que outros times adicionam com uma linha
Cobrir lacunas com skills inline quando precisa de algo agora
Filtrar diretórios compartilhados com predicados para que seu agente só carregue o que deve
Adicionar supervisão humana para scripts que tocam sistemas de produção

Tudo isso se compõe via AgentSkillsProviderBuilder. Sem roteamento especial, sem lógica condicional, sem verificações de tipo de skill.

Para encerrar

As agent skills no .NET agora têm um modelo de autoria genuinamente flexível. Seja você um desenvolvedor solo prototipando com skills de arquivo ou um time enterprise distribuindo capacidades empacotadas via NuGet, os padrões se encaixam. E o mecanismo de aprovação de scripts o torna pronto para produção em ambientes onde você precisa daquele checkpoint humano.

Confira o anúncio original, a documentação de Agent Skills no Microsoft Learn e os exemplos .NET no GitHub para começar.

Microsoft Agent Framework Chega à 1.0 — Eis O Que Realmente Importa para Desenvolvedores .NET

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

Este post foi traduzido automaticamente. Para a versão original, clique aqui.

Se você tem acompanhado a jornada do Agent Framework desde os primeiros dias do Semantic Kernel e AutoGen, este é significativo. O Microsoft Agent Framework acabou de chegar à versão 1.0 — pronto para produção, APIs estáveis, compromisso de suporte de longo prazo. Está disponível tanto para .NET quanto para Python, e está genuinamente pronto para cargas de trabalho reais.

Vou cortar o ruído do anúncio e focar no que importa se você está construindo apps com IA usando .NET.

A versão curta

Agent Framework 1.0 unifica o que costumava ser Semantic Kernel e AutoGen em um único SDK open source. Uma abstração de agente. Um motor de orquestração. Múltiplos provedores de IA. Se você estava alternando entre Semantic Kernel para padrões enterprise e AutoGen para workflows multi-agente de nível pesquisa, pode parar. Este é o único SDK agora.

Começar é quase injustamente simples

Aqui está um agente funcional em .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."));

É isso. Um punhado de linhas e você tem um agente de IA rodando contra o Azure Foundry. O equivalente em Python é igualmente conciso. Adicione ferramentas de funções, conversas multi-turno e streaming conforme avança — a superfície da API escala sem ficar estranha.

Orquestração multi-agente — isso é pra valer

Agentes individuais são bons para demos, mas cenários de produção geralmente precisam de coordenação. Agent Framework 1.0 vem com padrões de orquestração testados em batalha diretamente da Microsoft Research e AutoGen:

Sequencial — agentes processam em ordem (escritor → revisor → editor)
Concorrente — distribui para múltiplos agentes em paralelo, converge resultados
Handoff — um agente delega para outro baseado na intenção
Chat em grupo — múltiplos agentes discutem e convergem para uma solução
Magentic-One — o padrão multi-agente de nível pesquisa do MSR

Todos suportam streaming, checkpointing, aprovações com humano no loop, e pausa/retomada. A parte de checkpointing é crucial — workflows de longa duração sobrevivem a reinícios de processo. Para nós desenvolvedores .NET que construímos workflows duráveis com Azure Functions, isso é familiar.

As funcionalidades que mais importam

Aqui está minha lista do que vale a pena saber:

Hooks de middleware. Sabe como o ASP.NET Core tem pipelines de middleware? Mesmo conceito, mas para execução de agentes. Intercepte cada estágio — adicione segurança de conteúdo, logging, políticas de compliance — sem tocar nos prompts do agente. É assim que você torna agentes prontos para enterprise.

Memória plugável. Histórico conversacional, estado persistente chave-valor, recuperação baseada em vetores. Escolha seu backend: Foundry Agent Service, Mem0, Redis, Neo4j, ou crie o seu próprio. Memória é o que transforma uma chamada LLM sem estado em um agente que realmente lembra do contexto.

Agentes YAML declarativos. Defina as instruções do seu agente, ferramentas, memória e topologia de orquestração em arquivos YAML versionados. Carregue e execute com uma única chamada de API. Isso é um divisor de águas para equipes que querem iterar no comportamento do agente sem reimplantar código.

Suporte A2A e MCP. MCP (Model Context Protocol) permite que agentes descubram e invoquem ferramentas externas dinamicamente. A2A (protocolo Agent-to-Agent) habilita colaboração entre runtimes — seus agentes .NET podem se coordenar com agentes rodando em outros frameworks. O suporte ao A2A 1.0 está chegando em breve.

As funcionalidades em preview que valem acompanhar

Algumas funcionalidades foram lançadas como preview na 1.0 — funcionais mas as APIs podem evoluir:

DevUI — um depurador local baseado em navegador para visualizar a execução do agente, fluxos de mensagens e chamadas de ferramentas em tempo real. Pense no Application Insights, mas para o raciocínio do agente.
GitHub Copilot SDK e Claude Code SDK — use o Copilot ou Claude como harness de agente diretamente do seu código de orquestração. Componha um agente capaz de programar ao lado dos seus outros agentes no mesmo workflow.
Agent Harness — um runtime local customizável que dá aos agentes acesso a shell, sistema de arquivos e loops de mensagens. Pense em agentes de código e padrões de automação.
Skills — pacotes reutilizáveis de capacidades de domínio que dão aos agentes capacidades estruturadas prontas para uso.

Migrando do Semantic Kernel ou AutoGen

Se você tem código existente de Semantic Kernel ou AutoGen, existem assistentes de migração dedicados que analisam seu código e geram planos de migração passo a passo. O guia de migração do Semantic Kernel e o guia de migração do AutoGen te guiam por tudo.

Se você estava nos pacotes RC, atualizar para 1.0 é apenas uma mudança de versão.

Finalizando

Agent Framework 1.0 é o marco de produção que as equipes enterprise estavam esperando. APIs estáveis, suporte multi-provedor, padrões de orquestração que realmente funcionam em escala, e caminhos de migração tanto do Semantic Kernel quanto do AutoGen.

O framework é totalmente open source no GitHub, e você pode começar hoje com dotnet add package Microsoft.Agents.AI. Confira o guia de início rápido e os exemplos para colocar a mão na massa.

Se você estava esperando o sinal de “seguro para usar em produção” — é este.