💳 Flow-Tokens – Warum Token-Optimierung ein Flow-Problem und kein Vokabularproblem ist
vom 21. Juni 2026
Der Aufstieg von KI-Agenten hat ein Thema wieder in den Mittelpunkt vieler Softwarearchitekturen gerückt: die Kosten des Kontextes.
Wenn ein Agent einen Workflow ausführt, verbraucht er nicht nur eine Benutzereingabe, sondern auch eine große Menge an Zusatzdaten:
- Ausführungsprotokolle
- CLI-Befehlsausgaben
- Werkzeugergebnisse
- Debugging-Traces
- Brocken aus RAG
- Roh- oder halbstrukturierte Dateien
In der Praxis stellt dieser Kontext oft den größten Kostenfaktor im Arbeitsablauf dar, und zwar weit vor der eigentlichen Berechnungsphase des Modells.
Die Frage lautet dann:
Wie können wir den Tokenverbrauch reduzieren, ohne die Qualität des an das Modell übertragenen Signals zu beeinträchtigen?
Eine gängige Intuition ist es, den Wortschatz zu optimieren: Wörter zu verkürzen, bestimmte Geschäftsbegriffe abzukürzen, Texte künstlich zu verdichten.
Diese Intuition ist meistens falsch.
Tokenoptimierung ist kein lexikalisches Problem.
Es handelt sich um ein Durchflussproblem.
Das eigentliche Problem: ein unkontrollierter Kontext
In vielen Systemen gelangen die Daten in Form einer riesigen Zeichenkette in die KI-Kette.
Nehmen wir ein klassisches Beispiel.
Ein Agent muss das Ergebnis eines Symfony- oder Composer-Befehls analysieren.
Die Ausgabe kann Folgendes enthalten:
- sich wiederholende Debug-Zeilen
- Zeitstempel
- ANSI-Sequenzen
- Stacktraces
- Fortschrittslinien
- wirklich nützliche Informationen
Für den Menschen ist die Unterscheidung zwischen Rauschen und Signal unmittelbar.
Für ein LLM-Studium ist anfänglich alles gleichwertig.
Jeder Charakter kann zu einem Spielstein werden.
Jeder Token hat einen Preis.
Jeder Kostenfaktor beansprucht einen Teil des Kontextfensters.
Das Problem ist daher nicht nur die Größe des Textes.
Das Problem ist die fehlende Struktur im Datenfluss.
Tokenoptimierung ist Stream-Disziplin
Die These dieses Artikels ist einfach:
Tokenoptimierung ist nicht Wortverkürzung.
Tokenoptimierung ist Stream-Disziplin.
Mit anderen Worten:
Entscheidend ist nicht die Rechtschreibung der Wörter, sondern wie die Daten durch das System fließen.
Eine flussorientierte Architektur ermöglicht Folgendes:
- Daten bereinigen
- die Daten segmentieren
- ihre Kosten messen
- Die Wiederholungen komprimieren
- ein explizites Budget anwenden
Dieser Perspektivwechsel ist wichtig.
Wir versuchen nicht länger, Wörter zu komprimieren.
Wir versuchen, einen Fluss zu steuern.
Flow als Orchestrierungsmodell
Genau diesen Aspekt untersucht Flow.
Flow ist nicht nur eine Engine zur Ausführung von Aufgaben.
Flow kann als eine Ebene zur Orchestrierung des Datenflusses betrachtet werden.
Daten können zirkulieren:
- wie eine Pfeife
- wie ein Bach
- wie Brocken
- als messbarer Kontext
- wie beispielsweise ein budgetierter Kontext
Dieses Modell ist besonders interessant für agentenbasierte Workflows, da ein Agent selten stark typisierte Geschäftsobjekte verwendet.
Es verarbeitet hauptsächlich Text.
Dieser Text wird somit zu einer Ressource, die verwaltet werden muss.
Demonstration: Durchflussrohr
Um diese Idee zu vertiefen, habe ich eine Symfony-Demo erstellt, die Sie hier finden:
Das Projekt stellt einen Konsolenbefehl bereit:
php bin/console app:flow-token-demo \
--input=flow-engine-log --show-chunks
Ziel ist es nicht, einen LLM-Abschluss zu erlangen.
Ziel ist es, eine Kontextverarbeitungspipeline lokal zu simulieren.
Die Pipeline umfasst acht Phasen:
- Eine Quelle laden
- Entfernen Sie die ANSI-Sequenzen
- Beseitigen Sie das Rauschen
- Normalisieren Sie die Leerzeichen
- In Stücke schneiden
- Komprimieren
- Ein Budget festlegen
- Ein brauchbares Ergebnis erzeugen
Eine deklarative Pipeline
Die Pipeline kann in deklarativer Form ausgedrückt werden:
source |> strip_ansi |> remove_noise |> normalize_whitespace
|> chunk:300 |> compress |> budget:1000 |> sink
Diese Notation ermöglicht es, die Pipeline von links nach rechts zu lesen.
Jeder Schritt verändert den vorherigen.
Der Nutzen ist zweifach:
- verbesserte Lesbarkeit
- verbesserte Erweiterbarkeit
Das Hinzufügen einer neuen Operation erfordert keine Änderung der zentralen Bedingungsstruktur.
Jeder Vorgang wird zu einer eigenständigen Komponente.
Drei Bedeutungen der Pfeife
In dieser Demonstration erscheint das Symbol |> auf drei Ebenen.
1. Ausdrucks-DSL
Erste Ebene: Die Pipe repräsentiert eine deklarative Sprache, die für Menschen lesbar ist.
source |> compress |> sink
2. Pipe-Operator von PHP 8.5
PHP 8.5 führt den Pipe-Operator nativ ein.
Es ermöglicht eine explizitere Komposition von aufrufbaren Funktionen.
Beispiel :
yield $step |> (fn ($step) => new ClosureJob(...));
Der Code nähert sich dem Lesen der domänenspezifischen Sprache (DSL) an.
#3. Laufzeitkomposition mit Flow
Dritte Ebene: die tatsächliche Zusammensetzung der Jobs in Flow.
Jede Transformation wird zu einer Aufgabe, die auf einen gemeinsamen Kontext angewendet wird.
Dies ist die Schicht, die die Pipeline tatsächlich ausführt.
Inspiration: Pratt-Analyse
Der Parsing-Teil der DSL.
Anstelle eines monolithischen Parsers verfügt jede Operation über Folgendes:
- sein Name
- seine Parsing-Logik
- seine Ausführungslogik
Dieser Ansatz vermeidet einen überlasteten zentralen Parser.
Die Pipeline ist von vornherein erweiterbar.
Ergebnis
Nehmen wir als Beispiel die flow-engine-log-Fixture.
Vor der Transformation:
- 17.398 Zeichen
- ~4.488 Token geschätzt
Nach der Pipeline:
- 334 Zeichen
- Geschätzte Anzahl von Token: ~88
Das entspricht ungefähr:
98 % Rabatt
Wichtig ist nicht nur das Verhältnis.
Wichtig ist, dass das Fachvokabular erhalten bleibt.
Die Konzepte:
- fließen
- Stream
- Pipeline
- Quelle
- Waschbecken
wurden nicht gekürzt.
Verschwunden ist Folgendes:
- das Geräusch
- die Proben
- Zeilen ohne Wert
Mit anderen Worten:
Das Signal blieb bestehen.
Das Geräusch ist verschwunden.
Signal vs. Rauschen
Eine zweite Vorrichtung, flow-lexicon, ist absichtlich nicht sehr komprimierbar.
Die beobachtete Reduktion ist gering.
Und das ist gut so.
Das bedeutet, dass der Inhalt bereits größtenteils aus Signal besteht.
Eine gute Pipeline versucht nicht, alles zu komprimieren.
Sein Ziel ist es, nur das zu beseitigen, was keinen Nutzen bringt.
Und was dann?
Diese Demonstration ist bewusst synchron und lokal.
Das eröffnet aber eine interessante Richtung.
Eine natürliche Weiterentwicklung wäre die Bewegung hin zu Folgendem:
- nicht-blockierende Datenströme
stream_select()- Fasern
- Prozessleitungen
- PTY / TTY
- eine Ereignisschleife
Dies würde es uns ermöglichen, die Datenströme zu verarbeiten, sobald sie auftreten, und nicht erst im Nachhinein.
Mit anderen Worten:
Man muss nicht mehr bis zum Ende eines Prozesses warten, um dessen Ergebnis zu analysieren.
Den Feed in Echtzeit lesen und transformieren.
Abschluss
Die Kosten agentenbasierter Arbeitsabläufe sind nicht nur ein Modellproblem.
Es handelt sich um ein Orchestrierungsproblem.
Ein leistungsstarker Agent ist nicht jemand, der alles liest.
Es ist dasjenige, das seinen eigenen Kontext erhält, strukturiert und eingeschränkt ist.
Echte Optimierung besteht daher nicht in der Verkürzung von Wörtern.
Es besteht darin, den Fluss zu steuern.
Kontrolliere den Datenstrom, nicht die Rechtschreibung.
Ressourcen
- Guillaume Moigneu über die Tokenisierung von Kontextdisziplin
- flow-pipe
- Slidewire-Präsentation
- PHP 8.5 Pipe-Operator