Context Engineering erklärt: Context Filtering und autonomes Context Engineering

Inhalt:

1. Woher kommen all diese Tokens?
2. Filtering: Laden nach Bedarf
3. Filtering im System Prompt
4. Das Modell selbst Context Engineering durchführen lassen
5. Auf der Festplatte gespeicherter Context

Frühere Artikel:

• Wie KI-Agenten funktionieren: Der Fall OpenClaw
• Die zentrale Technologie von AI Agents verstehen: Context Engineering (LLM Summary, Observation Masking und Memory)
• Context Engineering erklärt: Was tun, wenn Aufgaben, die ein KI-Agent ursprünglich lösen konnte, nach dem Context Engineering scheitern?
• Context Engineering erklärt: Mechanismen zur Entscheidung, wann Kontext komprimiert werden sollte

1. Woher kommen all diese Tokens?

In den vorherigen Artikeln haben wir einige Konzepte zur Komprimierung von Context vorgestellt. Vielleicht ist dir dabei aber aufgefallen: Diese Methoden kommen meist erst dann zum Einsatz, wenn der Context bereits sehr lang geworden ist.

Das ist natürlich eine Möglichkeit, die Länge des Context zu kontrollieren. Man kann die Frage jedoch noch einen Schritt weiterdenken: Gibt es vielleicht eine Möglichkeit, von Anfang an zu verhindern, dass so viele Inhalte, also so viele Tokens, überhaupt in den Context gelangen?

Um diese Frage zu klären, müssen wir zunächst verstehen, was in unserem Context eigentlich enthalten ist und welche Inhalte den grössten Anteil ausmachen. Im Allgemeinen sollte man zuerst den Teil angehen, der am meisten Gewicht hat, denn dadurch werden die Auswirkungen meist schneller und deutlicher sichtbar.

Diese Studie analysiert genau ein ähnliches Problem. Aus der Abbildung lässt sich erkennen, dass ein bestimmter Anteil tatsächlich sehr, sehr gross ist.

Man kann die Inhalte im Context grob in drei Kategorien einteilen: Action, Reasoning und Observation.

Action bezeichnet die Anweisungen, die das Modell erzeugt, um Tools aufzurufen. Wenn das Modell beispielsweise entscheidet, eine Datei zu lesen, ein Programm auszuführen oder ein externes Tool aufzurufen, muss es einen entsprechenden Befehl erzeugen. In den meisten Fällen sind solche Anweisungen relativ kurz, weshalb ihr Anteil am Context tatsächlich nicht sehr hoch ist.

Reasoning kann grob als das verstanden werden, was das Modell selbst formuliert. Dazu gehören beispielsweise Inhalte, die entstehen, wenn das Modell eine Aufgabe analysiert, seinen Gedankengang erklärt oder den nächsten Schritt plant.

Observation bezeichnet Eingaben aus der Aussenwelt, zum Beispiel den Inhalt geladener Dateien, Ausgaben von Tools, Suchergebnisse, Log-Inhalte oder Fehlermeldungen nach der Ausführung eines Programms.

Darüber hinaus gibt es eine weitere Studie, die etwas Ähnliches untersucht und zu ähnlichen Schlussfolgerungen gelangt. Der Unterschied besteht darin, dass sich diese Studie hauptsächlich auf das Thema Software Engineering konzentriert, also beispielsweise darauf, Modelle Code ändern, Programme ausführen oder Fehler beheben zu lassen.

Man kann erkennen, dass etwa 12 % mit der Ausführung von Programmen zusammenhängen und 11 % mit Änderungen. Der grösste Teil entfällt jedoch auf das Lesen von Code, also Read, und macht einen beträchtlichen Anteil aus.

Die zentrale Frage lautet also: Gibt es eine Möglichkeit, das Problem an der Wurzel zu lösen? Mit anderen Worten: Gibt es eine Möglichkeit, von Anfang an zu vermeiden, dass so viele Inhalte in den Context eingelesen werden?

2. Filtering: Laden nach Bedarf

Im Kern geht es um Laden nach Bedarf. Wenn bestimmte Inhalte gerade nicht gebraucht werden, sollten sie zunächst nicht in den Context gelangen. Erst wenn sie wirklich benötigt werden, werden sie eingelesen.

Wenn wir beispielsweise einige Logs lesen müssen, kann das Modell sagen: Bitte rufe das Read-Tool auf und lies den Log ein, damit ich ihn mir ansehen kann.

Dann öffnet dieses Read-Tool den auf der Festplatte gespeicherten Log und liest ihn in den Context ein.

Wir können dieses Tool auch noch feiner gestalten. Wenn das Modell beispielsweise sagt, dass es im Log nur die Inhalte im Zusammenhang mit „Bug Fixing“ lesen möchte, gibt das Tool nur jene Log-Inhalte zurück, die mit „Bug Fixing“ relevant zusammenhängen.

Damit übernimmt dieses Tool eine „Filtering“-Funktion.

Was dieses sogenannte Tool genau ist, kann je nach Situation entschieden werden. Es kann sich um bestimmte technische Engineering-Tricks handeln, oder man kann ein kleines Modell trainieren, das speziell diese Aufgabe übernimmt.

