Multi-Agent | The .NET Blog

Das Handoff-Muster: Wenn Ein Agent Nicht Ausreicht

Emiliano Montesdeoca — Mon, 01 Jun 2026 00:00:00 +0000

Irgendwann überwächst jedes Multi-Agent-System einen einfachen Router. Das erste Anzeichen ist meist, wenn ein Spezialistenagent eine Folgefrage stellen muss oder mitten im Zug erkennt, dass ein anderer Agent weitermachen sollte. Eine feste Pipeline scheitert dort. Ein Ein-Schuss-Router scheitert dort.

Genau das ist das Problem, für das das Handoff-Orchestrierungsmuster in Microsoft Agent Framework konzipiert wurde.

Wie Handoff Funktioniert

Der Entwickler deklariert einen Graphen: Hier sind die Agenten, hier sind die Kanten zwischen ihnen. Das Framework erledigt den Rest — es synthetisiert pro ausgehende Kante ein Handoff-Tool und injiziert es in jeden Agenten. Wenn ein Agent entscheidet, die Kontrolle abzugeben, ruft er das Tool auf. Das Framework setzt die Topologie durch.

Drei Dinge unterscheiden das von einfachem gegenseitigen Aufrufen der Agenten:

Ein gemeinsames Transkript — der empfangende Agent sieht den gesamten Gesprächsverlauf. Kein Neustart von Null.
Topologiedurchsetzung — ein Agent kann nur an deklarierte Ziele übergeben. Routing-Bugs werden beim Erstellen erkannt, nicht in der Produktion.
Natürliche Beendigung — wenn der aktive Agent seinen Zug beendet, ohne ein Handoff-Tool aufzurufen, gibt der Workflow an den Benutzer ab. Kein Polling, keine expliziten Exit-Bedingungen.

Ein Minimales Beispiel

In .NET sieht das Erstellen eines Handoff-Workflows so aus:

using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Workflows;

AIAgent triage = chatClient.AsAIAgent(
 instructions: "Route to the right specialist.",
 name: "Triage");

AIAgent billing = chatClient.AsAIAgent(
 instructions: "Handle billing questions.",
 name: "Billing");

AIAgent tech = chatClient.AsAIAgent(
 instructions: "Handle technical support.",
 name: "Tech");

var workflow = HandoffWorkflow.Create()
 .Add(triage, targets: [billing, tech])
 .Add(billing, targets: [triage])
 .Add(tech, targets: [triage, billing]);

Triage kann an jeden Spezialisten senden. Beide Spezialisten können zurück zu Triage senden. Der Graph ist azyklisch-freundlich, unterstützt aber Rückkanten wenn Sie sie brauchen (“Ich brauche mehr Informationen” → zurück zur Recherche).

Wann Handoff Verwenden (und Wann Nicht)

Handoff ist eine gute Wahl wenn:

Ownership sich mitten im Gespräch ändern kann — ein Agent erkennt möglicherweise, dass er der falsche Spezialist ist
Rückkanten wichtig sind — Sie müssen möglicherweise einen früheren Schritt erneut aufsuchen, ohne neu zu starten
Routing-Entscheidungen unscharf sind — die Entscheidung zum Handoff ist kontextuell und vom Modell besser getroffen als durch typisierte Prädikate

Es ist nicht die richtige Wahl wenn:

Ihre Pipeline fest und sequentiell ist — verwenden Sie dafür den Sequential-Workflow
Jeder Schritt unabhängig ist — Agenten, die ein Transkript teilen, wo nur einer davon es brauchte, ist nur Rauschen
Sie strenge Verarbeitungsgarantien benötigen — der Nichtdeterminismus des modellgesteuerten Routings ist nicht das, was Sie wollen

Rückkanten und Human-in-the-Loop

Eine der interessanteren Formen, die Handoff ermöglicht, sind echte Rückkanten. Ein Agent kann entscheiden “Ich habe nicht genug Informationen” und zu einem Rechercheschritt zurückrouten, nicht mit einer harkodierten Schleife, sondern weil das Modell entscheidet, dass es der richtige Schritt ist.

Human-in-the-Loop-Interaktionen komponieren sich ebenfalls natürlich. Wenn ein Spezialist Benutzereingaben benötigt, gibt der Workflow über die Standard-Zugschleife zurück an den Benutzer, sammelt die Antwort und setzt mit vollständigem Kontext fort. Der Agent hat die Konversation nie verloren.

Fazit

Handoff ist eines dieser Muster, das einfach klingt, aber viel ermöglicht, sobald man es verinnerlicht hat: dezentrales Routing, gemeinsamer Kontext, erzwungene Topologie, natürliche Beendigung. Es ist der richtige nächste Schritt, wenn Ihre Agenten anfangen zu sagen “eigentlich sollte das jemand anderes übernehmen.”

Lesen Sie den vollständigen Durchgang im Originalbeitrag: A Tour of the Handoff Orchestration Pattern

Echtzeit-Multi-Agent-UIs Bauen, Die Sich Nicht Wie eine Black Box Anfühlen

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

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

