Tokenkosten bei AI-Agenten senken, ohne die Qualität zu verlieren

Wenn über Tokenkosten gesprochen wird, landet die Diskussion oft sofort beim Prompt. Das ist verständlich, aber zu kurz gedacht. In produktiven Agenten entstehen Kosten durch System-Prompts, Tool-Definitionen, Gesprächshistorie, RAG-Kontext, Zwischenschritte, Retry-Logik und Ausgaben. Wer nur am Wortlaut des Prompts spart, optimiert oft den kleinsten Teil des Problems.

Für mich ist Tokenoptimierung deshalb ein Architekturthema. Die zentrale Frage lautet nicht nur: Wie formuliere ich kürzer? Sondern: Welche Information braucht das Modell wirklich, wann braucht es sie, und welches Modell muss diese Aufgabe überhaupt bearbeiten?

Ein kompakter System-Prompt ist fast immer sinnvoll. Redundante Erklärungen, doppelte Regeln und zu viele Beispiele kosten bei jedem Aufruf erneut Geld. Gerade bei wiederkehrenden Agent-Flows lohnt es sich, Instruktionen regelmäßig zu prüfen: Welche Regel wird wirklich gebraucht, welche ist nur historisch gewachsen, und welche Beispiele verbessern das Ergebnis messbar?

Gleichzeitig darf Kürze nicht gegen Steuerbarkeit ausgespielt werden. Ein zu stark komprimierter Prompt kann teurer werden, wenn das Modell dadurch mehr Rückfragen stellt, häufiger Tools falsch nutzt oder Ergebnisse stärker nachbearbeitet werden müssen. Gute Prompt-Optimierung spart Tokens, ohne Rollen, Grenzen und Qualitätskriterien unklar zu machen.

Viele Chatbots und Agenten werden teuer, weil sie zu viel Verlauf mitschleppen. Jede Nachricht, jedes Tool-Ergebnis und jeder alte Zwischenschritt landet wieder im Kontext, obwohl nur ein kleiner Teil davon noch entscheidungsrelevant ist. Sliding Windows, Trimming und laufende Zusammenfassungen sind deshalb keine Komfortfunktionen, sondern Kostenkontrolle.

Noch besser ist selektiver Kontext. Statt komplette Historien oder Dokumente mitzuschicken, sollte das System aktiv entscheiden, welche Informationen für die aktuelle Aufgabe relevant sind. Genau hier treffen sich QA-Denken und Agenten-Design: Kontext muss nachvollziehbar, ausreichend und begrenzt sein.

RAG ist für mich einer der stärksten Hebel, wenn Agenten mit Wissensbeständen arbeiten. Statt ganze Dokumente oder lange Regelwerke in den Prompt zu laden, werden nur relevante Chunks gesucht, gerankt und eingebunden. Gute Chunking-Strategie, wenig Overlap und Reranking sind dabei wichtiger als möglichst viele Treffer. Top 3 gut gewählte Chunks sind oft besser als Top 20 mittelmäßige.

Dazu kommt Caching. Statische Systemteile, wiederkehrende Tool-Kontexte oder semantisch ähnliche Standardfragen müssen nicht jedes Mal vollständig neu bezahlt werden. Und beim Model Routing gilt: Nicht jede Aufgabe braucht das stärkste Modell. Klassifikation, Vorfilterung, einfache Extraktion oder Formatierung können häufig kleinere Modelle übernehmen, während komplexe Fälle gezielt eskaliert werden.

Agenten werden besonders teuer, wenn sie in langen Tool-Schleifen hängen. Ein Tool-Call erzeugt Kontext, der nächste Call erzeugt noch mehr Kontext, und ohne Abbruchkriterien wächst der Verlauf schnell. Deshalb gehören Max-Iterations, klare Stop-Bedingungen und schlanke Tool-Definitionen direkt zum Design.

Auch Tool-Descriptions sind Teil der Tokenrechnung. Jede Beschreibung wird dem Modell mitgegeben. Kurze, präzise Tool-Beschreibungen und Deferred Tool Loading helfen, nicht bei jedem Request ein komplettes Werkzeugarsenal mitzuschleppen. Ein Agent sollte nur die Werkzeuge sehen, die für die aktuelle Aufgabe plausibel relevant sind.

Wenn ich ein produktives Chatbot- oder Agentenszenario priorisieren müsste, würde ich meist mit drei Hebeln starten: RAG statt großer Kontexte, Prompt Caching für stabile Systemteile und Model Routing für einfache Anfragen. Diese drei Maßnahmen verändern die Kostenstruktur deutlich, ohne das Produkt komplett neu zu bauen.

Danach folgen Feinschliff: kürzere Prompts, bessere Zusammenfassungen, kleinere Outputs, Response Caching und Batch-Verarbeitung für asynchrone Workloads. Wichtig ist, Kosten nicht isoliert zu optimieren. Ein günstiger Agent, der falsche Antworten liefert oder nicht nachvollziehbar arbeitet, ist kein gutes System. Ziel ist nicht minimale Tokenzahl, sondern ein belastbares Verhältnis aus Qualität, Nachvollziehbarkeit und Kosten.