Kurz gesagt geht es darum, dieses Tool möglichst intelligent zu machen, damit es nur die Inhalte liest, die tatsächlich benötigt werden.

Memory

Wir haben bereits erwähnt, dass es im System eines Agents normalerweise ein Tool wie memory_get gibt. Auch hier wird ein ähnliches Filtering-Konzept verwendet: Der Agent entscheidet selbst, welche Erinnerungen in den Context eingelesen werden sollen, statt alle Erinnerungen auf einmal zu laden.

Filtering im System Prompt

Wie bereits erwähnt, ist der System Prompt eine besondere Art von Prompt. In jeder Runde der Interaktion mit dem Modell wird dieser Teil des Inhalts immer mitgeführt.

Im System Prompt werden viele nützliche Informationen abgelegt. Zum Beispiel kann dort stehen, welche Tools dem Modell derzeit zur Verfügung stehen. Falls im Gespräch ein bestimmtes Tool benötigt wird, kann das Modell anhand der Hinweise im System Prompt das entsprechende Tool finden und aufrufen.

Aber wie detailliert sollten die Informationen über die verschiedenen Tools im System Prompt eigentlich sein? Sollten wir nur einen Teil davon hineinlegen? Oder sollte man es anders machen?

Im obigen Beispiel gibt es etwa ein Tool zur Nutzung von GitHub. Wenn man die Informationen zu diesem Tool in den System Prompt einfügen wollte, bräuchte man mehr als 4.600 Tokens.

Vielleicht läuft der Agent einen ganzen Tag lang, und dieses Tool wird nur wenige Male verwendet. Die mehr als 4.600 Tokens würden jedoch die ganze Zeit über jede Interaktion zwischen dir und dem Modell begleiten. Wäre das nicht einfach eine unnötige Verschwendung von Geld?

Daher müssen wir weiterhin Wege finden, nicht zu viele Informationen zu laden. Erst wenn sie benötigt werden, sollte das Modell sie nachschlagen.

Ein traditioneller Ansatz besteht darin, die verfügbaren Tools zunächst nicht zu laden. Erst wenn eine Aufgabe ein geeignetes Tool erfordert, nutzt man ein RAG-ähnliches Konzept, um zu suchen, welche Tools verfügbar sein könnten.

In der Praxis funktioniert diese Methode jedoch häufig nicht besonders gut. Denn die Bedürfnisse der Nutzerinnen und Nutzer, also die Beschreibung und Definition der Aufgabe, sind oft sehr vage. Es ist schwierig, allein anhand dieser Beschreibung direkt nach den passenden Tools zu suchen.

Ein Beispiel: Die Aufgabe besteht darin, das Modell einen bestimmten Bug beheben zu lassen. Wahrscheinlich reicht dafür aber nicht nur ein einziges Tool aus. Möglicherweise braucht man ein Read-Tool, ein Editing-Tool und weitere Tools. Allein anhand der Beschreibung der Nutzerin oder des Nutzers ist es für die Suchmaschine schwer, sofort selbst zu entscheiden, welche Tools verwendet werden sollten.

Ein möglicher Verbesserungsansatz besteht deshalb darin, das AI-Modell selbst entscheiden zu lassen, welche Art von Tool es benötigt. Mit anderen Worten: Das Modell formuliert selbst eine „Description of the required tool“.

Nachdem diese Beschreibung erzeugt wurde, kann die Suchmaschine ihre Rolle übernehmen.

Skill

Wir haben zuvor auch das Konzept des Skills in einem Agent erwähnt. Wenn Nutzerinnen oder Nutzer eine Aufgabe stellen und der Agent über einen vorinstallierten Skill verfügt, der zu dieser Aufgabe passt, ruft der Agent diesen Skill auf, um die Aufgabe zu erledigen.

Auch hier wird im Grunde das Konzept des Ladens nach Bedarf verwendet. Das heisst, der Agent lädt nicht den gesamten detaillierten Inhalt eines Skills auf einmal in den Context.

Kehren wir nun noch einmal zu dieser Formel zurück. In der Funktion F, die anhand des aktuellen Context, der Eingabe und der Ausgabe des Modells entscheidet, welche Inhalte im neuen Context enthalten sein sollen, wird der grösste Teil im Grunde von Menschen festgelegt.

Mit anderen Worten: Wir Menschen versuchen, mit verschiedensten Methoden die Arbeit der Funktion F zu erledigen, sei es durch Engineering-Techniken oder durch kleine Modelle, die speziell dafür trainiert werden, diese Aufgabe zu unterstützen.

Das Modell selbst Wege für Context Engineering finden lassen

Gibt es also eine Möglichkeit, diesen Teil intelligenter zu machen? Anders gesagt: Statt dass wir Menschen versuchen, für das Modell Context Engineering zu betreiben, könnte das Modell selbst Wege finden, mit seinem eigenen Context umzugehen, ganz gleich, wie es diesen Context bearbeiten möchte.

