Der Autor stellte nach der Analyse einer OpenClaw-Arbeitslast fest, dass 79 % des Tokenverbrauchs aus Cached Prefix Replay stammen, und nicht aus Benutzereingaben oder Modellausgaben. Er schlug drei zentrale Optimierungsstrategien für den Kontext vor, um die Betriebskosten für AI-Agenten effektiv zu senken. Dieser Artikel basiert auf einem von MOSHIII verfassten Artikel (Warum meine OpenClaw-Sitzungen an einem Tag 21,5 Millionen Tokens verbrannt haben (und was tatsächlich dagegen geholfen hat)), übersetzt und bearbeitet von Dongqu. (Vorgeschichte: MEXC gehört zu den Top 3 CEX weltweit und vertieft seine Marktstrategie im Spot- und Rohstoffhandel.) (Hintergrundinformationen: Bullenmarkt auf Stablecoins: Zinsen im Vergleich OSL 18%, MEXC 15%, Binance 8%...) Ich analysierte eine echte OpenClaw-Arbeitslast und entdeckte ein Muster, das ich glaube, viele Agentenbenutzer erkennen würden: Der Tokenverbrauch sieht sehr „aktiv“ aus, die Antworten erscheinen normal, aber der Tokenverbrauch steigt plötzlich explosionsartig an. Im Folgenden sind die Strukturzerlegung, die zugrunde liegenden Ursachen und die tatsächlich umsetzbaren Reparaturwege dieser Analyse aufgeführt. Hauptkostentreiber: Cached Prefix Replay. Der größte Kostentreiber sind nicht die langen Nachrichten der Benutzer, sondern die massiven Cached Prefixes, die wiederholt abgespielt werden. Aus den Sitzungsdaten ergibt sich: Gesamte Tokens: 21,543,714 cacheRead: 17,105,970 (79.40%) input: 4,345,264 (20.17%) output: 92,480 (0.43%) Anders ausgedrückt: Die Kosten der meisten Aufrufe liegen nicht in der Verarbeitung neuer Benutzerabsichten, sondern im wiederholten Lesen eines riesigen historischen Kontexts. Ich dachte ursprünglich, dass der hohe Tokenverbrauch von extrem langen Benutzerprompts, einer großen Menge an Ausgaben oder teuren Toolaufrufen stammt. Aber das tatsächlich dominierende Muster ist: input: Hunderte bis Tausende von Tokens cacheRead: 170,000 bis 180,000 Tokens pro Aufruf. Das bedeutet, dass das Modell bei jedem Durchgang immer wieder dasselbe riesige Stable Prefix liest. Sitzungsdatenzerlegung Ich analysierte Daten auf zwei Ebenen: 1. Laufzeitprotokolle 2. Sitzungsprotokolle. Es ist zu beachten, dass die Ausführungsprotokolle hauptsächlich zur Beobachtung von Verhaltenssignalen (wie Neustarts, Fehlerberichten, Konfigurationsproblemen) verwendet werden. Die genauen Tokenstatistiken stammen aus dem usage-Feld in der session JSONL. Verwendete Skripte: scripts/session_token_breakdown.py scripts/session_duplicate_waste_analysis.py Generierte Analyse-Dateien: tmp/session_token_stats_v2.txt tmp/session_token_stats_v2.json tmp/session_duplicate_waste.txt tmp/session_duplicate_waste.json tmp/session_duplicate_waste.png Eine Sitzung hatte einen Verbrauch, der weit über dem anderer lag: 570587c3-dc42-47e4-9dd4-985c2a50af86: 19,204,645 Tokens. Dann gab es einen deutlichen Absturz: ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1,505,038 ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649,584 Tokens. Hauptsächlich aus: toolUse: 16,372,294 stop: 5,171,420. Dies zeigt, dass das Problem hauptsächlich in der Schleife der Toolaufrufe liegt und nicht im normalen Chat. Woher kommen die Token-Spitzen? Die Token-Spitzen sind nicht zufällig, sondern konzentrieren sich auf einige kurze Zeiträume: 2026-03-08 16:00: 4,105,105 2026-03-08 09:00: 4,036,070 2026-03-08 07:00: 2,793,648. Es liegt nicht am Inhalt des Gesprächs, sondern hauptsächlich an großen Zwischenprodukten: riesige toolResult-Datenblöcke, lange reasoning/thinking-Traces, große JSON-Snapshots, Dateilisten, Browser-Crawling-Daten, Dialogprotokolle von Sub-Agenten. In der größten Sitzung beträgt die Zeichenanzahl etwa: toolResult:text: 366,469 Zeichen assistant:thinking: 331,494 Zeichen assistant:toolCall: 53,039 Zeichen. Sobald diese Inhalte im historischen Kontext gespeichert sind, können sie bei jedem nachfolgenden Aufruf über das Cached Prefix erneut gelesen werden. An folgenden Stellen traten große Kontextblöcke wiederholt auf: sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70, große Gateway-JSON-Protokolle (ca. 37,000 Zeichen) sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134, Browser-Snapshot + Sicherheitsverpackung (ca. 29,000 Zeichen) sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219, große Dateilistausgaben (ca. 41,000 Zeichen) sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311, session/status Status-Snapshot + große Prompt-Struktur (ca. 30,000 Zeichen). Ich maß auch das Verhältnis der wiederholten Inhalte innerhalb eines einzelnen Aufrufs: Das Wiederholungsverhältnis beträgt etwa 1,72%. Es gibt sie, aber sie sind nicht das Hauptproblem. Das eigentliche Problem ist: das absolute Volumen des Cached Prefixes ist zu groß. Die Struktur ist: riesiger historischer Kontext, bei jedem Aufruf wird erneut gelesen, wobei nur wenige neue Eingaben hinzugefügt werden. Daher liegt der Optimierungsschwerpunkt nicht auf der Duplikatsbeseitigung, sondern auf dem Design der Kontextstruktur. Dreifache Mechanismen der Kontextexpansion. Drei Mechanismen wirken zusammen: 1. Eine große Menge an Toolausgaben wird in den historischen Kontext geschrieben. 2. Tool-Schleifen erzeugen viele kurze Aufrufe. 3. Die Veränderung des Prefixes ist sehr gering → cache wird bei jedem Aufruf erneut gelesen. Wenn die Kontextkompaktierung nicht stabil ausgelöst wird, wird das Problem schnell größer. Praktische Optimierungsstrategien. Für super große Toolausgaben: · Zusammenfassungen beibehalten ...