Baseline-Referenzarchitektur für Microsoft Foundry Chat

Foundry Tools

Azure App Service

Azure Monitor

Microsoft Foundry

Foundry-Agent-Dienst

Mithilfe von Unternehmenschatanwendungen können Mitarbeiter über Unterhaltungen in natürlicher Sprache mit KI-Agents interagieren. Diese Anwendungen verwenden Sprachmodelle wie OpenAI GPT-Modelle und Open-Source-Entwicklungskits wie das Microsoft Agent Framework. Diese Chatanwendungen bestehen in der Regel aus den folgenden Komponenten:

• Eine Chat-Benutzeroberfläche, die in eine größere Unternehmensanwendung integriert ist. Sie bietet Benutzern eine konversationsbasierte Erfahrung zusammen mit weiteren Geschäftsfunktionen.

• Datenrepositorys, die domänenspezifische Informationen enthalten, die für Benutzerabfragen relevant sind.

• Sprachmodelle, die domänenspezifische Daten analysieren, um relevante Antworten zu generieren.

• Eine permanente Orchestrierungsdefinition oder ein langlebiger Agent, der die Interaktionen zwischen Datenquellen, Sprachmodellen und dem Benutzer überwacht.

Dieser Artikel enthält eine grundlegende Architektur, mit der Sie Unternehmenschatanwendungen mithilfe von Foundry und Azure OpenAI-Modellen erstellen und bereitstellen können. Diese Architektur verwendet einen Eingabeaufforderungs-Agent , der im Foundry Agent Service beibehalten wird, aber auch gehostete Agents unterstützt. Sie definieren den Prompt-Agent deklarativ anhand seiner Anweisungen, der Modellauswahl und der verbundenen Tools, und Agent Service übernimmt sein Hosting. Der Agent empfängt Benutzernachrichten und fragt dann Datenspeicher ab, um Grundlageninformationen für das Sprachmodell abzurufen.

Die Chat-Benutzeroberfläche folgt den Richtlinien für die Baseline-Webanwendung von Azure App Service zur Bereitstellung einer sicheren, zonenredundanten und hochverfügbaren Webanwendung in App Service. In dieser Architektur kommuniziert der App Service mit der Azure-Plattform als Service (PaaS)-Lösung über die Integration virtueller Netzwerke und privater Endpunkte. In der Chat-UI-Architektur kommuniziert App Service mit dem Agent über einen privaten Endpunkt. Diese Architektur blockiert den öffentlichen Zugriff auf das Foundry-Portal und agents.

Von Bedeutung

In diesem Artikel werden die Komponenten oder Architekturentscheidungen aus der grundlegenden Webanwendungsarchitektur des App Service nicht beschrieben. Anleitungen zum Hosten der Webanwendung, die Ihre Chat-UI enthält, finden Sie in diesem Artikel.

Diese Architektur verwendet das Standard-Agent-Setup des Foundry Agent Service , um Sicherheit, Compliance und Kontrolle auf Unternehmensniveau bereitzustellen. In dieser Konfiguration bringen Sie Ihr eigenes virtuelles Netzwerk (BYO) für die Netzwerkisolation und Ihre eigenen Azure Ressourcen zum Speichern des Chat- und Agentstatus ein. Anwendungskomponenten greifen über private Endpunkte auf die Azure-Dienste zu, und Agenten greifen über private Netzwerkverbindungen auf workloadeigene MCP-Server zu. Mit diesem Ansatz wird sichergestellt, dass der Datenverkehr im virtuellen Netzwerk Ihrer Workload verbleibt. Der ausgehende Datenverkehr der Agenten wird ausschließlich über die Azure Firewall geleitet, die die Ausgangsregeln durchsetzt.

Tipp

Die Referenzimplementierung des Foundry Agent Service veranschaulicht eine grundlegende End-to-End-Chat-Implementierung auf Azure. Sie dient als Grundlage für die Entwicklung von benutzerdefinierten Lösungen, während Sie zur Produktion wechseln.

Architektur

Das Diagramm zeigt eine detaillierte Azure Architektur für die Bereitstellung einer KI-Lösung. Auf der linken Seite stellt ein Benutzer eine Verbindung über Azure Application Gateway mit einer Webanwendungsfirewall in Verbindung, die Teil eines virtuellen Netzwerks ist. Dieses Gateway ist mit privaten DNS-Zonen verknüpft und durch Azure DDoS Protection geschützt. Unter dem Gateway stellen private Endpunkte eine Verbindung mit Diensten wie App Service, Azure Key Vault und Azure Storage her, die für die Client-App-Bereitstellung verwendet werden. Der App Service wird unter Verwendung von Identitäten verwaltet und umfasst drei Regionen. Application Insights und Azure Monitor bieten Überwachung, und Microsoft Entra ID übernimmt die Authentifizierung. Rechts enthält das virtuelle Netzwerk mehrere Subnetze: App Service-Integration, privater Endpunkt, Foundry-Integration, Azure KI-Agent-Integration, Azure Bastion, Sprungfeld, Build-Agents und Azure Firewall. Jedes Subnetz hostet bestimmte Endpunkte oder Dienste, z. B. Speicher, Foundry, Azure KI-Suche und Azure Cosmos DB, alle über private Endpunkte verbunden. Ausgehender Datenverkehr aus dem Netzwerk durchläuft Azure Firewall, um Internetquellen zu erreichen. Ganz rechts stellt ein separater Kasten Foundry dar, das eine Ressource und ein Projekt enthält. Verwaltete Identitäten verbinden den Foundry Agent Service mit dem Foundry-Projekt, das wiederum auf ein Azure OpenAI-Modell zugreift. Das Diagramm verwendet nummerierte Kreise, um den logischen Fluss anzugeben. Es zeigt, wie Benutzeranforderungen das Netzwerk durchlaufen, mit verschiedenen Endpunkten interagieren und schließlich eine Verbindung mit Foundry- und Speicherdiensten herstellen, wobei Abhängigkeiten eindeutig gruppiert und bezeichnet werden.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Arbeitsablauf

1. Ein Anwendungsbenutzer interagiert mit einer Chat-UI. Die Anforderungen werden durch Azure Application Gateway geleitet. Azure Web Application Firewall überprüft diese Anforderungen, bevor sie an die Back-End-App Service-Instanz weitergeleitet werden.

2. Wenn die Webanwendung eine Benutzerabfrage oder -anweisung empfängt, ruft sie den zweckorientierten Agent auf. Die Webanwendung kommuniziert mit den Agentendpunkten über das Microsoft Agent Framework. Das Framework ruft die serverseitige Agentdefinition über die OpenAI-kompatible Antwort-API auf. Der HTTP-Aufruf des Clients bleibt unabhängig davon, welches unterstützte Modell der Agent verwendet, identisch. Die Webanwendung ruft den Agent über einen privaten Endpunkt auf und authentifiziert sich bei Foundry mithilfe seiner verwalteten Identität.

3. Der Agent verarbeitet die Anforderung des Benutzers basierend auf den Anweisungen in der Systemaufforderung. Um die Absicht des Benutzers zu erfüllen, verfügt der Agent über ein konfiguriertes Sprachmodell und verbundene Tools. In dieser Architektur umfasst die Toolauswahl das Azure KI-Suche-Tool zur Fundierung von Daten und das Websuchtool für Webdaten.

4. Der Agent stellt über das KI-Suchtool im privaten Netzwerk über einen privaten Endpunkt eine Verbindung mit Azure KI-Suche bereit.

5. Anforderungen an die meisten externen Tools, z. B. öffentliche MCP-Server oder benutzerdefinierte API-Tools, durchlaufen Azure Firewall zur Erzwingung von Inspektions- und Übergaberichtlinien. Anforderungen an private MCP-Server oder APIs verbleiben im virtuellen Netzwerk.

6. Der Agent stellt eine Verbindung mit seinem konfigurierten Sprachmodell her und übergibt den relevanten Kontext.

7. Bevor der Agent die Antwort an die Benutzeroberfläche zurücksendet, speichert er die Anfrage, die generierte Antwort sowie die Details zum Toolaufruf in der Kommunikation. Dieses in Azure Cosmos DB gespeicherte Unterhaltungsobjekt verwaltet den vollständigen Interaktionsverlauf als Dialogelemente (Nachrichten, Toolaufrufe und Toolausgaben). Dieser Verlauf unterstützt kontextabhängige Interaktionen und ermöglicht Benutzern das Fortsetzen von Unterhaltungen mit dem Agent, ohne dass der vorherige Kontext verloren geht.

   Die Foundry-APIs unterstützen die Entwicklung von Benutzeroberflächen, die mehrere gleichzeitige, kontextisolte Unterhaltungen verwalten.

Komponenten

Diese Architektur basiert auf der grundlegenden Referenzarchitektur des Foundry-Chats. Diese Architektur führt mehr Azure Dienste ein, um unternehmensweite Anforderungen an Zuverlässigkeit, Sicherheit und Betriebssteuerung zu erfüllen. Jede der folgenden Komponenten spielt eine bestimmte Rolle in einer Produktions-Unternehmenschatlösung:

• Der Foundry Agent Service ist eine cloudeigene Laufzeitumgebung, in der intelligente Agents sicher und autonom arbeiten können. In dieser Architektur stellt der Foundry Agent Service eine verwaltete Laufzeit für Eingabeaufforderungs-Agents bereit und ist in Azure-Dienste integriert. Es hostt und verwaltet Agents, die die folgenden Aufgaben ausführen:

  • Verarbeiten von Benutzeranforderungen
  • Orchestrierung von Aufrufen an Tools und andere Agenten
  • Inhaltssicherheit durchsetzen
  • Integrieren Sie mit Unternehmensidentität, Netzwerk und Überwachbarkeit

  Durch die Standard-Agent-Einrichtung wird die Netzwerkisolation sichergestellt und die Kontrolle über die Datenspeicherung bereitgestellt. Sie stellen dedizierte Azure Ressourcen für den Agentstatus, den Chatverlauf und die Dateispeicherung zur Verfügung, der Foundry Agent Service verwaltet sie jedoch ausschließlich. Andere Anwendungskomponenten in der Workload sollten diese erforderlichen Ressourcen nicht verwenden.

  • Azure Cosmos DB für NoSQL ist ein global verteilter Dokumentdatenbankdienst. In dieser Architektur hostet er die als enterprise_memory bezeichnete Speicherdatenbank der Workload innerhalb Ihres Abonnements. Diese Datenbank speichert den Betriebsstatus des Agents, einschließlich Chatunterhaltungen und Agentdefinitionen. Dieser Entwurf stellt sicher, dass der Chatverlauf und die Agentkonfiguration isoliert, auditierbar und gemäß den Anforderungen der Datengovernance verwaltet werden. Der Foundry Agent Service verwaltet die Datenbank, die zugehörigen Sammlungen und ihre Daten.

  • Azure Storage ist ein Cloudspeicherdienst für unstrukturierte Daten. In dieser Architektur bietet sie dedizierten Speicher für Dateien, die während Chatsitzungen hochgeladen wurden. Das Hosting dieses Kontos in Ihrem Abonnement bietet eine präzise Zugriffssteuerung, Überprüfungsfunktionen und die Einhaltung von Datenresidenz- oder Aufbewahrungsrichtlinien. Der Foundry Agent Service verwaltet die Container und den Datenlebenszyklus innerhalb dieser Container.

  • AI Search ist eine verwaltete Suchlösung, die Suchfunktionen bereitstellt. In dieser Architektur verwendet der Foundry Agent Service AI Search, um einen durchsuchbaren, gegliederten Index von Dateien zu speichern, die während der Unterhaltungen mit dem Agenten über das Tool "Dateisuche" hochgeladen wurden. AI Search speichert auch segmentierte, statische Dateien, die Sie bei der Erstellung eines Agenten als Wissensquellen hinzufügen. Diese Dateien bleiben für alle Agentaufrufe verfügbar. Der Foundry Agent Service verwaltet den Index, das Schema und die Daten und verwendet eine eigene Chunking-Strategie und Abfrage-Logik.

• Das Anwendungsgateway ist ein Web-Traffic-Load-Balancer und ein Application Delivery Controller. In dieser Architektur dient sie als sicherer, skalierbarer Einstiegspunkt für den gesamten HTTP- und HTTPS-Datenverkehr zur Chat-UI. Darüber hinaus bietet es TLS-Beendigung und pfadbasiertes Routing. Das Anwendungsgateway verteilt Anforderungen über Verfügbarkeitszonen, die hohe Verfügbarkeit und Leistung für die Webanwendungsebene unterstützen. Das Back-End ist die App Service-Instanz, die den Anwendungscode hosten soll.

  • Azure Web Application Firewall ist ein cloudeigener Dienst, der Webanwendungen vor allgemeinen Web-Exploits schützt. In dieser Architektur wird es in das Anwendungsgateway integriert, um die Chat-UI vor allgemeinen Webrisiken und Angriffen zu schützen. Sie prüft und filtert HTTP-Anforderungen, die eine Sicherheitsebene für öffentlich zugängliche Anwendungen bereitstellen.

  • Azure Key Vault ist ein Clouddienst zum sicheren Speichern und Zugreifen auf geheime Schlüssel, Schlüssel und Zertifikate. In dieser Architektur werden die TLS-Zertifikate, die das Anwendungsgateway benötigt, sicher gespeichert und verwaltet. Die zentralisierte Zertifikatsverwaltung in Key Vault unterstützt automatisierte Rotation, Überwachung und die Einhaltung von Sicherheitsstandards der Organisationen. Für diese Architektur sind keine gespeicherten Schlüssel oder andere geheime Schlüssel erforderlich.

• Azure Virtual Network ist der grundlegende Baustein für private Netzwerke in Azure. In dieser Architektur wird die Netzwerkisolation für alle Komponenten bereitgestellt, die Ihnen dabei helfen, Sicherheits- und Complianceanforderungen zu erfüllen. Wenn Sie Ressourcen in einem privaten virtuellen Netzwerk platzieren, steuern Sie den Ost-West- und Nord-Süd-Datenverkehr, erzwingen Segmentierung, halten Datenverkehr privat und stellen Eine Überprüfung von Eingangs- und Ausgangsflüssen bereit.

• Azure Private Link ist ein Netzwerkdienst, der private Verbindungen zwischen einem virtuellen Netzwerk und Azure PaaS-Diensten bereitstellt. In dieser Architektur verbindet sie alle PaaS-Dienste wie Azure Cosmos DB, Speicher, KI-Suche und Foundry Agent Service über private Endpunkte mit dem virtuellen Netzwerk. Private Link hilft Ihnen sicherzustellen, dass der gesamte Datenverkehr auf dem Azure Backbone bleibt, wodurch die Gefährdung des öffentlichen Internets beseitigt und die Angriffsfläche reduziert wird.

• Azure Firewall ist ein verwalteter, cloudbasierter Netzwerksicherheitsdienst. In dieser Architektur überprüft und kontrolliert das System den gesamten ausgehenden Datenverkehr aus dem virtuellen Netzwerk. Außerdem erzwingt er vollqualifizierte Domänennamen (FQDN)-basierte Regeln, wodurch sichergestellt wird, dass nur genehmigte Ziele erreichbar sind. Diese Konfiguration trägt dazu bei, Datenexfiltration zu verhindern und die Anforderungen für die Netzwerksicherheit zu erfüllen.

• Azure DNS ist ein Hostingdienst für DNS-Domänen (Domain Name System), der die Namensauflösung bereitstellt. In dieser Architektur stellt sie private DNS-Zonen bereit, die mit dem virtuellen Netzwerk verknüpft sind. Es behandelt die Namensauflösung für private Endpunkte, wodurch sichergestellt wird, dass alle Dienst-zu-Dienst-Kommunikation private IP-Adressen verwendet und innerhalb der Netzwerkgrenze verbleibt.

• Azure Storage ist ein Cloudspeicherdienst für unstrukturierte und strukturierte Daten. In dieser Architektur unterstützt sie sichere, automatisierte Bereitstellungsworkflows und trennt Anwendungsartefakte von Computeressourcen. Sie hostt den Webanwendungscode als ZIP-Datei für die Bereitstellung in App Service.

Modell- und Toolauswahl

Der Foundry Agent Service funktioniert nicht mit jedem Modell im Foundry-Modellkatalog. Der Katalog listet Modelle auf, die auf der Foundry-Plattform bereitgestellt werden können, aber ein Prompt-Agent kann nur eine Teilmenge davon verwenden, die vom Foundry Agent Service für die Nutzung durch Agenten validiert wurde.

Bevor Sie sich für ein Modell verpflichten, vergewissern Sie sich, dass Sie es in Ihrer Foundry-Region bereitstellen können und dass der Foundry Agent Service es unterstützt. Durchsuchen Sie den Modellkatalog, der auf agentgestützte Modelle im Foundry-Portal gefiltert ist, oder fragen Sie die Modelle programmgesteuert nach einer Region ab.

az cognitiveservices model list --location <location> --query "[?model.capabilities.agentsV2=='true']"

Ein Modell, das vom Foundry Agent Service unterstützt wird, unterstützt nicht zwangsläufig jede Agent-Funktion. Die Verfügbarkeit von Tools hängt sowohl vom Modell als auch von der Bereitstellungsregion ab. In dieser Architektur verwendet der Agent das KI-Suchtool und das Websuchtool, und nicht jedes unterstützte Modell funktioniert mit jedem Tool. Die vollständige Kompatibilitätsmatrix finden Sie unter Toolunterstützung nach Region und Modell.

Der Foundry Agent Service lehnt beim Definieren des Agents nicht immer eine nicht unterstützte Kombination ab. Wenn Sie einen Eingabeaufforderungs-Agent über die REST-API erstellen, kann ein nicht unterstütztes Modell oder eine Toolauswahl die Agenterstellung übergeben und dann unerwartetes Verhalten oder Laufzeitfehler verursachen, wenn der Agent das Modell oder Tool aufruft.

Alternatives

Diese Architektur umfasst mehrere Komponenten, die Sie je nach den funktionalen und nichtfunktionellen Anforderungen Ihrer Workload durch andere Azure Dienste oder Ansätze ersetzen können. Berücksichtigen Sie die folgenden Alternativen und Kompromisse.

Chat-Orchestrierung

Aktueller Ansatz: Diese Architektur verwendet den Foundry Agent Service , um die Ausführung von Eingabeaufforderungs-Agent-Abläufen zu koordinieren, einschließlich des Abrufens von Bodendaten über verbundene Tools, das Aufrufen von KI-Modellen und das Erzwingen eines konsistenten Reaktionsverhaltens basierend auf den Anweisungen auf Systemebene des Agents und des Unterhaltungsverlaufs. Der Foundry Agent Service bietet eine codelose, nichtdeterministische Orchestrierung für konversationelle KI-Workloads. Es verwaltet Chatanfragen, Unterhaltungsverlauf, Toolaufrufe, Inhaltssicherheit und Integration mit Identität, Netzwerk und Überwachbarkeit. Der Dienst unterstützt die Persistenz des Unterhaltungskontexts und des Agentstatus über ein vordefiniertes Datenmodell, das in einer Datenbank in Ihrem Abonnement bereitgestellt wird.

Alternativer Ansatz: Sie können benutzerdefinierte Ausführungslogik in einem gehosteten Agent implementieren, bei dem es sich um Ihre eigene deterministische, codegesteuerte Agent-Orchestrierungslogik handelt, die in einem Container im Foundry Agent Service ausgeführt wird. Ein gehosteter Agent muss den Laufzeitvertrag für Foundry implementieren, damit die Plattform ihn aufrufen kann. Sie erfüllen diesen Vertrag, indem Sie einen SDK-Adapter verwenden oder den Vertrag selbst implementieren, und Sie erstellen die eigene Logik des Agents mit einem Framework wie dem Agent Framework. Sie stellen diesen Code bereit als Containerimage, das Sie erstellen und in eine Azure Container Registry übertragen, die Ihnen gehört und die Sie verwalten.

In dieser Alternative behandelt Ihr Agentcode die Orchestrierung, und was die Plattform verwaltet, hängt vom Protokoll ab, das Ihr Agent verfügbar macht.

• Mit dem Responses-Protokoll verwaltet die Plattform den Konversationsverlauf und den Sitzungslebenszyklus, und Ihr Code erweitert das Ausführungsverhalten im Rahmen dieses Vertrags.

• Mit dem Invocations-Protokoll verwaltet Ihr Code den Sitzungszustand direkt, und die Plattform stellt keinen Konversationsverlauf bereit.

Jeder gehostete Agent erhält einen dedizierten Endpunktpfad bei der Bereitstellung, der einen eigenen Routing-, Zugriffssteuerungs- und Überwachungsumfang enthält.

Erwägen Sie gehostete Agenten anstelle von Prompt-Agenten, wenn Ihre Arbeitslast eine oder mehrere der folgenden Fähigkeiten erfordert:

• Verwendung von Modellen, die vom Foundry Agent Service nicht unterstützt werden, oder integration mit Tools, die vom Dienst nicht verfügbar gemacht werden

• Feinkörnige, deterministische Kontrolle über den Agent-Ausführungspfad, einschließlich expliziter Orchestrierungsmuster, Aufrufe externer Systeme oder Tools, Prompt-Engineering, Verbindung mit mehreren Agenten oder menschliche Eingriffe in den Prozess.

• Wiederverwenden vorhandener Codebasen oder Bibliotheken, die komplexe Geschäftsprozesse verarbeiten

• Agenten-Code-Überwachung, Inspektion oder Zertifizierung für Sicherheit, Einhaltung oder behördliche Zwecke

• Identitäts- und Endpunktisolation pro Agent, sodass Sie Zugriff auf geringste Rechte, Zugriffssteuerung und Überwachung für jeden Agent festlegen können, ohne Agents in verschiedene Projekte zu trennen

• Feinabstimmung der Konfiguration der Agent-Laufzeit, einschließlich CPU- und Speicherzuweisung für die Sandbox jeder Agentsitzung

• Erweiterter Arbeitsspeicher, der in einer separaten Datenbank zusammen mit dem Gesprächszustand des nativen Foundry Agent Service gespeichert ist.

Gehostete Agents werden weiterhin auf foundry-managed compute ausgeführt, sodass die Plattform weiterhin die Skalierung und die Kernlaufzeit verarbeitet. Die selbstgehostete Orchestrierung ist ein weiterer Schritt, bei dem Sie die Orchestrierungsebene auf Rechenressourcen ausführen, die Sie selbst betreiben, außerhalb des Foundry Agent Service. Wenn Sie Ihre eigene Infrastruktur ausführen, sind Sie für alle Laufzeitmerkmale, Kapazität und Sicherheit verantwortlich.

Komponenten der Anwendungsebene

Current approach: Die Front-End-Website der Chat-UI wird auf dem Web-Apps Feature von App Service gehostet, das eine verwaltete, skalierbare Plattform für Webanwendungen bereitstellt. Web-Apps integriert sich nativ in Azure Netzwerk- und Sicherheitsfeatures.

Alternative Approach: Sie können andere Azure verwaltete Computeplattformen wie Azure Container Apps oder Azure Kubernetes Service (AKS) verwenden, um die Anwendungsebene zu hosten.

Erwägen Sie diese Alternative, wenn Ihre Workload eine der folgenden Bedingungen erfüllt:

• Eine andere Computeplattform unterstützt besser bestimmte Anwendungsfälle, und die Verlagerung von Diensten auf dieser Plattform kann die Kosteneffizienz verbessern und Vorgänge vereinfachen.

• Für Ihre Anwendung sind anspruchsvollere Skalierung, Orchestrierung oder benutzerdefinierte Netzwerke erforderlich.

Der App-Dienst bleibt die bevorzugte Option für die Einfachheit beim Hosten von Webanwendungen und deren APIs.

Grundlagendatenspeicher (Wissensspeicher)

Aktueller Ansatz: Diese Architektur verwendet die KI-Suche als primären Datenspeicher für Grundlagenwissen. Es verwendet KI-Suche mit Vektor- und semantischen Ranking-Funktionen.

Alternativer Ansatz: Sie können andere Datenplattformen zum Erdnen von Wissen wie Azure Cosmos DB, Azure SQL-Datenbank oder anderen OLTP-Datenspeichern (Online Transaction Processing) verwenden. Ihre Datenplattform hängt von Ihren vorhandenen Datenbestands-, Daten-Aktualitätsanforderungen und Abfrageanforderungen ab.

Erwägen Sie diese Alternative, wenn Ihre Workload eine der folgenden Bedingungen erfüllt:

• Sie verwalten bereits Ihr Grundwissen in einer vorhandenen Transaktions- oder Betriebsdatenbank.

• Sie benötigen mehrmodell- oder SDK-Unterstützung, die in der KI-Suche nicht verfügbar ist.

• Sie müssen sich mit spezialisierten Datenquellen oder Altsystemen integrieren.

Die Vektorsuche ist typisch für die abfrage-unterstützte Erstellung (RAG), aber nicht immer notwendig. Weitere Informationen finden Sie unter Choose an Azure service for vector search. Bevor Sie einen Datenspeicher auswählen, bewerten Sie die Datenzugriffsmuster, Latenz und Skalierbarkeitsanforderungen Ihrer Workload.

Der vom Client verwaltete Chatverlauf

Aktueller Ansatz: Diese Architektur verwendet vom Service verwaltete Gespräche im Foundry-Agenten-Service, um den Chatverlauf in Azure Cosmos DB zu speichern. Der Dienst bietet Kontinuität über mehrere Runden und Sitzungen hinweg, ohne dass der Client den Status verwalten muss, und stellt bei der Generierung der Antwort automatisch die gesamte Konversation als Kontext bereit.

Alternativer Ansatz: Die Clientanwendung verwaltet den Unterhaltungsverlauf, anstatt ihn an den Agentdienst zu delegieren. Jede Antwort wird zustandslos generiert, und der Client übermittelt Ausgabeelemente aus früheren Antworten als Eingabe an nachfolgende Anforderungen.

Ziehen Sie eine vom Client verwaltete Konversationshistorie in Betracht, wenn Ihre Workload eine oder mehrere der folgenden Bedingungen erfüllt:

• Keine Datenaufbewahrung. Compliance- oder behördliche Anforderungen verbieten die serverseitige Persistenz von Unterhaltungsinhalten.

• Benutzerdefiniertes Kontextfenster-Steuerelement. Sie müssen frühere Runden selektiv einbeziehen, ausschließen, zusammenfassen oder lokal komprimieren, bevor Sie sie an das Modell senden.

• Mehrere UX-Kanäle mit unabhängiger Sitzungssemantik. Derselbe Agent wird von verschiedenen Anwendungen (Web, Mobil, VoIP) genutzt, die jeweils ihre eigenen Sitzungsverwaltungs-, Speicher- und Aufbewahrungsrichtlinien benötigen.

Dieser Ansatz verlagert die Verantwortung für die Zustandspermanenz, die Kontextverwaltung, die Data-Governance der Konversationsdaten und die Sitzungsisolierung auf Ihren Anwendungscode. Da der Konversationszustand in einem Datenspeicher liegt, der Ihnen gehört, müssen Sie Ihre eigenen Prozesse für Sicherung, Replikation und Wiederherstellung anwenden.

Berücksichtigen Sie die Grenzen des Kontextfensters und die erhöhte Nutzlastgröße der HTTP-Anforderungen durch die Weitergabe von Konversationselementen. Verwenden Sie für die Zuverlässigkeit bei mehreren Gesprächsrunden einen persistenten Speicher wie Azure Cosmos DB oder Ihre bestehende Anwendungsdatenbank anstelle eines reinen in-memory-Zustands.

Vordefinierter Agent oder dynamisch erstellte Agent

Aktueller Ansatz: Die Referenzimplementierung verwendet einen statisch definierten Agent, der als Microservice in Foundry bereitgestellt wird. Die Logik und Datenquellen des Agents werden bei der Bereitstellung konfiguriert und bleiben bis zur nächsten Anwendungsfreigabe unverändert. Dieser Ansatz funktioniert gut, wenn Agentverhalten und Datenquellen über DevOps-Prozesse stabil und gesteuert werden.

Alternativer Ansatz: Sie können Agents zur Laufzeit dynamisch erstellen oder ändern, indem Sie die Foundry-SDKs verwenden. Mit diesem Ansatz können die Anwendung Agents bei Bedarf instanziieren, Systemaufforderungen anpassen oder Verbindungen basierend auf Benutzerkontext oder Geschäftslogik neu konfigurieren.

Erwägen Sie dynamische Agents, wenn Ihre Workload die folgenden Funktionen erfordert:

• Personalisiertes Agent-Verhalten oder Datenquellen für jeden Benutzer oder jede Sitzung

• Häufige oder programmgesteuerte Änderungen an der Agentkonfiguration

• Kurzlebige, kontextspezifische Agentunterstützung für erweiterte Benutzeroberflächen

Dynamisches Agentenmanagement erhöht Flexibilität, führt aber auch die Last des Lebenszyklusmanagements ein. Stellen Sie sicher, dass Sie über geeignete Kontrollmechanismen für die Erstellung, Änderung und Bereinigung von Agenten verfügen.

Wählen Sie den Agent-Ansatz aus, der den Anforderungen ihrer Workload an die Benutzerfreundlichkeit entspricht.

Einzel-Agent- oder Multiagent-Orchestrierung

Aktueller Ansatz: Diese Referenzarchitektur verwendet einen einzelnen Agent, der Zugriff auf alle erforderlichen Tools hat, um die meisten Benutzerinteraktionen effektiv zu verarbeiten.

Alternativer Ansatz: Sie können mehrere spezialisierte Agents koordinieren, bei denen sich jeder Agent auf bestimmte Domänen konzentriert, verschiedene Modelle verwendet oder auf unterschiedliche Tools zugreift.

