RichardandClaude Opus 4.8
4747835fa1
Geplante Agenten begannen bei jedem Cron-Lauf bei null. Ein Agent, der alle 30 Minuten lief, wusste nichts von seinem letzten Durchgang — er rief dieselben Quellen ab, zog dieselben Schluesse und konnte keine Entwicklung ueber Zeit verfolgen. Das war zugleich die groesste Faehigkeitsluecke und eine dauerhafte Token-Verschwendung. Speicher-Fundament SqliteStorage buendelt den Zugang zur Instanz-Datenbank und aktiviert WAL, busy_timeout und Connection-Pooling. Vorher oeffnete jeder Aufruf eine Verbindung ohne diese Einstellungen; bei mehreren gleichzeitig schreibenden Agenten gab das "database is locked". Das sah nach einer Grenze von SQLite aus, war aber nur fehlende Konfiguration. Zwei Tests decken das gezielt ab. Gedaechtnis Typisierte Tabelle statt JSON in einer Wert-Spalte — nur so laesst sich filtern, sortieren und spaeter auswerten. Das Schema ist schlicht gehalten, damit eine MySQL-Variante spaeter dieselbe Struktur mit wenigen Dialektunterschieden bekommen kann. Der wichtigste Teil ist der optionale Schluessel: Erneutes Merken darunter aktualisiert den Eintrag, statt einen zweiten anzulegen. Ohne das wuechse das Gedaechtnis eines halbstuendlich laufenden Agenten um 48 Eintraege pro Tag zur selben Sache. Beobachtungen ohne Schluessel sammeln sich weiterhin an, wenn ein Verlauf entstehen soll. Der Abruf sortiert nach Wichtigkeit, dann Aktualitaet — wesentlich, weil das Ergebnis begrenzt wird und bei einer Kappung das Wichtigste ueberleben muss. Zusaetzlich greift eine Zeichenobergrenze, damit ein Abruf den Kontext nicht sprengt. Die Trennung privat/geteilt ist absichtlich dieselbe wie beim FileRW-Tool, damit das Konzept fuer Agenten wiedererkennbar bleibt. Beim Testen fiel auf, dass das Maskieren der LIKE-Platzhalter falsch war: Die Zeichen wurden entfernt statt maskiert, wodurch eine Suche nach einem Prozentzeichen zu einem leeren Muster und damit zu einem Treffer auf alles wurde. Jetzt mit ESCAPE-Klausel. 338 Tests gruen (190 Core, 148 Tools). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
73 lines
3.3 KiB
Markdown
73 lines
3.3 KiB
Markdown
# Memory — Langzeitgedächtnis für Agenten
|
||
|
||
Löst K1 aus der [Bestandsaufnahme](Bestandsaufnahme-2026-07.md): Geplante Agenten
|
||
begannen bei jedem Cron-Lauf bei null. Ein Agent, der alle 30 Minuten lief, wusste
|
||
nichts von seinem letzten Durchgang — er rief dieselben Quellen ab, zog dieselben
|
||
Schlüsse und konnte keine Entwicklung über Zeit verfolgen.
|
||
|
||
## Warum nicht der vorhandene State-Store
|
||
|
||
`IStateStore` ist eine Schlüssel-Wert-Tabelle für kleine Marker („zuletzt gesehene ID").
|
||
Ein Gedächtnis darin abzulegen hieße, JSON in eine `Value`-Spalte zu schreiben — damit
|
||
lässt sich nichts filtern, sortieren oder auswerten.
|
||
|
||
Deshalb typisierte Spalten in einer eigenen Tabelle. Das Schema ist bewusst schlicht
|
||
gehalten, damit eine MySQL-Variante später dieselbe Struktur mit wenigen
|
||
Dialektunterschieden bekommen kann.
|
||
|
||
## Modell
|
||
|
||
| Feld | Zweck |
|
||
|---|---|
|
||
| `Scope` | `agent` (privat) oder `shared` (alle Agenten der Instanz) |
|
||
| `Subject` | Worum es geht — Ticker, Kunde, Projekt |
|
||
| `Key` | **Optional.** Erneutes Merken darunter *aktualisiert* statt anzulegen |
|
||
| `Category` | `fact`, `decision`, `observation`, `task`, `contact`, `other` |
|
||
| `Tags` | Schlagworte zum Wiederfinden |
|
||
| `Importance` | 1–5, steuert die Reihenfolge beim Abruf |
|
||
| `CreatedBy` | Bleibt auch im geteilten Bereich sichtbar |
|
||
|
||
Die Scope-Trennung ist absichtlich dieselbe wie beim `FileRW`-Tool (`personal`/`shared`) —
|
||
für Agenten bleibt das Konzept dadurch wiedererkennbar.
|
||
|
||
## Der Schlüssel ist das Wichtigste
|
||
|
||
Ohne ihn wüchse das Gedächtnis eines alle 30 Minuten laufenden Agenten um 48 Einträge
|
||
pro Tag zur selben Sache. Mit `key='kursziel_nvda'` bleibt es **ein** Eintrag, der
|
||
sich fortschreibt — das Anlagedatum bleibt erhalten, nur `UpdatedAt` wandert.
|
||
|
||
Beobachtungen ohne Schlüssel sammeln sich weiterhin an; das ist gewollt, wenn ein
|
||
Verlauf entstehen soll.
|
||
|
||
## Abruf
|
||
|
||
Sortiert nach Wichtigkeit, dann Aktualität. Das ist wesentlich, weil das Ergebnis
|
||
begrenzt wird: Bei einer Kappung muss das Wichtigste überleben.
|
||
|
||
Zusätzlich greift eine Zeichenobergrenze (8.000 Zeichen) — ein Abruf darf den Kontext
|
||
nicht sprengen, dieselbe Überlegung wie bei der Tool-Ergebnis-Kappung (T2).
|
||
|
||
## Speicher-Fundament
|
||
|
||
`SqliteStorage` bündelt den Zugang zur Instanz-Datenbank:
|
||
|
||
- **WAL** — beliebig viele Leser parallel zu einem Schreiber
|
||
- **busy_timeout** — ein Schreiber wartet kurz, statt sofort zu scheitern
|
||
- **Connection-Pooling** — kein Verbindungsaufbau je Aufruf
|
||
- **Schreib-Warteschlange im Prozess** — macht Fehlerbilder reproduzierbar
|
||
|
||
Vorher öffnete jeder Aufruf eine Verbindung ohne diese Einstellungen. Bei mehreren
|
||
gleichzeitig schreibenden Agenten gab das `database is locked` — das sah nach einer
|
||
Grenze von SQLite aus, war aber nur fehlende Konfiguration. Zwei Tests decken das
|
||
gezielt ab (60 gleichzeitige Schreibvorgänge, gemischtes Lesen und Schreiben).
|
||
|
||
## Offen
|
||
|
||
- **Automatische Einblendung**: Ein Agent muss `recall` derzeit selbst aufrufen. Für
|
||
geplante Läufe wäre eine kurze Übersicht der wichtigsten Erinnerungen im Auftrag
|
||
hilfreich. Sie gehört in die Nutzernachricht, nicht in den System-Prompt — sonst
|
||
verfällt bei jedem Lauf der Prompt-Cache (T1).
|
||
- **Verfall**: Alte, unwichtige Beobachtungen könnten nach einer Frist entfallen.
|
||
- **MySQL**: Zweite Implementierung von `IMemoryRepository`, wenn mehrere Rechner
|
||
dazukommen.
|