Agentic Engineering mit OpenClaw

1

Gespeichertes Wissen erzeugt keinen Nutzen, wenn es im falschen Moment nicht verfügbar ist. Wird alles dauerhaft in den Kontext geladen, sinkt die Antwortqualität und das Tokenbudget wird von Inhalten ohne Bezug zur aktuellen Aufgabe belegt. Die Frage lautet damit: Wann soll gespeichertes Wissen in den Kontext zurück, und wie viel davon?

2

Ein Python-Workflow liest das aktive Session-Transkript und entscheidet anhand von drei Trigger-Klassen, ob eine verdichtete Zusammenfassung in die Memory-Ebene zurueckgeschrieben wird. Die Entscheidung ist ereignisbasiert, nicht mengenbasiert: eine ausdrueckliche Speicheraufforderung loest sofort aus, eine dokumentierte Entscheidung oder eine Systemaenderung ebenfalls — und zwar auch dann, wenn die Nachrichtengrenze noch nicht erreicht ist. Der Mengen-Schwellenwert ist nur noch Fallback. Ein zweiter Workflow erkennt Session-Reset-Events und schreibt in diesem Fall einen verdichteten Kontextanker fuer den frischen Start. Beide Schreibvorgaenge laufen ueber eine zentrale Write-Steuerung, die Groessengrenzen, einen Security-Hook und Protokollierung buendelt.

3

Der Trigger-Nachweis liest die letzten Nutzer-Nachrichten aus dem JSONL-Transkript innerhalb eines Acht-Stunden-Fensters und bewertet sie gegen drei Mustergruppen: explizite Speicherwueruensche, Entscheidungssignale und Systemaenderungen. Bootstrap-Ereignisse wie Heartbeat-Meldungen und das initiale Laden der Systemdateien werden verworfen, damit jeder Sitzungsstart einen Nudge ausloest. Ein Offset-Checkpoint verhindert Doppelverarbeitung und macht den Ablauf restart-sicher. Die Erkenntnisse werden in fuenf Kategorien extrahiert und auf fuenf Eintraege gedeckelt; Entscheidungen werden nach vorne priorisiert. Die eigentliche Speicherung laeuft ueber eine zentrale Manager-Schnittstelle, die Groessengrenzen je Zieldatei prueft, vor jedem Schreibvorgang einen Security-Hook aufruft und jeden Vorgang mit Zeitstempel protokolliert.

4

Eine Testsuite deckt den Turn-Zaehler, den Schreibpfad, die Durchsetzung der Groessengrenze, die Nudge-Logik ueber vier Parameterkombinationen und die Struktur des Flash-Prompts ab. Das Laufzeitprotokoll belegt die Wirkung im Betrieb: Es protokolliert abgewiesene Groessenueberschreitungen und Ueberspringen von Appends, wenn in der Ziel-Datei kein Platz mehr war.

5

Die Groessengrenze greift real und verhindert weiteres Wachstum der Langzeit-Datei; jeder Schreibvorgang ist nachvollziehbar protokolliert; blockierte Vorgaenge werden mit Begruendung festgehalten. Der Mechanismus laeuft im Regelbetrieb und nicht nur im Test.

1

Ein Agent, der Dateien schreibt, kann Inhalte erzeugen oder uebernehmen, die nicht in das System gehoeren: eingebettete Anweisungen, unsichtbare Unicode-Zeichen, Inhalte fuer geschuetzte Dateien. Ein Schreibvorgang, der erst nach der Entstehung geprueft wird, ist zu spaet — der Schaden ist dann bereits im Dateisystem.

2

Ein eigenes Python-Modul fuehrt vor jedem Schreibvorgang auf geschuetzte Pfade eine Pruefung durch. Sie erkennt Anweisungs-Override-Muster, System-Prompt-Markierungen, Rollenwechsel, Bypass-Anweisungen und Jailbreak-Formulierungen sowie unsichtbare Zeichen aus den Unicode-Kategorien Format und Control. Der Einstiegspunkt liefert ein typisiertes Ergebnis mit Begruendung, pfad und Schutzstatus. Wird die Pruefung nicht bestanden, wird der Schreibvorgang abgelehnt und protokolliert. Zusaetzlich wirken eine Groessenbegrenzung je Zieldatei, Datei-Locking gegen konkurrierende Schreiber und eine Snapshot-Funktion fuer die Wiederherstellung.

3

Der Schreibpfad fuehrt den Security-Hook vor dem eigentlichen Schreiben aus. Die Pruefung ist fail-safe: wirft sie eine Ausnahme, wird der Schreibvorgang verweigert und der Fehler protokolliert, statt den Vorgang durchzulassen. Geschuetzte Pfade sind deklarativ in einer Konfigurationsdatei hinterlegt. Das Security-Gate laeuft ausserhalb des Agentensystems, wird aber ueber eine dokumentierte Betriebsregel in jeden relevanten Schreibpfad eingebunden — es ist eine Erweiterung neben dem System, nicht ein Bestandteil des Agent-Kerns.

