Der Einsatz von AWS-KI-Agenten in großem Maßstab: Tokens, Ausgaben, Grenzen und Autonomie

Ein Agent, der sinnvoll strukturiert ist und durch Validierung sowie Abrufmechanismen gestützt wird, muss dennoch seinen ersten Monat in der Produktion überstehen. Was darüber entscheidet, ist meistens nicht besonders spektakulär: wie Sie Token zählen, wie Sie die Ausgaben überwachen, was passiert, wenn das Kontextfenster voll wird, und ob ein langlaufender autonomer Loop wie ein echter Workflow-Engine aufgebaut ist. Wenn Sie aus der Welt des vollständigen JavaScript-Entwickelns auf AWS kommen, entspricht jeder dieser Aspekte etwas, das Sie bereits kennen, und dieser Leitfaden nutzt diese Parallelen durchgehend.

Tokenisierung ist die Serialisierungsstufe

Eine Webanwendung serialisiert Daten, bevor sie über das Netzwerk gesendet werden, mit JSON.stringify oder protobuf. Ein Sprachmodell erledigt etwas Ähnliches mit Texten: Bevor es irgendetwas sieht, wird der Text in Token aufgeteilt, also in Sub-Wort-Fragmente – nicht in Zeichen oder ganze Wörter.

"Enterprise agents scale."
   → ["Enterprise", " agents", " scale", "."]   (≈4 tokens, illustrative)

Der Grund, warum es als Ingenieur wichtig ist, konzentriert sich auf drei Punkte.

• Tokens sind das, nach dem abgerechnet wird – vergleichbar mit den GB-Sekunden bei Lambda. Sowohl Eingabe als auch Ausgabe kosten Geld, und da die Preise von Bedrock je nach Modell unterschiedlich sind, bestimmt die Anzahl der Tokens direkt die AWS-Rechnung.
• Tokens legen außerdem die Obergrenze für den Payload fest, ähnlich wie eine Begrenzung für den Request-Body wie express.json({ limit: '5mb' }). In diesem Fall ist die Obergrenze das Kontextfenster, das bei aktuellen Modellen in Hunderttausende von Tokens ausmacht und weiter wächst – prüfen Sie daher die tatsächliche Grenze für Ihr Modell und raten Sie nicht.
• Die Tokenisierung ist in verschiedenen Sprachen nicht einheitlich. Nicht-englische Texte benötigen häufig mehr Tokens pro Wort, was für Produkte in mehreren Regionen von Bedeutung ist.

In Node.js fühlt sich das Zählen vor dem Senden an wie das Messen des Payloads vor einem Fetch-Aufruf:

// Node.js: counting tokens before sending a request
// (conceptually like calculating payload size before a fetch call)
import { encoding_for_model } from "tiktoken";

const enc = encoding_for_model("gpt-4o");
const tokens = enc.encode(userPrompt);
console.log(`Payload size: ${tokens.length} tokens`); // like Content-Length
enc.free();

Auf Bedrock können Sie den Tokenisierer von Drittanbietern überspringen. Die CountTokens-API zählt auf Serverseite für unterstützte Claude-Modelle, verwendet dieselbe Nachrichtenstruktur wie die Converse-API und ermöglicht es Ihnen, die Tokenanzahl einer Anfrage im Voraus zu überprüfen, ohne für die Verarbeitung bezahlen zu müssen:

# Python (boto3): pre-flight token count via Bedrock, no separate tokenizer library needed
response = bedrock_runtime.count_tokens(
    modelId="anthropic.claude-3-5-sonnet-20241022-v2:0",
    input={"converse": {"messages": [{"role": "user", "content": [{"text": userPrompt}]}]}}
)
print(f"Input tokens: {response['inputTokens']}")

Die Lektion: Messen Sie die Anzahl der Tokens genauso wie die Größe des HTTP-Payloads, bevor Sie senden – und nicht erst nachdem Sie abgerechnet oder abgelehnt wurden.

Tokenverbrauch überwachen wie CloudWatch für LLM-Abrechnungen

Der vorherige Abschnitt behandelte eine einzelne Anfrage. Der zusammenfassende Überblick zeigt, wie viel jeder Agent pro Mieter und pro Tag verbraucht hat – und Sie möchten das bereits vor der Finanzabteilung herausfinden. Niemand würde eine Express-API auf AWS ohne Dashboards und Alarme live schalten, und die Überwachung von Tokens verdient denselben Ansatz.

Die wichtigsten Indikatoren für einen Agenten:

