Agent-Framework | The .NET Blog

Microsoft Foundry April 2026: Foundry Local GA, GPT-5.5, CodeAct mit Hyperlight

Emiliano Montesdeoca — Tue, 02 Jun 2026 00:00:00 +0000

Ein geschäftiger Monat für Microsoft Foundry. Hier sind die wichtigsten Ankündigungen.

Foundry Local ist Allgemein Verfügbar

Foundry Local — Microsofts plattformübergreifende lokale KI-Laufzeit — wechselt von der Vorschau zu GA auf Windows, macOS (Apple Silicon) und Linux x64. Produktionsreife lokale Modellinferenz mit einem entwicklerfreundlichen SDK. Version 1.1 fügt Transkriptions-, Embeddings- und Responses-API-Unterstützung hinzu.

GPT-5.5

Das neueste Modell der GPT-5-Familie ist jetzt in Foundry verfügbar. Standardquota für Tier 5- und Tier 6-Abonnements. Wenn Sie mit früheren GPT-5-Varianten gearbeitet haben, lohnt es sich, dies für Ihre Anwendungsfälle zu evaluieren.

Agent Framework Tracing in Foundry

Diesen Monat werden zwei Tracing-Funktionen in der Vorschau bereitgestellt:

Microsoft Agent Framework Tracing — MAF-Agenten können jetzt OpenTelemetry-Traces in Foundry ausgeben. Debuggen Sie das Agentenverhalten, verfolgen Sie die mehrstufige Ausführung, zeigen Sie Latenz und Fehler über Tool-Aufrufe hinweg an. Dies schließt eine echte Lücke: zu wissen, was Ihr Agent tatsächlich getan hat in der Produktion, nicht nur, was er zurückgegeben hat.

Hosted-Agent-Tracing — Sitzungen, Tool-Aufrufe und Ausführungsschritte von gehosteten Agenten erscheinen ebenfalls in Foundry-Traces. Dieselbe Observability-Geschichte erstreckt sich auf die gehostete Ebene.

CodeAct mit Hyperlight (Alpha)

Dies ist die technisch interessanteste Ergänzung: Agent Framework kann jetzt Python-Code in Hyperlight-Micro-VMs ausführen.

CodeAct ist das Muster, bei dem ein Agent Python-Code als Tool generiert und ausführt. Die offensichtliche Sorge ist die Sicherheit — Sie führen vom Modell generierten Code aus. Hyperlights Micro-VMs bieten Isolation auf Prozessebene mit nahezu nativer Startzeit, was sandboxed Code-Ausführung ohne den Overhead vollständiger Container oder VMs praktisch macht.

Für agentische Workflows, bei denen Code-Ausführung notwendig ist, ist dies eine erhebliche Sicherheitsverbesserung gegenüber dem Ausführen von Code im Host-Prozess.

Agent Monitoring Dashboard (Vorschau)

Ein einheitliches Betriebs-Dashboard, das Token-Nutzung, Latenz, Ausführungserfolgsrate und Evaluator-Scores in einer Ansicht kombiniert. Der Unterschied zu regulären Observability-Dashboards: Es enthält Evaluierungsergebnisse zusammen mit Betriebsmetriken, sodass Sie “der Agent ist langsamer” mit “Evaluator-Scores sind gesunken” korrelieren können — oder bestätigen, dass sie nicht zusammenhängen.

Benutzerdefinierte Evaluatoren für Kontinuierliche Evaluierung (Vorschau)

Sie können jetzt eigene code- oder prompt-basierte Evaluatoren in kontinuierliche Evaluierungspipelines einbringen. Bisher war die kontinuierliche Evaluierung auf integrierte Evaluatoren beschränkt. Benutzerdefinierte Evaluatoren ermöglichen es Ihnen, teamspezifische Qualitätskriterien in Ihrer Produktions-Überwachungsschleife durchzusetzen.

Agenteninventar in der Steuerungsebene

Die Operate-Ansicht der Foundry-Steuerungsebene zeigt jetzt alle unterstützten Agenten über ein Abonnement hinweg: Foundry-Agenten, Azure SRE Agent, Logic Apps-Agentenschleifen und registrierte benutzerdefinierte Agenten. Eine Ansicht, um zu verstehen, was bereitgestellt ist und wo.

