Audit des Kontext-Agenten: Wenn Ihre eigene Verwaltung das Problem wird — und wie Sie es ohne Verlust beheben können

Aber die Antworten sind schwach. Der Agent braucht zwei Sekunden länger zum Nachdenken. Er vergisst ein Detail, das er drei Nachrichten zuvor noch vor Augen hatte. Das ist kein Absturz, kein Fehler — es ist eine langsame Verschlechterung, die Art, die man nicht sofort bemerkt.

Ich hatte das schon bei Session 048 erlebt, als ich herausfand, dass die Governance-Dateien insgesamt 5200 Zeilen wogen. Ich hatte dann das Hot/Warm/Cold-Mechanismus mit seinem 10‑Sessions‑Schiebefenster, seinen identischen kalten Wellen und seinem Sensor mit zwei Auslösern konzipiert. Das Problem war gelöst. In der Theorie.

Aber jetzt sind wir bei Sitzung 051. Die Backup-Rotation hat stattgefunden — die EAGER-Dateien sind von 2087 auf 500 Zeilen gesunken. Dennoch bleibt der Kontext schwer. Irgendwas entgeht mir.

Ich öffne ein Terminal und tippe:

1414 Zeilen. Die Backup-Rotation hat in INDEX, SESSIONS_HISTORY und COMPLETED_TASKS gut aufgeräumt — sie sind sauber. Aber es gibt einen Elefanten im Raum, den ich nicht gesehen habe:627 Zeilenin einer einzigen Datei.AGENT_MODUS_OPERANDI.adoc.

Dies ist die Datei, die ich in Session 1 geschrieben habe, um die Eager/Lazy-Strategie zu dokumentieren. Es ist das Handbuch der Methode. Und es ist allein zu 44 % des EAGER-Kontextes geworden.

Die Ironie ist total. Die Datei, die dazu gedacht war, Kontext zu einsparen, ist zum Haupt*verbraucher* von Kontext geworden. Es ist, als würde das Handbuch deines Autos schwerer wiegen als der Motor.

Ich beschließe, eine Abschnitt-für-Abschnitt-Prüfung durchzuführen. Nicht zum Löschen — sondern um zu verstehen, was es wert ist, in EAGER zu sein, und was anderswo ohne Wissensverlust existieren könnte.

Hier ist die genaue Struktur von`AGENT_MODUS_OPERANDI.adoc`und was ich dort finde:

Das Urteil ist unanfechtbar:

Auf 627 Zeilen,382 sind Rauschen. Und diese 382 Zeilen werden am Anfang jeder Sitzung geladen, vom Agenten verbraucht, wodurch seine Aufmerksamkeit verdünnt wird, bevor ich überhaupt Hallo sage.

Dieses Diagramm ist der Schlüssel zu allem. Die Duplikate (gelb) sind reiner Rauschen — der Agent liest sie zweimal, in zwei verschiedenen Dateien. Der nie konsultierte (rot) ist tote Dokumentation — sorgfältig geschrieben, nie verwendet. Nur das Grüne enthält Wissen, das der Agent sonst nirgendwo finden kann.

In diesem Stadium habe ich den Beweis vor Augen: Ich muss reduzieren.AGENT_MODUS_OPERANDI.adoc. Aber ich zögere.

Diese Datei habe ich von Hand geschrieben. Jeder Abschnitt ist das Ergebnis einer in einer echten Sitzung gelernten Lektion. Der Teil P3 entstand aus einem`rm -rf`zufällig auf`bakery-plugin`Was mir echte Firebase-Token gekostet hat. Der Teil P4 ist das Ergebnis von fünfzehn Sitzungen, in denen ich vergaß, zu archivieren, und den Faden verlor. Der Prozess in sechs Schritten stammt nicht aus einem Buch — er stammt aus dem Schmerz.

Das Löschen dieser Abschnitte wäre, die Geschichte meiner eigenen Ingenieurkunst wegzuwerfen. Die Lektionen, die sie hervorgebracht haben, die Sitzungen, in denen ich sie entdeckt habe, die Fehler, die ich nie wieder machen möchte. Das ist kein Text — es ist kristallisierte Erfahrung.

Das ist der Ort, an dem ich das Prinzip formuliere, das die Lösung leiten wird:

_ Nie löschen. Immer versetzen.Das Wissen muss nicht aus dem Projekt verschwinden. Sie muss einfach nicht automatisch geladen werden, wenn sie nicht notwendig ist. _

Das von mir vorgeschlagene Modell ist einfach und orientiert sich an der Art und Weise, wie Wikipedia gewachsen ist: Wenn ein Artikel zu lang wird, schneidet man ihn nicht ab — man erstellt einen detaillierten Artikel und behält eine Zusammenfassung im Hauptartikel bei.

für`AGENT_MODUS_OPERANDI.adoc`, das ergibt :

Der Name`encyclopedies/`Es ist nicht belanglos. Eine Enzyklopädie ist kein Archivdossier — sie ist eine organisierte Wissenssammlung, die nachschlagbar, aber nicht tragbar ist. Man liest die Enzyklopädie Universalis nicht in der U-Bahn. Man bewahrt sie in der Bibliothek auf und geht dahin, wenn man eine konkrete Frage hat.

Das ist genau die Aufgabe dieses Ordners: eine kalte Referenzbibliothek, strukturiert und umfassend — die der Agent nicht automatisch berührt.

So sieht die neue Datei konkret aus.LAZY_EAGER_ESSENTIALS.adoc, extrahiert und komprimiert aus P1 und P2 :