• Prompt-Tokens pro Anfrage, ähnlich wie die Größe des eingehenden Payloads.
• Vollendungs-Tokens pro Anfrage, ähnlich wie die Größe der Antwort.
• Kumulierte Tokens in einer Sitzung, was dem Speicherverbrauch der Sitzung entspricht.
• Kosten pro Agent, Benutzer oder Mieter – dieselbe Messung wie bei der Datenbanknutzung pro Mieter in multi-tenant SaaS-Lösungen.

Die Latenz von Agentenaufrufen bei p95 und p99 muss den üblichen SLOs entsprechen. Geben Sie die SLOs ausdrücklich an und weichen Sie bei Gefahr auf einen gepufferten oder best-effort-Path aus.

Ausgabenrate in Tokens pro Minute, vergleichbar mit der Rate-Limiting-Regelung für Anfragen pro Sekunde.

Konkrete Schritte auf AWS:

• Senden Sie benutzerdefinierte CloudWatch-Metriken für Prompt-Token, Completion-Token und den Dollarpreis (prompt_tokens, completion_tokens, cost_usd), versehen mit dem Namen des Agents und des Tenants.
• Aktivieren Sie das Prompt-Caching. Bedrock kann lange, stabile Präfixe wie System-Prompts, Tool-Definitionen und Few-Shot-Beispiele zu einem erheblich geringeren Preis und mit niedrigerer Latenz wiederverwenden. Platzieren Sie unveränderlichen Inhalt zuerst, andernfalls zahlen Sie den vollen Preis für identische Tokens bei jedem Aufruf.
• Erstellen Sie CloudWatch-Alarms, die über SNS benachrichtigen, wenn die täglichen Ausgaben einen Schwellenwert überschreiten – genauso wie die AWS-Billing-Alarms.
• Schreiben Sie jeden Aufruf des Agents in S3, entweder über Kinesis Firehose oder direkt, um einen Audit-Trail zu erhalten. SOC 2 sowie Unternehmenskunden werden dies verlangen.
• Eine grobe Schätzung funktioniert genauso wie bei Lambda: Fügen Sie Prompt- und Completion-Tokens hinzu, multiplizieren Sie mit dem Preis des Modells und addieren Sie anschließend die Kosten für Abruf und Infrastruktur pro Sitzung.

Falls Sie nicht angeben können, wie viel Agent X letzten Dienstag pro Kunde gekostet hat, sind Sie zwar für Demonstrationen bereit, aber noch nicht für die Produktion – und das ist ein großer Unterschied.

Fehler aufgrund von Kontextbegrenzungen: Circuit Breaker plus Paginierung

Jedes Kontextfenster hat eine Obergrenze. Lange Gespräche, umfangreiche Tool-Ausgaben sowie übermäßig große Abrufblöcke können diese überschreiten. Es handelt sich dabei um das 413 Payload Too Large der Agentenwelt – nur schlimmer, da es mitten in einer mehrschrittigen Aufgabe auftreten kann.

Rehabilitationsstrategien stammen direkt aus der Backend-Entwicklung:

1. Zusammenfassung und Komprimierung. Alte Nachrichtenperiodisch komprimieren, ähnlich wie bei der Log-Rotation.
2. Schiebefenster- oder Trunkierungsverfahren. Die ältesten Nachrichten entfernen, so wie man bei großen Abfrageresultaten nicht alles lädt, sondern nacheinander durchsieht.
3. Auslagerung an das Abrufsystem. Material außerhalb der Anweisung speichern und auf Nachfrage abrufen, im Sinne des „Lazy Loading“.
4. Aufteilung in Unteragenten. Eine riesige Aufgabe in kleinere Aufträge mit frischen Kontexten aufteilen, ähnlich wie man eine monolithische Batch-Aufgabe in eine Reihe kleinerer Aufgaben umwandelt.

Sanft abbrechen. Wenn der Überlauf während einer Aufgabe nicht behoben werden kann, soll ein strukturierter, wiederaufnahmefähiger Checkpoint ausgelöst werden – niemals eine stille Halluzination.

Hier ist das Muster zur Abfangung und Komprimierung im Code, ähnlich wie bei der Abfangung eines Datenbank-Timeouts:

# Conceptual: catching a context-limit error, like catching a DB timeout
try:
    result = agent.run(task, conversation_history)
except AgentError as err:
    if err.code == "context_length_exceeded":
        # Keep the system prompt intact — compact the *conversation*, never the identity.
        # Summarizing everything (including system instructions) is how agents quietly
        # "forget" their role mid-task, the same way you'd never let a cache-eviction
        # policy drop your app's config alongside its session data.
        compacted = summarize(conversation_history, preserve="system_prompt")
        result = agent.run(task, compacted)
    else:
        raise  # don't swallow unrelated errors