Berücksichtigen Sie einen Multiagent-Ansatz, wenn Ihre Workload die folgenden Merkmale aufweist:

• Anforderungen umfassen mehrere Fachgebiete, z. B. Finanzanalyse, Rechtliche Überprüfung und technische Implementierung. Spezialisierte Agents bieten tiefere, genauere Antworten innerhalb ihrer jeweiligen Domänen.

• Informationen erfordern unterschiedliche Berechtigungsstufen. Ein Personalmitarbeiter kann auf Mitarbeiterdaten zugreifen, während ein Kundendienstmitarbeiter nur auf Produktinformationen zugreift. Multiagent-Architekturen unterstützen granulare Sicherheitsgrenzen auf Agentebene.

• Verschiedene Abfrageinteraktionen profitieren von verschiedenen Modellen. Ein einfaches Modell verarbeitet einfache Fragen, während ein leistungsfähigeres Modell komplexe Denkaufgaben verarbeitet. Dieser Ansatz optimiert sowohl Kosten als auch Latenz.

• Die Chaterfahrung dient als Front-End für Geschäftsprozesse, die sequenzielle oder parallele Schritte erfordern, die unterschiedliche Spezialisten erfordern.

Multiagent-Ansätze führen aufgrund der Kommunikation zwischen Agenten zu einer Koordinationskomplexität und erhöhter Latenz. Für gut definierte Szenarien ohne strenge Zugriffsisolationsanforderungen erfüllt ein einzelner Agent, der ein Modell und geeignete Tools verwendet, die die Anforderungen erfüllen.

Der Foundry Agent Service unterstützt das Verbinden von Agents mit externen Agents und Tools über Standardprotokolle. Sie können eine Verbindung mit Tools herstellen, die auf MCP-Servern (Model Context Protocol) und anderen Agents über Agent-to-Agent-Endpunkte (A2A) gehostet werden. Öffentliche MCP-Serverendpunkte erfordern Firewallregeln für den Ausgang. Private MCP-Serverendpunkte erfordern die Standard-Agent-Einrichtung mit privatem Netzwerk und einem dedizierten Subnetz. Konfigurieren Sie die entsprechende Authentifizierung für jeden Endpunkt.

Weitere Informationen zum Implementieren mehrerer koordinierter Agents finden Sie unter AI-Agent-Orchestrierungsmuster. In diesem Artikel werden sequenzielle, gleichzeitige Gruppenchats, Übergaben und magentische Orchestrierungsansätze behandelt. Sie können einige Muster im Foundry Agent Service implementieren. Andere Muster erfordern selbst gehostete Orchestrierung mithilfe eines SDK wie Agent Framework.

Überlegungen

Diese Überlegungen implementieren die Säulen des Azure Well-Architected-Frameworks, die eine Reihe von Leitsätzen sind, die Sie verwenden können, um die Qualität einer Arbeitsauslastung zu verbessern. Weitere Informationen finden Sie unter Well-Architected Framework.

Wenden Sie diese Architektur und die Entwurfsrichtlinien für AI-Workloads auf Azure während der Entwurfsphase Ihrer Workloads an.

Zuverlässigkeit

Zuverlässigkeit trägt dazu bei, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie für Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für Zuverlässigkeit.

Die grundlegende App Service-Webanwendungsarchitektur konzentriert sich auf Zonenredundanz für wichtige regionale Dienste. Verfügbarkeitszonen sind physisch getrennte Standorte innerhalb einer Region, die Redundanz bieten, wenn Sie zwei oder mehr Instanzen auf diese Weise bereitstellen. Wenn eine Zone Ausfallzeiten erlebt, bleiben andere Zonen in der Region möglicherweise nicht betroffen. Die Architektur verteilt auch Instanzen und Konfigurationen von Azure Diensten über Verfügbarkeitszonen hinweg. Weitere Informationen finden Sie unter Baseline hochverwendbarte zonenredundante Webanwendung.

In diesem Abschnitt wird die Zuverlässigkeit für Komponenten behandelt, die nicht in der Basisarchitektur des App-Diensts behandelt werden, insbesondere foundry und AI Search.

Zonenredundanz in der Orchestrierungsebene

Unternehmensbereitstellungen erfordern in der Regel Zonenredundanz, um das Risiko von Dienstunterbrechungen durch Fehler auf Zonenebene zu minimieren. In Azure bedeutet Zonenredundanz, dass Sie Ressourcen verwenden, die verfügbarkeitszonen unterstützen und mindestens drei Instanzen bereitstellen oder Redundanz auf Plattformebene aktivieren, wenn die direkte Instanzsteuerung nicht verfügbar ist.

In dieser Architektur hosten Foundry die Foundry Agent Service-Funktion. Die Zuverlässigkeit des Agents hängt von der Verfügbarkeit der Abhängigkeiten des Foundry Agent Service ab, die Azure Cosmos DB, Speicher und KI-Suche sind. Der Foundry Agent Service verwaltet die Daten innerhalb dieser Dienste, aber Sie konfigurieren ihre Zuverlässigkeit in Ihrem Abonnement.

Befolgen Sie die folgenden Empfehlungen, um Zonenredundanz für die Orchestrierungsebene zu erreichen:

• Verwenden Sie zone Redundanz in Ihrem Azure Cosmos DB für NoSQL Konto. Diese Konfiguration stellt die synchrone Datenreplikation über mehrere Zonen hinweg sicher, wodurch das Risiko von Datenverlusten oder Ausfallzeiten durch einen Ausfall einer einzelnen Zone reduziert wird.

  Erwägen Sie auch globale Verteilung, um regionale Ausfälle innerhalb Azure Cosmos DB zu mindern.

• Verwenden Sie den zonenredundanten Speicher (ZRS) für Ihr Speicherkonto. Verwenden Sie für eine höhere Resilienz den geozonenredundanten Speicher (GZRS), der Zonen- und Regionalredundanz kombiniert.

• Konfigurieren Sie Ihre KI-Suchinstanz mit mindestens drei Replikaten. Diese Konfiguration stellt sicher, dass der Dienst Replikate über eindeutige Zonen in Ihrer Region verteilt.

Wenn Ihr Agent in andere workloadspezifische Abhängigkeiten integriert ist, z. B. benutzerdefinierte Toolverbindungen oder externe Datenquellen, stellen Sie sicher, dass diese Abhängigkeiten Ihren Verfügbarkeits- und Redundanzanforderungen entsprechen. Jede einzelzonen- oder nicht redundante Abhängigkeit kann die Gesamtzuverlässigkeit der Orchestrierungsebene beeinträchtigen.

Das Foundry-Portal, seine Datenebenen-APIs und die Funktion "Foundry Agent Service" bieten keine direkten Steuerelemente für Zonenredundanz.

Zuverlässigkeit im Hosting des Foundry-Modells

Foundry stellt Modelle als Dienst (MaaS) bereit, die mit mehreren Bereitstellungsoptionen gehostet werden. Diese Optionen unterstützen in erster Linie die Kontingent- und Durchsatzverwaltung und nicht die herkömmliche hohe Verfügbarkeit innerhalb einer Region. Standardmodellbereitstellungen werden in einer einzelnen Region ausgeführt und unterstützen keine Verfügbarkeitszonen. Um die Verfügbarkeit über mehrere Rechenzentren hinweg zu erreichen, müssen Sie entweder eine globale Bereitstellung oder ein Datenzonenmodell verwenden.

Stellen Sie für Unternehmenschatszenarien sowohl eine bereitgestellte Datenzone als auch ein Datenzonen-Standardmodell bereit. Konfigurieren Sie Spillover, um übermäßigen Datenverkehr oder Ausfälle zu bewältigen. Wenn Ihre Workload keine geringe Latenz oder strenge geografische Datenbewahrung und -verarbeitung erfordert, verwenden Sie globale Bereitstellungen für maximale Resilienz.

Foundry unterstützt keine erweiterten Lastverteilungs- oder Failover-Mechanismen wie Round-Robin-Routing oder Circuit Breaking für Modellbereitstellungen. Wenn Sie granulare Redundanz und Failover-Steuerung innerhalb einer Region benötigen, hosten Sie die Modellzugriff-Logik außerhalb des verwalteten Dienstes. Sie können beispielsweise ein benutzerdefiniertes Gateway mithilfe von Azure API Management erstellen. Mit diesem Ansatz können Sie benutzerdefinierte Routing-, Integritätsprüfungen und Failoverstrategien implementieren. Sie erhöht aber auch die Betriebskomplexität und verschiebt die Verantwortung für die Zuverlässigkeit dieser Komponente in Ihr Team.

Sie können auch gateway-gestützte Modelle als benutzerdefinierte, API-basierte Werkzeuge für Ihren Agenten verfügbar machen. Weitere Informationen finden Sie unter Verwenden Sie ein Gateway vor mehreren Azure OpenAI-Bereitstellungen oder -Instanzen.

Zuverlässigkeit in der KI-Suche nach Unternehmenskenntnissen

Stellen Sie die KI-Suche mithilfe des Standard-Preisniveaus oder höher in einer Region bereit, die Verfügbarkeitszonen unterstützt. Konfigurieren Sie mindestens drei Replikate, um sicherzustellen, dass der Dienst Instanzen über separate Verfügbarkeitszonen verteilt. Diese Konfiguration bietet Resilienz für Fehler auf Zonenebene und unterstützt hohe Verfügbarkeit für Suchvorgänge.

Verwenden Sie die folgenden Methoden, um die optimale Anzahl von Replikaten und Partitionen für Ihre Workload zu ermitteln:

• Überwachen Sie die KI-Suche mithilfe integrierter Metriken und Protokolle. Überwachen Sie die Abfragelatenz, Drosselung und Ressourcennutzung.

• Verwenden Sie Überwachungsmetriken und Protokolle und Leistungsanalysen, um die entsprechende Anzahl von Replikaten zu ermitteln. Dieser Ansatz hilft Ihnen, Drosselungen aufgrund eines hohen Abfragevolumens, unzureichender Partitionen oder Indexbeschränkungen zu vermeiden.

• Stellen Sie die Zuverlässigkeit der Indizierung sicher, indem Sie Unterbrechungen durch regelmäßige Indizierung oder Indizierungsfehler vermeiden. Erwägen Sie, in einen Offlineindex zu indizieren, und ersetzen Sie Ihren Liveindex durch Ihren neu erstellten Index, nachdem Sie die Datenintegrität überprüft haben.

Zuverlässigkeit in Azure Firewall

Azure Firewall ist eine kritische Egress-Kontrollstelle in dieser Architektur, stellt jedoch einen einzelnen Ausfallpunkt für den gesamten ausgehenden Datenverkehr dar. Um dieses Risiko zu verringern, stellen Sie Azure Firewall across alle Verfügbarkeitszonen in Ihrer Region bereit. Diese Konfiguration trägt dazu bei, ausgehende Verbindungen aufrechtzuerhalten, wenn eine Zone nicht verfügbar ist.

Wenn Ihre Workload ein hohes Volumen gleichzeitiger ausgehender Verbindungen erfordert, konfigurieren Sie Azure Firewall mit mehreren öffentlichen IP-Adressen. Dieser Ansatz verteilt SNAT-Verbindungen (Source Network Address Translation) über mehrere IP-Adresspräfixe, wodurch das Risiko einer SNAT-Portausschöpfung reduziert wird. Die SNAT-Erschöpfung kann zu unterbrechungs- oder totalem Verlust der ausgehenden Konnektivität für Agents und andere Workloadkomponenten führen, was zu Ausfallzeiten von Features oder zu leistungseinbußen führt.

Überwachen sie die SNAT-Portnutzung und den Firewallstatus. Wenn Sie Verbindungsfehler oder Durchsatzprobleme erkennen, überprüfen Sie Firewallmetriken und Protokolle, um SNAT-Erschöpfung oder andere Engpässe zu identifizieren und zu beheben.

Abhängigkeiten des Foundry Agent Service von ähnlichen Workloads isolieren

Um die Zuverlässigkeit zu maximieren und den Strahlradius von Fehlern zu minimieren, isolieren Sie die Abhängigkeiten des Foundry Agent Service streng von anderen Workloadkomponenten, die dieselben Azure Dienste verwenden. Insbesondere sollten Sie AI Search-, Azure Cosmos DB- oder Storage-Ressourcen nicht zwischen dem Agent-Dienst und anderen Anwendungskomponenten gemeinsam nutzen. Stellen Sie stattdessen dedizierte Instanzen für die erforderlichen Abhängigkeiten des Agentdiensts bereit.

Diese Trennung bietet zwei wichtige Vorteile:

• Sie enthält Fehler oder Leistungsbeeinträchtigungen für ein einzelnes Workloadsegment, wodurch kaskadierende Effekte über nicht verwandte Anwendungsfeatures hinweg verhindert werden.

• Auf diese Weise können Sie gezielte betriebliche Prozesse wie Sicherung, Wiederherstellung und Failover anwenden. Diese Prozesse richten sich an die spezifischen Verfügbarkeits- und Wiederherstellungsanforderungen des Workloadflusses, der diese Ressourcen verwendet.

Wenn Ihre Chat-UI-Anwendung beispielsweise den Transaktionsstatus in Azure Cosmos DB speichern muss, richten Sie für diesen Zweck ein separates Azure Cosmos DB Konto und eine eigene Datenbank ein, anstatt das Konto oder die Datenbank erneut zu verwenden, das der Foundry Agent Service verwaltet. Selbst wenn kosten- oder betriebliche Einfachheit die Ressourcenfreigabe motiviert, überwiegt das Risiko eines Zuverlässigkeitsereignisses, das sich auf nicht verwandte Workloadfeatures auswirkt, die potenziellen Einsparungen in den meisten Unternehmensszenarien.

Von Bedeutung

Wenn Sie aus Kosten- oder Betriebsgründen arbeitslastspezifische Daten zusammen mit den Abhängigkeiten des Agent bereitstellen, interagieren Sie niemals direkt mit den vom System verwalteten Daten, wie Sammlungen, Containern oder Indizes, die der Foundry Agent Service erstellt. Diese internen Implementierungsdetails sind nicht dokumentiert und können ohne vorherige Ankündigung geändert werden. Der direkte Zugriff kann den Agentdienst unterbrechen oder zu Datenverlust führen. Verwenden Sie immer die Findry Agent Service-Datenebenen-APIs für die Datenmanipulation, z. B. das Erfüllen des Rechts auf Vergessenwerden (RTBF)-Anforderungen. Behandeln Sie die zugrunde liegenden Daten als unzugänglich und überwachen Sie sie nur.

Mehrregionen-Design

Diese Architektur verwendet Verfügbarkeitszonen für hohe Verfügbarkeit innerhalb einer einzelnen Azure Region. Es ist keine Multiregion-Lösung. Es fehlen die folgenden kritischen Elemente, die für regionale Resilienz und Notfallwiederherstellung (DR) erforderlich sind:

• Globale Eingangs- und Datenverkehrsweiterleitung
• DNS-Verwaltung für Failover
• Datenreplikations- oder Isolationsstrategien in allen Regionen
• Eine Aktiv-Aktiv-, Aktiv-Passiv- oder Aktiv-Kalt-Zuordnung
• Regionale Failover- und Failback-Prozesse zur Einhaltung von Wiederherstellungszeitzielen (RTOs) und Wiederherstellungspunktzielen (RPOs)
• Berücksichtigung der regionalen Verfügbarkeit für Entwicklererfahrungen, einschließlich des Foundry-Portals und der Datenebene-APIs.

Wenn Ihre Workload Geschäftskontinuität erfordert, wenn ein regionaler Ausfall auftritt, müssen Sie zusätzliche Komponenten und betriebliche Prozesse über diese Architektur hinaus entwerfen und implementieren. Insbesondere müssen Sie den Lastenausgleich und failover auf jeder Architekturebene behandeln, einschließlich der folgenden Bereiche:

• Datenabgleichstools und die ihnen zugrunde liegenden Datenspeicher
• Modellhosting- und Ableitungsendpunkte
• Die Orchestrierungs- oder Agentenschicht
• Benutzerorientierter UI-Datenverkehr und DNS-Einstiegspunkte

Sie müssen auch sicherstellen, dass Überwachbarkeit, Monitoring und Inhaltsicherheit in allen Regionen funktionsfähig und konsistent bleiben.

Diese Basisarchitektur verfügt nicht über multiregionsübergreifende Funktionen, sodass regionale Ausfälle wahrscheinlich zu einem Dienstverlust innerhalb Ihrer Workload führen.

Notfallwiederherstellung

Die Chatarchitekturen enthalten zustandsbehaftete Komponenten, daher müssen Sie für Disaster Recovery (DR) planen. Diese Workloads erfordern in der Regel einen Speicher für aktive oder angehaltene Chatsitzungen. Sie benötigen außerdem Speicherplatz für zusätzliche Daten, wie Dokumente oder Bilder, die zu Chats hinzugefügt werden. Die Agent-Orchestrierungsebene kann auch den Status aufrechterhalten, der für Gesprächsabläufe spezifisch ist. In dieser Architektur verwendet der Foundry Agent Service Azure Cosmos DB, Storage und AI Search, um den Betriebs- und Transaktionsstatus beizubehalten. Der Lebenszyklus und die Kopplung dieses Zustands über Komponenten hinweg bestimmen Ihre DR-Strategie und Wiederherstellungsvorgänge.

Der Foundry Agent Service bietet keine integrierten DR-Funktionen. Es fehlt an Funktionen zum Replizieren des Zustands, zum Erstellen von Sicherungen oder zum Ausführen von Point-in-Time-Wiederherstellungen. Die Wiederherstellung erfolgt durch Rekonstruktion, nicht durch die Hochstufung einer Replik. Ein Zwischenfall kann Agenten, Konversationen und Wissensdaten dauerhaft entfernen. Planen Sie die Möglichkeit des totalen Zustandsverlusts für zustandsbehaftete Inhalte und legen Sie die Wiederherstellungserwartungen entsprechend mit den Beteiligten fest.

Die folgenden kompensierenden Kontrollen, basierend auf dem Foundry-Agentendienst-DR-Leitfaden, verringern die Wahrscheinlichkeit und den Umfang des Datenverlusts, beseitigen ihn jedoch nicht.

• Azure Cosmos DB: Aktivieren Sie die fortlaufende Sicherung für die enterprise_memory Datenbank, einschließlich Agentdefinitionen und Chatunterhaltungen. Die kontinuierliche Sicherung ermöglicht eine Point-in-Time-Wiederherstellung (PITR) zu jedem Zeitpunkt innerhalb des Aufbewahrungszeitraums, der die vorherigen sieben Tage umfasst. Testen Sie ihren Wiederherstellungsvorgang regelmäßig, um sicherzustellen, dass er Ihren RTO erfüllt und dass die wiederhergestellten Daten für den Agentdienst verfügbar bleiben. Stellen Sie immer dasselbe Konto und dieselbe Datenbank wieder her.

• KI-Suche: DIE KI-Suche verfügt nicht über integrierte Wiederherstellungsfunktionen und unterstützt keine direkte Indexmanipulation. Wenn Datenverlust oder Beschädigung auftritt, müssen Sie sich an Microsoft-Support wenden, um Unterstützung bei den verfügbaren Indexwiederherstellungsoptionen zu erhalten. Diese Einschränkung kann sich erheblich auf Ihre RTO auswirken. Wenn Ihre Chat-UI Dateiuploads nicht unterstützt und Sie keine Agents haben, die statische Dateien als Wissen verwenden, benötigen Sie möglicherweise keinen DR-Plan für die KI-Suche.

  Bewahren Sie eine separate, regelmäßig aktualisierte verlässliche Informationsquelle für Ihr unternehmensspezifisches Wissen auf. Diese Übung stellt sicher, dass Sie Indizes bei Bedarf neu erstellen können.

• Speicher: Wenn Sie über ein georedundantes Speicherkonto verfügen, verwenden Sie kundenseitig verwaltetes Failover für Blob-Container, die vom Foundry Agent Service genutzt werden. Mit diesem Setup können Sie ein Failover während eines regionalen Ausfalls initiieren. Wenn Sie nur ZRS verwenden, wenden Sie sich an Microsoft Support zum Wiederherstellen von Daten. Dieser Vorgang kann Ihr RTO verlängern. Wie bei der KI-Suche benötigen Sie möglicherweise keinen DR-Plan für BLOB-Container, wenn Ihre Chat-UI Dateiuploads nicht unterstützt und Sie keine Agents haben, die statische Dateien als Wissen verwenden.

• Transaktionale Konsistenz: Wenn der Statusspeicher in Ihrer Workload auf Azure AI-Agent-IDs wie Konversations-IDs oder Agent-IDs verweist, koordinieren Sie die Wiederherstellung über alle relevanten Datenspeicher hinweg. Das Wiederherstellen einer Teilmenge von Abhängigkeiten kann zu verwaisten oder inkonsistenten Daten führen. Entwerfen Sie Ihre DR-Prozesse, um die referentielle Integrität zwischen Ihrer Arbeitslast und dem Status des Agentendienstes aufrechtzuerhalten.

• Agentdefinitionen und -konfiguration: Definieren Sie Agents als Code. Speichern von Agentdefinitionen, Verbindungen, Systemaufforderungen und Parametern in der Quellcodeverwaltung. Diese Vorgehensweise ermöglicht es Ihnen, Agents aus einer bekanntermaßen fehlerfreien Konfiguration neu bereitzustellen, falls die Orchestrierungsebene ausfällt. Vermeiden Sie es, nicht nachverfolgte Änderungen an der Agentkonfiguration über das Findry-Portal oder Datenebenen-APIs vorzunehmen. Durch diesen Ansatz wird sichergestellt, dass Ihre bereitgestellten Agents reproduzierbar bleiben.

• Foundry-Projekte: Verwenden Sie eine benutzerseitig zugewiesene verwaltete Identität als Identität für ein Projekt. Wenn das Projekt versehentlich gelöscht wird, können Sie mit einer vom Benutzer zugewiesenen verwalteten Identität Ihre vorhandenen Rollenzuweisungen wiederverwenden, wenn Sie das Projekt und dessen Funktionshost erneut erstellen. Durch diesen Ansatz wird die Koordination reduziert, die bei der Wiederherstellung von Projektabhängigkeiten erforderlich ist.

Als zusätzliche präventive Maßnahme für die Abhängigkeiten des Foundry Agent Service fügen Sie jedem Dienst eine Löschressourcensperre hinzu. Diese Praxis trägt zum Schutz vor katastrophalem Zustandsverlust in der KI-Suche, Azure Cosmos DB und Cloud-Speicher bei.

Bevor Sie in die Produktion übergehen, erstellen Sie ein Wiederherstellungs-Runbook, das Fehler sowohl im anwendungseigenen Zustand als auch im agenteigenen Zustand behandelt.

Sicherheit

Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Entwurfsprüfliste für die Sicherheit.

Diese Architektur erweitert die Sicherheitsbasis, die in der grundlegenden Referenzarchitektur des Foundry-Chats eingerichtet wurde. Es fügt einen Netzwerksicherheitsperimeter neben dem Identitätsperimeter aus der grundlegenden Architektur hinzu. Aus Netzwerksicht ist Das Anwendungsgateway die einzige ressource, die über das Internet verfügbar gemacht wird. Die Chat-UI-Anwendung wird benutzern zur Verfügung gestellt. Aus Identitätsperspektive sollte die Chat-UI Anforderungen authentifizieren und autorisieren. Verwenden Sie verwaltete Identitäten, wenn möglich, um Anwendungen für Azure Dienste zu authentifizieren.

Identitäts- und Zugriffsverwaltung

Diese Architektur verwendet in erster Linie vom System zugewiesene verwaltete Identitäten für die Dienst-zu-Dienst-Authentifizierung. Sie können auch vom Benutzer zugewiesene verwaltete Identitäten verwenden. Wenden Sie in beiden Fällen die folgenden Prinzipien an:

• Isolieren Sie Identitäten nach Ressource und Funktion. Erstellen Sie unterschiedliche verwaltete Identitäten für die folgenden Komponenten:

  • Die Foundry-Ressource
  • Jedes Foundry-Projekt
  • Die Webanwendung
  • Application Gateway
  • Beliebiger benutzerdefinierter Orchestrator- oder Integrationscode

• Verwenden Sie Zuordnungseinschränkungen (Vorschau). Microsoft.CognitiveServices/accounts/projects Nur für Foundry-Projektidentitäten, Microsoft.Web/sites für Webanwendungsidentitäten und Microsoft.Network/applicationGateways für Anwendungsgatewayidentitäten zulassen. Legen Sie den Isolationsbereich auf Regional, und erstellen Sie einen separaten Satz von Identitäten für jede Bereitstellungsregion.

• Weisen Sie einer Azure Ressource nur eine Identität zu, wenn diese Ressource sich als Client bei einem anderen Azure Dienst authentifizieren muss.

• Verwenden Sie zweckmäßige Identitätstypen. Verwenden Sie nach Möglichkeit Arbeitsauslastungsidentitäten für Anwendungen und Automatisierung, und verwenden Sie Agent-Identitäten für KI-Agents.

Gemeinsame Nutzung und Isolierung von Foundry-Ressourcen

Diese Architektur stellt eine dedizierte Foundry-Ressource für einen einzelnen Produktionsworkload bereit. Die vollständig isolierte Workloadtopologie ist die empfohlene Topologie für Produktionsworkloads. Die Foundry-Ressource ist die Netzwerkgrenze und die Identitätsgrenze für alles, was darin ausgeführt wird. Eine dedizierte Ressource trennt den Compliance-Bereich, den Blast-Radius und das Kontingent dieser Arbeitslast von nicht damit verbundenen Arbeitslasten sowie von Ihren Vorproduktionsumgebungen. Diese Wahl entspricht den veröffentlichten Leitlinien zur gemeinsamen Nutzung von KI-Plattformen, in denen empfohlen wird, standardmäßig eine einzige KI-Plattform-Instanz pro Produktions-Arbeitslast zu verwenden.

Die vollständig isolierte Topologie verursacht im Vergleich zur gemeinsamen Ausführung von Workloads in einer gemeinsam genutzten Foundry-Ressource zusätzlichen Einrichtungs- und Verwaltungsaufwand. Diese Architektur akzeptiert diesen Kompromiss im Austausch für Segmentierung und unabhängige Zugriffssteuerung, Kontingent und Kostengrenzen, die für die meisten Produktionsworkloads erforderlich sind.

Verbindungen

Verbindungen definieren, wie sich eine Foundry-Ressource oder ein einzelnes Projekt bei einer externen Abhängigkeit authentifiziert und diese nutzt. Erstellen Sie nach Möglichkeit Verbindungen auf Projektebene. Entfernen Sie nicht verwendete Verbindungen. Bevorzugen Sie Microsoft Entra ID-basierte Authentifizierung für alle Verbindungen.

Wenn eine Verbindung Microsoft Entra ID nicht unterstützt, müssen Sie einen geheimen Schlüssel wie einen API-Schlüssel angeben. Speichern Sie diese Geheimnisse in einem dedizierten, selbst gehosteten Azure Schlüsseltresor. Konfigurieren Sie eine Azure Key Vault Verbindung für die Foundry-Ressource, damit der Dienst die geheimen Schlüssel lesen und schreiben kann, die es verwaltet.

Verwenden Sie diesen Schlüsselspeicher ausschließlich für Foundry. Teilen Sie sie nicht mit anderen Workloadkomponenten. Alle Nicht-Microsoft Entra ID Verbindungen in allen Projekten in der Ressource speichern ihre geheimen Schlüssel in diesem Tresor. Andere Workloadkomponenten benötigen keinen Zugriff auf diese geheimen Schlüssel, um Foundry-Funktionen zu verwenden. Erteilen Sie anderen Komponenten keine Lese- oder Schreibberechtigungen für diesen Tresor, es sei denn, Sie haben eine klare betriebliche Anforderung, oder akzeptieren Sie den Kompromiss.

Diese Architektur umfasst zwei API-schlüsselbasierte Verbindungen: Application Insights for Foundry-Metriken und das Websuchtool. Wenn Sie diese Architektur mit Tools erweitern, die externe HTTP-Endpunkte aufrufen, z. B. MCP-Server oder openAPI-definierte APIs, fügt jedes Tool eine Projektverbindung hinzu, die seine Authentifizierungsanmeldeinformationen enthält.

Wenn Sie einen MCP-Server verbinden, beschränken Sie die verfügbaren Tools mithilfe von allowed_tools. Erfordern und protokollieren Sie die Genehmigung für Vorgänge mit hohem Risiko, z. B. Tools, die Daten schreiben oder Ressourcen ändern, und überprüfen Sie den Namen und die Argumente des Tools vor der Genehmigung. Weitere Informationen finden Sie unter MCP best practices.

Wenn Sie vom Kunden verwaltete Schlüssel für die Verschlüsselung verwenden, können Sie sowohl die vom Kunden verwalteten Schlüssel als auch die Verbindungsschlüssel im selben dedizierten Tresor hosten, wenn Ihre Sicherheitsgovernancerichtlinien die Kolocation von Verschlüsselungsschlüsseln und geheimen Schlüsseln ermöglichen.

Zugriff auf das Foundry-Portal für Mitarbeiter

Wenn Sie Mitarbeiter in Foundry-Projekte integrieren, weisen Sie die für ihre Rolle erforderlichen Mindestberechtigungen zu. Verwenden Sie Microsoft Entra ID Gruppen und Azure rollenbasierte Zugriffssteuerung (Azure RBAC), um die Trennung von Aufgaben zu erzwingen. Unterscheiden Sie beispielsweise Agententwickler von Datenwissenschaftlern, die Feinabstimmungsaufgaben ausführen. Aber verstehen Sie die Einschränkungen und Risiken. Ordnen Sie Personas den in Foundry integrierten Rollen und Azure RBAC-Rollen zu, z. B.:

