Suchfähige Langzeitmerkmale für Datenengineering-Agenten

Stateless-Agenten lösen Probleme gut. Sie sind jedoch schlecht darin, sich daran zu erinnern, dass sie sie bereits gelöst haben.

Das Amnesie-Problem

Stellen Sie sich einen Agenten vor, der fast eine Stunde damit verbringt, einen NoClassDefFoundError in einem frisch erstellten Databricks-Notebook zu beheben. Er geht den Stack Trace durch, findet die fehlende Bibliothek im Job-Cluster, wendet eine Lösung an und bestätigt einen reibungslosen Ablauf. Solides, autonomes Debugging.

Eine Woche später tritt derselbe Fehler in einem anderen Pipeline auf – der Agent hat jedoch keine Ahnung, dass er ihn bereits einmal gesehen hat. Die gesamte Debugging-Sitzung muss erneut mit vollem Kostenaufwand durchgeführt werden, wobei diesmal tatsächlich die Chance besteht, eine andere Lösung zu finden.

Das ist kein Modellversagen. So verhalten sich Agenten standardmäßig, und sie vergessen auf drei Arten:

1. Wenn eine Sitzung endet, verschwindet alles, was darin gelernt wurde.
2. Lange Sitzungen werden letztendlich zusammengefasst oder komprimiert, wodurch die übergeordnete Handlungsgeschichte erhalten bleibt, aber oft die wichtigen Implementierungsdetails weggelassen werden.
3. In Mehr-Agentensystemen starten die Arbeitsagenten in der Regel mit einem sauberen Kontext, erben nichts von früheren Agenten und behalten nach Abschluss ihrer Aufgabe nichts zurück.

Ein Team, das ein Mehr-Agentensystem betreibt, das Databricks Lakehouse-Pipelines erstellt, musste in allen drei Punkten diese „Amnesiegebühr“ zahlen. Ihre Lösung war eine suchbare Langzeitgedächtnisschicht.

Was „suchbares Gedächtnis“ bedeutet

In Agentensystemen werden zwei unterschiedliche Dinge als Gedächtnis bezeichnet, daher müssen die Begriffe präzisiert werden.

Das Kontextfenster fungiert als Arbeitsgedächtnis des Agenten. Alles, was darin gespeichert ist, steht dem Modell sofort zur Verfügung – allerdings nur für die Dauer der Sitzung. Sobald Informationen daraus verschwinden, gelten sie aus Sicht des Agenten als weg.

Das Langzeitgedächtnis ist eine dauerhafte Speicherstelle, die Sitzungen, Aufgaben und Agenten überdauert. Doch allein das Speichern reicht nicht aus. Gespeicherte Informationen werden erst zu nützlichem Gedächtnis, wenn sie automatisch erfasst werden, effektiv gesucht werden können und bei Bedarf in das Kontextfenster zurückgerufen werden. Der letzte Schritt ist der entscheidende. Eine perfekte Lektion, die niemals abgerufen wird, ist im Grunde genommen nicht vorhanden, und eine abgerufene Lektion ist wertlos, wenn sie nicht den Agenten erreicht, der die Entscheidung trifft.

Die Kognitionswissenschaft bietet eine Taxonomie, die sich gut auf Agentensysteme übertragen lässt:

• Episodisches Gedächtnis speichert Aufzeichnungen spezifischer vergangener Erfahrungen: archivierte Sitzungsauszüge, frühere Fehler mit ihren Lösungen sowie Entscheidungen aus früheren Versionen.
• Semantisches Gedächtnis speichert strukturierte Fakten wie „Die Entität X gehört zum Datenerzeugnis Y“ oder „Dieses Quellsystem authentifiziert sich auf diese Weise“, idealerweise mit Gültigkeitsintervallen, da sich Fakten ändern können.
• Prozedurales Gedächtnis umfasst das Know-how: Anweisungsdateien, Fähigkeiten sowie die Konventionen, die bei jeder Sitzung geladen werden.

Zwei Ebenen des Gedächtnisses

Eine Entscheidung hat einen großen Teil der Komplexität beseitigt: die Aufteilung des Gedächtnisses in zwei Ebenen.

Ebene 1, kuratiertes Gedächtnis. Eine kleine, manuell gepflegte Sammlung von Regeln, die bei jeder Sitzung geladen wird. Dazu gehören Architekturstandards, Sicherheitsanforderungen, Namenskonventionen und Governance-Beschränkungen. Speicherplatz ist kostspielig, daher ist diese Ebene für das reserviert, was stets verfügbar sein muss.

