agents microsoft-foundry agent-framework enterprise observability security

Der Einsatz von Agenten in der Produktion mit dem Foundry Agent Service und dem Agent Framework

Wie ein Sales-Prep-Agent von einem lokalen Code zu einer gehosteten, identitätsbasierten, sandboxierten und überwachten Implementierung wechselt, die in Microsoft 365 veröffentlicht wird und auf Geschäftsdaten beruht.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 202611 Min. Lesezeit2634 Wörter

Quellen: Foundry Agent Service + Microsoft Agent Framework Explained

Von Prototyp bis Produktionsagent

Dass ein KI-Agent auf einem Laptop funktioniert, ist der einfachere Teil. Die schwierigere Aufgabe in großen Unternehmen besteht darin, ihn sicher für Tausende von Nutzern zu betreiben: ihm eine Identität zu geben, einzuschränken, was er lesen darf, seine Aktionen aufzuzeichnen und ihn den Nutzern in den bereits geöffneten Tools zur Verfügung zu stellen. Der Microsoft Foundry Agent Service zusammen mit dem Open-Source-Tool Microsoft Agent Framework zielt genau auf diese Lücke ab. Der erste kümmert sich um die Hostung mit unternehmensweiten Kontrollen, Messbarkeit und Auffindbarkeit und ermöglicht es, Agenten mit den gewünschten Tools zu erstellen. Der zweite hilft dabei, sowohl einzelne Agenten als auch mehrere Agenten in Kombination mithilfe von Orchestrierungsfunktionen zu entwickeln.

Die Idee ist, dass Agenten direkt aus einer lokalen Umgebung eingesetzt werden können, unter einer sicheren Identität mit eingeschränkten Berechtigungen laufen und Interaktion für Interaktion überwacht werden können, sodass sie debuggt, verbessert und skaliert werden können, ohne dass jemand die Kontrolle verliert. Agenten können außerdem in bekannte Tools veröffentlicht werden, wobei jede Aktion nachvollziehbar, steuerbar und isoliert ist.

Der andere Aspekt betrifft die Grundlagen. Agenten werden nützlich, wenn sie mit echten Geschäftsdaten arbeiten: E-Mails, Meetings und Betriebssysteme liefern personalisierte Erkenntnisse, Dokumente und Präsentationen. Teams nutzen vertraute Frameworks, um anschließend die Leistung, Kosten und Qualität aller ihrer Agenten zu verwalten, je mehr es davon gibt.

Was die Enterprise-Einsatzstellung schwierig macht

Das Erstellen eines Agents ist viel einfacher geworden. Seine sichere und zuverlässige Einrichtung in einer ganzen Organisation hingegen nicht. Viele der derzeit entwickelten Agents sind längst über die kleine Pilotphase hinaus. Einige dienen als Chat-Funktionen für Tausende von Mitarbeitern, während andere im Hintergrund unauffällig laufen und gelegentlich mit kritischen Systemen verbunden werden.

Alle benötigen dieselben Grundlagen: Identitäts- und Zugriffskontrolle, private Verbindungen sowie Telemetrie- und Tracking-Funktionen sowohl auf Ebene eines einzelnen Agents als auch der gesamten Flotte. Diese Komponenten manuell miteinander zu verbinden, ist kompliziert – genau dieses Problem sollen die Foundry-Dienste beseitigen, damit Agents sicher, skalierbar und mit vollständiger Sichtbarkeit laufen können. Es hilft, sich die Alternative vorzustellen: Ein Team, das seinen eigenen Agent betreibt, muss entscheiden, wie der Agent sich authentifiziert, welches Service-Konto er verwendet, wohin die Protokolle gespeichert werden, wie die Daten eines Benutzers vor denen eines anderen geschützt werden und wer benachrichtigt wird, wenn der Agent Fehler macht. Jede dieser Entscheidungen stellt ein kleines Projekt dar, und eine Sicherheitsprüfung wird vor dem ersten Kontakt des Agents mit einem Kalender oder einer Kundenakte nach allen Aspekten fragen.

Das Beispiel: Ein Agent zur Vorbereitung von Verkaufstreffen

