Was sind gehostete Agents?

Wenn Sie agentische Anwendungen mithilfe von Open-Source-Frameworks erstellen, verwalten Sie in der Regel viele übergreifende Probleme: Containerisierung, Webservereinrichtung, Sicherheit, Speicherpersistenz, Skalierung, Instrumentierung und Versionsrollbacks. Diese Aufgaben werden in heterogenen Cloudumgebungen noch schwieriger.

Gehostete Agents im Foundry Agent Service lösen diese Herausforderungen für Microsoft Foundry-Benutzer. Gehostete Agents rufen Modelle aus dem Foundry-Modellkatalog auf, um die Begründung auszuführen, während Ihr benutzerdefinierter Code die Orchestrierung behandelt. Mithilfe dieser verwalteten Plattform können Sie KI-Agents sicher und in großem Umfang bereitstellen und betreiben. Sie können Ihren benutzerdefinierten Agentcode oder ein bevorzugtes Agent-Framework mit optimierter Bereitstellung und Verwaltung verwenden.

Wann werden gehostete Agents verwendet?

Wählen Sie gehostete Agents anstatt von eingabeaufforderungsbasierten Agents aus, wenn Sie Folgendes benötigen:

Bring your own code – verwenden Sie jedes Framework (Agent Framework, LangGraph, Semantischer Kernel oder benutzerdefinierter Code) anstatt nur Aufforderungen zu verwenden.
Verwenden Sie benutzerdefinierte Protokolle – akzeptieren Sie Webhooks oder Nicht-OpenAI-Nutzlasten über das Invocations-Protokoll.
Steuern von Computeressourcen – Geben Sie CPU und Arbeitsspeicher für den Sandkasten Ihres Agents an.
Zustandsbehaftete Workloads ausführen – Dateien und Zustände über $HOME und den /files-Endpunkt beibehalten.

Funktionsweise

Sie packen Ihren Agent als Containerimage und übertragen ihn an Azure Container Registry. Wenn Sie bereitstellen, ruft der Agentdienst das Image ab, stellt die Berechnung bereit, weist eine dedizierte Microsoft Entra ID (Agentidentität) zu und macht einen dedizierten Endpunkt verfügbar. Zur Laufzeit verarbeitet Ihr Agentcode Anforderungen von Clients und kann Foundry-Modelle, Toolbox-Tools und downstream-Azure-Dienste mit seiner Agentidentität aufrufen. Die Plattform behandelt Skalierung, Sitzungszustandspersistenz, Observierbarkeit und Lebenszyklusverwaltung.

Wichtig

Wenn Sie gehostete Agents mit anderen Microsoft Produkten und Diensten verwenden, müssen Sie alle relevanten Dokumentationen für solche Produkte und Dienste lesen und verwandte Risiken und Compliance-Überlegungen verstehen. Wenn Sie gehostete Agents mit Servern, Agents, Code oder Modellen von Drittanbietern verwenden, die nicht Azure Direct-Modelle ("Drittanbietersysteme") sind, tun Sie dies auf eigene Gefahr. Drittanbietersysteme sind nicht Microsoft Produkte unter den Microsoft Produktbedingungen und unterliegen ihren eigenen Lizenzbedingungen von Drittanbietern. Sie sind für alle Nutzungs- und damit verbundenen Kosten verantwortlich. Überprüfen Sie alle daten, die mit Drittanbietersystemen geteilt und empfangen wurden. Beachten Sie die Methoden von Drittanbietern für die Behandlung, Freigabe, Aufbewahrung und den Speicherort von Daten. Es liegt in Ihrer Verantwortung, zu verwalten, ob Ihre Daten außerhalb der Azure Compliance- und geografischen Grenzen Ihrer Organisation und alle damit verbundenen Auswirkungen fließen. Microsoft hat keine Verantwortung für Sie oder andere Personen in Bezug auf die Nutzung von Drittanbietersystemen, und Sie sind für die Implementierung Ihrer eigenen verantwortungsvollen KI-Entschärfungen wie Metaprompts, Inhaltsfilter oder andere Sicherheitssysteme verantwortlich.

Schlüsselkonzepte

Gehostete Agents

Gehostete Agents sind containerisierte agentische KI-Anwendungen, die auf dem Agent-Dienst ausgeführt werden. Im Gegensatz zu promptbasierten Agents, die vollständig über Eingabeaufforderungen und Toolkonfiguration im Foundry-Portal definiert werden, sind gehostete Agents Ihr eigener Code, der als Containerimage verpackt ist. Sie wählen das Framework aus, steuern das Laufzeitverhalten und stellen das Image für Microsoft verwaltete Infrastruktur bereit.

