KI-Agenten mit dem Microsoft Agent Framework: Praxisleitfaden

Inhalt

Das Microsoft Agent Framework ist Microsofts Open-Source-Framework für KI-Agenten in Python und C#. Es führt die Multi-Agent-Muster von AutoGen mit den Enterprise-Funktionen von Semantic Kernel zusammen und bringt mit, was Agenten im Produktivbetrieb brauchen: Tracing mit OpenTelemetry, Anbindung an Entra ID, Freigaben durch Menschen (Human-in-the-Loop) und Checkpointing für lange laufende Workflows. Dieser Leitfaden erklärt zuerst die Architektur und baut dann einen IT-Helpdesk-Agenten, von den Tools bis zum FastAPI-Endpunkt im Docker-Container.

Warum ist das wichtig? Beeindruckende Demos von Agenten, die komplexe Aufgaben planen, durchdenken und ausführen, kennt inzwischen jeder (zwei davon zeigen wir auf Englisch: mit smolagents und von Grund auf gebaut). Vom Proof of Concept zu einer verlässlichen Anwendung im Produktivbetrieb ist es aber ein weiter Weg. Im Unternehmen reichen gute Prompts und eine durchdachte Agentenschleife nicht. Sie brauchen Zustandsverwaltung, strenge Sicherheit, eine zuverlässige Anbindung von Tools und eine nachvollziehbare Spur dessen, was der Agent wann und warum getan hat.

Viele Frameworks eignen sich hervorragend für schnelle Prototypen, bieten aber kein Gerüst für Produktivsysteme. Observability, Fehlerbehandlung und vor allem lange laufende Aufgaben bleiben den Entwicklern überlassen. Zwischen einer Demo auf dem Laptop und einem Geschäftsprozess, dem man kritische Abläufe anvertraut, klafft deshalb eine große Lücke. Microsoft will sie mit einem einzigen Framework für den gesamten Lebenszyklus eines Agenten schließen, Enterprise-Funktionen inklusive.

Die Architektur des Microsoft Agent Framework: ein Betriebssystem für Agenten

Was das Microsoft Agent Framework besonders macht, versteht man am besten, wenn man es sich als Betriebssystem für KI-Agenten vorstellt. Das klingt nach Clickbait, aber der Vergleich trägt. Ein Betriebssystem stellt die Dienste bereit, die Anwendungen für einen stabilen Betrieb brauchen: Es verwaltet den Speicher, plant Aufgaben ein und gibt Software einen einheitlichen Zugang zur Hardware. Genauso verwaltet das Agent Framework das Gedächtnis eines Agenten (den Zustand), führt seine Programme aus (die Tools) und regelt die Kommunikation mit anderen Systemen (die Workflows).

Das ist eine attraktive Aussicht: Alle nötigen Bausteine stecken in einem Framework, und die Entwickler kümmern sich nur noch um die Logik des Agenten. Ob das Framework dieses Versprechen hält, sehen wir uns jetzt an.

Die vier Kernkomponenten des Microsoft Agent Framework

Das Framework besteht aus vier Komponenten, die zusammenspielen.

1. KI-Agenten sind die eigentlichen "Arbeiter", das "Gehirn" des Systems. Jeder Agent nutzt ein LLM, um auf Basis seiner Anweisungen zu überlegen, zu planen und zu handeln. Microsoft hat diese Agenten als Weiterentwicklung der eigenen Vorgängerprojekte entworfen: Sie verbinden die Multi-Agent-Gesprächsmuster von AutoGen mit dem strukturierten, toolorientierten Ansatz von Semantic Kernel.

2. Tools (AIFunctions) sind die Verbindung des Agenten zur Außenwelt. Statt sich auf fehleranfälliges Parsen von Text zu verlassen, definieren Sie Tools als streng typisierte Python- oder C#-Funktionen. Sie versehen eine normale Funktion mit einem Decorator, und der Agent sieht sie mit ihren Ein- und Ausgaben. Das Framework übersetzt die Absicht des LLM in einen gültigen Funktionsaufruf. Dadurch sind Tools sicherer, berechenbarer und leichter zu debuggen.

3. Workflows verbinden die Agenten, ähnlich wie ein Nervensystem. Mehrstufige Prozesse definieren Sie als Graph, und das ist deutlich mehr als eine einfache, lineare Kette von Agenten. Mit Workflows orchestrieren Sie mehrere Agenten und Tools, bauen Bedingungen ein ("wenn X, dann Y"), führen Aufgaben parallel aus und, besonders wichtig, halten an, bis ein Mensch eine Freigabe erteilt.

