context window

Wer schreibt das Kontextfenster?

Gerade jetzt steckt irgendwo ein Agent mitten in seiner Schleife. In seinem Kontextfenster liegen Zehntausende Token. Ein paar hundert davon hat ein Mensch geschrieben, den System Prompt und die ursprüngliche Aufgabe, und ist dann gegangen. Alles andere hat sich in den letzten Millisekunden selbst zusammengesetzt: von der Platte gelesene Dateien, die Ergebnisse des letzten Tool-Aufrufs, eine komprimierte Erinnerung an frühere Runden, die Schemas für alles, was der Agent anfassen darf. Im nächsten Durchlauf wird das meiste davon verworfen und neu aufgebaut. Was dieses Fenster schreibt, ist kein Mensch. Es ist ein Programm, das denselben Zusammenbau tausendfach wiederholt, während niemand zusieht.

Es gibt ein beliebtes Diagramm, das genau das nicht sehen kann.

Sie kennen es, oder einen seiner Verwandten. Drei konzentrische Ringe. In der Mitte Prompt Engineering: wie man die Anweisung formuliert. Darum herum Context Engineering: was sonst noch ins Fenster kommt, also abgerufene Dokumente, Verlauf, Tool-Definitionen. Darum herum der Harness: die Schleife, die Leitplanken, die Ausführung der Tools. Das Ganze läuft auf eine ordentliche Gleichung hinaus. Agent gleich Modell plus Harness. Das ist ein redlicher Versuch, ein Feld zu ordnen, das sich schneller bewegt als sein eigenes Vokabular. Gezeichnet ist es allerdings von der Entwurfsoberfläche her, nicht vom laufenden System. Man erkennt das daran, dass die Ringe nach dem falschen Merkmal sortiert sind. Sie gehen nach Umfang: kleine Dinge in der Mitte, große am Rand.

Umfang ist die falsche Achse. Sie legt gleiche Arbeit in verschiedene Ringe und Unzusammenhängendes in denselben. So sieht eine Karte aus, die von anderen Karten abgezeichnet wurde statt vom Gelände. Die Achse, auf die es ankommt, fragt nicht, wie groß die Arbeitseinheit ist. Sie fragt, wer die Arbeit erledigt, und wann. Es gibt zwei Regime und eine Linie dazwischen. Oberhalb der Linie sitzt ein Mensch und verfasst Text für einen einzelnen Austausch. Er feilt am Prompt. Er wählt aus, was er hineinkopiert. Er liest die Ausgabe und entscheidet, was er als Nächstes schickt.

Das ist Handwerk, von Hand erledigt, eine Interaktion nach der anderen. Unterhalb der Linie passiert nichts davon, weil niemand da ist. Ein Programm verfasst den Text. Es läuft in jeder Runde einer Schleife, die Stunden dauern kann, und trifft dieselben Entscheidungen wie ein Mensch (was hinein soll, was wegkommt, was an den Anfang gehört), in einem Takt, den kein Mensch halten könnte, und auf Eingaben, die nie ein Mensch zu Gesicht bekommt. Prompt Engineering liegt oberhalb der Linie. Ebenso das Context Engineering, das man sich tatsächlich vorstellt, wenn man das Wort ausspricht: ein Mensch, der entscheidet, was er hineinkopiert, abruft, zusammenfasst oder weglässt.

Der Harness liegt darunter. Und genau das stellen die Ringe auf den Kopf. Unterhalb der Linie ist Context Engineering nicht etwas Kleineres, das im Harness steckt. Es ist das, was der Harness tut. Was ins Fenster kommt, in welcher Reihenfolge, in welcher Detailtreue und was verdrängt wird, um Platz zu machen: Das ist in jeder beliebigen Runde der größte Teil der Arbeit eines Harness. Der Harness ist keine Schicht rund um das Context Engineering. Er ist Context Engineering, automatisiert und in Gang gesetzt.

Der Mensch hört nicht auf zu arbeiten. Die Arbeit ändert ihre Form. Sie kuratieren kein Fenster mehr; Sie schreiben das Regelwerk, nach dem ein Fenster kuratiert wird, in jeder Runde, ohne Sie. Das ist eine andere Aufgabe, und genau sie meint „Harness Engineering“ eigentlich.

Sehen Sie einem Harness beim Laufen zu, und die Umkehrung ist nicht mehr abstrakt. Stellen Sie sich eine einzelne Runde vor. Im Fenster liegen die ursprüngliche Aufgabe, die aktuelle To-do-Liste, der Diff der letzten Änderung, drei Quelldateien, die das Modell sehen wollte, und das Schema für ein einziges Shell-Tool. Das Modell führt einen Befehl aus. Er schlägt fehl. Das Fenster der nächsten Runde ist nicht mehr dasselbe. Die zwei Quelldateien, die sich als irrelevant herausgestellt haben, sind weg. Das Fehlerprotokoll ist drin. Die Überlegungen der vorigen Runde sind auf eine zweizeilige Zusammenfassung eingedampft, und ein anderes Tool steht jetzt zur Verfügung. Die Aufgabe hat sich nie geändert. Der Prompt hat sich kaum bewegt. Das Fenster wurde neu gebaut.

