Semantic-Kernel | The .NET Blog

Agent Skills in .NET sind jetzt richtig flexibel

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

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion hier klicken.

Wenn ihr Agenten mit dem Microsoft Agent Framework baut, kennt ihr den Ablauf: Skills definieren, in einen Provider einbinden und den Agenten entscheiden lassen, welchen er aufruft. Neu ist wie ihr diese Skills erstellt — und der Flexibilitätssprung ist erheblich.

Das neueste Update führt drei verschiedene Authoring-Patterns für Agent Skills ein: dateibasiert, klassenbasiert und inline-codedefiniert. Alle drei werden über einen einzigen AgentSkillsProviderBuilder verbunden, sodass ihr sie ohne Routing-Logik oder speziellen Glue-Code mischen könnt. Ich zeige euch jedes Pattern und wann ihr es einsetzen solltet.

Dateibasierte Skills: der Einstiegspunkt

Dateibasierte Skills sind genau das, wonach sie klingen — ein Verzeichnis auf der Festplatte mit einer SKILL.md-Datei, optionalen Scripts und Referenzdokumenten. Die einfachste Art, eurem Agenten neue Fähigkeiten zu geben:

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

Das SKILL.md-Frontmatter deklariert den Skill-Namen und die Beschreibung, und der Instruktionsabschnitt sagt dem Agenten, wie er Scripts und Referenzen nutzen soll:

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

Dann verbindet ihr es mit SubprocessScriptRunner.RunAsync für die Script-Ausführung:

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

Der Agent entdeckt den Skill automatisch und ruft das Provisioning-Script auf, wenn er den Kontostatus prüfen muss. Sauber und einfach.

Klassenbasierte Skills: per NuGet ausliefern

Hier wird es für Teams interessant. Klassenbasierte Skills leiten von AgentClassSkill<T> ab und verwenden Attribute wie [AgentSkillResource] und [AgentSkillScript], damit das Framework alles per Reflection entdeckt:

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

Das Schöne daran: Ein Team kann das als NuGet-Paket verpacken. Ihr fügt es eurem Projekt hinzu, steckt es in den Builder und es funktioniert neben euren dateibasierten Skills ohne Koordination:

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

Beide Skills erscheinen im System-Prompt des Agenten. Der Agent entscheidet basierend auf dem Gespräch, welchen er nutzt — kein Routing-Code nötig.

Inline Skills: die schnelle Brücke

Kennt ihr das, wenn ein anderes Team genau den Skill baut, den ihr braucht, aber erst im nächsten Sprint fertig wird? AgentInlineSkill ist eure Brücke:

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

Fügt ihn genauso wie die anderen zum Builder hinzu:

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

Wenn das NuGet-Paket irgendwann erscheint, tauscht ihr den Inline-Skill gegen die klassenbasierte Version aus. Der Agent merkt den Unterschied nicht.

Inline Skills sind aber nicht nur für Brücken. Sie sind auch die richtige Wahl, wenn ihr Skills dynamisch zur Laufzeit generieren müsst — denkt an einen Skill pro Geschäftsbereich aus einer Konfiguration geladen — oder wenn ein Script lokalen State erfassen muss, der nicht in einen DI-Container gehört.

Script-Genehmigung: Mensch in der Schleife

Für uns .NET-Entwickler, die Produktionsagenten bauen, ist das der Teil, der Deployment-Gespräche wirklich freischaltet. Manche Scripts haben echte Konsequenzen — jemanden in Benefits einschreiben, Produktionsinfrastruktur abfragen. Aktiviert UseScriptApproval und der Agent pausiert vor jeder Script-Ausführung:

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

Wenn der Agent ein Script ausführen will, gibt er stattdessen eine Genehmigungsanfrage zurück. Eure App sammelt die Entscheidung — genehmigen oder ablehnen — und der Agent fährt entsprechend fort. In regulierten Umgebungen ist das der Unterschied zwischen “wir können das deployen” und “die Rechtsabteilung sagt nein.”

Warum diese Kombination wichtig ist