4. Die Zustandsverwaltung gibt Agenten ein Gedächtnis. Ohne Gedächtnis ist ein Agent nur ein zustandsloses Tool. Das Framework stellt dafür das Objekt AgentThread bereit, das den gesamten Verlauf und Kontext eines Gesprächs oder einer Aufgabe enthält. Dieses dauerhafte Gedächtnis brauchen Sie für Gespräche über mehrere Runden und für lange laufende Jobs.

Enterprise-Funktionen des Microsoft Agent Framework

Auf den Kernkomponenten bauen Funktionen auf, die für den Einsatz im Unternehmen gedacht sind. Hier will sich das Framework von der Konkurrenz abheben.

1. Observability. Bei jedem Produktivsystem müssen Sie die Frage "Warum hat es das getan?" beantworten können. Das Framework unterstützt von Haus aus OpenTelemetry, den Industriestandard für Tracing und Logging. Sie können jeden Schritt eines Agenten nachverfolgen, von der ersten Überlegung über das aufgerufene Tool bis zum zurückgelieferten Ergebnis. So finden Sie Fehler, prüfen Entscheidungen nach und optimieren die Leistung. Unser Beitrag über LLM-Tracing mit Opik (auf Englisch) stellt ein Open-Source-Tool vor, mit dem Sie solche Traces sammeln und auswerten.

2. Sicherheit und Governance. Das Framework lässt sich mit Diensten wie Azure AI Content Safety verbinden, die schädliche Inhalte filtern (siehe unseren Beitrag über die Inhaltsfilter von Azure OpenAI), und mit Microsoft Entra ID für Authentifizierung und Autorisierung. Besonders gefällt uns, dass Human-in-the-Loop-Workflows fest eingebaut sind. Sie können Agenten so gestalten, dass sie bei heiklen Aktionen anhalten und eine Freigabe einholen, etwa bevor sie eine Zahlung autorisieren, Daten löschen oder eine Nachricht an Kunden schicken. Das letzte Wort hat dann immer ein Mensch. KI kann erstaunliche Dinge, aber meistens soll trotzdem ein Mensch die Kontrolle behalten.

3. Dauerhaftigkeit und lange laufende Aufgaben. Geschäftsprozesse sind nicht immer in Sekunden erledigt. Sie können Stunden oder Tage dauern und müssen Neustarts und Unterbrechungen überstehen. Die Workflows des Frameworks sind darauf ausgelegt. Mit Checkpointing wird der Zustand eines Workflows dauerhaft gespeichert und später wieder aufgenommen. So bauen Sie Agenten, die eine mehrtägige Spesenfreigabe begleiten oder eine Datenmigration über das ganze Wochenende steuern und genau dort weitermachen, wo sie aufgehört haben.

4. Offene Standards und Interoperabilität. Wer sich in eine Unternehmens-IT einfügen will, muss dieselbe Sprache sprechen wie die anderen Systeme. Das Framework bindet bestehende APIs über OpenAPI an (aus denselben OpenAPI-Spezifikationen lassen sich übrigens auch automatisch MCP-Server erzeugen) und unterstützt das Model Context Protocol (MCP). MCP ist ein neuer Standard, um KI-Modelle mit externen Datenquellen und Tools zu verbinden. Agenten auf Basis des Frameworks kommen so an die Informationen, die sie brauchen.

Und schließlich unterstützt das Microsoft Agent Framework .NET vollständig. Damit ist es im Microsoft-Ökosystem ein vollwertiger Bestandteil.

So funktionieren Dauerhaftigkeit und lange laufende Aufgaben

Die Fähigkeit, lange laufende Aufgaben dauerhaft abzusichern, gehört zu den wichtigsten Enterprise-Funktionen des Frameworks. Es lohnt sich, sie genauer zu verstehen. Denken Sie an einen Spielstand. Während ein Agent läuft, liegt sein Zustand (Verlauf, Pläne usw.) im Arbeitsspeicher. Muss er auf einen lange laufenden externen Prozess warten, macht das Framework einen "Schnappschuss" dieses Zustands, speichert ihn an einem dauerhaften Ort und kann den Prozess beenden. Ist das externe Ereignis eingetreten, "lädt das Framework den Spielstand": Es stellt den Zustand des Agenten wieder her, und der Agent macht genau dort weiter, wo er stehen geblieben ist.