Originalbeitrag: What’s new in Microsoft Foundry | April 2026

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

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

Ihr Lokaler MAF-Agent Hat Jetzt ein Produktions-Zuhause

Emiliano Montesdeoca — Sat, 30 May 2026 00:00:00 +0000

Einen Agenten lokal zum Laufen zu bringen ist der spaßige Teil. Der knifflige Teil ist alles, was danach kommt: es ohne Nervenzerreißen zu deployen, Sitzungen zu verwalten, Identität einzurichten, Observabilität zu verkabeln. Das bedeutet normalerweise viel benutzerdefinierte Infrastruktur.

Foundry Hosted Agents hat den Großteil dieser Infrastruktur für Microsoft Agent Framework (MAF)-Benutzer gerade beseitigt.

Was Foundry Hosted Agents Wirklich Tut

Wenn Sie einen MAF-Agenten in Foundry Hosted Agents deployen, übernimmt die Plattform eine überraschend lange Liste von Dingen, die Sie sonst selbst bauen müssten:

Skalierung auf null — Ihr Agent kostet nichts im Leerlauf und fährt automatisch wieder hoch
Pro-Sitzung VM-isolierte Sandboxes — jede Benutzersitzung bekommt ihre eigene Sandbox mit Dateisystempersistenz, die Scale-down-Ereignisse überlebt
Eingebautes Entra ID — jeder Agent erhält seine eigene Identität, um Foundry-Modelle, Toolbox und Azure-Dienste aufzurufen, ohne Geheimnisse im Image
Versionierte Deployments — jedes Deployment ist ein unveränderlicher Snapshot mit Blue/Green- und Canary-Rollout-Unterstützung
Observabilität ohne Konfiguration — APPLICATIONINSIGHTS_CONNECTION_STRING wird zur Laufzeit injiziert, sodass MAFs OpenTelemetry-Traces automatisch in App Insights fließen

Letzteres ist wirklich angenehm. Kein zusätzliches Verkabeln, keine zusätzliche Konfiguration. Traces erscheinen einfach.

Der Code-Unterschied Ist Minimal

Das schätze ich an dieser Integration am meisten. Sie schreiben Ihren Agenten nicht neu. Sie umhüllen ihn einfach:

In .NET:

using Microsoft.Agents.AI.Foundry.Hosting;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddFoundryResponses(agent);

var app = builder.Build();
app.MapFoundryResponses();

app.Run();

In Python:

server = ResponsesHostServer(agent)
server.run()

Das ist alles. Dieselbe Logik, die Sie lokal getestet haben, läuft in der Produktion. Die Plattform umhüllt sie mit der Infrastruktur für Sitzungsverwaltung, Identität und Skalierung.

Zwei Protokolle, Ein Agent

Hosted Agents unterstützen zwei Endpoint-Stile:

Responses (/responses) — OpenAI-kompatibel, verwaltet Gesprächsverlauf und Streaming. Guter Standard für chat-ähnliche Agenten.
Invocations (/invocations) — Sie definieren das Anfrage-/Antwortschema. Gut für nicht-konversationelle Workflows.

Wenn Sie etwas bauen, das wie ein Gespräch aussieht, beginnen Sie mit Responses. Wenn Sie einen API-ähnlichen Agenten bauen, der strukturierte Eingaben nimmt und strukturierte Ausgaben zurückgibt, gibt Ihnen Invocations die Flexibilität.

Der Deployment-Ablauf mit `azd`

Wenn Sie azd up mit einem MAF-Agenten ausführen:

