Context Engineering für Coding-Agenten
Prompt Engineering ging um Formulierung. Context Engineering geht darum, was im Fenster steht, wenn die Formulierung ankommt, und das ist weit mehr wert.
Geben Sie einem Modell Ihr gesamtes Repository und eine Frage, dann haben Sie ihm die Arbeit nicht erleichtert. Sie haben aus ihr ein Suchproblem gemacht, bevor sie ein Antwortproblem sein darf. Es muss die eine relevante Ecke finden, in einem Fenster, in dem jede irrelevante Datei mit der relevanten um Aufmerksamkeit konkurriert.
Das wird gern übersehen: mehr Kontext ist nicht strikt besserer Kontext. Ab einem Punkt ist er schlechter, und Sie zahlen mehr dafür.
Die drei Fehlerarten
- Verdünnung. Das Signal ist da, aber umzingelt. Die Trefferquote beim Auffinden einer Tatsache sinkt, je mehr unbeteiligtes Material sie umgibt, und am schnellsten für Material in der Mitte eines langen Fensters.
- Widerspruch. Zwei Fassungen derselben Funktion, ein alter Kommentar gegen neuen Code, eine veraltete README. Das Modell hat keine Möglichkeit zu wissen, was aktuell ist, und greift manchmal zum Falschen.
- Abdrift. Lange Sitzungen sammeln zurückgenommene Entscheidungen, aufgegebene Wege und behobene Fehler an. Alles davon steht noch im Fenster, wird noch gelesen und formt noch die Antwort.
Regeln, die standhalten
Sie sind nicht raffiniert. Es sind die, die den Kontakt mit echter Arbeit überstehen.
Relevanz schlägt Menge. Zehn Zeilen, die die Frage beantworten, schlagen tausend, die die Antwort irgendwo enthalten. Wenn Sie auf den Code zeigen können, zeigen Sie darauf.
Aktuell schlägt vollständig. Eine veraltete Datei, die dem heutigen Verhalten widerspricht, ist schlimmer als gar keine, weil sie eine selbstsichere falsche Antwort erzeugt statt einer Rückfrage.
Eine harte Obergrenze schlägt gute Absichten. Ohne sie wächst Kontext monoton. Nichts in einer Agentenschleife entscheidet je, dass es nun genug weiß.
Eine Aufgabe pro Fenster. Die billigste Technik des Kontextmanagements überhaupt ist, die Sitzung zu schließen.
Wie das in der Praxis aussieht
capsul context 'warum gibt der Webhook-Handler 500 zurück' --open src/app/api/polar/webhook/route.tsSetzt den Kontext zusammen und meldet, was er kostet, ohne eine Anfrage auszugeben.
Der Sinn, den Kontext separat zu bauen, ist, dass es den unsichtbaren Teil sichtbar macht. Sie sehen, was eine Aufgabe kostet, bevor Sie sich darauf einlassen, und können zwei Fassungen derselben Frage vergleichen.
Es messen
Context Engineering hat ein Ehrlichkeitsproblem, und das gehört benannt. Fast jede Behauptung in diesem Feld kommt ohne Kontrollarm, was sie unwiderlegbar macht. Wenn Sie ändern, wie Kontext zusammengesetzt wird, messen Sie dieselbe Aufgabe auf demselben Modell mit und ohne die Änderung, wiederholen Sie oft genug, um das Rauschniveau zu sehen, und veröffentlichen Sie das Intervall statt des Medians.
Fragen
Ist Context Engineering nur Prompt Engineering mit neuem Namen?
Nein. Prompt Engineering betrifft die Formulierung der Anfrage, die ein kleiner Bruchteil des Gesendeten ist. Context Engineering betrifft die übrigen über neunzig Prozent: welche Dateien, welcher Verlauf, welche Werkzeugausgaben, und was wegbleibt.
Beseitigt ein Fenster von zweihunderttausend Tokens das Problem?
Es beseitigt die Obergrenze, nicht das Problem. Die Trefferquote sinkt weiter mit der Menge, Widersprüche verwirren weiter, und Sie zahlen weiter jeden Token in jeder Runde.
Wie groß sollte ein Kontextbudget sein?
Klein genug, um eine Wahl zu erzwingen. Die genaue Zahl zählt weniger, als überhaupt eine zu haben, denn ein Agent ohne Obergrenze füllt, was er bekommt.
Woran erkenne ich, dass eine Kontextänderung wirklich geholfen hat?
Führen Sie dieselbe Aufgabe mehrmals auf beide Arten auf demselben Modell aus und vergleichen Sie das Intervall statt eines einzelnen Laufs. Agentensitzungen rauschen genug, dass ein einzelner Vorher-Nachher-Vergleich fast nichts bedeutet.
$ npm i -g @penra/capsul