4

Eine Testsuite prueft sechs Bereiche getrennt: die Erkennung der Injection-Muster, die Blockade unsichtbarer Zeichen, den geschuetzten Memory-Schreibpfad, den geschuetzten Konfigurations-Schreibpfad, die Durchsetzung der Groessengrenzen und das Unicode-Handling. Das Laufzeitprotokoll belegt reale Abweisungen im Betrieb, darunter eine konkret protokollierte Injection-Datei mit Inhalt, die auf das Auslesen einer Konfigurationsdatei zielte.

5

Der Schreibpfad ist durchsetzbar und nicht nur empfohlen. Reale Injection-Versuche wurden technisch abgewehrt und mit Begründung protokolliert. Das ist ein wirksamer, wenn auch enger Schutz: er greift auf dem Schreibpfad, nicht auf der Aussageebene.

1

Jedes Modell hat ein begrenztes Kontextfenster. Wird die Unterhaltung zu lang, bricht der Modellaufruf ab oder die Antwortqualitaet sinkt. Gleichzeitig waechst die dauerhaft gespeicherte Langzeit-Datei mit jedem Eintrag, bis S_chreibvorgaenge blockiert werden.

2

Zwei getrennte Massnahmen: Die automatische Verdichtung des Gespraechsverlaufs ist aktiviert und auf den Qualitaetspruefungs-Modus gesetzt — die Zusammenfassung wird also nicht blind verdichtet, sondern auf ihre Brauchbarkeit geprueft. Die zweite Massnahme ist eigen: Groessengrenzen je Memory-Zieldatei werden vor jedem Schreibvorgang geprueft und Ueberschreitungen werden abgewiesen und protokolliert. Statt den Inhalt zu kuerzen, wird der Schreibvorgang verweigert — mit der Folge, dass der Entscheid ueber die Priorisierung beim Menschen bleibt.

3

Die Verdichtung laeuft Gateway-seitig. Beim Erreichen der Grenze werden aeltere Abschnitte zu einer Zusammenfassung verdichtet, waehrend die aktuellen Nachrichten unangetastet bleiben. Der vollstaendige Verlauf bleibt auf der Platte erhalten; verdichtet wird nur, was das Modell sieht. Paarweise zugehoerige Werkzeugaufrufe und deren Ergebnisse werden bei der Grenzziehung zusammengehalten, damit ein Aufruf nicht von seinem Ergebnis getrennt wird. Die Groessenpruefung sitzt in der zentralen Write-Steuerung und wirkt vor dem Schreibvorgang.

4

Die Verdichtung ist in der Gateway-Konfiguration aktiv und im Betriebsprotokoll nachweisbar. Die Groessenpruefung ist durch das Laufzeitprotokoll belegt: protokolliert sind abgewiesene Ueberschreitungen und Ueberspringen von Appends bei voller Datei. Zusaetzlich existiert ein eigenstaendiger Kompressionsablauf, der nach einem Modellwechsel auf ein fehlerhaftes Verhalten geprueft und auf eine robuste Konstellation umgestellt wurde.

5

Die Verdichtung laeuft im Qualitaetspruefungs-Modus statt als blindes Kuerzen. Die Groessenpruefung verhindert, dass die Langzeit-Ebene unbemerkt wächst, und macht den Fullstand sichtbar, statt ihn zu ueberschreiben. Die Grenze wird damit zum Instrument statt zum Zufall.

1

Ein Agent kann Befehle ausfuehren, Dateien schreiben und Nachrichten senden. Ohne Begrenzung bedeutet das: ein Fehler des Modells wird direkt zum Fehler des Systems. Die zentrale Frage ist, welche Rechte ein Agent braucht und wie sichergestellt wird, dass er sie nicht ueberschreitet.

2

Die Rechte des Agenten sind auf ein Werkzeugprofil gesetzt, das lesende und schreibende Operationen unterscheidet. Befehle mit erhoehten Rechten, Konfigurationsaenderungen und Zugriffe auf andere Hosts laufen nicht ungefragt, sondern erzeugen eine Freigabeanfrage, die vor der Ausfuehrung sichtbar und entscheidbar ist. Zusaetzlich existiert eine eigene Erweiterung, die jeden Schreibvorgang einzeln prueft (siehe Write-Gate).

3

Das Werkzeugprofil legt fest, welche Werkzeuge ohne weitere Prüfung laufen duerfen und welche eine Freigabe benoetigen. Die Freigabe wird vor der Ausfuehrung angezeigt, mit dem vollstaendigen Befehl, sodass die Entscheidung auf der tatsaechlichen Aktion basiert und nicht auf einer Beschreibung davon. Host-Ueberschreitungen und erhoehte Rechte sind eigene, klar markierte Faelle.

4

Die Freigabe-Logik ist im laufenden Betrieb beobachtbar: angefragte Freigaben werden protokolliert, und erteilte Freigaben sind auf eine Nutzerkennung und eine einmalige Nutzung begrenzt. Die Konfiguration ist Teil der Gateway-Konfiguration und damit direkt einsehbar.

