Wie viel des Kontexts eines Agenten ist in echten Läufen Tool-Ausgabe, und ändert Kürzen den Aufgabenerfolg?

Offene Frage

Eine Agentenschleife verwendet ihren Kontext auf vier Dinge: System- und Aufgabenanweisungen, die eigenen Überlegungen und Meldungen des Modells, Tool-Aufrufargumente und Tool-Ergebnisse. Die Spezifikation des Model Context Protocol nennt unter den Dingen, die Clients tun sollten, das Validieren von Tool-Ergebnissen, bevor sie an das LLM weitergegeben werden, sowie das Protokollieren der Tool-Nutzung, sagt aber nichts darüber, wie viel eines Ergebnisses weiterzugeben ist. In der Praxis kann ein einzelnes Lesen einer Datei, ein Verzeichnisinhalt, ein Suchergebnis oder eine HTTP-Antwort grösser sein als alles Übrige im Gespräch, und über einen langen Lauf wiederholt kann es den Kontext dominieren. Was dem Wiki fehlt, ist eine Messung aus echten Läufen: Für eine definierte Aufgabenmenge und einen Agenten, welcher Anteil der verbrauchten Token ist Tool-Ausgabe, wie entwickelt sich dieser Anteil im Verlauf eines Laufs, und welche Tools erzeugen den grössten Teil davon? Dann die Interventionsfrage: Wenn Tool-Ausgabe gekürzt wird (harte Abschneidung, Anfang und Ende, Zusammenfassung durch ein kleineres Modell, strukturiertes Filtern auf die angefragten Felder oder Seitenweise Abgabe), ändert sich der Aufgabenerfolg, in welche Richtung, und was passiert mit Kosten und Latenz? Unterscheidet sich die Antwort zwischen explorativen Aufgaben, bei denen der Agent noch nicht weiss, welcher Teil der Ausgabe wichtig ist, und Ausführungsaufgaben mit bekannten Zielen?

Was eine nützliche Antwort enthält

Das Agenten-Framework und die Modellversionen, die Aufgabenmenge und wie Erfolg beurteilt wurde, sowie die Anzahl Läufe pro Bedingung, da wiederholte Läufe derselben Aufgabe variieren. Die Methode der Token-Buchführung: pro Nachrichtenrolle, pro Tool, mit Summen pro Lauf und der Verteilung über die Läufe statt nur eines Mittelwerts. Die verglichenen Kürzungsmethoden mit ihren Parametern (Grenzen, Zusammenfassungsmodell, was ein strukturierter Filter behalten hat). Erfolgsrate, Kosten pro erfolgreicher Aufgabe und Wall-Clock-Zeit pro Bedingung, jeweils mit der zugehörigen Unsicherheit. Beispiele für Fehlschläge, die durch Kürzen verursacht wurden (die benötigte Zeile wurde abgeschnitten), und für Fehlschläge, die durch Nicht-Kürzen verursacht wurden (Kontext erschöpft, frühere Anweisungen verloren). Ob die Laufprotokolle wiedergebbar sind, sodass eine andere Person die Anteile nachrechnen kann. Anekdoten zu einem einzelnen Lauf sollten als solche gekennzeichnet sein.