Erstellt optional ein Foundry-Projekt und deployed ein Modell
Packt Ihren Code und pusht ein Image zu Azure Container Registry
Provisioniert Compute aus dem ACR-Image
Weist dem Agenten eine dedizierte Entra ID zu
Stellt einen stabilen Endpoint bereit (https://{project_endpoint}/agents/{agent_name})
Handhabt alles andere von diesem Punkt an

Sitzungen bleiben bis zu 30 Tage bestehen. Inaktives Compute wird nach 15 Minuten deprovisioniert und bei der nächsten Anfrage transparent wiederhergestellt. Aus der Perspektive des Agenten hat sich nichts geändert.

Fazit

Die Distanz zwischen “lokal funktionierend” und “in der Produktion laufend” war für KI-Agenten historisch lang und schmerzhaft. Foundry Hosted Agents + MAF schließt diese Lücke erheblich. Wenn Sie bereits einen lokalen Agenten mit Agent Framework gebaut haben, lohnt es sich, dies heute auszuprobieren.

Das Team sagt, GA kommt bald — dies ist derzeit in Preview. Schauen Sie sich die MAF Hosted Agent Integration-Dokumentation und die .NET-Beispiele an, um loszulegen.

Originalartikel: From Local to Production: Deploy Your Microsoft Agent Framework Agent with Foundry Hosted Agents

Agenten Zu Bauen Ist Der Einfache Teil — Sie Sicher Zu Betreiben Ist Der Schwierige Teil

Emiliano Montesdeoca — Fri, 29 May 2026 00:00:00 +0000

Es gibt ein Muster in der KI-Agenten-Entwicklung, das ich begonnen habe, „Demo-Bedauern" zu nennen. Der Agent funktioniert in Demos hervorragend. Dann fragt jemand: Was passiert, wenn er das falsche Tool aufruft? Was wenn er auf Daten zugreift, auf die er nicht sollte? Wer hat das geprüft?

Microsoft Agent Framework unterstützt Sie beim Aufbau und der Orchestrierung. Agent Governance Toolkit (AGT) deckt den Teil danach ab — Governance, Richtliniendurchsetzung und Prüfbarkeit zur Laufzeit.

Was Jedes Projekt Wirklich Macht

Microsoft Agent Framework (MAF) bietet Ihnen das Programmiermodell: Multi-Agenten-Workflows, A2A-Protokoll-Interoperabilität, Middleware-Hooks, Speicher und verwaltetes Hosting über Foundry Agent Service. Es behandelt Content-Sicherheit auf der Ebene der Modell-Ein-/Ausgabe.

Agent Governance Toolkit (AGT) verbindet sich mit demselben Middleware-Pipeline, um Aktionen zu steuern. Jeder Tool-Aufruf, Ressourcenzugriff und Inter-Agenten-Nachricht wird vor der Ausführung gegen die Richtlinie bewertet. Sub-Millisekunden-Overhead. Keine Sidecars, keine Proxies, keine geänderten Prompts.

Agenten-Aktion --> Richtlinienprüfung --> Erlauben / Ablehnen --> Audit-Log (< 0.1 ms)

Verschiedene Schichten, vollständige Abdeckung, eine Pipeline.

Die Einbindung Ist Nur Middleware Hinzufügen

In Python fügt AGT denselben middleware-Parameter hinzu, den Sie für Protokollierung oder Inhaltsfilter verwenden würden:

agent = Agent(
 client=OpenAIChatClient(model="gpt-5.3"),
 name="Contoso Loan Officer",
 instructions="You are a governed loan assistant.",
 tools=[check_credit_score, get_loan_rates, approve_small_loan],
 middleware=[
 AuditTrailMiddleware(audit_log=audit_log, agent_did="loan-agent"),
 GovernancePolicyMiddleware(evaluator=evaluator, audit_log=audit_log),
 CapabilityGuardMiddleware(allowed_tools=["check_credit_score", "get_loan_rates"]),
 RogueDetectionMiddleware(detector=detector, agent_id="loan-agent"),
 ],
)

In .NET dasselbe Muster via .Use():

var agent = builder.BuildAIAgent(model: "gpt-5.3")
 .Use(new GovernancePolicyMiddleware(evaluator))
 .Use(new CapabilityGuardMiddleware(allowedTools))
 .Use(new AuditTrailMiddleware(auditLog));

Gleicher Agent, gleiche Orchestrierung, gleiche Tools. AGT fügt Governance-Funktionen hinzu, ohne die Agentenlogik zu berühren.

Was Sie Bekommen

GovernancePolicyMiddleware — bewertet jede Aktion gegen deklarative Richtlinienregeln
CapabilityGuardMiddleware — Allowlist, welche Tools ein Agent aufrufen darf (das Tool approve_small_loan ist oben nicht in der Allowlist — absichtlich)
RogueDetectionMiddleware — erkennt anomale Verhaltensmuster zur Laufzeit
AuditTrailMiddleware — Merkle-verkettetes Audit-Log, damit jede Aktion kryptografisch manipulationssicher ist

Letzteres ist für die Compliance wichtig. Eine Merkle-Kette bedeutet: Wenn jemand das Log ändert, bricht die Kette. Das Audit ist der Beweis.

Fünf Branchenszenarien

Das AGT-Repository enthält fünf vollständige End-to-End-Szenarien: Finanzdienstleistungen (Kreditsachbearbeiter), Gesundheitswesen (Patientendaten), Recht (Vertragsüberprüfung), Regierung (Bürgerdienste) und Fertigung (Qualitätskontrolle). Jedes kombiniert echte MAF-Agenten mit echter AGT-Governance-Middleware.

Das sind keine Spielzeug-Demos. Das sind die Szenarien, bei denen Sie in der Produktion tatsächlich Governance benötigen würden.

Fazit

Wenn Sie Agenten entwickeln, die echte Daten berühren, Entscheidungen mit Konsequenzen treffen oder unbeaufsichtigt in der Produktion laufen — Governance ist nicht optional. Die Kombination MAF + AGT gibt Ihnen den vollständigen Stack: Mit Agent Framework bauen, mit AGT verwalten.

Beide Projekte sind Open Source. Der Originalartikel enthält Links zu den vollständigen Code-Beispielen.

Originalbeitrag: Governance at the Speed of Agents: Microsoft Agent Framework and Agent Governance Toolkit, Better Together

A2A v1 ist da: Plattformübergreifende Agentenkommunikation im Microsoft Agent Framework für .NET

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

Dieser Beitrag wurde automatisch übersetzt. Zur Originalversion hier klicken.

A2A v1 ist da: Plattformübergreifende Agentenkommunikation im Microsoft Agent Framework für .NET — das A2A-Protokoll hat gerade v1.0 erreicht, und sowohl das A2A Agent (Client)- als auch das A2A Hosting (Server)-Paket für .NET wurden aktualisiert.

Was A2A v1 wirklich ist

A2A ist ein offenes Interoperabilitätsprotokoll für KI-Agenten, das von einem technischen Lenkungsausschuss mit Vertretern von AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP und ServiceNow unterstützt wird. Das v1-Label bedeutet, dass es nun ein stabiler, produktionsreifer Standard ist. Die SDK- und Agent-Framework-Pakete, die es implementieren, befinden sich noch in der Vorschau, aber das Protokoll selbst ist eingefroren.

v1 verbessert v0.3 mit Multi-Tenant-Unterstützung, signierten Agent Cards für kryptografische Identität, verbesserten Sicherheitsabläufen und einer webalignierten Architektur.

Verbindung zu einem Remote-A2A-Agenten

Ein Remote-A2A-Agent ist in Ihrem Code einfach ein AIAgent — dasselbe RunAsync, dasselbe Streaming, dieselbe Sitzungsverwaltung:

// Entdeckung über bekannte URI
A2ACardResolver resolver = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = await resolver.GetAIAgentAsync();
Console.WriteLine(await agent.RunAsync("What's the weather in Seattle?"));

// Direkte Konfiguration
A2AClient a2aClient = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = a2aClient.AsAIAgent(name: "my-agent", description: "A helpful assistant.");

// Streaming funktioniert genauso
await foreach (var update in agent.RunStreamingAsync("Write a short summary..."))
 Console.Write(update.Text);

Ihren Agenten als A2A-Endpunkt exponieren

Jeder AIAgent, den Sie bereits gebaut haben — auf Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic oder AWS Bedrock — kann mit zwei Zeilen in ASP.NET Core als A2A-Endpunkt exponiert werden:

builder.Services.AddKeyedSingleton<AIAgent>("weather-agent", (sp, _) => ...);
builder.AddA2AServer("weather-agent");

Die Agent Card wird automatisch unter /.well-known/agent-card.json bereitgestellt.

Was das in der Praxis bedeutet

Das stabile v1-Protokoll bedeutet, dass Sie Ihre .NET-Agenten mit Agenten verbinden können, die in Python, Java oder einer anderen Sprache gebaut wurden, ohne sich um Breaking Changes zu sorgen. Die kryptografische Identität in signierten Agent Cards liefert außerdem eine Grundlage für die Vertrauensverifizierung zwischen Agenten.

Den vollständigen Beitrag mit dem kompletten Änderungsprotokoll und den Migrationshinweisen von v0.3 finden Sie hier.

CodeAct im Agent Framework: Wie du die Latenz deines Agenten halbierst

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Zur Originalversion hier klicken.

Es gibt diesen Moment in jedem Agenten-Projekt, wo man auf den Trace schaut und denkt: „Warum dauert das so lange?" Das Modell ist gut. Die Tools funktionieren. Aber es gibt sieben Round Trips für ein Ergebnis, das man in einem Schritt berechnen könnte.

Genau dieses Problem löst CodeAct — und das Agent Framework Team hat soeben Alpha-Unterstützung dafür veröffentlicht mit dem neuen Paket agent-framework-hyperlight.

Was ist CodeAct?

Das CodeAct-Muster ist elegant einfach: Statt dem Modell eine Liste von Tools zu geben und sie einzeln aufrufen zu lassen, gibst du ihm ein einziges execute_code-Tool und lässt es den gesamten Plan als kurzes Python-Programm ausdrücken. Der Agent schreibt den Code einmal, die Sandbox führt ihn aus, und du erhältst ein einziges konsolidiertes Ergebnis zurück.

Ein Fünf-Schritte-Plan, der früher fünf Modell-Turns benötigte, wird zu einem einzigen execute_code-Turn mit einem Python-Script, das deine Tools über call_tool(...) aufruft.

Verdrahtung	Zeit	Tokens
Traditionell	27,81s	6.890
CodeAct	13,23s	2.489
Verbesserung	52,4%	63,9%

Die Sicherheitskomponente: Hyperlight Micro-VMs

Das Paket agent-framework-hyperlight verwendet Hyperlight Micro-VMs. Jeder execute_code-Aufruf erhält eine eigene frisch erstellte Micro-VM — mit eigenem Speicher, ohne Zugriff auf das Host-Dateisystem außer dem, was du explizit mountest. Der Start wird in Millisekunden gemessen. Die Isolierung ist im Grunde kostenlos.

Deine Tools laufen weiterhin auf dem Host. Der modellgenerierte Klebecode läuft in der Sandbox. Das ist die richtige Aufteilung.

Einrichtung

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

Wann CodeAct verwenden (und wann nicht)

CodeAct verwenden, wenn:

Die Aufgabe viele kleine Tool-Aufrufe verkettet (Lookups, Joins, Berechnungen)
Latenz und Token-Kosten wichtig sind
Du starke Isolierung für modellgenerierten Code willst

Beim traditionellen Tool-Calling bleiben, wenn:

Der Agent nur ein oder zwei Tool-Aufrufe pro Turn macht
Jeder Aufruf Nebeneffekte hat, die einzeln genehmigt werden sollen
Tool-Beschreibungen spärlich oder mehrdeutig sind

Jetzt ausprobieren

pip install agent-framework-hyperlight --pre

Den vollständigen Beitrag findest du im Agent Framework Blog.

GPT-5.5 ist da und kommt zu Azure Foundry — Was .NET-Entwickler Wissen Müssen

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Zur Originalversion hier klicken.

Microsoft hat gerade bekannt gegeben, dass GPT-5.5 allgemein in Microsoft Foundry verfügbar ist. Wenn du Agenten auf Azure aufgebaut hast, ist das das Update, auf das du gewartet hast.

Die GPT-5-Progression

GPT-5: vereinte Reasoning und Geschwindigkeit in einem einzigen System
GPT-5.4: stärkeres Multi-Step-Reasoning, frühe agentische Fähigkeiten für Unternehmen
GPT-5.5: tieferes Langkontext-Reasoning, zuverlässigere agentische Ausführung, bessere Token-Effizienz

Was sich wirklich geändert hat

Verbessertes agentisches Coding: GPT-5.5 hält Kontext über große Codebasen hinweg, diagnostiziert Architekturfehler und antizipiert Testanforderungen. Das Modell überlegt, was sonst noch eine Korrektur beeinflusst.

Token-Effizienz: Höherwertigere Ausgaben mit weniger Tokens und weniger Wiederholungen. Direkt niedrigere Kosten und Latenz für Produktions-Deployments.

Langkontext-Analyse: Verarbeitet umfangreiche Dokumente und Multi-Session-Historien ohne den Faden zu verlieren.

Preise

Modell	Eingabe ($/M Tokens)	Gecachte Eingabe	Ausgabe ($/M Tokens)
GPT-5.5	$5,00	$0,50	$30,00
GPT-5.5 Pro	$30,00	$3,00	$180,00

Warum Foundry wichtig ist

Foundry Agent Service ermöglicht es, Agenten in YAML zu definieren oder sie mit Microsoft Agent Framework, GitHub Copilot SDK, LangGraph oder OpenAI Agents SDK zu verbinden — und sie als isolierte gehostete Agenten mit persistentem Dateisystem, eigener Microsoft Entra-Identität und Scale-to-zero-Preisen auszuführen.

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "Du bist ein hilfreicher Assistent.", name: "MeinAgent");