Das laufende Beispiel ist ein Agent, der einem Vertriebsteam dabei hilft, sich auf Kundentermine vorzubereiten. Sein Code ist bereits mit dem Microsoft Agent Framework in Python geschrieben, obwohl jedes andere Framework und jede andere Sprache verwendet werden könnte. Er definiert eine beträchtliche Anzahl an Werkzeugen, einige Middleware-Logik sowie einen Workflow, und derzeit läuft alles lokal.

Die offene Frage ist, wie man ihn in eine sichere, skalierbare, konformen und schützende Lösung für das gesamte Unternehmen umwandeln kann. In Visual Studio Code bietet die Erweiterung AI Toolkit eine Aktion zum Bereitstellen auf gehosteten Agenten. Sie packt den Agent wie beschrieben zusammen und deployt ihn innerhalb von Foundry als gehosteten Agenten. Derselbe Agent, der zuvor lokal lief, erscheint nun im Foundry-Portal, und das Playground kann ihn aufrufen, um zu zeigen, was die Hostingschicht hinzufügt.

Die Frage, welche wichtigen Meetings diese Woche anstehen, zeigt die neueren Agent-Muster. Der Agent läuft in einer sicheren Sandbox, einer MicroVM, in der er logisch denkt, den Kalender überprüft und Code schreiben sowie ausführen kann – genauso wie Coding-Agents wie GitHub Copilot CLI oder Claude Code.

Identität, Isolation und Schutzmechanismen

Sofort nach dem Bereitstellen des Agents geschehen mehrere Dinge, und das nächste Bild zeigt, wo die Einrichtung der Identität und Berechtigungen im Portal sichtbar wird.

Der Agent erhält eine eigene, eindeutige ID von Microsoft Entra. Jede von ihm ausgeführte Aktion, wie zum Beispiel das Lesen eines Kalenders, kann auf ihn zurückverfolgt werden. Mit dieser Identität kann er unter seinen eigenen, eingeschränkten Berechtigungen autonom auf Ressourcen zugreifen oder im Auftrag einer Person unter Verwendung der Berechtigungen dieses Benutzers handeln.
Jeder Benutzer, der eine Agentensitzung startet, erhält eine eigene, sichere MicroVM. Wenn zwei Verkäufer gleichzeitig Fragen stellen, verfügt jeder über eine eigene Agenteninstanz, sodass die Informationen jeder Sitzung in ihrem eigenen Bereich gelesen, geschrieben und gespeichert werden.
Bei jeder Interaktion überprüft der Service die von der Organisation definierten Richtlinien und Schutzmaßnahmen, die Dinge wie Inhaltsfilterung, Schutz vor Prompt-Injection sowie den Einsatz urheberrechtlich geschützten Materials umfassen. Die präzise Kontrolle darüber, was der Agent tun und zugreifen darf, ergibt sich aus der automatisch bei der Bereitstellung vorgenommenen Konfiguration.

Zurück auf dem Spielplatz gibt der Agent seine Antwort zurück. Auf der Grundlage der gesammelten und durchgesehenen Signale erweist sich ein Kundenkonto namens Zava DIY als höchste Priorität. In diesem Fall arbeitete der Agent im Auftrag des Benutzers, unter Verwendung der Identität und Berechtigungen dieser Person, um den Kalender zu prüfen und die Konten herauszufinden, die Aufmerksamkeit verdienen. Da ein Lesen des Posteingangs, des Kalenders sowie von Datenspeichern und Dateispeichern erforderlich ist, sind geeignete Zugriffskontrollen genau das, was für ein konformes System notwendig ist.

Überwachung und Veröffentlichung

Zwei weitere Unternehmensanforderungen stammen direkt von Foundry. Die erste ist die Überwachbarkeit. Das Portal bietet Überwachungsfunktionen sowie Protokolle, sodass Sie jede Konversation verfolgen, sehen können, wie der Agent jede Frage beantwortet, und den allgemeinen Zustand des Agents überprüfen können.

Der zweite Aspekt ist die Auffindbarkeit. Sobald ein Agent läuft, muss er trotzdem zu den Personen gelangen, die ihn benötigen, und niemand freut sich darauf, eine neue App zu entwickeln und zu hoffen, dass jeder den Link findet und sie sich speichert. Wenn ein Unternehmen bereits in Microsoft 365 und Teams tätig ist, kann eine Veröffentlichungstaste jeden in Foundry bereitgestellten Agenten in diesen Diensten registrieren. Die Nutzer finden ihn anschließend und nutzen ihn dort, wo sie bereits arbeiten – am Desktop oder auf dem Handy außerhalb des Büros. In Microsoft 365 erscheint der Agent im Copilot Chat, und er ist auch in Teams verfügbar.

