Wie ein KI-Agent 94% weniger Tokens verbraucht: Vom natürlichen Sprachbefehl zur optimierten Routine

Deine Reaktion:

Ein Assistent führt jeden Morgen denselben Ablauf durch: E-Mails checken, Aufgaben priorisieren, Kalender aktualisieren, Zusammenfassung schreiben. Anfangs erklärst du ihm jeden Schritt in ausführlichen Sätzen. Nach einigen Wochen wiederholt er sich immer gleich. Wäre es nicht sinnvoll, die immergleichen Schritte als festes Programm zu hinterlegen und nur noch Ausnahmen mit dem Assistenten zu besprechen? Ein erfahrener Entwickler hat das umgesetzt und erreichte: 94 Prozent weniger Tokenverbrauch, 87 Prozent niedrigere Latenz bei gleichbleibender Qualität.

Ausgangspunkt war ein täglicher Workflow: Ein KI-Agent – der Coding-Assistent Codex – durchstöberte das Archiv eigener Blogartikel, wählte einen Beitrag aus, prüfte, ob er kürzlich erwähnt wurde, und verfasste einen LinkedIn-Post-Entwurf. Der Entwurf diente als Inspiration, wurde nie automatisch veröffentlicht. Die ursprüngliche Version war vollständig in natürlicher Sprache als Agent Skill formuliert. Der Skill beschrieb Quellen, Prüfungen, Auswahlkriterien und Textstruktur. Bei jedem Durchlauf interpretierte der Agent diese Anweisungen, erstellte einen Plan, rief Werkzeuge auf und verfolgte den Zustand. Das war gut für die erste Version – natürliche Sprache macht den Workflow verständlich und änderbar.

Sobald ein Skill oft ausgeführt wird und immer dieselben Pfade nimmt, wird sein Verhalten festgelegt. Der Workflow kristallisiert sich heraus: Der Skill sucht an denselben Stellen, erstellt dasselbe Inventar, wendet identische Filter an und speichert Zwischenzustände gleich. Das muss nicht jeden Morgen neu durchdacht werden. Vieles braucht kein großes Sprachmodell (LLM). Nur zwei Schritte benötigen ein LLM: die Auswahl eines geeigneten Kandidaten und das Verfassen des LinkedIn-Entwurfs. Alles andere kann deterministischer Code erledigen.

Der Autor kompilierte den Skill in eine spezialisierte Softwareumgebung – eine Harness. Der neue Skill besteht nur noch aus einem dünnen Bootloader, der ein Python-Programm startet. Dieses Programm ruft Quellen ab, baut das Inventar auf, prüft aktuelle Beiträge, wendet Filter an und verwaltet den Workflow. Ein LLM wird nur für Auswahl und Texterzeugung genutzt. Ergebnis: 94 Prozent weniger Tokens, 87 Prozent niedrigere Latenz bei identischer Ausgabequalität. Die Einsparungen kommen nicht von einem kleineren Modell – die LLM-Schritte nutzen dasselbe Modell. Die Einsparung entsteht, weil alle Modellaufrufe entfernt wurden, die regulärer Code direkt und effizienter ausführen kann.

Was bedeutet „Kompilieren“ hier genau?

Der Entwickler hatte historische Spuren (Traces) früherer Ausführungen des Skills – der Workflow lief täglich als Automatisierung in Codex. Diese Traces zeigten Planung, Werkzeugaufrufe, Verzweigungen und benötigten Zustand. Er gab diese Traces, den ursprünglichen Skill und seine Gedanken zu spezialisierten Harnesses einem leistungsstarken Modell. Aufgabe: Identifiziere, welche Schritte wirklich ein LLM erfordern und welche stabil genug für Code sind, und baue die spezialisierte Harness. Der natürlichsprachliche Skill diente als hochrangige Spezifikation, die Traces lieferten operative Details – das Ergebnis vorheriger Modellreasonings. Die Compiler-Analogie passt: Beginne mit einer flexiblen, hochrangigen Darstellung der Absicht. Nachdem der Workflow oft genug ausgeführt wurde, senkt man die stabilen Teile in eine effizientere Repräsentation ab. Das Modell wird weiterhin dort eingesetzt, wo es nötig ist.

Das Ziel: Workflow-Teile unterscheiden, die deterministischer Code sein können, von denen, die Sprachverständnis, Textgenerierung oder Reasoning benötigen. Es geht nicht darum, Sprachverständnis in starre Regeln zu zwängen. Die Kandidatenauswahl hängt davon ab, was die Quelle sagt und ob der Beitrag interessant wäre. Das Verfassen profitiert von Sprachgenerierung. Diese bleiben Modellaufrufe, weil sie modellgeprägte Probleme sind. Die Wertschöpfung liegt darin, das LLM nur auf kleine, wirklich intelligente Aufgaben zu konzentrieren.

Der Workflow: Erst flüssig, dann optimieren

