Prototyp erstellen, nachverfolgen, bewerten, Red-Teaming durchführen: Ein Workflow für KI-Agenten in Microsoft Foundry.

Es dauert nur wenige Minuten, um aus einem KI-Agenten ein paar gute Antworten zu bekommen. Die Entscheidung, ob dieser für die Veröffentlichung geeignet ist, dauert jedoch viel länger, denn das Team muss zunächst herausfinden, ob das gewählte Modell die entstehenden Kosten rechtfertigt, ob der Agent auf die richtigen Daten zugreift, welche Tools er verwendet, wie gut seine Antworten abschneiden und wie er sich gegen jemanden behauptet, der aktiv versucht, ihn zu durchbrechen.

Microsoft Foundry bündelt einen großen Teil dieses Prozesses in einem einzigen Browser-Arbeitsbereich, der Modellvergleiche, Anweisungen, Tools und Wissen, Nachverfolgung, Bewertung, generierte Testdaten sowie automatisierte Red-Team-Tests umfasst. Sein eigentlicher Wert liegt nicht darin, dass Code unbegrenzt aufgeschoben werden kann. Vielmehr ermöglicht er es, kostspielige Designentscheidungen zu treffen, solange das Projekt noch leicht zu ändern ist, bevor der Produktionscode feste Strukturen daraus schafft.

Im Folgenden wird ein Agent von einem leeren Projekt bis zu einem datengestützten Prototypen verfolgt – dieser wird analysiert, bewertet und angegriffen – und anschließend wird der Punkt markiert, an dem die Arbeit vom Portal in das SDK übergeht. Der Ablauf findet im Microsoft Build Retail-Agent-Umfeld innerhalb der neuen Foundry-Umgebung statt, die in der Region Sweden Central gehostet wird. Das Portal dient als Plattform für schnelle Iterationen, und der Weg in die Produktion bleibt innerhalb desselben Foundry-Projekts, sodass nichts von Grund auf neu erstellt werden muss.

Beginnen Sie mit etwas, das bereits funktioniert

Ein neues Foundry-Projekt ist eine Arbeitsumgebung, die Agenten, Modelle, Tools, Wissen, Bewertungsmöglichkeiten sowie Funktionen zur Überwachung enthält. Genaue Bereitstellungs Schritte, Standardeinstellungen sowie verfügbare Funktionen unterscheiden sich je nach Region und ändern sich im Laufe der Zeit, weshalb das Portal selbst als endgültige Quelle bezüglich der Möglichkeiten eines Projekts angesehen werden sollte.

Sobald ein Agent erstellt wurde, beginnt die eigentliche Arbeit im Playground. Dort werden das Modell und die Anweisungen festgelegt, Tools oder Wissen hinzugefügt, und das Ergebnis wird im Chat-Fenster getestet. Auch hier zeigt sich zunächst, wie schwach ein Prototyp ist. Wenn man einer kaum konfigurierten Agentin eine umfassende Produktfrage stellt, ist die Antwort in der Regel banal. Sie mag selbstbewusst klingen, obwohl sie nichts über das Sortiment, die Richtlinien oder den Geschäftskontext weiß. Behalten Sie diese Antwort als Grundlage, denn jede spätere Änderung sollte daran gemessen werden.

Modellwahl auf der Grundlage von Belegen

Ein starkes Standardmodell ist nicht unbedingt das Richtige für die Produktion. Manche Aufgaben erfordern tiefgehendes Denken, während andere Geschwindigkeit oder niedrige Kosten priorisieren – daher sollte die Auswahl auf einer Bewertung und nicht auf einem Bauchgefühl beruhen. Foundry bietet mehrere Tools zur Filterung des Sortiments an:

• Eine Rangliste, die Modelle anhand von Kriterien wie Qualität, Sicherheit, Leistung und Kosten bewertet.
• Ausgleichsdiagramme, die zwei Dimensionen in einem Diagramm darstellen, wie beispielsweise Qualität gegenüber Preis.
• Eine nebeneinander angezeigte Ansicht, die eine kurze Liste auf Modelle reduziert, die für die jeweilige Arbeitslast geeignet sind.
• Ein Modellrouter, der jede Anfrage entsprechend einer Kosten-Qualitäts-Strategie an ein geeignetes Modell zuweist, sodass kein einzelnes Modell alles bewältigen muss.