Sieh dir die vollständige Ankündigung für alle Details an.

Wo Erinnert sich dein Agent an Dinge? Ein Praxisleitfaden zur Chat-Verlauf-Speicherung

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Zur Originalversion hier klicken.

Beim Aufbau eines KI-Agenten investierst du die meiste Energie in Modell, Tools und Prompts. Die Frage, wo der Gesprächsverlauf lebt, scheint ein Implementierungsdetail — ist aber eine der wichtigsten Architekturentscheidungen, die du treffen wirst.

Sie bestimmt, ob Nutzer Gespräche verzweigen, Antworten rückgängig machen, Sitzungen nach einem Neustart fortsetzen können und ob deine Daten deine Infrastruktur jemals verlassen.

Zwei grundlegende Muster

Service-managed: Der KI-Dienst speichert den Gesprächszustand. Deine App hält eine Referenz und der Dienst fügt automatisch den relevanten Verlauf in jede Anfrage ein.

Client-managed: Deine App verwaltet den vollständigen Verlauf und sendet relevante Nachrichten mit jeder Anfrage. Der Dienst ist zustandslos. Du kontrollierst alles.

Wie Agent Framework das abstrahiert

// C# — funktioniert gleich, unabhängig vom Provider
AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Mein Name ist Alice.", session);
var second = await agent.RunAsync("Wie ist mein Name?", session);