In dieser Studie wird beispielsweise, nachdem Context_t, Input_t und Outputt erzeugt wurden, vom Modell selbst auf Grundlage dieser drei Elemente ein neuer Context{t+1} erzeugt.

Nach derselben Logik erhält man dann Context_{t+2}.

Danach wird dieser Prozess fortlaufend weitergeführt.

Dabei stellt man fest, dass wichtigere Inhalte, zum Beispiel der System Prompt, an diesem Prozess nicht beteiligt sind. In ähnlichen Arbeiten kann man also gezielt einen Teil des Context reservieren, den das LLM auf keinen Fall berühren darf, und zugleich einen anderen Teil bereitstellen, mit dem das LLM frei arbeiten kann. In diesen Bereich kann das Modell dann einfügen, was es möchte.

Natürlich bedeutet es nicht, dass das LLM den Context der nächsten Runde völlig blind erzeugen darf. Menschen können ihm weiterhin bestimmte Anweisungen geben. In dieser Studie geben die Autorinnen und Autoren dem Modell beispielsweise eine ziemlich lange Anleitung. Der Grundgedanke ist ungefähr folgender: Zu konkrete Aufzeichnungen werden später wahrscheinlich nicht mehr nützlich sein und müssen daher nicht gespeichert werden. Beibehalten werden sollten nur wirksame Erfahrungsstrategien, wiederverwendbarer Code und einige zentrale Erkenntnisse.

Im Unterschied zur vorherigen Studie macht diese Arbeit etwas Komplexeres. Hinweis: In dieser Studie wird der Context als Playbook bezeichnet.

In dieser Arbeit durchläuft der Context nicht nur ein einziges Modell, sondern drei Modelle. Nachdem diese drei Modelle jeweils Prüfungen aus unterschiedlichen Perspektiven durchgeführt haben, erzeugen sie nicht direkt einen neuen Context, denn eine direkte Erzeugung eines neuen Context könnte wichtige Inhalte beschädigen. Stattdessen erzeugen sie zunächst eine Anweisung dazu, wie der Context geändert werden soll, also eine Edit Instruction.

Auf Grundlage dieser Edit Instruction wird anschliessend ein neuer Context erzeugt.

Auf der Festplatte gespeicherter Context

Es gibt noch eine weitere Situation: Der Context wird extrem lang, so lang, dass er auf der Festplatte gespeichert werden muss.

Im tatsächlichen Ablauf muss nur ein kleiner Teil wichtiger Informationen in den Echtzeit-Context geladen werden. In dieser Studie werden diese wichtigen Informationen als metadata bezeichnet. Dazu gehört zum Beispiel, wie lang der vollständige Context ist, in wie viele Abschnitte er aufgeteilt wurde, wo er gespeichert ist und so weiter.

Das LLM entscheidet anhand dieser metadata, P_t, welche Materialien es von der Festplatte, M_t, lesen muss.

Natürlich kann das LLM auch selbst Programme schreiben und ausführen, um die auf der Festplatte gespeicherten Inhalte zu durchsuchen. Es kann eigenständig RAG durchführen, die benötigten Informationen herausholen und anschliessend seine metadata ändern.

Insgesamt erfordert die Frage, wie man das LLM anleitet oder dazu bringt, bessere Methoden für Context Engineering zu verwenden, weiterhin Prompt Engineering. Das bedeutet: In dem Prompt, den das LLM sieht, muss man immer wieder versuchen, dem Modell Hinweise zu geben, dass es bei Bedarf RAG verwenden soll, um nach den benötigten Materialien zu suchen.

Daher gibt es eigentlich keine besondere Magie, durch die das Context Engineering des Modells plötzlich auf einmal aussergewöhnlich gut wird.

Auch wenn diese Methode auf den ersten Blick nicht besonders magisch wirkt, ist ihre tatsächliche Leistung gut. In dieser Abbildung zeigt die obere Hälfte die Leistung ohne die Methode aus dieser Studie. Man kann erkennen, dass die Leistung bei einigen Aufgaben deutlich abnimmt, je länger die Tokens werden.

Wenn man hingegen die Methode dieser Studie verwendet, lassen sich auch dann noch gute Ergebnisse erzielen, wenn die Zahl der Tokens sehr gross wird.

Noch wichtiger ist, dass diese Methode eher wie ein allgemeiner Mechanismus wirkt. Sie kann auf jedes LLM angewendet werden und ist nicht nur auf ein bestimmtes Modell beschränkt.

Hinweis zu dieser Notiz:

• Diese Notiz basiert hauptsächlich auf dem Machine-Learning-Kurs von Prof. Hung-yi Lee aus dem Jahr 2026 (https://www.youtube.com/watch?v=urwDLyNa9FU). Ein kleiner Teil des Inhalts kann aufgrund meines eigenen Verständnisses leicht angepasst worden sein;
• Es wurden nur die zentralsten Inhalte beibehalten. Deshalb ist diese Notiz relativ kurz, versucht aber zugleich, die Wissensstruktur möglichst vollständig zu erhalten. Sie eignet sich daher gut für eine schnelle Wiederholung, aber auch für Einsteigerinnen und Einsteiger, die sich rasch einen Überblick verschaffen möchten.