Azure Functions | The .NET Blog

Langlebige Workflows in Microsoft Agent Framework: Von In-Memory zu Azure Functions

Emiliano Montesdeoca — Sun, 31 May 2026 00:00:00 +0000

Einer der Schmerzpunkte bei frühen KI-Agent-Workflows: Sie sind fragil. Ein lang laufender Multi-Step-Workflow, der an einen einzelnen Prozess gebunden ist, bedeutet, dass Prozessneustart = verlorener Zustand. Für einfache Demos ist das in Ordnung. Für Produktionsworkloads ist es das nicht.

Das Workflow-Programmiermodell von Microsoft Agent Framework unterstützt jetzt dauerhafte Ausführung, gesichert durch das Durable Task-Framework, mit Azure Functions-Hosting. Hier erfahren Sie, wie das Programmiermodell funktioniert und warum die Dauerhaftigkeitsgeschichte wichtig ist.

Die grundlegenden Bausteine

Executors sind die fundamentale Arbeitseinheit. Jeder ist typisiert — er nimmt eine bestimmte Eingabe und produziert eine bestimmte Ausgabe:

using Microsoft.Agents.AI.Workflows;

internal sealed class OrderLookup()
 : Executor<OrderCancelRequest, Order>("OrderLookup")
{
 public override async ValueTask<Order> HandleAsync(
 OrderCancelRequest message,
 IWorkflowContext context,
 CancellationToken cancellationToken = default)
 {
 // Bestellung nachschlagen, zurückgeben
 return new Order(Id: message.OrderId, ...);
 }
}

Workflows verbinden Executors zu gerichteten Graphen mit einem Fluent Builder. Das Framework übernimmt die Ausführung, den Datenfluss zwischen Schritten und die Fehlerfortpflanzung.

Sie können modellieren:

Sequentielle Ketten (Schritt A → Schritt B → Schritt C)
Paralleles Fan-out/Fan-in (Agenten A, B, C parallel ausführen, Ergebnisse aggregieren)
Bedingte Verzweigung
Human-in-the-Loop-Genehmigungen (Workflow pausieren, auf externes Signal warten)

Der In-Memory-Runner für lokale Entwicklung

Der Einstieg ist schnell:

dotnet add package Microsoft.Agents.AI
dotnet add package Microsoft.Agents.AI.Workflows

Das Kernpaket enthält einen leichtgewichtigen In-Process-Runner. Keine externen Abhängigkeiten, keine Datenbank, keine Azure-Ressourcen. Funktioniert hervorragend für lokale Entwicklung und Unit-Tests.

Dauerhaftigkeit mit Durable Task hinzufügen

Wenn ein Workflow Prozessneustarts überleben muss — weil er lang läuft, weil er Human-in-the-Loop-Schritte hat, weil er auf viele parallele Agent-Aufrufe verteilt wird — reicht der In-Memory-Runner nicht aus.

MAFs Durable Task-Integration speichert den Workflow-Zustand in Azure Storage. Wenn der Prozess neu startet, wird der Workflow von dort fortgesetzt, wo er aufgehört hat. Das Programmiermodell bleibt gleich; Sie tauschen nur den Runner aus.

dotnet add package Microsoft.Agents.AI.Workflows.DurableTask

Dieselben Executors, derselbe Workflow-Graph — gesichert durch dauerhaften Zustand.

Azure Functions-Hosting

Die dritte Schicht ist das Azure Functions-Hosting. Ihr Workflow wird zu einer Function-App: Lösen Sie den Workflow über einen HTTP-Endpoint aus, und die dauerhafte Laufzeit kümmert sich um Skalierung, Zustand und Zuverlässigkeit.

Das bedeutet, dass ein Multi-Agent-Workflow mit parallelen Aufrufen, bedingten Verzweigungen und menschlichen Genehmigungen über eine serverlose Functions-Umgebung skalieren kann, ohne benutzerdefinierte Zustandsverwaltung.

Warum das wichtig ist

Die Kombination ist bedeutsam für echte KI-Systeme:

Parallele Agent-Aufrufe — gleichzeitig auf mehrere spezialisierte Agenten verteilen ohne Blockierung, Ergebnisse aggregieren wenn alle abgeschlossen sind
Lang laufende Prozesse — Workflows, die menschliche Genehmigung oder externe Ereignisse beinhalten, können über Stunden oder Tage pausieren und fortgesetzt werden
Skalierung — Azure Functions skaliert die Ausführung horizontal; das Durable Task-Framework koordiniert den parallelen Zustand