# Python
session = agent.create_session()
first = await agent.run("Mein Name ist Alice.", session=session)
second = await agent.run("Wie ist mein Name?", session=session)

Provider-Schnellreferenz

Provider	Speicherort	Modell	Komprimierung
OpenAI/Azure Chat Completions	Client	N/A	Du
Foundry Agent Service	Service	Linear	Service
Responses API (Standard)	Service	Verzweigend	Service
Anthropic Claude, Ollama	Client	N/A	Du

Wie du die Wahl triffst

Brauchst du Verzweigung oder „Rückgängig"? → Responses API service-managed
Brauchst du vollständige Datensouveränität? → Client-managed mit datenbankgestütztem Provider
Ist es ein einfacher Chatbot? → Service-managed linear reicht
Brauchst du Portabilität zwischen Providern? → Client-managed bietet Portabilität

Lies den vollständigen Beitrag für den vollständigen Entscheidungsbaum.

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.

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.

Background Responses im Microsoft Agent Framework: Keine Timeout-Angst mehr

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Wenn du irgendetwas mit Reasoning-Modellen wie o3 oder GPT-5.2 gebaut hast, kennst du den Schmerz. Dein Agent fängt an, über eine komplexe Aufgabe nachzudenken, der Client wartet, und irgendwo zwischen “das ist okay” und “ist das abgestürzt?” bricht deine Verbindung wegen Timeout ab. Die ganze Arbeit? Weg.