Persona	Eingebaute Rolle	Geltungsbereich
Ressourcen-Manager für Foundry	Besitzer des Foundry-Kontos	Foundry-Ressource
Agent-Entwickler oder Data Scientist	Foundry-Benutzer im Foundry-Projekt sowie Leser der Foundry-Ressource	Foundry-Projekt und Foundry-Ressource

Die Berechtigungen in den einzelnen integrierten Rollen und zusätzlichen Enterprise-Zuordnungsbeispielen finden Sie unter Role-basierte Zugriffssteuerung für Microsoft Foundry.

Das Foundry-Portal führt viele Aktionen aus, indem die Identität des Diensts anstelle der Identität des Mitarbeiters verwendet wird. Daher haben Mitarbeiter, die eingeschränkte Azure RBAC-Rollen haben, möglicherweise Einblicke in vertrauliche Daten, z. B. Chatunterhaltungen, Agentdefinitionen und Konfiguration. Dieses Findry-Portaldesign kann versehentlich Ihre gewünschten Zugriffsbeschränkungen umgehen und mehr Informationen als beabsichtigt verfügbar machen.

Um das Risiko eines nicht autorisierten Zugriffs zu verringern, beschränken Sie die Portalnutzung in Produktionsumgebungen auf Mitarbeiter, die über einen klaren betrieblichen Bedarf verfügen. Für die meisten Mitarbeiter können Sie den Zugriff auf das Foundry-Portal in der Produktion widerrufen oder blockieren. Verwenden Sie stattdessen automatisierte Bereitstellungspipelinen und -infrastruktur als Code (IaC), um die Agent- und Projektkonfiguration zu verwalten.

Behandeln Sie das Erstellen neuer Projekte in einer Foundry-Ressource als privilegierte Aktion. Projekte, die über das Portal erstellt wurden, erben nicht automatisch Ihre etablierten Netzwerksicherheitskontrollen, z. B. private Endpunkte oder Netzwerksicherheitsgruppen (NSGs). Neue Agents in diesen Projekten umgehen Ihren vorgesehenen Sicherheitsperimeter. Erzwingen Sie die Projekterstellung ausschließlich über Ihre kontrollierten, auditierbaren IaC-Prozesse.

Gießerei-Projekt-Rollenzuweisungen und -Verbindungen

Um den Foundry Agent Service im Standardmodus zu verwenden, muss das Projekt über Berechtigungen für Daten und Steuerungsebenen für die Abhängigkeiten des Foundry Agent Service verfügen. Insbesondere muss die verwaltete Identität des Projekts über erhöhte Rollenzuweisungen für das Speicherkonto, die KI-Suche und das Azure Cosmos DB-Konto verfügen. Diese Berechtigungen bieten nahezu vollständigen Zugriff auf diese Ressourcen, einschließlich der Möglichkeit, Daten zu lesen, zu schreiben, zu ändern oder zu löschen. Um den Zugriff mit geringstmöglichen Berechtigungen zu gewährleisten, isolieren Sie Ihre Workload-Ressourcen von den Abhängigkeiten des Foundry Agent Service.

Alle Agents innerhalb eines einzelnen Foundry-Projekts verwenden dieselbe verwaltete Identität. Wenn Ihre Workload mehrere Agents verwendet, die Zugriff auf verschiedene Ressourcengruppen erfordern, befolgen Sie das Prinzip der geringsten Berechtigungen und erstellen ein separates Foundry-Projekt für jedes unterschiedliche Agent-Zugriffsmuster. Mit dieser Trennung können Sie nur die mindestens erforderlichen Berechtigungen für die verwaltete Identität jedes Projekts zuweisen, wodurch das Risiko eines übermäßigen oder unbeabsichtigten Zugriffs reduziert wird. Dieses Modell der gemeinsamen Identität gilt für die Prompt-Agents in dieser Architektur. Ein bereitgestellter gehosteter Agent erhält stattdessen seine eigene Microsoft Entra Agentidentität bei der Bereitstellung, sodass Sie den Zugriff auf Tools und downstream-Ressourcen pro Agent gewähren und überwachen können, ohne Zugriffsmuster in verschiedene Projekte zu trennen.

Wenn Sie connections mit externen Ressourcen innerhalb von Foundry einrichten, verwenden Sie Microsoft Entra ID-basierte Authentifizierung, falls verfügbar. Bei diesem Ansatz wird die Notwendigkeit beseitigt, vorausgeteilte Geheimnisse zu beibehalten. Beschränken Sie jede Verbindung so, dass nur das besitzereigene Projekt sie verwenden kann. Wenn mehrere Projekte Zugriff auf dieselbe Ressource benötigen, erstellen Sie in jedem Projekt eine separate Verbindung, anstatt eine einzelne Verbindung für alle Projekte freizulegen. Diese Vorgehensweise erzwingt strenge Zugriffsgrenzen und verhindert, dass zukünftige Projekte den Zugriff erben, den sie nicht benötigen.

Vermeiden Sie das Erstellen von Verbindungen auf der Ressourcenebene der Gießerei, da Verbindungen auf Ressourcenebene für alle aktuellen und zukünftigen Projekte in der Ressource gelten. Sie können versehentlich breiten Zugriff auf Ressourcen gewähren, die geringsten Berechtigungsprinzipien verletzen und das Risiko einer nicht autorisierten Datenexposition erhöhen. Erstellen Sie nur Verbindungen auf Projektebene.

Gesprächsisolation

Der Foundry Agent Service erzwingt keine Benutzerautorisierung für Unterhaltungen. Die Identität des Anwendungsservers verfügt über Anmeldeinformationen auf Projektebene, mit denen durch Angabe der ID auf jede Kommunikation gelesen oder in diese geschrieben werden kann. Wenn die Chat-UI-Anwendung eine vom Client bereitgestellte Unterhaltungs-ID ohne Überprüfung direkt an den Agentdienst übergibt, kann ein Benutzer auf Nachrichten zugreifen oder in die Unterhaltung eines anderen Benutzers einfügen. Dies ist eine Sicherheitsanfälligkeit in der Autorisierung auf fehlerhafter Objektebene .

Ihr Anwendungsserver muss die Eigentumsrechte an Kommunikationen durchsetzen. Vertrauen Sie keine Konversationskennungen vom Client. Vergewissern Sie sich bei jeder Anforderung, dass der authentifizierte Benutzer die referenzierte Unterhaltung besitzt, bevor Sie die Anforderung an den Agent-Dienst weiterleiten.

Gehostete Agents bieten ein Sitzungsisolationsmodell pro Benutzer , aber die Topologie dieser Architektur bestimmt, ob sie gilt. Die Webanwendung ruft den Agent im Namen jedes angemeldeten Benutzers mit eigener Workloadidentität auf, sodass die Plattform eine einzelne Anruferidentität sieht und einen Endbenutzer nicht von einem anderen unterscheiden kann. Bei diesem Muster bleibt Ihr Anwendungsserver die Vertrauensgrenze und muss die Eigentümerschaft von Konversationen wie zuvor beschrieben durchsetzen.

Die Isolation wird anwendbar, wenn die Anforderung an den Endpunkt des gehosteten Agents die Identität des Endbenutzers und nicht nur die Identität der Anwendung trägt. Entweder authentifiziert sich der Aufrufer direkt mit seinem eigenen Microsoft Entra-Token, oder Ihr Anwendungsserver übergibt den stabilen Bezeichner des Endbenutzers an die Plattform. Wenn die Anfrage den Endbenutzer identifiziert, ordnet die Plattform Konversationen, Sitzungen, gespeicherte Daten und das Dateisystem $HOME pro Sitzung der in der Anfrage angegebenen Identität zu. Wenn jeder Anrufer seine eigene Identität darstellt, trennt dies die Daten eines Benutzers von den Anderen. Bei delegierten Identitäten trennt die Plattform keinen delegierten Benutzer von einem anderen, sodass die gleiche zuvor beschriebene Anwendungsservererzwingung weiterhin gilt.

Wenn Ihr Anwendungsserver Endbenutzeridentitäten delegiert, kann er auch viele Benutzer in einer begrenzten Gruppe von Agentsitzungen bündeln, anstatt eine Agentsitzung pro Benutzer zu öffnen. Die Plattform begrenzt gleichzeitige Agentsitzungen pro Abonnement und Region, und diese Obergrenze zählt nur Agentsitzungen, die eine Anforderung aktiv verarbeiten. Wenn Nutzer eine Agent-Sitzung gemeinsam verwenden, isoliert die Plattform weiterhin den Konversationszustand jedes Nutzers, aber alle Daten, die der Agent-Container selbst speichert, etwa Dateien, Datenbankzeilen oder ein Cache, werden nicht automatisch voneinander getrennt. Ihr Code muss diese Daten sowohl der Agentensitzung als auch der Endbenutzeridentität zuordnen. Andernfalls können Benutzer in derselben poolierten Sitzung die gespeicherten Daten des anderen lesen. Informationen zu den Zuordnungsstrategien und dieser Partitionierung pro Benutzer finden Sie unter Multiplex mehrerer Benutzer in einer gehosteten Agentsitzung.

Inhaltssicherheit

Jedes Modell in Ihrer Bereitstellung sollte eine Inhaltsfilterrichtlinie zuweisen, die Eingabeaufforderungen und Modellvervollständigungen auf schädliche Inhalte überprüft.

Bewerten Sie die standardmäßig von Microsoft verwaltete Richtlinie im Hinblick auf die Inhaltssicherheitsanforderungen Ihrer Workload. Wenn die Standardschwellenwerte diese Anforderungen nicht erfüllen, erstellen Sie eine benutzerdefinierte Inhaltsfilterrichtlinie, und binden Sie sie an die Bereitstellung. Verwalten Sie die Richtlinie zusammen mit dem Rest Ihrer Infrastruktur als Code, sodass die Inhaltssicherheitskonfiguration in allen Umgebungen versionsgesteuert und konsistent bleibt.

Vernetzung

Zusätzlich zum identitätsbasierten Zugriff erfordert diese Architektur die Netzwerkvertraulichkeit.

Das Netzwerkdesign umfasst die folgenden Sicherheitsvorkehrungen:

• Ein einzelner, sicherer Einstiegspunkt für den gesamten Chat-UI-Datenverkehr, der die Angriffsfläche minimiert

• Gefilterter Eingangs- und Ausgang des Netzwerkdatenverkehrs mithilfe einer Kombination aus NSGs, einer Webanwendungsfirewall, benutzerdefinierten Routen (UDRs) und Azure Firewall Regeln

• End-to-End-Verschlüsselung von Daten während der Übertragung mithilfe von TLS

• Netzwerkdatenschutz mithilfe von Private Link für alle Azure PaaS-Dienstverbindungen

• Logische Segmentierung und Isolierung von Netzwerkressourcen mit dedizierten Subnetzen für jede Hauptkomponentengruppierung zur Unterstützung granularer Sicherheitsrichtlinien

Netzwerkflüsse

Das Diagramm ähnelt der geplanten End-to-End-Chatarchitektur. Sie umfasst die Azure OpenAI-Architektur und drei nummerierte Netzwerkflüsse. Der eingehende Fluss und der Fluss von App Service zu Azure PaaS-Dienste werden aus der grundlegenden App Service-Webarchitektur kopiert. Der Ablauf des Foundry Agent Service zeigt einen Pfeil vom privaten Foundry-Endpunkt im privaten virtuellen Netzwerk, der auf den Foundry Agent Service verweist. Der zweite nummerierte Pfeil im Fluss "Foundry Agent Service" zeigt Aufrufe aus der virtuellen Azure AI-Agent-Schnittstelle im privaten Netzwerk, die über private Endpunkte fließen. Der dritte nummerierte Pfeil zeigt einen Pfeil von der virtuellen Schnittstelle zu einem Azure Firewall Feld, das angibt, dass alle Aufrufe des Internets über diese Firewall fließen.

Die baseline App Service-Webanwendungsarchitektur beschreibt den eingehenden Fluss vom Benutzer zur Chatbenutzeroberfläche und den Fluss von App Service zu Azure PaaS-Dienste. Dieser Abschnitt konzentriert sich auf Agentinteraktionen.

Wenn die Chat-UI mit dem in Foundry bereitgestellten Agent kommuniziert, treten die folgenden Netzwerkflüsse auf:

1. Die vom App Service gehostete Chat-UI initiiert HTTPS-Anforderungen über einen privaten Endpunkt an den API-Endpunkt der Foundry-Datenebene.

2. Wenn der Agent auf Azure PaaS-Dienste zugreift, z. B. Dienstabhängigkeiten, benutzerdefinierte Wissensspeicher oder benutzerdefinierte Tools, sendet der Einzelmandantendatenproxy im delegierten Subnetz HTTPS-Anforderungen an die privaten Endpunkte dieser Dienste.

3. Wenn der Agent auf Ressourcen außerhalb des virtuellen Netzwerks zugreift, einschließlich internetbasierter APIs oder externer Dienste, leitet der Datenproxy diese HTTPS-Anforderungen vom delegierten Subnetz über Azure Firewall weiter.

Private Endpunkte dienen als kritische Sicherheitskontrolle in dieser Architektur, indem sie die identitätsbasierte Sicherheit ergänzen. Da diese Architektur private Endpunkte und UDRs in Ihrem virtuellen Netzwerk verwendet, wird die Netzwerksicherheitsperimeterfunktion von Foundry-Projekten nicht unterstützt.

Eingangsverkehr zu Foundry

Diese Architektur blockiert den öffentlichen Zugriff auf die Gießereidatenebene, indem datenverkehr nur über einen privaten Link für Foundry zugelassen wird. Sie können über die Portalwebsite auf den großteil des Foundry-Portals zugreifen, aber alle Funktionen auf Projektebene erfordern Netzwerkzugriff. Das Portal basiert auf den Datenebenen-APIs Ihrer Foundry-Ressource, die nur über private Endpunkte erreichbar sind. Entwickler und Data Scientists müssen daher über ein Sprungfeld, ein peered virtual network, eine Azure ExpressRoute-Verbindung oder eine Standort-zu-Standort-VPN-Verbindung auf das Portal zugreifen.

Alle programmgesteuerten Interaktionen mit der Agentdatenebene müssen auch diese privaten Endpunkte verwenden. Beispiele sind Aufrufe aus der Webanwendung oder aus externem Orchestrierungscode, der die Modellinferenz aufruft. Private Endpunkte werden auf Ressourcenebene und nicht auf Projektebene definiert, sodass alle Projekte innerhalb der Ressource dieselben Endpunkte und Netzwerkexposition aufweisen. Sie können den Netzwerkzugriff nicht auf Projektebene segmenten.

Um diese Konfiguration zu unterstützen, richten Sie DNS für die folgenden FQDN-API-Endpunkte für Foundry ein:

• privatelink.services.ai.azure.com
• privatelink.openai.azure.com
• privatelink.cognitiveservices.azure.com

Das folgende Diagramm veranschaulicht, wie ein KI-Entwickler über Azure Bastion eine Verbindung zu einer virtuellen Maschine (VM) herstellt. Über dieses Sprungfeld kann der Autor über einen privaten Endpunkt im selben Netzwerk auf das Projekt im Foundry-Portal zugreifen.

Ein Pfeil verweist von einem Agent-Autor auf Azure Bastion, auf die Jump-Box, auf einen privaten Endpunkt für Foundry (Portal) und dann auf das Foundry-Projekt, das den Foundry Agent Service enthält. Aus dem Foundry-Projekt zeigt ein Pfeil auf eine virtuelle Schnittstelle im Azure KI-Agent-Integrationssubnetz. Ein letzter Pfeil verweist von der virtuellen Schnittstelle auf die drei privaten Endpunkte der Abhängigkeiten des Foundry Agent Service. Diese Abhängigkeiten sind KI-Suche, Azure Cosmos DB und Speicher.

Steuern Sie den Datenverkehr im Subnetz des Foundry-Agents

Diese Architektur leitet ausgehenden (Egress-)Netzwerkverkehr der Funktion „Foundry Agent Service“ über ein delegiertes Subnetz innerhalb Ihres virtuellen Netzwerks.

Bei Prompt-Agent wird in diesem delegierten Subnetz ein Single-Tenant-Datenproxy ausgeführt, der die gesamte ausgehende Konnektivität im Namen des Agent abwickelt. Der Foundry Agent Service stellt für jedes Projekt einen Datenproxy bereit, den sich alle Prompt-Agent in diesem Projekt teilen. Der Datenproxy ist der Ausgangspunkt für die erforderlichen Dienstabhängigkeiten des Agent sowie für die meisten externen Wissensquellen oder Tool-Verbindungen, die der Agent nutzt.

Bei gehosteten Agents verlagert sich der Steuerungspunkt: Jede Sitzung eines gehosteten Agents läuft auf Computing-Ressourcen mit einer dedizierten Netzwerkschnittstelle in diesem Subnetz, sodass der ausgehende Datenverkehr des Agents direkt über diese Schnittstelle und nicht über den Datenproxy nach außen geleitet wird, auch wenn seine Toolaufrufe weiterhin über den Datenproxy laufen.

Durch die Erzwingung dieses Ausgangspfads erhalten Sie den Vollzugriff auf den ausgehenden Datenverkehr. Sie können präzise NSG-Regeln, benutzerdefiniertes Routing und DNS-Steuerung für den gesamten Datenverkehr des Agents, der den Dienst verlässt, anwenden. Dieses Design trägt dazu bei, Datenexfiltrationsversuche innerhalb der Orchestrierungslogik zu reduzieren.

Der Agentdienst verwendet die DNS-Konfiguration des virtuellen Netzwerks, um private Endpunkteinträge und erforderliche externe FQDNs aufzulösen. Mit diesem Setup wird sichergestellt, dass die Anforderungen des Agents DNS-Protokolle generieren, die Überwachung und Problembehandlung unterstützen.

Die an das Ausgangssubnetz des Agent angehängte NSG blockiert den gesamten eingehenden Datenverkehr, da kein legitimer eingehender Datenverkehr stattfinden sollte. Ausgehende NSG-Regeln ermöglichen nur den Zugriff auf private Endpunktsubnetze innerhalb des virtuellen Netzwerks und den TCP-Port 443 (Transmission Control Protocol) für internetgebundenen Datenverkehr. Die NSG lehnt jeglichen anderen Datenverkehr ab.

Um den Internetdatenverkehr weiter einzuschränken, wendet diese Architektur ein UDR auf das Subnetz an, das den gesamten HTTPS-Datenverkehr über Azure Firewall leitet. Die Firewall steuert, welche FQDNs der Agent über HTTPS-Verbindungen erreichen kann. Wenn der Agent beispielsweise eine Verbindung mit einem öffentlichen MCP-Server https://contoso.com/mcp herstellt oder eine externe API über eine OpenAPI-Tooldefinition aufruft, konfigurieren Sie Azure Firewall so, dass Datenverkehr zu diesen spezifischen FQDNs auf Port 443 aus diesem Subnetz zulässt, und stellen Sie sicher, dass der NSG diesen Datenverkehr zulässt.

Die Agentlaufzeit benötigt außerdem ausgehenden Zugriff auf ihre eigenen Plattformabhängigkeiten, nicht nur auf die FQDNs, die Ihre Agenten verwenden. Lassen Sie das AzureActiveDirectory Service-Tag zu, damit sich das Agent Compute authentifizieren kann. Ein gehosteter Agent, der externe Endpunkte erreicht, erfordert, dass Sie diese FQDNs über Ihre Firewall zulassen. Wenden Sie die TLS-Inspektion in Azure Firewall nicht auf diesen Datenverkehr an. Das zertifikat, das bei der Inspektion verwendet wird, kann die Verbindungen der Agenten unterbrechen.

Hinweis

Nicht alle Wissenstools, die mit Ihren Agents verbunden sind, gehen über dieses Subnetz. Beispielsweise ruft das Websuchtool aufapi.bing.microsoft.com, das Sie möglicherweise durch Azure Firewall weiterleiten möchten, indem Sie Port 443 von diesem Subnetz aus zulassen. Aber Agent Service ruft dieses Tool über einen internen Mechanismus auf, der das Egress-Subnetz vollständig umgeht. Testen Sie alle integrierten Wissens- und Tool-Verbindungen für Ihre Workload, um zu überprüfen, ob sie mit Ihren Richtlinien zur Kontrolle des ausgehenden Netzwerkverkehrs übereinstimmen.

Zugriff auf workloadeigene MCP-Server

Wenn Sie einen privaten MCP-Server für Ihre Workload hosten, platzieren Sie ein dediziertes MCP-Subnetz im selben virtuellen Netzwerk wie Ihr Agent-Subnetz. Lassen Sie ausgehenden TCP-Datenverkehr über die Ports 443 und 31443 vom Agent-Subnetz zum MCP-Subnetz zu, und lassen Sie den entsprechenden eingehenden Datenverkehr im MCP-Subnetz zu. Konfigurieren Sie private DNS so, dass die Standard- oder benutzerdefinierte Domäne der Container-Apps-Umgebung in ihre statische IP-Adresse innerhalb des virtuellen Netzwerks aufgelöst wird. In dieser Topologie verwenden Agentaufrufe an MCP-Server private Adressierung und verbleiben innerhalb des virtuellen Netzwerks. Implementierungsanleitungen finden Sie unter Verbinden von Agents mit Modellkontextprotokollservern.

Vorausgesetzt, Ihr MCP-Server wird in Container-Apps gehostet, muss das MCP-Subnetz NSG auch den erforderlichen Container-Apps-Netzwerkdatenverkehr zulassen. Leiten Sie internetgebundenen Datenverkehr von Ihren Workload-MCP-Servern über Azure Firewall weiter.

Segmentierung und Sicherheit des virtuellen Netzwerks

Diese Architektur segmentiert das virtuelle Netzwerk, indem jede Hauptkomponentengruppe ihrem eigenen Subnetz zugewiesen wird. Jedes Subnetz verfügt über eine dedizierte Netzwerksicherheitsgruppe (NSG), die den eingehenden und ausgehenden Datenverkehr auf das beschränkt, was die Komponente benötigt.

In der folgenden Tabelle sind die NSG- und Firewallkonfigurationen für jedes Subnetz zusammengefasst.

Verwendungs- oder Subnetzname	Eingehender Datenverkehr (NSG)	Ausgehender Datenverkehr (NSG)	UDR zur Firewall	Ausgangsregeln der Firewall
Private Endpunkte snet-privateEndpoints	Virtuelles Netzwerk	Kein Verkehr erlaubt	Yes	Kein Verkehr erlaubt
Anwendungsgateway snet-appGateway	Quell-IP-Adressen der Chat-Benutzer, z. B. aus dem öffentlichen Internet, sowie erforderliche Quellen für den Dienst	Subnetz des privaten Endpunkts und erforderliche Elemente für den Dienst	Nein	-
App-Dienst snet-appServicePlan	Kein Verkehr erlaubt	Private Endpunkte und Azure Monitor	Yes	Zu Azure Monitor
Foundry-Agentendienst snet-agentsEgress	Kein Verkehr erlaubt	Private Endpunkte, MCP-Subnetz und das Internet	Yes	Nur öffentliche FQDNs, deren Verwendung Sie Ihren Agenten gestatten
Private MCP-Server snet-mcpServers	TCP-Ports 443 und 31443 aus dem Subnetz des Foundry Agent Service und erforderlichen Quellen für den Host	Erforderliche Einträge für den Dienst	Yes	Erforderliche Plattform-FQDNs und nur öffentliche FQDNs, die für die MCP-Server erforderlich sind
Jump-Box-VMs snet-jumpBoxes	Azure Bastion Subnetz	Private Endpunkte und das Internet	Yes	Nach Bedarf der virtuellen Maschine
Build-Agents snet-buildAgents	Azure Bastion Subnetz	Private Endpunkte und das Internet	Yes	Nach Bedarf der virtuellen Maschine
Azure Bastion AzureBastionSubnet	Siehe NSG-Zugriff und Azure Bastion	Siehe NSG-Zugriff und Azure Bastion	Nein	-
Azure Firewall AzureFirewallSubnet AzureFirewallManagementSubnet	Keine NSG	Keine NSG	Nein	-

Diese Konfiguration verweigert explizit allen anderen Datenverkehr, entweder über NSG-Regeln, oder standardmäßig in Azure Firewall.

Wenn Sie die Netzwerksegmentierung und Sicherheit in dieser Architektur implementieren, befolgen Sie die folgenden Empfehlungen:

• Stellen Sie einen Azure DDoS Protection-Plan an der öffentlichen IP-Adresse des Application Gateway bereit, um volumetrische Angriffe abzumildern.

• Fügen Sie eine NSG an jedes Subnetz an, das es unterstützt. Wenden Sie die strengsten Regeln an, die möglich sind, ohne die erforderliche Funktionalität zu unterbrechen.

• Wenden Sie die erzwungene Tunnelung auf alle unterstützten Subnetze an, damit Ihre Ausgangsfirewall den gesamten ausgehenden Datenverkehr überprüfen kann. Verwenden Sie erzwungenes Tunneling auch in Subnetzen, in denen Sie keinen ausgehenden Datenverkehr erwarten. Diese Methode fügt eine detaillierte Verteidigungsmaßnahme hinzu, die vor absichtlichem oder versehentlichem Missbrauch des Subnetzes schützt.

Optimierung der Webanwendungsfirewall

Chatanwendungen erzeugen häufig Inhalte, die falsch positive Ergebnisse aus Web Application Firewall verwalteten Regeln auslösen. Benutzeraufforderungen und Modellantworten enthalten häufig Codeausschnitte, SQL-Anweisungen oder HTML-Fragmente. Chat-Inhalte können in vielen Kategorien verwalteter Regeln Fehlalarme auslösen, darunter Regeln zur Remote-Code-Ausführung, zur Einbindung lokaler Dateien und zur Bedrohungserkennung. In mehrstufigen Konversationen summiert sich der OWASP-Anomalie-Score über mehrere Nachrichten hinweg, bis die WAF die Anfrage mit einem HTTP-403-Fehler blockiert, was bedeutet, dass Blockierungen spontan auftreten können, wenn Konversationen länger werden.

Um dies zu beheben, optimieren Sie Ihre WAF-Richtlinie , indem Sie Ausschlüsse erstellen, die auf das Anforderungstextfeld beschränkt sind, das Chatnachrichten enthält. Bereichsausschlüsse auf die betroffenen Regelgruppen anstatt global Regeln zu deaktivieren. Überprüfen Sie auch, ob die Anfragekörper-Inspektionsgrenzwerte die in Ihren Chatinteraktionen typischen Nutzlastgrößen berücksichtigen.

Governance durch Politik

Verwenden Sie Azure Policy- und Netzwerkrichtlinien, um die Sicherheitsgrundwerte Ihrer Workload anzupassen, um sicherzustellen, dass alle Workloadressourcen Ihren Anforderungen entsprechen. Die Plattformautomatisierung durch Richtlinien reduziert das Risiko einer Sicherheitskonfigurationsabweichung und reduziert manuelle Überprüfungsaktivitäten.

Erwägen Sie die Implementierung der folgenden Arten von Sicherheitsrichtlinien, um Ihre Architektur zu stärken:

• Deaktivieren Sie schlüsselbasierte oder andere lokale Authentifizierungsmethoden in Diensten wie Foundry-Tools und Key Vault.

• Erfordert eine explizite Konfiguration von Netzwerkzugriffsregeln, privaten Endpunkten und NSGs.

• Erfordert Verschlüsselung, z. B. vom Kunden verwaltete Schlüssel.

• Einschränken der Ressourcenerstellung, z. B. Einschränken von Regionen oder Ressourcentypen.

Kostenoptimierung

Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Design Review-Checkliste für die Kostenoptimierung.

Diese vorkonfigurierte Schätzung im Azure Preisrechner enthält nur die Komponenten in dieser Architektur, sodass sie an Ihre Nutzung angepasst werden. Die teuersten Komponenten im Szenario sind Azure Cosmos DB, AI Search und DDoS Protection. Weitere wichtige Kosten sind die Berechnung der Chat-UI und das Anwendungsgateway. Optimieren Sie diese Ressourcen, um Kosten zu senken.

Gießerei-Agentendienst

Wenn Sie die Standardbereitstellung verwenden, müssen Sie die Abhängigkeiten des Diensts in Ihrem eigenen Azure-Abonnement einrichten und verwalten.

Die folgenden Empfehlungen erläutern, wie Die Kosten für diese erforderlichen Dienste optimiert werden:

• Der Foundry Agent Service verwaltet die Anforderungseinheitszuordnung (RU) für Azure Cosmos DB. Um langfristige Kosten zu reduzieren, kaufen Sie reservierte Kapazität für Azure Cosmos DB. Richten Sie Reservierungen nach der erwarteten Nutzungsdauer und dem erwarteten Volumen aus. Reservierte Kapazität erfordert vorab Engagement und fehlt an Flexibilität, wenn sich die Nutzungsmuster Ihrer Workload erheblich ändern.

• Wenn Ihr Chatszenario keine Dateiuploads erfordert, schließen Sie dieses Feature in Ihrer Anwendung aus. Wenden Sie in diesem Fall die folgenden Konfigurationsänderungen an:

  • Verwenden Sie eine lokal redundante Speicherebene (LRS) für das Speicherkonto.

  • Konfigurieren Sie die KI-Suche mit einem einzelnen Replikat anstelle der empfohlenen drei Replikate.

• Löschen Sie regelmäßig nicht verwendete Agents und ihre zugehörigen Unterhaltungen mithilfe der SDK- oder REST-APIs. Veraltete Agents und Konversationen beanspruchen weiterhin Speicherplatz und können die Kosten für Azure Cosmos DB, Storage und AI Search erhöhen.

• Deaktivieren Sie Features für abhängige Ressourcen, die Ihre Workload nicht benötigt, wie die folgenden Features:

  • Der semantische Rangierer in der KI-Suche

  • Die Gateway- und Multiregion-Schreibfunktionen in Azure Cosmos DB