Die Plattform verwaltet den Containerlebenszyklus automatisch basierend auf Aktivitäten und stellt Ressourcen bereit, wenn Sie eine Version erstellen, und hebt die Bereitstellung auf, wenn das Leerlauf-Timeout erreicht ist.

Isolationsmodell

Gehostete Agents werden in VM-isolierten Sandboxes pro Sitzung ausgeführt. Jede Sitzung erhält einen dedizierten Sandkasten mit einem persistenten Dateisystem ($HOME und /files), wodurch Scale-to-Zero mit zustandsvollen Fortsetzungs- und vorhersagbaren Kaltstarts ermöglicht wird. Sitzungen sind voneinander isoliert und der Zustand wird automatisch wiederhergestellt, wenn eine Sitzung nach einer Inaktivitätsphase fortgesetzt wird.

Protokolle: Antworten und Aufrufe

Gehostete Agentcontainer machen ein oder beide Protokolle verfügbar. Jedes Protokoll wird von einer einfachen Bibliothek bereitgestellt, die den HTTP-Server, Integritätsprüfungen und die OpenTelemetry-Integration verarbeitet.

Welches Protokoll sollte ich verwenden?

Szenario	Protokoll	Warum
Unterhaltungs-Chatbot oder Assistent	Antworten	Die Plattform verwaltet aufgezeichnete Unterhaltungen, Streamingereignisse und Sitzungslebenszyklus – verwenden Sie ein beliebiges OpenAI-kompatibles SDK als Client.
Mehrstufige Frage-Antwort-Sitzung mit RAG oder Tools	Antworten	Integrierte Unterhaltungs-ID-Threading und Toolergebnisbehandlung.
Hintergrund/ asynchrone Verarbeitung	Antworten	Hintergrund: true mit plattformgesteuerter Abfrage und Abbruch – kein benutzerdefinierter Code erforderlich.
Agent veröffentlicht in Teams oder Microsoft 365	Antworten + Aktivität	Das Antwortprotokoll unterstützt die Agentlogik; die Plattform überbrückt die Antworten automatisch mit dem Aktivitätsprotokoll für die Kanalübermittlung.
Webhook-Empfänger (GitHub, Stripe, Jira usw.)	Aufrufe	Das externe System sendet ein eigenes Nutzlastformat– Sie können es nicht so ändern, dass es mit "/responses" übereinstimmt.
Nicht-konversationelle Verarbeitung (Klassifizierung, Extraktion, Stapel)	Aufrufe	Die Eingabe ist strukturierte Daten, keine Chatnachricht. Beliebiger JSON in, beliebiger JSON aus.
Benutzerdefiniertes Streamingprotokoll (AG-UI usw.)	Aufrufe	AG-UI und andere Agent-UI-Protokolle sind nicht openAI-kompatibel – Sie benötigen ein unformatiertes SSE-Steuerelement.
Protokollbrücke (GitHub Copilot, proprietäre Systeme)	Aufrufe	Der Aufrufer verfügt über ein eigenes Protokoll, das /responses nicht zugeordnet ist.

Tipp

Weiß nicht? Beginnen Sie mit Antworten. Sie können später immer einen Endpunkt für Aufrufe hinzufügen – ein gehosteter Agent kann beide Protokolle gleichzeitig unterstützen.

Protokollvergleich

	Antworten	Aufrufe