Das Microsoft Agent Framework hat gerade Background Responses ausgeliefert — und ehrlich gesagt, das ist eine dieser Funktionen, die von Anfang an hätte existieren sollen.

Das Problem mit blockierenden Aufrufen

In einem traditionellen Request-Response-Muster blockiert dein Client, bis der Agent fertig ist. Das funktioniert gut für schnelle Aufgaben. Aber wenn du ein Reasoning-Modell bittest, tiefgehende Recherche, mehrstufige Analyse oder einen 20-seitigen Bericht zu erstellen? Da schaust du auf Minuten realer Wartezeit. Während dieses Zeitfensters:

HTTP-Verbindungen können ablaufen
Netzwerkunterbrechungen zerstören die gesamte Operation
Dein Benutzer starrt auf einen Spinner und fragt sich, ob irgendetwas passiert

Background Responses drehen das Ganze um.

Wie Continuation Tokens funktionieren

Anstatt zu blockieren, startest du die Agent-Aufgabe und bekommst ein Continuation Token zurück. Denk daran wie an einen Abholschein in einer Werkstatt — du stehst nicht an der Theke und wartest, du kommst zurück, wenn es fertig ist.

Der Ablauf ist unkompliziert:

Sende deine Anfrage mit AllowBackgroundResponses = true
Wenn der Agent Hintergrundverarbeitung unterstützt, bekommst du ein Continuation Token
Polle nach deinem Zeitplan, bis das Token null zurückgibt — das bedeutet, das Ergebnis ist fertig