Die Intelligenzschicht hinter fundierten Antworten

Foundry integriert sich außerdem in Microsofts vereinigte Intelligenzschicht für KI, die sicherstellt, dass die Agenten im richtigen Wissens- und Geschäftskontext arbeiten, sodass ihre Ausgaben relevant sind. Das geht weit über das hinaus, was ein einzelner MCP-Server bietet. Dafür sind drei Komponenten notwendig.

Work IQ liefert Kontext darüber, wie eine Person arbeitet: Verbindungen zu E-Mails, Kalendern, früheren Meetings, Teams-Chats, Dateien und mehr.
Fabric IQ fügt Kontext zu verbundenen Geschäftsprozessen hinzu, wie z. B. Verkaufsdaten, Kundenakten oder Logistik.
Foundry IQ kombiniert mehrere Wissensquellen für einen Agenten – von strukturierten Daten und Datenbanken über unstrukturierte Materialien in Cloud-Speichern bis hin zu Bildern, die durch agentbasierte Prozesse abgerufen werden können.

Beim ersten Ausführungsvorgang war nur die Kalenderabfrage sichtbar, das ist der Teil von Work IQ. Der fortgeschritteneere Agent nutzt alle drei Komponenten.

Eine vollständigere Ausführung: Vorbereitung auf das Zava-Meeting

Derselbe Agent hat über die ihm zur Verfügung gestellten Tools und Fähigkeiten Zugang zu allen drei IQs. Im „Playground“ weist eine Notiz aus den früheren Ausgaben des Agents auf ein wichtiges Treffen mit Zava hin, weshalb die nächste Anfrage darum bittet, bei der Vorbereitung dieses Treffens zu helfen.

Innerhalb des Sandboxes führt er das gerade Beschriebene aus. Er konsultiert Work IQ bezüglich der Korrespondenz, um E-Mails sowie Teams-Gespräche über Zava abzurufen. Außerdem holt er sich aus Fabric IQ Nutzungsdaten, Kaufmuster sowie Vertragsdetails. Zudem durchsucht er Verkaufshilfen und Marketingmaterialien über Foundry IQ, um das für diesen Kunden Relevanteste zu finden.

Der Agent verfügt außerdem über einige Fähigkeiten, die auf dem beliebten Agent-Fähigkeitsmuster basieren. Eine davon erstellt eine PowerPoint-Präsentation, eine andere erzeugt Informationsdokumente in Word. Er gibt zwei miteinander verknüpfte Dateien zurück: ein Word-Dokument für das interne Team sowie ein maßgeschneidertes Präsentationsdeck für die Nutzung bei Zava.

Die Zusammenfassung vereint den aus der Geheimdienstdatenquelle gewonnenen Kontext, Beziehungsdaten aus dem CRM-System, aktuelle Kommunikationen aus dem Korrespondenzverkehr des Nutzers, Geschäftsanalysen zu Leistung, Nutzung und Messung sowie Support-Anfragen aus dem Ticketing-System. Das Ergebnis ist ein einziges Vorbereitungsdokument mit empfohlenen Diskussionsthemen.
Die Präsentation wird für diese spezifische Kundeninteraktion individualisiert und verwendet die Markenfarben des Unternehmens. Sie kombiniert Materialien aus Fabric IQ und Foundry IQ zu Diskussionspunkten sowie kundenbezogene Erkenntnisse zu aktuellen Aktivitäten, ergänzt durch Daten zu Geschäftsabläufen, Kampagnenmetriken sowie neue Möglichkeiten und Dienstleistungen, die die Partnerschaft weiter vorantreiben können.

Der Wert ergibt sich nicht nur aus der Bereitstellung: Die Agenten laufen auf der Intelligenzschicht, wo sie im Auftrag einer Person auf Arbeitsdaten, Geschäftsdaten und organisatorisches Wissen zugreifen können, und sind eng in Microsoft 365 integriert.

Wie es aufgebaut ist