Der Ablauf hat drei Phasen:

• Anhalten und Checkpoint: Muss ein Workflow warten, etwa auf eine Freigabe oder einen stundenlangen Datenjob, serialisiert das Framework den gesamten AgentThread des Agenten in ein speicherbares Format wie JSON. Die offizielle Dokumentation nennt das "Checkpointing".

• Dauerhafte Speicherung: Der serialisierte Zustand landet bei einem konfigurierbaren Persistenz-Provider. Im Produktivbetrieb binden Sie eine Datenbank wie Azure Cosmos DB an, die den Zustand außerhalb des Arbeitsspeichers der Anwendung hält.

• Fortsetzen und Wiederherstellen: Kommt ein externer Auslöser (etwa ein API-Aufruf von einem Freigabe-Button), lädt ein neuer Prozess den gespeicherten Zustand aus der Datenbank. Er deserialisiert die Daten und macht daraus wieder ein lebendiges AgentThread-Objekt. Der Agent ist wieder "wach", mit vollem Gedächtnis und Kontext, und bereit für den nächsten Schritt.

Nehmen wir als Beispiel einen Bot für Spesenfreigaben. Eine Mitarbeiterin reicht eine Ausgabe über 500 Dollar ein. Der Agent prüft die Unternehmensrichtlinie und stellt fest, dass die Führungskraft zustimmen muss. Hier beginnt der lange laufende Prozess. Der Workflow des Agenten schickt eine Freigabeanfrage an die Führungskraft und erreicht dann einen Haltepunkt. Das Framework speichert den AgentThread mit den Belegdaten, dem Ergebnis der Richtlinienprüfung und dem aktuellen Status "awaiting_manager_approval" als Checkpoint in einer Datenbank. Stunden später klickt die Führungskraft auf "Freigeben", was einen API-Aufruf auslöst. Der API-Handler lädt den gespeicherten Zustand, stellt den Agenten wieder her und übergibt ihm das Ereignis "approved". Der Agent wacht auf, ruft das Tool für die Zahlungsabwicklung auf und bestätigt der Mitarbeiterin den Abschluss.

Genau diese Fähigkeit, anzuhalten, den Zustand zu sichern und weiterzumachen, macht das Microsoft Agent Framework aus unserer Sicht so interessant.

Wie das Microsoft Agent Framework mit Copilot Studio und Microsoft 365 zusammenhängt

Sie können das Microsoft Agent Framework eigenständig einsetzen. Es ist aber auch ein Grundbaustein von Microsofts übergreifender KI- und Copilot-Strategie.

Das Framework ist Microsofts "Pro-Code"-Engine. Entwickler bauen damit Agenten für den Unternehmenseinsatz, die sich anschließend im gesamten Microsoft-Ökosystem einbinden, verwalten und bereitstellen lassen. So verbindet es individuelle Entwicklung mit den Anwendungen, die Endnutzer täglich verwenden.

So sieht die Verbindung zwischen Microsoft 365 Copilot und dem Agent Framework aus:

• Das Framework ist die Pro-Code-Grundlage für Copilot Studio, Microsofts Low-Code-Plattform zum Erstellen und Anpassen von Copilots. Entwickler bauen mit dem Agent Framework in Python oder C# zustandsbehaftete Agenten mit umfangreicher Geschäftslogik und vielen Tool-Anbindungen. Diese Agenten lassen sich anschließend mit Copilot Studio verbinden und dort verwalten. Die Entwickler kümmern sich um die Logik im Backend, während Fachanwender oder IT-Administratoren die Agenten in der Low-Code-Oberfläche konfigurieren, bereitstellen und überwachen, ohne Code zu schreiben. (Ein Low-Code-Beispiel zeigt unser Beitrag über SharePoint-Listen als Wissensquelle in Copilot Studio.)

Das Agent Framework im Zusammenspiel mit Copilot Studio, Microsoft Foundry (früher Azure AI Foundry) und dem M365 Agents SDK

Praxis: ein IT-Helpdesk-Agent mit dem Microsoft Agent Framework