Wenn Sie MAF-Workflows über einfache lokale Demos hinaus erstellen, ist dies der Weg zur produktionsreifen Ausführung.

Originalbeitrag: Durable Workflows in the Microsoft Agent Framework

Hör auf, eine kämpfende Abhängigkeit zu bombardieren: Retry-Muster für Azure Functions + Service Bus

Emiliano Montesdeoca — Thu, 21 May 2026 00:00:00 +0000

So wird ein behebbarer Fehler zu einem Ausfall in einer Functions-Anwendung: Eine Abhängigkeit beginnt zu timeoutn, jede Functions-Instanz wiederholt sofort und unbegrenzt, die Abhängigkeit wird mit Hunderten gleichzeitiger fehlgeschlagener Anfragen bombardiert, und was als vorübergehender Hickup begann, wird zu einem systemweiten Gegendruck-Ereignis.

Sie kennen diese Geschichte wahrscheinlich. Azure Functions skaliert schnell — das ist der ganze Sinn. Aber “schnell skalieren” und “sofort wiederholen” zusammen können Fehler dramatisch verschlimmern.

Zwei Muster helfen. Exponential Backoff und Circuit Breaker. Beide werden jetzt nativ für Service Bus-ausgelöste Azure Functions unterstützt.

Zwei Muster, Verschiedene Rollen

Diese Muster ergänzen sich, sind keine Alternativen:

Exponential Backoff beantwortet: Wann soll ich es erneut versuchen? Es erhöht die Verzögerung zwischen Wiederholungsversuchen, damit eine Abhängigkeit Zeit hat, sich zu erholen. Auf Nachrichtenebene, Taktung des Retry-Timings.

Circuit Breaker beantwortet: Soll ich diese Abhängigkeit gerade überhaupt aufrufen? Er stoppt wiederholte Aufrufe an eine ungesunde Abhängigkeit, nachdem ein Fehlerschwellenwert erreicht wurde, und testet dann vorsichtig nach einer Abkühlungsperiode. Auf Systemebene, Verhinderung von Retry-Stürmen.

Sie wollen beide. Backoff kümmert sich um das Retry-Timing pro Nachricht. Circuit Breaker kümmert sich um aggregierte Gesundheitsentscheidungen.

Warum Das Besonders für Service Bus Wichtig Ist

Die Warteschlange absorbiert Burst-Traffic, was gut ist. Aber ohne Kontrollen kann die Warteschlange wachsen, während Worker weiterhin Rechenleistung für Aufrufe verschwenden, die fehlschlagen werden. Poison Messages bleiben länger aktiv als sie sollten. Heiße Partitionen oder begrenzte Downstream-Kapazität erzeugen Kaskadenprobleme.

Das sicherere Design:

Vorübergehenden Fehler erkennen
Den nächsten Versuch mit Exponential Backoff verzögern
Aufrufe an die Abhängigkeit stoppen, wenn ein Fehlerschwellenwert erreicht wird (Schaltkreis offen)
Nach einer Abkühlungsperiode vorsichtig fortfahren (Schaltkreis-Sonde)
Nicht wiederherstellbare Arbeit in Dead-Letter oder einen Quarantänepfad verschieben

Wie die Native Unterstützung Aussieht

Die neue Unterstützung integriert sich mit dem bestehenden Azure Functions-Host-Modell — keine zusätzlichen Bibliotheken, keine benutzerdefinierten Implementierungen. Die Konfiguration geht in Ihre host.json:

{
 "extensions": {
 "serviceBus": {
 "messageHandlerOptions": {
 "maxRetryCount": 5,
 "retryPolicy": {
 "mode": "exponentialBackoff",
 "minBackoff": "00:00:02",
 "maxBackoff": "00:05:00",
 "maxRetryCount": 5
 }
 }
 }
 }
}

Die Circuit-Breaker-Konfiguration legt den Fehlerschwellenwert und das Reset-Intervall fest, damit ungesunde Abhängigkeiten während der Wiederherstellung nicht bombardiert werden.

Abgedeckte Sprachen

Das ist nicht nur für .NET. Das Feature deckt dotnet, JavaScript, TypeScript und Python ab — den vollständigen Satz der vom Service Bus-Trigger in Azure Functions unterstützten Sprachen.

