Lange Agenten-Züge im Kontextfenster halten

Ein Modell kann nur eine begrenzte Menge auf einmal lesen, sein Kontextfenster. Mythex' Agent erledigt lange Aufgaben: Er liest viele Dateien, führt Befehle aus und übergibt abgegrenzte Jobs an Sub-Agenten. Wir haben drei Wege gefunden, wie lange Arbeit kaputtging: Sub-Agenten wuchsen, bis das Modell jede Anfrage ablehnte. Ein Sub-Agent hörte früh auf, weil er dachte, ihm gehe der Platz aus. Und unsere Token-Zählung war für Russisch, Chinesisch und Japanisch völlig daneben. Hier ist, was wir geändert haben.

Zuerst ein paar Begriffe

• Tokens sind die Stücke, die ein Modell liest. Limits und Kosten werden in ihnen gezählt, nicht in Zeichen oder Wörtern.
• Kontextfenster ist die größte Menge, die ein Modell in einer Anfrage lesen kann. Außerdem setzen wir für jede Anfrage ein eigenes, niedrigeres Budget, damit Kosten und Geschwindigkeit vernünftig bleiben.
• Tool-Ergebnisse sind das, was der Agent von seinen Tools zurückbekommt: den Inhalt einer gelesenen Datei, die Ausgabe eines ausgeführten Befehls. Bei langer Arbeit machen sie den größten Teil dessen aus, was gesendet wird.
• Ein Sub-Agent ist ein Helfer, den der Hauptagent für eine in sich geschlossene Aufgabe startet, etwa „prüfe diese Kapitel gegen die Notizen“. Er bekommt eine einzige Anweisung und arbeitet dann selbstständig viele Tool-Aufrufe ab.

Problem 1: Sub-Agenten wuchsen, bis das Modell sie ablehnte

Bei jedem Schritt sendet der Agent dem Modell die bisherige Unterhaltung. Wurde sie zu groß, kürzte unser Code sie, aber nur am Anfang einer Nutzernachricht, sodass ein Tool-Aufruf und sein Ergebnis nie getrennt wurden. Die erste Nachricht blieb erhalten, es kam ein Hinweis hinzu, dass frühere Unterhaltung gekürzt wurde, und die neuesten ganzen Züge, die noch hineinpassten, blieben.

Ein Sub-Agent hat genau eine Nutzernachricht: seine Anweisung. Dort gab es nichts zum Schneiden. Er sendete also bei jedem Schritt seine gesamte Historie, die jedes Mal größer wurde, bis die Anfrage größer war als das, was das Modell überhaupt annimmt, rund eine Million Tokens. In einem Test mit acht solchen Sub-Agenten wurden alle acht abgelehnt.

Die Lösung: zuerst alte Tool-Ergebnisse leeren

Anfragen passen jetzt in drei Schritten in das Budget. Jeder Schritt wird nur versucht, wenn der vorige nicht gereicht hat:

1. Die ältesten Tool-Ergebnisse leeren. Ihr Inhalt wird durch einen kurzen Hinweis ersetzt: Das Ergebnis wurde geleert, damit die Unterhaltung im Kontext des Modells bleibt, und der Agent kann das Tool bei Bedarf erneut ausführen. Eine Datei, die vor einer Stunde gelesen wurde, ist meist das größte und am wenigsten nützliche Element der Anfrage, und die Datei lässt sich erneut lesen. Die neuesten Ergebnisse bleiben vollständig.
2. Ganze Nutzerzüge behalten. Wie bisher: die erste Nachricht, ein Hinweis und die neuesten vollständigen Züge, die noch passen.
3. Ganze Tool-Runden behalten. Innerhalb eines langen Zugs – der einzigen Art, die ein Sub-Agent hat – bleiben die erste Nachricht, ein Hinweis und die neuesten vollständigen Runden „Tool aufrufen, Ergebnis erhalten“.

Das betrifft nur, was gesendet wird. Die gespeicherte Historie des Agenten behält alles. Im selben Test wurde keiner von acht abgelehnt, und alle acht schlossen ab.

In Stapeln leeren, damit der Cache funktioniert

Modellanbieter können den Anfang einer Anfrage wiederverwenden, wenn er identisch mit der letzten ist, einen Präfix-Cache. Würden wir bei jedem Aufruf ein weiteres Ergebnis leeren, würde sich der Anfang der Anfrage bei jedem Aufruf ändern, und der Cache würde nie helfen.

