Das Übungskonto für Mehr-Agenten-Läufe: Kosten, Obergrenzen, Aufräumen

Ein einzelner Agent beantwortet eine Frage mit einem Modellaufruf, vielleicht mit zwei oder drei Runden Werkzeugen. Das Gruppenreise-Team der Nordlicht Reisen GmbH besteht aus sieben Agenten (M-03), und planer ruft Unteragenten auf, die ihrerseits Werkzeuge aufrufen. Ein Fehler in der Steuerung, eine Schleife zwischen texter und pruefer, und aus einer Anfrage werden Dutzende Aufrufe. Diese Lektion richtet das Konto so ein, dass das in den Übungen nicht teuer wird: mit einer Obergrenze je Lauf im Code, mit Kennzeichen an jedem Aufruf und mit einem Aufräumen, das auch die neuen Dienste dieses Kurses kennt.

Vorwissen. Konto, Gruppen als Behälter einer Übung, Budget als Warnung, Anlegen von Ressource und Projekt, Kontingent prüfen sowie Soft-Delete und Purge der Foundry-Ressource lehrt „AI-103, Lektion 0.2“; sie werden hier nicht wiederholt. Dass der Monatsdeckel Code ist und das Azure-Budget nur warnt, steht dort und in „KI-Track, Lektion T10.3“. Dass ein Span die KI-Funktion trägt, zu der er gehört, zeigt „KI-Track, Lektion T10.2“. Neu ist hier die Mehrfachrechnung des Verbunds und die Kennzeichnung je Mandant.

Neu in dieser Lektion. Die Übungsgruppe heißt rg-ai500-start (M-09: rg-ai500-<umgebung> für die Umgebungen des Falls, rg-ai500-<übung> für Übungen). Für die Übungen gilt: Ein Lauf darf höchstens 20 Modellaufrufe machen (Annahme der Aufgabe). Eine mandantId hat in den Beispielen die Form m- und vier Ziffern (m-0042), eine laufId die Form lauf- und drei Ziffern; beides ist erfunden. Spätere Lektionen nutzen die Obergrenze und die Kennzeichen; keine ändert sie still.

Die Anforderung

Alle Zahlen sind Annahmen der Aufgabe.

Entscheidung 1: wie viele Aufrufe darf ein Lauf haben?

Learn sagt zu Mehr-Agenten-Abläufen, dass sie die Zahl der Modellaufrufe vervielfachen: Jeder Agent verbraucht Tokens für Anweisungen, Kontext und Werkzeugaufrufe, und bei Magentic ist der Verbrauch am schwersten vorherzusagen. Learn rät, Tokens je Agent und je Lauf zu messen und jedem Agenten ein Modell zuzuweisen, das zu seiner Aufgabe passt. Für die Obergrenze braucht es eine Rechnung am eigenen Fall:

Entscheidungsnotiz.

• Kontext: Ein Lauf aus sieben Agenten kann sich durch eine Schleife selbst vervielfachen; das Azure-Budget meldet das Stunden später, nur per Mail.
• Entscheidung: Die Obergrenze von 20 Modellaufrufen je Lauf ist ein Zähler im Code. Wird sie erreicht, bricht der Lauf ab und geht an die Reiseplanerin; er rechnet nicht weiter.
• Folgen: Ein Fehler kostet höchstens 20 Aufrufe. Die Zahl 20 ist eine Annahme und muss mit dem Testsatz (M-12) bestätigt werden.
• Alternativen: Nur das Kontingent des Deployments begrenzen: es begrenzt Tokens je Minute für ein Deployment, nicht Aufrufe je Lauf (AI-103, Lektion 0.2). Nur das Budget: warnt, stoppt nichts.

Entscheidung 2: Zähler und Kennzeichen an einer Stelle

Zähler und Kennzeichen gehören an den Chat-Client, durch den jeder Agent des Laufs spricht, nicht in jeden Agenten. Dort läuft jeder Aufruf vorbei, also kann kein Agent ihn vergessen. Der Client unten zählt mit einem gemeinsamen LaufZaehler, wirft bei Überschreitung und setzt drei Kennzeichen an den Span des Aufrufs (Telemetrie: „KI-Track, Lektion T10.2“):

public sealed class LaufZaehler(int obergrenze)
{
    private int aufrufe;
    public int Aufrufe => aufrufe;
    public int Obergrenze { get; } = obergrenze;

    public void Zaehlen()
    {
        if (Interlocked.Increment(ref aufrufe) > Obergrenze)
            throw new InvalidOperationException(
                $"Obergrenze von {Obergrenze} Modellaufrufen erreicht.");
    }
}

public sealed record LaufKontext(string MandantId, string LaufId, string Agent);

