Vor Microsoft Build 2027: Wie nehmen Sie die Bereitstellung von Foundry Hosted Agents ab?

Nehmen Sie eine Bereitstellung von Foundry Hosted Agents erst ab, wenn Laufzeitprotokoll, Bereitschaft, Sitzungszustand, Identität und Aufrufkette geprüft sind – ein erfolgreicher Deployment-Status allein reicht nicht. Wenn Sie diese Woche einen lokalen Agenten migrieren, beginnen Sie mit einem reproduzierbaren Protokolltest und dokumentieren Sie danach jeden Schritt bis zum produktionsnahen Aufruf.

Dieser Beitrag richtet sich an Entwickler, die einen lokalen Agenten in Microsoft Foundry Hosted Agents überführen möchten.
Plattformingenieure finden hier Prüfpunkte für Container, Bereitschaft und Veröffentlichungsstatus.
Teams, die ihre Agent-Infrastruktur vor Microsoft Build 2027 bewerten, können damit den aktuellen Stand nachvollziehbar testen.

Vor dem ersten Lauf: Einsatzbereich und Abhängigkeiten

Microsoft Foundry kann codebasierte Agenten als containerisierte Anwendungen in einer verwalteten Infrastruktur hosten. Das Hosting nimmt Ihnen jedoch nicht die Verantwortung für Agentenlogik, unterstützte Anfragen, Zustandsverwaltung oder Tests ab. Maßgeblich sind die aktuell dokumentierten Anforderungen und Abläufe der Microsoft-Learn-Übersicht zu Hosted Agents sowie die Einführung zur Bereitstellung eigenen Codes.

Ein verwaltetes Hosting passt vor allem dann, wenn Ihr Agent als Dienst auf Anfragen reagieren kann und seine Abhängigkeiten im vorgesehenen Container verfügbar sind. Prüfen Sie vorab, ob die Anwendung beim Start externe Ressourcen erwartet, etwa Zugangsdaten, Konfigurationswerte, Dateien oder Verbindungen zu anderen Diensten. Diese Abhängigkeiten sind nicht automatisch harmlos, nur weil der Container startet: Ein Agent kann den Start überstehen und trotzdem beim ersten echten Aufruf scheitern.

Erfassen Sie vor der Migration insbesondere:

• Startverhalten: Kann der Prozess mit der vorgesehenen Konfiguration starten, oder setzt er lokale Dateien, Umgebungswerte oder manuelle Schritte voraus?
• Netzwerkzugriffe: Welche externen Endpunkte werden zur Laufzeit gebraucht? Sind DNS-Auflösung, ausgehende Verbindungen und erforderliche Berechtigungen in Ihrer Zielumgebung abgedeckt?
• Geheimnisse und Identität: Wo liegen Zugangsdaten, und welche Identität soll der Agent für nachgelagerte Aufrufe verwenden? Legen Sie keine produktiven Geheimnisse in Quellcode oder Testprotokolle.
• Speicher und Sitzungen: Liegen wichtige Daten nur im flüchtigen Prozessspeicher oder auf dem lokalen Dateisystem? Klären Sie, wie der Agent Sitzungen nach Neustarts oder einer neuen Bereitstellung behandeln soll.
• Abhängigkeiten des Builds: Stimmen Laufzeit, Bibliotheken und Paketierung mit dem dokumentierten Bereitstellungsweg überein? Übernehmen Sie nicht ungeprüft lokale Annahmen in den Container.

Die folgende Tabelle trennt drei Arbeitssituationen. Sie ist eine Entscheidungshilfe, keine Aussage über garantierte Plattformressourcen.

Wenn Ihr Agent auf lokale Dateien, interaktive Anmeldung oder einen nur auf Ihrem Rechner vorhandenen Dienst angewiesen ist, verschieben Sie die Bereitstellung nicht einfach in die Cloud und hoffen auf dasselbe Verhalten. Ersetzen Sie die Abhängigkeit durch einen für die Zielumgebung vorgesehenen Mechanismus oder entscheiden Sie bewusst, dass dieses Szenario nicht in den Hosted-Agent-Betrieb gehört.

Was muss vor der Bereitstellung geprüft werden?

Legen Sie eine kurze, versionierte Prüfbasis an: Quellstand, verwendete Paketierung, Startkonfiguration, erforderliche Zugriffe und erwartete Antwortformen. Notieren Sie auch, welche Zustände der Agent zwischen Anfragen behalten muss. Damit können Sie einen späteren Unterschied zwischen lokalem Lauf und gehostetem Lauf auf einen konkreten Änderungspunkt zurückführen, statt nur „funktioniert lokal“ festzuhalten.

