Files

T

RichardandClaude Opus 5 740649789e Eine Roadmap statt neun verteilter Listen

Der Stand lag ueber eine Bestandsaufnahme, drei Konzeptpapiere, vier
Umsetzungsplaene und zwei Deploymentcenter-Dokumente verteilt - jedes mit
eigener Reihenfolge, teils widersprueglich. Alle offenen Punkte daraus sind
in docs/Roadmap.md zusammengefuehrt.

Aufbau der neuen Roadmap
- Statusvokabular: erledigt / beschlossen-offen / Entscheidung noetig /
  zurueckgestellt / Idee. Damit steht das Geparkte sichtbar drin, statt in
  einem Konzeptpapier zu verschwinden.
- Herkunft-Spalte traegt das alte Kuerzel (S4, K2, B9, T4, F-A1, C1, DC1),
  damit die archivierten Papiere auffindbar bleiben, ohne sie zu lesen.
- Abschnitt 1 Reihenfolge, 2 offene Entscheidungen, 3 die Vorhaben nach
  Bereich, 4 Ideenspeicher, 5 Chronik des Erledigten, 6 Modell-Einstufung,
  7 Herkunftskarte.

Was dabei sichtbar wurde
- Neun Entscheidungen blockieren Arbeit, ohne dass sie Aufwand kosten -
  allen voran Matrix oder Rocket.Chat. Sie stehen jetzt gesammelt in
  Abschnitt 2 statt verstreut in den Diskussionsteilen der Konzepte.
- B8 (keine Tiefenbegrenzung bei AgentComm) ist unveraendert offen. Das ist
  keine Theorie: A haelt sein Gate, waehrend es auf B wartet - ruft B nun A,
  warten beide bis zum Timeout. Der Testfall A13 dafuer fehlt bis heute.
- Die vier Umsetzungsplaene vom 2026-08-05 sind alle unumgesetzt und waren
  in keiner Roadmap verzeichnet.

Archiv
Sechs Dokumente ziehen nach docs/archiv/: Bestandsaufnahme, Konzepte
Backup/Finanz/Analyse, Linux-Portierung-Analyse, Lizenz-HardwareId-v2
(gegenstandslos - LicenseLabrador ist ersetzt), Deploymentcenter-Review und
der 2.4-Integrationsplan. Sie bleiben als Begruendung lesbar, werden aber
nicht mehr fortgeschrieben; das README ordnet jedes einzeln ein und warnt,
dass ihre Quelltext-Verweise ins Leere gehen koennen.

Bauplan bleibt Bauplan
Taskboard, Audit, Staging, Memory, Agentenkommunikation, RocketChat und
Deploymentcenter-Integration bleiben in docs/ - sie sind die Detailvorgabe
fuer die Umsetzung, nicht Vorhabenlisten. Jedes bekommt oben eine Zeile,
die seine Rolle und den Umsetzungsstand nennt und auf die Roadmap zeigt.
Dasselbe fuer die vier Umsetzungsplaene: die Reihenfolge gilt in der
Roadmap, nicht im Plan.

Nebenbei repariert: Taskboard-Konzept und Teststrategie verwiesen auf
AgentScheduler und ToolJobScheduler, die seit der Scanner-Konsolidierung
geloescht sind. Alle Dokument-Verweise in docs/ sind geprueft.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-23 18:31:06 +02:00

3.5 KiB

Raw Permalink Blame History

Memory — Langzeitgedächtnis für Agenten

Bauplan zu einem gebauten System. Umgesetzt; der Stand steht in der Roadmap 3.2. Die drei Punkte unter „Offen" laufen dort weiter.

Löst K1 aus der Bestandsaufnahme: 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.

3.5 KiB Raw Permalink Blame History Unescape Escape