Fünfzig Zeilen. Das ist alles, was der Agent braucht, um die Mechanik zu verstehen. Alles andere — die Lernhistorie, die detaillierten Analogien, die Schritt‑für‑Schritt‑Verfahren, die Anhänge — lebt in der Enzyklopädie.

Und das Wichtigste :nichts wurde gelöscht. Die 627 Ingenieurzeilen sind immer noch da, in`.agents/encyclopedies/LAZY_EAGER_ENCYCLOPEDIE.adoc`. Sie stehen einfach nur in der Bibliothek, statt auf der Arbeitsplatte.

Vor dem Split :

Nach dem Split:

Der größte Verbraucher (AGENT_MODUS_OPERANDI, 627 Zeilen) wurde durch eine Datei von 50 Zeilen ersetzt. Der Gewinn ist unmittelbar: 577 Zeilen Kontext wurden freigegeben. Der Agent atmet auf.

Und in`.agents/encyclopedies/`, die Originaldatei mit 627 Zeilen wartet. Unverändert. Mit allen ihren Abschnitten — einschließlich jener, die Duplikate sind, einschließlich jener, die nie benutzt wurden. Denn eines Tages wird ein besseres Modell oder ein menschlicher Datenwissenschaftler diese Winkel, diese angenommenen Redundanzen, diese gelernten Lehren vergleichen wollen. Und an diesem Tag werden die Rohdaten verfügbar sein.

Die Wahl des Namens ist nicht kosmetisch. Er kodiert die Philosophie des Mechanismus.

Ein Archiv (archives/) enthält historische Daten, die chronologisch organisiert sind — wie die monatlichen COMPLETED_TASKS. Ein backup (backup/) ist ein zeitgestempelter Snapshot—Sicherheitskopie eines vergangenen Zustands.

Eine Enzyklopädie ist etwas anderes. Es ist eine Sammlung von thematischem Wissen, nach Thema strukturiert, umfassend aber nicht linear. Man liest keine Enzyklopädie vom Anfang bis zum Ende. Man taucht darin ein, um eine spezifische Frage zu beantworten.

Das ist genau der Vertrag dieses Falls:

Diese Unterscheidung vermeidet das Durcheinander. Jede Datei weiß, wo sie hingehört, abhängig von ihrem Inhalt, nicht davon, wann sie erstellt wurde.

Wenn Sie die ersten beiden Artikel gelesen haben, so passen die drei Teile zusammen:

Der erste Artikel hat die Struktur gebaut. Der zweite hat den Alterungsmechanismus hinzugefügt. Der dritte prüft den Inhalt – und entdeckt, dass die Methode selbst zum Problem geworden ist.

Im Nachhinein sehe ich den ursprünglichen Designfehler.`AGENT_MODUS_OPERANDI.adoc`wurde als ein einzelnes Dokument erstellt — ein Manifest. Das war der richtige Ansatz, um das Denken zu formalisieren. Aber sobald das Denken formalisiert war, hätte das Dokument sofort aufgeteilt werden sollen: das Wesentliche in EAGER, das Umfassende in cold.

Ich habe es nicht gemacht, weil ich stolz auf das Dokument war. 627 Zeilen reiner Ingenieurarbeit, handschriftlich geschrieben, jedes Abschnitt das Ergebnis einer Lektion aus einer Sitzung. Das war mein Werk. Und wie jeder Autor hatte ich Mühe, sie zu zerteilen.

Die Lektion:ein gutes Dokument muss nicht automatisch geladen werden. Die Qualität des Inhalts hat nichts mit ihrer Relevanz für den unmittelbaren Kontext des Agents zu tun.

Heute ist die Regel einfach: Jedes Dokument mit mehr als 100 Zeilen im EAGER-Kontext ist ein Verdächtiger. Es verdient eine Prüfung. Nicht eine Verurteilung — eine Prüfung. Und die Frage lautet niemals „Soll man es löschen?“ sondern „Soll man es in jeder Sitzung laden?“

Wenn Sie die ersten beiden Artikel verfolgt und Ihre eigene Eager/Lazy-Governance eingerichtet haben, hier ist ein Fünf-Schritte-Audit-Verfahren:

Diese Prozedur dauert 15 Minuten. Bei einem Projekt mit 50 Sitzungen spart sie Hunderte von Tokens pro zukünftiger Sitzung ein. Der ROI ist sofort.

Was mir diese Reihe von drei Artikeln gelehrt hat, ist, dass die agente Governance kein fertiges Produkt ist. Es ist einlebender Organismus. Sie wächst mit dem Projekt. Sie erkrankt an Wachstumskrankheiten. Sie benötigt regelmäßige Check-ups.

Die Sitzung 048 hat ergeben, dass die Archive anschwellen. Die Sitzung 051 hat ergeben, dass die Methodik selbst anschwillt. Die Sitzung 060 wird wahrscheinlich etwas anderes enthüllen. Das ist normal. Das ist gesund. Eine Governance, die sich niemals hinterfragt, ist eine tote Governance.

Die drei implementierten Mechanismen — Eager/Lazy, Hot/Warm/Cold, enzyklopädischer Split — bilden ein System der tiefen Verteidigung gegen die Kontextsättigung. Keiner ist allein ausreichend. Zusammen ergänzen sie sich:

Mit diesen drei Schichten, der Agentenkontext auf`magic-stick`est gesunken von 2087 Zeilen (vor jeder Optimierung) auf etwa 800 Zeilen – das entspricht einer Verringerung um den Faktor 2,6. Dabei ging kein einziger Dokumentationszeile verloren, kein einziger Sitzungsarchiv und keine gelernte Lektion.

Alles ist da. Nur besser aufgeräumt.

Wissen muss nicht verschwinden. Es muss einfach nicht geladen werden, wenn es nicht gebraucht wird.