Fazit

Retry-Muster sind nicht aufregend zu konfigurieren, bis zum ersten Mal ein Downstream-Ausfall dazu führt, dass Ihre Functions das Problem verschlimmern, anstatt angemessen zu degradieren. Diese proaktiv einzurichten ist günstig. Sie während eines Incidents nachzurüsten nicht.

Originalbeitrag: Exponential backoff and circuit breaker for Service Bus-triggered Azure Functions

MCP Apps bekommen eine Fluent API — Erstelle reichhaltige AI-Tool-UIs in .NET in drei Schritten

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

Dieser Beitrag wurde automatisch übersetzt. Die Originalversion finden Sie hier.

MCP-Tools sind großartig, um AI-Agenten Fähigkeiten zu geben. Aber was, wenn dein Tool dem Benutzer etwas zeigen muss — ein Dashboard, ein Formular, eine interaktive Visualisierung? Genau dafür gibt es MCP Apps, und sie sind jetzt viel einfacher zu erstellen.

Lilian Kasem vom Azure SDK-Team hat die neue Fluent-Konfigurations-API vorgestellt für MCP Apps auf .NET Azure Functions, und es ist die Art von Verbesserung der Entwicklererfahrung, bei der man sich fragt, warum es nicht schon immer so einfach war.

Was sind MCP Apps?

MCP Apps erweitern das Model Context Protocol, indem sie Tools eigene UI-Views, statische Assets und Sicherheitskontrollen mitgeben können. Anstatt nur Text zurückzugeben, kann dein MCP-Tool vollständige HTML-Erlebnisse rendern — interaktive Dashboards, Datenvisualisierungen, Konfigurationsformulare — alles von AI-Agenten aufrufbar und den Benutzern durch MCP-Clients präsentiert.

Der Haken war, dass das manuelle Verkabeln all dieser Dinge tiefes Wissen über die MCP-Spezifikation erforderte: ui://-URIs, spezielle MIME-Types, Metadaten-Koordination zwischen Tools und Ressourcen. Nicht schwer, aber fummellig.

Die Fluent API in drei Schritten

Schritt 1: Definiere deine Funktion. Ein standardmäßiges Azure Functions MCP-Tool:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Schritt 2: Mach sie zur MCP App. In deinem Programm-Startup:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Schritt 3: Füge deine HTML-View hinzu. Erstelle assets/hello-app.html mit der UI, die du brauchst.

Das war’s. Die Fluent API kümmert sich um die gesamte MCP-Protokoll-Plumbing — generiert die synthetische Ressourcen-Funktion, setzt den korrekten MIME-Type und injiziert die Metadaten, die dein Tool mit seiner View verbinden.

Die API-Oberfläche ist gut durchdacht

Ein paar Dinge, die mir besonders gefallen:

View-Quellen sind flexibel. Du kannst HTML von Dateien auf der Festplatte servieren oder Ressourcen direkt in deine Assembly einbetten für eigenständige Deployments:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

CSP ist komponierbar. Du erlaubst explizit die Origins, die deine App braucht, nach dem Prinzip der minimalen Berechtigung. Rufe WithCsp mehrmals auf und die Origins akkumulieren sich:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Sichtbarkeitskontrolle. Du kannst ein Tool nur für das LLM sichtbar machen, nur für die Host-UI oder für beides. Du willst ein Tool, das nur UI rendert und nicht vom Modell aufgerufen werden soll? Kein Problem:

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

Erste Schritte

Füge das Preview-Paket hinzu:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

Wenn du bereits MCP-Tools mit Azure Functions baust, ist das nur ein Paket-Update. Der MCP Apps Quickstart ist der beste Einstiegspunkt, wenn du neu im Konzept bist.

Zusammenfassung

MCP Apps sind eine der spannendsten Entwicklungen im AI-Tooling-Bereich — Tools, die nicht nur Dinge tun, sondern den Benutzern auch Dinge zeigen können. Die Fluent API entfernt die Protokollkomplexität und lässt dich auf das Wesentliche konzentrieren: die Logik deines Tools und seine Oberfläche.

Lies den vollständigen Beitrag für die komplette API-Referenz und Beispiele.

Verbinde deine MCP-Server auf Azure Functions mit Foundry Agents — So geht's

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