• Um regionsübergreifende Bandbreitengebühren zu vermeiden, stellen Sie Azure Cosmos DB, Speicher und KI-Suche in derselben Azure Region wie foundry Agent Service bereit.

• Vermeiden Sie die Platzierung von workload-spezifischen Daten in denselben Azure Cosmos DB- oder AI Search-Ressourcen, die der "Foundry Agent Service" verwendet. In einigen Fällen können Sie diese Ressourcen freigeben, um nicht verwendete Kapazität in RUs oder Sucheinheiten zu reduzieren, wodurch die Kosten reduziert werden. Berücksichtigen Sie die gemeinsame Ressourcennutzung erst nach einer gründlichen Risikobewertung hinsichtlich Zuverlässigkeit, Sicherheit und Leistungsabstrichen.

Agentenwissen und -tools

Der Foundry-Agent-Dienst führt Agentlogik in einer nicht deterministischen Weise aus. Es kann verbundene Tools aufrufen, einschließlich Wissensabruftools, benutzerdefinierte API-Tools oder andere Agents für jede Anforderung, auch wenn dieses Tool für die Benutzerabfrage nicht relevant ist. Dieses Verhalten kann zu unnötigen Aufrufen externer APIs oder Datenquellen führen, die Kosten für jede Transaktion erhöhen und unvorhersehbare Nutzungsmuster einführen, die die Budgetprognose erschweren.

Um Kosten zu steuern und vorhersagbares Verhalten aufrechtzuerhalten, wenden Sie die folgenden Strategien an:

• Verbinden Sie nur die Tools, die die meisten Agentaufrufe wahrscheinlich verwenden. Vermeiden Sie das Verbinden von Tools, die selten benötigt werden oder für jeden Anruf hohe Kosten verursachen, es sei denn, sie sind unerlässlich.

• Entwerfen und verfeinern Sie die Systemaufforderung, um den Agent anzuweisen, unnötige oder redundante externe Anrufe zu minimieren. Die Systemaufforderung sollte den Agent so leiten, dass nur die relevantesten Verbindungen für jede Anforderung verwendet werden.

• Verwenden Sie Foundry-Metriken und Protokolle, um zu überwachen, welche Tools der Agent aufruft, wie häufig sie aufgerufen wird, und die zugehörigen Kosten. Überprüfen Sie diese Daten regelmäßig, um unerwartete Nutzungsmuster oder Kostenspitzen zu identifizieren und Ihre Systemaufforderung nach Bedarf anzupassen.

• Beachten Sie, dass ein unbestimmter Aufruf die Kostenprognose schwierig machen kann, insbesondere bei der Integration mit nutzungsbasierten APIs. Wenn Sie vorhersehbare Kosten benötigen, sollten Sie den Orchestrator selbst hosten, indem Sie deterministischen Code verwenden.

Azure OpenAI-Modelle

Modellbereitstellungen in Foundry nutzen den MaaS-Ansatz. Die Kosten hängen in erster Linie vom Nutzungsverhalten oder von der vorkonfigurierten Zuweisung ab.

Um die Verbrauchsmodellkosten in dieser Architektur zu steuern, verwenden Sie eine Kombination der folgenden Ansätze:

• Steuern von Clients. Kundenanfragen verursachen die meisten Kosten in einem Verbrauchermodell, daher müssen Sie das Verhalten des Agents steuern.

  Um die unnötige Nutzung zu reduzieren, führen Sie die folgenden Aktionen aus:

  • Genehmigen Sie alle Modellnutzer. Stellen Sie Modelle nicht auf eine Weise zur Verfügung, die uneingeschränkten Zugriff zulässt.

  • Erzwingen Sie tokenbegrenzende Beschränkungen für jede Antwort. Wenn Ihre Anwendung eine Antwort erstellt, legen Sie fest max_output_tokens , dass die vom Modell generierten Token begrenzt werden. Verwenden Sie die Einstellung truncation, um zu steuern, wie viel Konversationsverlauf bei jedem Zug in das Kontextfenster des Modells gelangt.

  • Optimieren Sie die Eingabelänge und die Antwortlänge des Prompts. Längere Aufforderungen verbrauchen mehr Token, was die Kosten erhöht. Eingaben, die nicht genügend Kontext bieten, verringern die Effektivität des Modells. Erstellen Sie präzise Eingabeaufforderungen, die genügend Kontext bereitstellen, damit das Modell eine nützliche Antwort generieren kann. Stellen Sie sicher, dass Sie den Grenzwert der Antwortlänge optimieren.

    Diese Steuerungsebene ist nur in selbst gehosteter Orchestrierung verfügbar. Der Foundry Agent Service bietet nicht genügend Konfiguration, um diese Funktionalität zu unterstützen.

• Wählen Sie das richtige Modell für den Agent aus. Wählen Sie das am wenigsten teure Modell aus, das den Anforderungen Ihres Agenten entspricht. Vermeiden Sie höhere Kostenmodelle, es sei denn, sie sind unerlässlich. Die Referenzimplementierung verwendet beispielsweise ein GPT-5-Serienmodell, das die Anforderungen des Szenarios erfüllt.

• Überwachen und Verwalten der Nutzung. Verwenden Sie Microsoft Cost Management und Modellverwendungsmetriken, um die Tokennutzung nachzuverfolgen, Budgets festzulegen und Warnungen für Anomalien zu erstellen. Überprüfen Sie die Verwendungsmuster regelmäßig, und passen Sie Kontingente oder den Clientzugriff nach Bedarf an.

• Verwenden Sie den richtigen Bereitstellungstyp. Verwenden Sie pay-as-you-go Preise für unvorhersehbare Workloads, und wechseln Sie zum bereitgestellten Durchsatz, wenn die Nutzung stabil und vorhersehbar ist. Kombinieren Sie beide Optionen, wenn Sie einen zuverlässigen Basisplan einrichten.

• Schränken Sie die Nutzung des Playgrounds ein. Um ungeplante Produktionskosten zu vermeiden, beschränken Sie die Verwendung des Foundry-Playgrounds nur auf Vorproduktionsumgebungen.

• Planen Sie die Feinabstimmung und die Bildgenerierung sorgfältig. Diese Features weisen unterschiedliche Abrechnungsmodelle auf. Sie werden pro Stunde oder pro Batch abgerechnet. Planen Sie die Nutzung, um die Abrechnungsintervalle auszurichten und Abfälle zu vermeiden.

Netzwerksicherheitsressourcen

Diese Architektur erfordert Azure Firewall als Ausgangskontrollpunkt. Um Die Kosten zu optimieren, verwenden Sie die Standardebene von Azure Firewall, es sei denn, die restlichen Workloadkomponenten erfordern erweiterte Features. Höhere Ebenen fügen Kosten hinzu, verwenden Sie sie also nur, wenn Sie deren Funktionen benötigen. Bevor Sie die Stufe "Einfach" auswählen, vergewissern Sie sich, dass ihre Einschränkungen ihren Workload entsprechen. Der Basic-Tarif begrenzt den Durchsatz und verfügt über eingeschränkte Threat-Intelligence-Funktionen.

Wenn Ihre Organisation eine Azure-Zielzone verwendet, sollten Sie die Verwendung von gemeinsamen Firewall- und verteilten DDoS-Ressourcen (Dienstverweigerung) in Betracht ziehen, um die Kosten zu verzögern oder zu reduzieren. Workloads mit ähnlichen Sicherheits- und Leistungsanforderungen können von gemeinsam genutzten Ressourcen profitieren. Stellen Sie sicher, dass freigegebene Ressourcen keine Sicherheits- oder Betriebsrisiken darstellen. Ein Beispiel, das gemeinsam genutzte Ressourcen verwendet, finden Sie in der Zielzonenversion dieser Architektur.

Microsoft Defender for Cloud

Verwenden Sie die folgenden Cloud Workload Protection-Pläne, um die zugehörigen Ressourcen in dieser Architektur abzudecken.

Plan	Nutzen
Microsoft Defender für Server	Erkennt Schwachstellen und überwacht die Dateiintegrität, um zu verhindern, dass Jump-Boxen mit hohen Berechtigungen und Build-Agents zu Bedrohungsvektoren werden.
Microsoft Defender für App Service	Überwacht Protokolle, Hostcomputer und Verwaltungsschnittstellen für Ihre Chat-UI-Komponenten.
Microsoft Defender für Azure Cosmos DB	Überwacht Datenbankinteraktionen auf Anzeichen von potenziellem Missbrauch oder unbefugtem Zugriff auf Chatdaten und Agentdefinitionen.
Microsoft Defender für KI-Dienste	Warnungen zu Jailbreaking-Versuchen oder Datenlecks basierend auf Agentanforderungen und -antworten. Wenn Ihre Organisation Microsoft Purview verwendet, bietet dieser Plan auch die Integration mit Microsoft Purview Datensicherheitstatus-Management für KI (DSPM for AI).

Wenn Ihre Organisation eine SIEM-Lösung (Security Information and Event Management) oder Microsoft Purview verwendet, stellen Sie sicher, dass alle Kundendaten, die in diesen Datenspeichern repliziert wurden, z. B. Eingabeaufforderungen und Antworten, in einer Region gespeichert sind, die die Datenhoheitsanforderungen Ihrer Workload erfüllt.

Operative Exzellenz

„Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie in der Checkliste zur Designüberprüfung für operationale Exzellenz.

Der folgende Leitfaden zur betrieblichen Exzellenz enthält nicht die Front-End-Anwendungselemente, die mit der grundlegenden hoch verfügbaren, zonenredundanten Webanwendungsarchitektur identisch bleiben.

Wenn Sie Ihre Experimentier-, Test- und Produktionsumgebungen planen, richten Sie unterschiedliche und isolierte Foundry-Ressourcen ein, einschließlich Abhängigkeiten.

Agents-Rechenleistung

Microsoft verwaltet die serverlose Rechenplattform für die Foundry Agent Service REST APIs sowie die Logik zur Orchestrierungsimplementierung. Ein gehosteter Agent führt Ihren eigenen Orchestrierungscode auf diesen von Foundry verwalteten Rechenressourcen aus. Eine selbst gehostete Orchestrierung geht noch einen Schritt weiter bietet mehr Kontrolle über Laufzeiteigenschaften und Kapazität, allerdings müssen Sie den Day-2-Betrieb für diese Plattform direkt verwalten. Bewerten Sie die Einschränkungen und Verantwortlichkeiten Ihres Ansatzes, um zu verstehen, welche Day-2-Vorgänge Sie implementieren müssen, um Ihre Orchestrierungsschicht zu unterstützen.

Die Verantwortung für die Zustandsverwaltung folgt Ihrer Protokollkonfiguration und nicht Ihrem Computeansatz. Sowohl Prompt-Agents als auch gehostete Agents unterstützen sowohl dienstverwaltete Konversationen, bei denen die Plattform den Chatverlauf speichert, als auch clientverwaltete Konversationen, bei denen Ihr Code den Status weiterführt. Die selbstgehostete Orchestrierung verwaltet immer ihren eigenen Zustand. In jedem Fall befinden sich die dauerhaften Datenspeicher für Chatverlauf und Agentkonfiguration innerhalb Ihres Abonnements, damit liegen Dauerhaftigkeit, Sicherung und Wiederherstellung in Ihrer Verantwortung.

Agent-Interaktions-SDK

Verwenden Sie Microsoft Agent Framework als Laufzeit-SDK in Ihrer Clientanwendung, um Nachrichten an Agents zu senden, Unterhaltungen zu verwalten und Antworten zu verarbeiten. Agent Framework unterstützt C# und Python. Wenn Ihre Clientanwendung JavaScript oder Java erfordert, verwenden Sie das Foundry SDK direkt für diese Laufzeitinteraktionen.

Verwenden Sie das Foundry SDK für Plattformverwaltungsvorgänge unabhängig von Ihrer Client-SDK-Wahl. Die Erstellung und Versionsverwaltung zentral verwalteter Agentdefinitionen gehören zu CI/CD-Pipelines und IaC-Prozessen, nicht im Clientanwendungscode.

Weitere Informationen zum Integrieren von Agent Framework in Foundry finden Sie unter Microsoft Agent Framework Foundry-Anbieter.

Überwachung

Ähnlich wie bei der grundlegenden Architektur sendet diese Architektur Diagnosedaten von allen Diensten an den Log Analytics Arbeitsbereich Ihrer Workload. Die Konfiguration erfasst alle verfügbaren Protokollkategorien für jeden Dienst, mit Ausnahme von App Service. In der Produktion benötigen Sie möglicherweise nicht jede Protokollkategorie. Die Chat-UI-Anwendung im App Service benötigt beispielsweise nur AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs, AppServicePlatformLogs und AppServiceAuthenticationLogs. Optimieren Sie Protokolldatenströme so, dass sie Ihren betrieblichen Anforderungen entsprechen.

Bewerten Sie benutzerdefinierte Warnungen, z. B. aus den Azure Monitor Basiswarnungen, für die Ressourcen in dieser Architektur. Berücksichtigen Sie die folgenden Warnungen:

• KI-Suchwarnungen
• KI-Dienste-Warnungen
• Web-Apps Warnungen

Überwachen Sie die Nutzung von Tokens in Bezug auf Ihre Modellbereitstellungen. In dieser Architektur verfolgt Foundry die Tokennutzung durch die Integration in Application Insights.

Ihre Jumpserver und Build-Agent-VMs befinden sich an Orten mit hohen Berechtigungen, die diesen VMs direkten Netzwerkzugriff auf die Datenebene aller Komponenten in Ihrer Architektur bieten. Stellen Sie sicher, dass diese virtuellen Computer genügend Protokolle ausgeben, um anzuzeigen, wann Benutzer darauf zugreifen, wer dies tut und was sie darauf machen.

Agent-Versionsverwaltung und Lebenszyklus

Behandeln Sie jeden Agent als eigenständige bereitstellungsfähige Einheit innerhalb Ihrer Chat-Workload, es sei denn, Sie entwerfen Ihre Anwendung speziell so, dass Agents zur Laufzeit dynamisch erstellt und gelöscht werden. Diese Agents verfügen über Lebenszyklusverwaltungsanforderungen wie andere Microservices in Ihrer Workload.

Um Dienstunterbrechungen zu verhindern, stellen Sie die sichere und kontrollierte Agentbereitstellung sicher, indem Sie die folgenden Ansätze implementieren:

• Definieren Sie Agenten als Code. Speichern Sie immer Agentdefinitionen, Verbindungen, Systemaufforderungen und Konfigurationsparameter in der Quellcodeverwaltung. Diese Praxis sorgt für Rückverfolgbarkeit und Reproduzierbarkeit. Vermeiden Sie unprotokollierte Änderungen im Foundry-Portal.

• Automatisieren Sie die Agentbereitstellung. Nutzen Sie die Continuous-Integration- und Continuous-Deployment-Pipelines (CI/CD) Ihrer Workload. Verwenden Sie die Foundry-SDKs zum Erstellen, Testen und Bereitstellen von Agentänderungen von Ihren mit dem Netzwerk verbundenen Build-Agents.

  Bevorzugen Sie Agent-Pipelines, die Sie unabhängig für kleine, inkrementelle Änderungen bereitstellen können. Stellen Sie jedoch sicher, dass die Pipelines genügend Flexibilität bieten, um sie zusammen mit Ihrem Anwendungscode bereitzustellen, wenn Sie koordinierte Updates benötigen. Um diese Methode zu unterstützen, koppeln Sie Ihren Chat-UI-Code und Ihre Chat-Agents lose, sodass Änderungen an einer Komponente keine gleichzeitigen Änderungen an der anderen erfordern.

• Testen Sie vor der Produktion. Überprüfen Des Agentverhaltens, Aufforderungen und Verbindungen in Vorproduktionsumgebungen. Verwenden Sie eine Kombination aus automatisierten und manuellen Tests, um Regressionen, Sicherheitsprobleme und unbeabsichtigte Änderungen des Agentverhaltens abzufangen.

  Agents, die im Foundry Agent Service definiert sind, verhalten sich nicht deterministisch, sodass Sie bestimmen müssen, wie Sie Ihr gewünschtes Qualitätsniveau messen und verwalten können. Erstellen und ausführen Sie eine Testsuite, die nach idealen Antworten auf realistische Benutzerfragen und Szenarien sucht.

• Versionsverwalten und Nachverfolgen von Agents. Weisen Sie jedem Agent eindeutige Versionsbezeichner zu. Verwalten Sie Aufzeichnungen darüber, welche Agentenversionen aktiv sind, sowie deren Abhängigkeiten wie Modelle, Datenquellen und Tools. Stellen Sie neue Agentversionen zusammen mit vorhandenen Versionen bereit, um progressives Rollout, Rollback und kontrollierte Migration von Benutzern oder Sitzungen zu unterstützen.

  Foundry unterstützt nativ unveränderliche Agentversionen. Jedes Mal, wenn Sie Änderungen an einer Agentdefinition vornehmen, erstellt Foundry eine neue Versionsmomentaufnahme, die die vorherige Konfiguration bewahrt. Verwenden Sie diesen integrierten Versionsverlauf für Überwachungspfade und Rollbackziele.

  Für gehostete Agents bedeutet der Versand eines Updates mehr als das Erstellen einer Konfigurationsmomentaufnahme. Sie erstellen und pushen zuerst ein Containerimage, und die Version des Foundry-Agents verweist darauf. Ein Rollback setzt den Versionsselektor des Agent-Endpunkts lediglich wieder auf eine frühere Version, ohne Neu-Build und ohne neues Image. Die weiter oben in diesem Abschnitt beschriebenen Vorgehensweisen für Quellcodeverwaltung, Tests und CI/CD gelten sowohl für Prompt- als auch für gehostete Agenten. Da Sie den Code eines gehosteten Agenten schreiben, kommt ein zusätzlicher Schritt hinzu, den Prompt-Agents nicht haben: eine lokale Build-und-Debug-Schleife für diesen ausführbaren Code, bevor er in diese gemeinsamen Pipelines gelangt.

  Nicht jede Laufzeitvariation erfordert eine neue Version. Strukturierte Eingaben parametrisieren Agentdefinitionen. Der Client stellt tatsächliche Werte zur Anforderungszeit zur Verfügung, sodass eine einzelne Agentversion benutzerspezifische oder kontextspezifische Konfigurationen ohne erneute Bereitstellung bereitstellen kann.

  Hinweis

  Beschränken Sie strukturierte Eingaben auf Anweisungstext, z. B. das Einfügen eines Benutzernamens in die Systemaufforderung. Vermeiden Sie das Verwenden von Templates für Tool-Endpunkteigenschaften wie MCP-Server-URLs. Vorlagengestützte Tool-Endpunkte ermöglichen es dem aufrufenden Client, den Agent zur Laufzeit auf beliebige externe Dienste umzuleiten, was die statische Governance-Struktur dieser Architektur untergräbt. Ihre Firewall-FQDN-Zulassungsliste blockiert weiterhin nicht genehmigte Ziele, aber die Agentdefinition selbst dokumentiert nicht mehr, welche Endpunkte der Agent erreichen soll.

• Fixieren und Kontrollieren von Modellversionen. Das Verhalten eines Agents hängt von der aufgerufenen Modellversion ab. Behandeln Sie daher die Modellbereitstellung als Teil Ihres Änderungskontrollesprozesses. Legen Sie die Option für Versionsupgrades der Bereitstellung auf „Nicht automatisch aktualisieren“ fest. Dieses Setup verhindert, dass ein automatisches Modellupdate die Agentantworten ändert, bevor Sie die neue Version für Ihre Testsuite überprüfen.

• Erzwingen der Zugriffssteuerung und Datenisolation auf Benutzerebene. In dieser Architektur ist die Chat-UI-Anwendungsschicht die Zugriffsgrenze zwischen Endbenutzern und Ihren Agents. Die Foundry-Projekt-API befindet sich hinter privaten Endpunkten und kann nicht direkt für Verbraucher zugänglich sein. Ihr Anwendungscode muss Endbenutzer über Microsoft Entra ID authentifizieren und jede Unterhaltung und die zugehörigen Daten auf die authentifizierte Identität beschränken.

  Wenn Sie APIs auf Projektebene verwenden, kann jeder Prinzipal, der über die Rolle "Foundry User" im Foundry-Projekt verfügt, mit allen Agents in diesem Projekt interagieren. Die Authentifizierungs- und Autorisierungsebene Ihrer Anwendung, nicht das Projekt RBAC von Foundry, erzwingt, welche Benutzer auf welche Agents und Unterhaltungen zugreifen können. Entwerfen Sie Ihr Sitzungsmanagement so, dass ein benutzerübergreifender Datenzugriff verhindert wird, und wenden Sie die Daten-Governance- und Aufbewahrungsrichtlinien Ihrer Workload auf die von Ihrer Anwendung gespeicherten Konversationsdaten an.

• Planen Sie eine schrittweise Einführung und ein Failback. Foundry bietet keine integrierte Unterstützung für blue-green- oder Canary-Bereitstellungen von Agents. Wenn Sie diese Bereitstellungsmuster oder die kontrollierte Migration von Benutzern zwischen Agentversionen benötigen, implementieren Sie eine Routingebene, z. B. ein API-Gateway oder einen benutzerdefinierten Router, vor der Agent-API. Mit dieser Routingebene können Sie den Datenverkehr inkrementell zwischen Agentversionen verschieben, den Effekt überwachen und bei Bedarf einen vollständigen Switchover ausführen.

• Koordination der Agentenentfernung. Wenn Sie Agents entfernen, koordinieren Sie den Prozess mit den Anforderungen für die Zustandsverwaltung und die Benutzerfreundlichkeit Ihrer Anwendung. Behandeln Sie aktive Chatsitzungen entsprechend. Abhängig von den funktionalen Anforderungen Ihrer Workload können Sie Sitzungen migrieren, Benutzer an die alte Agentversion anheften oder benutzer zum Starten neuer Sitzungen auffordern.

Leistungseffizienz

Die Leistungseffizienz bezieht sich auf die Fähigkeit Ihrer Arbeitslast, die Anforderungen der Benutzer effizient zu erfüllen. Weitere Informationen finden Sie in der Checkliste zur Entwurfsüberprüfung für die Leistungseffizienz.

In diesem Abschnitt werden die Leistungseffizienz für die KI-Suche, modellbasierte Bereitstellungen, das MCP-Server-Subnetz und das Foundry behandelt.

Leistungseffizienz in der KI-Suche

Im Foundry Agent Service steuern Sie nicht die spezifischen Abfragen, die an Ihre Indizes gesendet werden, da Agents codelos sind. Um die Leistung zu optimieren, konzentrieren Sie sich auf das, was Sie im Index steuern können. Beobachten Sie, wie Ihr Agent den Index in der Regel abfragt, und wenden Sie Anleitungen an, um die Leistung in der KI-Suche zu analysieren und zu optimieren.

Wenn die Indexserveroptimierung allein nicht alle Engpässe behebt, sollten Sie die folgenden Optionen in Betracht ziehen:

• Ersetzen Sie die direkte Verbindung mit der KI-Suche durch eine Verbindung mit einer API, die Sie besitzen. Diese API kann Code implementieren, der für die Abrufmuster Ihres Agents optimiert ist.

• Gestalten Sie die Orchestrierungsebene neu, um Ihren eigenen Orchestrierungscode auszuführen – entweder als gehosteten Agent auf von Foundry verwalteter Recheninfrastruktur oder als selbstgehostete Orchestrierung, die Sie selbst betreiben –, sodass Sie Abfragen im Code Ihres eigenen Orchestrators definieren und optimieren können.

Leistungseffizienz bei Modellbereitstellungen

• Ermitteln Sie, ob Ihre Anwendung einen bereitgestellten Durchsatz benötigt oder das freigegebene Modell (Verbrauchsmodell) verwenden kann. Der bereitgestellte Durchsatz bietet reservierte Kapazität und vorhersehbare Latenz, die Produktionsworkloads unterstützt, die strenge Ziele auf Dienstebene (SLOs) aufweisen. Das Verbrauchsmodell bietet einen Best-Effort-Dienst und es kann zu „Noisy-Neighbor“-Effekten kommen.

• Überwachen Sie die bereitstellungsverwaltete Nutzung , um eine Über- oder Unterbereitstellung zu vermeiden.

• Wählen Sie ein Konversationsmodell aus, das Ihre Anforderungen an die Inferenzlatenz erfüllt.

• Stellen Sie Modelle in derselben Datenregion wie Ihre Agents bereit, um die Netzwerklatenz zu minimieren.

Azure KI-Agent-Leistung

Die Azure KI-Agents werden auf einem serverlosen Berechnungs-Back-End ausgeführt, das keine benutzerdefinierte Leistungsoptimierung unterstützt. Sie können die Leistung jedoch über das Agentdesign verbessern:

• Minimieren Sie die Anzahl der Tools, die mit Ihrem Chat-Agent verbunden sind. Jede zusätzliche Verbindung erhöht möglicherweise die Gesamtlaufzeit für einen Agentanruf, da der Agent möglicherweise alle konfigurierten Tools für jede Anforderung aufruft.

• Verwenden Sie Azure Monitor und Application Insights, um Aufrufzeiten, Toollatenz und Fehlerraten des Agents nachzuverfolgen. Überprüfen Sie diese Metriken regelmäßig, um langsame Toolverbindungen zu identifizieren.

• Designsystem-Anweisungen leiten den Agenten an, Verknüpfungen effizient zu nutzen. Weisen Sie z. B. den Agent an, Datengrundungstools nur bei Bedarf abzufragen oder redundante Toolaufrufe zu vermeiden.

• Überwachen Sie auf Dienstgrenzwerte oder Kontingente, die sich auf die Leistung während der Spitzenauslastung auswirken können. Achten Sie auf Drosselungsindikatoren wie HTTP-429- oder 503-Antworten, auch wenn die serverlose Rechenleistung automatisch skaliert wird.

MCP-Server-Subnetzkapazität

Diese Architektur reserviert ein dediziertes /24-Subnetz, das an Microsoft.App/environments delegiert ist, damit Sie später eine interne Azure Container Apps-Umgebung für Workloadprofile bereitstellen können, die MCP-Server hostet, um Ihre Agenten zu erweitern.

Foundry-Agent-Subnetzkapazität

Das Foundry-Agent-Subnetz muss ausreichend Platz für die Agent-Infrastruktur haben. Es wird an Microsoft.App/environments delegiert und sollte einen /24-CIDR-Bereich verwenden. Diese Größe berücksichtigt den Datenproxy und die Adressen, die von der Subnetzdelegierung reserviert werden. Foundry stellt für jedes Projekt einen Single-Tenant-Datenproxy bereit, und jeder Proxy skaliert mit dem Datenverkehr mit, sodass mehr Projekte und mehr Last mehr Subnetz-IPs verbrauchen. Wenn Sie gehostete Agents einführen, führt die Plattform jede gleichzeitig aktive Agent-Sitzung in einer eigenen Berechnung aus, die eine Subnetz-IP nutzt. Eine Agentsitzung ist die isolierte Sandbox, die von der Plattform zum Verarbeiten der Anforderungen eines Benutzers bereitgestellt wird. Die Plattform richtet bei der ersten Anfrage eine Agentensitzung ein. Da diese Architektur dienstverwaltete Konversationen verwendet, bindet die Plattform diese Agent-Sitzung an die Konversation und verwendet sie bei späteren Gesprächswechseln erneut. Eine separate gleichzeitige Konversation beansprucht eine separate Agentsitzung mit eigenen Rechenressourcen. Eine Agentsitzung verwendet eine Subnetz-IP nur, während die Berechnung ausgeführt wird. Nehmen Sie also die Größe des Subnetzes für die Spitzenanzahl der Agentsitzungen an, die gleichzeitig ausgeführt werden, nicht für die Anzahl der Agents, die Sie bereitstellen.

Durch die Bereitstellung einer neuen Revision des gehosteten Agents werden vorübergehend zusätzliche IPs verwendet, da die alten und neuen Überarbeitungen während des Rollouts parallel ausgeführt werden. Informationen zur Subnetzgröße und IP-Zuordnung finden Sie unter Deep dive into Foundry Agent Service Networking. Eine Foundry-Ressource kann ihr Agent-Subnetz nicht mit einer anderen Foundry-Ressource teilen, obwohl für Ihre Workload mehrere Foundry-Ressourcen erforderlich sind, können sie dasselbe virtuelle Netzwerk gemeinsam nutzen.

Bereitstellen dieses Szenarios

Um diese Referenzimplementierung bereitzustellen und auszuführen, befolgen Sie die Bereitstellungsanleitung in der Foundry Agent Service Chat-Baseline-Referenzimplementierung.

Die Chat-UI-Anwendung in dieser Referenzimplementierung ist einfach und veranschaulicht die Kommunikation mit Agentendpunkten. Beispiele für erweiterte Chat-Benutzeroberflächen finden Sie im Web-App-Repository des Foundry-Agents.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

• Rob Bagby | Leitender Inhaltsentwickler - Azure Muster und Praktiken
• Chad Kittel | Principal Software Engineer - Azure Patterns & Practices

Andere Mitwirkende:

• Raouf Aliouat | Senior Software Engineer
• Freddy Ayala | Cloud-Lösungsarchitekt
• Prabal Deb | Hauptsoftwareingenieur
• Ritesh Modi | Hauptsoftwareingenieur
• Ryan Pfalz | Senior Technical Program Manager

Um nicht öffentliche LinkedIn-Profile zu sehen, melden Sie sich bei LinkedIn an.

Nächster Schritt

• Grundlagen der Foundry-Chat-Architektur in einem Azure-Landebereich

Verwandte Ressourcen