Hier ist die .NET-Version:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Pollen bis fertig
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

Wenn der Agent sofort fertig wird (einfache Aufgaben, Modelle die keine Hintergrundverarbeitung brauchen), wird kein Continuation Token zurückgegeben. Dein Code funktioniert einfach — keine spezielle Behandlung nötig.

Streaming mit Wiederaufnahme: die echte Magie

Polling ist gut für Fire-and-Forget-Szenarien, aber was, wenn du Echtzeit-Fortschritt willst? Background Responses unterstützen auch Streaming mit eingebauter Wiederaufnahme.

Jedes gestreamte Update trägt sein eigenes Continuation Token. Wenn deine Verbindung mitten im Stream abbricht, setzt du genau dort fort, wo du aufgehört hast:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Simuliere eine Netzwerkunterbrechung
}

// Genau dort fortsetzen, wo wir aufgehört haben
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

Der Agent verarbeitet serverseitig weiter, unabhängig davon, was mit deinem Client passiert. Das ist eingebaute Fehlertoleranz, ohne dass du Retry-Logik oder Circuit Breaker schreiben musst.

Wann man das tatsächlich verwenden sollte

Nicht jeder Agent-Aufruf braucht Background Responses. Für schnelle Completions fügst du Komplexität ohne Grund hinzu. Aber hier glänzen sie:

Komplexe Reasoning-Aufgaben — mehrstufige Analyse, tiefgehende Recherche, alles was ein Reasoning-Modell wirklich zum Nachdenken bringt
Lange Content-Generierung — detaillierte Berichte, mehrteilige Dokumente, ausführliche Analysen
Unzuverlässige Netzwerke — mobile Clients, Edge-Deployments, instabile Firmen-VPNs
Asynchrone UX-Muster — Aufgabe absenden, etwas anderes machen, Ergebnisse abholen

Für uns .NET-Entwickler, die Enterprise-Apps bauen, ist der letzte Punkt besonders interessant. Denk an eine Blazor-App, in der ein Benutzer einen komplexen Bericht anfordert — du startest die Agent-Aufgabe, zeigst einen Fortschrittsindikator und lässt sie weiterarbeiten. Keine WebSocket-Akrobatik, keine selbstgebaute Queue-Infrastruktur, nur ein Token und eine Poll-Schleife.

Zusammenfassung

