AI Agents | The .NET Blog

Microsoft Agent Framework Teil 3: Von Tools zu Workflows — Die Bausteine fügen sich zusammen

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Die Originalversion findest du hier.

Wenn du der Building Blocks for AI in .NET-Serie gefolgt bist, weißt du: Teil 1 brachte uns IChatClient (die universelle Modellschnittstelle) und Teil 2 Microsoft.Extensions.VectorData (semantische Suche und RAG). Beides sind grundlegende Bausteine, jeder für sich nützlich. Aber hier beginnt alles, sich zu verbinden.

Teil 3 dreht sich um das Microsoft Agent Framework — und ehrlich gesagt ist es genau das Stück, auf das ich in .NET gewartet habe. Version 1.0 erschien im April. Die API ist stabil. Es ist Zeit, echte Agenten zu bauen.

Was ein Agent wirklich ist (vs. ein Chatbot)

Bevor wir in den Code einsteigen, klären wir diesen Unterschied. Ein Chatbot empfängt Input, ruft ein Modell auf, gibt Output zurück. Einfache Schleife.

Ein Agent hat Autonomie. Er kann über eine Aufgabe nachdenken, entscheiden, welche Tools er verwenden soll, diese aufrufen, Ergebnisse auswerten und entscheiden, was als nächstes zu tun ist — alles ohne explizite Schritt-für-Schritt-Logik von deiner Seite. Du gibst ihm Tools und Anweisungen, und er kümmert sich um die Orchestrierung.

Stell es dir so vor: IChatClient ist wie ein Gespräch. Ein Agent ist wie das Delegieren einer Aufgabenliste an jemanden.

Dein erster Agent in 10 Zeilen

dotnet add package Microsoft.Agents.AI

AIAgent agent = new AzureOpenAIClient(
 new Uri(endpoint),
 new DefaultAzureCredential())
 .GetChatClient(deploymentName)
 .AsAIAgent(
 instructions: "You are good at telling jokes.",
 name: "Joker");

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate."));

Die .AsAIAgent()-Erweiterungsmethode ist die Brücke. Dasselbe Muster wie .AsIChatClient() von MEAI — es verpackt das SDK des Anbieters in eine stabile Abstraktion. Funktioniert mit Azure OpenAI, OpenAI, GitHub Models, Microsoft Foundry oder lokalen Modellen.

Streaming funktioniert ebenfalls:

await foreach (var update in agent.RunStreamingAsync("Tell me a joke about a pirate."))
{
 Console.Write(update);
}

Dem Agenten Tools geben

Hier hören Agenten auf, ausgefeilte Chatbots zu sein. Tools sind Funktionen, die das Modell je nach Benutzeranfrage aufrufen kann. Du brauchst keine Routing-Logik — das Modell findet es selbst heraus.

[Description("Get the weather for a given location.")]
static string GetWeather(
 [Description("The location to get the weather for.")] string location)
 => $"The weather in {location} is cloudy with a high of 15°C.";

AIAgent agent = chatClient.AsAIAgent(
 instructions: "You are a helpful assistant",
 tools: [AIFunctionFactory.Create(GetWeather)]);

Zwei Dinge zu beachten. Erstens: AIFunctionFactory kommt von MEAI — dieselbe Tool-Factory, die du mit einem normalen IChatClient verwenden würdest. Bereits definierte Tools für Chat-Szenarien funktionieren hier auch.

Zweitens: Die Description-Attribute sind sehr wichtig. So versteht das Modell, was ein Tool macht und wann es eingesetzt werden soll. Behandle sie als Dokumentation für deine KI, nicht für Menschen.

Sessions: Gespräche mit echtem Gedächtnis

AgentSession session = await agent.CreateSessionAsync();

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate.", session));

Console.WriteLine(await agent.RunAsync(
 "Now add some emojis and tell it in the voice of a pirate's parrot.",
 session));

Ohne Session ist jeder RunAsync-Aufruf zustandslos. Mit Session weiß der Agent, auf welchen Witz du dich beziehst. AgentSession bewahrt den Gesprächsverlauf zwischen den Turns.

Für zustandslose Produktionsdienste lassen sich Sessions sauber serialisieren:

JsonElement sessionState = await agent.SerializeSessionAsync(session);
// ... irgendwo speichern ...
var restoredSession = await agent.DeserializeSessionAsync(sessionState);
Console.WriteLine(await agent.RunAsync("What were we just talking about?", restoredSession));

Das ist entscheidend, wenn dein Agent in einer serverlosen oder horizontal skalierten Umgebung läuft.

AIContextProvider: Persistentes Gedächtnis über Sessions hinaus

Sessions bewahren den Gesprächsverlauf innerhalb einer Session. Aber was ist mit Wissen über einen Benutzer über mehrere Sessions hinweg? Dafür ist AIContextProvider zuständig.

