DDDFXYqiming/Agent_Extensions

Gedächtnisverwaltung (DSH-Version)

Sitzungsübergreifendes Langzeitgedächtnis: L1-Index-Injektion (bei jeder Runde sichtbar) + L2-Umgebungsfakten + L3-Aufgabenerfahrung.

Auslösezeitpunkte

Lesen (Wann wird das Gedächtnis abgefragt?)

• Zu Beginn einer neuen Aufgabe: Wenn die Aufgabe die lokale Umgebung, Tool-Konfigurationen, einen bestimmten Technologie-Stack oder ähnliche frühere Aufgaben betrifft → zuerst memory_list um zu sehen, was vorhanden ist, dann memory_read um relevante Einträge abzurufen.
• Bei Schwierigkeiten/Problemen: memory_read um nach relevanten SOPs zu suchen (Stichwortabgleich mit Dateinamen in sops/ oder Abschnitten in facts).
• Gedächtnisindex im Modell-Prompt (memory:index): Der bei jeder Runde sichtbare L1-Existenzindex – wenn verwandte Stichwörter gesehen werden, sollte aktiv memory_read/memory_list aufgerufen werden, um Details abzurufen.

Schreiben (Wann wird das Gedächtnis gefestigt?)

Wenn eine Aufgabe abgeschlossen (oder ein Teilabschnitt abgeschlossen) ist und durch Aktionen verifizierte, erfolgreiche Informationen vorliegen, wird memory_write aufgerufen:

Schreibbar (muss mit einem evidence-Beleg versehen sein):

• Umgebungsspezifische Fakten: Pfade, Konfigurationen, getestete Parameter, Tool-Verhalten (→ entry_type: fact)
• Erfahrungen mit komplexen Aufgaben: Stolpersteine, die nur nach mehreren Wiederholungen erfolgreich waren, versteckte Vorbedingungen, stabile Schritte (→ entry_type: sop)
• Allgemeine rote Linien/Muster (→ können auch per memory_write sop oder durch direkte Pflege in [RULES] festgehalten werden)

Nicht schreibbar (Schreiben wäre eine Verunreinigung):

• ❌ Informationen ohne Bestätigungsbeleg (keine Aktion, keine Erinnerung)
• ❌ Im Modell inhärentes Wissen, logische Schlussfolgerungen, unbestätigte Hypothesen
• ❌ Veränderliche Zustände: Zeitstempel, PIDs, temporäre Pfade, einmalige IDs
• ❌ Allgemeinwissen, Protokolle, Details des Schlussfolgerungsprozesses

Index-Synchronisation

• memory_write synchronisiert den L1-Index automatisch; manuelle Eingriffe sind normalerweise nicht nötig.
• Nach manuellen Änderungen an facts.md / den sops/-Dateien → memory_index aufrufen, um den Index neu aufzubauen.
• Wenn der Index 30 Zeilen überschreitet: [RULES] straffen (Wortänderungen vornehmen, kein Überschreiben des gesamten Textes).

Speicherstruktur

<home>/.dsh/memory/
├── memory_management_sop.md   L0-Metaregeln (wie das Gedächtnis verwaltet wird)
├── index.txt                  L1-Index (≤30 Zeilen: L2/L3-Existenzliste + RULES)
├── facts.md                   L2-Umgebungsfakten (## SECTION)
├── sops/*.md                  L3-Aufgabenerfahrungen
└── file_access_stats.json     Lesezugriffsstatistik

Werkzeuge

Werkzeug	Zweck
memory_list	Alle Erinnerungen auflisten (Fakten + SOPs + Indexzeilenanzahl)
memory_read	Bestimmte Erinnerung lesen (Index / Fact-Thema / SOP-Dateiname)
memory_write	Erinnerung schreiben (Fact/SOP, evidence ist Pflicht)
memory_index	L1-Index-Autosegment neu aufbauen

Prinzipien

1. Aktionsvalidierung: Keine Ausführung, keine Erinnerung. Es werden nur erfolgreich verifizierte Informationen geschrieben.
2. Minimal ausreichend: Der Inhalt sollte so kurz wie möglich sein; es werden nur Informationen gespeichert, deren Vergessen zu kostspieligen Wiederholungen führen würde.
3. Keine Änderung oder Löschung verifizierter Fakten: Sie können komprimiert oder verschoben werden, aber nicht verworfen.
4. Aktives Schreiben: Das Schreiben von Erinnerungen wird immer vom Modell/Benutzer initiiert; es erfolgt keine automatische Änderung der Konfiguration oder Installation von Plugins.