Nehmen Sie den Ralph Loop, Geoffrey Huntleys Muster, einen Agenten aus einer Bash-Schleife heraus zu steuern. Seine prägende Entscheidung ist Zustandslosigkeit, und zwar nicht die der Arbeit, die auf der Platte erhalten bleibt, sondern die des Kontextfensters, das bei jeder Iteration zurückgesetzt wird. Der Agent bekommt nichts, woran er sich erinnert, weil er sich an nichts erinnert: Die Schleife baut den Arbeitskontext aus dem Dateisystem neu auf, speist ihn frisch ein, führt einen Durchgang aus, lässt den Agenten seine Änderungen auf die Platte zurückschreiben und wirft das Fenster weg. Dann beginnt alles von vorn.

Achten Sie darauf, wo die Kontinuität der Arbeit liegt. Der Prompt am Kopf der Schleife ändert sich zwischen den Iterationen kaum. Das Modell steht fest. Was sich ändert und die Arbeit weiterträgt, ist der Zustand auf der Platte und die Disziplin, mit der die Schleife ihn jedes Mal wiederherstellt. Nehmen Sie die Schleife weg, und Sie haben ein Modell, das zwischen den Runden alles vergisst. Nehmen Sie das Modell weg, und Sie haben immer noch eine präzise Theorie davon, welchen Kontext diese Aufgabe braucht und wie man ihn aus dem Nichts wieder aufbaut. Der Ralph Loop ist eine Maschine für Context Engineering, bei der das Modell fast vollkommen stillgehalten wird.

Skills machen denselben Zug aus der anderen Richtung. Ein Skill ist ein Bündel von Anweisungen, das der Agent nur lädt, wenn die Aufgabe danach verlangt; den Rest der Zeit kommt es gar nicht ins Fenster. Der Harness liest die Situation, entscheidet, dass dieser Skill dazugehört und jene vierzig nicht, und lässt nur zu, was die Aufgabe braucht. Wo der Ralph Loop den Kontext durch Rekonstruktion neu aufbaut, verwaltet ein Skill ihn durch selektive Zulassung: Das Fenster bleibt klein, nicht weil wenig existiert, sondern weil der Harness alles zurückhält, was sich seinen Platz darin nicht verdient hat.

Zwei Mechanismen, gegenläufig in der Bewegung, gleich in der Art. Beide sind der Harness, der entscheidet, was das Modell zu sehen bekommt. Das ist derselbe Akt, den ein Mensch von Hand vollzieht, wenn er einen Prompt kuratiert, nur an ein Programm übergeben, ausgeführt im Tempo des Programms und nach dessen Urteil. Es gibt einen Grund, warum der Bereich unterhalb der Linie existiert, und das Feld hatte ihn die ganze Zeit in der Hand. Es hat ihn nur falsch abgelegt.

Meta-Prompting war die erste Fassung dieses Zugs, im kleinstmöglichen Maßstab. Die Idee war bescheiden: den Prompt nicht mehr von Hand schreiben, sondern etwas schreiben, eine Vorlage oder ein Modell, das den Prompt für Sie schreibt. Das galt als cleverer Trick, verstaut im Prompt Engineering. Eine Fußnote.

Aber die Fußnote war das Muster. Man nimmt ein Stück Kontextbau, das ein Mensch bisher von Hand erledigt hat, und gibt es einem Programm. Meta-Prompting hat das für den Prompt getan. Der Harness tut es für alles andere (die abgerufenen Dokumente, das Gedächtnis, die Tool-Ergebnisse, die Reihenfolge, die Verdrängung), und zwar nicht einmal, sondern in jeder Runde einer laufenden Schleife. Der Harness verhält sich zum Context Engineering wie Meta-Prompting zum Prompting: dieselbe Aufgabe, aus menschlichen Händen genommen und einer Maschine übergeben.

Die Ringe waren also nie Stufen des Umfangs. Sie waren Standbilder einer Wanderung, und Meta-Prompting, die Fußnote, war das erste Bild. Legen Sie die Etappen nebeneinander: Prompt von Hand, dann Meta-Prompting, dann Context Engineering, dann der Harness. Das ist keine Hierarchie der Größen. Es ist dieselbe Arbeit, die dieselbe Linie überquert, ein Stück Kontextfenster nach dem anderen, von der Seite, auf der ein Mensch sie erledigt, auf die Seite, auf der ein Programm sie erledigt. Das Diagramm hat die Bewegung in einem einzigen Moment erwischt und das Standbild für eine Struktur gehalten.

Die Linie liegt nicht fest. Sie wandert, seit zum ersten Mal jemand einen Prompt automatisiert hat, und sie wandert nur in eine Richtung: nach unten. Jedes Jahr wechselt mehr von der Arbeit, die früher darüber lag (von einem Menschen, von Hand, für eine einzelne Interaktion erledigt), auf die Seite, auf der ein Programm sie laufend und ungesehen erledigt. Den Anfang machte das Abrufen. Das Gedächtnis folgte. Reihenfolge, Zusammenfassung und Verdrängung wechseln gerade hinüber.

Die Frage, die das Diagramm hätte stellen sollen und nicht gestellt hat, lautet also nicht, wie die Schichten aufeinanderliegen. Sie lautet, wie viel auf der menschlichen Seite der Linie noch übrig ist und was aus dieser Seite wird, wenn der Harness seinen eigenen Kontext besser zusammenstellen kann als jedes Regelwerk, das Sie dafür schreiben könnten. Lange schreibt dieses Fenster niemand mehr von Hand.

Aus dem Englischen übersetzt: zum Originalbeitrag

Gestalten Sie die Zukunft Ihres Unternehmens mit KI

Tauchen Sie ein in unsere spannenden Workshops und rüsten Sie Ihr Team mit den Werkzeugen und dem Wissen aus, um im Zeitalter der KI führend zu sein.

Kontaktieren Sie uns
Scroll to top