Dein KI-Agent vergisst alles: die MCP-Tricks gegen Kontext-Aufblähung

Das Problem, das niemand bewirbt

Jede Demo eines KI-Coding-Agents zeigt dasselbe: ein sauberes Terminal, eine klare Anweisung, ein ordentliches Ergebnis. Niemand zeigt dir die dritte Stunde, in der der Agent vierzig Dateien gelesen, ein Dutzend Testsuiten ausgeführt und sein context window mit der verrauschten Ausgabe jedes jemals ausgeführten Befehls gefüllt hat. An diesem Punkt wird der Agent nicht schlauer. Er wird dümmer, vergesslich und neigt dazu, bereits erledigte Arbeit selbstsicher zu wiederholen.

Das ist das am wenigsten glamouröse und universellste Problem beim agentischen Codieren. Kontext ist das Arbeitsgedächtnis des Agenten, und es ist begrenzt. Alles, was der Agent liest, konkurriert um denselben Platz, und das meiste davon ist Müll: Build-Logs, Stacktraces, Verzeichnislisten, der Volltext von Dateien, aus denen er nur eine Zeile brauchte. Das Fenster füllt sich mit Sediment, und die Schlussfolgerungen, die den Agenten überhaupt nützlich machten, werden verdrängt.

Die Werkzeuge, die das beheben, sind nicht die, die Benchmark-Vergleiche gewinnen. Es ist Sanitärtechnik. Und im Oktober ist genau diese Sanitärtechnik in die Trending-Liste von GitHub geklettert.

Die Idee hinter dem Sandboxing von Tool-Ausgaben

Eines der interessanteren aufgetauchten Projekte ist eine Kontext-Optimierungsschicht für Coding-Agents, die das Problem an der Wurzel packt. Seine Schlagzahl: eine Reduktion um rund 98 Prozent des Tool-Output-Volumens, das das Modell erreicht.

Der Mechanismus ist im Konzept unkompliziert. Statt die Rohausgabe eines Befehls direkt in die Unterhaltung strömen zu lassen, führst du sie in einem sandbox aus und reichst dem Modell nur das, was es vom Ergebnis braucht: eine Zusammenfassung, einen Exit-Status, die konkreten Zeilen, die einer Abfrage entsprachen. Das vollständige Protokoll bleibt für das Modell verfügbar, um es gezielt abzurufen, aber es belegt nicht den Platz im Fenster, nur weil es relevant sein könnte.

Das ist dieselbe Disziplin, die ein guter Ingenieur aus Gewohnheit anwendet. Man fügt nicht das gesamte Log in einen Chat ein, wenn die eine Fehlerzeile der Punkt ist. Ein Agent, sich selbst überlassen, tut genau das Gegenteil.

Daran hängt eine Rechnung, weshalb das Tooling keine reine Ingenieurs-Nettigkeit ist. Ein context window ist nicht kostenlos. Jedes Token, das das Modell verarbeiten muss, kostet Geld und Zeit, und jedes Token, das es sich merken muss, kostet Aufmerksamkeit. Ein Tool, das hunderttausend Token Build-Ausgabe in eine Session schüttet, berechnet dir doppelt: einmal für die Token und noch einmal für die Verschlechterung des Urteilsvermögens des Modells, wenn das Signal begraben wird. Die 98-Prozent-Reduktion ist in Wahrheit eine Qualitätskorrektur im Kostensparmantel.

Ein Gedächtnis, das die Session überlebt

Die zweite Hälfte des Problems ist, dass Agents nicht nur innerhalb einer Session vergessen, sondern über Sessions hinweg. Schließ das Terminal, und der Kontext ist weg. Öffne es morgen wieder, und der Agent hat keine Ahnung, was du entschieden, welchen Ansatz du verworfen hast oder warum der Code aussieht, wie er aussieht. Du erklärst erneut, der Agent leitet erneut ab, und irgendwo wird eine Entscheidung zweimal getroffen.

Die Tools für persistente Erinnerung in diesem Feld verfolgen unterschiedliche Ansätze. Eines der sichtbarsten erfasst, was der Agent während einer Session tut, komprimiert es mit einem Modell und spritzt die relevanten Teile in künftige Sessions ein. Das Versprechen ist unspektakulär und richtig: ein Agent, der sich an die Form deines Projekts erinnert, ist mehr wert als ein Agent, der bei einer einzelnen Aufgabe marginal schlauer ist. Die großen Modellanbieter haben sich in dieselbe Richtung bewegt und Schrauben hinzugefügt, die einem subagent erlauben, seinen eigenen context früher zu kompaktieren als die übergeordnete Unterhaltung, gerade damit er nicht die Historie der ganzen Session in eine Aufgabe schleppt, die keine davon braucht.