Fehler aufgrund von Kontextbegrenzungen sind zu erwarten und keine Ausnahme. Behandeln Sie sie wie Bandbreitenbeschränkungen und Zeitüberschreitungen: Wiederholte Versuche mit Pufferzeiten, Kontrollpunkte in DynamoDB sowie eine fehlerfreie Abschaltung. Ein leeres catch-Blöck, der den Fehler einfach verschluckt, ist niemals akzeptabel.

Autonome Workflows als Zustandsmaschinen

Ein autonomer Agent antwortet nicht einmalig. Er plant, handelt, beobachtet und wiederholt den Prozess, bis ein Ziel erreicht ist. Jeder, der bereits eine XState-Maschine, eine Redux-Saga oder einen AWS Step Functions-Flow für einen mehrstufigen Bestellvorgang entwickelt hat, kennt diese Struktur. Es handelt sich um den bekannten ReAct-Style-Loop aus Planen, Handeln, Beobachten und Evaluieren, mit Ausgängen für die Abschlussabwicklung sowie für die Eskalation an einen Menschen – und er sollte wie ein widerstandsfähiger Workflow-Engine konzipiert werden.

• Idempotente Schritte. Das erneute Ausführen eines Schritts darf den Kunden nicht zweimal belasten oder eine doppelte E-Mail senden.

Klare Stoppsbedingungen. Begrenzen Sie die Anzahl der Iterationen sowie Kosten und Zeit – oder vermeiden Sie es, einen endlosen while(true)-Schleifenzyklus mit einer Kreditkarte zu erstellen.

Menschliche Überprüfung. Genau wie bei kompensierenden Transaktionen in einer Saga sollten Fälle mit geringem Vertrauensgrad oder hohen Risiken an einen Menschen weitergeleitet werden und nicht automatisch ausgeführt werden.

Persistenter Zustand. Erstellen Sie für jeden Schritt im DynamoDB- oder Step Functions-Zustand Checkpoints, damit ein Absturz während des Workflows fortgesetzt werden kann, ohne dass eine Transaktion verloren geht. Fügen Sie zu Session-Elementen ein DynamoDB-TTL hinzu, damit veraltete Gespräche ablaufen – genauso wie bei der Ablaufzeit von Redis-Session-Schlüsseln.

Fallback-Modelle. Wenn das primäre Modell, beispielsweise Claude auf Bedrock, die Zeitüberschreitung erreicht oder eingeschränkt wird, sollte ein Circuit Breaker auf ein sekundäres Modell wie Amazon Nova umschalten, ohne dem Benutzer einen Fehler anzuzeigen. Es handelt sich dabei um denselben Ansatz wie bei einem HTTP-Client, der auf eine Backup-Region umsteigt.

Modellverwaltung. Der Wechsel eines Modells sollte wie jede Produktivbereitstellung behandelt werden: Es sollte zunächst an einem Teil des Verkehrs getestet werden, eine Freigabe erforderlich sein und es muss ein Weg zum Zurücksetzen vorhanden sein. „Wir haben einfach das Modell geändert“ sollte keine ungeprüfte Änderung darstellen.

Aus-Schalter. Es muss eine Möglichkeit geben – sei es manuell oder durch einen Schwellenwert –, die gesamte Agentenflotte auf einmal anzuhalten, ähnlich wie ein Feature-Flag-Aus-Schalter bei einer unkontrollierten Veröffentlichung.

Ein Checkpoint ist lediglich ein weiteres Aufnahmeprotokoll für wiederholbare Aufgaben in DynamoDB, das von Step Functions beim Neustart gelesen wird, um dort fortzufahren, wo die letzte erfolgreiche Schritt war:

{
  "pk": "session#8f2c1a",
  "sk": "checkpoint#2026-08-23T10:15:00Z",
  "step": "plan",
  "hop_count": 2,
  "cost_so_far_usd": 0.014,
  "state": { "goal": "resolve billing dispute", "last_action": "lookup_charge" },
  "ttl": 1788084900
}

Bauen Sie Autonomie nicht als while-Schleife um einen Aufruf einer LLM-Engine auf. Entwickeln Sie stattdessen eine widerstandsfähige, beobachtbare und wiederaufnahmefähige Zustandsmaschine – das ist schließlich ihre wahre Natur. Step Functions erfüllt diesen Anforderungen hervorragend, falls Sie eine fertige Lösung wünschen.