Die echte Stärke liegt nicht in einem einzelnen Authoring-Pattern — sondern in der Komposition. Ihr könnt:

Klein anfangen mit einem dateibasierten Skill, die Instruktionen iterieren und ohne C# veröffentlichen
Wiederverwendbare Skills als NuGet-Pakete ausliefern, die andere Teams mit einer Zeile hinzufügen können
Lücken überbrücken mit Inline Skills, wenn ihr etwas jetzt braucht
Gemeinsame Skill-Verzeichnisse filtern mit Predicates, damit euer Agent nur das lädt, was er soll
Menschliche Aufsicht hinzufügen für Scripts, die Produktionssysteme berühren

All das wird über AgentSkillsProviderBuilder zusammengesetzt. Kein spezielles Routing, keine bedingte Logik, keine Skill-Typ-Prüfungen.

Zum Abschluss

Agent Skills in .NET haben jetzt ein wirklich flexibles Authoring-Modell. Ob ihr ein Solo-Entwickler seid, der mit dateibasierten Skills einen Prototyp skizziert, oder ein Enterprise-Team, das verpackte Fähigkeiten per NuGet ausliefert — die Patterns passen. Und der Script-Genehmigungsmechanismus macht es produktionsreif für Umgebungen, in denen ihr diesen menschlichen Checkpoint braucht.

Schaut euch die Original-Ankündigung an, die Agent Skills Dokumentation auf Microsoft Learn und die .NET-Beispiele auf GitHub zum Loslegen.

Microsoft Agent Framework Erreicht 1.0 — Das Ist Wirklich Wichtig für .NET-Entwickler

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

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Wenn du die Reise des Agent Frameworks seit den frühen Tagen von Semantic Kernel und AutoGen verfolgt hast, ist das hier bedeutend. Microsoft Agent Framework hat gerade Version 1.0 erreicht — produktionsreif, stabile APIs, langfristiges Support-Commitment. Es ist sowohl für .NET als auch für Python verfügbar und wirklich bereit für echte Workloads.

Ich schneide durch den Ankündigungslärm und konzentriere mich auf das, was wichtig ist, wenn du KI-gestützte Apps mit .NET baust.

Die Kurzversion

Agent Framework 1.0 vereint das, was früher Semantic Kernel und AutoGen waren, in ein einziges Open-Source-SDK. Eine Agent-Abstraktion. Eine Orchestrierungs-Engine. Mehrere KI-Anbieter. Wenn du zwischen Semantic Kernel für Enterprise-Patterns und AutoGen für forschungsbasierte Multi-Agent-Workflows hin und her gesprungen bist, kannst du aufhören. Das ist jetzt das eine SDK.

Der Einstieg ist fast unfair einfach

Hier ist ein funktionierender Agent 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."));

Das war’s. Eine Handvoll Zeilen und du hast einen KI-Agenten, der gegen Azure Foundry läuft. Das Python-Äquivalent ist genauso knapp. Füge Funktions-Tools, Multi-Turn-Konversationen und Streaming hinzu, wie du vorankommst — die API-Oberfläche skaliert, ohne seltsam zu werden.

Multi-Agent-Orchestrierung — das ist die echte Sache

Einzelne Agenten sind gut für Demos, aber Produktionsszenarien brauchen normalerweise Koordination. Agent Framework 1.0 liefert kampferprobte Orchestrierungsmuster direkt von Microsoft Research und AutoGen:

Sequenziell — Agenten verarbeiten der Reihe nach (Autor → Reviewer → Editor)
Gleichzeitig — verteile an mehrere Agenten parallel, führe Ergebnisse zusammen
Handoff — ein Agent delegiert basierend auf der Absicht an einen anderen
Gruppen-Chat — mehrere Agenten diskutieren und konvergieren zu einer Lösung
Magentic-One — das forschungsbasierte Multi-Agent-Pattern von MSR