Jetzt setzen wir das Microsoft Agent Framework praktisch ein und sehen, wie es wirklich funktioniert. Wir bauen einen einfachen, aber praxistauglichen IT-Helpdesk-Agenten, der Zustandsverwaltung, Gespräche über mehrere Runden und Tool-Aufrufe nutzt.

Das Ziel: Unser Agent sortiert IT-Supportanfragen vor. Zuerst prüft er, ob eine Störung bereits bekannt ist, damit keine unnötigen Tickets entstehen. Gibt es keine Störung, sammelt er die nötigen Informationen vom Benutzer und legt ein Support-Ticket an.

Voraussetzungen

Bevor Sie loslegen, richten Sie Folgendes ein:

1. Installieren Sie die nötigen Pakete:

   1pip install agent-framework agent-framework-azure-ai pydantic
   

2. Setzen Sie die Umgebungsvariablen für Azure OpenAI. Der AzureOpenAIResponsesClient braucht Ihren Endpunkt und die Namen Ihrer Bereitstellungen. Folgende Variablen müssen in Ihrer Umgebung gesetzt sein:

   • AZURE_OPENAI_ENDPOINT: Ihr Azure-OpenAI-Endpunkt
   • AZURE_OPENAI_CHAT_DEPLOYMENT_NAME: der Name Ihrer Bereitstellung des Chatmodells in Azure OpenAI
   • AZURE_OPENAI_RESPONSES_DEPLOYMENT_NAME: der Name Ihrer Responses-Bereitstellung in Azure OpenAI
   • AZURE_OPENAI_API_KEY: Ihr API-Schlüssel für Azure OpenAI

Schritt 1: Die Tools definieren (die "Hände" des Agenten)

Zuerst legen wir die Tools an, die unser Agent verwenden kann. Das sind ganz normale Python-Funktionen. Mit typing.Annotated und pydantic.Field beschreiben wir die Parameter, damit das LLM die Funktionen richtig aufruft.

Legen Sie eine Datei tools.py an:

1# tools.py
2import datetime
3from typing import Annotated
4from pydantic import Field
5
6def check_system_status(
7    service_name: Annotated[str, Field(description="The IT service to check, e.g., 'email', 'vpn', 'sharepoint'.")]
8) -> str:
9    """Checks the operational status of a known IT service."""
10    print(f"--- TOOL LOG: Checking status for '{service_name}' ---")
11    known_outages = {"email": "Degraded performance"}
12    status = known_outages.get(service_name.lower(), "Fully operational.")
13    return f"Status for {service_name}: {status}"
14
15def create_support_ticket(
16    user_name: Annotated[str, Field(description="The full name of the user reporting the issue.")],
17    issue_description: Annotated[str, Field(description="A detailed description of the IT issue.")],
18) -> str:
19    """Creates a support ticket in the helpdesk system."""
20    # In einer echten Anwendung stünde hier ein API-Aufruf, etwa an Jira oder ServiceNow
21    ticket_id = f"IT-{int(datetime.datetime.now().timestamp())}"
22    print(f"--- TOOL LOG: Creating ticket {ticket_id} for {user_name} with issue: '{issue_description}' ---")
23    return f"Successfully created ticket {ticket_id}. A technician will be in touch shortly."

Schritt 2: Den Agenten anlegen und ausführen

Als Nächstes definieren wir den Agenten und sprechen mit ihm. Die zentrale Klasse heißt ChatAgent. Wir konfigurieren sie mit einem Client, den Anweisungen und unserer Liste von Tools. Der Agent selbst merkt sich den Gesprächsverlauf zwischen zwei run()-Aufrufen nicht. Dieser Verlauf liegt in einem AgentThread: Wir erzeugen einen mit get_new_thread() und übergeben ihn an jeden Aufruf, der zum selben Gespräch gehört. So entstehen zustandsbehaftete Gespräche über mehrere Runden.

Legen Sie eine Datei main.py an:

1# main.py
2import asyncio
3from agent_framework import ChatAgent
4from agent_framework.azure import AzureOpenAIResponsesClient
5from tools import check_system_status, create_support_ticket
6
7# 1. Client mit den Anmeldedaten der Azure CLI initialisieren
8# Endpunkt und Bereitstellung liest er automatisch aus den Umgebungsvariablen.
9chat_client = AzureOpenAIResponsesClient()
10
11# 2. Agenten anlegen und ihm Anweisungen und Tools mitgeben.
12helpdesk_agent = ChatAgent(
13    chat_client=chat_client,
14    instructions="""You are an enterprise IT Helpdesk assistant.
15    1. First, understand the user's problem and identify the specific IT service.
16    2. Use the `check_system_status` tool to check for outages.
17    3. If there is an outage, inform the user and tell them the team is aware. Do NOT create a ticket.
18    4. If the system is normal, you MUST get the user's name before creating a ticket. Ask for it if you don't have it.
19    5. Once you have the user's name and issue description, use the `create_support_ticket` tool.
20    6. Confirm to the user that a ticket has been created and provide the ticket number.""",
21    tools=[check_system_status, create_support_ticket],
22)
23
24async def run_conversation():
25    print("Agent: Hello! I'm the IT Helpdesk Agent. How can I assist you today?\n")
26
27    # Erste Nachricht des Benutzers
28    user_input_1 = "Hi, my email is not working. I can't send or receive messages."
29    print(f"User: {user_input_1}")
30
31    # Der Thread hält den Gesprächsverlauf über alle Runden.
32    thread = helpdesk_agent.get_new_thread()
33
34    # 'run' auf der Agenteninstanz führt eine Gesprächsrunde aus.
35    # Der Thread wird dabei um diese Runde ergänzt.
36    agent_response_1 = await helpdesk_agent.run(user_input_1, thread=thread)
37    print(f"Agent: {agent_response_1}\n")
38
39    # Zweite Nachricht des Benutzers (simuliert den Fall ohne Störung)
40    # HINWEIS: Um diesen Pfad zu testen, entfernen Sie in tools.py die E-Mail-Störung.
41    # Der Agent fragt dann nach einem Namen.
42    # user_input_2 = "My name is Alice."
43    # print(f"User: {user_input_2}")
44
45    # # Über den Thread kennt der Agent den Kontext der ersten Nachricht.
46    # agent_response_2 = await helpdesk_agent.run(user_input_2, thread=thread)
47    # print(f"Agent: {agent_response_2}\n")
48
49
50if __name__ == "__main__":
51    asyncio.run(run_conversation())

Schritt 3: Debuggen mit der Dev UI des Agent Framework

Mit der eingebauten Dev UI können Sie die Überlegungen des Agenten sehr bequem Schritt für Schritt verfolgen. Wir passen unseren Code so an, dass er sie startet.

1. Die Web-Komponenten installieren

1pip install "agent-framework[web]" uvicorn

2. main.py so ändern, dass der Agent bereitgestellt wird

Ersetzen Sie in main.py den Teil mit run_conversation durch einen Aufruf von serve aus agent_framework.devui.

1# main.py
2import asyncio
3from agent_framework import ChatAgent
4from agent_framework.azure import AzureOpenAIResponsesClient
5from agent_framework.devui import serve  # <-- serve importieren
6from tools import check_system_status, create_support_ticket
7
8# --- Definition des Agenten (dieser Teil bleibt gleich) ---
9chat_client = AzureOpenAIResponsesClient()
10helpdesk_agent = ChatAgent(
11    chat_client=chat_client,
12    instructions="""You are an enterprise IT Helpdesk assistant...""", # Anweisungen hier gekürzt
13    tools=[check_system_status, create_support_ticket],
14)
15# --- Ende der Definition des Agenten ---
16
17# Webanwendung erzeugen und ihr den Agenten übergeben
18serve(entities=[helpdesk_agent], port=8090, auto_open=True)
19
20# Die Konsolenfunktion run_conversation wird nicht mehr gebraucht

Wenn Sie das Skript starten, öffnet sich im Browser unter http://localhost:8090 eine Weboberfläche. Dort chatten Sie mit dem Agenten und sehen live, welche Tools er aufruft und was er antwortet.

Die Dev UI mit einem Helpdesk-Chat und dem Aufruf des Tools check_system_status

Schritt 4: Den Agenten für den Produktivbetrieb bereitstellen

Die Dev UI ist ideal für die lokale Entwicklung und das Debuggen, aber nicht für den Produktivbetrieb gebaut. Damit andere Anwendungen Ihren Agenten nutzen können, stellen Sie ihn über eine standardisierte, skalierbare Web-API bereit. Wir verwenden dafür FastAPI, ein schnelles Python-Webframework, und bauen einen produktionstauglichen Endpunkt.

1. Den API-Endpunkt für den Produktivbetrieb anlegen