Die spezialisierte Harness von Anfang an zu schreiben, wäre verfrüht gewesen. Der Autor kannte den genauen Workflow nicht, wusste nicht, welche Regeln wichtig sein würden oder wo Urteilsvermögen nötig wäre. Die natürlichsprachliche Version des Skills ermöglichte es, diese Dinge durch wiederholte Ausführung zu entdecken. Doch den gesamten Workflow für immer in natürlicher Sprache zu belassen, hieße, das Modell bei jedem Durchlauf denselben Plan neu finden zu lassen. Das nützliche Muster: 1. Drücke den Workflow als natürlichsprachlichen Skill aus. 2. Führe ihn oft genug aus, um Traces zu sammeln und das Verhalten zu verfeinern. 3. Finde die Teile, die stabil und deterministisch geworden sind. 4. Kompiliere diese Teile in Code. 5. Behalte LLM-Aufrufe an den wenigen Stellen, an denen semantisches Urteilsvermögen erforderlich ist.

Es gibt einmalige Kosten für diesen Kompilierungsdurchlauf. Der Autor nutzte ein leistungsstarkes Modell und viel Kontext, um Traces zu inspizieren und die neue Harness zu erstellen. Diese Kosten werden nur einmal bezahlt. Der kompilierte Workflow kann hunderte Male laufen und spart jedes Mal Tokens und Zeit. Klassische Optimierungsökonomie: einmal ausgeben, über wiederholte Nutzung amortisieren. Der Entwickler betont, dass er lokale Agenten bevorzugt, weil diese genau diese Art von Historie ansammeln: Skills, Traces, Zustände und Artefakte früherer Läufe. Diese Geschichte liefert das Rohmaterial, um die Harness selbst zu verbessern.

Die langfristige Ökonomie der Agenten

Die langfristigen Kosten von Agenten-Workflows hängen von dieser Optimierung ab. Wenn jeder wiederkehrende Workflow für immer ein Frontline-Modell als Planer, Zustandsmaschine und Klebecode verwendet, sinken Kosten und Latenz nie wirklich. Eine spezialisierte Harness erlaubt dem Modell, sich auf den kleinen Bruchteil des Workflows zu konzentrieren, der von Intelligenz profitiert. Der Autor macht einen wichtigen Punkt: Die großen Modellanbieter haben wenig Anreiz, diese Technik aktiv zu promoten. Ihr Geschäft ist der Verkauf von Tokens – möglichst viele von ihren teuersten Modellen. Es gibt einen alten Spruch: Es ist schwer, jemanden von etwas zu überzeugen, wenn sein Gehalt davon abhängt, es nicht zu verstehen. Eine Technik, die die Ausgabequalität erhält und den Tokenverbrauch um 94 Prozent senkt, läuft den wirtschaftlichen Interessen eines Unternehmens zuwider, dessen Einnahmen mit dem Tokenverbrauch steigen.

Der Autor räumt ein, dass es innerhalb dieser Firmen Leute gibt, denen Effizienz wichtig ist – bessere Inferenz, Caching und günstigere Modelle machen deren Produkte nützlicher. Aber es gibt einen Unterschied zwischen günstigeren Tokens und der Hilfe für Kunden, zu entdecken, dass die meisten ihrer Workflows überhaupt keine Tokens benötigen. Derzeit sieht er wenig Anreiz für die großen Anbieter, diese zweite Idee stark zu verfolgen. Also liegt es an Nutzern und unabhängigen Entwicklern, diese Optimierungsmöglichkeiten selbst zu finden. Das ist auch die Chance. Es gibt einen großen offenen Raum für Gründer, die spezialisierte Harnesses, Compiler und Werkzeuge bauen, die wiederkehrende Agenten-Workflows untersuchen und die deterministischen Teile in Code verschieben. Das Wertversprechen ist konkret: Behalte die Ausgabequalität bei, senke Kosten und Latenz.

Die Modellanbieter werden weiterhin leistungsstärkere Motoren bauen. Jemand muss trotzdem sicherstellen, dass wir diese Motoren nicht aufdrehen, um einfache, deterministische Arbeit zu erledigen. Der Ansatz des Autors ist einleuchtend: Nutze natürliche Sprache, um den Workflow zu entdecken. Nutze Traces, um ihn zu verstehen. Dann kompiliere, was sich verfestigt hat. Dieses Prinzip lässt sich auf unzählige alltägliche Automatisierungen anwenden – E-Mails verfassen, Daten auswerten, Projekte verwalten. Es erfordert keine neuen, teuren Modelle, sondern nur den Willen, den eigenen Workflow zu analysieren und die richtigen Grenzen zu ziehen. Wer tiefer einsteigen möchte: Der ursprüngliche Prompt für den „Token Shrinker“ steht zur Verfügung, um ihn im eigenen Agenten auszuprobieren.

Wir können unsere KI-Assistenten effizienter machen, indem wir sie nicht jede einfache Routine neu durchdenken lassen. Stattdessen geben wir ihnen ein festes Skelett für immer gleiche Abläufe und rufen sie nur, wenn echtes Denken gefragt ist. Das spart Geld, Zeit und Rechenaufwand.

Quelle: vivekhaldar.com

Deine Reaktion:
Artikel teilen:
Sebastian Krötzsch
Autor

Sebastian Krötzsch

Sebastian Krötzsch schreibt auf sebask.de über Künstliche Intelligenz, Automatisierung, digitale Systeme und die Frage, was davon im Alltag wirklich nützlich ist. Ohne Buzzword-Nebel, dafür mit klarem Blick auf Praxis, Tools und echte Wirkung.