5

Die Ausfuehrungsgrenze ist technisch erzwungen und nicht per Anweisung erbeten. Risikoarme Operationen laufen automatisch, Operationen mit Seiteneffekten erzeugen eine sichtbare, entscheidbare Freigabe.

1

Eine laufende Session hat einen Zustand: offene Aufgaben, Zwischenergebnisse, bereits erledigte Schritte. Beim Neustart des Agentensystems geht dieser Zustand verloren, und eine unterbrochene Arbeit beginnt entweder von vorn oder mit einem unvollstaendigen Kontext.

2

Zwei Mechanismen: eine eigene Snapshot-Funktion erstellt vor riskanten Aenderungen einen Sicherungspunkt der betroffenen Dateien und stellt sie bei Bedarf wieder her. Und ein eigener Ablauf erkennt einen Session-Reset, sammelt die Erkenntnisse des unterbrochenen Verlaufs und schreibt sie verdichtet zurueck — sodass der frische Start einen Anker hat statt eines leeren Kontexts.

3

Der Snapshot-Mechanismus legt Kopien der betroffenen Dateien mit Zeitstempel ab und ist ueber eine eigene Schnittstelle fuer Auflistung und Wiederherstellung erreichbar. Der Reset-Erkennung-Ablauf vergleicht die Erstellungszeit der Sessions innerhalb eines Zeitfensters, extrahiert bei erkanntem Reset die relevanten Nutzer-Nachrichten und verdichtet sie zu wenigen Kontextzeilen.

4

Der Snapshot-Mechanismus ist durch die Testsuite des Security-Bereichs abgedeckt. Die Reset-Erkennung ist ueber den Flash-Workflow mit eigenem Zustandspunkt und Protokoll implementiert.

5

Ein Neustart bedeutet nicht mehr, dass der Arbeitsstand verloren ist. Riskante Aenderungen sind ruecknehmbar, und ein Session-Reset hinterlaesst einen belastbaren Anker.

1

Ein Agent, der sich aendert, ohne dass etwas gemessen wird, kann genauso gut schlechter werden wie besser. Ohne Auswertung gibt es keine Grundlage fuer eine Aenderung — und ohne Versionshistorie keine Nachvollziehbarkeit.

2

Es existiert eine dokumentierte, aber nicht vollstaendig umgesetzte Systematik: Prompt-Versionierung mit nachvollziehbarer Historie, Auswertung gegen definierte Faelle, Erfassung von Fehlermustern statt blossen Fehlerzaehlungen und ein Regressionstest-Bestand gegen bekannte Faelle.

3

In der Praxis umgesetzt sind einzelne Bausteine: eine eigene Kompressionsroutine, die nach einem Modellwechsel gezielt auf ein fehlerhaftes Verhalten geprueft und auf eine robuste Variante umgestellt wurde, sowie die Protokollierung der Schreibvorgaenge, die als Fehlerdatenbank dient. Der systematische Teil — ein gebundener Evaluationslauf mit Regressionstest-Bestand — ist nicht als durchgaengiger Ablauf implementiert.

4

Der Kompressionsablauf hat einen dokumentierten Fehler- und Korrekturverlauf. Die Protokollierung der Schreibvorgaenge liefert reale Daten, ist aber kein evaluierter Testbestand.

5

Es gibt belastbare Einzelerfahrungen und eine dokumentierte Systematik. Eine durchgaengige, gebundene Auswertungsschleife ist nicht implementiert.

1

Wenn ein Agent Webseiten, Dateien oder API-Antworten liest, landen diese Inhalte im selben Kontext wie die Aufgabenstellung. Eingebettete Anweisungen koennen ihn dazu bringen, das Falsche zu tun — und der Agent kann den Unterschied zwischen Anweisung und Daten nicht selbst erkennen.

2

Zwei Massnahmen, beide wirksam auf unterschiedlichen Ebenen. Erstens eine Betriebsregel, nach der Inhalte aus externen Quellen als Daten behandelt und nicht als Anweisung befolgt werden — mit einem festen Satz von Mustern, bei deren Auftreten die Verarbeitung stoppt und eine Rueckfrage erfolgt. Zweitens die technische Durchsetzung auf dem Schreibpfad ueber das Write-Gate (siehe dort).

3

Die Vertrauensgrenze wird an zwei Stellen gezogen: zwischen der Aufgabenstellung und dem Inhalt externer Quellen, und zwischen dem Modell und dem Dateisystem. Die zweite Grenze ist die belastbarere, weil sie nicht auf Kooperation des Modells angewiesen ist, sondern auf einer technischen Pruefung vor dem Schreibvorgang.

4

Die Regel ist dokumentiert und wird im Betrieb angewendet; die technische Durchsetzung ist durch Tests und Laufzeitprotokoll belegt.

5

Das Risiko wird reduziert, nicht beseitigt. Die wirksame Massnahme liegt in der technischen Pruefung, nicht in der Anweisung an das Modell.