Hier ist das Ding mit Multi-Agent-Systemen: Sie sehen in Demos unglaublich aus. Drei Agenten, die Arbeit weiterreichen, Probleme lösen, Entscheidungen treffen. Dann versuchst du es echten Benutzern zu zeigen und… Stille. Ein drehender Ladeindikator. Keine Ahnung, welcher Agent was macht oder warum das System pausiert ist. Das ist kein Produkt — das ist ein Vertrauensproblem.

Das Microsoft Agent Framework Team hat gerade einen fantastischen Walkthrough veröffentlicht, wie man MAF-Workflows mit AG-UI kombiniert — einem offenen Protokoll zum Streamen von Agent-Ausführungsereignissen an ein Frontend über Server-Sent Events. Und ehrlich gesagt? Das ist genau die Brücke, die uns gefehlt hat.

Warum das für .NET-Entwickler wichtig ist

Wenn du KI-gestützte Apps baust, bist du wahrscheinlich schon an diese Wand gestoßen. Deine Backend-Orchestrierung funktioniert super — Agenten übergeben aneinander, Tools feuern, Entscheidungen werden getroffen. Aber das Frontend hat keine Ahnung, was hinter den Kulissen passiert. AG-UI löst das, indem es ein Standardprotokoll zum Streamen von Agent-Events definiert (denk an RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_*) direkt an deine UI-Schicht über SSE.

Die Demo ist ein Kundenservice-Workflow mit drei Agenten: ein Triage-Agent, der Anfragen weiterleitet, ein Erstattungs-Agent für Geldangelegenheiten, und ein Bestell-Agent für Austauschvorgänge. Jeder Agent hat seine eigenen Tools, und die Handoff-Topologie ist explizit definiert — kein “finde es aus dem Prompt heraus”-Vibe.

Die Handoff-Topologie ist der eigentliche Star

Was mir aufgefallen ist, ist wie HandoffBuilder dir erlaubt, einen gerichteten Routing-Graphen zwischen Agenten zu deklarieren:

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

Jedes add_handoff erstellt eine gerichtete Kante mit einer natürlichsprachlichen Beschreibung. Das Framework generiert Handoff-Tools für jeden Agenten basierend auf dieser Topologie. Routing-Entscheidungen basieren also auf deiner Orchestrierungsstruktur, nicht nur darauf, was das LLM gerade für richtig hält. Das ist ein riesiger Gewinn für die Produktionszuverlässigkeit.

Human-in-the-Loop, das tatsächlich funktioniert

Die Demo zeigt zwei Unterbrechungsmuster, die jede echte Agent-App braucht:

Tool-Genehmigungs-Unterbrechungen — wenn ein Agent ein Tool aufruft, das mit approval_mode="always_require" markiert ist, pausiert der Workflow und sendet ein Event. Das Frontend rendert ein Genehmigungs-Modal mit dem Tool-Namen und den Argumenten. Keine Token-verbrennenden Retry-Schleifen — einfach ein sauberer Pause-Genehmigung-Fortsetzen-Ablauf.

Informationsanfrage-Unterbrechungen — wenn ein Agent mehr Kontext vom Benutzer braucht (wie eine Bestell-ID), pausiert er und fragt nach. Das Frontend zeigt die Frage an, der Benutzer antwortet, und die Ausführung wird genau dort fortgesetzt, wo sie aufgehört hat.

Beide Muster werden als Standard-AG-UI-Events gestreamt, sodass dein Frontend keine agenten-spezifische Logik braucht — es rendert einfach jedes Event, das über die SSE-Verbindung kommt.

Die Anbindung ist überraschend einfach

Die Integration zwischen MAF und AG-UI ist ein einziger Funktionsaufruf:

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

Die workflow_factory erstellt einen frischen Workflow pro Thread, sodass jede Konversation isolierten State bekommt. Der Endpoint übernimmt die gesamte SSE-Verkabelung automatisch. Wenn du bereits FastAPI nutzt (oder es als leichte Schicht hinzufügen kannst), ist das praktisch ohne Reibungsverluste.

Meine Einschätzung

Für uns .NET-Entwickler ist die sofortige Frage: „Geht das auch in C#?" Das Agent Framework ist für .NET und Python verfügbar, und das AG-UI-Protokoll ist sprachunabhängig (es ist nur SSE). Obwohl diese spezifische Demo Python und FastAPI verwendet, lässt sich das Muster direkt übertragen. Du könntest eine ASP.NET Core Minimal API mit SSE-Endpoints nach dem gleichen AG-UI-Event-Schema aufbauen.

Die wichtigere Erkenntnis ist, dass Multi-Agent-UIs zu einem erstklassigen Thema werden — nicht mehr nur ein Nachgedanke. Wenn du irgendetwas baust, wo Agenten mit Menschen interagieren — Kundenservice, Genehmigungs-Workflows, Dokumentenverarbeitung — dann ist diese Kombination aus MAF-Orchestrierung und AG-UI-Transparenz das Muster, dem man folgen sollte.

Zusammenfassung

AG-UI + Microsoft Agent Framework gibt dir das Beste aus beiden Welten: robuste Multi-Agent-Orchestrierung im Backend und Echtzeit-Transparenz im Frontend. Keine Black-Box-Agent-Interaktionen mehr.

Schau dir den vollständigen Walkthrough und das AG-UI-Protokoll-Repository an, um tiefer einzutauchen.

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.