Für den Webserver legen wir eine neue Datei api.py an. So bleibt die Logik für den Produktivbetrieb von den Skripten zum lokalen Debuggen getrennt.

Installieren Sie zuerst FastAPI und den Webserver Uvicorn:

1pip install fastapi uvicorn

Legen Sie jetzt api.py an. Die Datei importiert die Bausteine des Agenten und macht den helpdesk_agent über einen API-Endpunkt erreichbar.

1# api.py
2import os
3from fastapi import FastAPI
4from pydantic import BaseModel
5
6# Bausteine der Agentendefinition importieren
7from agent_framework import ChatAgent
8from agent_framework.azure import AzureOpenAIResponsesClient
9from tools import check_system_status, create_support_ticket
10
11# --- Definition des Agenten ---
12# Das ist derselbe Agent, den wir für die DevUI konfiguriert haben.
13# Achten Sie darauf, dass die Umgebungsvariablen für den Produktivbetrieb gesetzt sind.
14chat_client = AzureOpenAIResponsesClient()
15helpdesk_agent = ChatAgent(
16    chat_client=chat_client,
17    instructions="""You are an enterprise IT Helpdesk assistant.
18    1. First, understand the user's problem and identify the specific IT service.
19    2. Use the `check_system_status` tool to check for outages.
20    3. If there is an outage, inform the user and tell them the team is aware. Do NOT create a ticket.
21    4. If the system is normal, you MUST get the user's name before creating a ticket. Ask for it if you don't have it.
22    5. Once you have the user's name and issue description, use the `create_support_ticket` tool.
23    6. Confirm to the user that a ticket has been created and provide the ticket number.""",
24    tools=[check_system_status, create_support_ticket],
25)
26# --- Ende der Definition des Agenten ---
27
28# FastAPI-App erzeugen
29app = FastAPI(
30    title="IT Helpdesk Agent API",
31    description="An API to interact with the Microsoft Agent Framework IT Helpdesk Agent.",
32)
33
34# Request-Modell für unseren API-Endpunkt
35class ChatRequest(BaseModel):
36    message: str
37
38@app.post("/chat")
39async def chat_with_agent(request: ChatRequest):
40    """
41    Receives a user message and returns the agent's response.
42    No thread is passed, so each request starts a new conversation.
43    """
44    response = await helpdesk_agent.run(request.message)
45    return {"response": response}

2. Dateien für die Containerisierung vorbereiten

Als Nächstes bereiten wir die Dateien vor, mit denen die Anwendung in einen Docker-Container verpackt wird.

• requirements.txt

  # requirements.txt
  agent-framework
  agent-framework-azure-ai
  fastapi
  uvicorn
  pydantic
  

• Dockerfile

  Diese Datei startet unsere FastAPI-Anwendung mit Uvicorn.

  1# Offizielles Python-Image als Basis
  2FROM python:3.11-slim
  3
  4WORKDIR /app
  5
  6# Abhängigkeiten kopieren und installieren
  7COPY requirements.txt .
  8RUN pip install --no-cache-dir -r requirements.txt
  9
  10# Anwendungscode kopieren (api.py, tools.py)
  11COPY . .
  12
  13# Port freigeben, auf dem die API läuft
  14EXPOSE 8000
  15
  16# Uvicorn-Server mit der FastAPI-App aus api.py starten
  17CMD ["uvicorn", "api:app", "--host", "0.0.0.0", "--port", "8000"]
  

3. Die API bauen, starten und testen

Mit API und Dockerfile können Sie den Container bauen und starten.

• Docker-Image bauen:

  1docker build -t helpdesk-agent-api .
  

• Container starten. Übergeben Sie Ihre Azure-Zugangsdaten als Umgebungsvariablen.

  1docker run -p 8000:8000 \
  2  -e AZURE_OPENAI_ENDPOINT="YOUR_ENDPOINT" \
  3  -e AZURE_OPENAI_API_KEY="YOUR_API_KEY" \
  4  -e AZURE_OPENAI_CHAT_DEPLOYMENT_NAME="YOUR_CHAT_DEPLOYMENT" \
  5  -e AZURE_OPENAI_RESPONSES_DEPLOYMENT_NAME="YOUR_RESPONSES_DEPLOYMENT" \
  6  helpdesk-agent-api
  