Aufgrund von Benchmark-Ergebnissen allein liegen nur schwache Beweise vor. Es ist aussagekräftiger, dieselbe Arbeitslast mit jedem Kandidatmodell auszuführen. Der Router ist besonders nützlich, wenn die Anfragen in ihrer Schwierigkeit stark variieren. Derzeit stehen Modus „Ausgeglichen“, „Kosten“ und „Qualität“ zur Verfügung, und aktuelle Versionen wechseln automatisch auf ein anderes geeignetes Modell, falls das zugeordnete ausfällt.

Der nächste Schritt besteht darin, dieselben Anweisungen an jede Kandidatenkonfiguration zu senden und die Qualität der Antworten, die Latenz sowie die Kosten zu vergleichen. Benchmarks reduzieren den Auswahlkreis, und Ihre eigene Arbeitsbelastung bestimmt den Gewinner. Microsoft Learn beschreibt in seiner Foundry-Dokumentation sowohl den Benchmark-Ablauf als auch den Router.

Anweisungen sind der günstigste Hebel

Das Wechseln von Modellen ist nicht immer der richtige erste Schritt. Unklare Anweisungen können ein teures Modell in einen generischen Chatbot verwandeln. Der Prompt Optimizer in Foundry überarbeitet und strukturiert die Anweisungen neu, erklärt die Gründe für Änderungen in bestimmten Abschnitten und ermöglicht mehrere Durchgänge, bevor etwas angewendet wird. Auf diese Weise werden die Anweisungen zu einer versionierten Eingabe für das Engineering, anstelle eines unstrukturierten Absatzes, der so lange überarbeitet wird, bis eine Antwort besser erscheint.

Eine ansprechende Überarbeitung sagt wenig aus. Die bessere Überprüfung erfolgt durch das Vergleichen eines Evaluationsdatensatzes mit den alten und neuen Versionen. Jede Rolle, Antwortstruktur, Fallback-Verhaltensweise oder Beschränkung bei abweichenden Anfragen, denen der Agent folgen soll, muss sowohl in seinen Anweisungen als auch in den Bewertungskriterien enthalten sein, die seine Ausgaben bewerten.

Antworten auf Grundlage genehmigter Daten

Die Anweisungen bestimmen, wie sich der Agent verhält, während das Wissen bestimmt, worauf er antworten kann. In kleineren Fällen ermöglicht das Anhängen von Dateien und deren Bereitstellung über Suchwerkzeuge es den Antworten, auf Quellmaterialen zu verweisen.

Größere Unternehmensumgebungen können Foundry IQ nutzen, eine gemeinsame Wissensschicht, die auf vielen Quellen basiert. Eine Wissensdatenbank kann Azure Blob Storage, SharePoint, OneLake, bestehende Suchindizes sowie öffentlichen Webinhalten verknüpfen, wobei agierende Suchmechanismen die Abfragen planen, Quellen auswählen, diese durchsuchen und fundierte, belegte Ergebnisse zurückgeben.

Eine Warnung gilt für die Zugriffskontrolle. Berechtigungen auf Dokumentenebene werden nur für Quellen und Konfigurationen berücksichtigt, die sie unterstützen; daher sollte niemand eine Wissensdatenbank als berechtigungsorientiert bezeichnen, bevor die Quellenberechtigungen sowie der Identitätsfluss tatsächlich konfiguriert wurden.

Um den Effekt zu sehen, stellen Sie eine Frage zweimal – vor und nach der Konfiguration. Die erste Antwort zeigt das allgemeine Wissen des Modells, während die zweite den Unterschied aufzeigen sollte, den Ihre Daten bewirken.

Frühzeitige Aktivierung der Protokollierung

Die Beobachtbarkeit ist besonders nützlich, solange der Agent noch Fehler aufweist. Foundrys Protokollierung folgt den Konventionen von OpenTelemetry und ist in Azure Monitor Application Insights integriert; sie erfasst den Ablauf eines Agents oder einer Anwendung, sodass Modelleaufrufe, Werkzeugnutzung, Eingaben, Ausgaben sowie Zeiten später untersucht werden können.

Drei Ebenen nutzen dieses gemeinsame Betriebsbild und beantworten jeweils ihre eigenen Fragen:

• Die Nachverfolgung zeigt an, was bei einem bestimmten Lauf stattgefunden hat.
• Die Bewertung gibt an, ob das Verhalten den Anforderungen entspricht.
• Die Überwachung zeigt, wie sich die Laufe im Laufe der Zeit entwickeln.