Er hat zwei Hooks:

ProvideAIContextAsync — läuft vor jeder Interaktion, injiziert Kontext in den Agenten
StoreAIContextAsync — läuft nach jeder Interaktion, ermöglicht Lernen und Persistierung

Das Muster ist elegant: Du kannst mehrere Provider stapeln — einer für Benutzerpräferenzen, einer für kürzliche Interaktionen, einer der deinen VectorData-Store nach relevanten Dokumenten abfragt. Letzteres ist genau das RAG-Muster aus Teil 2, das jetzt automatisch bei jedem Agenten-Aufruf ausgeführt wird.

Multi-Agenten-Workflows

Hier verdient das Framework seinen Namen. Es enthält ein graphenbasiertes Workflow-System, in dem Executors (Agenten, Funktionen, was auch immer) über Kanten verbunden werden.

Nativ unterstützte Muster:

Sequenziell: Die Ausgabe von Agent A speist Agent B
Parallel (Fan-out/Fan-in): Dispatchiert parallel an mehrere Agenten, sammelt Ergebnisse
Bedingtes Routing: Leitet Arbeit je nach Ausgabe an unterschiedliche Agenten weiter
Schreiber-Kritiker-Schleifen: Ein Agent schreibt, ein anderer bewertet, Schleife bis zur Genehmigung
Sub-Workflows: Hierarchisches Komponieren von Workflows

Ein Schreiber-Kritiker-Beispiel:

WorkflowBuilder builder = new(writerAgent);
builder
 .AddEdge(writerAgent, criticAgent)
 .AddEdge(criticAgent, writerAgent, condition: result => !result.IsApproved)
 .WithOutputFrom(criticAgent, condition: result => result.IsApproved);
var workflow = builder.Build();

Sauber, lesbar, und das bedingungsbasierte Routing bedeutet, dass du die Schleifenlogik nicht selbst schreibst.

Human-in-the-Loop

Nicht alles sollte vollständig autonom laufen. Für sensible Operationen — Datenbankschreibvorgänge, Finanztransaktionen, Kommunikationsversendungen — möchtest du, dass ein Mensch genehmigt, bevor der Agent ausführt.

Das Framework hat dafür eingebaute Unterstützung via FunctionApprovalRequestContent und FunctionApprovalResponseContent. Der Agent schlägt den Tool-Aufruf vor, dein Anwendungscode präsentiert ihn dem Benutzer, und die Antwort entscheidet, ob die Ausführung fortgesetzt wird.

Das ist die richtige Art, in Unternehmensumgebungen über Agenten nachzudenken: nicht vollständig autonom, sondern Autonomie mit Leitplanken.

Das Gesamtbild

Wenn du einen Schritt zurückgehst:

MEAI gibt dir eine universelle Schnittstelle zu jedem Modell
VectorData gibt deinen Agenten Zugriff auf das Wissen deiner Organisation durch semantische Suche
Agent Framework orchestriert alles — verwendet intern IChatClient, kombiniert sich mit Kontext-Providern und koordiniert durch Workflows

Jedes Teil wurde darauf ausgelegt, mit den anderen zu komponieren. Schau dir den Originalbeitrag von Jeremy Likness und das Agent Framework GitHub-Repository für die vollständigen Beispiele an.

Fazit

Der Microsoft Agent Framework Teil 3 schließt den Kreis der Building Blocks-Serie. Für .NET-Entwickler, die KI-Agenten bauen wollen — keine Chatbots, echte Agenten, die Tools verwenden, Dinge merken und koordinieren — das ist dein Weg nach vorne.

Der stabile 1.0-Release bedeutet, dass du damit in der Produktion bauen kannst. Wenn du darauf gewartet hast, in die Agentenentwicklung in .NET einzusteigen, ist jetzt der richtige Zeitpunkt.

SQL MCP Server auf Azure App Service — Ohne Container

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Die Originalversion findest du hier.

Ehrlich gesagt: Jedes Mal, wenn ich “erfordert einen Container” in einem Tutorial lese, seufze ich innerlich. Container sind großartig — bis dein Team keine Container-Strategie hat und eine scheinbar einfache Funktion hinter Orchestrierungsaufwand steckt, den niemand eingeplant hatte.

Deshalb hat mich das hier aufhorchen lassen. Der SQL MCP Server läuft jetzt auf Azure App Service — ohne Docker, ohne Kubernetes, nur mit derselben Data API Builder (DAB)-Konfiguration, die deine SQL-Datenbank über MCP, REST und GraphQL bereitstellt.

Was ist der SQL MCP Server?

