In dem Moment, in dem eine Anwendung anfängt, Tools aufzurufen, hört die Ausgabe des Modells auf, Text zum Lesen zu sein, und wird zu einer Anweisung zu handeln, und jede Garantie, die diese Serie bisher gebaut hat, drehte sich um Tokens. Ein Framework kann diese Schleife leicht schreibbar machen und im selben Zug das Throttling verstecken, am Routing des Gateways vorbeisteuern und aus einem gemessenen Request elf machen, die niemand eingeplant hat. Teil 7 hat den Anwendungen Retrieval gegeben. In diesem Teil geht es um das, was darauf sitzt, und konkret darum, welche Aufgaben das Framework nicht übernehmen sollte, weil die Plattform sie bereits erledigt.

Das Framework auf das Gateway richten, und dort aufhören

Die Mechanik ist trivial, und genau deshalb muss die Disziplin explizit sein. Ein Orchestrierungs-Framework spricht das OpenAI-Chat-Completions-Format, das Gateway exponiert genau das, also besteht die Integration aus einer Base URL und einem Credential:

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
    base_url="https://apim-genai-prod.azure-api.net/llm/v1",
    api_key=gateway_token,        # Entra ID token, not a model key
    model="chat-default",         # gateway alias, never a deployment name
    max_retries=0,                # the gateway owns retry and failover
    timeout=60,
)

max_retries=0 ist die Zeile, auf die es ankommt, und es ist die, die Leute zuerst löschen. Frameworks liefern client-seitigen Retry, exponentielles Backoff und oft Provider-Fallback als Standard aus, alles vernünftige Defaults für eine Anwendung, die direkt mit einem Modellanbieter spricht, und alles aktiv schädlich vor einem Gateway, das Routing, Load Balancing und Circuit Breaking bereits übernimmt.

Man betrachte, was client-seitiger Retry mit dem circuit breaker aus Teil 3 macht. Der Breaker löst aus und liefert 503 genau deshalb, damit Aufrufer aufhören, auf ein ausfallendes Backend einzuhämmern. Ein Framework, das konfiguriert ist, eine 503 fünfmal mit Backoff zu wiederholen, verwandelt dieses Signal in die fünffache Last, die genau dann eintrifft, wenn das Backend sie am wenigsten tragen kann. Dasselbe gilt für 429: Ein Token-Limit existiert, um Nachfrage zu formen, und ein Client, der sich durch das Limit hindurch wiederholt, wird nicht geformt. Retries gehören an eine Stelle, und diese Stelle existiert bereits.

Das ehrliche Gegenstück: Ein einzelner Retry bei einem Fehler auf Verbindungsebene, im Client, ist in Ordnung. Die Regel handelt vom Wiederholen der eigenen Antworten des Gateways, nicht von Netzwerk-Flakiness.

Was das Framework weiterhin tun sollte

Nachdem Provider-Abstraktion, Routing, Retry und Fallback aus seiner Stellenbeschreibung gestrichen sind, bleiben einem Framework die Teile, die von Hand tatsächlich mühsam zu bauen sind und kein Plattform-Anliegen berühren: Prompt-Templating mit typisierten Inputs, Tool-Schema-Generierung aus Funktionssignaturen, Output-Parsing in strukturierte Typen und die Buchführung der Schleife, die aus einem Tool Call eine Folgenachricht macht. Das ist echte Arbeit und ein vernünftiger Grund, die Dependency zu nehmen.

Was es nicht werden sollte, ist der Ort, an dem die Modellwahl lebt. Der Alias im Code oben ist ein Gateway-Alias, aufgelöst vom Modellkatalog aus Teil 2. Ein eigenes Modellregister des Frameworks, eigene Fallback-Ketten, eine eigene Provider-Liste, all das ist ein zweiter Katalog, der dem ersten an dem Tag widersprechen wird, an dem ein Modell abgekündigt wird.

Tools sind die zweite Fläche, und sie können die erste Tür teilen

Die Tools eines Agents verdienen dieselbe Behandlung wie seine Modelle: ein kontrollierter Eintrittspunkt, Zugriff pro Tenant, ein Audit Trail. API Management kann eine REST API, die es bereits verwaltet, als remote MCP server exponieren und ausgewählte Operationen als Tools publizieren, die MCP-Clients aufrufen, verfügbar in den Tiers Developer, Basic, Standard und Premium einschließlich ihrer v2-Varianten. Diesen MCP server mit einem product zu verknüpfen heißt, dass Tool-Zugriff über dieselben products und subscriptions verwaltet wird wie Modell-Zugriff, und genau das ist der Punkt: eine Identität, eine Quota-Geschichte, eine Stelle zum Widerrufen.

Zwei Einschränkungen entscheiden, wie weit das heute trägt. API Management unterstützt MCP server tools, aber keine MCP resources oder prompts für Server, die aus verwalteten REST APIs exponiert werden. Und MCP-server-Fähigkeiten werden in workspaces nicht unterstützt, was genau für die isolierten Teams zählt, die Teil 5 auf workspaces verwiesen hat. Ein Team, das sowohl ein Workspace-Gateway als auch MCP-Tool-Publishing braucht, muss sich für eines entscheiden, und das lernt man besser, während man die Architektur zeichnet.

Content safety auf dem Prompt-Pfad

