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.

Wenn Sie gehostete Agents mit einem KI-Codierungs-Agent untersuchen, kann die Microsoft Foundry Skill diese Konzepte mit Implementierungs-, Bereitstellungs- und Betriebsaufgaben verbinden.

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.
• Lang andauernde Aufgaben robust ausführen – die laufende Arbeit von Agenten über Prozessunterbrechungen hinweg beibehalten und gestreamte Ergebnisse für Clients, die sich erneut verbinden, erneut wiedergeben.

Funktionsweise

Sie packen Ihren Agent als Containerimage und übertragen ihn an Azure Container Registry. Bei der Bereitstellung ruft der Agent-Dienst das Image ab, weist eine dedizierte Microsoft Entra ID (Agent-Identität) zu und stellt einen dedizierten Endpunkt für den Agent bereit.

Zur Laufzeit stellt Agent Service Rechenressourcen für die Sitzung bereit und leitet Anfragen an Ihren Container weiter. Ihr Agentcode verarbeitet diese Anforderungen und kann Foundry-Modelle, Toolboxtools und nachgeschaltete Azure Dienste mithilfe seiner Agentidentität aufrufen. Die Plattform behandelt Skalierung, Sitzungszustandspersistenz, Observierbarkeit und Lebenszyklusverwaltung.

Das folgende Diagramm zeigt, wie die Verantwortung geteilt wird. Sie besitzen den Code, der im Sandkasten ausgeführt wird. Die Plattform verwaltet den Endpunkt sowie die zugehörige Identität, Skalierung und den Sitzungszustand.

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?

Das von Ihnen gewählte Protokoll bestimmt, welche Nutzlast Ihr Container empfängt und in welchem Umfang die Plattform Sitzungsverwaltung, Streaming und Hintergrundverarbeitung für Sie übernimmt. Ein einzelner Agent kann mehrere Protokolle unterstützen, sodass diese Wahl nicht dauerhaft ist. Verwenden Sie die folgende Entscheidungsstruktur, um einen Ausgangspunkt auszuwählen.

Protokollvergleich

Hintergrundmodus und robuste Ausführung lösen verschiedene Probleme. Im Hintergrundmodus kann die Arbeit fortgesetzt werden, nachdem die initiierende Anforderung zurückgegeben wurde. Widerstandsfähige Ausführung behält Arbeit bei, nachdem der Hostingprozess beendet wurde. Weitere Informationen zum Wiederherstellungsmodell und zu den Verantwortlichkeiten der Anwendung finden Sie unter Resilienz für langlebige gehostete Agenten.

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
• Aufrufe (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: Sie können das Leerlauftimeout pro Agentversion von 5 bis 60 Minuten konfigurieren, wobei die Standardeinstellung 15 Minuten beträgt. Wenn keine Anforderung innerhalb dieses Fensters eingeht, wird die Berechnung von der Plattform aufgehoben und der Sitzungszustand beibehalten. Die Plattform löscht eine Sitzung nach 30 Tagen Inaktivität dauerhaft.
• 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

Compute folgt der Sitzung, nicht der einzelnen Anforderung. Die Plattform stellt beim Start einer Sitzung eine Sandbox bereit und gibt sie wieder frei, wenn das konfigurierte Leerlauf-Timeout nach der letzten Anfrage abläuft. Wenn die Sitzung fortgesetzt wird, stellt die Plattform $HOME und /files wieder her, sodass Ihr Code die Dateien findet, die er zuvor geschrieben hat. Das folgende Diagramm zeigt, wie eine Anforderung diese Zustände durchläuft.

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. Die Version ist eine Momentaufnahme des Containerimages, der Ressourcenzuordnung, der Umgebungsvariablen und der Protokollkonfiguration. Um Ihren Agent zu aktualisieren, erstellen und bereitstellen Sie eine neue Version.

Ein Agentendpunkt dient jeweils einer Version und leitet 100% seines Datenverkehrs an diese Version weiter. Die Aufteilung des Datenverkehrs zwischen Versionen wird nicht unterstützt.

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 Agenten haben uneingeschränkten Zugriff auf von Foundry verwaltete Tools, einschließlich Code Interpreter, Websuche (mit Grounding mit Bing Custom Search), Azure KI-Suche, OpenAPI, MCP, A2A, Skills und mehr. Sie verbinden diese Tools über einen TOOLBOX-MCP-Endpunkt , der in Ihrem Foundry-Projekt bereitgestellt wird, anstatt sie direkt zur Agentdefinition hinzuzufügen. Die Toolbox bietet Ihnen eine konsolidierte Authentifizierung über OAuth Identity Passthrough, Agent-Identität, schlüsselbasierte Authentifizierung und vieles mehr. Wenn Sie Microsoft Agent Framework verwenden, verbinden Sie sich über FoundryToolbox in Python oder AddFoundryToolboxes in .NET statt über einen generischen MCP-Client. Andere Laufzeiten stellen eine Verbindung mit standardmäßigen MCP-Clientbibliotheken her. Ausführliche Informationen finden Sie unter Absichtsgesteuertes Toolset in Foundry kuratieren.

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. Die Inhalte der Plattform bleiben erhalten, wenn die Computeressourcen nach dem konfigurierten Leerlauftimeout freigegeben werden. Die Plattform stellt die Inhalte wieder her, wenn die Sitzung wieder aufgenommen wird, sodass Dateien, die unter $HOME geschrieben wurden, Leerlaufzeiten überdauern. Die Plattform schreibt Dateien, die über den Endpunkt /files hochgeladen wurden, in $HOME, wo sie denselben Speicher gemeinsam nutzen. Jede Sitzung verfügt über ein gesamtes Datenträgerbudget von bis zu 20 GiB bei 1 vCPU oder höher, was für kleinere CPU-Ebenen proportional nach unten skaliert wird. Die Plattform reserviert etwa 20% dieses Budgets für die Systemnutzung, und es ist nicht sichtbar oder für Ihren Agenten 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 und hält ihre Rechenressourcen aktiv, solange weiterhin Anfragen eingehen. Jede Anforderung setzt den Leerlauftimer zurück. Wenn das konfigurierte Leerlauftimeout nach der letzten Anfrage abläuft, hebt die Plattform die Sandboxberechnung auf und der Sitzungszustand wird beibehalten.

Der Leerlauftimeout kann 5 bis 60 Minuten betragen und wird standardmäßig auf 15 Minuten festgelegt. Die Plattform löscht eine Sitzung nach 30 Tagen Inaktivität dauerhaft. 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:

• Australien Ost
• Brasilien Süd
• Kanada Zentral
• Canada East
• Zentrale USA
• East US
• Ost-USA 2
• Frankreich Zentral
• Deutschland West Central
• Italy North
• Japan Ost
• Japan West
• Korea Central
• Nord-Mittel-USA
• Norwegen Ost
• Polen Zentral
• Südafrika Nord
• Süd-Mittel-USA
• Südindien
• Südostasien
• Spanien Zentral
• Schweden Zentral
• Schweiz Nord
• Westschweiz
• UAE North
• UK South
• UK West
• Zentralwesten der USA
• West Europe
• USA, Westen
• USA, Westen 3

Nächste Schritte

Verwandte Inhalte

• Agent-Laufzeitkomponenten
• Lebenszyklus der Agententwicklung
• Agent-Identitätskonzepte in Microsoft Foundry
• Was ist Toolbox in Foundry?
• Azure Container Registry-Dokumentation