Tier 2, suchfähige Speicherung. Ein umfangreiches Archiv an Erfahrungen, das automatisch erfasst und nur dann abgerufen wird, wenn es relevant ist: validierte Lösungen, Erkenntnisse aus der Fehlerbehebung, Lektionen aus der Implementierung sowie Muster wiederkehrender Fehler. Standardmäßig bleibt es außerhalb des Prompt-Bereichs.

Die Faustregel:

Eine Regel, der man jedes Mal folgen muss, gehört in das sorgfältig ausgewählte Niveau. Eine Regel, die nützlich ist, wenn sich eine ähnliche Situation wiederholt, gehört in das suchfähige Niveau.

Diese Trennung bewahrt das Wissen, ohne den Kontextfenster zu überfluten.

Das mehragentige System, das es benötigte

Das betreffende System bewältigt den gesamten Datenengineering-Lebenszyklus und wandelt Geschäftsanforderungen in für die Produktion bereite Pipelines und Dashboards um. Ein Orchesterator koordiniert spezialisierte Arbeitsprozesse, wobei jeder Prozess nur eine einzige Aufgabe hat und nur die benötigten Tools verwendet:

• Funktionale Spezifikation: Es wird das Anforderungsdokument gelesen, eine Spezifikation entworfen und die Freigabe vom Anfragenden eingeholt.
• Technisches Design: Die genehmigte Spezifikation wird in einen Entwurf für Datenverträge sowie Zuordnungen von Quelle zu Ziel umgewandelt.
• Einholung, Transformation und Integration: Dabei entsteht der eigentliche Pipeline-Code – also Bronze-Notebooks, die Daten aus Kafka, SAP, REST oder Dateien abrufen, Silver-Notebooks, die die Daten umformen, sowie Gold-Dimensionenmodelle, alles in einem medallionartigen Aufbau.
• Validierung: Dieses Element ist das einzige, das in der Nähe eines Live-Clusters erlaubt ist. Es führt jedes generierte Notebook an temporären Testtabellen aus und überprüft die Ergebnisse.
• Repository: Es verwaltet Branches, Commits und Pull Requests.
• Überwachung: Sie beobachtet den CI/CD-Prozess, sobald eine Änderung eingefügt wurde.

Dashboard erstellt Analyse-Dashboards aus den Ergebnissen.

Kostenverfolgung gibt an, was all das kostet.

Die Architektur ist absichtlich isoliert. Die Worker laufen parallel mit getrennter Datei-Eigentumsstruktur, können nicht miteinander kommunizieren und beginnen jede Aufgabe in einem völlig sauberen Kontext. Der Orchestrator schreibt eine eigenständige Aufgabenanweisung, der Worker erledigt begrenzte Aufgaben, gibt ein Ergebnis zurück und verschwindet.

Die Isolation macht das System sicher und parallelisierbar. Gleichzeitig verschlimmert sie die Amnesie im Vergleich zu einer Ein-Agenten-Struktur, da jeder Worker jedes Mal wie neu entsteht. Jede Rolle sammelt ihre eigenen Erfahrungen, die es wert sind, aufbewahrt zu werden, doch keine davon überlebt das Ende einer Aufgabe, es sei denn, etwas außerhalb des Kontexts der Agenten bewahrt sie auf.

Merkmalsdesign für viele Agenten

Vier Mechanismen lösen dieses Problem.

1. Automatische Erfassung

Die Hooks im Agenten-Laufzeitumfeld werden zu zwei Zeitpunkten ausgelöst: wenn eine Sitzung beendet wird und unmittelbar bevor der Kontext komprimiert wird. Jeder Hook liest die Transkripte und zieht wiederverwendbare Erkenntnisse in einen Speicher. Niemand muss sich daran erinnern, Dokumentation zu schreiben oder eine Wissensdatenbank zu aktualisieren.

Auch die Speicheroperationen sind nicht blockierend. Falls die Speicherinfrastruktur ausfällt, tun die Hooks stillschweigend nichts. Die Speicherschicht dient dazu, zu helfen – sie sollte niemals zu etwas werden, ohne das die eigentliche Arbeit nicht weitergehen kann.

2. Eingeschränkter Zugriff

Der Orchestrierer besitzt das gesamte Speicherwerkzeugset. Die Worker haben nur drei Befugnisse: ihr eigenes Tagebuch lesen, ihr eigenes Tagebuch schreiben und im Speicher suchen. Die Tools sorgen dafür, dass dies eingehalten wird – nicht die Anweisungen – wodurch die Verantwortlichkeiten klar bleiben und verhindert wird, dass Worker den Speicher außerhalb ihres Aufgabenbereichs verändern.

3. Rollenspezifische Tagebücher

Jeder Worker erhält einen privaten Speicherraum für Erinnerungen. Laufzeitfehler sowie nachgewiesene Lösungen werden im Tagebuch des Validierungs-Agenten gesammelt, während der CI/CD-Monitor Fehlermerkmale sowie die wirksamen Korrekturmaßnahmen erfasst. Die anderen Agenten führen ähnlich begrenzte Speicherungen.