Verwenden Sie für lokale Tests dieselbe Schnittstelle, die Sie im gehosteten Betrieb erwarten. Ein separates Testskript, das nur eine interne Funktion direkt aufruft, belegt nicht, dass der Agent die vorgesehene Anfrage annimmt. Die Microsoft-Dokumentation beschreibt die Hosting- und Bereitstellungswege; die Eignung Ihrer individuellen Abhängigkeiten müssen Sie anhand Ihrer Anwendung nachweisen.

Lokale Prüfung: Vertrag statt bloßem Startsignal

Bevor Sie ein Artefakt veröffentlichen, gleichen Sie die Anwendung mit dem offiziellen Hosted-Agent-Laufzeitvertrag ab. Prüfen Sie dort die aktuell beschriebene Schnittstelle und die Erwartungen an Ein- und Ausgaben. Verwenden Sie nicht ungeprüft alte Codebeispiele: Endpunkte, SDKs und Bereitstellungsoptionen können sich ändern. Vor der Veröffentlichung sollten Sie die jeweilige Microsoft-Learn-Seite und den Status der verwendeten SDK-Version erneut kontrollieren.

Ein gültiger Start ist nur ein Teil des Tests. Rufen Sie die Anwendung über den vorgesehenen Vertrag auf und prüfen Sie mindestens diese Fälle:

1. Gültige Eingabe: Die Anfrage wird angenommen; die Antwort entspricht dem Format, das Ihr Aufrufer verarbeitet.
2. Ungültige oder unvollständige Eingabe: Die Anwendung reagiert kontrolliert und gibt eine verständliche Fehlerantwort zurück, statt einen unklaren Abbruch zu erzeugen.
3. Längere Verarbeitung: Sie können erkennen, ob die Anwendung Zwischenergebnisse streamt oder erst am Ende antwortet. Testen Sie die Variante, die Ihr tatsächlicher Aufrufer nutzt.
4. Fortsetzung einer Sitzung: Ein Folgeaufruf erhält nur dann Kontext, wenn Ihre Implementierung das vorsieht. Prüfen Sie ausdrücklich, ob neue Sitzungen isoliert bleiben.
5. Fehler eines nachgelagerten Dienstes: Der Agent meldet einen geeigneten Fehler und hinterlässt verwertbare Diagnoseinformationen, ohne geheime Werte auszugeben.

Stream-Verhalten, Sitzungszustand und Fehlerantworten sind Eigenschaften Ihrer Anwendung und Ihres konkreten Aufrufpfads. Gehen Sie nicht davon aus, dass ein SDK automatisch jede Geschäftsregel oder jeden Fehlerfall abdeckt. Halten Sie pro Test Eingabe, erwartetes Ergebnis und tatsächlich beobachtete Antwort fest. Für HTTP-Antworten sollten Sie den Statuscode mit dem Fehlerbild verbinden: Beispielsweise sind 401 oder 403 Anlass, Authentifizierung und Berechtigung zu untersuchen; ein 5xx-Status lenkt die Diagnose eher auf Laufzeit, Anwendung oder einen abhängigen Dienst. Prüfen Sie die Zuordnung immer zusammen mit den Vertrags- und Debugging-Hinweisen von Microsoft.

Wie prüfen Sie Gesundheitsstatus und Anfrageprotokoll?

Behandeln Sie Bereitschaft und Geschäftsaufruf als getrennte Prüfungen. Ein Bereitschaftssignal soll zeigen, dass die Anwendung für den vorgesehenen Betrieb verfügbar ist. Es beweist nicht, dass eine Anfrage mit gültiger Identität funktioniert, eine Sitzung korrekt fortsetzt oder ein externer Dienst erreichbar ist.

Prüfen Sie deshalb zuerst, welche Bereitschafts- und Startbedingungen die aktuelle Hosted-Agent-Dokumentation für den gewählten Weg nennt. Vergleichen Sie die Anforderung mit dem Verhalten Ihres Containers: Wird ein Fehler während der Initialisierung sichtbar? Wird der Prozess erst dann als bereit betrachtet, wenn notwendige Konfiguration geladen ist? Und können Sie einen Zustand erkennen, in dem der Prozess lebt, aber keine Anfragen erfolgreich verarbeitet?

Erstellen Sie anschließend einen Testaufruf über die dokumentierte Schnittstelle. Verwenden Sie keine selbst erfundenen Pfade, Variablennamen oder Beispielwerte. Falls Sie für einen Testlauf Konfigurationswerte brauchen, tragen Sie nur Werte ein, die für Ihre eigene Umgebung freigegeben sind. So vermeiden Sie, dass ein lokaler Erfolg lediglich auf einer nicht dokumentierten Annahme beruht.

Achtung: Ein „läuft“-Signal ersetzt weder den Aufruf über den Laufzeitvertrag noch den Test mit der später eingesetzten Identität. Wenn die Bereitschaftsmeldung erfolgreich ist, der echte Aufruf aber scheitert, halten Sie beides als getrennte Befunde fest.