public sealed class GrenzClient(
    IChatClient inner, LaufZaehler zaehler, LaufKontext kontext)
    : DelegatingChatClient(inner)
{
    private static readonly ActivitySource Quelle = new("Nordlicht.Agenten");

    public override async Task<ChatResponse> GetResponseAsync(
        IEnumerable<ChatMessage> messages, ChatOptions? options = null,
        CancellationToken cancellationToken = default)
    {
        zaehler.Zaehlen();
        using Activity? span = Quelle.StartActivity("modellaufruf");
        span?.SetTag("mandantId", kontext.MandantId);
        span?.SetTag("laufId", kontext.LaufId);
        span?.SetTag("agent", kontext.Agent);
        return await base.GetResponseAsync(messages, options, cancellationToken);
    }
}

Drei Dinge sind Absicht. Der Zähler zählt vor dem Aufruf; der 21. geht nicht ans Modell. Interlocked hält die Zählung richtig, wenn unterkunft und transport parallel laufen (F-01). Alle Clients eines Laufs teilen einen LaufZaehler; jeder hat sein eigenes LaufKontext mit dem Namen seines Agenten. Der Streaming-Pfad fehlt im Beispiel; ein echter Client zählt dort ebenso.

Die Kennzeichen sind der Schlüssel für Lektion 3.4 (Spuren je Lauf) und 3.5 (Kosten je Mandant): Eine Spur ohne mandantId lässt sich keiner Kundin zuordnen, und eine Rückbelastung ohne Zuordnung gibt es nicht. Hier genügt, dass die Kennzeichen von Anfang an gesetzt werden.

Entscheidung 3: Kosten und Aufräumen der neuen Dienste

Die Übungen dieses Kurses brauchen mehr Dienste als AI-103. Das Aufräumen bleibt eine Gruppe je Übung; neu sind die Kostentreiber und eine zweite Sperre für Namen. Alle Angaben ohne Beträge; Preise stehen auf den Preisseiten der Dienste:

Zu API Management sagt Learn: Eine gelöschte Instanz wird weich gelöscht, ihr Name ist dann gesperrt, nach 48 Stunden wird sie endgültig gelöscht. Purgen geht mit az apim deletedservice purge --location <region> --service-name <name> und braucht Rechte auf Abonnementebene. Die Übungen nehmen für API Management einen Namen mit Übungssuffix.

Das Konto aus AI-103, Lektion 0.2 trägt den Rest: Ihre Gruppe rg-ai500-start entsteht mit demselben Skript, wenn Sie vier Dinge ändern: die Gruppe, das Projekt (gruppenreisen statt reiseassistent, M-09), die Markierung kurs=ai500 und, falls die Foundry-Ressource ai-nordlicht aus AI-103 noch weich gelöscht steht, einen anderen Namen oder deren Purge. Mit -WhatIf prüfen Sie es zuerst, wie dort.

Stand der Prüfung

Der Code oben wurde in einem Wegwerfprojekt mit Microsoft.Extensions.AI 10.0.0 auf .NET 10 übersetzt und lokal ausgeführt (mit einem Fake-Client). Das beweist Syntax, Typen und die Logik des Zählers, nicht das Verhalten eines Modells. Nichts lief gegen Azure; die Aussagen zu API Management und Cosmos DB sind nach Learn gelesen, nicht ausgeführt. Offen: ob das Löschen der Gruppe API Management ebenfalls weich löscht (Learn nennt Portal und REST-Schnittstelle); welche Stufen von API Management genügen (Lektion 2.7).

var zaehler = new LaufZaehler(obergrenze: 2);
var kontext = new LaufKontext("m-0042", "lauf-001", "planer");
IChatClient client = new GrenzClient(new FakeClient(), zaehler, kontext);

for (int i = 0; i < 3; i++)
{
    try
    {
        await client.GetResponseAsync("Hallo");
        Console.WriteLine($"Aufruf {i + 1} ok, Zähler {zaehler.Aufrufe}");
    }
    catch (InvalidOperationException e)
    {
        Console.WriteLine(e.Message);
    }
}

Typische Denkfehler

• „Das Budget in Azure schützt mich vor Schleifen.“ Es warnt Stunden später und stoppt nichts; der Zähler im Code stoppt vor dem Aufruf.
• „Das Kontingent des Deployments begrenzt den Lauf.“ Es begrenzt Tokens je Minute für ein Deployment, nicht die Aufrufe eines Laufs.
• „Kennzeichen lassen sich später nachrüsten.“ Aufrufe ohne mandantId lassen sich nachträglich keiner Kundin zuordnen.
• „Gruppe gelöscht, Name frei.“ Foundry und API Management halten Namen nach dem Löschen eine Zeit lang gesperrt.

Weiterlesen

• https://learn.microsoft.com/azure/architecture/ai-ml/guide/ai-agent-design-patterns
• https://learn.microsoft.com/azure/api-management/soft-delete
• https://learn.microsoft.com/azure/ai-services/recover-purge-resources
• https://learn.microsoft.com/azure/cosmos-db/soft-delete