Die Tagebücher sind keine Kommunikationskanäle. Workers übertragen keine Nachrichten über den Speicher, und die Koordination erfolgt durch den Orchestrator, der dafür sorgt, dass jedes Tagebuch kohärent und relevant bleibt.

4. Abruf auf Kontextebene

Das erwies sich als die wichtigste Entscheidung. Workers starten mit einem leeren Kontext, sodass eine abgerufene Erinnerung nur dann nützlich ist, wenn sie in diesen Kontext eingefügt wurde. Die geltende Regel lautet:

Eine abgerufene, aber nicht im Kontext platzierte Erinnerung existiert für den Worker nicht.

Sobald relevante Lektionen gefunden werden, schreibt der Orchesterer sie direkt in den Aufgabenkontext, bevor die Arbeit verteilt wird. Allein das Abrufen reicht nicht aus – eine Lektion muss sichtbar sein, um angewendet werden zu können.

Aufbau in MemPalace

Die Schicht basiert auf MemPalace, einem open-source-basierten, lokal ausgerichteten Speicherrahmenwerk. Der Speicher, die Embeddings sowie der Suchindex laufen alle lokal, sodass keine Daten das Umfeld verlassen – was wichtig ist, wenn Agenten Unternehmensdaten und Produktionsysteme verarbeiten.

MemPalace speichert Erinnerungen als Textblöcke, die mit Metadaten wie dem erstellenden Agenten, einer Kategorie und einem Zeitstempel angereichert sind, und ordnet sie in separate Namensräume ein. Dadurch sind rollenspezifische Tagebücher nutzbar: Jeder Agent schreibt in seinen eigenen Raum und entwickelt im Laufe der Zeit Fachwissen auf.

Die Erfassung erfolgt über die oben genannten Lebenszyklus-Hooks. Am Ende der Sitzung oder vor der Komprimierung wird die Transkription gereinigt, in wiederverwendbare Lektionen umgewandelt, mit einem lokalen ONNX-Modell verknüpft und für spätere Abrufung indiziert. All das geschieht im Hintergrund, sodass die Agenten niemals auf Speicheroperationen warten müssen.

Der Abruf erfolgt hybrid, indem Vektorähnlichkeit mit Schlüsselwortabgleich kombiniert wird. Das hilft im Datenengineering, wo einige Signale semantischer Natur sind und andere aus exakten Zeichenketten bestehen. Ein Fehlername wie NoClassDefFoundError oder eine genaue Databricks-Laufzeitversion muss wörtlich übereinstimmen, während dasselbe Problem in anderer Form dennoch erkannt werden sollte.

Agenten erreichen den Speicher über MCP. Der Orchestrierer hat Zugriff auf das gesamte Werkzeugset, während die Worker nur diary_read, diary_write und search sehen, wobei die Grenzen durch die Tools und nicht durch Anfragen festgelegt werden.

MemPalace wurde gewählt, weil es lokal ausgerichtet ist, kostenlos ist und sich leicht integrieren lässt, doch die Architektur ist nicht davon abhängig. Mem0, Zep oder Letta könnten dieselbe Rolle übernehmen. Entscheidend ist nicht das Framework, sondern der Feedback-Zyklus: Erfahrungen erfassen, speichern und bei Wiederholung des gleichen Problems zur Verfügung stellen.

Was sich in der Praxis geändert hat

Der erste sichtbare Vorteil war die Fehlerbewertung. Eine grundlegende Regel für den Validierungsagenten lautet kurz: Bei jedem Fehler zuerst suchen, bevor man debuggt.

mempalace_search(query="NoClassDefFoundError DBR 14.3")

Wenn ein Fall erneut auftaucht, erhält der Agent eine Lektion, die aus einer früheren erfolgreichen Lösung abgeleitet wurde:

Das Bronze-Notizbuch für Aufträge stürzte bei DBR 14.3 mit einem NoClassDefFoundError zusammen, der mit dem Avro-Deserialisierer zusammenhing. Was die Lösung war: Die Serialisierer-Bibliothek muss explizit in der Konfiguration des Job-Clusters deklariert werden.

Der Unterschied ist groß. Anstatt eine Lösung von Grund auf neu zu finden, startet der Agent von Belegen dafür aus, dass etwas funktioniert hat. Der Vorteil liegt nicht nur in der Geschwindigkeit, sondern auch in der Konsistenz. Ohne Erinnerung könnten zwei Agenten, die vor demselben Problem stehen, jeweils eine andere, scheinbar vernünftige Lösung wählen. Mit Erinnerung entscheidet sich das System für eine Lösung, von der bekannt ist, dass sie funktioniert, und verwendet sie weiterhin.