Deshalb werden die ältesten Ergebnisse vier auf einmal geleert, nicht einzeln. Der geleerte Teil bleibt dann über mehrere Aufrufe gleich. Ein Ergebnis, das nicht viel größer ist als der Hinweis, bleibt unangetastet, denn das Leeren würde kaum etwas sparen und hätte trotzdem den Anfang der Anfrage verändert. Wie viel vollständig bleibt, bestimmt die Größe und nicht die Anzahl: Die neuesten Ergebnisse, die in ein Viertel des Budgets passen, bleiben, mindestens aber eines. Eine frühere Version behielt fest sechs vollständig. Das passte für kurze Befehlsausgaben, ließ bei langen Dateien aber den größten Teil des Budgets für alte Ergebnisse.

Ablehnungen werden jetzt benannt

Eine Anfrage, die das Modell als ungültig ablehnt, wird nicht mehr wiederholt. Dieselbe Anfrage erhält immer dieselbe Antwort. Ist die Unterhaltung für das Modell zu lang, sieht die Person: „Diese Unterhaltung ist für das Modell zu lang, um sie auf einmal zu lesen. Starte für den nächsten Schritt einen neuen Chat. Alles bisher Gebaute bleibt erhalten.“ Das ist eine Entscheidung, die bei der Person liegt, und kein Ausfall, daher löst es keinen Alarm bei uns aus.

Problem 2: Der Agent hörte auf, um „Platz zu sparen“

Ein Sub-Agent, der 40 lange Kapitel lesen sollte, hörte nach zwei auf und sagte, er wolle Platz sparen. Er hatte etwa 100.000 Tokens eines Budgets von 400.000 verbraucht.

Er konnte nicht wissen, dass für ihn jetzt alte Ergebnisse geleert würden. Also haben wir es ihm gesagt. Die Anweisungen des Agenten sagen jetzt: Wenn die Unterhaltung über das hinauswächst, was das Modell aufnehmen kann, werden die ältesten Tool-Ergebnisse geleert und die neuesten bleiben vollständig. Also musst du eine lange Aufgabe nicht abbrechen, um Platz zu sparen. Mach weiter, und lies eine Datei erneut, wenn du etwas Geleertes brauchst.

Eine Korrektur, die das Modell nicht sieht, ist aus dessen Sicht keine Korrektur. Der Mechanismus hilft nur, wenn der Agent ihm vertraut.

Problem 3: Tokens so zählen, als wäre alles Englisch

Wir haben Tokens ohne Tokenizer geschätzt, als Zeichen geteilt durch vier. Das ist eine brauchbare Faustregel für Englisch. Für andere Schriften gilt sie nicht: Russisch hat etwa 2,2 Zeichen pro Token, Chinesisch oder Japanisch etwa eines.

Ein Sub-Agent, der russische Kapitel las, sendete deshalb eine Anfrage mit rund 640.000 Tokens, während unsere Schätzung unter dem Budget von 400.000 lag. Die Schätzung hätte genauso gut eine Anfrage über das harte Limit des Modells schieben können.

Die Schätzung zählt jetzt nach Schriftsystem: einfaches ASCII mit vier Zeichen pro Token, Chinesisch, Japanisch und Koreanisch mit einem Zeichen pro Token, alles andere – Kyrillisch, Griechisch, Arabisch, akzentuierte Buchstaben, Emoji – mit zwei Zeichen pro Token. Sie soll eher zu hoch schätzen. Bei einem russischen Kapitel schätzt sie jetzt 43.423 Tokens gegenüber gemessenen rund 44.600. Vorher waren es 25.023. Da sich eine Nachricht nach dem Schreiben nie ändert, wird ihre Schätzung einmal berechnet und gemerkt, statt bei jedem Schritt neu.

Was wir daraus gelernt haben

• Kürze dort, wo die Größe tatsächlich steckt. Bei Agentenarbeit sind das Tool-Ergebnisse, nicht Nutzernachrichten.
• Sag dem Agenten, welche Sicherheitsnetze existieren. Sonst plant er um Grenzen herum, die nicht mehr gelten.
• „Zeichen ÷ 4“ ist eine Annahme für Englisch. Alles, was Tokens für mehrsprachige Nutzer zählt, muss nach Schriftsystem zählen oder einen echten Tokenizer verwenden.
• Achte auf den Cache. Eine Anfrage, deren Anfang sich bei jedem Aufruf ändert, kostet mehr und läuft langsamer.

Wenn du KI-Funktionen in deine eigene App einbaust, behandeln unsere Guides was ein LLM ist und wie du LLM-APIs nutzt Kontextfenster und Tokens von Grund auf. Mehr dazu, wie Sub-Agenten in Mythex arbeiten, findest du in der Sub-Agenten-Dokumentation.