Eine agent loop verbreitert die Eingabefläche: abgerufene Dokumente, Tool-Outputs und Nutzertext landen alle in einem Prompt. Die llm-content-safety-Policy leitet Inhalte an Azure AI Content Safety, bevor das Modell sie sieht.

<llm-content-safety backend-id="content-safety-backend" shield-prompt="true">
  <categories output-type="EightSeverityLevels">
    <category name="Hate" threshold="4" />
    <category name="Violence" threshold="4" />
  </categories>
</llm-content-safety>

Drei Attribute wollen sorgfältig gelesen statt kopiert werden. Der threshold funktioniert wie eine Toleranz, nicht wie ein Limit: Mit threshold="4" lässt der Filter Severity 0 bis 3 durch und blockiert 4 bis 7, das Erhöhen der Zahl erhöht also die Toleranz und blockiert weniger. Es ist dieselbe Umkehrung wie beim Score-threshold des Caches in Teil 6, und sie erwischt Leute auf dieselbe Weise.

shield-prompt="true" schaltet die Prüfung auf adversariale Nutzerangriffe ein und steht per Default auf false. Für einen Agent, der abgerufene Dokumente in seinen Kontext konkateniert, ist dieser Default der falsche: Prompt Injection, die über ein Dokument ankommt, ist die realistische Bedrohung, nicht ein Nutzer, der einen Angriff in eine Chatbox tippt.

enforce-on-completions, per Default ebenfalls false, dehnt die Prüfung auf die Antworten des Modells aus, wenn die Policy in inbound sitzt. Und window-size, das auf das 10.000-Zeichen-Limit von Content Safety defaulted, ist nur für Responses konfigurierbar; für Requests gilt immer das Default-Fenster. Ein sehr langer abgerufener Kontext wird also von genau dem Windowing bewertet, das man nicht kontrolliert, was ein Argument dafür ist, Retrieval-Ergebnisse begrenzt zu halten, statt darauf zu vertrauen, dass der Filter mit ihnen skaliert.

Was eine Loop mit jeder Zahl aus Teil 5 macht

Eine einzelne Nutzerfrage, die vier Tool Calls auslöst, ist nicht ein Request, sondern fünf Modellaufrufe, von denen jeder das wachsende Transkript erneut sendet. Drei Konsequenzen für die Plattform:

  • Die Quota pro Minute handelt nicht mehr vom Nutzervolumen. Sie wird zu Nutzervolumen multipliziert mit der durchschnittlichen Loop-Tiefe, und Loop-Tiefe ist eine Eigenschaft des Prompts der Anwendung, die sich ohne Plattform-Review ändert.
  • Eine außer Kontrolle geratene Loop ist von Last nicht zu unterscheiden. Das Gateway sieht wohlgeformte Requests innerhalb der Quota. Die Anwendung muss ihre eigenen Iterationen begrenzen, und die Plattform sollte das als Anforderung publizieren, statt es stillschweigend anzunehmen.
  • Chargeback braucht eine correlation ID pro Nutzerinteraktion, nicht pro Request, sonst sind die Zahlen pro Team wahr und nutzlos. Diese ID gehört in den Log-Record, wo Teil 5 hochkardinale Daten genau aus diesem Grund abgelegt hat.

Eine Token-Obergrenze pro Request am Gateway ist ein nützlicher Backstop und kein Ersatz. Sie deckelt den Schaden eines einzelnen riesigen Aufrufs; gegen eine Loop, die zweihundert kleine macht, richtet sie nichts aus.

Fehlerbilder, die man im Blick behalten sollte

  • Framework-Retry, der den circuit breaker aushebelt. Der Default ist an. Bewusst abschalten und das Warum dokumentieren, sonst wird der Schutzmechanismus der Plattform zum Lastverstärker.
  • Ein zweiter Modellkatalog im Framework. Er wird dem des Gateways am Abkündigungstag widersprechen, und die Anwendung hängt dann an einem Deployment-Namen, von dem niemand wusste, dass sie ihn hat.
  • Content-safety-threshold als Limit gelesen. Höher ist permissiver. Ein Team, das False Positives wegtuned, kann den Filter praktisch abschalten und dabei glauben, es habe ihn verschärft.
  • shield-prompt auf seinem Default belassen. Aus. Bei einem Agent, der abgerufene Dokumente einliest, ist das der offen gelassene Injection-Pfad.
  • Unbegrenzte Loops. Keine Gateway-Policy kann "nach sechs Iterationen aufhören" ausdrücken. Nur die Anwendung kann das, also ist es ein Vertrag, kein Control.
  • MCP plus workspaces. Heute zusammen nicht unterstützt. Das zu entdecken, nachdem man einem Team beides versprochen hat, ist ein Architektur-Rollback.

Was Teil 9 erbt

Anwendungen mit Orchestrierung, Tools, die über dasselbe Gateway publiziert werden, und content safety im Request-Pfad. All das konfiguriert in Policy-XML, Alias-Mappings und Product-Definitionen, die Produktion derzeit auf demselben Weg erreichen wie jede andere Änderung, und genau dieser Teil wurde noch nicht untersucht. Als Nächstes: Azure DevOps, und was es heißt, eine Modellversionsänderung hinter eine Evaluation zu stellen statt hinter einen Review-Kommentar.

Weiterlesen

Für die Infrastruktur- und Plattform-Seite, so etwas in diesem Maßstab zu betreiben, gibt es die Field Notes auf ercan.cloud, und der Hub liegt auf ercanermis.com.

Referenzen