Ahnliche Verbesserungen zeigten sich auch an anderen Stellen. Der CI/CD-Monitor integriert nun historische Vorkommen bestimmter Fehlermuster in seine Diagnoseberichte, die Session-Start-Hooks stellen den relevanten aktuellen Kontext wieder her, und spezialisierte Agenten entwickeln im Laufe der Zeit Fachwissen anstelle dessen, es ständig neu aufbauen zu müssen.

Es ist kein Neutraining erforderlich. Der Lernzyklus findet außerhalb des Modells statt: Erfahrung sammeln, Lektionen ziehen, Speichern, Abrufen, Anwenden.

Lektionen aus der Produktion

Seien Sie vorsichtig bei historischen Nachträgen. Der erste Versuch führte zur Importierung großer Mengen an alten Transkripten. Die Ergebnisse waren enttäuschend, da älteres Material oft neuere, bessere Erkenntnisse überschattete und das Abrufen unübersichtlich machte. Das Team gab den Massenimport auf und begann von vorne, seitdem die Echtzeit-Erfassung in Betrieb ist. Aktualität und Qualität sind wichtiger als Menge.

Schreiben Sie Erinnerungen in einfachem Sprachstil. Das Framework bietet kompakte Eingabeformate, die das Team übernommen hat. Die Wiederauffindung funktioniert am besten, wenn eine gespeicherte Lektion genau die Wörter enthält, die bei einer späteren Suche verwendet werden: Produktnamen, Entitätsnamen, Fehlermeldungen und Ausnahmeklassen. In einem Erinnerungsspeicher ist die Auffindbarkeit wichtiger als eine geringe Größe.

Wählen Sie sorgfältig aus, was Sie aufzeichnen. Nicht alles, was gesehen wird, verdient einen dauerhaften Platz. Wertvoll sind bestätigte Fehlerbehebungen, validierte Erkenntnisse und wiederverwendbare Lektionen. Routinemäßige Protokolle, vorübergehende Beobachtungen, wiederholte Statusmeldungen und sensible Informationen sollten weggelassen werden. Schlecht organisierte Erinnerungen häufen sich schnell an und können mehr Schaden anrichten als gar keine.

Ergebnisse

Immer dann, wenn Mitarbeiter wiederholt echte Arbeit leisten, erzeugen sie Erfahrungen, die es wert sind, aufbewahrt zu werden. Folgendes legt sich nahe:

• Teilen Sie das Gedächtnis in sorgfältig ausgewählte Regeln und suchbare Erlebnisse auf.
• Fangen Sie Lektionen automatisch ein, insbesondere vor der Komprimierung des Kontexts.
• Geben Sie den Mitarbeitern eng gefasste, rollenbasierte Berechtigungen.
• Ziehen Sie bei ähnlichen Problemen, bei denen bereits eine Lösung gefunden wurde sein könnte, zuerst auf gespeicherte Erinnerungen zurück.
• Fügen Sie die abgerufenen Erinnerungen direkt in die Anfrage ein.
• Betrachten Sie Erinnerungen als Beweise, nicht als unumstößliche Wahrheiten.
• Legen Sie mehr Wert auf die Qualität der Erinnerungen als auf ihre Menge.

Die wichtigste Lektion ist architektonischer Natur. Viel Aufwand wird darauf verwendet, Agenten intelligenter zu machen, doch in der Praxis entsteht langfristiger Wert dadurch, dass Systeme lernen, sich zu erinnern.

Verwandte Literatur

• Von Modellen zu Agenten: Die drei Verteidigungslinien neu gestalten — Wie die Governance von MLOps auf Agentensysteme übertragen wird: Was jede der drei Verteidigungslinien hinzufügen muss, wo die Lücken liegen und was die Regulierungsbehörden der EU, der FDA und der Finanzbranche signalisieren.
• Agenten-Speicher entwickeln, der das Gespräch überdauert, ohne Daten anzuhäufen — Ein dreistufiges Speicherdesign für Agenten: Lassen Sie den Sitzungszustand verfallen, halten Sie die Langzeitnotizen klein und editierbar und holen Sie aktuelle Daten frisch ab. Zusätzlich wird ein Fehlfall bei der Übertragung zwischen mehreren Agenten behandelt.

Erklärung von Agenten: Werkzeuge, Systemanfragen und der Gedanken-Aktion-Zyklus — Ein Einführungstext dazu, wie AI-Agenten funktionieren: Warum Chatmodelle vergessen, wie Werkzeuge einem LLM beschrieben werden, Systemanfragen, ReAct, Code-Agenten und Beobachtungen.