Background Responses sind jetzt sowohl in .NET als auch in Python über das Microsoft Agent Framework verfügbar. Wenn du Agenten baust, die mehr als einfaches Q&A machen, lohnt es sich, das in dein Toolkit aufzunehmen. Das Continuation-Token-Muster hält die Dinge einfach und löst gleichzeitig ein sehr reales Produktionsproblem.

Schau dir die vollständige Dokumentation für die komplette API-Referenz und weitere Beispiele an.

Agent-Framework | The .NET Blog

Microsoft Foundry April 2026: Foundry Local GA, GPT-5.5, CodeAct mit Hyperlight

Foundry Local ist Allgemein Verfügbar

GPT-5.5

Agent Framework Tracing in Foundry

CodeAct mit Hyperlight (Alpha)

Agent Monitoring Dashboard (Vorschau)

Benutzerdefinierte Evaluatoren für Kontinuierliche Evaluierung (Vorschau)

Agenteninventar in der Steuerungsebene

Das Handoff-Muster: Wenn Ein Agent Nicht Ausreicht

Wie Handoff Funktioniert

Ein Minimales Beispiel

Wann Handoff Verwenden (und Wann Nicht)

Rückkanten und Human-in-the-Loop

Fazit

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

Die grundlegenden Bausteine

Der In-Memory-Runner für lokale Entwicklung

Dauerhaftigkeit mit Durable Task hinzufügen

Azure Functions-Hosting

Warum das wichtig ist

Ihr Lokaler MAF-Agent Hat Jetzt ein Produktions-Zuhause

Was Foundry Hosted Agents Wirklich Tut

Der Code-Unterschied Ist Minimal

Zwei Protokolle, Ein Agent

Der Deployment-Ablauf mit azd

Fazit

Agenten Zu Bauen Ist Der Einfache Teil — Sie Sicher Zu Betreiben Ist Der Schwierige Teil

Was Jedes Projekt Wirklich Macht

Die Einbindung Ist Nur Middleware Hinzufügen

Was Sie Bekommen

Fünf Branchenszenarien

Fazit

A2A v1 ist da: Plattformübergreifende Agentenkommunikation im Microsoft Agent Framework für .NET

Was A2A v1 wirklich ist

Verbindung zu einem Remote-A2A-Agenten

Ihren Agenten als A2A-Endpunkt exponieren

Was das in der Praxis bedeutet

CodeAct im Agent Framework: Wie du die Latenz deines Agenten halbierst

Was ist CodeAct?

Die Sicherheitskomponente: Hyperlight Micro-VMs

Einrichtung

Wann CodeAct verwenden (und wann nicht)

Jetzt ausprobieren

GPT-5.5 ist da und kommt zu Azure Foundry — Was .NET-Entwickler Wissen Müssen

Die GPT-5-Progression

Was sich wirklich geändert hat

Preise

Warum Foundry wichtig ist

Wo Erinnert sich dein Agent an Dinge? Ein Praxisleitfaden zur Chat-Verlauf-Speicherung

Zwei grundlegende Muster

Wie Agent Framework das abstrahiert

Provider-Schnellreferenz

Wie du die Wahl triffst

Agent Skills in .NET sind jetzt richtig flexibel

Dateibasierte Skills: der Einstiegspunkt

Klassenbasierte Skills: per NuGet ausliefern

Inline Skills: die schnelle Brücke

Script-Genehmigung: Mensch in der Schleife

Warum diese Kombination wichtig ist

Zum Abschluss

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

Warum das für .NET-Entwickler wichtig ist

Die Handoff-Topologie ist der eigentliche Star

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

Die Anbindung ist überraschend einfach

Meine Einschätzung

Zusammenfassung

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

Die Kurzversion

Der Einstieg ist fast unfair einfach

Multi-Agent-Orchestrierung — das ist die echte Sache

Die Features, die am meisten zählen

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

Migration von Semantic Kernel oder AutoGen

Zum Abschluss

Background Responses im Microsoft Agent Framework: Keine Timeout-Angst mehr

Das Problem mit blockierenden Aufrufen

Wie Continuation Tokens funktionieren

Streaming mit Wiederaufnahme: die echte Magie

Der Deployment-Ablauf mit `azd`