Veröffentlichung: Paket, Version und Status nachvollziehen

Nutzen Sie den für Ihre Anwendung passenden Weg aus der aktuellen Bereitstellungsanleitung für Hosted Agents. Die konkreten Schritte können davon abhängen, welche Veröffentlichungsoption Sie wählen. Übertragen Sie deshalb weder einen älteren Befehl noch eine SDK-Probe aus einem fremden Beispiel ohne Abgleich mit der aktuellen Anleitung auf Ihre Umgebung.

Arbeiten Sie die Veröffentlichung in einer nachvollziehbaren Reihenfolge ab:

1. Paket festlegen: Bestimmen Sie, welches geprüfte Artefakt veröffentlicht wird. Dokumentieren Sie den zugehörigen Quellstand und die verwendete Konfiguration, ohne Geheimnisse in die Versionsnotiz aufzunehmen.
2. Veröffentlichungsweg prüfen: Öffnen Sie die aktuelle Anleitung für den von Ihnen gewählten Weg. Prüfen Sie Voraussetzungen, Befehle und SDK-Aufrufe direkt in dieser Dokumentation.
3. Version erstellen: Erstellen Sie die bereitgestellte Version nach dem dokumentierten Prozess. Notieren Sie, welche Version Sie später über den Endpunkt testen.
4. Status beobachten: Warten Sie, bis der von der Plattform gemeldete Zustand für den nächsten Schritt geeignet ist. Ein Vorgang, der noch erstellt oder aktualisiert wird, ist kein Nachweis für einen abgeschlossenen Funktionstest.
5. Endpunkt aufrufen: Testen Sie den tatsächlichen Aufrufweg, nicht nur die Verwaltungsansicht. Erfassen Sie Ergebnis, Status und relevante Diagnoseinformationen.
6. Änderung abgleichen: Vergleichen Sie das Ergebnis mit dem lokalen Referenztest. Wenn sich das Verhalten unterscheidet, ordnen Sie den Fehler zuerst Paketierung, Konfiguration, Identität oder nachgelagerter Abhängigkeit zu.

Damit vermeiden Sie einen häufigen Denkfehler: Verwaltungsstatus und Anwendungsergebnis sind verschiedene Beobachtungen. Der erste zeigt den Stand des Bereitstellungsvorgangs; der zweite zeigt, ob Ihre Anwendung unter den tatsächlichen Aufrufbedingungen das erwartete Verhalten liefert.

Wo suchen Sie bei einem fehlgeschlagenen Einsatz zuerst?

Ordnen Sie den Fehler nach dem ersten Schritt ein, der nicht wie erwartet funktioniert:

• Paket oder Start: Prüfen Sie, ob das erwartete Artefakt verwendet wird und ob die Anwendung unter der Zielkonfiguration startet.
• Bereitschaft: Vergleichen Sie Initialisierung und Bereitschaftsbedingungen. Fragen Sie, ob notwendige Abhängigkeiten bereits erreichbar sind.
• Identität: Untersuchen Sie, welche Identität der jeweilige Aufruf nutzt und ob sie die benötigte Berechtigung besitzt.
• Protokoll: Vergleichen Sie Anfrage und Antwort mit dem Laufzeitvertrag. Achten Sie auf abweichende Felder, unerwartete Antwortformen und nicht abgefangene Fehler.
• Sitzungszustand: Prüfen Sie, ob der Fehler nur bei einem Folgeaufruf oder nach einem Neustart auftritt.
• Abhängiger Dienst: Kontrollieren Sie Erreichbarkeit, Fehlerantwort und Zeitverlauf des Dienstes, den der Agent aufruft.

Nutzen Sie für Laufzeitprobleme die offizielle Anleitung zum Debuggen gehosteter Agenten. Für den Betrieb hilft die Microsoft-Dokumentation zur Überwachung von Hosted-Agent-Protokollen; für die Einrichtung verteilter Agent-Traces gibt es eine Anleitung zur Agent-Beobachtbarkeit. Protokolle und Traces sind Diagnosequellen, aber kein Ersatz für einen reproduzierbaren Anfragefall.

Achten Sie bei der Erfassung auf Datenschutz und Zugriffsschutz. Protokollieren Sie keine Geheimnisse, Sitzungstokens oder unnötigen personenbezogenen Inhalte. Legen Sie intern fest, wer Diagnosedaten lesen darf und wie lange sie aufbewahrt werden. Wenn Ihr Agent personenbezogene Daten verarbeitet, beziehen Sie die für Ihr Unternehmen geltenden DSGVO-Vorgaben in die Betriebsprüfung ein.

Nach dem Go-live: Aufrufkette und erste Betriebswoche