• AI-Workloads auf Azure
• Azure OpenAI-Modelle
• Leitplanken und Steuerungen
• KI-Agenten-Orchestrierungsmuster

Mithilfe von Unternehmenschatanwendungen können Mitarbeiter über Unterhaltungen in natürlicher Sprache mit KI-Agents interagieren. Diese Anwendungen verwenden Sprachmodelle wie OpenAI GPT-Modelle und Open-Source-Entwicklungskits wie das Microsoft Agent Framework. Diese Chatanwendungen bestehen in der Regel aus den folgenden Komponenten:

• Eine Chat-Benutzeroberfläche, die in eine größere Unternehmensanwendung integriert ist. Sie bietet Benutzern eine konversationsbasierte Erfahrung zusammen mit weiteren Geschäftsfunktionen.

• Datenrepositorys, die domänenspezifische Informationen enthalten, die für Benutzerabfragen relevant sind.

• Sprachmodelle, die domänenspezifische Daten analysieren, um relevante Antworten zu generieren.

• Eine permanente Orchestrierungsdefinition oder ein langlebiger Agent, der die Interaktionen zwischen Datenquellen, Sprachmodellen und dem Benutzer überwacht.

Dieser Artikel enthält eine grundlegende Architektur, mit der Sie Unternehmenschatanwendungen mithilfe von Foundry und Azure OpenAI-Modellen erstellen und bereitstellen können. Diese Architektur verwendet einen Eingabeaufforderungs-Agent , der im Foundry Agent Service beibehalten wird, aber auch gehostete Agents unterstützt. Sie definieren den Prompt-Agent deklarativ anhand seiner Anweisungen, der Modellauswahl und der verbundenen Tools, und Agent Service übernimmt sein Hosting. Der Agent empfängt Benutzernachrichten und fragt dann Datenspeicher ab, um Grundlageninformationen für das Sprachmodell abzurufen.

Die Chat-Benutzeroberfläche folgt den Richtlinien für die Baseline-Webanwendung von Azure App Service zur Bereitstellung einer sicheren, zonenredundanten und hochverfügbaren Webanwendung in App Service. In dieser Architektur kommuniziert der App Service mit der Azure-Plattform als Service (PaaS)-Lösung über die Integration virtueller Netzwerke und privater Endpunkte. In der Chat-UI-Architektur kommuniziert App Service mit dem Agent über einen privaten Endpunkt. Diese Architektur blockiert den öffentlichen Zugriff auf das Foundry-Portal und agents.

Von Bedeutung

In diesem Artikel werden die Komponenten oder Architekturentscheidungen aus der grundlegenden Webanwendungsarchitektur des App Service nicht beschrieben. Anleitungen zum Hosten der Webanwendung, die Ihre Chat-UI enthält, finden Sie in diesem Artikel.

Diese Architektur verwendet das Standard-Agent-Setup des Foundry Agent Service , um Sicherheit, Compliance und Kontrolle auf Unternehmensniveau bereitzustellen. In dieser Konfiguration bringen Sie Ihr eigenes virtuelles Netzwerk (BYO) für die Netzwerkisolation und Ihre eigenen Azure Ressourcen zum Speichern des Chat- und Agentstatus ein. Anwendungskomponenten greifen über private Endpunkte auf die Azure-Dienste zu, und Agenten greifen über private Netzwerkverbindungen auf workloadeigene MCP-Server zu. Mit diesem Ansatz wird sichergestellt, dass der Datenverkehr im virtuellen Netzwerk Ihrer Workload verbleibt. Der ausgehende Datenverkehr der Agenten wird ausschließlich über die Azure Firewall geleitet, die die Ausgangsregeln durchsetzt.

Tipp

Die Referenzimplementierung des Foundry Agent Service veranschaulicht eine grundlegende End-to-End-Chat-Implementierung auf Azure. Sie dient als Grundlage für die Entwicklung von benutzerdefinierten Lösungen, während Sie zur Produktion wechseln.

Architektur

Das Diagramm zeigt eine detaillierte Azure Architektur für die Bereitstellung einer KI-Lösung. Auf der linken Seite stellt ein Benutzer eine Verbindung über Azure Application Gateway mit einer Webanwendungsfirewall in Verbindung, die Teil eines virtuellen Netzwerks ist. Dieses Gateway ist mit privaten DNS-Zonen verknüpft und durch Azure DDoS Protection geschützt. Unter dem Gateway stellen private Endpunkte eine Verbindung mit Diensten wie App Service, Azure Key Vault und Azure Storage her, die für die Client-App-Bereitstellung verwendet werden. Der App Service wird unter Verwendung von Identitäten verwaltet und umfasst drei Regionen. Application Insights und Azure Monitor bieten Überwachung, und Microsoft Entra ID übernimmt die Authentifizierung. Rechts enthält das virtuelle Netzwerk mehrere Subnetze: App Service-Integration, privater Endpunkt, Foundry-Integration, Azure KI-Agent-Integration, Azure Bastion, Sprungfeld, Build-Agents und Azure Firewall. Jedes Subnetz hostet bestimmte Endpunkte oder Dienste, z. B. Speicher, Foundry, Azure KI-Suche und Azure Cosmos DB, alle über private Endpunkte verbunden. Ausgehender Datenverkehr aus dem Netzwerk durchläuft Azure Firewall, um Internetquellen zu erreichen. Ganz rechts stellt ein separater Kasten Foundry dar, das eine Ressource und ein Projekt enthält. Verwaltete Identitäten verbinden den Foundry Agent Service mit dem Foundry-Projekt, das wiederum auf ein Azure OpenAI-Modell zugreift. Das Diagramm verwendet nummerierte Kreise, um den logischen Fluss anzugeben. Es zeigt, wie Benutzeranforderungen das Netzwerk durchlaufen, mit verschiedenen Endpunkten interagieren und schließlich eine Verbindung mit Foundry- und Speicherdiensten herstellen, wobei Abhängigkeiten eindeutig gruppiert und bezeichnet werden.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Arbeitsablauf

1. Ein Anwendungsbenutzer interagiert mit einer Chat-UI. Die Anforderungen werden durch Azure Application Gateway geleitet. Azure Web Application Firewall überprüft diese Anforderungen, bevor sie an die Back-End-App Service-Instanz weitergeleitet werden.

2. Wenn die Webanwendung eine Benutzerabfrage oder -anweisung empfängt, ruft sie den zweckorientierten Agent auf. Die Webanwendung kommuniziert mit den Agentendpunkten über das Microsoft Agent Framework. Das Framework ruft die serverseitige Agentdefinition über die OpenAI-kompatible Antwort-API auf. Der HTTP-Aufruf des Clients bleibt unabhängig davon, welches unterstützte Modell der Agent verwendet, identisch. Die Webanwendung ruft den Agent über einen privaten Endpunkt auf und authentifiziert sich bei Foundry mithilfe seiner verwalteten Identität.

3. Der Agent verarbeitet die Anforderung des Benutzers basierend auf den Anweisungen in der Systemaufforderung. Um die Absicht des Benutzers zu erfüllen, verfügt der Agent über ein konfiguriertes Sprachmodell und verbundene Tools. In dieser Architektur umfasst die Toolauswahl das Azure KI-Suche-Tool zur Fundierung von Daten und das Websuchtool für Webdaten.

4. Der Agent stellt über das KI-Suchtool im privaten Netzwerk über einen privaten Endpunkt eine Verbindung mit Azure KI-Suche bereit.

5. Anforderungen an die meisten externen Tools, z. B. öffentliche MCP-Server oder benutzerdefinierte API-Tools, durchlaufen Azure Firewall zur Erzwingung von Inspektions- und Übergaberichtlinien. Anforderungen an private MCP-Server oder APIs verbleiben im virtuellen Netzwerk.

6. Der Agent stellt eine Verbindung mit seinem konfigurierten Sprachmodell her und übergibt den relevanten Kontext.

7. Bevor der Agent die Antwort an die Benutzeroberfläche zurücksendet, speichert er die Anfrage, die generierte Antwort sowie die Details zum Toolaufruf in der Kommunikation. Dieses in Azure Cosmos DB gespeicherte Unterhaltungsobjekt verwaltet den vollständigen Interaktionsverlauf als Dialogelemente (Nachrichten, Toolaufrufe und Toolausgaben). Dieser Verlauf unterstützt kontextabhängige Interaktionen und ermöglicht Benutzern das Fortsetzen von Unterhaltungen mit dem Agent, ohne dass der vorherige Kontext verloren geht.

   Die Foundry-APIs unterstützen die Entwicklung von Benutzeroberflächen, die mehrere gleichzeitige, kontextisolte Unterhaltungen verwalten.

Komponenten

Diese Architektur basiert auf der grundlegenden Referenzarchitektur des Foundry-Chats. Diese Architektur führt mehr Azure Dienste ein, um unternehmensweite Anforderungen an Zuverlässigkeit, Sicherheit und Betriebssteuerung zu erfüllen. Jede der folgenden Komponenten spielt eine bestimmte Rolle in einer Produktions-Unternehmenschatlösung:

• Der Foundry Agent Service ist eine cloudeigene Laufzeitumgebung, in der intelligente Agents sicher und autonom arbeiten können. In dieser Architektur stellt der Foundry Agent Service eine verwaltete Laufzeit für Eingabeaufforderungs-Agents bereit und ist in Azure-Dienste integriert. Es hostt und verwaltet Agents, die die folgenden Aufgaben ausführen:

  • Verarbeiten von Benutzeranforderungen
  • Orchestrierung von Aufrufen an Tools und andere Agenten
  • Inhaltssicherheit durchsetzen
  • Integrieren Sie mit Unternehmensidentität, Netzwerk und Überwachbarkeit

  Durch die Standard-Agent-Einrichtung wird die Netzwerkisolation sichergestellt und die Kontrolle über die Datenspeicherung bereitgestellt. Sie stellen dedizierte Azure Ressourcen für den Agentstatus, den Chatverlauf und die Dateispeicherung zur Verfügung, der Foundry Agent Service verwaltet sie jedoch ausschließlich. Andere Anwendungskomponenten in der Workload sollten diese erforderlichen Ressourcen nicht verwenden.

  • Azure Cosmos DB für NoSQL ist ein global verteilter Dokumentdatenbankdienst. In dieser Architektur hostet er die als enterprise_memory bezeichnete Speicherdatenbank der Workload innerhalb Ihres Abonnements. Diese Datenbank speichert den Betriebsstatus des Agents, einschließlich Chatunterhaltungen und Agentdefinitionen. Dieser Entwurf stellt sicher, dass der Chatverlauf und die Agentkonfiguration isoliert, auditierbar und gemäß den Anforderungen der Datengovernance verwaltet werden. Der Foundry Agent Service verwaltet die Datenbank, die zugehörigen Sammlungen und ihre Daten.

  • Azure Storage ist ein Cloudspeicherdienst für unstrukturierte Daten. In dieser Architektur bietet sie dedizierten Speicher für Dateien, die während Chatsitzungen hochgeladen wurden. Das Hosting dieses Kontos in Ihrem Abonnement bietet eine präzise Zugriffssteuerung, Überprüfungsfunktionen und die Einhaltung von Datenresidenz- oder Aufbewahrungsrichtlinien. Der Foundry Agent Service verwaltet die Container und den Datenlebenszyklus innerhalb dieser Container.

  • AI Search ist eine verwaltete Suchlösung, die Suchfunktionen bereitstellt. In dieser Architektur verwendet der Foundry Agent Service AI Search, um einen durchsuchbaren, gegliederten Index von Dateien zu speichern, die während der Unterhaltungen mit dem Agenten über das Tool "Dateisuche" hochgeladen wurden. AI Search speichert auch segmentierte, statische Dateien, die Sie bei der Erstellung eines Agenten als Wissensquellen hinzufügen. Diese Dateien bleiben für alle Agentaufrufe verfügbar. Der Foundry Agent Service verwaltet den Index, das Schema und die Daten und verwendet eine eigene Chunking-Strategie und Abfrage-Logik.

• Das Anwendungsgateway ist ein Web-Traffic-Load-Balancer und ein Application Delivery Controller. In dieser Architektur dient sie als sicherer, skalierbarer Einstiegspunkt für den gesamten HTTP- und HTTPS-Datenverkehr zur Chat-UI. Darüber hinaus bietet es TLS-Beendigung und pfadbasiertes Routing. Das Anwendungsgateway verteilt Anforderungen über Verfügbarkeitszonen, die hohe Verfügbarkeit und Leistung für die Webanwendungsebene unterstützen. Das Back-End ist die App Service-Instanz, die den Anwendungscode hosten soll.

  • Azure Web Application Firewall ist ein cloudeigener Dienst, der Webanwendungen vor allgemeinen Web-Exploits schützt. In dieser Architektur wird es in das Anwendungsgateway integriert, um die Chat-UI vor allgemeinen Webrisiken und Angriffen zu schützen. Sie prüft und filtert HTTP-Anforderungen, die eine Sicherheitsebene für öffentlich zugängliche Anwendungen bereitstellen.

  • Azure Key Vault ist ein Clouddienst zum sicheren Speichern und Zugreifen auf geheime Schlüssel, Schlüssel und Zertifikate. In dieser Architektur werden die TLS-Zertifikate, die das Anwendungsgateway benötigt, sicher gespeichert und verwaltet. Die zentralisierte Zertifikatsverwaltung in Key Vault unterstützt automatisierte Rotation, Überwachung und die Einhaltung von Sicherheitsstandards der Organisationen. Für diese Architektur sind keine gespeicherten Schlüssel oder andere geheime Schlüssel erforderlich.

• Azure Virtual Network ist der grundlegende Baustein für private Netzwerke in Azure. In dieser Architektur wird die Netzwerkisolation für alle Komponenten bereitgestellt, die Ihnen dabei helfen, Sicherheits- und Complianceanforderungen zu erfüllen. Wenn Sie Ressourcen in einem privaten virtuellen Netzwerk platzieren, steuern Sie den Ost-West- und Nord-Süd-Datenverkehr, erzwingen Segmentierung, halten Datenverkehr privat und stellen Eine Überprüfung von Eingangs- und Ausgangsflüssen bereit.

• Azure Private Link ist ein Netzwerkdienst, der private Verbindungen zwischen einem virtuellen Netzwerk und Azure PaaS-Diensten bereitstellt. In dieser Architektur verbindet sie alle PaaS-Dienste wie Azure Cosmos DB, Speicher, KI-Suche und Foundry Agent Service über private Endpunkte mit dem virtuellen Netzwerk. Private Link hilft Ihnen sicherzustellen, dass der gesamte Datenverkehr auf dem Azure Backbone bleibt, wodurch die Gefährdung des öffentlichen Internets beseitigt und die Angriffsfläche reduziert wird.

• Azure Firewall ist ein verwalteter, cloudbasierter Netzwerksicherheitsdienst. In dieser Architektur überprüft und kontrolliert das System den gesamten ausgehenden Datenverkehr aus dem virtuellen Netzwerk. Außerdem erzwingt er vollqualifizierte Domänennamen (FQDN)-basierte Regeln, wodurch sichergestellt wird, dass nur genehmigte Ziele erreichbar sind. Diese Konfiguration trägt dazu bei, Datenexfiltration zu verhindern und die Anforderungen für die Netzwerksicherheit zu erfüllen.

• Azure DNS ist ein Hostingdienst für DNS-Domänen (Domain Name System), der die Namensauflösung bereitstellt. In dieser Architektur stellt sie private DNS-Zonen bereit, die mit dem virtuellen Netzwerk verknüpft sind. Es behandelt die Namensauflösung für private Endpunkte, wodurch sichergestellt wird, dass alle Dienst-zu-Dienst-Kommunikation private IP-Adressen verwendet und innerhalb der Netzwerkgrenze verbleibt.

• Azure Storage ist ein Cloudspeicherdienst für unstrukturierte und strukturierte Daten. In dieser Architektur unterstützt sie sichere, automatisierte Bereitstellungsworkflows und trennt Anwendungsartefakte von Computeressourcen. Sie hostt den Webanwendungscode als ZIP-Datei für die Bereitstellung in App Service.

Modell- und Toolauswahl

Der Foundry Agent Service funktioniert nicht mit jedem Modell im Foundry-Modellkatalog. Der Katalog listet Modelle auf, die auf der Foundry-Plattform bereitgestellt werden können, aber ein Prompt-Agent kann nur eine Teilmenge davon verwenden, die vom Foundry Agent Service für die Nutzung durch Agenten validiert wurde.

Bevor Sie sich für ein Modell verpflichten, vergewissern Sie sich, dass Sie es in Ihrer Foundry-Region bereitstellen können und dass der Foundry Agent Service es unterstützt. Durchsuchen Sie den Modellkatalog, der auf agentgestützte Modelle im Foundry-Portal gefiltert ist, oder fragen Sie die Modelle programmgesteuert nach einer Region ab.

az cognitiveservices model list --location <location> --query "[?model.capabilities.agentsV2=='true']"

Ein Modell, das vom Foundry Agent Service unterstützt wird, unterstützt nicht zwangsläufig jede Agent-Funktion. Die Verfügbarkeit von Tools hängt sowohl vom Modell als auch von der Bereitstellungsregion ab. In dieser Architektur verwendet der Agent das KI-Suchtool und das Websuchtool, und nicht jedes unterstützte Modell funktioniert mit jedem Tool. Die vollständige Kompatibilitätsmatrix finden Sie unter Toolunterstützung nach Region und Modell.

Der Foundry Agent Service lehnt beim Definieren des Agents nicht immer eine nicht unterstützte Kombination ab. Wenn Sie einen Eingabeaufforderungs-Agent über die REST-API erstellen, kann ein nicht unterstütztes Modell oder eine Toolauswahl die Agenterstellung übergeben und dann unerwartetes Verhalten oder Laufzeitfehler verursachen, wenn der Agent das Modell oder Tool aufruft.

Alternatives

Diese Architektur umfasst mehrere Komponenten, die Sie je nach den funktionalen und nichtfunktionellen Anforderungen Ihrer Workload durch andere Azure Dienste oder Ansätze ersetzen können. Berücksichtigen Sie die folgenden Alternativen und Kompromisse.

Chat-Orchestrierung

Aktueller Ansatz: Diese Architektur verwendet den Foundry Agent Service , um die Ausführung von Eingabeaufforderungs-Agent-Abläufen zu koordinieren, einschließlich des Abrufens von Bodendaten über verbundene Tools, das Aufrufen von KI-Modellen und das Erzwingen eines konsistenten Reaktionsverhaltens basierend auf den Anweisungen auf Systemebene des Agents und des Unterhaltungsverlaufs. Der Foundry Agent Service bietet eine codelose, nichtdeterministische Orchestrierung für konversationelle KI-Workloads. Es verwaltet Chatanfragen, Unterhaltungsverlauf, Toolaufrufe, Inhaltssicherheit und Integration mit Identität, Netzwerk und Überwachbarkeit. Der Dienst unterstützt die Persistenz des Unterhaltungskontexts und des Agentstatus über ein vordefiniertes Datenmodell, das in einer Datenbank in Ihrem Abonnement bereitgestellt wird.

Alternativer Ansatz: Sie können benutzerdefinierte Ausführungslogik in einem gehosteten Agent implementieren, bei dem es sich um Ihre eigene deterministische, codegesteuerte Agent-Orchestrierungslogik handelt, die in einem Container im Foundry Agent Service ausgeführt wird. Ein gehosteter Agent muss den Laufzeitvertrag für Foundry implementieren, damit die Plattform ihn aufrufen kann. Sie erfüllen diesen Vertrag, indem Sie einen SDK-Adapter verwenden oder den Vertrag selbst implementieren, und Sie erstellen die eigene Logik des Agents mit einem Framework wie dem Agent Framework. Sie stellen diesen Code bereit als Containerimage, das Sie erstellen und in eine Azure Container Registry übertragen, die Ihnen gehört und die Sie verwalten.

In dieser Alternative behandelt Ihr Agentcode die Orchestrierung, und was die Plattform verwaltet, hängt vom Protokoll ab, das Ihr Agent verfügbar macht.

• Mit dem Responses-Protokoll verwaltet die Plattform den Konversationsverlauf und den Sitzungslebenszyklus, und Ihr Code erweitert das Ausführungsverhalten im Rahmen dieses Vertrags.

• Mit dem Invocations-Protokoll verwaltet Ihr Code den Sitzungszustand direkt, und die Plattform stellt keinen Konversationsverlauf bereit.

Jeder gehostete Agent erhält einen dedizierten Endpunktpfad bei der Bereitstellung, der einen eigenen Routing-, Zugriffssteuerungs- und Überwachungsumfang enthält.

Erwägen Sie gehostete Agenten anstelle von Prompt-Agenten, wenn Ihre Arbeitslast eine oder mehrere der folgenden Fähigkeiten erfordert:

• Verwendung von Modellen, die vom Foundry Agent Service nicht unterstützt werden, oder integration mit Tools, die vom Dienst nicht verfügbar gemacht werden

• Feinkörnige, deterministische Kontrolle über den Agent-Ausführungspfad, einschließlich expliziter Orchestrierungsmuster, Aufrufe externer Systeme oder Tools, Prompt-Engineering, Verbindung mit mehreren Agenten oder menschliche Eingriffe in den Prozess.

• Wiederverwenden vorhandener Codebasen oder Bibliotheken, die komplexe Geschäftsprozesse verarbeiten

• Agenten-Code-Überwachung, Inspektion oder Zertifizierung für Sicherheit, Einhaltung oder behördliche Zwecke

• Identitäts- und Endpunktisolation pro Agent, sodass Sie Zugriff auf geringste Rechte, Zugriffssteuerung und Überwachung für jeden Agent festlegen können, ohne Agents in verschiedene Projekte zu trennen

• Feinabstimmung der Konfiguration der Agent-Laufzeit, einschließlich CPU- und Speicherzuweisung für die Sandbox jeder Agentsitzung

• Erweiterter Arbeitsspeicher, der in einer separaten Datenbank zusammen mit dem Gesprächszustand des nativen Foundry Agent Service gespeichert ist.

Gehostete Agents werden weiterhin auf foundry-managed compute ausgeführt, sodass die Plattform weiterhin die Skalierung und die Kernlaufzeit verarbeitet. Die selbstgehostete Orchestrierung ist ein weiterer Schritt, bei dem Sie die Orchestrierungsebene auf Rechenressourcen ausführen, die Sie selbst betreiben, außerhalb des Foundry Agent Service. Wenn Sie Ihre eigene Infrastruktur ausführen, sind Sie für alle Laufzeitmerkmale, Kapazität und Sicherheit verantwortlich.

Komponenten der Anwendungsebene

Current approach: Die Front-End-Website der Chat-UI wird auf dem Web-Apps Feature von App Service gehostet, das eine verwaltete, skalierbare Plattform für Webanwendungen bereitstellt. Web-Apps integriert sich nativ in Azure Netzwerk- und Sicherheitsfeatures.

Alternative Approach: Sie können andere Azure verwaltete Computeplattformen wie Azure Container Apps oder Azure Kubernetes Service (AKS) verwenden, um die Anwendungsebene zu hosten.

Erwägen Sie diese Alternative, wenn Ihre Workload eine der folgenden Bedingungen erfüllt:

• Eine andere Computeplattform unterstützt besser bestimmte Anwendungsfälle, und die Verlagerung von Diensten auf dieser Plattform kann die Kosteneffizienz verbessern und Vorgänge vereinfachen.

• Für Ihre Anwendung sind anspruchsvollere Skalierung, Orchestrierung oder benutzerdefinierte Netzwerke erforderlich.

Der App-Dienst bleibt die bevorzugte Option für die Einfachheit beim Hosten von Webanwendungen und deren APIs.

Grundlagendatenspeicher (Wissensspeicher)

Aktueller Ansatz: Diese Architektur verwendet die KI-Suche als primären Datenspeicher für Grundlagenwissen. Es verwendet KI-Suche mit Vektor- und semantischen Ranking-Funktionen.

Alternativer Ansatz: Sie können andere Datenplattformen zum Erdnen von Wissen wie Azure Cosmos DB, Azure SQL-Datenbank oder anderen OLTP-Datenspeichern (Online Transaction Processing) verwenden. Ihre Datenplattform hängt von Ihren vorhandenen Datenbestands-, Daten-Aktualitätsanforderungen und Abfrageanforderungen ab.

Erwägen Sie diese Alternative, wenn Ihre Workload eine der folgenden Bedingungen erfüllt:

• Sie verwalten bereits Ihr Grundwissen in einer vorhandenen Transaktions- oder Betriebsdatenbank.

• Sie benötigen mehrmodell- oder SDK-Unterstützung, die in der KI-Suche nicht verfügbar ist.

• Sie müssen sich mit spezialisierten Datenquellen oder Altsystemen integrieren.

Die Vektorsuche ist typisch für die abfrage-unterstützte Erstellung (RAG), aber nicht immer notwendig. Weitere Informationen finden Sie unter Choose an Azure service for vector search. Bevor Sie einen Datenspeicher auswählen, bewerten Sie die Datenzugriffsmuster, Latenz und Skalierbarkeitsanforderungen Ihrer Workload.

Der vom Client verwaltete Chatverlauf

Aktueller Ansatz: Diese Architektur verwendet vom Service verwaltete Gespräche im Foundry-Agenten-Service, um den Chatverlauf in Azure Cosmos DB zu speichern. Der Dienst bietet Kontinuität über mehrere Runden und Sitzungen hinweg, ohne dass der Client den Status verwalten muss, und stellt bei der Generierung der Antwort automatisch die gesamte Konversation als Kontext bereit.

Alternativer Ansatz: Die Clientanwendung verwaltet den Unterhaltungsverlauf, anstatt ihn an den Agentdienst zu delegieren. Jede Antwort wird zustandslos generiert, und der Client übermittelt Ausgabeelemente aus früheren Antworten als Eingabe an nachfolgende Anforderungen.

Ziehen Sie eine vom Client verwaltete Konversationshistorie in Betracht, wenn Ihre Workload eine oder mehrere der folgenden Bedingungen erfüllt:

• Keine Datenaufbewahrung. Compliance- oder behördliche Anforderungen verbieten die serverseitige Persistenz von Unterhaltungsinhalten.

• Benutzerdefiniertes Kontextfenster-Steuerelement. Sie müssen frühere Runden selektiv einbeziehen, ausschließen, zusammenfassen oder lokal komprimieren, bevor Sie sie an das Modell senden.

• Mehrere UX-Kanäle mit unabhängiger Sitzungssemantik. Derselbe Agent wird von verschiedenen Anwendungen (Web, Mobil, VoIP) genutzt, die jeweils ihre eigenen Sitzungsverwaltungs-, Speicher- und Aufbewahrungsrichtlinien benötigen.

Dieser Ansatz verlagert die Verantwortung für die Zustandspermanenz, die Kontextverwaltung, die Data-Governance der Konversationsdaten und die Sitzungsisolierung auf Ihren Anwendungscode. Da der Konversationszustand in einem Datenspeicher liegt, der Ihnen gehört, müssen Sie Ihre eigenen Prozesse für Sicherung, Replikation und Wiederherstellung anwenden.

Berücksichtigen Sie die Grenzen des Kontextfensters und die erhöhte Nutzlastgröße der HTTP-Anforderungen durch die Weitergabe von Konversationselementen. Verwenden Sie für die Zuverlässigkeit bei mehreren Gesprächsrunden einen persistenten Speicher wie Azure Cosmos DB oder Ihre bestehende Anwendungsdatenbank anstelle eines reinen in-memory-Zustands.

Vordefinierter Agent oder dynamisch erstellte Agent

Aktueller Ansatz: Die Referenzimplementierung verwendet einen statisch definierten Agent, der als Microservice in Foundry bereitgestellt wird. Die Logik und Datenquellen des Agents werden bei der Bereitstellung konfiguriert und bleiben bis zur nächsten Anwendungsfreigabe unverändert. Dieser Ansatz funktioniert gut, wenn Agentverhalten und Datenquellen über DevOps-Prozesse stabil und gesteuert werden.

Alternativer Ansatz: Sie können Agents zur Laufzeit dynamisch erstellen oder ändern, indem Sie die Foundry-SDKs verwenden. Mit diesem Ansatz können die Anwendung Agents bei Bedarf instanziieren, Systemaufforderungen anpassen oder Verbindungen basierend auf Benutzerkontext oder Geschäftslogik neu konfigurieren.

Erwägen Sie dynamische Agents, wenn Ihre Workload die folgenden Funktionen erfordert:

• Personalisiertes Agent-Verhalten oder Datenquellen für jeden Benutzer oder jede Sitzung

• Häufige oder programmgesteuerte Änderungen an der Agentkonfiguration

• Kurzlebige, kontextspezifische Agentunterstützung für erweiterte Benutzeroberflächen

Dynamisches Agentenmanagement erhöht Flexibilität, führt aber auch die Last des Lebenszyklusmanagements ein. Stellen Sie sicher, dass Sie über geeignete Kontrollmechanismen für die Erstellung, Änderung und Bereinigung von Agenten verfügen.

Wählen Sie den Agent-Ansatz aus, der den Anforderungen ihrer Workload an die Benutzerfreundlichkeit entspricht.

Einzel-Agent- oder Multiagent-Orchestrierung

Aktueller Ansatz: Diese Referenzarchitektur verwendet einen einzelnen Agent, der Zugriff auf alle erforderlichen Tools hat, um die meisten Benutzerinteraktionen effektiv zu verarbeiten.

Alternativer Ansatz: Sie können mehrere spezialisierte Agents koordinieren, bei denen sich jeder Agent auf bestimmte Domänen konzentriert, verschiedene Modelle verwendet oder auf unterschiedliche Tools zugreift.

Berücksichtigen Sie einen Multiagent-Ansatz, wenn Ihre Workload die folgenden Merkmale aufweist:

• Anforderungen umfassen mehrere Fachgebiete, z. B. Finanzanalyse, Rechtliche Überprüfung und technische Implementierung. Spezialisierte Agents bieten tiefere, genauere Antworten innerhalb ihrer jeweiligen Domänen.

• Informationen erfordern unterschiedliche Berechtigungsstufen. Ein Personalmitarbeiter kann auf Mitarbeiterdaten zugreifen, während ein Kundendienstmitarbeiter nur auf Produktinformationen zugreift. Multiagent-Architekturen unterstützen granulare Sicherheitsgrenzen auf Agentebene.

• Verschiedene Abfrageinteraktionen profitieren von verschiedenen Modellen. Ein einfaches Modell verarbeitet einfache Fragen, während ein leistungsfähigeres Modell komplexe Denkaufgaben verarbeitet. Dieser Ansatz optimiert sowohl Kosten als auch Latenz.

• Die Chaterfahrung dient als Front-End für Geschäftsprozesse, die sequenzielle oder parallele Schritte erfordern, die unterschiedliche Spezialisten erfordern.

Multiagent-Ansätze führen aufgrund der Kommunikation zwischen Agenten zu einer Koordinationskomplexität und erhöhter Latenz. Für gut definierte Szenarien ohne strenge Zugriffsisolationsanforderungen erfüllt ein einzelner Agent, der ein Modell und geeignete Tools verwendet, die die Anforderungen erfüllen.

Der Foundry Agent Service unterstützt das Verbinden von Agents mit externen Agents und Tools über Standardprotokolle. Sie können eine Verbindung mit Tools herstellen, die auf MCP-Servern (Model Context Protocol) und anderen Agents über Agent-to-Agent-Endpunkte (A2A) gehostet werden. Öffentliche MCP-Serverendpunkte erfordern Firewallregeln für den Ausgang. Private MCP-Serverendpunkte erfordern die Standard-Agent-Einrichtung mit privatem Netzwerk und einem dedizierten Subnetz. Konfigurieren Sie die entsprechende Authentifizierung für jeden Endpunkt.

Weitere Informationen zum Implementieren mehrerer koordinierter Agents finden Sie unter AI-Agent-Orchestrierungsmuster. In diesem Artikel werden sequenzielle, gleichzeitige Gruppenchats, Übergaben und magentische Orchestrierungsansätze behandelt. Sie können einige Muster im Foundry Agent Service implementieren. Andere Muster erfordern selbst gehostete Orchestrierung mithilfe eines SDK wie Agent Framework.

Überlegungen

Diese Überlegungen implementieren die Säulen des Azure Well-Architected-Frameworks, die eine Reihe von Leitsätzen sind, die Sie verwenden können, um die Qualität einer Arbeitsauslastung zu verbessern. Weitere Informationen finden Sie unter Well-Architected Framework.

Wenden Sie diese Architektur und die Entwurfsrichtlinien für AI-Workloads auf Azure während der Entwurfsphase Ihrer Workloads an.

Zuverlässigkeit

Zuverlässigkeit trägt dazu bei, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie für Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für Zuverlässigkeit.

Die grundlegende App Service-Webanwendungsarchitektur konzentriert sich auf Zonenredundanz für wichtige regionale Dienste. Verfügbarkeitszonen sind physisch getrennte Standorte innerhalb einer Region, die Redundanz bieten, wenn Sie zwei oder mehr Instanzen auf diese Weise bereitstellen. Wenn eine Zone Ausfallzeiten erlebt, bleiben andere Zonen in der Region möglicherweise nicht betroffen. Die Architektur verteilt auch Instanzen und Konfigurationen von Azure Diensten über Verfügbarkeitszonen hinweg. Weitere Informationen finden Sie unter Baseline hochverwendbarte zonenredundante Webanwendung.

In diesem Abschnitt wird die Zuverlässigkeit für Komponenten behandelt, die nicht in der Basisarchitektur des App-Diensts behandelt werden, insbesondere foundry und AI Search.

Zonenredundanz in der Orchestrierungsebene

Unternehmensbereitstellungen erfordern in der Regel Zonenredundanz, um das Risiko von Dienstunterbrechungen durch Fehler auf Zonenebene zu minimieren. In Azure bedeutet Zonenredundanz, dass Sie Ressourcen verwenden, die verfügbarkeitszonen unterstützen und mindestens drei Instanzen bereitstellen oder Redundanz auf Plattformebene aktivieren, wenn die direkte Instanzsteuerung nicht verfügbar ist.

In dieser Architektur hosten Foundry die Foundry Agent Service-Funktion. Die Zuverlässigkeit des Agents hängt von der Verfügbarkeit der Abhängigkeiten des Foundry Agent Service ab, die Azure Cosmos DB, Speicher und KI-Suche sind. Der Foundry Agent Service verwaltet die Daten innerhalb dieser Dienste, aber Sie konfigurieren ihre Zuverlässigkeit in Ihrem Abonnement.

Befolgen Sie die folgenden Empfehlungen, um Zonenredundanz für die Orchestrierungsebene zu erreichen:

• Verwenden Sie zone Redundanz in Ihrem Azure Cosmos DB für NoSQL Konto. Diese Konfiguration stellt die synchrone Datenreplikation über mehrere Zonen hinweg sicher, wodurch das Risiko von Datenverlusten oder Ausfallzeiten durch einen Ausfall einer einzelnen Zone reduziert wird.

  Erwägen Sie auch globale Verteilung, um regionale Ausfälle innerhalb Azure Cosmos DB zu mindern.

• Verwenden Sie den zonenredundanten Speicher (ZRS) für Ihr Speicherkonto. Verwenden Sie für eine höhere Resilienz den geozonenredundanten Speicher (GZRS), der Zonen- und Regionalredundanz kombiniert.

• Konfigurieren Sie Ihre KI-Suchinstanz mit mindestens drei Replikaten. Diese Konfiguration stellt sicher, dass der Dienst Replikate über eindeutige Zonen in Ihrer Region verteilt.

Wenn Ihr Agent in andere workloadspezifische Abhängigkeiten integriert ist, z. B. benutzerdefinierte Toolverbindungen oder externe Datenquellen, stellen Sie sicher, dass diese Abhängigkeiten Ihren Verfügbarkeits- und Redundanzanforderungen entsprechen. Jede einzelzonen- oder nicht redundante Abhängigkeit kann die Gesamtzuverlässigkeit der Orchestrierungsebene beeinträchtigen.

Das Foundry-Portal, seine Datenebenen-APIs und die Funktion "Foundry Agent Service" bieten keine direkten Steuerelemente für Zonenredundanz.

Zuverlässigkeit im Hosting des Foundry-Modells

Foundry stellt Modelle als Dienst (MaaS) bereit, die mit mehreren Bereitstellungsoptionen gehostet werden. Diese Optionen unterstützen in erster Linie die Kontingent- und Durchsatzverwaltung und nicht die herkömmliche hohe Verfügbarkeit innerhalb einer Region. Standardmodellbereitstellungen werden in einer einzelnen Region ausgeführt und unterstützen keine Verfügbarkeitszonen. Um die Verfügbarkeit über mehrere Rechenzentren hinweg zu erreichen, müssen Sie entweder eine globale Bereitstellung oder ein Datenzonenmodell verwenden.

Stellen Sie für Unternehmenschatszenarien sowohl eine bereitgestellte Datenzone als auch ein Datenzonen-Standardmodell bereit. Konfigurieren Sie Spillover, um übermäßigen Datenverkehr oder Ausfälle zu bewältigen. Wenn Ihre Workload keine geringe Latenz oder strenge geografische Datenbewahrung und -verarbeitung erfordert, verwenden Sie globale Bereitstellungen für maximale Resilienz.

Foundry unterstützt keine erweiterten Lastverteilungs- oder Failover-Mechanismen wie Round-Robin-Routing oder Circuit Breaking für Modellbereitstellungen. Wenn Sie granulare Redundanz und Failover-Steuerung innerhalb einer Region benötigen, hosten Sie die Modellzugriff-Logik außerhalb des verwalteten Dienstes. Sie können beispielsweise ein benutzerdefiniertes Gateway mithilfe von Azure API Management erstellen. Mit diesem Ansatz können Sie benutzerdefinierte Routing-, Integritätsprüfungen und Failoverstrategien implementieren. Sie erhöht aber auch die Betriebskomplexität und verschiebt die Verantwortung für die Zuverlässigkeit dieser Komponente in Ihr Team.

Sie können auch gateway-gestützte Modelle als benutzerdefinierte, API-basierte Werkzeuge für Ihren Agenten verfügbar machen. Weitere Informationen finden Sie unter Verwenden Sie ein Gateway vor mehreren Azure OpenAI-Bereitstellungen oder -Instanzen.

Zuverlässigkeit in der KI-Suche nach Unternehmenskenntnissen

Stellen Sie die KI-Suche mithilfe des Standard-Preisniveaus oder höher in einer Region bereit, die Verfügbarkeitszonen unterstützt. Konfigurieren Sie mindestens drei Replikate, um sicherzustellen, dass der Dienst Instanzen über separate Verfügbarkeitszonen verteilt. Diese Konfiguration bietet Resilienz für Fehler auf Zonenebene und unterstützt hohe Verfügbarkeit für Suchvorgänge.

Verwenden Sie die folgenden Methoden, um die optimale Anzahl von Replikaten und Partitionen für Ihre Workload zu ermitteln:

• Überwachen Sie die KI-Suche mithilfe integrierter Metriken und Protokolle. Überwachen Sie die Abfragelatenz, Drosselung und Ressourcennutzung.

• Verwenden Sie Überwachungsmetriken und Protokolle und Leistungsanalysen, um die entsprechende Anzahl von Replikaten zu ermitteln. Dieser Ansatz hilft Ihnen, Drosselungen aufgrund eines hohen Abfragevolumens, unzureichender Partitionen oder Indexbeschränkungen zu vermeiden.

• Stellen Sie die Zuverlässigkeit der Indizierung sicher, indem Sie Unterbrechungen durch regelmäßige Indizierung oder Indizierungsfehler vermeiden. Erwägen Sie, in einen Offlineindex zu indizieren, und ersetzen Sie Ihren Liveindex durch Ihren neu erstellten Index, nachdem Sie die Datenintegrität überprüft haben.

Zuverlässigkeit in Azure Firewall

Azure Firewall ist eine kritische Egress-Kontrollstelle in dieser Architektur, stellt jedoch einen einzelnen Ausfallpunkt für den gesamten ausgehenden Datenverkehr dar. Um dieses Risiko zu verringern, stellen Sie Azure Firewall across alle Verfügbarkeitszonen in Ihrer Region bereit. Diese Konfiguration trägt dazu bei, ausgehende Verbindungen aufrechtzuerhalten, wenn eine Zone nicht verfügbar ist.

Wenn Ihre Workload ein hohes Volumen gleichzeitiger ausgehender Verbindungen erfordert, konfigurieren Sie Azure Firewall mit mehreren öffentlichen IP-Adressen. Dieser Ansatz verteilt SNAT-Verbindungen (Source Network Address Translation) über mehrere IP-Adresspräfixe, wodurch das Risiko einer SNAT-Portausschöpfung reduziert wird. Die SNAT-Erschöpfung kann zu unterbrechungs- oder totalem Verlust der ausgehenden Konnektivität für Agents und andere Workloadkomponenten führen, was zu Ausfallzeiten von Features oder zu leistungseinbußen führt.

Überwachen sie die SNAT-Portnutzung und den Firewallstatus. Wenn Sie Verbindungsfehler oder Durchsatzprobleme erkennen, überprüfen Sie Firewallmetriken und Protokolle, um SNAT-Erschöpfung oder andere Engpässe zu identifizieren und zu beheben.

Abhängigkeiten des Foundry Agent Service von ähnlichen Workloads isolieren

Um die Zuverlässigkeit zu maximieren und den Strahlradius von Fehlern zu minimieren, isolieren Sie die Abhängigkeiten des Foundry Agent Service streng von anderen Workloadkomponenten, die dieselben Azure Dienste verwenden. Insbesondere sollten Sie AI Search-, Azure Cosmos DB- oder Storage-Ressourcen nicht zwischen dem Agent-Dienst und anderen Anwendungskomponenten gemeinsam nutzen. Stellen Sie stattdessen dedizierte Instanzen für die erforderlichen Abhängigkeiten des Agentdiensts bereit.

Diese Trennung bietet zwei wichtige Vorteile:

• Sie enthält Fehler oder Leistungsbeeinträchtigungen für ein einzelnes Workloadsegment, wodurch kaskadierende Effekte über nicht verwandte Anwendungsfeatures hinweg verhindert werden.

• Auf diese Weise können Sie gezielte betriebliche Prozesse wie Sicherung, Wiederherstellung und Failover anwenden. Diese Prozesse richten sich an die spezifischen Verfügbarkeits- und Wiederherstellungsanforderungen des Workloadflusses, der diese Ressourcen verwendet.

Wenn Ihre Chat-UI-Anwendung beispielsweise den Transaktionsstatus in Azure Cosmos DB speichern muss, richten Sie für diesen Zweck ein separates Azure Cosmos DB Konto und eine eigene Datenbank ein, anstatt das Konto oder die Datenbank erneut zu verwenden, das der Foundry Agent Service verwaltet. Selbst wenn kosten- oder betriebliche Einfachheit die Ressourcenfreigabe motiviert, überwiegt das Risiko eines Zuverlässigkeitsereignisses, das sich auf nicht verwandte Workloadfeatures auswirkt, die potenziellen Einsparungen in den meisten Unternehmensszenarien.

Von Bedeutung

Wenn Sie aus Kosten- oder Betriebsgründen arbeitslastspezifische Daten zusammen mit den Abhängigkeiten des Agent bereitstellen, interagieren Sie niemals direkt mit den vom System verwalteten Daten, wie Sammlungen, Containern oder Indizes, die der Foundry Agent Service erstellt. Diese internen Implementierungsdetails sind nicht dokumentiert und können ohne vorherige Ankündigung geändert werden. Der direkte Zugriff kann den Agentdienst unterbrechen oder zu Datenverlust führen. Verwenden Sie immer die Findry Agent Service-Datenebenen-APIs für die Datenmanipulation, z. B. das Erfüllen des Rechts auf Vergessenwerden (RTBF)-Anforderungen. Behandeln Sie die zugrunde liegenden Daten als unzugänglich und überwachen Sie sie nur.

Mehrregionen-Design

Diese Architektur verwendet Verfügbarkeitszonen für hohe Verfügbarkeit innerhalb einer einzelnen Azure Region. Es ist keine Multiregion-Lösung. Es fehlen die folgenden kritischen Elemente, die für regionale Resilienz und Notfallwiederherstellung (DR) erforderlich sind:

• Globale Eingangs- und Datenverkehrsweiterleitung
• DNS-Verwaltung für Failover
• Datenreplikations- oder Isolationsstrategien in allen Regionen
• Eine Aktiv-Aktiv-, Aktiv-Passiv- oder Aktiv-Kalt-Zuordnung
• Regionale Failover- und Failback-Prozesse zur Einhaltung von Wiederherstellungszeitzielen (RTOs) und Wiederherstellungspunktzielen (RPOs)
• Berücksichtigung der regionalen Verfügbarkeit für Entwicklererfahrungen, einschließlich des Foundry-Portals und der Datenebene-APIs.

Wenn Ihre Workload Geschäftskontinuität erfordert, wenn ein regionaler Ausfall auftritt, müssen Sie zusätzliche Komponenten und betriebliche Prozesse über diese Architektur hinaus entwerfen und implementieren. Insbesondere müssen Sie den Lastenausgleich und failover auf jeder Architekturebene behandeln, einschließlich der folgenden Bereiche:

• Datenabgleichstools und die ihnen zugrunde liegenden Datenspeicher
• Modellhosting- und Ableitungsendpunkte
• Die Orchestrierungs- oder Agentenschicht
• Benutzerorientierter UI-Datenverkehr und DNS-Einstiegspunkte

Sie müssen auch sicherstellen, dass Überwachbarkeit, Monitoring und Inhaltsicherheit in allen Regionen funktionsfähig und konsistent bleiben.

Diese Basisarchitektur verfügt nicht über multiregionsübergreifende Funktionen, sodass regionale Ausfälle wahrscheinlich zu einem Dienstverlust innerhalb Ihrer Workload führen.

Notfallwiederherstellung

Die Chatarchitekturen enthalten zustandsbehaftete Komponenten, daher müssen Sie für Disaster Recovery (DR) planen. Diese Workloads erfordern in der Regel einen Speicher für aktive oder angehaltene Chatsitzungen. Sie benötigen außerdem Speicherplatz für zusätzliche Daten, wie Dokumente oder Bilder, die zu Chats hinzugefügt werden. Die Agent-Orchestrierungsebene kann auch den Status aufrechterhalten, der für Gesprächsabläufe spezifisch ist. In dieser Architektur verwendet der Foundry Agent Service Azure Cosmos DB, Storage und AI Search, um den Betriebs- und Transaktionsstatus beizubehalten. Der Lebenszyklus und die Kopplung dieses Zustands über Komponenten hinweg bestimmen Ihre DR-Strategie und Wiederherstellungsvorgänge.

Der Foundry Agent Service bietet keine integrierten DR-Funktionen. Es fehlt an Funktionen zum Replizieren des Zustands, zum Erstellen von Sicherungen oder zum Ausführen von Point-in-Time-Wiederherstellungen. Die Wiederherstellung erfolgt durch Rekonstruktion, nicht durch die Hochstufung einer Replik. Ein Zwischenfall kann Agenten, Konversationen und Wissensdaten dauerhaft entfernen. Planen Sie die Möglichkeit des totalen Zustandsverlusts für zustandsbehaftete Inhalte und legen Sie die Wiederherstellungserwartungen entsprechend mit den Beteiligten fest.

Die folgenden kompensierenden Kontrollen, basierend auf dem Foundry-Agentendienst-DR-Leitfaden, verringern die Wahrscheinlichkeit und den Umfang des Datenverlusts, beseitigen ihn jedoch nicht.

• Azure Cosmos DB: Aktivieren Sie die fortlaufende Sicherung für die enterprise_memory Datenbank, einschließlich Agentdefinitionen und Chatunterhaltungen. Die kontinuierliche Sicherung ermöglicht eine Point-in-Time-Wiederherstellung (PITR) zu jedem Zeitpunkt innerhalb des Aufbewahrungszeitraums, der die vorherigen sieben Tage umfasst. Testen Sie ihren Wiederherstellungsvorgang regelmäßig, um sicherzustellen, dass er Ihren RTO erfüllt und dass die wiederhergestellten Daten für den Agentdienst verfügbar bleiben. Stellen Sie immer dasselbe Konto und dieselbe Datenbank wieder her.

• KI-Suche: DIE KI-Suche verfügt nicht über integrierte Wiederherstellungsfunktionen und unterstützt keine direkte Indexmanipulation. Wenn Datenverlust oder Beschädigung auftritt, müssen Sie sich an Microsoft-Support wenden, um Unterstützung bei den verfügbaren Indexwiederherstellungsoptionen zu erhalten. Diese Einschränkung kann sich erheblich auf Ihre RTO auswirken. Wenn Ihre Chat-UI Dateiuploads nicht unterstützt und Sie keine Agents haben, die statische Dateien als Wissen verwenden, benötigen Sie möglicherweise keinen DR-Plan für die KI-Suche.

  Bewahren Sie eine separate, regelmäßig aktualisierte verlässliche Informationsquelle für Ihr unternehmensspezifisches Wissen auf. Diese Übung stellt sicher, dass Sie Indizes bei Bedarf neu erstellen können.

• Speicher: Wenn Sie über ein georedundantes Speicherkonto verfügen, verwenden Sie kundenseitig verwaltetes Failover für Blob-Container, die vom Foundry Agent Service genutzt werden. Mit diesem Setup können Sie ein Failover während eines regionalen Ausfalls initiieren. Wenn Sie nur ZRS verwenden, wenden Sie sich an Microsoft Support zum Wiederherstellen von Daten. Dieser Vorgang kann Ihr RTO verlängern. Wie bei der KI-Suche benötigen Sie möglicherweise keinen DR-Plan für BLOB-Container, wenn Ihre Chat-UI Dateiuploads nicht unterstützt und Sie keine Agents haben, die statische Dateien als Wissen verwenden.

• Transaktionale Konsistenz: Wenn der Statusspeicher in Ihrer Workload auf Azure AI-Agent-IDs wie Konversations-IDs oder Agent-IDs verweist, koordinieren Sie die Wiederherstellung über alle relevanten Datenspeicher hinweg. Das Wiederherstellen einer Teilmenge von Abhängigkeiten kann zu verwaisten oder inkonsistenten Daten führen. Entwerfen Sie Ihre DR-Prozesse, um die referentielle Integrität zwischen Ihrer Arbeitslast und dem Status des Agentendienstes aufrechtzuerhalten.

• Agentdefinitionen und -konfiguration: Definieren Sie Agents als Code. Speichern von Agentdefinitionen, Verbindungen, Systemaufforderungen und Parametern in der Quellcodeverwaltung. Diese Vorgehensweise ermöglicht es Ihnen, Agents aus einer bekanntermaßen fehlerfreien Konfiguration neu bereitzustellen, falls die Orchestrierungsebene ausfällt. Vermeiden Sie es, nicht nachverfolgte Änderungen an der Agentkonfiguration über das Findry-Portal oder Datenebenen-APIs vorzunehmen. Durch diesen Ansatz wird sichergestellt, dass Ihre bereitgestellten Agents reproduzierbar bleiben.

• Foundry-Projekte: Verwenden Sie eine benutzerseitig zugewiesene verwaltete Identität als Identität für ein Projekt. Wenn das Projekt versehentlich gelöscht wird, können Sie mit einer vom Benutzer zugewiesenen verwalteten Identität Ihre vorhandenen Rollenzuweisungen wiederverwenden, wenn Sie das Projekt und dessen Funktionshost erneut erstellen. Durch diesen Ansatz wird die Koordination reduziert, die bei der Wiederherstellung von Projektabhängigkeiten erforderlich ist.

Als zusätzliche präventive Maßnahme für die Abhängigkeiten des Foundry Agent Service fügen Sie jedem Dienst eine Löschressourcensperre hinzu. Diese Praxis trägt zum Schutz vor katastrophalem Zustandsverlust in der KI-Suche, Azure Cosmos DB und Cloud-Speicher bei.

Bevor Sie in die Produktion übergehen, erstellen Sie ein Wiederherstellungs-Runbook, das Fehler sowohl im anwendungseigenen Zustand als auch im agenteigenen Zustand behandelt.

Sicherheit

Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Entwurfsprüfliste für die Sicherheit.

Diese Architektur erweitert die Sicherheitsbasis, die in der grundlegenden Referenzarchitektur des Foundry-Chats eingerichtet wurde. Es fügt einen Netzwerksicherheitsperimeter neben dem Identitätsperimeter aus der grundlegenden Architektur hinzu. Aus Netzwerksicht ist Das Anwendungsgateway die einzige ressource, die über das Internet verfügbar gemacht wird. Die Chat-UI-Anwendung wird benutzern zur Verfügung gestellt. Aus Identitätsperspektive sollte die Chat-UI Anforderungen authentifizieren und autorisieren. Verwenden Sie verwaltete Identitäten, wenn möglich, um Anwendungen für Azure Dienste zu authentifizieren.

Identitäts- und Zugriffsverwaltung

Diese Architektur verwendet in erster Linie vom System zugewiesene verwaltete Identitäten für die Dienst-zu-Dienst-Authentifizierung. Sie können auch vom Benutzer zugewiesene verwaltete Identitäten verwenden. Wenden Sie in beiden Fällen die folgenden Prinzipien an:

• Isolieren Sie Identitäten nach Ressource und Funktion. Erstellen Sie unterschiedliche verwaltete Identitäten für die folgenden Komponenten:

  • Die Foundry-Ressource
  • Jedes Foundry-Projekt
  • Die Webanwendung
  • Application Gateway
  • Beliebiger benutzerdefinierter Orchestrator- oder Integrationscode

• Verwenden Sie Zuordnungseinschränkungen (Vorschau). Microsoft.CognitiveServices/accounts/projects Nur für Foundry-Projektidentitäten, Microsoft.Web/sites für Webanwendungsidentitäten und Microsoft.Network/applicationGateways für Anwendungsgatewayidentitäten zulassen. Legen Sie den Isolationsbereich auf Regional, und erstellen Sie einen separaten Satz von Identitäten für jede Bereitstellungsregion.

• Weisen Sie einer Azure Ressource nur eine Identität zu, wenn diese Ressource sich als Client bei einem anderen Azure Dienst authentifizieren muss.

• Verwenden Sie zweckmäßige Identitätstypen. Verwenden Sie nach Möglichkeit Arbeitsauslastungsidentitäten für Anwendungen und Automatisierung, und verwenden Sie Agent-Identitäten für KI-Agents.

Gemeinsame Nutzung und Isolierung von Foundry-Ressourcen

Diese Architektur stellt eine dedizierte Foundry-Ressource für einen einzelnen Produktionsworkload bereit. Die vollständig isolierte Workloadtopologie ist die empfohlene Topologie für Produktionsworkloads. Die Foundry-Ressource ist die Netzwerkgrenze und die Identitätsgrenze für alles, was darin ausgeführt wird. Eine dedizierte Ressource trennt den Compliance-Bereich, den Blast-Radius und das Kontingent dieser Arbeitslast von nicht damit verbundenen Arbeitslasten sowie von Ihren Vorproduktionsumgebungen. Diese Wahl entspricht den veröffentlichten Leitlinien zur gemeinsamen Nutzung von KI-Plattformen, in denen empfohlen wird, standardmäßig eine einzige KI-Plattform-Instanz pro Produktions-Arbeitslast zu verwenden.

Die vollständig isolierte Topologie verursacht im Vergleich zur gemeinsamen Ausführung von Workloads in einer gemeinsam genutzten Foundry-Ressource zusätzlichen Einrichtungs- und Verwaltungsaufwand. Diese Architektur akzeptiert diesen Kompromiss im Austausch für Segmentierung und unabhängige Zugriffssteuerung, Kontingent und Kostengrenzen, die für die meisten Produktionsworkloads erforderlich sind.

Verbindungen

Verbindungen definieren, wie sich eine Foundry-Ressource oder ein einzelnes Projekt bei einer externen Abhängigkeit authentifiziert und diese nutzt. Erstellen Sie nach Möglichkeit Verbindungen auf Projektebene. Entfernen Sie nicht verwendete Verbindungen. Bevorzugen Sie Microsoft Entra ID-basierte Authentifizierung für alle Verbindungen.

Wenn eine Verbindung Microsoft Entra ID nicht unterstützt, müssen Sie einen geheimen Schlüssel wie einen API-Schlüssel angeben. Speichern Sie diese Geheimnisse in einem dedizierten, selbst gehosteten Azure Schlüsseltresor. Konfigurieren Sie eine Azure Key Vault Verbindung für die Foundry-Ressource, damit der Dienst die geheimen Schlüssel lesen und schreiben kann, die es verwaltet.

Verwenden Sie diesen Schlüsselspeicher ausschließlich für Foundry. Teilen Sie sie nicht mit anderen Workloadkomponenten. Alle Nicht-Microsoft Entra ID Verbindungen in allen Projekten in der Ressource speichern ihre geheimen Schlüssel in diesem Tresor. Andere Workloadkomponenten benötigen keinen Zugriff auf diese geheimen Schlüssel, um Foundry-Funktionen zu verwenden. Erteilen Sie anderen Komponenten keine Lese- oder Schreibberechtigungen für diesen Tresor, es sei denn, Sie haben eine klare betriebliche Anforderung, oder akzeptieren Sie den Kompromiss.

Diese Architektur umfasst zwei API-schlüsselbasierte Verbindungen: Application Insights for Foundry-Metriken und das Websuchtool. Wenn Sie diese Architektur mit Tools erweitern, die externe HTTP-Endpunkte aufrufen, z. B. MCP-Server oder openAPI-definierte APIs, fügt jedes Tool eine Projektverbindung hinzu, die seine Authentifizierungsanmeldeinformationen enthält.

Wenn Sie einen MCP-Server verbinden, beschränken Sie die verfügbaren Tools mithilfe von allowed_tools. Erfordern und protokollieren Sie die Genehmigung für Vorgänge mit hohem Risiko, z. B. Tools, die Daten schreiben oder Ressourcen ändern, und überprüfen Sie den Namen und die Argumente des Tools vor der Genehmigung. Weitere Informationen finden Sie unter MCP best practices.

Wenn Sie vom Kunden verwaltete Schlüssel für die Verschlüsselung verwenden, können Sie sowohl die vom Kunden verwalteten Schlüssel als auch die Verbindungsschlüssel im selben dedizierten Tresor hosten, wenn Ihre Sicherheitsgovernancerichtlinien die Kolocation von Verschlüsselungsschlüsseln und geheimen Schlüsseln ermöglichen.

Zugriff auf das Foundry-Portal für Mitarbeiter

Wenn Sie Mitarbeiter in Foundry-Projekte integrieren, weisen Sie die für ihre Rolle erforderlichen Mindestberechtigungen zu. Verwenden Sie Microsoft Entra ID Gruppen und Azure rollenbasierte Zugriffssteuerung (Azure RBAC), um die Trennung von Aufgaben zu erzwingen. Unterscheiden Sie beispielsweise Agententwickler von Datenwissenschaftlern, die Feinabstimmungsaufgaben ausführen. Aber verstehen Sie die Einschränkungen und Risiken. Ordnen Sie Personas den in Foundry integrierten Rollen und Azure RBAC-Rollen zu, z. B.:

Persona	Eingebaute Rolle	Geltungsbereich
Ressourcen-Manager für Foundry	Besitzer des Foundry-Kontos	Foundry-Ressource
Agent-Entwickler oder Data Scientist	Foundry-Benutzer im Foundry-Projekt sowie Leser der Foundry-Ressource	Foundry-Projekt und Foundry-Ressource

Die Berechtigungen in den einzelnen integrierten Rollen und zusätzlichen Enterprise-Zuordnungsbeispielen finden Sie unter Role-basierte Zugriffssteuerung für Microsoft Foundry.

Das Foundry-Portal führt viele Aktionen aus, indem die Identität des Diensts anstelle der Identität des Mitarbeiters verwendet wird. Daher haben Mitarbeiter, die eingeschränkte Azure RBAC-Rollen haben, möglicherweise Einblicke in vertrauliche Daten, z. B. Chatunterhaltungen, Agentdefinitionen und Konfiguration. Dieses Findry-Portaldesign kann versehentlich Ihre gewünschten Zugriffsbeschränkungen umgehen und mehr Informationen als beabsichtigt verfügbar machen.

Um das Risiko eines nicht autorisierten Zugriffs zu verringern, beschränken Sie die Portalnutzung in Produktionsumgebungen auf Mitarbeiter, die über einen klaren betrieblichen Bedarf verfügen. Für die meisten Mitarbeiter können Sie den Zugriff auf das Foundry-Portal in der Produktion widerrufen oder blockieren. Verwenden Sie stattdessen automatisierte Bereitstellungspipelinen und -infrastruktur als Code (IaC), um die Agent- und Projektkonfiguration zu verwalten.

Behandeln Sie das Erstellen neuer Projekte in einer Foundry-Ressource als privilegierte Aktion. Projekte, die über das Portal erstellt wurden, erben nicht automatisch Ihre etablierten Netzwerksicherheitskontrollen, z. B. private Endpunkte oder Netzwerksicherheitsgruppen (NSGs). Neue Agents in diesen Projekten umgehen Ihren vorgesehenen Sicherheitsperimeter. Erzwingen Sie die Projekterstellung ausschließlich über Ihre kontrollierten, auditierbaren IaC-Prozesse.

Gießerei-Projekt-Rollenzuweisungen und -Verbindungen

Um den Foundry Agent Service im Standardmodus zu verwenden, muss das Projekt über Berechtigungen für Daten und Steuerungsebenen für die Abhängigkeiten des Foundry Agent Service verfügen. Insbesondere muss die verwaltete Identität des Projekts über erhöhte Rollenzuweisungen für das Speicherkonto, die KI-Suche und das Azure Cosmos DB-Konto verfügen. Diese Berechtigungen bieten nahezu vollständigen Zugriff auf diese Ressourcen, einschließlich der Möglichkeit, Daten zu lesen, zu schreiben, zu ändern oder zu löschen. Um den Zugriff mit geringstmöglichen Berechtigungen zu gewährleisten, isolieren Sie Ihre Workload-Ressourcen von den Abhängigkeiten des Foundry Agent Service.

Alle Agents innerhalb eines einzelnen Foundry-Projekts verwenden dieselbe verwaltete Identität. Wenn Ihre Workload mehrere Agents verwendet, die Zugriff auf verschiedene Ressourcengruppen erfordern, befolgen Sie das Prinzip der geringsten Berechtigungen und erstellen ein separates Foundry-Projekt für jedes unterschiedliche Agent-Zugriffsmuster. Mit dieser Trennung können Sie nur die mindestens erforderlichen Berechtigungen für die verwaltete Identität jedes Projekts zuweisen, wodurch das Risiko eines übermäßigen oder unbeabsichtigten Zugriffs reduziert wird. Dieses Modell der gemeinsamen Identität gilt für die Prompt-Agents in dieser Architektur. Ein bereitgestellter gehosteter Agent erhält stattdessen seine eigene Microsoft Entra Agentidentität bei der Bereitstellung, sodass Sie den Zugriff auf Tools und downstream-Ressourcen pro Agent gewähren und überwachen können, ohne Zugriffsmuster in verschiedene Projekte zu trennen.

Wenn Sie connections mit externen Ressourcen innerhalb von Foundry einrichten, verwenden Sie Microsoft Entra ID-basierte Authentifizierung, falls verfügbar. Bei diesem Ansatz wird die Notwendigkeit beseitigt, vorausgeteilte Geheimnisse zu beibehalten. Beschränken Sie jede Verbindung so, dass nur das besitzereigene Projekt sie verwenden kann. Wenn mehrere Projekte Zugriff auf dieselbe Ressource benötigen, erstellen Sie in jedem Projekt eine separate Verbindung, anstatt eine einzelne Verbindung für alle Projekte freizulegen. Diese Vorgehensweise erzwingt strenge Zugriffsgrenzen und verhindert, dass zukünftige Projekte den Zugriff erben, den sie nicht benötigen.

Vermeiden Sie das Erstellen von Verbindungen auf der Ressourcenebene der Gießerei, da Verbindungen auf Ressourcenebene für alle aktuellen und zukünftigen Projekte in der Ressource gelten. Sie können versehentlich breiten Zugriff auf Ressourcen gewähren, die geringsten Berechtigungsprinzipien verletzen und das Risiko einer nicht autorisierten Datenexposition erhöhen. Erstellen Sie nur Verbindungen auf Projektebene.

Gesprächsisolation

Der Foundry Agent Service erzwingt keine Benutzerautorisierung für Unterhaltungen. Die Identität des Anwendungsservers verfügt über Anmeldeinformationen auf Projektebene, mit denen durch Angabe der ID auf jede Kommunikation gelesen oder in diese geschrieben werden kann. Wenn die Chat-UI-Anwendung eine vom Client bereitgestellte Unterhaltungs-ID ohne Überprüfung direkt an den Agentdienst übergibt, kann ein Benutzer auf Nachrichten zugreifen oder in die Unterhaltung eines anderen Benutzers einfügen. Dies ist eine Sicherheitsanfälligkeit in der Autorisierung auf fehlerhafter Objektebene .

Ihr Anwendungsserver muss die Eigentumsrechte an Kommunikationen durchsetzen. Vertrauen Sie keine Konversationskennungen vom Client. Vergewissern Sie sich bei jeder Anforderung, dass der authentifizierte Benutzer die referenzierte Unterhaltung besitzt, bevor Sie die Anforderung an den Agent-Dienst weiterleiten.

Gehostete Agents bieten ein Sitzungsisolationsmodell pro Benutzer , aber die Topologie dieser Architektur bestimmt, ob sie gilt. Die Webanwendung ruft den Agent im Namen jedes angemeldeten Benutzers mit eigener Workloadidentität auf, sodass die Plattform eine einzelne Anruferidentität sieht und einen Endbenutzer nicht von einem anderen unterscheiden kann. Bei diesem Muster bleibt Ihr Anwendungsserver die Vertrauensgrenze und muss die Eigentümerschaft von Konversationen wie zuvor beschrieben durchsetzen.

Die Isolation wird anwendbar, wenn die Anforderung an den Endpunkt des gehosteten Agents die Identität des Endbenutzers und nicht nur die Identität der Anwendung trägt. Entweder authentifiziert sich der Aufrufer direkt mit seinem eigenen Microsoft Entra-Token, oder Ihr Anwendungsserver übergibt den stabilen Bezeichner des Endbenutzers an die Plattform. Wenn die Anfrage den Endbenutzer identifiziert, ordnet die Plattform Konversationen, Sitzungen, gespeicherte Daten und das Dateisystem $HOME pro Sitzung der in der Anfrage angegebenen Identität zu. Wenn jeder Anrufer seine eigene Identität darstellt, trennt dies die Daten eines Benutzers von den Anderen. Bei delegierten Identitäten trennt die Plattform keinen delegierten Benutzer von einem anderen, sodass die gleiche zuvor beschriebene Anwendungsservererzwingung weiterhin gilt.

Wenn Ihr Anwendungsserver Endbenutzeridentitäten delegiert, kann er auch viele Benutzer in einer begrenzten Gruppe von Agentsitzungen bündeln, anstatt eine Agentsitzung pro Benutzer zu öffnen. Die Plattform begrenzt gleichzeitige Agentsitzungen pro Abonnement und Region, und diese Obergrenze zählt nur Agentsitzungen, die eine Anforderung aktiv verarbeiten. Wenn Nutzer eine Agent-Sitzung gemeinsam verwenden, isoliert die Plattform weiterhin den Konversationszustand jedes Nutzers, aber alle Daten, die der Agent-Container selbst speichert, etwa Dateien, Datenbankzeilen oder ein Cache, werden nicht automatisch voneinander getrennt. Ihr Code muss diese Daten sowohl der Agentensitzung als auch der Endbenutzeridentität zuordnen. Andernfalls können Benutzer in derselben poolierten Sitzung die gespeicherten Daten des anderen lesen. Informationen zu den Zuordnungsstrategien und dieser Partitionierung pro Benutzer finden Sie unter Multiplex mehrerer Benutzer in einer gehosteten Agentsitzung.

Inhaltssicherheit

Jedes Modell in Ihrer Bereitstellung sollte eine Inhaltsfilterrichtlinie zuweisen, die Eingabeaufforderungen und Modellvervollständigungen auf schädliche Inhalte überprüft.

Bewerten Sie die standardmäßig von Microsoft verwaltete Richtlinie im Hinblick auf die Inhaltssicherheitsanforderungen Ihrer Workload. Wenn die Standardschwellenwerte diese Anforderungen nicht erfüllen, erstellen Sie eine benutzerdefinierte Inhaltsfilterrichtlinie, und binden Sie sie an die Bereitstellung. Verwalten Sie die Richtlinie zusammen mit dem Rest Ihrer Infrastruktur als Code, sodass die Inhaltssicherheitskonfiguration in allen Umgebungen versionsgesteuert und konsistent bleibt.

Vernetzung

Zusätzlich zum identitätsbasierten Zugriff erfordert diese Architektur die Netzwerkvertraulichkeit.

Das Netzwerkdesign umfasst die folgenden Sicherheitsvorkehrungen:

• Ein einzelner, sicherer Einstiegspunkt für den gesamten Chat-UI-Datenverkehr, der die Angriffsfläche minimiert

• Gefilterter Eingangs- und Ausgang des Netzwerkdatenverkehrs mithilfe einer Kombination aus NSGs, einer Webanwendungsfirewall, benutzerdefinierten Routen (UDRs) und Azure Firewall Regeln

• End-to-End-Verschlüsselung von Daten während der Übertragung mithilfe von TLS

• Netzwerkdatenschutz mithilfe von Private Link für alle Azure PaaS-Dienstverbindungen

• Logische Segmentierung und Isolierung von Netzwerkressourcen mit dedizierten Subnetzen für jede Hauptkomponentengruppierung zur Unterstützung granularer Sicherheitsrichtlinien

Netzwerkflüsse

Das Diagramm ähnelt der geplanten End-to-End-Chatarchitektur. Sie umfasst die Azure OpenAI-Architektur und drei nummerierte Netzwerkflüsse. Der eingehende Fluss und der Fluss von App Service zu Azure PaaS-Dienste werden aus der grundlegenden App Service-Webarchitektur kopiert. Der Ablauf des Foundry Agent Service zeigt einen Pfeil vom privaten Foundry-Endpunkt im privaten virtuellen Netzwerk, der auf den Foundry Agent Service verweist. Der zweite nummerierte Pfeil im Fluss "Foundry Agent Service" zeigt Aufrufe aus der virtuellen Azure AI-Agent-Schnittstelle im privaten Netzwerk, die über private Endpunkte fließen. Der dritte nummerierte Pfeil zeigt einen Pfeil von der virtuellen Schnittstelle zu einem Azure Firewall Feld, das angibt, dass alle Aufrufe des Internets über diese Firewall fließen.

Die baseline App Service-Webanwendungsarchitektur beschreibt den eingehenden Fluss vom Benutzer zur Chatbenutzeroberfläche und den Fluss von App Service zu Azure PaaS-Dienste. Dieser Abschnitt konzentriert sich auf Agentinteraktionen.

Wenn die Chat-UI mit dem in Foundry bereitgestellten Agent kommuniziert, treten die folgenden Netzwerkflüsse auf:

1. Die vom App Service gehostete Chat-UI initiiert HTTPS-Anforderungen über einen privaten Endpunkt an den API-Endpunkt der Foundry-Datenebene.

2. Wenn der Agent auf Azure PaaS-Dienste zugreift, z. B. Dienstabhängigkeiten, benutzerdefinierte Wissensspeicher oder benutzerdefinierte Tools, sendet der Einzelmandantendatenproxy im delegierten Subnetz HTTPS-Anforderungen an die privaten Endpunkte dieser Dienste.

3. Wenn der Agent auf Ressourcen außerhalb des virtuellen Netzwerks zugreift, einschließlich internetbasierter APIs oder externer Dienste, leitet der Datenproxy diese HTTPS-Anforderungen vom delegierten Subnetz über Azure Firewall weiter.

Private Endpunkte dienen als kritische Sicherheitskontrolle in dieser Architektur, indem sie die identitätsbasierte Sicherheit ergänzen. Da diese Architektur private Endpunkte und UDRs in Ihrem virtuellen Netzwerk verwendet, wird die Netzwerksicherheitsperimeterfunktion von Foundry-Projekten nicht unterstützt.

Eingangsverkehr zu Foundry

Diese Architektur blockiert den öffentlichen Zugriff auf die Gießereidatenebene, indem datenverkehr nur über einen privaten Link für Foundry zugelassen wird. Sie können über die Portalwebsite auf den großteil des Foundry-Portals zugreifen, aber alle Funktionen auf Projektebene erfordern Netzwerkzugriff. Das Portal basiert auf den Datenebenen-APIs Ihrer Foundry-Ressource, die nur über private Endpunkte erreichbar sind. Entwickler und Data Scientists müssen daher über ein Sprungfeld, ein peered virtual network, eine Azure ExpressRoute-Verbindung oder eine Standort-zu-Standort-VPN-Verbindung auf das Portal zugreifen.

Alle programmgesteuerten Interaktionen mit der Agentdatenebene müssen auch diese privaten Endpunkte verwenden. Beispiele sind Aufrufe aus der Webanwendung oder aus externem Orchestrierungscode, der die Modellinferenz aufruft. Private Endpunkte werden auf Ressourcenebene und nicht auf Projektebene definiert, sodass alle Projekte innerhalb der Ressource dieselben Endpunkte und Netzwerkexposition aufweisen. Sie können den Netzwerkzugriff nicht auf Projektebene segmenten.

Um diese Konfiguration zu unterstützen, richten Sie DNS für die folgenden FQDN-API-Endpunkte für Foundry ein:

• privatelink.services.ai.azure.com
• privatelink.openai.azure.com
• privatelink.cognitiveservices.azure.com

Das folgende Diagramm veranschaulicht, wie ein KI-Entwickler über Azure Bastion eine Verbindung zu einer virtuellen Maschine (VM) herstellt. Über dieses Sprungfeld kann der Autor über einen privaten Endpunkt im selben Netzwerk auf das Projekt im Foundry-Portal zugreifen.

Ein Pfeil verweist von einem Agent-Autor auf Azure Bastion, auf die Jump-Box, auf einen privaten Endpunkt für Foundry (Portal) und dann auf das Foundry-Projekt, das den Foundry Agent Service enthält. Aus dem Foundry-Projekt zeigt ein Pfeil auf eine virtuelle Schnittstelle im Azure KI-Agent-Integrationssubnetz. Ein letzter Pfeil verweist von der virtuellen Schnittstelle auf die drei privaten Endpunkte der Abhängigkeiten des Foundry Agent Service. Diese Abhängigkeiten sind KI-Suche, Azure Cosmos DB und Speicher.

Steuern Sie den Datenverkehr im Subnetz des Foundry-Agents

Diese Architektur leitet ausgehenden (Egress-)Netzwerkverkehr der Funktion „Foundry Agent Service“ über ein delegiertes Subnetz innerhalb Ihres virtuellen Netzwerks.

Bei Prompt-Agent wird in diesem delegierten Subnetz ein Single-Tenant-Datenproxy ausgeführt, der die gesamte ausgehende Konnektivität im Namen des Agent abwickelt. Der Foundry Agent Service stellt für jedes Projekt einen Datenproxy bereit, den sich alle Prompt-Agent in diesem Projekt teilen. Der Datenproxy ist der Ausgangspunkt für die erforderlichen Dienstabhängigkeiten des Agent sowie für die meisten externen Wissensquellen oder Tool-Verbindungen, die der Agent nutzt.

Bei gehosteten Agents verlagert sich der Steuerungspunkt: Jede Sitzung eines gehosteten Agents läuft auf Computing-Ressourcen mit einer dedizierten Netzwerkschnittstelle in diesem Subnetz, sodass der ausgehende Datenverkehr des Agents direkt über diese Schnittstelle und nicht über den Datenproxy nach außen geleitet wird, auch wenn seine Toolaufrufe weiterhin über den Datenproxy laufen.

Durch die Erzwingung dieses Ausgangspfads erhalten Sie den Vollzugriff auf den ausgehenden Datenverkehr. Sie können präzise NSG-Regeln, benutzerdefiniertes Routing und DNS-Steuerung für den gesamten Datenverkehr des Agents, der den Dienst verlässt, anwenden. Dieses Design trägt dazu bei, Datenexfiltrationsversuche innerhalb der Orchestrierungslogik zu reduzieren.

Der Agentdienst verwendet die DNS-Konfiguration des virtuellen Netzwerks, um private Endpunkteinträge und erforderliche externe FQDNs aufzulösen. Mit diesem Setup wird sichergestellt, dass die Anforderungen des Agents DNS-Protokolle generieren, die Überwachung und Problembehandlung unterstützen.

Die an das Ausgangssubnetz des Agent angehängte NSG blockiert den gesamten eingehenden Datenverkehr, da kein legitimer eingehender Datenverkehr stattfinden sollte. Ausgehende NSG-Regeln ermöglichen nur den Zugriff auf private Endpunktsubnetze innerhalb des virtuellen Netzwerks und den TCP-Port 443 (Transmission Control Protocol) für internetgebundenen Datenverkehr. Die NSG lehnt jeglichen anderen Datenverkehr ab.

Um den Internetdatenverkehr weiter einzuschränken, wendet diese Architektur ein UDR auf das Subnetz an, das den gesamten HTTPS-Datenverkehr über Azure Firewall leitet. Die Firewall steuert, welche FQDNs der Agent über HTTPS-Verbindungen erreichen kann. Wenn der Agent beispielsweise eine Verbindung mit einem öffentlichen MCP-Server https://contoso.com/mcp herstellt oder eine externe API über eine OpenAPI-Tooldefinition aufruft, konfigurieren Sie Azure Firewall so, dass Datenverkehr zu diesen spezifischen FQDNs auf Port 443 aus diesem Subnetz zulässt, und stellen Sie sicher, dass der NSG diesen Datenverkehr zulässt.

Die Agentlaufzeit benötigt außerdem ausgehenden Zugriff auf ihre eigenen Plattformabhängigkeiten, nicht nur auf die FQDNs, die Ihre Agenten verwenden. Lassen Sie das AzureActiveDirectory Service-Tag zu, damit sich das Agent Compute authentifizieren kann. Ein gehosteter Agent, der externe Endpunkte erreicht, erfordert, dass Sie diese FQDNs über Ihre Firewall zulassen. Wenden Sie die TLS-Inspektion in Azure Firewall nicht auf diesen Datenverkehr an. Das zertifikat, das bei der Inspektion verwendet wird, kann die Verbindungen der Agenten unterbrechen.

Hinweis

Nicht alle Wissenstools, die mit Ihren Agents verbunden sind, gehen über dieses Subnetz. Beispielsweise ruft das Websuchtool aufapi.bing.microsoft.com, das Sie möglicherweise durch Azure Firewall weiterleiten möchten, indem Sie Port 443 von diesem Subnetz aus zulassen. Aber Agent Service ruft dieses Tool über einen internen Mechanismus auf, der das Egress-Subnetz vollständig umgeht. Testen Sie alle integrierten Wissens- und Tool-Verbindungen für Ihre Workload, um zu überprüfen, ob sie mit Ihren Richtlinien zur Kontrolle des ausgehenden Netzwerkverkehrs übereinstimmen.

Zugriff auf workloadeigene MCP-Server

Wenn Sie einen privaten MCP-Server für Ihre Workload hosten, platzieren Sie ein dediziertes MCP-Subnetz im selben virtuellen Netzwerk wie Ihr Agent-Subnetz. Lassen Sie ausgehenden TCP-Datenverkehr über die Ports 443 und 31443 vom Agent-Subnetz zum MCP-Subnetz zu, und lassen Sie den entsprechenden eingehenden Datenverkehr im MCP-Subnetz zu. Konfigurieren Sie private DNS so, dass die Standard- oder benutzerdefinierte Domäne der Container-Apps-Umgebung in ihre statische IP-Adresse innerhalb des virtuellen Netzwerks aufgelöst wird. In dieser Topologie verwenden Agentaufrufe an MCP-Server private Adressierung und verbleiben innerhalb des virtuellen Netzwerks. Implementierungsanleitungen finden Sie unter Verbinden von Agents mit Modellkontextprotokollservern.

Vorausgesetzt, Ihr MCP-Server wird in Container-Apps gehostet, muss das MCP-Subnetz NSG auch den erforderlichen Container-Apps-Netzwerkdatenverkehr zulassen. Leiten Sie internetgebundenen Datenverkehr von Ihren Workload-MCP-Servern über Azure Firewall weiter.

Segmentierung und Sicherheit des virtuellen Netzwerks

Diese Architektur segmentiert das virtuelle Netzwerk, indem jede Hauptkomponentengruppe ihrem eigenen Subnetz zugewiesen wird. Jedes Subnetz verfügt über eine dedizierte Netzwerksicherheitsgruppe (NSG), die den eingehenden und ausgehenden Datenverkehr auf das beschränkt, was die Komponente benötigt.

In der folgenden Tabelle sind die NSG- und Firewallkonfigurationen für jedes Subnetz zusammengefasst.

Verwendungs- oder Subnetzname	Eingehender Datenverkehr (NSG)	Ausgehender Datenverkehr (NSG)	UDR zur Firewall	Ausgangsregeln der Firewall
Private Endpunkte snet-privateEndpoints	Virtuelles Netzwerk	Kein Verkehr erlaubt	Yes	Kein Verkehr erlaubt
Anwendungsgateway snet-appGateway	Quell-IP-Adressen der Chat-Benutzer, z. B. aus dem öffentlichen Internet, sowie erforderliche Quellen für den Dienst	Subnetz des privaten Endpunkts und erforderliche Elemente für den Dienst	Nein	-
App-Dienst snet-appServicePlan	Kein Verkehr erlaubt	Private Endpunkte und Azure Monitor	Yes	Zu Azure Monitor
Foundry-Agentendienst snet-agentsEgress	Kein Verkehr erlaubt	Private Endpunkte, MCP-Subnetz und das Internet	Yes	Nur öffentliche FQDNs, deren Verwendung Sie Ihren Agenten gestatten
Private MCP-Server snet-mcpServers	TCP-Ports 443 und 31443 aus dem Subnetz des Foundry Agent Service und erforderlichen Quellen für den Host	Erforderliche Einträge für den Dienst	Yes	Erforderliche Plattform-FQDNs und nur öffentliche FQDNs, die für die MCP-Server erforderlich sind
Jump-Box-VMs snet-jumpBoxes	Azure Bastion Subnetz	Private Endpunkte und das Internet	Yes	Nach Bedarf der virtuellen Maschine
Build-Agents snet-buildAgents	Azure Bastion Subnetz	Private Endpunkte und das Internet	Yes	Nach Bedarf der virtuellen Maschine
Azure Bastion AzureBastionSubnet	Siehe NSG-Zugriff und Azure Bastion	Siehe NSG-Zugriff und Azure Bastion	Nein	-
Azure Firewall AzureFirewallSubnet AzureFirewallManagementSubnet	Keine NSG	Keine NSG	Nein	-

Diese Konfiguration verweigert explizit allen anderen Datenverkehr, entweder über NSG-Regeln, oder standardmäßig in Azure Firewall.

Wenn Sie die Netzwerksegmentierung und Sicherheit in dieser Architektur implementieren, befolgen Sie die folgenden Empfehlungen:

• Stellen Sie einen Azure DDoS Protection-Plan an der öffentlichen IP-Adresse des Application Gateway bereit, um volumetrische Angriffe abzumildern.

• Fügen Sie eine NSG an jedes Subnetz an, das es unterstützt. Wenden Sie die strengsten Regeln an, die möglich sind, ohne die erforderliche Funktionalität zu unterbrechen.

• Wenden Sie die erzwungene Tunnelung auf alle unterstützten Subnetze an, damit Ihre Ausgangsfirewall den gesamten ausgehenden Datenverkehr überprüfen kann. Verwenden Sie erzwungenes Tunneling auch in Subnetzen, in denen Sie keinen ausgehenden Datenverkehr erwarten. Diese Methode fügt eine detaillierte Verteidigungsmaßnahme hinzu, die vor absichtlichem oder versehentlichem Missbrauch des Subnetzes schützt.

Optimierung der Webanwendungsfirewall

Chatanwendungen erzeugen häufig Inhalte, die falsch positive Ergebnisse aus Web Application Firewall verwalteten Regeln auslösen. Benutzeraufforderungen und Modellantworten enthalten häufig Codeausschnitte, SQL-Anweisungen oder HTML-Fragmente. Chat-Inhalte können in vielen Kategorien verwalteter Regeln Fehlalarme auslösen, darunter Regeln zur Remote-Code-Ausführung, zur Einbindung lokaler Dateien und zur Bedrohungserkennung. In mehrstufigen Konversationen summiert sich der OWASP-Anomalie-Score über mehrere Nachrichten hinweg, bis die WAF die Anfrage mit einem HTTP-403-Fehler blockiert, was bedeutet, dass Blockierungen spontan auftreten können, wenn Konversationen länger werden.

Um dies zu beheben, optimieren Sie Ihre WAF-Richtlinie , indem Sie Ausschlüsse erstellen, die auf das Anforderungstextfeld beschränkt sind, das Chatnachrichten enthält. Bereichsausschlüsse auf die betroffenen Regelgruppen anstatt global Regeln zu deaktivieren. Überprüfen Sie auch, ob die Anfragekörper-Inspektionsgrenzwerte die in Ihren Chatinteraktionen typischen Nutzlastgrößen berücksichtigen.

Governance durch Politik

Verwenden Sie Azure Policy- und Netzwerkrichtlinien, um die Sicherheitsgrundwerte Ihrer Workload anzupassen, um sicherzustellen, dass alle Workloadressourcen Ihren Anforderungen entsprechen. Die Plattformautomatisierung durch Richtlinien reduziert das Risiko einer Sicherheitskonfigurationsabweichung und reduziert manuelle Überprüfungsaktivitäten.

Erwägen Sie die Implementierung der folgenden Arten von Sicherheitsrichtlinien, um Ihre Architektur zu stärken:

• Deaktivieren Sie schlüsselbasierte oder andere lokale Authentifizierungsmethoden in Diensten wie Foundry-Tools und Key Vault.

• Erfordert eine explizite Konfiguration von Netzwerkzugriffsregeln, privaten Endpunkten und NSGs.

• Erfordert Verschlüsselung, z. B. vom Kunden verwaltete Schlüssel.

• Einschränken der Ressourcenerstellung, z. B. Einschränken von Regionen oder Ressourcentypen.

Kostenoptimierung

Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Design Review-Checkliste für die Kostenoptimierung.

Diese vorkonfigurierte Schätzung im Azure Preisrechner enthält nur die Komponenten in dieser Architektur, sodass sie an Ihre Nutzung angepasst werden. Die teuersten Komponenten im Szenario sind Azure Cosmos DB, AI Search und DDoS Protection. Weitere wichtige Kosten sind die Berechnung der Chat-UI und das Anwendungsgateway. Optimieren Sie diese Ressourcen, um Kosten zu senken.

Gießerei-Agentendienst

Wenn Sie die Standardbereitstellung verwenden, müssen Sie die Abhängigkeiten des Diensts in Ihrem eigenen Azure-Abonnement einrichten und verwalten.

Die folgenden Empfehlungen erläutern, wie Die Kosten für diese erforderlichen Dienste optimiert werden:

• Der Foundry Agent Service verwaltet die Anforderungseinheitszuordnung (RU) für Azure Cosmos DB. Um langfristige Kosten zu reduzieren, kaufen Sie reservierte Kapazität für Azure Cosmos DB. Richten Sie Reservierungen nach der erwarteten Nutzungsdauer und dem erwarteten Volumen aus. Reservierte Kapazität erfordert vorab Engagement und fehlt an Flexibilität, wenn sich die Nutzungsmuster Ihrer Workload erheblich ändern.

• Wenn Ihr Chatszenario keine Dateiuploads erfordert, schließen Sie dieses Feature in Ihrer Anwendung aus. Wenden Sie in diesem Fall die folgenden Konfigurationsänderungen an:

  • Verwenden Sie eine lokal redundante Speicherebene (LRS) für das Speicherkonto.

  • Konfigurieren Sie die KI-Suche mit einem einzelnen Replikat anstelle der empfohlenen drei Replikate.

• Löschen Sie regelmäßig nicht verwendete Agents und ihre zugehörigen Unterhaltungen mithilfe der SDK- oder REST-APIs. Veraltete Agents und Konversationen beanspruchen weiterhin Speicherplatz und können die Kosten für Azure Cosmos DB, Storage und AI Search erhöhen.

• Deaktivieren Sie Features für abhängige Ressourcen, die Ihre Workload nicht benötigt, wie die folgenden Features:

  • Der semantische Rangierer in der KI-Suche

  • Die Gateway- und Multiregion-Schreibfunktionen in Azure Cosmos DB