Für Entwickler, die etwas Ähnliches erstellen möchten, ist der Ausgangspunkt einfacher als das vollständige Beispiel. Die Azure Developer CLI kann beispielsweise ein neues Projekt initialisieren, wie einen Verkaufs-Vorbereitung-Agenten. Chat-basierte Agenten werden unterstützt und bleiben sehr beliebt; es können beliebige Frameworks verwendet werden, einschließlich LangGraph, und der Service unterstützt auch neuartige Muster. Vorlagen liefern die benötigten Dateien, und von dort aus kann das Projekt lokal debuggt und bereitgestellt werden. Das ist ein einfacher Agent aus einer Vorlage mit viel Raum für Anpassungen.

Wenn man zum fortgeschrittenen Agenten zurückkehrt, wird deutlich, was dahintersteckt. Der Code definiert Werkzeuge und Wissensquellen, einschließlich der drei IQs, sowie weitere Arten von Fähigkeiten, die heute zu den Mustern von Programmier-Agenten hinzugefügt werden können. Im Kern verwendet der Agent das GitHub Copilot SDK, das einen agentbasierten Zyklus über die definierte Werkzeugliste ausführt. Dieser Zyklus führte die Analyse von Dutzenden von Dateien, E-Mails, früheren Meetings sowie Betriebs- und Service-Daten durch, und daraus entstanden die Empfehlungen.

Das Microsoft Agent Framework verbindet alle Komponenten miteinander und fügt Elemente wie Middleware hinzu. Ein Beispiel für eine Regel: Wenn das Programmieragent versucht, eines dieser Dokumente ohne ausreichende Daten aus den drei IQs zu erstellen, blockiert die Middleware dies, da eine Ausgabe ohne diese fundierten Daten fast sicher falsch ist. Solche Muster sind wichtig, wenn man eine Unternehmensimplementierung skaliert, wobei Qualitätskontrollen ein ganzes Vertriebsteam sowie zusätzliche Sicherheitsmaßnahmen umfassen. Der volle Nutzen zeigt sich, wenn sowohl Frameworks als auch Muster kombiniert und innerhalb des Foundry Agent Service bereitgestellt werden.

Verwaltung einer Flotte

Sobald mehrere Agenten laufen, stellt sich die nächste Frage nach deren Überwachung und Verwaltung – und das ist möglich, weil alles innerhalb von Foundry abläuft. Das Portal zeigt in einem Überblick die Leistung und Kosten der gesamten Flotte: den Zustand der Agenten sowie Benachrichtigungen (im Demo sind alle Agenten gesund und es gibt noch keine Benachrichtigungen), die geschätzten Kosten, die Erfolgsraten und den Tokenverbrauch, wobei für die wichtigsten Agenten detailliertere Informationen zu deren Ausführungsmengen bereitgestellt werden. Die besten und schlechtesten Agenten hinsichtlich der Erfolgsraten zeigen an, welche Aufmerksamkeit benötigen.

Alles, was benötigt wird, um von Experimenten in die Produktion überzugehen und die Lösung allen Endnutzern zur Verfügung zu stellen, ist mit vollständiger Überwachungsfunktion bereits integriert. Der Hauptzweck besteht darin, die Komplexität beim sicheren und zuverlässigen Erstellen sowie Bereitstellen von Agenten in einer Organisation zu verringern. Für alle, die es ausprobieren möchten, besteht der Weg darin, zunächst ein Projekt im Foundry-Portal zu starten und die öffentlichen Beispiele von Microsoft durchzusehen, um das richtige SDK zu finden.

Daraus ergibt sich eine praktische Arbeitsabfolge. Beginnen Sie mit einem kleinen Agenten aus einem Template und bringen Sie ihn lokal zum Laufen. Fügen Sie nacheinander Tools und Wissensquellen hinzu, wobei das Middleware-System den Fortschritt verweigert, wenn Grundlagen fehlen. Deployen Sie früh in die gehostete Umgebung, damit Identifizierung, Isolierung und Tracking bereits lange vor dem Eintreffen echter Nutzer getestet werden können. Veröffentlichen Sie in den Chat-Tools, die die Menschen bereits nutzen, erst dann, wenn die Protokolle aussagekräftig sind, und halten Sie den Überblick über alle Agenten offen, sobald mehrere im Einsatz sind – schließlich zeigen sich dort zuerst steigende Kosten und sinkende Erfolgsraten. Teams, die dieser Reihenfolge folgen, finden Probleme in der Regel, solange sie noch günstig zu beheben sind.