Alle unterstützen Streaming, Checkpointing, Human-in-the-Loop-Freigaben und Pause/Fortsetzen. Der Checkpointing-Teil ist entscheidend — lang laufende Workflows überleben Prozess-Neustarts. Für uns .NET-Entwickler, die dauerhafte Workflows mit Azure Functions gebaut haben, fühlt sich das vertraut an.

Die Features, die am meisten zählen

Hier ist meine Shortlist dessen, was wissenswert ist:

Middleware-Hooks. Du weißt, wie ASP.NET Core Middleware-Pipelines hat? Gleiches Konzept, aber für die Agent-Ausführung. Fange jede Stufe ab — füge Content-Sicherheit, Logging, Compliance-Richtlinien hinzu — ohne die Agent-Prompts anzufassen. So machst du Agenten enterprise-ready.

Steckbare Memory. Konversationshistorie, persistenter Key-Value-State, vektorbasiertes Retrieval. Wähle dein Backend: Foundry Agent Service, Mem0, Redis, Neo4j, oder baue dein eigenes. Memory ist das, was einen zustandslosen LLM-Aufruf in einen Agenten verwandelt, der sich tatsächlich an den Kontext erinnert.

Deklarative YAML-Agenten. Definiere die Anweisungen, Tools, Memory und Orchestrierungs-Topologie deines Agenten in versionskontrollierten YAML-Dateien. Lade und starte mit einem einzigen API-Aufruf. Das ist ein Game-Changer für Teams, die das Agent-Verhalten iterieren wollen, ohne Code neu zu deployen.

A2A- und MCP-Unterstützung. MCP (Model Context Protocol) ermöglicht es Agenten, externe Tools dynamisch zu entdecken und aufzurufen. A2A (Agent-to-Agent-Protokoll) ermöglicht runtime-übergreifende Zusammenarbeit — deine .NET-Agenten können sich mit Agenten in anderen Frameworks koordinieren. A2A 1.0-Unterstützung kommt bald.

Die Preview-Features, die es wert sind, beobachtet zu werden

Einige Features wurden als Preview in 1.0 ausgeliefert — funktional, aber APIs können sich weiterentwickeln:

DevUI — ein browserbasierter lokaler Debugger zur Visualisierung der Agent-Ausführung, Nachrichtenflüsse und Tool-Aufrufe in Echtzeit. Denk an Application Insights, aber für Agent-Reasoning.
GitHub Copilot SDK und Claude Code SDK — verwende Copilot oder Claude als Agent-Harness direkt aus deinem Orchestrierungscode. Komponiere einen programmierfähigen Agenten neben deinen anderen Agenten im selben Workflow.
Agent Harness — eine anpassbare lokale Runtime, die Agenten Zugriff auf Shell, Dateisystem und Messaging-Loops gibt. Denk an Coding-Agenten und Automatisierungsmuster.
Skills — wiederverwendbare Domain-Capability-Pakete, die Agenten strukturierte Fähigkeiten out of the box geben.

Migration von Semantic Kernel oder AutoGen

Wenn du bestehenden Semantic Kernel- oder AutoGen-Code hast, gibt es dedizierte Migrationsassistenten, die deinen Code analysieren und schrittweise Migrationspläne generieren. Der Semantic Kernel Migrationsleitfaden und der AutoGen Migrationsleitfaden führen dich durch alles.

Wenn du auf den RC-Paketen warst, ist das Upgrade auf 1.0 nur ein Versions-Bump.

Zum Abschluss

Agent Framework 1.0 ist der Produktions-Meilenstein, auf den Enterprise-Teams gewartet haben. Stabile APIs, Multi-Provider-Support, Orchestrierungsmuster, die tatsächlich im großen Maßstab funktionieren, und Migrationspfade von sowohl Semantic Kernel als auch AutoGen.

Das Framework ist vollständig Open Source auf GitHub, und du kannst heute mit dotnet add package Microsoft.Agents.AI loslegen. Schau dir den Schnellstart-Leitfaden und die Beispiele an, um praktisch einzusteigen.

Wenn du auf das Signal „sicher für den Produktionseinsatz" gewartet hast — das ist es.