Kurzer Kontext, falls du ihn noch nicht kennst. Der SQL MCP Server sitzt zwischen deinem KI-Agenten und deiner SQL-Datenbank. Statt dem Agenten direkten Datenbankzugriff zu geben (was eine schreckliche Idee wäre), stellt er Tabellen und Views als Abstraktionsschicht bereit — Entitäten mit definierten Berechtigungen.

Er basiert auf Data API Builder, was bedeutet, dass eine einzige Konfigurationsdatei MCP und REST und GraphQL gleichzeitig bereitstellt. Dein Agent spricht mit dem MCP-Endpoint. Deine klassische Anwendung spricht mit REST oder GraphQL. Gleiche Config, gleiche Runtime, unterschiedliche Oberflächen.

Das ist wirklich nützlich. Du pflegst nicht zwei separate API-Schichten.

Das Container-Problem (und die Lösung)

Das ursprüngliche Bereitstellungsmodell für den SQL MCP Server waren Container. Das funktioniert in vielen Teams gut — aber nicht in allen. Viele .NET-Teams standardisieren auf Azure App Service oder VMs. Einen Container-Runtime nur für einen SQL-Endpoint zu benötigen, fügt Reibung hinzu, die niemand angefordert hat.

Das neue Walkthrough zeigt, wie man den Container komplett überspringt. Alles läuft mit einem dab start-Befehl, gehostet auf App Service als standardmäßiger .NET 8-Webprozess.

# Data API Builder installieren
dotnet tool install microsoft.dataapibuilder --prerelease -g

# Konfiguration initialisieren
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# Eine Entität hinzufügen
dab add products --source dbo.products --permissions "authenticated:*"

# App Service Auth-Provider konfigurieren
dab configure --runtime.host.authentication.provider AppService

# Server starten
dab start

Jetzt hast du MCP unter /mcp, REST und GraphQL aus demselben Prozess, und nichts läuft in einem Container.

Authentifizierung ohne geteilte API-Schlüssel

Das ist der Teil, den ich am meisten schätze. Bei der Bereitstellung auf App Service konfigurierst du Microsoft Entra ID als Authentifizierungsanbieter. Keine geteilten Geheimnisse in Konfigurationsdateien, keine API-Schlüssel, die rotiert werden müssen.

Der Connection String bleibt in einer App Service-Umgebungsvariable (nicht in dab-config.json), und der MCP-Endpoint ist durch Plattform-Authentifizierung geschützt. Wenn du bereits auf Entra ID in deinen Azure-Workloads ausgerichtet bist, fügt sich das natürlich ein.

Für die lokale Entwicklung wechselst du in den Simulator-Modus und STDIO-Transport. Vor dem Deployment wechselst du zurück in den AppService-Modus. Klar und explizit.

Bereitstellung auf App Service

az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

Dann deployst du dein DAB-Projekt über deinen bevorzugten Code-Deployment-Weg. Das Entscheidende: Es ist ein Code-Deployment, kein Container-Deployment.

Warum das für .NET-Entwickler wichtig ist

Wenn du KI-Agenten in .NET baust, wird dein Agent irgendwann mit einer Datenbank kommunizieren müssen. Der SQL MCP Server bietet eine strukturierte Möglichkeit, das zu tun, ohne rohe Connection Strings preiszugeben.

Das vollständige Walkthrough findest du im Originalbeitrag und im Beispiel-Repository auf GitHub.

Fazit

Der SQL MCP Server auf App Service ist eine solide pragmatische Option für .NET-Teams, die ihren Agenten strukturierten SQL-Datenzugriff geben möchten, ohne eine Container-Strategie zu benötigen. Probier es aus — deine Agenten werden die saubere API-Oberfläche zu schätzen wissen.

MCP Toolaufrufe in .NET mit dem Agent Governance Toolkit steuern

Emiliano Montesdeoca — Mon, 04 May 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch ubersetzt. Die Originalversion findest du hier.

MCP Toolaufrufe in .NET mit dem Agent Governance Toolkit steuern ist fur Teams relevant, die .NET Systeme produktiv betreiben.

Aus meiner Sicht ist nicht nur die neue Funktion wichtig, sondern wie schnell man daraus ein wiederholbares Engineering Muster macht.

Warum das fur .NET Teams wichtig ist

Solche Updates helfen beim Ausgleich zwischen Liefergeschwindigkeit, Plattformkonsistenz und Governance.

Praktische nachste Schritte

Feature in einem kleinen .NET Pilot mit produktionsnahen Daten validieren.
Vor dem Rollout Observability und Rollback Punkte definieren.
Das Muster intern dokumentieren, damit andere Teams es ubernehmen konnen.

Quelle

Originalartikel: https://devblogs.microsoft.com/dotnet/governing-mcp-tool-calls-in-dotnet-with-the-agent-governance-toolkit/

Visual Studio April Update: Cloud Agent Integration fur .NET Workflows