Warum sich lokale und gehostete Lösungen so stark unterscheiden

Es lohnt sich, zu unterscheiden, was der Entwickler geschrieben hat und was die Plattform hinzufügt. Die Tools, Middleware und Workflows im Vertriebsagenten sind gewöhnlicher Anwendungscode, der sich auf einem Laptop genauso verhält wie in der Cloud. Was nach der Bereitstellung ändert, ist alles, was um diesen Code herum existiert: Es entsteht eine Identität, Sessions werden isoliert, Richtlinien werden bei jeder Interaktion geprüft, Spuren sammeln sich an und es öffnet sich ein Veröffentlichungsweg. Für all das war es nicht notwendig, den Agenten neu zu schreiben, weshalb die Demo die Bereitstellung als einzige Aktion in einem Editor und nicht als Migrationsprojekt darstellt.

Drei Fragen fassen diesen Ansatz zusammen, wobei jede auf eine oben beschriebene Schicht verweist.

Wer handelt? Die Entra-Identität gibt darauf eine Antwort – ob der Agent seine eigenen, eingeschränkten Berechtigungen verwendet oder die eines Benutzers ausleiht.
Wo findet die Arbeit statt und wer kann sie sehen? Nutzerbezogene MicroVM-Sandboxen halten die Sitzungen voneinander getrennt, und die Inhalts- sowie Einbettungspolitiken der Organisation gelten bei jedem Aufruf.
Was hat es getan und funktioniert es gut? Spuren, Ansicht der Konversationen, Leistungsindikatoren sowie Zusammenfassungen zu Kosten und Erfolgsquote beantworten diese Fragen – jeweils für jeden Agenten sowie für die gesamte Flotte.

Schutzmechanismen im Code

Die Plattform-Rahmenbedingungen ersetzen nicht die in dem Agenten selbst festgelegten Rahmenbedingungen. Die Middleware-Regel, die die Erstellung von Dokumenten verhindert, wenn die drei IQs nicht ausreichende Daten bereitgestellt haben, ist ein gutes Beispiel dafür, da sie eine Qualitätsstandards vorschreibt, von der keine allgemeine Richtlinie Kenntnis haben könnte. Eine Präsentation, die ohne CRM-Historie oder Nutzungsdaten erstellt wird, sieht dennoch professionell aus, und ein Verkäufer könnte zu einem Kundentreffen gehen und dabei auf erfundene Details vertrauen. Dies bereits auf Codeebene zu verhindern, bevor ein Datei erstellt wird, ist kostengünstiger als es danach zu korrigieren.

Dieselbe Denkweise erklärt, warum die Demo-Funktionen Fähigkeiten als separate, wiederverwendbare Komponenten zusammenfasst. Eine Fähigkeit, die Karten erstellt, und eine Fähigkeit, die Zusammenfassungen schreibt, können jeweils getestet, versioniert und von anderen Agenten wiederverwendet werden, wobei der Agentenzyklus entscheidet, wann sie aufgerufen werden sollen. Durch die Kombination dieses Zyklus, des Middleware-Bausteins des Frameworks sowie der Hostingschicht entstehen drei Bereiche, in denen Kontrolle ausgeübt werden kann: wie der Agent argumentiert, was er ausgeben darf und was die Umgebung ihm erlaubt.

Dinge, die vor dem Nachahmen des Musters berücksichtigt werden sollten

Das Beispiel zeigt einen optimalen Fall, in dem jede Datenquelle verbunden ist und die Berechtigungen ordentlich gestaltet sind. In der Praxis hängt die Qualität der Informationen von der Qualität der zugrundeliegenden CRM-, Ticketing- und Analysedaten ab. Eingrenzte Berechtigungen helfen nur, wenn sie tatsächlich eingegrenzt wurden; ein Agent, der über die eigenen Zugriffsrechte eines Benutzers verfügt, kann alles sehen, was dieser sehen kann – wodurch übermäßig umfassende Konten zu übermäßig umfassenden Agenten werden. Flotten-Dashboards sind nützlich, um die schwächsten Agenten auszumachen, doch jemand muss trotzdem die Protokolle durchlesen und entscheiden, ob ein niedriger Erfolgsgrad auf das Modell, ein Tool, eine fehlende Datenquelle oder zu strenge Einschränkungen zurückzuführen ist.