Microsoft Foundry Agent erstellen: Prompt Agent oder Hosted Agent?

Wer einen Microsoft Foundry Agent erstellen will, entscheidet nicht zuerst über ein Sprachmodell. Zunächst müssen Aufgabe, zulässige Aktionen, Datenzugriffe und Verantwortung feststehen. Erst daraus ergibt sich, ob ein deklarativ konfigurierter Prompt Agent ausreicht oder ein Hosted Agent mit eigenem Laufzeitcode sinnvoll ist.

Dieser Ratgeber führt von der Foundry-Ressource und dem Projekt über Modell, Tools und Identität bis zu Deployment, Endpunkt und Betrieb. Er richtet sich an technische Verantwortliche, die einen Agent nicht nur demonstrieren, sondern sicher in eine Unternehmensarchitektur überführen möchten.

Microsoft Foundry Agent erstellen: Ziel und Eingriffsgrenzen klären

Ein Agent braucht einen eng formulierten Auftrag. „Unterstützt den Einkauf“ ist dafür zu breit. Prüft der Agent Lieferantenunterlagen, beantwortet er Fragen zu Verträgen oder legt er Bestellanforderungen an? Für jeden Anwendungsfall sollten erwartete Eingaben, erlaubte Datenquellen, mögliche Aktionen und ein messbares Ergebnis dokumentiert werden.

Ebenso wichtig sind Negativregeln. Dazu gehören Daten, die der Agent nicht sehen darf, Entscheidungen, die Menschen vorbehalten bleiben, und Aktionen, die eine Freigabe benötigen. Diese Grenzen bestimmen später Systemanweisung, Werkzeugumfang, Identitätsmodell und Testfälle. Die Architektur von Microsoft Foundry liefert dafür den technischen Rahmen.

Ressource und Projekt sauber zuschneiden

Die Foundry-Ressource bündelt zentrale Verwaltungs- und Sicherheitsfunktionen. Projekte schaffen getrennte Arbeitsräume für Anwendungen, Deployments und beteiligte Teams. Eine sinnvolle Projektgrenze orientiert sich an Verantwortlichkeit, Datenrisiko und Lebenszyklus, nicht an jeder einzelnen Idee. Zu viele Projekte erhöhen Betriebsaufwand; ein Sammelprojekt erschwert Kosten- und Rechtezuordnung.

Für Entwicklung, Test und Produktion sollten getrennte Umgebungen oder mindestens klar getrennte Deployments mit eigenen Konfigurationen bestehen. Namen, Regionen, Tags, Budgetzuordnung und verantwortliche Personen gehören vor dem ersten Deployment in einen Standard. Dadurch bleibt erkennbar, welcher Endpunkt welchem Prozess dient.

Modell nach Aufgabe statt Bekanntheit wählen

Die Modellauswahl beginnt mit Qualitätsanforderungen: Muss der Agent lange Dokumente verarbeiten, strukturierte Ausgaben erzeugen, Werkzeuge zuverlässig auswählen oder mehrere Sprachen beherrschen? Dazu kommen Latenz, verfügbare Region, Durchsatz, Inhaltsfilter, Kontextfenster und Kosten. Ein großes Modell ist nicht automatisch die wirtschaftlichste Wahl.

Für einen belastbaren Vergleich wird ein repräsentativer Testsatz benötigt. Mehrere Kandidaten beantworten dieselben Fälle unter identischen Anweisungen und Werkzeugen. Bewertet werden fachliche Richtigkeit, Quellenbezug, Formatstabilität, Toolauswahl, Laufzeit und Verbrauch. Erst die Messwerte rechtfertigen eine Modellentscheidung.

Wann ein Prompt Agent passt

Ein Prompt Agent eignet sich, wenn Verhalten weitgehend durch Anweisungen, Wissen und standardisierte Tools beschrieben werden kann. Typische Fälle sind Recherche in freigegebenen Quellen, Zusammenfassung, Klassifikation oder die Ausführung weniger klar definierter Aktionen. Die Plattform übernimmt einen großen Teil der Orchestrierung und beschleunigt Änderungen.

Die geringere Codebasis erleichtert einen Pilot, hebt aber die Architekturarbeit nicht auf. Versionierung der Anweisungen, Zugriff auf Werkzeuge, Fehlerbehandlung und Evaluation bleiben notwendig. Sobald komplexer Zustand, eigene Bibliotheken oder eine sehr spezielle Ablaufsteuerung erforderlich werden, stößt das deklarative Modell an praktische Grenzen.

Wann ein Hosted Agent sinnvoll wird

Hosted Agents erlauben eigene Agentenlogik und Frameworks in einer verwalteten Laufzeit. Das ist interessant, wenn der Ablauf mehrere spezialisierte Komponenten koordiniert, umfangreiche Geschäftslogik enthält oder Abhängigkeiten benötigt, die ein Prompt Agent nicht abbildet. Auch deterministische Vor- und Nachverarbeitung lässt sich so enger kontrollieren.