Dieser Beitrag wurde automatisch übersetzt. Die Originalversion finden Sie hier.

Das liebe ich am MCP-Ökosystem: Du baust deinen Server einmal, und er funktioniert überall. VS Code, Visual Studio, Cursor, ChatGPT — jeder MCP-Client kann deine Tools entdecken und nutzen. Jetzt fügt Microsoft einen weiteren Konsumenten zu dieser Liste hinzu: Foundry-Agenten.

Lily Ma vom Azure SDK-Team hat einen praktischen Leitfaden veröffentlicht zur Verbindung von MCP-Servern auf Azure Functions mit Microsoft Foundry-Agenten. Wenn du bereits einen MCP-Server hast, ist das reiner Mehrwert — kein Neuaufbau nötig.

Warum diese Kombination Sinn macht

Azure Functions bietet dir skalierbare Infrastruktur, integrierte Authentifizierung und Serverless-Abrechnung für das Hosting von MCP-Servern. Microsoft Foundry bietet dir AI-Agenten, die denken, planen und handeln können. Beides zu verbinden bedeutet, dass deine benutzerdefinierten Tools — Datenbankabfragen, Business-API-Aufrufe, Validierungslogik — zu Fähigkeiten werden, die Enterprise-AI-Agenten autonom entdecken und nutzen können.

Der Kernpunkt: Dein MCP-Server bleibt gleich. Du fügst einfach Foundry als weiteren Konsumenten hinzu. Die gleichen Tools, die in deinem VS Code-Setup funktionieren, treiben jetzt einen AI-Agenten an, mit dem dein Team oder deine Kunden interagieren.

Authentifizierungsoptionen

Hier liefert der Post echten Mehrwert. Vier Authentifizierungsmethoden je nach Szenario:

Methode	Anwendungsfall
Schlüsselbasiert (Standard)	Entwicklung oder Server ohne Entra-Auth
Microsoft Entra	Produktion mit verwalteten Identitäten
OAuth Identity Passthrough	Produktion, bei der sich jeder Benutzer einzeln authentifiziert
Ohne Authentifizierung	Entwicklung/Tests oder nur öffentliche Daten

Für die Produktion ist Microsoft Entra mit Agentenidentität der empfohlene Weg. OAuth Identity Passthrough ist für Fälle, in denen der Benutzerkontext wichtig ist — der Agent fordert Benutzer zur Anmeldung auf, und jede Anfrage trägt das eigene Token des Benutzers.

Einrichtung

Der allgemeine Ablauf:

Deploye deinen MCP-Server auf Azure Functions — Beispiele verfügbar für .NET, Python, TypeScript und Java
Aktiviere die integrierte MCP-Authentifizierung auf deiner Function App
Hole deine Endpoint-URL — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
Füge den MCP-Server als Tool in Foundry hinzu — navigiere zu deinem Agenten im Portal, füge ein neues MCP-Tool hinzu, gib Endpoint und Credentials an

Dann teste es im Agent Builder Playground, indem du einen Prompt sendest, der eines deiner Tools auslöst.

Meine Einschätzung

Die Composability-Geschichte wird hier richtig stark. Baue deinen MCP-Server einmal in .NET (oder Python, TypeScript, Java), deploye ihn auf Azure Functions, und jeder MCP-kompatible Client kann ihn nutzen — Coding-Tools, Chat-Apps und jetzt Enterprise-AI-Agenten. Das ist ein „einmal schreiben, überall nutzen"-Muster, das tatsächlich funktioniert.

Speziell für .NET-Entwickler macht die Azure Functions MCP-Erweiterung das unkompliziert. Du definierst deine Tools als Azure Functions, deployest sie, und du hast einen produktionsreifen MCP-Server mit der gesamten Sicherheit und Skalierung, die Azure Functions bietet.

Zusammenfassung

Wenn du MCP-Tools auf Azure Functions betreibst, ist die Verbindung mit Foundry-Agenten ein schneller Gewinn — deine benutzerdefinierten Tools werden zu Enterprise-AI-Fähigkeiten mit korrekter Authentifizierung und ohne Code-Änderungen am Server selbst.

Lies den vollständigen Leitfaden für Schritt-für-Schritt-Anleitungen zu jeder Authentifizierungsmethode, und sieh dir die detaillierte Dokumentation für Produktions-Setups an.