Vergessen Sie nicht, dass die Telemetriedaten von Application Insights mit Kosten verbunden sind, die vom Datenvolumen und der Speicherung abhängen. Planen Sie die Überwachungsfunktionen als Teil der Produktionsarchitektur ein und nicht als kostenloses Debugging-Extra.

Messen Sie das Verhalten, nicht nur Vermutungen

Praktische Tests eignen sich zur Erkundung, können jedoch nicht feststellen, ob eine Änderung den Agenten verbessert hat. Foundry bietet vorgefertigte Bewertungstools für verschiedene Aspekte des Verhaltens: Qualität, Risiko und Sicherheit sowie agentenspezifische Kriterien wie die Einhaltung der Aufgaben, deren Abschluss, das Verständnis der Absicht sowie die Effektivität der Toolaufrufe.

Kundenspezifische Bewertungsfunktionen nehmen in der Regel eine von zwei Formen an. Solche, die auf einer Bewertungsskala oder Anweisungen basieren, nutzen ein Modell als Entscheider für kritische Kriterien, die subjektiv sind oder vom Kontext abhängen. Deterministische Funktionen hingegen sind einfache Funktionen für Kriterien, die direkt berechnet werden können. Wie freundlich eine Antwort ist, erfordert möglicherweise eine Bewertungsskala, während eine Längenbeschränkung dies niemals tut. Die Bewertung fügt selbst Kosten und Unschärfen hinzu, weshalb bei einer zuverlässigen Entscheidung durch eine Funktion ein weiterer Aufruf eines Modells Geldverschwendung ist.

Datensätze sorgen für präzise Iterationen

Eine einzelne Anweisung zeigt nur, dass eine Funktion funktioniert, doch ein Datensatz macht Muster sichtbar. Foundry kann Dateien im JSONL- oder CSV-Format bewerten, die Sie vorbereitet haben, bereits vorhandene Protokolle oder synthetische Testdaten. Synthetische Daten sind nützlich vor dem Start sowie dann, wenn der aktuelle Traffic zu gering ist, um die relevanten Randfälle abzudecken.

Das Ergebnis ist ein Zyklus, den man wiederholen kann:

1. Stellen Sie einen repräsentativen Testdatensatz so ein, dass er konstant bleibt.
2. Führen Sie die aktuelle Version des Agents darauf aus.
3. Ändern Sie genau eine Variable – sei es das Modell, die Anweisungen, die Tool-Einstellungen oder die Grundlagen.
4. Bewerten Sie erneut am selben Datensatz.
5. Vergleichen Sie die Ergebnisse, Reaktionszeiten und Ressourcenverbrauch.
6. Nehmen Sie die Änderung an oder lehnen Sie sie ab.

Hier hört die Arbeit auf, einer einfachen Anpassung von Prompten zu ähneln, und beginnt eher an Regressionstests für Software zu erinnern.

Red-Teaming entdeckt das, was normale Bewertungsmethoden übersehen

Herkömmliche Qualitätskontrollen prüfen, ob der Agent seine zugewiesene Aufgabe gut erledigt. Red Teaming untersucht hingegen, was das System tut, wenn ihm absichtlich feindliche Eingaben zugeführt werden. Der AI Red Teaming Agent in Foundry kombiniert das Open-Source-Projekt PyRIT mit Foundrys Risiko- und Sicherheitsbewertung. Er testet unterstützte Modelle und Agenten mit Angriffsmethoden, die darauf ausgelegt sind, Standard-Schutzmaßnahmen zu umgehen, und gibt einen Angriffs-Erfolgsgrad (ASR) an.

Zu den unterstützten Methoden gehören Transformationen wie Flip und Tense sowie Jailbreaks und andere feindliche Tricks. Die aktuellen Risikoszenarien umfassen schädlichen Inhalt, das Lecksen sensibler Daten, verbotene Aktionen und indirekte Prompt-Injektionen. Die Übung lohnt sich, wenn ihre Ergebnisse zu einer weiteren Entwicklungsphase führen, und nicht nur, wenn sie als einzelnes Screenshot zur Konformitätsprüfung endet. Betrachten Sie sie als einen Kreislauf:

1. Führen Sie einen Scan an einem Ort durch, der nicht in der Produktionsumgebung liegt.
2. Prüfen Sie, welche Risikokategorie und welches Angriffsmethoden durchgedrungen sind.
3. Beseitigen Sie die Ursache, sei es eine Anweisung, eine Grenze eines Tools, eine Inhaltskontrolle oder Berechtigungen.
4. Führen Sie erneut einen Scan durch.
5. Überwachen Sie, ob sich die Erfolgsrate der Angriffe verringert.