• Mit curl testen. Sobald der Container läuft, öffnen Sie ein neues Terminal und rufen den Endpunkt /chat auf:

  1curl -X POST http://localhost:8000/chat \
  2-H "Content-Type: application/json" \
  3-d '{"message": "Hi, my email is not working."}'
  

Ihr Agent antwortet mit JSON, und damit ist bestätigt, dass die API funktioniert. Den Container können Sie bei jedem Cloud-Dienst betreiben, zum Beispiel in Azure App Service oder Azure Container Apps.

Fazit: Was das Microsoft Agent Framework bietet

Das Microsoft Agent Framework ist ein Werkzeugkasten für KI-Anwendungen im Unternehmen, der auf den Produktivbetrieb ausgerichtet ist. Seine größte Stärke: Es verbindet die forschungsnahen Muster von AutoGen mit der Stabilität, Sicherheit und Struktur, die echte Geschäftsprozesse brauchen.

Als "Betriebssystem" für Agenten übernimmt es Zustandsverwaltung, Observability und lange laufende Aufgaben, damit sich Entwickler auf die Logik des Agenten konzentrieren können. In diesem Leitfaden waren das typisierte Tools, ein ChatAgent mit Anweisungen, die Dev UI zum Debuggen und ein FastAPI-Endpunkt in einem Docker-Container.

Da Python und .NET gleichermaßen unterstützt werden, rechnen wir damit, dass es zum führenden Agenten-Framework für Unternehmen im .NET-Ökosystem wird. Python-Entwickler bekommen gleichzeitig eine solide, vertraute Umgebung.

Der nächste Schritt liegt nahe: Ergänzen Sie den Helpdesk-Agenten aus diesem Leitfaden um eine Persistenzschicht, damit er Neustarts übersteht. Danach geht es um mehrstufige Prozesse: Teil 2: Komplexe Aufgaben mit Workflows im Microsoft Agent Framework orchestrieren setzt diese Serie fort.

Planen Sie einen solchen Agenten für Ihre eigenen IT- oder Geschäftsprozesse? Unser Team für KI-Beratung setzt solche Projekte gemeinsam mit Unternehmen um, vom ersten Prototyp bis zum Produktivbetrieb.

Offizielle Ressourcen

• Offizielle Dokumentation: Der beste Einstieg, um Architektur und Möglichkeiten des Frameworks im Detail kennenzulernen.
• GitHub-Repository: Quellcode, weitere Beispiele und die Möglichkeit, selbst zum Projekt beizutragen.
• Ankündigung im Blog: Microsofts ursprüngliche Ankündigung mit Hintergründen zu Vision und Strategie hinter dem Framework (auf Englisch).

Sie möchten zuverlässige KI-Agenten-Systeme bauen?

Wir haben auf Basis aktueller Forschung einen ausführlichen Leitfaden (auf Englisch) erstellt, wie Sie robuste KI-Agenten-Systeme bauen, die auch im produktiven Betrieb funktionieren. Der Leitfaden behandelt:

• die 14 systematischen Fehlerquellen in Multi-Agenten-Systemen
• belegte Best Practices für das Design von Agenten
• strukturierte Kommunikationsprotokolle und Prüfmechanismen

Weiterlesen

• Zuverlässige KI-Agenten-Systeme bauen: Best Practices und Architekturmuster für robuste, verlässliche KI-Agenten.
• AI Agents From Scratch (auf Englisch): Eine Einführung in die Grundlagen von KI-Agenten, von der Planung bis zur Ausführung von Tools.
• Langfuse: Observability für LLM-Anwendungen: Mehr zur Observability von LLM-Anwendungen, einem zentralen Thema für Agenten im Unternehmenseinsatz.
• Smolagents: A Minimalist Agent Framework (auf Englisch): Ein anderer, schlanker Ansatz für die Agentenentwicklung, zum Vergleich.
• RAG mit Azure AI Search: Wie Sie Ihre Agenten mit internem Wissen versorgen, indem Sie ein Retrieval-Augmented-Generation-System auf Azure bauen.

Über den Autor

Andreas Nigg

Mitgründer, Pondhouse Data

Andreas entwickelt seit mehr als acht Jahren Datenanwendungen. Bei Pondhouse Data konzipiert und baut er KI-Systeme und integriert sie in komplexe, gewachsene Unternehmensumgebungen.

Sprechen Sie mit Andreas über Ihr ProjektAuf LinkedIn folgen