Der zusätzliche Freiheitsgrad erzeugt Verantwortung für Codequalität, Abhängigkeiten, Secrets, Skalierung und Fehlerbilder. Ein Hosted Agent sollte deshalb nicht gewählt werden, weil Pro-Code grundsätzlich leistungsfähiger wirkt. Entscheidend ist, ob der Anwendungsfall die zusätzliche Kontrolle tatsächlich benötigt und das Team sie dauerhaft betreiben kann.

Prompt Agent und Hosted Agent vergleichen

Für die Entscheidung helfen sechs Fragen: Lässt sich der Ablauf deklarativ beschreiben? Gibt es eigene Bibliotheken? Muss Zustand außerhalb einer Sitzung verwaltet werden? Wie komplex ist die Toolsteuerung? Welche Laufzeitkontrolle wird verlangt? Wer übernimmt Wartung und Bereitschaft? Ein Prompt Agent gewinnt bei Einfachheit und Änderbarkeit, ein Hosted Agent bei spezieller Logik und Laufzeitkontrolle.

Ein schrittweiser Ansatz reduziert Risiko. Das Team setzt zunächst den kleinsten fachlich vollständigen Ablauf um und misst, wo echte Grenzen auftreten. Erst belegte Lücken rechtfertigen den Wechsel. Die Gegenüberstellung Copilot Studio versus Microsoft Foundry hilft zusätzlich, wenn auch Low-Code als Plattformoption betrachtet wird.

Tools als kontrollierte Fähigkeiten gestalten

Tools verbinden den Agent mit Suchsystemen, APIs oder Geschäftsprozessen. Jede Fähigkeit benötigt eine eindeutige Beschreibung, ein knappes Eingabeschema und validierbare Ausgaben. Überlappende Toolbeschreibungen führen dazu, dass das Modell unzuverlässig auswählt. Fachliche Namen und Beispiele sind meist wirksamer als technische Kurzformen.

Schreibende Tools brauchen zusätzliche Leitplanken: Eingaben werden serverseitig validiert, wiederholte Aufrufe müssen beherrscht werden und kritische Änderungen benötigen Bestätigung oder Genehmigung. Fehler werden strukturiert an den Agent zurückgegeben. Eine freundliche Textmeldung ohne Fehlercode erschwert Diagnose und kann falsche Erfolgsmeldungen auslösen.

Identität folgt dem fachlichen Auftrag

Ein Agent darf nicht pauschal mit weitreichenden Anwendungsrechten arbeiten. Zuerst ist zu entscheiden, ob eine Aktion im Namen des angemeldeten Benutzers oder als eigene Workload ausgeführt wird. Benutzerdelegation erhält den persönlichen Berechtigungskontext; eine Agentenidentität eignet sich für klar definierte, vom Benutzer unabhängige Aufgaben.

Bei Anwendungsrechten werden die erforderlichen Berechtigungen einzeln begründet und administrativ genehmigt. Hinweise zur Kontrolle liefert die Prüfung von Entra-App-Berechtigungen und Admin Consent. Secrets sollten vermieden oder in einem sicheren Dienst verwaltet werden; wo möglich, sind verwaltete Identitäten und Zertifikate vorzuziehen.

Anweisungen versionieren und gegen Fehlgebrauch absichern

Die Systemanweisung beschreibt Rolle, zulässigen Umfang, Quellenregeln, Ausgabeformat und Verhalten bei Unsicherheit. Sie sollte keine geheimen Werte enthalten und als versioniertes Artefakt behandelt werden. Änderungen gehören durch Review und Test, weil eine kleine Formulierung Toolauswahl oder Antwortgrenzen verändern kann.

Prompt Injection lässt sich nicht allein durch einen Satz wie „Ignoriere fremde Anweisungen“ lösen. Schutz entsteht durch minimale Berechtigungen, Trennung von Daten und Steueranweisungen, Validierung von Toolparametern, Inhaltskontrollen und Tests mit absichtlich manipulierten Dokumenten. Der Agent muss unzulässige Aufforderungen erkennbar ablehnen.

Deployment und Endpunkt planbar machen

Ein Deployment fixiert Modell, Kapazität und Konfiguration für eine nutzbare Version. Der aufrufende Dienst sollte nicht von zufälligen Studiokonfigurationen abhängen, sondern einen klar benannten Endpunkt mit kontrollierter Authentifizierung verwenden. Konfigurationswerte für Entwicklung, Test und Produktion werden getrennt verwaltet.

Vor dem produktiven Wechsel sind Last, Zeitüberschreitungen, Quoten und Wiederholungsverhalten zu testen. Die Anwendung braucht eine verständliche Reaktion, wenn Modell oder Tool nicht erreichbar sind. Warteschlange, begrenzter Retry und ein manueller Ersatzprozess verhindern, dass ein externer Engpass zum unkontrollierten Geschäftsrisiko wird.

Evaluation vor der Freigabe