Überwachen Sie die gesamte Flotte

Sobald die Agenten im Einsatz sind, geht es nicht mehr darum, ob eine bestimmte Anweisung funktioniert hat, sondern darum, wie sich das System über Wochen hinweg verhält. Die Überwachungs- und Betriebsansichten zeigen Kennzahlen für die gesamte Arbeitslast, wie z. B. Anrufzahlen, Tokenverbrauch, Fehler sowie kostenbasierte Metriken, wobei bei Unterstützung auch Einblicke in einzelne Agenten und Modelle möglich sind.

Das Denken in Mikroservices ist hier innerhalb gewisser Grenzen nützlich. Ein Agent kann als Verhaltenseinheit mit eigener Version betrachtet werden, die aus Anweisungen, Werkzeugen, Wissen, einer Modellpolitik sowie beobachtbaren Ausgaben besteht. Jeder Agent muss nicht zu einem separat bereitgestellten Service werden. Es geht darum, Grenzen festzulegen, damit ein Agent bearbeitet, bewertet und verbessert werden kann, ohne alles in seiner Umgebung neu schreiben zu müssen.

Der Kreislauf hinter dem Portal

In der Praxis läuft der Zyklus aus Bauen, Messen, Optimieren, Steuern und anschließendem Zurückkehren zum Anfang ab, sobald Hinweise darauf vorliegen, dass der Agent noch nicht bereit ist. Es wird weitergemacht, weil Spuren und Bewertungen eine im Voraus festgelegte Hürde überwinden, niemals weil eine Demo gut aussah. Die Produktseiten ändern sich, doch der Ablauf bleibt derselbe: Prototyp erstellen, nachverfolgen, bewerten, festigen, überwachen und wiederholen.

Eine Einschränkung vorerst: Microsoft plant, Foundry Workflows am 1. Dezember 2026 einzustellen und lenkt die Entwicklung neuer Workflows in Richtung des Microsoft Agent Frameworks. Ein neues Design sollte nicht auf der bald veralteten Plattform basieren.

Von Browser-Prototyp bis Produktionscode

Das Portal sollte den Weg zum Code verkürzen und nicht dessen Ersatz sein. Anforderungen wie benutzerdefinierte Orchestrierung, CI/CD, tiefere Integration oder gehosteter Agentencode erfordern das Foundry SDK sowie seine Tools, die derzeit für Python, C#, JavaScript und Java verfügbar sind. Architektonisch bleiben die Ressourcen und Endpunkte des Projekts zentral. Das Portal, das SDK sowie die Tools sind lediglich verschiedene Zugänge zu einem Foundry-Projekt und seinen Ressourcen – man kann sich also ein Projekt mit einem einheitlichen Endpunkt vorstellen, ohne getrennte Prototypen- und Produktionsplattformen. Der SDK-Schnellstart auf Microsoft Learn markiert den Beginn dieser Umstellung.

Nächste Experimente

Zwei Themen folgen. Das eine ist die Multi-Agent-Orchestrierung, bei der unabhängig testbare Agenten, jeder mit einem klaren Vertrag und einer Bewertungsgrundlage, über ein modernes Orchestrierungsframework miteinander verbunden werden und nicht in einen einzigen riesigen Prompt gepackt werden. Das andere ist die Anpassung von Modellen, die erst dann bewertet werden sollte, wenn Prompting, Grounding, Routing und Tool-Design alle versagt haben. Beide Themen gehören nach der hier beschriebenen Bewertungsmethode.

Fazit

Die erste funktionierende Antwort eines Agenten startet den Prozess, beendet ihn jedoch nicht. Ein Release Candidate benötigt Belege in mehreren Bereichen: eine Modellwahl, die bei einem Vergleich verschiedener Arbeitslasten Bestand hält, eine Erklärung dafür, warum bestimmte Antworten sichtbar anders ausfallen, aufrufbare Tools, eine wiederholbare Bewertung sowie eine Risikozahl des Red-Teams, die im Laufe der Zeit abnimmt. Das Portal bietet den schnellen Zyklus, während das Projekt und das SDK die Arbeit in die eigentliche Produktionsumgebung übertragen. Bauen Sie schnell, fügen Sie frühzeitig Instrumentierung hinzu, testen Sie jede Änderung an derselben Arbeitslast, prüfen Sie Ihr eigenes System, bevor externe Parteien es tun, und wechseln Sie auf Code, sobald der Browser bereits die Aufgaben gut bewältigt.