Nach der Veröffentlichung wiederholen Sie die Tests mit der tatsächlichen Identitätskonfiguration. Prüfen Sie einen erfolgreichen Aufruf, eine absichtlich fehlerhafte Anfrage und eine Folgeanfrage in derselben Sitzung. Testen Sie außerdem einen unabhängigen neuen Kontext. So können Sie unterscheiden, ob ein Fehler vom Anfragevertrag, der Identität oder dem Umgang mit Sitzungskontext stammt.

Wie bestätigen Sie, dass der Sitzungszustand korrekt bleibt?

Definieren Sie vor dem Test, was „korrekt“ in Ihrer Anwendung bedeutet. Soll eine Folgeanfrage einen vorherigen Kontext nutzen? Muss eine neue Sitzung davon isoliert sein? Soll der Agent nach einem Neustart einen Zustand wiederherstellen oder ausdrücklich mit leerem Kontext beginnen? Die Plattformdokumentation kann Hosting und Aufruf beschreiben; die fachliche Bedeutung Ihrer Sitzungen muss Ihr Team selbst festlegen und prüfen.

Führen Sie die Folgeanfragen über denselben Weg aus, den auch Ihr Aufrufer verwendet. Vergleichen Sie die Ergebnisse mit der erwarteten Zustandsregel. Wenn Sie den Kontext in Ihrer Anwendung verwalten, prüfen Sie außerdem, ob dieser Zustand außerhalb eines flüchtigen Prozesses gespeichert werden muss. Ein Test, der nur im selben lokalen Prozess läuft, belegt nicht, dass sich eine neue Bereitstellung genauso verhält.

Checkliste für die Abnahme und die erste Woche

Nutzen Sie die folgenden Punkte als Teamprotokoll. Die Beobachtungsgrößen sind von Ihnen festzulegen; sie sind keine zugesicherten Leistungswerte von Microsoft.

• [ ] Der verwendete Laufzeitvertrag und die dazu passende aktuelle Bereitstellungsanleitung sind dokumentiert.
• [ ] Das veröffentlichte Paket lässt sich einem Quellstand und einer nachvollziehbaren Konfiguration zuordnen.
• [ ] Start, Bereitschaft und echter Aufruf werden als getrennte Prüfergebnisse erfasst.
• [ ] Eine gültige Anfrage liefert eine vom Aufrufer verarbeitbare Antwort.
• [ ] Fehlerhafte Eingaben und Fehler nachgelagerter Dienste erzeugen nachvollziehbare Fehlerbilder.
• [ ] Die konfigurierte Identität wird beim echten Endpunktaufruf verwendet; erforderliche Berechtigungen sind geprüft.
• [ ] Folgeanfragen und neue Sitzungen verhalten sich entsprechend der dokumentierten Zustandsregel.
• [ ] Das Team erfasst fehlgeschlagene Aufrufarten, Wiederholungen, Sitzungsauffälligkeiten und Versionswechsel.
• [ ] Protokolle und Traces enthalten keine unnötigen Geheimnisse oder personenbezogenen Daten.
• [ ] Für eine fehlerhafte Version ist festgelegt, wer eine Rücknahme auslöst und wie der vorherige geprüfte Stand wiederhergestellt wird.

Erweitern Sie einen Pilotbetrieb erst, wenn die Fehlerbilder verstanden und die Rücknahme getestet sind. Wenn wiederkehrende Ausfälle keiner klaren Ursache zugeordnet werden können, pausieren Sie die Ausweitung und verbessern Sie zunächst Protokollierung, Zustandsregeln oder Identitätskonfiguration. „Keine Fehler im kurzen Test“ ist kein Ersatz für eine beobachtbare Betriebsroutine.

Bevor Sie zusätzliche Laufzeitressourcen beschaffen, vergleichen Sie Ihre aktuelle Lösung mit dem tatsächlichen Bedarf. Lokale Rechner sind für dauerhafte Fernverfügbarkeit ungeeignet und lokale Abhängigkeiten erschweren reproduzierbare Tests; eine beliebige Cloud-Umgebung kann zudem macOS-spezifische Builds oder gerätenahe Prüfungen nicht automatisch ersetzen. Das macht einen Mac jedoch nicht zum Ersatz für Microsoft Foundry Hosted Agents: Für den dokumentierten Agentenbetrieb ist die Foundry-Bereitstellung weiterhin separat abzunehmen. Wenn Sie zusätzlich eine entfernte Mac-Umgebung für macOS-abhängige Entwicklungs- oder Kompatibilitätstests benötigen, können Sie sich zunächst auf der Hashvps-Übersichtsseite über die verfügbaren Informationen orientieren und anschließend die Angebotsdetails von Hashvps prüfen. Für einen allgemeinen Agenten ohne solchen Bedarf ist Mieten nicht automatisch sinnvoll; beginnen Sie mit der beschriebenen Abnahme Ihrer vorhandenen Umgebung.