Der Testsatz bildet normale, schwierige und unzulässige Fälle ab. Neben Antwortqualität werden Quellenbezug, Toolauswahl, Parameter, Berechtigungsgrenzen und Abbruchverhalten bewertet. Für wichtige Felder sind erwartete Werte oder Rubriken festzulegen. Ein Mittelwert allein verdeckt kritische Einzelverstöße.

Eine Freigabe benötigt Schwellenwerte. Beispielsweise darf keine fremde Kundennummer offengelegt werden, während eine kleine sprachliche Abweichung tolerierbar ist. Fachbereich, IT und Informationssicherheit müssen wissen, welche Kriterien sie abnehmen. Testergebnisse werden zusammen mit Prompt-, Modell- und Toolversion gespeichert.

Beobachtbarkeit für Modell und Werkzeuge

Im Betrieb sollten Anfrage, Laufzeit, Modellverbrauch, Toolaufrufe, Fehlerklasse und Ergebnisstatus korrelierbar sein. Personenbezogene oder vertrauliche Inhalte dürfen dabei nicht unkontrolliert in Protokolle gelangen. Ein gemeinsamer Trace-Identifier verbindet Anwendung, Agent und nachgelagerte API, ohne den gesamten Gesprächsinhalt zu duplizieren.

Dashboards zeigen Fehlerquoten, Latenz, Verbrauch und fachliche Erfolgsindikatoren. Warnungen brauchen eine klare Reaktion: Wer prüft einen Anstieg fehlerhafter Toolaufrufe, wer sperrt ein Deployment und wer informiert betroffene Prozessverantwortliche? Monitoring ohne Zuständigkeit erzeugt nur Daten.

Betriebsübergabe und Rückfallweg

Vor der Übergabe werden Eigentümer für Produkt, Modellkonfiguration, Tool-APIs, Berechtigungen und Support benannt. Dokumentiert werden bekannte Grenzen, Quoten, Datenquellen, Abhängigkeiten und Notfallkontakte. Auch die Überwachung von App-Secrets und Zertifikaten gehört in den Lebenszyklus.

Ein Rückfallweg kann eine vorherige Agentenversion, ein read-only Modus oder die Weiterleitung an einen Menschen sein. Er muss technisch vorbereitet und geprobt werden. Wird erst während eines Vorfalls über die Abschaltung nachgedacht, bleiben Abhängigkeiten und Auswirkungen oft unklar.

Von einem belastbaren Pilot zum Produktionsdienst

Ein guter Pilot bearbeitet einen echten, aber begrenzten Prozess mit repräsentativen Benutzern. Er liefert Messwerte zu Qualität, Zeitgewinn, Fehlern und Betriebskosten. Die Ergebnisse entscheiden, ob Umfang, Modell oder Plattform angepasst werden. Eine erfolgreiche Demo ist noch kein Nachweis für Produktionsreife.

Der produktive Dienst entsteht, wenn Architektur und Organisation zusammenpassen: ein abgegrenzter Auftrag, minimale Rechte, nachvollziehbare Versionen, überprüfte Werkzeuge, definierte Qualitätsgrenzen und ein erreichbarer Betrieb. Dann wird aus dem Agentenexperiment eine kontrollierbare Anwendung.

Produktionscheck vor der Endpunktfreigabe

Vor der Freigabe werden Modell- und Toolversionen, minimale Rechte, Netzwerkpfade, Quoten, Kostenwarnungen, Traces, Evaluationsergebnisse und Rückfallweg in einer Checkliste bestätigt. Die aufrufende Anwendung nutzt dieselbe Identität und denselben Endpunkt wie im späteren Betrieb. Ein Test allein aus dem Studio genügt nicht.

Zusätzlich wird ein kontrollierter Ausfall geprobt: Ein Tool antwortet nicht, die Modellquote ist erschöpft oder eine Identität verliert ihre Berechtigung. Der Agent muss abbrechen, einen nachvollziehbaren Status liefern und darf keine halbfertige Aktion als Erfolg melden. Erst diese Probe zeigt, ob Architektur und Runbook zusammenpassen.

API-Vertrag für aufrufende Anwendungen stabilisieren

Der Agentenendpunkt sollte eine klar versionierte Eingabe, Antwort, Fehlerstruktur und Korrelations-ID besitzen. Aufrufende Anwendungen dürfen nicht von internen Zwischenschritten oder frei wechselnden Textformaten abhängen. Strukturierte Ergebnisfelder werden serverseitig validiert; menschenlesbarer Text bleibt eine Darstellung, kein technischer Status.

Ändert sich ein Tool oder Agentenframework, kann der äußere Vertrag stabil bleiben. Inkompatible Änderungen erhalten eine neue Version und einen Übergangszeitraum. Last- und Sicherheitstests erfolgen über genau diese Schnittstelle. Das entkoppelt Benutzeroberfläche und Agentenimplementierung, erleichtert Rollback und verhindert, dass ein internes Experiment unbemerkt mehrere produktive Verbraucher bricht.