Die interessante Designfrage ist hier, was man sich merken sollte. Alles merken, und du hast das ursprüngliche Problem in langsamerer Form wieder aufgebaut. Zu wenig merken, und die Erinnerung ist nutzlos. Die Projekte, die Fahrt aufnehmen, sind die, die selektiv erinnern, nach der Theorie, dass eine gute Zusammenfassung des letzten Monats einen perfekten Bericht der letzten Stunde schlägt.

Routing als Kontextstrategie

Das dritte Puzzleteil ist Routing: vorab entscheiden, welches Modell und welche Tools eine Aufgabe braucht, damit sie nicht mit Fähigkeiten beladen wird, die sie nie nutzen wird. Ein Modell, dem von siebzehn verschiedenen Integrationen erzählt wurde, gibt Kontext für alle siebzehn aus, selbst wenn die Aufgabe nur eine braucht. Routing plattformübergreifend zu erzwingen klingt nach einem Infrastrukturdetail. Es ist in Wahrheit eine verkappte Kontext-Budget-Entscheidung.

An diesem Punkt sieht das Problem nicht mehr nach einem Cache-Problem aus und beginnt, nach Systemdesign auszusehen. Das context window des Agenten ist eine Ressource, so wie Speicher und Festplatte Ressourcen sind, und die Tools, die es so behandeln, halten Agents über lange Jobs hinweg kohärent. Dass die Sandboxing-, Memory- und Routing-Projekte konvergieren, ist kein Zufall: Es sind drei Ansichten derselben Knappheit.

Das subagent-Muster ist das klarste Beispiel. Wenn ein Agent einen Helfer für eine enge Aufgabe erzeugt, muss dieser Helfer nicht die gesamte Unterhaltung erben. Ihm einen sauberen Kontext mit nur der anstehenden Aufgabe zu reichen, ist billiger und präziser, und deshalb lassen die neueren Harnesses einen subagent seinen eigenen context früher kompaktieren als den des Elternteils. Der Elternteil behält die lange Historie; das Kind bekommt einen frischen Schreibtisch. Teams, die Agents über wochenlange Refactorings laufen ließen, kommen meist von selbst zu dieser Regel, oft nachdem sie gesehen haben, wie ein subagent sein ganzes Fenster damit verbrachte, eine Unterhaltung neu zu lesen, die es nicht brauchte.

Warum das jetzt kommt

Keines dieser Probleme ist neu. Agents verlieren Kontext, seit der erste lief. Was sich geändert hat: Von Agents wird jetzt erwartet, dass sie stundenlang laufen, über viele Sessions hinweg, an Arbeit, die zählt. Ein Spielzeug verliert nichts, wenn es vergisst. Ein Tool, auf das ein Team für ein wochenlanges Refactoring setzt, verliert eine Menge.

Der Markt hat es bemerkt. Vor zwei Jahren war „unser Agent hat ein 200k-Kontextfenster" ein Verkaufsargument. Jetzt lautet die nützliche Frage, welcher Anteil dieses Fensters für Signal aufgewendet wird. Die Anbieter, die das verstehen, liefern Kompaktierungs-Steuerung und Kontext-Isolation für subagents. Die Community liefert die Sanitärtechnik, die den Rest erträglich macht.

Das unspektakuläre Fazit

Man ist versucht, die Agent-News vom Oktober als Geschichte über schlauere Modelle und gerissenere Plugins zu lesen. Die leisere, beständigere Geschichte handelt von Hygiene. Agents sind nützlich genug geworden, um lange zu laufen, und lange Läufe legen jede Schwäche darin offen, wie sie ihr eigenes Gedächtnis verwalten.

Die Projekte, die die Trending-Charts erklimmen, sind die, die eine nüchterne Wahrheit akzeptieren: Der Engpass autonomer Arbeit ist selten rohe Intelligenz. Es ist die Fähigkeit, bei der Aufgabe zu bleiben, ohne in den eigenen Notizen zu ertrinken. Repariere das Gedächtnis, siege das Rauschen in einen sandbox, route die Fähigkeiten, und ein bloß kompetentes Modell wirkt plötzlich exzellent. Mach das falsch, und selbst ein Frontier-Modell verbringt seinen Nachmittag damit, eine Logdatei neu zu lesen, die es schon fünfmal gelesen hat.