Oben auf all dem liegt noch eine weitere Schicht: die Bewertungen. Regeln zur Einhaltung von Standards, Qualität der Informationsbeschaffung sowie die Verankerung in realen Daten erfordern genauso wie der Anwendungscode Regressionstests. Ein Bewertungssatz führt eine feste Reihe von Eingaben gegen den Agenten durch und bewertet die Ausgaben anhand des erwarteten Verhaltens, sodass kleine Anpassungen an den Prompts oder das Wechseln des Modells nicht heimlich die Produktivität beeinträchtigen können. Ragas bewertet spezifische Kriterien der Informationsbeschaffung wie Treue und Kontextrelevanz, während Promptfoo und Braintrust umfassendere Tests für Prompts und Ausgaben durchführen. Integrieren Sie Ihre Wahl in den CI-Prozess genauso wie pytest, damit fehlgeschlagene Bewertungen den Deployment-Prozess blockieren und niemand anschließend manuell die Ausgaben überprüfen muss.

Checkliste für die Produktionsbereitschaft

• Jeder Agent hat eine überprüfbare Verantwortung sowie eng gefasste IAM-Berechtigungen.
• Die Übertragung von Daten erfolgt über einen dauerhaften Bus (SQS oder EventBridge) mit strukturiertem Kontext und ist vor Schleifen geschützt.
• Eingabesicherungen und Ausgabesicherungen sind getrennt, komponierbar und werden eigenständig versioniert.
• Die Qualität der Datenabrufung wird durch eigene Messgrößen für Präzision und Vollständigkeit bewertet und nicht einfach unter „die KI liegt falsch“ zusammengefasst.
• Alles, was von großer Bedeutung ist, durchläuft Halluzinationstests: Grundierung, Zuverlässigkeitsbewertung oder menschliche Überprüfung.
• Der Tokenverbrauch wird vor dem Senden einer Anfrage gemessen, nicht erst danach abgerechnet.
• CloudWatch-Dashboards zeigen die Kosten pro Mieter und pro Agent auf, mit SNS-Budgetwarnungen.
• Es existiert ein definiertes Wiederherstellungsplan für Fehler aufgrund von Kontextbeschränkungen: Komprimieren, kürzen oder Aufladen an einen anderen Ort.

Autonome Schleifen haben feste Obergrenzen für Anzahl der Iterationen, verstrichene Zeit und Aufwand.

Unerückgängige Aktionen wie Rückerstattungen, E-Mails und Löschungen erfordern eine menschliche Freigabestufe.

Die Entscheidungen der Agenten werden zur Einhaltung der Vorschriften vollständig in S3 oder CloudWatch aufgezeichnet.

Automatisierte Bewertungen werden im CI durchgeführt, bevor jegliche Änderung an Prompts oder Modellen veröffentlicht wird – ein Schritt, den man bei Anwendungscode niemals überspringen würde.

Die Staging-Umgebung wurde mit simulierten Modelltimouten, beschädigten Suchergebnissen und Übertragungsschleifen auf Stabilität getestet, sodass die Wiederherstellungswege vor dem Einsatz in der Produktion bereits überprüft sind.

Was das insgesamt bedeutet

Jedes Agentenkonzept hat einen Gegenpart in der Welt der Full-Stack-Technologien, die Ihnen bekannt sind. Agenten sind mikroservicebasierte Einheiten mit Entscheidungsfähigkeit, und die Übertragungen erfolgen über langlebige, nachvollziehbare Routing-Verfahren mit begrenzter Anzahl an Schritten. Schutzmechanismen bestehen aus mehrschichtigem Middleware-Code, die Datenerfassung erfolgt über eine intelligentere Abfrageschicht, und Halluzinationen werden durch Verifizierung und Grundlegung erkannt – nicht einfach nur durch höfliche Anfragen. Tokens dienen gleichzeitig als Maß für die Größe der übertragenen Daten und als Zahlungseinheit. Die Überwachung von Ausgaben entspricht dem CloudWatch-System für die Nutzung von Modellen. Ein vollständiges Kontextfenster stellt ein vorhersehbares Versagen dar, das einen Wiederherstellungsplan erfordert, während Autonomie eine langlebige Zustandsmaschine ist – ganz anders als ein einfacher while-Schleifen.

Enterprise-Agenten versagen in der Produktion selten wegen mangelnder Intelligenz des Modells. Sie versagen vielmehr, weil Teams die grundlegenden Disziplinen von verteilten Systemen außer Acht lassen – Disziplinen, die sie bei einer gewöhnlichen API niemals vernachlässigen würden: Validierung, Beobachtbarkeit, Wiederholungsversuche, Idempotenz sowie ein stabiles Funktionieren bei Störungen. Wenn Sie bereits eine widerstandsfähige JavaScript-Anwendung auf AWS veröffentlicht haben, besitzen Sie bereits die notwendigen Instinkte. Übrig bleibt nur noch, diese Instinkte auf eine unbekannte, unvorhersehbare Abhängigkeit anzuwenden, die in Form von Sätzen antwortet.