Optimal für	Die meisten Agents – die Plattform verwaltet aufgezeichnete Unterhaltungen, Streaming-Lebenszyklus und Hintergrundausführung	Agents, die vollständige HTTP-Steuerung, benutzerdefinierte Nutzlasten oder asynchrone Workflows mit langer Ausführung benötigen
Nutzlast	OpenAI-kompatibler Vertrag für /responses	Beliebiges JSON mittels /invocations – Sie definieren das Schema
Client-SDK	Jedes openAI-kompatible SDK (Python, JS, C#) funktioniert sofort.	Benutzerdefinierter Client – Sie definieren den Vertrag
Sitzungsverlauf	Plattform wird über Gesprächs-ID verwaltet	Sie verwalten Sitzungen (Im Memory, Cosmos DB usw.)
Streaming	Plattformgesteuerter Response-Event-Stream mit Lebenszyklusereignissen	Unformatiertes SSE – Sie formatieren und schreiben Ereignisse direkt
Hintergrund / langandauernd	Integriert (Hintergrund: true + plattformgesteuertes Polling)	Manuelle Aufgabenverfolgung und benutzerdefinierte Abfrageendpunkte

Zusätzliche Protokolle

Gehostete Agents unterstützen außerdem das Protokoll Activity für Teams und Microsoft 365 Kanalintegration. Wenn Sie das Antwortprotokoll für die Agentlogik verwenden und in Microsoft 365 Kanälen wie Teams veröffentlichen, überbrückt die Plattform automatisch Antworten auf das Aktivitätsprotokoll für die Kanalübermittlung – es ist keine separate Verkabelung erforderlich. Das A2A-Protokoll unterstützt die Agent-zu-Agent-Delegierung. Alle vier Protokolle – Antworten, Aufrufe, Aktivitäten und A2A – können in einem einzigen Agent kombiniert werden.

Agentenidentität und -endpunkt

Jeder gehostete Agent, der in einem Foundry-Projekt bereitgestellt wird, erhält einen eigenen dedizierten Microsoft Entra ID (Agentidentität) und dedizierten Endpunkt – beide werden zur Bereitstellungszeit automatisch erstellt. Sie müssen keine verwalteten Identitäten oder manuelles Routing konfigurieren.

Der Endpunkt ist unmittelbar nach der Bereitstellung verfügbar– für den programmgesteuerten Zugriff ist keine Veröffentlichung erforderlich:

Antworten: {project_endpoint}/agents/{name}/endpoint/protocols/openai/v1/responses
Aufrufe: {project_endpoint}/agents/{name}/endpoint/protocols/invocations
A2A (Vorschau): {project_endpoint}/agents/{name}/endpoint/protocols/a2a

Welche Endpunkte aktiv sind, hängt von den Protokollen ab, die in der Agentversionsdefinition deklariert sind (bei Verwendung von azd oder über container_protocol_versions bei Verwendung des SDK in agent.yaml festgelegt).

Zwei Identitäten sind beteiligt:

Identität	Umfang	Zweck
Microsoft Entra ID (Agentidentität, pro Agent)	Automatisch zum Bereitstellungszeitpunkt erstellt	Die Identität, mit der der Agentcontainer zur Laufzeit authentifiziert wird. Wird für Modellaufrufe, Toolzugriff und nachgeschaltete Azure-Dienste verwendet.
Projekteigene Identität (projektweit)	Systemzuweisung für das Foundry-Projekt	Wird von der Plattform für Infrastrukturvorgänge verwendet (z. B. Containerregistrierungs-Repositoryleser in der Containerregistrierung). Nicht die Laufzeitidentität des Software-Agents.

Wenn Sie mit azd bereitstellen, wird die erforderliche RBAC-Rolle (Azure AI User auf Kontoebene) automatisch der Microsoft Entra ID des Agents zugewiesen. Für externe Ressourcen (z. B. Ihre eigene Azure Storage) weisen Sie RBAC manuell dem Microsoft Entra ID des Agents zu.

Bei der Integration über Microsoft 365 Kanäle (z. B. Teams) können gehostete Agents auch mit der Benutzeridentität im Auftrag von (OBO) arbeiten. Die Microsoft Entra ID des Agents kann ein Benutzertoken austauschen, um damit nachgeschaltete Dienste gemäß den Mandantenrichtlinien als Benutzer aufzurufen. Weitere Informationen finden Sie unter Agent-Anwendungen und Agent-Identitätskonzepte.

Sitzungen und Unterhaltungen

Gehostete Agents verwenden Sitzungen und Interaktionen zum Verwalten des Zustands. Wie sie funktionieren, hängt vom Protokoll ab.

Sitzungen

Eine Sitzungs-ID identifiziert eine logische Sitzung mit beibehaltenem Zustand, einschließlich $HOME und Dateien, die über den /files-Endpunkt hochgeladen wurden. Die Plattform stellt Rechenressourcen bei Bedarf bereit und stellt den persistenten Zustand darauf wieder her.

Statuspersistenz: $HOME- und /files-Inhalte werden über Sitzungen und während Leerlaufzeiten beibehalten. Sobald die Rechenkapazität in den Leerlauf geht und reaktiviert wird (auf neuer oder bestehender Infrastruktur), wird der Sitzungszustand automatisch wiederhergestellt.
Isolation: Jede Sitzung ist von anderen Sitzungen isoliert.
Automatischer Lebenszyklus: Sitzungen werden bei der ersten Verwendung erstellt. Die Plattform stellt Rechenressourcen automatisch bereit und zieht sie ab.
Sitzungsdauer: Sitzungen bestehen bis zu 30 Tage. Das Leerlauftimeout beträgt 15 Minuten– wenn keine Anforderung innerhalb dieses Fensters eingeht, wird die Berechnung aufgehoben und der Sitzungszustand beibehalten.
Sitzungsverwaltungs-APIs: Sitzungen auflisten, Sitzungen beenden und Dateien pro Sitzung hochladen oder herunterladen.

Gespräche

Eine Unterhaltungs-ID ist ein dauerhafter Datensatz von Aufgezeichneten Unterhaltungen (Nachrichten, Toolanrufe und Antworten), die in Foundry gespeichert sind.

Persistenz: Der Konversationsverlauf wird in Foundry gespeichert und bleibt unabhängig vom Berechnungszustand erhalten.
Kanalübergreifender Zugriff: Benutzer können über den Playground, die API, Teams oder andere veröffentlichte Kanäle auf dieselbe Unterhaltung zugreifen.

Funktionsweise von Sitzungen und Interaktionen mit jedem Protokoll

Antwortprotokoll: Gesprächs-ID ist das primäre Konzept. Die Plattform verwaltet den Unterhaltungsverlauf automatisch und ordnet jeder Unterhaltung eine Sitzungs-ID zu. Die Plattform gibt die Sitzungs-ID an den Client zurück, der sie zum Hochladen von Dateien über den Endpunkt "/files" verwenden kann, sodass diese Dateien für die Rechnerleistung der Konversation verfügbar sind.

Aufrufprotokoll: Sitzungs-ID ist das primäre Konzept. Der Client verwaltet die Sitzungs-ID direkt, um den Zustand über Interaktionen hinweg aufrechtzuerhalten. Der Client kann Inhalte über den /files-Endpunkt mithilfe der Sitzungs-ID hochladen, um ihn für die Sitzung verfügbar zu machen. Es gibt keinen von der Plattform verwalteten Konversationsverlauf – Sie verwalten den Status selbst in Ihrem eigenen Code.

Sitzungs-Berechnungslebenszyklus

Staat	Was ist los
Aktiv	Die Berechnung läuft. Anfragen werden an ihn weitergeleitet. $HOME- und /files-Inhalte sind verfügbar.
Im leerlauf	Keine Anforderungen für 15 Minuten. Compute wird deprovisioniert. Der Sitzungszustand ($HOME, /files) wird beibehalten.
Fortgesetzt	Auf dieselbe Sitzungs-ID wird erneut verwiesen. Plattform stellt neue Rechenressourcen bereit und stellt den gespeicherten Zustand wieder her.

Sicherheit und Datenverarbeitung

Behandeln Sie einen gehosteten Agent wie Produktionsanwendungscode.

Wichtig

Wenn Sie den Foundry Agent Service zum Hosten von Agents verwenden, die mit Modellen, Servern oder Agents von Drittanbietern interagieren, tun Sie dies auf Eigenes Risiko. Es wird empfohlen, alle Daten zu überprüfen, die für Modelle, Server oder Agents von Drittanbietern freigegeben werden, und die Methoden von Drittanbietern für die Aufbewahrung und den Speicherort von Daten zu verstehen. Es liegt in Ihrer Verantwortung, zu verwalten, ob Ihre Daten außerhalb der Azure Compliance- und geografischen Grenzen Ihrer Organisation und alle damit verbundenen Auswirkungen fließen.

Fügen Sie keine geheimen Schlüssel in Containerimages oder Umgebungsvariablen ein. Verwenden Sie verwaltete Identitäten und Verbindungen, und speichern Sie geheime Schlüssel in einem verwalteten geheimen Speicher. Anleitungen finden Sie unter Setup a Key Vault connection.
Achten Sie auf nicht-Microsoft-Tools und Server. Wenn Ihr Agent Tools aufruft, die nicht von Microsoft-Dienste unterstützt werden, fließen einige Daten möglicherweise zu diesen Diensten. Überprüfen Sie die Datenfreigabe-, Aufbewahrungs- und Standortrichtlinien für alle Nicht-Microsoft Dienste, die Sie verbinden.

Plattformdetails

Versionsverwaltung

Jeder Aufruf zum Erstellen einer Version erzeugt eine unveränderliche Agentversion – eine Momentaufnahme des Containerimages, der Ressourcenzuordnung, der Umgebungsvariablen und der Protokollkonfiguration. Bereitstellungen verweisen auf eine bestimmte Version. Um Ihren Agent zu aktualisieren, erstellen Sie eine neue Version, und die Plattform stellt sie bereit. Beachten Sie, dass Anforderungen zum Erstellen der Agentversion ohne Änderung an den Agentversionsparametern wie Containerimage, Umgebungsvariablen usw. nicht dazu führen, dass eine neue Version erstellt wird. Sie können Traffic zwischen Versionen mit gewichteten Rollouts verteilen, um Canary- und Blue-Green-Deployments zu unterstützen.

Umgebungsvariablen sind der primäre Mechanismus zum Übergeben der Konfiguration an Ihren Container zur Laufzeit (z. B. der Projektendpunkt, der Modellbereitstellungsname und benutzerdefinierte Einstellungen). Sie werden pro Version festgelegt und sind unveränderlich, sobald die Version erstellt wurde.

Beobachtbarkeit

Gehostete Agents bieten eine eingebaute Observabilität. Die Plattform fügt automatisch eine Application Insights-Verbindungszeichenfolge über Umgebungsvariablen in Ihren Agentcontainer ein. Agents, die die Protokollbibliotheken verwenden, geben standardmäßig OpenTelemetry-Ablaufverfolgungen aus, die in der verknüpften Application Insights-Ressource unter InvestigateTransaction search oder Performance angezeigt werden.

Anleitungen zur Konfiguration und Analyse finden Sie unter Aktivieren der Ablaufverfolgung in Ihrem Projekt.

Die Toolbox in Foundry

Gehostete Agents greifen in Ihrem Foundry-Projekt über einen Toolbox MCP-Endpunkt auf Foundry-verwaltete Tools (Code Interpreter, Web Search, Azure KI-Suche, OpenAPI, benutzerdefinierte MCP-Verbindungen, A2A) zu. Ihr Agentcode stellt mithilfe standardmäßiger MCP-Clientbibliotheken eine Verbindung mit diesem Endpunkt bereit. Die Plattform fügt keine Tools automatisch ein. Ausführliche Informationen finden Sie unter Absichtsgesteuertes Toolset in Foundry kuratieren. Wir empfehlen Kunden, die Toolbox in Foundry zu nutzen, um Tools im gehosteten Agenten zu verbinden. Diese bietet konsolidierte Unterstützung für Authentifizierungsmethoden wie OAuth Identity passthrough, Agenten-Identität, Schlüsselbasierte Authentifizierung und mehr.

Sprachunterstützung

Gehostete Agents unterstützen Python und C#. Sie können ein beliebiges Agent-Framework verwenden– die Protokollbibliotheken sind frameworkagnostisch. Beispiele mit Microsoft Agent Framework, LangGraph und benutzerdefiniertem Code finden Sie im Repository foundry-samples.

Sandkastengrößen

Gehostete Agent-Sandboxes unterstützen CPU- und Speicherzuweisungen von 0,25 vCPU / 0,5 GiB bis 2 vCPU / 4 GiB.

Private Netzwerke

Gehostete Agents unterstützen die Bereitstellung innerhalb von netzwerkisolten Foundry-Ressourcen und können eine vom Kunden bereitgestellte Azure Virtual Network für ausgehenden Datenverkehr verwenden. Auf diese Weise können Agents in netzwerkisolten Foundry-Bereitstellungen private Ressourcen wie Datenbanken oder interne APIs erreichen. Weitere Informationen finden Sie unter Konfigurieren virtueller Netzwerke.

Hinweis

Das Azure Container Registry, in dem sich Ihr Agentimage befindet, muss derzeit über seinen öffentlichen Endpunkt erreichbar bleiben. Ein durch privates Netzwerk gesichertes ACR wird derzeit nicht unterstützt.

Grenzwerte, Preise und Verfügbarkeit (Vorschau)

Gehostete Agents befinden sich derzeit in der Vorschau.

Einschränkungen während der Vorschau

Grenze	Umfang	Standardwert	Einstellbar
Maximale Anzahl gleichzeitiger aktiver Sitzungen	pro Abonnement pro Region	50	Ja, mit Kontingentanforderungen an Microsoft-Support

Preise

Die Abrechnung der verwalteten Hostinglaufzeit basiert auf dem Verbrauch von CPU- und Arbeitsspeicherressourcen während der aktiven Sitzungen. Aktuelle Preise finden Sie auf der Seite " Foundry-Preise".

Verfügbarkeit der Region

Gehostete Agents sind derzeit in den folgenden Regionen verfügbar:

Ost-USA 2
Nord-Mittel-USA
Schweden Zentral
Kanada Zentral
Südostasien
Polen Zentral
Südafrika Nord
Korea Central
Südindien
Brasilien Süd
USA (Westen)
West-USA 3
Norwegen Ost
Japan Ost
Frankreich Zentral
Schweiz Nord
Spanien Zentral
Australien Ost