• Um regionsübergreifende Bandbreitengebühren zu vermeiden, stellen Sie Azure Cosmos DB, Speicher und KI-Suche in derselben Azure Region wie foundry Agent Service bereit.

• Vermeiden Sie die Platzierung von workload-spezifischen Daten in denselben Azure Cosmos DB- oder AI Search-Ressourcen, die der "Foundry Agent Service" verwendet. In einigen Fällen können Sie diese Ressourcen freigeben, um nicht verwendete Kapazität in RUs oder Sucheinheiten zu reduzieren, wodurch die Kosten reduziert werden. Berücksichtigen Sie die gemeinsame Ressourcennutzung erst nach einer gründlichen Risikobewertung hinsichtlich Zuverlässigkeit, Sicherheit und Leistungsabstrichen.

Agentenwissen und -tools

Der Foundry-Agent-Dienst führt Agentlogik in einer nicht deterministischen Weise aus. Es kann verbundene Tools aufrufen, einschließlich Wissensabruftools, benutzerdefinierte API-Tools oder andere Agents für jede Anforderung, auch wenn dieses Tool für die Benutzerabfrage nicht relevant ist. Dieses Verhalten kann zu unnötigen Aufrufen externer APIs oder Datenquellen führen, die Kosten für jede Transaktion erhöhen und unvorhersehbare Nutzungsmuster einführen, die die Budgetprognose erschweren.

Um Kosten zu steuern und vorhersagbares Verhalten aufrechtzuerhalten, wenden Sie die folgenden Strategien an:

• Verbinden Sie nur die Tools, die die meisten Agentaufrufe wahrscheinlich verwenden. Vermeiden Sie das Verbinden von Tools, die selten benötigt werden oder für jeden Anruf hohe Kosten verursachen, es sei denn, sie sind unerlässlich.

• Entwerfen und verfeinern Sie die Systemaufforderung, um den Agent anzuweisen, unnötige oder redundante externe Anrufe zu minimieren. Die Systemaufforderung sollte den Agent so leiten, dass nur die relevantesten Verbindungen für jede Anforderung verwendet werden.

• Verwenden Sie Foundry-Metriken und Protokolle, um zu überwachen, welche Tools der Agent aufruft, wie häufig sie aufgerufen wird, und die zugehörigen Kosten. Überprüfen Sie diese Daten regelmäßig, um unerwartete Nutzungsmuster oder Kostenspitzen zu identifizieren und Ihre Systemaufforderung nach Bedarf anzupassen.

• Beachten Sie, dass ein unbestimmter Aufruf die Kostenprognose schwierig machen kann, insbesondere bei der Integration mit nutzungsbasierten APIs. Wenn Sie vorhersehbare Kosten benötigen, sollten Sie den Orchestrator selbst hosten, indem Sie deterministischen Code verwenden.

Azure OpenAI-Modelle

Modellbereitstellungen in Foundry nutzen den MaaS-Ansatz. Die Kosten hängen in erster Linie vom Nutzungsverhalten oder von der vorkonfigurierten Zuweisung ab.

Um die Verbrauchsmodellkosten in dieser Architektur zu steuern, verwenden Sie eine Kombination der folgenden Ansätze:

• Steuern von Clients. Kundenanfragen verursachen die meisten Kosten in einem Verbrauchermodell, daher müssen Sie das Verhalten des Agents steuern.

  Um die unnötige Nutzung zu reduzieren, führen Sie die folgenden Aktionen aus:

  • Genehmigen Sie alle Modellnutzer. Stellen Sie Modelle nicht auf eine Weise zur Verfügung, die uneingeschränkten Zugriff zulässt.

  • Erzwingen Sie tokenbegrenzende Beschränkungen für jede Antwort. Wenn Ihre Anwendung eine Antwort erstellt, legen Sie fest max_output_tokens , dass die vom Modell generierten Token begrenzt werden. Verwenden Sie die Einstellung truncation, um zu steuern, wie viel Konversationsverlauf bei jedem Zug in das Kontextfenster des Modells gelangt.

  • Optimieren Sie die Eingabelänge und die Antwortlänge des Prompts. Längere Aufforderungen verbrauchen mehr Token, was die Kosten erhöht. Eingaben, die nicht genügend Kontext bieten, verringern die Effektivität des Modells. Erstellen Sie präzise Eingabeaufforderungen, die genügend Kontext bereitstellen, damit das Modell eine nützliche Antwort generieren kann. Stellen Sie sicher, dass Sie den Grenzwert der Antwortlänge optimieren.

    Diese Steuerungsebene ist nur in selbst gehosteter Orchestrierung verfügbar. Der Foundry Agent Service bietet nicht genügend Konfiguration, um diese Funktionalität zu unterstützen.

• Wählen Sie das richtige Modell für den Agent aus. Wählen Sie das am wenigsten teure Modell aus, das den Anforderungen Ihres Agenten entspricht. Vermeiden Sie höhere Kostenmodelle, es sei denn, sie sind unerlässlich. Die Referenzimplementierung verwendet beispielsweise ein GPT-5-Serienmodell, das die Anforderungen des Szenarios erfüllt.

• Überwachen und Verwalten der Nutzung. Verwenden Sie Microsoft Cost Management und Modellverwendungsmetriken, um die Tokennutzung nachzuverfolgen, Budgets festzulegen und Warnungen für Anomalien zu erstellen. Überprüfen Sie die Verwendungsmuster regelmäßig, und passen Sie Kontingente oder den Clientzugriff nach Bedarf an.

• Verwenden Sie den richtigen Bereitstellungstyp. Verwenden Sie pay-as-you-go Preise für unvorhersehbare Workloads, und wechseln Sie zum bereitgestellten Durchsatz, wenn die Nutzung stabil und vorhersehbar ist. Kombinieren Sie beide Optionen, wenn Sie einen zuverlässigen Basisplan einrichten.

• Schränken Sie die Nutzung des Playgrounds ein. Um ungeplante Produktionskosten zu vermeiden, beschränken Sie die Verwendung des Foundry-Playgrounds nur auf Vorproduktionsumgebungen.

• Planen Sie die Feinabstimmung und die Bildgenerierung sorgfältig. Diese Features weisen unterschiedliche Abrechnungsmodelle auf. Sie werden pro Stunde oder pro Batch abgerechnet. Planen Sie die Nutzung, um die Abrechnungsintervalle auszurichten und Abfälle zu vermeiden.

Netzwerksicherheitsressourcen

Diese Architektur erfordert Azure Firewall als Ausgangskontrollpunkt. Um Die Kosten zu optimieren, verwenden Sie die Standardebene von Azure Firewall, es sei denn, die restlichen Workloadkomponenten erfordern erweiterte Features. Höhere Ebenen fügen Kosten hinzu, verwenden Sie sie also nur, wenn Sie deren Funktionen benötigen. Bevor Sie die Stufe "Einfach" auswählen, vergewissern Sie sich, dass ihre Einschränkungen ihren Workload entsprechen. Der Basic-Tarif begrenzt den Durchsatz und verfügt über eingeschränkte Threat-Intelligence-Funktionen.

Wenn Ihre Organisation eine Azure-Zielzone verwendet, sollten Sie die Verwendung von gemeinsamen Firewall- und verteilten DDoS-Ressourcen (Dienstverweigerung) in Betracht ziehen, um die Kosten zu verzögern oder zu reduzieren. Workloads mit ähnlichen Sicherheits- und Leistungsanforderungen können von gemeinsam genutzten Ressourcen profitieren. Stellen Sie sicher, dass freigegebene Ressourcen keine Sicherheits- oder Betriebsrisiken darstellen. Ein Beispiel, das gemeinsam genutzte Ressourcen verwendet, finden Sie in der Zielzonenversion dieser Architektur.

Microsoft Defender for Cloud

Verwenden Sie die folgenden Cloud Workload Protection-Pläne, um die zugehörigen Ressourcen in dieser Architektur abzudecken.

Plan	Nutzen
Microsoft Defender für Server	Erkennt Schwachstellen und überwacht die Dateiintegrität, um zu verhindern, dass Jump-Boxen mit hohen Berechtigungen und Build-Agents zu Bedrohungsvektoren werden.
Microsoft Defender für App Service	Überwacht Protokolle, Hostcomputer und Verwaltungsschnittstellen für Ihre Chat-UI-Komponenten.
Microsoft Defender für Azure Cosmos DB	Überwacht Datenbankinteraktionen auf Anzeichen von potenziellem Missbrauch oder unbefugtem Zugriff auf Chatdaten und Agentdefinitionen.
Microsoft Defender für KI-Dienste	Warnungen zu Jailbreaking-Versuchen oder Datenlecks basierend auf Agentanforderungen und -antworten. Wenn Ihre Organisation Microsoft Purview verwendet, bietet dieser Plan auch die Integration mit Microsoft Purview Datensicherheitstatus-Management für KI (DSPM for AI).

Wenn Ihre Organisation eine SIEM-Lösung (Security Information and Event Management) oder Microsoft Purview verwendet, stellen Sie sicher, dass alle Kundendaten, die in diesen Datenspeichern repliziert wurden, z. B. Eingabeaufforderungen und Antworten, in einer Region gespeichert sind, die die Datenhoheitsanforderungen Ihrer Workload erfüllt.

Operative Exzellenz

„Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie in der Checkliste zur Designüberprüfung für operationale Exzellenz.

Der folgende Leitfaden zur betrieblichen Exzellenz enthält nicht die Front-End-Anwendungselemente, die mit der grundlegenden hoch verfügbaren, zonenredundanten Webanwendungsarchitektur identisch bleiben.

Wenn Sie Ihre Experimentier-, Test- und Produktionsumgebungen planen, richten Sie unterschiedliche und isolierte Foundry-Ressourcen ein, einschließlich Abhängigkeiten.

Agents-Rechenleistung

Microsoft verwaltet die serverlose Rechenplattform für die Foundry Agent Service REST APIs sowie die Logik zur Orchestrierungsimplementierung. Ein gehosteter Agent führt Ihren eigenen Orchestrierungscode auf diesen von Foundry verwalteten Rechenressourcen aus. Eine selbst gehostete Orchestrierung geht noch einen Schritt weiter bietet mehr Kontrolle über Laufzeiteigenschaften und Kapazität, allerdings müssen Sie den Day-2-Betrieb für diese Plattform direkt verwalten. Bewerten Sie die Einschränkungen und Verantwortlichkeiten Ihres Ansatzes, um zu verstehen, welche Day-2-Vorgänge Sie implementieren müssen, um Ihre Orchestrierungsschicht zu unterstützen.

Die Verantwortung für die Zustandsverwaltung folgt Ihrer Protokollkonfiguration und nicht Ihrem Computeansatz. Sowohl Prompt-Agents als auch gehostete Agents unterstützen sowohl dienstverwaltete Konversationen, bei denen die Plattform den Chatverlauf speichert, als auch clientverwaltete Konversationen, bei denen Ihr Code den Status weiterführt. Die selbstgehostete Orchestrierung verwaltet immer ihren eigenen Zustand. In jedem Fall befinden sich die dauerhaften Datenspeicher für Chatverlauf und Agentkonfiguration innerhalb Ihres Abonnements, damit liegen Dauerhaftigkeit, Sicherung und Wiederherstellung in Ihrer Verantwortung.

Agent-Interaktions-SDK

Verwenden Sie Microsoft Agent Framework als Laufzeit-SDK in Ihrer Clientanwendung, um Nachrichten an Agents zu senden, Unterhaltungen zu verwalten und Antworten zu verarbeiten. Agent Framework unterstützt C# und Python. Wenn Ihre Clientanwendung JavaScript oder Java erfordert, verwenden Sie das Foundry SDK direkt für diese Laufzeitinteraktionen.

Verwenden Sie das Foundry SDK für Plattformverwaltungsvorgänge unabhängig von Ihrer Client-SDK-Wahl. Die Erstellung und Versionsverwaltung zentral verwalteter Agentdefinitionen gehören zu CI/CD-Pipelines und IaC-Prozessen, nicht im Clientanwendungscode.

Weitere Informationen zum Integrieren von Agent Framework in Foundry finden Sie unter Microsoft Agent Framework Foundry-Anbieter.

Überwachung

Ähnlich wie bei der grundlegenden Architektur sendet diese Architektur Diagnosedaten von allen Diensten an den Log Analytics Arbeitsbereich Ihrer Workload. Die Konfiguration erfasst alle verfügbaren Protokollkategorien für jeden Dienst, mit Ausnahme von App Service. In der Produktion benötigen Sie möglicherweise nicht jede Protokollkategorie. Die Chat-UI-Anwendung im App Service benötigt beispielsweise nur AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs, AppServicePlatformLogs und AppServiceAuthenticationLogs. Optimieren Sie Protokolldatenströme so, dass sie Ihren betrieblichen Anforderungen entsprechen.

Bewerten Sie benutzerdefinierte Warnungen, z. B. aus den Azure Monitor Basiswarnungen, für die Ressourcen in dieser Architektur. Berücksichtigen Sie die folgenden Warnungen:

• KI-Suchwarnungen
• KI-Dienste-Warnungen
• Web-Apps Warnungen

Überwachen Sie die Nutzung von Tokens in Bezug auf Ihre Modellbereitstellungen. In dieser Architektur verfolgt Foundry die Tokennutzung durch die Integration in Application Insights.

Ihre Jumpserver und Build-Agent-VMs befinden sich an Orten mit hohen Berechtigungen, die diesen VMs direkten Netzwerkzugriff auf die Datenebene aller Komponenten in Ihrer Architektur bieten. Stellen Sie sicher, dass diese virtuellen Computer genügend Protokolle ausgeben, um anzuzeigen, wann Benutzer darauf zugreifen, wer dies tut und was sie darauf machen.

Agent-Versionsverwaltung und Lebenszyklus

Behandeln Sie jeden Agent als eigenständige bereitstellungsfähige Einheit innerhalb Ihrer Chat-Workload, es sei denn, Sie entwerfen Ihre Anwendung speziell so, dass Agents zur Laufzeit dynamisch erstellt und gelöscht werden. Diese Agents verfügen über Lebenszyklusverwaltungsanforderungen wie andere Microservices in Ihrer Workload.

Um Dienstunterbrechungen zu verhindern, stellen Sie die sichere und kontrollierte Agentbereitstellung sicher, indem Sie die folgenden Ansätze implementieren:

• Definieren Sie Agenten als Code. Speichern Sie immer Agentdefinitionen, Verbindungen, Systemaufforderungen und Konfigurationsparameter in der Quellcodeverwaltung. Diese Praxis sorgt für Rückverfolgbarkeit und Reproduzierbarkeit. Vermeiden Sie unprotokollierte Änderungen im Foundry-Portal.

• Automatisieren Sie die Agentbereitstellung. Nutzen Sie die Continuous-Integration- und Continuous-Deployment-Pipelines (CI/CD) Ihrer Workload. Verwenden Sie die Foundry-SDKs zum Erstellen, Testen und Bereitstellen von Agentänderungen von Ihren mit dem Netzwerk verbundenen Build-Agents.

  Bevorzugen Sie Agent-Pipelines, die Sie unabhängig für kleine, inkrementelle Änderungen bereitstellen können. Stellen Sie jedoch sicher, dass die Pipelines genügend Flexibilität bieten, um sie zusammen mit Ihrem Anwendungscode bereitzustellen, wenn Sie koordinierte Updates benötigen. Um diese Methode zu unterstützen, koppeln Sie Ihren Chat-UI-Code und Ihre Chat-Agents lose, sodass Änderungen an einer Komponente keine gleichzeitigen Änderungen an der anderen erfordern.

• Testen Sie vor der Produktion. Überprüfen Des Agentverhaltens, Aufforderungen und Verbindungen in Vorproduktionsumgebungen. Verwenden Sie eine Kombination aus automatisierten und manuellen Tests, um Regressionen, Sicherheitsprobleme und unbeabsichtigte Änderungen des Agentverhaltens abzufangen.

  Agents, die im Foundry Agent Service definiert sind, verhalten sich nicht deterministisch, sodass Sie bestimmen müssen, wie Sie Ihr gewünschtes Qualitätsniveau messen und verwalten können. Erstellen und ausführen Sie eine Testsuite, die nach idealen Antworten auf realistische Benutzerfragen und Szenarien sucht.

• Versionsverwalten und Nachverfolgen von Agents. Weisen Sie jedem Agent eindeutige Versionsbezeichner zu. Verwalten Sie Aufzeichnungen darüber, welche Agentenversionen aktiv sind, sowie deren Abhängigkeiten wie Modelle, Datenquellen und Tools. Stellen Sie neue Agentversionen zusammen mit vorhandenen Versionen bereit, um progressives Rollout, Rollback und kontrollierte Migration von Benutzern oder Sitzungen zu unterstützen.

  Foundry unterstützt nativ unveränderliche Agentversionen. Jedes Mal, wenn Sie Änderungen an einer Agentdefinition vornehmen, erstellt Foundry eine neue Versionsmomentaufnahme, die die vorherige Konfiguration bewahrt. Verwenden Sie diesen integrierten Versionsverlauf für Überwachungspfade und Rollbackziele.

  Für gehostete Agents bedeutet der Versand eines Updates mehr als das Erstellen einer Konfigurationsmomentaufnahme. Sie erstellen und pushen zuerst ein Containerimage, und die Version des Foundry-Agents verweist darauf. Ein Rollback setzt den Versionsselektor des Agent-Endpunkts lediglich wieder auf eine frühere Version, ohne Neu-Build und ohne neues Image. Die weiter oben in diesem Abschnitt beschriebenen Vorgehensweisen für Quellcodeverwaltung, Tests und CI/CD gelten sowohl für Prompt- als auch für gehostete Agenten. Da Sie den Code eines gehosteten Agenten schreiben, kommt ein zusätzlicher Schritt hinzu, den Prompt-Agents nicht haben: eine lokale Build-und-Debug-Schleife für diesen ausführbaren Code, bevor er in diese gemeinsamen Pipelines gelangt.

  Nicht jede Laufzeitvariation erfordert eine neue Version. Strukturierte Eingaben parametrisieren Agentdefinitionen. Der Client stellt tatsächliche Werte zur Anforderungszeit zur Verfügung, sodass eine einzelne Agentversion benutzerspezifische oder kontextspezifische Konfigurationen ohne erneute Bereitstellung bereitstellen kann.

  Hinweis

  Beschränken Sie strukturierte Eingaben auf Anweisungstext, z. B. das Einfügen eines Benutzernamens in die Systemaufforderung. Vermeiden Sie das Verwenden von Templates für Tool-Endpunkteigenschaften wie MCP-Server-URLs. Vorlagengestützte Tool-Endpunkte ermöglichen es dem aufrufenden Client, den Agent zur Laufzeit auf beliebige externe Dienste umzuleiten, was die statische Governance-Struktur dieser Architektur untergräbt. Ihre Firewall-FQDN-Zulassungsliste blockiert weiterhin nicht genehmigte Ziele, aber die Agentdefinition selbst dokumentiert nicht mehr, welche Endpunkte der Agent erreichen soll.

• Fixieren und Kontrollieren von Modellversionen. Das Verhalten eines Agents hängt von der aufgerufenen Modellversion ab. Behandeln Sie daher die Modellbereitstellung als Teil Ihres Änderungskontrollesprozesses. Legen Sie die Option für Versionsupgrades der Bereitstellung auf „Nicht automatisch aktualisieren“ fest. Dieses Setup verhindert, dass ein automatisches Modellupdate die Agentantworten ändert, bevor Sie die neue Version für Ihre Testsuite überprüfen.

• Erzwingen der Zugriffssteuerung und Datenisolation auf Benutzerebene. In dieser Architektur ist die Chat-UI-Anwendungsschicht die Zugriffsgrenze zwischen Endbenutzern und Ihren Agents. Die Foundry-Projekt-API befindet sich hinter privaten Endpunkten und kann nicht direkt für Verbraucher zugänglich sein. Ihr Anwendungscode muss Endbenutzer über Microsoft Entra ID authentifizieren und jede Unterhaltung und die zugehörigen Daten auf die authentifizierte Identität beschränken.

  Wenn Sie APIs auf Projektebene verwenden, kann jeder Prinzipal, der über die Rolle "Foundry User" im Foundry-Projekt verfügt, mit allen Agents in diesem Projekt interagieren. Die Authentifizierungs- und Autorisierungsebene Ihrer Anwendung, nicht das Projekt RBAC von Foundry, erzwingt, welche Benutzer auf welche Agents und Unterhaltungen zugreifen können. Entwerfen Sie Ihr Sitzungsmanagement so, dass ein benutzerübergreifender Datenzugriff verhindert wird, und wenden Sie die Daten-Governance- und Aufbewahrungsrichtlinien Ihrer Workload auf die von Ihrer Anwendung gespeicherten Konversationsdaten an.

• Planen Sie eine schrittweise Einführung und ein Failback. Foundry bietet keine integrierte Unterstützung für blue-green- oder Canary-Bereitstellungen von Agents. Wenn Sie diese Bereitstellungsmuster oder die kontrollierte Migration von Benutzern zwischen Agentversionen benötigen, implementieren Sie eine Routingebene, z. B. ein API-Gateway oder einen benutzerdefinierten Router, vor der Agent-API. Mit dieser Routingebene können Sie den Datenverkehr inkrementell zwischen Agentversionen verschieben, den Effekt überwachen und bei Bedarf einen vollständigen Switchover ausführen.

• Koordination der Agentenentfernung. Wenn Sie Agents entfernen, koordinieren Sie den Prozess mit den Anforderungen für die Zustandsverwaltung und die Benutzerfreundlichkeit Ihrer Anwendung. Behandeln Sie aktive Chatsitzungen entsprechend. Abhängig von den funktionalen Anforderungen Ihrer Workload können Sie Sitzungen migrieren, Benutzer an die alte Agentversion anheften oder benutzer zum Starten neuer Sitzungen auffordern.

Leistungseffizienz

Die Leistungseffizienz bezieht sich auf die Fähigkeit Ihrer Arbeitslast, die Anforderungen der Benutzer effizient zu erfüllen. Weitere Informationen finden Sie in der Checkliste zur Entwurfsüberprüfung für die Leistungseffizienz.

In diesem Abschnitt werden die Leistungseffizienz für die KI-Suche, modellbasierte Bereitstellungen, das MCP-Server-Subnetz und das Foundry behandelt.

Leistungseffizienz in der KI-Suche

Im Foundry Agent Service steuern Sie nicht die spezifischen Abfragen, die an Ihre Indizes gesendet werden, da Agents codelos sind. Um die Leistung zu optimieren, konzentrieren Sie sich auf das, was Sie im Index steuern können. Beobachten Sie, wie Ihr Agent den Index in der Regel abfragt, und wenden Sie Anleitungen an, um die Leistung in der KI-Suche zu analysieren und zu optimieren.

Wenn die Indexserveroptimierung allein nicht alle Engpässe behebt, sollten Sie die folgenden Optionen in Betracht ziehen:

• Ersetzen Sie die direkte Verbindung mit der KI-Suche durch eine Verbindung mit einer API, die Sie besitzen. Diese API kann Code implementieren, der für die Abrufmuster Ihres Agents optimiert ist.

• Gestalten Sie die Orchestrierungsebene neu, um Ihren eigenen Orchestrierungscode auszuführen – entweder als gehosteten Agent auf von Foundry verwalteter Recheninfrastruktur oder als selbstgehostete Orchestrierung, die Sie selbst betreiben –, sodass Sie Abfragen im Code Ihres eigenen Orchestrators definieren und optimieren können.

Leistungseffizienz bei Modellbereitstellungen

• Ermitteln Sie, ob Ihre Anwendung einen bereitgestellten Durchsatz benötigt oder das freigegebene Modell (Verbrauchsmodell) verwenden kann. Der bereitgestellte Durchsatz bietet reservierte Kapazität und vorhersehbare Latenz, die Produktionsworkloads unterstützt, die strenge Ziele auf Dienstebene (SLOs) aufweisen. Das Verbrauchsmodell bietet einen Best-Effort-Dienst und es kann zu „Noisy-Neighbor“-Effekten kommen.

• Überwachen Sie die bereitstellungsverwaltete Nutzung , um eine Über- oder Unterbereitstellung zu vermeiden.

• Wählen Sie ein Konversationsmodell aus, das Ihre Anforderungen an die Inferenzlatenz erfüllt.

• Stellen Sie Modelle in derselben Datenregion wie Ihre Agents bereit, um die Netzwerklatenz zu minimieren.

Azure KI-Agent-Leistung

Die Azure KI-Agents werden auf einem serverlosen Berechnungs-Back-End ausgeführt, das keine benutzerdefinierte Leistungsoptimierung unterstützt. Sie können die Leistung jedoch über das Agentdesign verbessern:

• Minimieren Sie die Anzahl der Tools, die mit Ihrem Chat-Agent verbunden sind. Jede zusätzliche Verbindung erhöht möglicherweise die Gesamtlaufzeit für einen Agentanruf, da der Agent möglicherweise alle konfigurierten Tools für jede Anforderung aufruft.

• Verwenden Sie Azure Monitor und Application Insights, um Aufrufzeiten, Toollatenz und Fehlerraten des Agents nachzuverfolgen. Überprüfen Sie diese Metriken regelmäßig, um langsame Toolverbindungen zu identifizieren.

• Designsystem-Anweisungen leiten den Agenten an, Verknüpfungen effizient zu nutzen. Weisen Sie z. B. den Agent an, Datengrundungstools nur bei Bedarf abzufragen oder redundante Toolaufrufe zu vermeiden.

• Überwachen Sie auf Dienstgrenzwerte oder Kontingente, die sich auf die Leistung während der Spitzenauslastung auswirken können. Achten Sie auf Drosselungsindikatoren wie HTTP-429- oder 503-Antworten, auch wenn die serverlose Rechenleistung automatisch skaliert wird.

MCP-Server-Subnetzkapazität

Diese Architektur reserviert ein dediziertes /24-Subnetz, das an Microsoft.App/environments delegiert ist, damit Sie später eine interne Azure Container Apps-Umgebung für Workloadprofile bereitstellen können, die MCP-Server hostet, um Ihre Agenten zu erweitern.

Foundry-Agent-Subnetzkapazität

Das Foundry-Agent-Subnetz muss ausreichend Platz für die Agent-Infrastruktur haben. Es wird an Microsoft.App/environments delegiert und sollte einen /24-CIDR-Bereich verwenden. Diese Größe berücksichtigt den Datenproxy und die Adressen, die von der Subnetzdelegierung reserviert werden. Foundry stellt für jedes Projekt einen Single-Tenant-Datenproxy bereit, und jeder Proxy skaliert mit dem Datenverkehr mit, sodass mehr Projekte und mehr Last mehr Subnetz-IPs verbrauchen. Wenn Sie gehostete Agents einführen, führt die Plattform jede gleichzeitig aktive Agent-Sitzung in einer eigenen Berechnung aus, die eine Subnetz-IP nutzt. Eine Agentsitzung ist die isolierte Sandbox, die von der Plattform zum Verarbeiten der Anforderungen eines Benutzers bereitgestellt wird. Die Plattform richtet bei der ersten Anfrage eine Agentensitzung ein. Da diese Architektur dienstverwaltete Konversationen verwendet, bindet die Plattform diese Agent-Sitzung an die Konversation und verwendet sie bei späteren Gesprächswechseln erneut. Eine separate gleichzeitige Konversation beansprucht eine separate Agentsitzung mit eigenen Rechenressourcen. Eine Agentsitzung verwendet eine Subnetz-IP nur, während die Berechnung ausgeführt wird. Nehmen Sie also die Größe des Subnetzes für die Spitzenanzahl der Agentsitzungen an, die gleichzeitig ausgeführt werden, nicht für die Anzahl der Agents, die Sie bereitstellen.

Durch die Bereitstellung einer neuen Revision des gehosteten Agents werden vorübergehend zusätzliche IPs verwendet, da die alten und neuen Überarbeitungen während des Rollouts parallel ausgeführt werden. Informationen zur Subnetzgröße und IP-Zuordnung finden Sie unter Deep dive into Foundry Agent Service Networking. Eine Foundry-Ressource kann ihr Agent-Subnetz nicht mit einer anderen Foundry-Ressource teilen, obwohl für Ihre Workload mehrere Foundry-Ressourcen erforderlich sind, können sie dasselbe virtuelle Netzwerk gemeinsam nutzen.

Bereitstellen dieses Szenarios

Um diese Referenzimplementierung bereitzustellen und auszuführen, befolgen Sie die Bereitstellungsanleitung in der Foundry Agent Service Chat-Baseline-Referenzimplementierung.

Die Chat-UI-Anwendung in dieser Referenzimplementierung ist einfach und veranschaulicht die Kommunikation mit Agentendpunkten. Beispiele für erweiterte Chat-Benutzeroberflächen finden Sie im Web-App-Repository des Foundry-Agents.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

• Rob Bagby | Leitender Inhaltsentwickler - Azure Muster und Praktiken
• Chad Kittel | Principal Software Engineer - Azure Patterns & Practices

Andere Mitwirkende:

• Raouf Aliouat | Senior Software Engineer
• Freddy Ayala | Cloud-Lösungsarchitekt
• Prabal Deb | Hauptsoftwareingenieur
• Ritesh Modi | Hauptsoftwareingenieur
• Ryan Pfalz | Senior Technical Program Manager

Um nicht öffentliche LinkedIn-Profile zu sehen, melden Sie sich bei LinkedIn an.

Nächster Schritt

• Grundlagen der Foundry-Chat-Architektur in einem Azure-Landebereich

Verwandte Ressourcen

• AI-Workloads auf Azure
• Azure OpenAI-Modelle
• Leitplanken und Steuerungen
• KI-Agenten-Orchestrierungsmuster