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 Agenten gegenüber promptbasierten Agenten, wenn Sie Folgendes benötigen:

• Bring your own code - Verwenden Sie ein beliebiges Framework (Agent Framework, LangGraph, Semantischer Kernel oder angepassten Code) anstelle von reinen Prompt-Definitionen.
• 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 Zustand rundenübergreifend auf $HOME und dem /files-Endpunkt speichern.

Funktionsweise

Sie packen Ihren Agent als Containerimage und übertragen ihn an Azure Container Registry. Beim Bereitstellen ruft der Agent Service das Image ab, stellt Computeressourcen bereit, weist eine dedizierte Microsoft Entra ID (Agent-Identität) zu und stellt einen dedizierten Endpunkt zur Verfügung. 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.

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 eine dedizierte Sandbox mit einem persistenten Dateisystem ($HOME und /files), wodurch eine Skalierung auf Null mit zustandsbehafteter Wiederaufnahme 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, Aufrufe und Aufrufe (WebSocket)

Gehostete Agentcontainer können ein oder mehrere Protokolle verfügbar machen. Jedes Protokoll wird von einer einfachen Bibliothek bereitgestellt, die den HTTP- oder WebSocket-Server, Integritätsprüfungen und die OpenTelemetry-Integration verarbeitet. Die Protokolle Antworten, Aufrufe und Aufrufe (WebSocket) sind in allen Regionen, die gehostete Agenten unterstützen, verfügbar.

Welches Protokoll sollte ich verwenden?

Protokollvergleich

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. Unterstützte Protokolle 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/responses
• Aufrufe: {project_endpoint}/agents/{name}/endpoint/protocols/invocations
• Invocations (WebSocket): wss://{account}.services.ai.azure.com/api/projects/{project}/agents/{name}/endpoint/protocols/invocations_ws?api-version=v1
• 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. Legen Sie diese Definition im Dienst azure.ai.agent in azure.yaml bei Verwendung von azd oder über protocol_versions bei Verwendung des SDK fest.

Zwei Identitäten sind beteiligt:

Die Agent-Identität kann standardmäßig über den Projektendpunkt und den Sitzungsspeicher auf Modellinferenz zugreifen. Weisen Sie für externe Ressourcen (z. B. Ihre eigene Azure Storage) RBAC-Rollen manuell dem Microsoft Entra ID des Agents zu. Weitere Informationen finden Sie unter Agentzugriff über die Standardeinstellungen hinaus.

Bei der Integration über Microsoft 365 Kanäle (z. B. Teams) können gehostete Agents in zwei Identitätsmodi arbeiten, je nachdem, wie sie aufgerufen werden:

• Vom Benutzer aufgerufene Szenarien (interaktiv): Wenn ein Benutzertoken vorhanden ist, unterstützt die Plattform OAuth 2.0 On-Behalf-Of (OBO)-Flüsse. In diesem Fall kann der Agent nachgeschaltete Dienste im Namen des Benutzers aufrufen, indem er die delegierten Berechtigungen des Benutzers verwendet, vorbehaltlich Microsoft Entra ID Mandantenrichtlinien.

• Autonome oder Hintergrundszenarien: Wenn kein Benutzertoken verfügbar ist, authentifiziert sich der Agent mit seiner eigenen Microsoft Entra-ID (Agentidentität), in der Regel über eine verwaltete Identität, um auf nachgeschaltete Dienste zuzugreifen.

In beiden Fällen behält der Agent seine dedizierte Microsoft Entra ID für Authentifizierung, Autorisierung und Prüfbarkeit bei. 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 nach Bedarf Computeressourcen bereit und stellt darauf den persistenten Zustand 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 die Compute bereit und hebt die Bereitstellung automatisch wieder auf.
• Sitzungsdauer: Das Leerlauftimeout beträgt 15 Minuten – wenn keine Anforderung innerhalb dieses Fensters eingeht, wird die Plattform die Berechnung aufheben und den Sitzungszustand beibehalten. Eine Sitzung wird nach 30 Tagen Inaktivität endgültig gelöscht.
• 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-Computelebenszyklus

Sicherheit und Datenverarbeitung

Behandeln Sie einen gehosteten Agent wie Produktionsanwendungscode.

