Token-Effizienz ist ein Kontextproblem
Die meisten KI-Agenten verschwenden Tokens aus einem Grund: Sie laden denselben Kontext bei jedem Schritt neu, statt ihn zu referenzieren. Die Lösung ist kein kürzerer Prompt, sondern deine Dateien, Daten und den geteilten Zustand in eine Ebene zu verlagern, die der Agent per Referenz liest. Dieser Leitfaden erklärt, wohin die Tokens wirklich gehen und warum eine geteilte Datenebene den Verlust beseitigt.
Wohin gehen die Tokens wirklich?
Token-Verbrauch in Agenten ist selten das "Nachdenken" des Modells. Es ist redundanter Kontext, immer wieder geladen. Die vier größten Quellen:
| Quelle der Verschwendung | Warum sie entsteht | Typische Kosten |
|---|---|---|
| Dieselbe Datei erneut lesen | Der Agent erinnert sich nicht, dass er sie schon gelesen hat | 2.000+ Tokens pro Wiederholung |
| Komplette Datei- oder Tool-Scans | Der Agent listet alles, um eine Sache zu finden | 10.000 bis 20.000 Tokens pro Befehl |
| Kontextverlust zwischen Sessions | Eine neue Session liest das ganze Projekt neu | 30.000 bis 50.000 Tokens vor der eigentlichen Arbeit |
| Rohe Tool-Ausgabe und Screenshots | Wörtlich in den Prompt gekippt | Bis zu 60 bis 70 Prozent des Verbrauchs in manchen Agenten |
Warum löst ein größeres Kontextfenster es nicht?
Ein größeres Fenster beseitigt die Verschwendung nicht, es verteilt sie um. Du zahlst weiter für jeden geladenen Token, und die Aufmerksamkeit über lange Kontexte verschlechtert sich in der Mitte des Fensters, der Agent kostet also mehr und denkt zugleich schlechter. Mehr laden ist nicht dasselbe wie das Richtige laden.
Warum ist Token-Verschwendung in Wahrheit ein Kontextproblem?
Die Ursache ist, wo dein Kontext liegt. Liegt er nur in der Konversation, muss jeder Schritt ihn neu laden. Liegt er in einer geteilten Ebene mit stabilen Adressen, referenziert der Agent ihn einmal und zeigt darauf zurück, statt ihn neu einzulesen. Token-Effizienz ist daher eine Architekturfrage, kein Prompting-Trick.
Wie beseitigt eine geteilte Datenebene die Verschwendung?
adlass ist eine geteilte Datenebene, in der du, dein Team und eure Agenten über dieselben Dateien, Datensätze und denselben Zustand arbeiten, verbunden über MCP. Der Agent liest ein Dokument oder einen Datensatz per Referenz, einmal, aus der Ebene, statt den vollen Inhalt in jeden Prompt zu packen. Wiederholte Lesevorgänge werden zu günstigen Lookups, Scans zu gezielten Abfragen, und eine neue Session setzt am geteilten Zustand an, statt das Projekt neu zu lesen.
Vertiefende Leitfäden
- Warum liest mein Agent dieselbe Datei erneut und verschwendet Tokens?
- Warum verliert mein Agent den Kontext zwischen Sessions?
In diesem Leitfaden
- Warum liest mein Agent dieselbe Datei erneut und verschwendet Tokens?
Agenten lesen Dateien erneut, weil jeder Schritt frühere Lesevorgänge vergisst. Eine geteilte, adressierbare Ebene lässt den Agenten Dateien referenzieren statt neu einlesen.
- Warum verliert mein Agent den Kontext zwischen Sessions?
Agenten verlieren Kontext, weil die Konversation der einzige Speicher ist. Eine geteilte Datenebene hält Dateien, Entscheidungen und Zustand, sodass eine neue Session fortsetzt.
Häufige Fragen
- Reduziert ein kürzerer Prompt den Token-Verbrauch?
- Ein wenig, aber das behandelt das Symptom. Der meiste Verlust kommt vom Neuladen von Dateien, von Scans und verlorenem Session-Kontext, nicht von deinen Anweisungen. Diesen Kontext in eine geteilte Ebene zu verlagern, die der Agent referenziert, bringt weit mehr als das Kürzen des Prompts.
- Ist eine geteilte Datenebene dasselbe wie RAG?
- Nein. RAG holt Passagen aus einem statischen Korpus in den Prompt. Eine geteilte Datenebene hält lebende Dateien, Daten und Zustand, die Agenten und Menschen per Referenz lesen und schreiben. Du kannst innerhalb der Ebene weiterhin Retrieval betreiben.
- Behebt Prompt-Caching wiederholte Lesevorgänge?
- Caching hilft bei stabilem Kontext, kostet aber mehr pro Token als frischer Kontext und bricht, sobald sich Dateien ändern. Eine referenzbasierte Ebene vermeidet das erneute Einlesen der Datei von vornherein.
Arbeite mit deinen Agenten auf denselben Daten
adlass ist die geteilte Datenebene, auf der du, dein Team und ihre Agenten an denselben Dokumenten und Datensätzen arbeiten.