• 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 den Datenverkehr zwischen Versionen mit gewichteten Rollouts aufteilen, um Canary- und Blau-Grün-Bereitstellungen 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 Investigate> 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 zu diesem Endpunkt her. Die Plattform fügt keine Tools automatisch ein. Ausführliche Informationen finden Sie unter Absichtsgesteuertes Toolset in Foundry kuratieren. Verwenden Sie die Toolbox in Foundry, um Tools in einem gehosteten Agent mit konsolidierter Authentifizierungsunterstützung über OAuth Identity-Passthrough, Agentidentität, Schlüsselbasiert und vieles mehr zu verbinden.

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-Sandkasten unterstützen die folgenden CPU- und Arbeitsspeicherkombinationen:

Sitzungsspeicher

Jede Sitzung hat ein persistentes $HOME. Seine Inhalte bleiben erhalten, wenn die Rechenressource nach 15 Minuten Inaktivität deprovisioniert wird, und werden wiederhergestellt, wenn die Sitzung fortgesetzt wird, sodass unter $HOME geschriebene Dateien Leerlaufphasen überdauern. Dateien, die über den Endpunkt /files hochgeladen werden, werden in $HOME geschrieben und verwenden denselben Speicher. Jede Sitzung wird ein gesamtes Datenträgerbudget von bis zu 20 GiB bei 1 vCPU oder höher zugewiesen, das proportional nach unten für kleinere CPU-Ebenen skaliert wird. Etwa 20% dieses Budgets ist für die Systemnutzung reserviert und ist für Ihren Agenten nicht sichtbar oder verfügbar. Der verbleibende Speicherplatz wird zwischen Ihrem Container-Image, $HOME, und allen anderen beschreibbaren Speicherorten in Ihrem Container aufgeteilt.

Skalierung und bedarfsgerechte Dimensionierung

Gehostete Agents skalieren pro Sitzung, nicht pro Replikat. Die Plattform erstellt bei Bedarf für jede Sitzung eine neue VM-isolierte Sandbox, betreibt sie für die Dauer der Sitzung (Inaktivitäts-Timeout 15 Minuten, maximale Lebensdauer 30 Tage) und entfernt sie, wenn die Sitzung endet. Es gibt keine Anzahl von Replikaten zu konfigurieren und keinen aktiven Pool zu dimensionieren.

Da jede Sitzung in einem eigenen Sandkasten ausgeführt wird, beschreiben die cpu- und speicherwerte, die Sie für eine Agentversion festgelegt haben, eine einzelne Sitzung, nicht den aggregierten Speicherbedarf des Agents. Die Abrechnung basiert auf dem CPU- und Arbeitsspeicherverbrauch über alle aktiven Sitzungen hinweg, sodass eine Überdimensionierung die Kosten mit Ihrem Grad der Parallelität vervielfacht.

Zur richtigen Dimensionierung führen Sie einen repräsentativen Workload aus und überprüfen die Ressourcenauslastung in der verknüpften Application Insights-Ressource:

1. Öffnen Sie die App Insights-Ressource im Azure-Portal, und wählen Sie Investigate>Performance aus.
2. Überprüfen Sie die CPU, den verfügbaren Arbeitsspeicher, die Anforderungsrate und die durchschnittliche Anforderungsdauer über den von Ihnen getesteten Zeitraum.

Vergleichen Sie die beobachteten Spitzen mit der cpu und dem von Ihnen zugewiesenen Arbeitsspeicher. Wenn anhaltende Auslastungsspitzen etwa 70 % der zugewiesenen Kapazität überschreiten, erhöhen Sie die Zuweisung der nächsten Agent-Version; wenn die Spitzen deutlich darunter bleiben, verringern Sie die zugewiesene Kapazität, um Kosten zu reduzieren. Testen Sie nach jeder Änderung immer erneut, denn jede neue Version ist unveränderbar.

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.

Grenzwerte, Preise und Verfügbarkeit

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
• Canada East
• Südostasien
• Polen Zentral
• Südafrika Nord
• Korea Central
• Südindien
• Brasilien Süd
• USA, Westen
• USA, Westen 3
• Norwegen Ost
• Japan Ost
• Frankreich Zentral
• Deutschland West Central
• Schweiz Nord
• Spanien Zentral
• Australien Ost

Nächste Schritte

Verwandte Inhalte

• Agent-Laufzeitkomponenten
• Lebenszyklus der Agententwicklung
• Agent-Identitätskonzepte in Microsoft Foundry
• Entdecken von Tools in Foundry Tools
• Azure Container Registry-Dokumentation